Homing all (RepSnapper)

I just got toe the point of moving things around with RepSnapper.

Now when I home all, It does the X then Y then Z.
This can't be the norm can it?!?! I haven't tried any other of the host software, so not sure if its a RepSnapper issue or firmware.

Every CNC I have worked on (I currently fix CNC lasers for a living), retracts the tool first, so the other axis don't crash into the tool.

Actually, I was just looking at the code for that (in the 5D firmware) this morning. That is the norm for the "official 5D reprap firmware" when it receives a G28 code.

You can specify which axes to home, and they are test for (and homed) in X Y Z order. If you just say "G28" then it does all axes, one at a time, in X Y Z order.

I do not believe that this behavior is correct, but nor is it incorrect. The closest thing we have to a "spec" for g-code says it's a "G0" or non-syncronized move. You might assume that means all axes traversing at max speed, and just not stopping at the same time, but it could also be taken to mean one at a time.

I'm trying to write something better and more consistent (for triffid's fiveD_on_arduino firmware) but getting it right in all cases is more complicated than I thought it would be.

---

--
I'm building it with Baling Wire

Yeah I can see where I can home a single axis, but like I said, for a 3 axis homing, the tool should retract first.
I might give a shot at fixing it, but thats down the road a bit (have a mega PLC program to finish up after this Mendel is up an running)

You could just write a simple g-code to do it and save it under one of the custom buttons.

That would be a workaround rather than a solution.

Yes, but normally when you want to home the axes there is nothing in the way, so the homing order does not matter. (Hopefully you removed your previous print before starting a new one?) With milling the order of homing becomes more important because you don't want your mill to crash into the material to be cut.