Well, I can only tell you what should happen on a Nomad since I don’t have a ShapeOko. But there is one thing both of them have in common: Grbl. Grbl doesn’t know anything about M6, it’ll barf if you send it directly to the Grbl board. However, Carbide Motion knows what it is and turns it into other g-code that it sends to Grbl. On the Nomad, it looks something like this:
; Here there’s a pause with a prompt in Carbide Motion
G0Z(current)+3 ; carbide motion actually computes an absolute coordinate to do a relative move of up 3mm
You can’t just run that as a gcode script because Carbide Motion reads the resulting positions from the Grbl responses and uses that to compute subsequent moves. Also, it waits for Grbl’s queue to be empty at several points.
Also, a thing to note here is that CM always works in machine coordinates and does the work coordinate translation itself (on the Nomad at least). That’s why all the coordinates are negative off of the 0,0,0 that is the homed position.
So on a Nomad, the script you gave would work, but it would have unnecessary movement because it would first move 50.8mm up off of the Z-zero, then move to the X0 Y0 coordinate of the work piece (often lower left corner of the stock) but then raise Z all the way up and center it left-to-right and ask you to change the tool to “#02”.
On a Shapeoko, I would guess it could do the same except for two problems. One, it could only really move in absolute terms if it knows that you have homing switches and where those are, so you have to make sure your Grbl settings reflect this. Second, after the tool is changed, it needs to measure the tool to maintain the Z zero, but the ShapeOko doesn’t have a tool measurement probe, so really it’d have to ask you to re-zero Z, but I don’t think that’s hooked up to anything yet (maybe when they produce the Z-probe?).
What I don’t understand is that your G0 Z50.8 should move you up 50.8mm from your work zero regardless of the M06 tool change. Why doesn’t that work?