CNC Coordinate Systems

resam

sounds like the same problem I reported here: https://forum.duet3d.com/topic/7940/firmware-2-02rc5-now-available/7

@dc42 in RRF, when you call resume.g to run DoFileMacro, there is this line:
gb.MachineState().useMachineCoordinatesSticky = true; // running a system macro e.g. homing or tool change, so don't use workplace coordinates

Not sure if thats the actual problem - but something to know about.

Related question: is pause+resume aware of "relative positioning" and "relative extrusion" and does it reset the correct state as it was before pausing? While paused the user could have changed it to move around...

dc42

Thanks @resam, that explains it. I now remember making that change so that homing wouldn't be messed up by workplace coordinates.

To fix it, I think I could change it so as not to apply that sticky G53 in the case of running resume.g. That would mean that if resume.g does any moves apart from ones to restore the original position (e.g. wiping the nozzle on a FDM printer), they would need to be prefixed by G53. Does that sound a reasonable solution?
An alternative would be to record all restore point coordinates in machine coordinates, and to use machine coordinates always when the R parameter is used on a G1 command.

In answer to your other question, whenever a macro file is run the relative/absolute movement and extrusion states are remembered at the start and restored at the end.

resam

I don't really know what G53 and G54 do - and I don't think I want to bother with them in a 3d-printing task (I guess I can only speak for 3d-printing use cases, as I don't run CNC-style jobs). Most people I believe already have difficulties with G90/G91.

In my case, I just want to move the head to to a parking position during pause, and move back to the last position on resume.

I wasn't even aware that RRF already provides this hard-coded - I assumed it has to be specified in resume.g - thats also what the examples did, so I copied it. I will try to remove my G1 R1 ... commands from my resume.g at let the firmware do it.

dc42

This is getting complicated. Currently there is an inconsistency in how tool offsets, workplace coordinate offsets (which includes M206 offsets) and Z-hop offsets are applied to restore points. So I'm trying to find a unified scheme for handling restore point coordinates.

What I think is required is:

When moving to a restore point (using the G1 R parameter), tool offsets are taken into account. This means you can create a restore point, switch tool, then send the new tool to the same point even if it has a different offset. This is needed e.g. when switching between extruders on a dual extruder FDM printer.
When moving to a restore point at the end of resume.g, the same workplace coordinate offsets that were in effect when the restore point was created should be applied, even though workplace coordinates are not normally applied when running resume.g.
So this begs the question: suppose you create a restore point (G60), do something, change to a different workplate coordinate system or change the offsets of the current one, then use G1 R1 to go back to the restore point. Should it go to the same machine position as before, assuming that there has been no change to the tool offset? Or should it go to the same user position, which will be a different machine position if the workplace coordinate offsets have changed?

The NIST standard doesn't define G60, so no help there.

Currently I am considering storing the user coordinates offset by the current workplace offsets in the restore point. This would mean that in case#3, the point in space that the tool moves back to would be unaffected by changes to the workplace coordinate system since the restore point was created. I think that's safe and sensible, although it would preclude the use of a restore point to save position, change workplace coordinates as part of a step-and-repeat operation, and then use G1 R1 to move to the corresponding position in the new coordinate system.

Danal

I believe the answer to all scenarios is "consider the control point":

The control point is the "tip" of the tool. All work coordinate offsets, too lengths, etc, contribute to that.

There are ONLY two exceptions, that I'm aware of:

Hardware home. This ignores the control point and offsets completely. Axis "hit" something (switch, stall, etc). Control point literally "n/a" during this operation.
Tool change. For pragmatic reasons of "tool holders", it also ignores many types of offset. Note that the NIST standard is very unclear about how this really works, but many big CNC makers are quite clear in their documentation: No offsets active.

Those two cases aside, EVERYTHING should result in putting the "Control Point" in the "correct" position.

I realize that's a very 'soft' description... but... with some thought applied to it, it does seem to be a very useful way to validate or invalidate scenarios.

dc42

@danal, thanks for your response. However, I'm not clear what is the "correct" position in the case that you save a position using G60, then maybe change workplace coordinate offsets, maybe change tool to one with different offsets, then use G1 R to restore the position.

Is the "correct" position for the (new) control point the same physical position as that of the (old) control point when G60 was executed? If so then I think my approach of storing restore point coordinates as user coordinates with the workplace offsets removed is suitable. That way, in determining the machine position to restore the tool head to, changed tool offsets would affect that machine position but changed workplace coordinates would not.

bot

@dc42 said in CNC Coordinate Systems:

[...]
Is the "correct" position for the (new) control point the same physical position as that of the (old) control point when G60 was executed? [...]

If the user is changing the WCS, then the tool would presumably going to a different physical location relative to the work piece. This, of course, assumes that the origin of that different WCS is in fact in a different physical space. If the two WCS have the same origin, there would be no reason to change to the new WCS.

Alternate WCS are used to perform the same operations, using the same gcode, on various work pieces all laid out at once on the table. Say you have 6 of the same part you want to perform machining operations on, and they are laid out on the machine table with 6 vises in a 2x3 configuration. You would set the origin for 6 different WCS to a specific corner on each of the 6 different work pieces. You can then load a gcode file, run it on one WCS, then switch to a new WCS to perform the same action on a different part. This way, the gcode file's coordinates don't change, but the physical location (coordinates in MCS) is changing due to selecting new WCS with differing origins.

So, given that (sorry if I'm explaining things you are already aware of) if a user changes WCS during a pause, the tool is usually moving to a new physical location.

Danal

@bot said in CNC Coordinate Systems:

@dc42 said in CNC Coordinate Systems:

[...]
Is the "correct" position for the (new) control point the same physical position as that of the (old) control point when G60 was executed? [...]

If the user is changing the WCS, then the tool would presumably going to a different physical location relative to the work piece. This, of course, assumes that the origin of that different WCS is in fact in a different physical space. If the two WCS have the same origin, there would be no reason to change to the new WCS.

Correct, with a few caveats, see below.

Alternate WCS are used to perform the same operations, using the same gcode, on various work pieces all laid out at once on the table. Say you have 6 of the same part you want to perform machining operations on, and they are laid out on the machine table with 6 vises in a 2x3 configuration. You would set the origin for 6 different WCS to a specific corner on each of the 6 different work pieces. You can then load a gcode file, run it on one WCS, then switch to a new WCS to perform the same action on a different part. This way, the gcode file's coordinates don't change, but the physical location (coordinates in MCS) is changing due to selecting new WCS with differing origins.

Agreed, this is one use case. Another is having 0,0 be the corner of a "fixture", even for a single machining operation. Another is to set 0,0,0 as you go, by using an "edge finder" (wiggler) and a Z-probe (often the bit itself in the CNC world, both the bit and the stock are often metal).

In fact, setting "Z-Zero" with a probe operation is probably the most common use of Work Coordinate Systems. Even people who don't realize they are using a WCS when they probe... they really are. Remember, per NIST standard, the machine is ALWAYS in ONE of the Work Coordinate Systems. (Unless executing a line that has G53 on that line). So a probe that sets Z0 is ALWAYS setting the 'current' WCS.

So, given that (sorry if I'm explaining things you are already aware of) if a user changes WCS during a pause, the tool is usually moving to a new physical location.

Agreed. Let's start examples without the Pause:

G90 ;Absolute mode
G54
G1 X22.5 Y22.5 Z1
G55
G1 X22.5 Y22.5 Z1

WILL produce a move on the last G1 (assuming G54 and G55 have different offsets)

Whereas:

G90 
G54
G1 X22.5 Y22.5 Z1
G54
G1 X22.5 Y22.5 Z1

Will not produce any motion.

.

Now with a pause:

G90
G54
G1 X22.5 Y22.5 Z1
G60 S0
G55
M226   ; Pause
[...user interaction... for clarity, no moves.]
G1 R0

Reading this, I would expect the machine to move to X22.5 Y22.5 Z1 in the new G55 coordinate space. on the last G1. A physical move will occur (assuming G54 and G55 are different offsets). Having the R0 should be exactly like specifying the X Y Z stored in 'slot 0'. G55 is in effect... so G55 should be in effect.

Thoughts?

Edit: Corrected a typo in my descriptions.

bot

@dc42 said in CNC Coordinate Systems:

So this begs the question: suppose you create a restore point (G60), do something, change to a different workplate coordinate system or change the offsets of the current one, then use G1 R1 to go back to the restore point. Should it go to the same machine position as before, assuming that there has been no change to the tool offset? Or should it go to the same user position, which will be a different machine position if the workplace coordinate offsets have changed?

My last answer was maybe not very clear, so I'll re-state it by answering this specific question.

IMO, in that situation, it would move to a different physical location, respecting whichever new offsets were set during the pause.

Any scripted moves in resume.g or pause.g would need to reference G53 in order to command moves like wipes or tool changes at specific absolute locations.

Danal

@bot said in CNC Coordinate Systems:

@dc42 said in CNC Coordinate Systems:

So this begs the question: suppose you create a restore point (G60), do something, change to a different workplate coordinate system or change the offsets of the current one, then use G1 R1 to go back to the restore point. Should it go to the same machine position as before, assuming that there has been no change to the tool offset? Or should it go to the same user position, which will be a different machine position if the workplace coordinate offsets have changed?

My last answer was maybe not very clear, so I'll re-state it by answering this specific question.

IMO, in that situation, it would move to a different physical location, respecting whichever new offsets were set during the pause.

Any scripted moves in resume.g or pause.g would need to reference G53 in order to command moves like wipes or tool changes at specific absolute locations.

Agreed.

The ultimate G1 R0 that we are talking about should do EXACTLY what a G1 Xnnn Ynnn Znnn would do (where each nnn was captured by a prior G60). The word "EXACTLY" includes honoring the coordinate system in force at the moment of the G1 R0 is executed.

dc42

Thanks, both of you. I think all I need to do is to change the firmware so that an actual or assumed G53 command is ignored for a G1 R move. Then a G1 R move in resume.g will work properly.

mwinterm

@dc42 Please add the same way as WCS as well ToolOffsets.

PS: I would vote for option (a) even though (c) is fine as well as behavior (a) can be kind of mocked up using macros.

Ryan Lock

Hi, I just wanted to see if a unified scheme for restore points was sorted? And that restore points will now go back to the correct position for the work coordinate systems, without having to manually select the work coordinate system before resuming?

In addition, I was testing the power loss resume today, and it seems that it ignores which coordinate system was selected when the file was running. Even manually selecting the coordinate system before resuming doesn't seem to work. I tested this today on 2.02 RTOS

Ryan Lock

dc42

@ryan-lock said in CNC Coordinate Systems:

Hi, I just wanted to see if a unified scheme for restore points was sorted? And that restore points will now go back to the correct position for the work coordinate systems, without having to manually select the work coordinate system before resuming?

In addition, I was testing the power loss resume today, and it seems that it ignores which coordinate system was selected when the file was running. Even manually selecting the coordinate system before resuming doesn't seem to work. I tested this today on 2.02 RTOS

Ryan Lock

I am out of the office, but AFAIR I fixed this in the 2.02 release.

A Former User

Is there currently any way to probe in directions other than Z? I see G38.x isnt supported, and G30 only takes x and y for locations to do the Z probe.

G38.x would be nice to have for CNC.

dc42

@bearer said in CNC Coordinate Systems:

Is there currently any way to probe in directions other than Z? I see G38.x isnt supported, and G30 only takes x and y for locations to do the Z probe.

G38.x would be nice to have for CNC.

Look up M585 in the GCodes page of the wiki.