CNC Coordinate Systems

[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:

1. Hardware home. This ignores the control point and offsets completely. Axis "hit" something (switch, stall, etc). Control point literally "n/a" during this operation.

2. 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.