I’ve noticed that if I tell the machine to return to zero after I cancel a job, it slams the x, y, and/or Z axis and goes nowhere near the zero I set. Any ideas why? This is annoying as heck. I hit Reset Zero before the job very carefully and it makes no difference. If I hit cancel it goes haywire. If the job completes properly, no problem. I can then return to zero without a hitch.
Any ideas?
really? So the abswer is not to retun to zero from cancel.? Is it the controler software? You’d think soemethibg this asic would have been adressed lo g ago.
Are you skipping steps? Mine always returns to work zero after cancel. But I’m still running the Arduino.
Using Universal G-Code Sender
I had this happen on the Z-axis with UGS. Did some googling and found a thread in a forum where the developers were talking about the “runaway z” when returning to zero. I just stopped using that command, don’t know if there’s a fix.
What version of grbl are you using?
What version of UGCS are you using?
More information is needed to determine why you are getting the behavior that you are experiencing.
What is the command that is being issued when you press the “Return to Zero” button? (it shows in the display window)
What is the $G and $# output information just before you press “Return to Zero”?
Been using 1.0.9 for 1 1/2 years. Never had a single glitch.
Obviously, your mileage did vary.
I’ve seen countless posts concerning this and I don’t know exactly what was going on. Never was able to get anyone to do some debugging with me on the issue to find out what the straight story was.
Here is what gets generated when I press “Return to Zero” on version 1.0.9.
G90 G0 Z0.0
G90 G0 X0 Y0 Z0
For some time there were many versions of firmware that were floating around for the Inventables fork of grbl with the same version #. Maybe the same thing occurred with UGCS.
Yes, Larry, this is 1.09. Its scary.
V2 reverses this by sending it to XY0 then lowering the bit to Z0. Good except when you realize you left the bit below zero.
Still playing
What program do you use to generate your G-code?
this is just gcode. nothing special.
I guess that most people are using the “Return to Zero” inappropriately.
The machine is just doing what it has been asked to do. Moving X and/or Y first is potential more damaging as the location in Z is not known when the command is requested.
Moving to Z=0 should clear the work surface (if it’s flat) before moving X and Y.
I guess most people have Z=0 too low.
The reason that I asked is there is most likely a way to get the function that you want, but setting it up depends on how the G-code is generated.
If you are writing the G-code yourself then it’s even easier to get what you want.
Getting back to the original question:
In UGCS version 1.0.9
Start a job
Cancel the job
get the $G and $# output from grbl and post it here along with the $$ output
I’ll see if I can determine what is happening.
