DXF curves jerky 1.1f CNC Z-XY
Agree not sure where I can go from here except to compare the parameters between the two versions. I would certainly like to keep the Z homing for sure. I'll try turning the laser right down so it it simply draws on paper and see if I can see the difference that way. But the movement is very noticeable on the curves.
Now we have a worse situation!
I did compare the 1.1e and 1.1f CNC Z-XY gbrl parameters and there are no differences at all. I made sure that after loading each firmware I loaded the defaults and they are the same.
Bigger problem is that as a test I loaded your 1.1f XY home firmware, and got a sync error at the end. However the firmware seems to have loaded. The big problem now is I can't load any other firmware. I just get a failed to load 1/1 error and the firmware has not changed. The main DOS box closes after a second, and another empty one pops up followed by the error. Of course it's not got the firmware to home the Z, AND it has the same problem as the CNC version - Jerky curves.
I have the 3 axis mana board and there is no reset switch on it to press, and removing power doesn't help.
Any advice on how to recover this situation??
Ok, I replaced the nano with the old one from the original board and we are back to sq 1. Can load firmware now. I have a spare Arduino uno, so I'll use that to reload the boot loader later.
So we are still left with 1.1fCNC Z-XY as suspect...
@DavidF Do you know how to compile and load your own firmware using Arduino IDE?
Yes. I have written code for Arduino on other projects. What do you suggest?
@DavidF I would get the latest Grbl (v1.1f 2017-08-01 Release) from https://github.com/gnea/grbl/releases and set your required homing Z then XY if you want to match my firmware and compile to your Nano and see if it shows the same issue.
These would be the only changes necessary:
#define HOMING_CYCLE_0 (1<<Z_AXIS)
#define HOMING_CYCLE_1 ((1<<X_AXIS)|(1<<Y_AXIS))
#define X_LIMIT_BIT 1 // Uno Digital Pin 9
#define Y_LIMIT_BIT 2 // Uno Digital Pin 10
#define Z_LIMIT_BIT 4 // Uno Digital Pin 12
I should have time to do this next week but since I'm not seeing the issue I would still have to send to you for testing and feedback.
Hi Zax, I am back working in China for a couple of weeks so can't do this right now, but I'll see if I can get the source into the IDE. I suppose I could add your homing code to 1.1e as well, as that version doesn't have the problem??
Just had a look at the config.h file for both 1.1e and 1.1f and they are the same as far as the homing cycle is concerned. So what is different with your firmware? how come your 1.1e doesn't support Z homing? Is it just that you defined the cpu_map differently in 1.1e?
Just trying to make sure I understand what I am doing before I attempt this!
Any chance of a look at your config.h??
NOTE: I just looked at the cpu_map.h and that seems to have the same pins allocated as you mention above, is it still necessary to paste your values into config.h?
Agai just checking I understand all this before I break something:-)
Sorry Zax, another question as I get in to this. In your load firmware section, you have about 6 different 1.1f versions. Are they all the same as the GitHub 1.1f, but the default parameters you load with them are different, hence your various suffix to tell them apart.
@DavidF The only difference with my default 1.1e is I disabled the Z-homing and set X/Y to use the same pin and home sequentially as it's easier for people to connect one wire (D9).
config.h would look like this:
#define HOMING_CYCLE_0 (1<<X_AXIS)
#define HOMING_CYCLE_1 (1<<Y_AXIS)
#define X_LIMIT_BIT 1 // D9
#define Y_LIMIT_BIT 1 // D9
I don't keep the files, but as you can see the changes are very minor so I just edit and compile. The various firmware are all basically the same, depending on the machine some pins may be changed in the cpu map or the homing sequence etc. but I always use the same basic parameters.
I always use the latest version from github and if I notice updates that are necessary I will also recompile my default to get the new changes but since 1.1f didn't really have anything I considered "necessary" I left the default at 1.1e. Any new firmware I've compiled would use f, which is why you see a combination but I haven't seen the problem you are having in my testing.
Perfect Zax, so what i'll do when I get back is Un brick my Nano then edit the config.h for 1.1e so that Z homing is enabled and XY home separately (like 1.1f. And I'll make sure that works. Then I'll do the same with 1.1f and see what happens. I'll update my un bricked Nano so that if everything goes "pear shaped" I'll at least have the current Nano that works! I'll keep you posted.
@DavidF That sounds like a good test, I'm interested to hear the results.
I'll keep you posted Zax.
Hi Zax, ok, I un-bricked the nano by using my spare arduino. I recompiled the 1.1e firmware from github with XY&Z homing enabled and the curves are cut smoothly in CNC mode so I have a version that works perfectly for me. However, I did exactly the same with the 1.1f version, also from Github and in CNC mode that has the jerky movement on curves. I Have compared the parameters for both 1.1e and 1.1f and they are the same. So I assume there is some other change in the firmware that is possibly not compatible with my control board (Bang good Mana 3 axis.). I read through the release notes and they don't mention anything that jumps out as a possible change. So at the moment I can stick with 1.1e with XY & Z homing and I'll be fine.
@DavidF That's good diagnostics work, but very strange result. I use my default Grbl 1.1e on the lasers and the 1.1f XY Home Sw. on my CNC but have never noticed this. My CNC uses a Nano with a Xylotex stepper driver board.
Yes, it's weird. Tried it with a genuine Nano I had spare and that was the same. Who knows:-)
If I find anything I'll let you know.