Probably a stupid question, but…
From what I’ve observed, pressing the “Home” button in Ground Control will start moving the sled and the z-axis to their saved values. Sometimes, if the bit is in the work, this means dragging the bit across the wood until the z-axis has cleared the surface.
Is there a reason why the z-axis doesn’t retract at least to 0 or maybe a little higher before moving the sled motors?
Or am I just missing an option or something?
It should retract to a height of .25 (above the work surface) and then begin it’s move. When it arrives it goes back to 0. I just tested it and at least as far as I can tell it seems to be working. Are you seeing it start to move before retracting? What does the digital readout of the z-axis position say when it starts to move?
I had some issues where the bit was not zeroed in GC/firmware, thought it was way above the sled (around 25 inches iirc), and then proceeded to try to drill it’s way back to it’s concept of zero leaving a souvenir in the table. I’m not near the Maslowto find the correct procedure, but did you zero your bit.
There’s also an automatic zero (programmatic home?) that requires a conductive surface (aluminum foil?) and one of the aux pins, but it’s on my to-do list.
you just found a bug. It just moves to 0,0,0 when it should move the Z by itself
and then to x0y0
I may have contributed to this.
When I moved us to fully coordinated 3D movements I didn’t check to see how the home command works. If the Z retract is not on a line by itself it will get interpolated with the XY movement.
I just tested it on the latest and I saw it lift before going home, then return to height zero.
It sends the lift as one command followed by the move command so we should be good on the new coordinated move code not having an effect.
Would someone else be willing to give it a try and see what behavior they see?
Here is the relevant code:
def home(self):
'''
Return the machine to it's home position. (0,0) is the default unless the
origin has been moved by the user.
'''
self.data.gcode_queue.put("G90 ")
#if the machine has a z-axis lift it then go home
if int(self.data.config.get('Maslow Settings', 'zAxis')):
if self.units == "INCHES":
self.data.gcode_queue.put("G00 Z.25 ")
else:
self.data.gcode_queue.put("G00 Z5.0 ")
self.data.gcode_queue.put("G00 X" + str(self.data.gcodeShift[0]) + " Y" + str(self.data.gcodeShift[1]) + " ")
self.data.gcode_queue.put("G00 Z0 ")
#if the machine does not have a z-axis, just go home
else:
self.data.gcode_queue.put("G00 X" + str(self.data.gcodeShift[0]) + " Y" + str(self.data.gcodeShift[1]) + " ")Yeah, stupid of me not to include the version. I’m on .97
I’ve got a cut going now, but I’ll do a home test once that’s done.
.98 is up now. .99 next Wednesday? You might want to update.
Thank you for the follow up. Keep up the good work.
Well, I just tested it and of course it’s working as Bar described. I SWEAR that’s not what it did before, but maybe I did something weird.
Sorry for causing trouble.
As it should. Any other way will cause some serious breakage. If you want separate moves then they should be sent as separate moves. That’s what coordinated movement is all about
This is why taking advantage of the ‘feature’ to skip the G command on the line
is a really bad idea 
No worries, I bet it did “forget” to retract for some reason. Keep an eye on it and let us know if it happens again. If it does see if you can reproduce it so we can track down what is going on
There is nothing to be sorry about. On 1 test sheet I have scratches from Home+Z on both sides and on the new one on 1 side.
Personally I find it annoying that I have to wait for Z before moving Home, but there are security aspects.
I think this is worth a more general discussion about the expected result of pressing the button.
After a cut, GC should know where Z is because 0 was set and if it did not glitch or backlash, should go safely home. (here I think a good g-code would have already put Z to safty hight). Not so after a tool change or before a cut, because then the actual Z-Hight is not known.
Do note: if you update to the version 0.99 of either, you must up update both - they are interdependent. 
but well worth trying.
I ran into the problem today using 0.99. I stopped a job during the process and the tool was still embedded in the work piece. When I hit home, it did NOT raise the bit before moving to home position… iirc, it was doing it in conjunction with the xy move. I was able to catch it and move the sled away from the piece, but it was a little scary ( I just spent 3 hours cutting out something and it was about to be cut in half 
)
Ok so we know the issue is still out there then.
The fact that the bit did retract, but it did it at the same time as the XY move makes me think it might be a serial issue. If we were to accidentally lose the newline character which marks the end of the line I could see the behavior you saw happening. We’ve seen the last character being lost due to serial issues in the past. It’s intermittent and tough to track down.
Without the new line the line would look something like G0 Z5 G0 X0 Y0. The parser will ignore the second G in the line and process it as a single move. Even worse, if the the second gcode line omits the G0 we might get the command G0 Z5 X0 Y0 which is a completely valid move.
I think the only solution is to dig into the serial code again…does anyone else have a theory which might be easier to investigate?
I can’t guarantee this was the case (that the z axis bit was retracting while moving xy) I can only guarantee that it moved while the router bit was still in the piece… this was unexpected. I immediately powered off the router and was more focused on the piece I cut and not what was going on with the router z-axis.
I wonder if it behaves differently when you issue a stop command on running gcode and then press home.
Is the gcode sent from GC to the controller (firmware) where the issue was? A simple CRC w/resend might make sense to include (not simple to implement, I know, but it would counter bad serial data).
The log.txt file would have had the echo of the lines as they were interpreted by the firmware, yes?
Could it be related to the state left behind by the ‘Stop’ command? Does the ‘Home’ button send all the codes necessary to put the firmware back into the default state?