Closed tomjnixon closed 13 hours ago
Thanks for reporting this. Will investigate tomorrow.
Adding the G10 nonmodal group check here should fix the issue.
I'll test it tomorrow
So the RS274NGC v3, point 3.5.5 states that:
The coordinates of the origin of the coordinate system specified by the P number are reset to the coordinate values given (in terms of the absolute coordinate system). Only those coordinates for which an axis word is included on the line will be reset.
Also LinuxCNC in https://linuxcnc.org/docs/html/gcode/g-code.html#gcode:g10-l2 defines that:
All axis words are optional. Being in incremental distance mode (G91) has no effect on G10 L2. Important Concepts:
- G10 L2 Pn does not change from the current coordinate system to the one specified by P, you have to use G54-59.3 to select a coordinate system.
- When a rotation is in effect jogging an axis will only move that axis in a positive or negative direction and not along the rotated axis.
- If a G52 local offset or G92 origin offset was in effect before G10 L2, it will continue to be in effect afterwards.
- When programming a coordinate system with R, any G52 or G92 will be applied after the rotation.
- The coordinate system whose origin is set by a G10 command may be active or inactive at the time the G10 is executed. If it is currently active, the new coordinates take effect immediately.
Looking at your example you mentioned that
(incremental l2)
g53 g0 z20 (abs z20)
g90
g10 l20 z0 (abs z20)
g0 z2 (abs z22)
(abs z 22, work 2, offset 20)
g91
g0 z1 (abs z23)
g10 l2 p1 z3
(offset should be 23, but is actually 26)
(Actually offset should be 3, since L2 states that the Axis values are relative to the homing origin = machine origin)
and https://linuxcnc.org/docs/html/gcode/g-code.html#gcode:g10-l20 defines that:
G10 L20 is similar to G10 L2 except that instead of setting the offset/entry to the given value, it is set to a calculated value that makes the current coordinates become the given value.
So
(incremental l20)
g53 g0 z20 (abs z20)
g90
g10 l20 z0 (abs z20)
g0 z2 (abs z22)
(abs z 22, work 2, offset 20)
g91
g0 z1 (abs z23)
g10 l20 p1 z3 (abs z23)
(abs 23 work 3 -> work 6)
(offset should be 17 (abs 23, work 6), but is actually 3 (work 26))
(Actually offset should be 20, since L20 states that the Axis values are relative to the current machine position)
Am I interpreting this wright? My question with L20 is that if the G92 affects the final axis value or not. I need to try running this on LinuxCNC to check it out.
Hi, thanks for looking into this.
I agree with your interpretation -- my examples were talking about what should happen if L2 and L20 are affected by incremental mode.
Your examples look right to me if they are not affected by incremental mode.
I actually detected another unwanted behavior. It's more of a transitional report error.
Offset commands like G92, G10, and coordinate system commands have immediate effect. That causes a status report temporary error that leads the WCO to be modified while previous motions are still being flushed. The status then auto-syncs once the code catches the new workspace but for some brief moments the machine show itself out of place.
I will fix this also by forcing it to interpret these commands as in sync commands.
After reading G10 and G92 several times, I'm under the impression that G10 does not take in account G92 offset because it says:
When programming a coordinate system with R, any G52 or G92 will be applied after the rotation.
But I need to confirm that over LinuxCNC
You can try #791 and see if it fixed the issue. I did some testings and seems ok, but I need to compare it to LinuxCNC
Thanks, I'll have a go this evening.
I tested on LinuxCNC. From what I understood both G10 L20 and G92 affect each other. That means that G92 offset will also enter the calculations for G10 with L20. I need to make a slight modification to the code to take that in account.
@tomjnixon I've modified #791.
I sill nee to run a final test file but as far as I can tell G10 L2, G10 L20 and G92 are now working as expected and relative to each other.
Please give it a try.
Describe the bug The behaviour of
g10 l2
andg10 l20
is affected by the absolute/incremental mode, when it typically isn't in other controllers. Obviously this is a silly thing to do on purpose, but my sender (bCNC) does this by accident, assuming that it these ignore the mode.In general,
g10 l2
andg10 l20
both have a reasonable incremental interpretation (add to the offset or the current work position), but that doesn't seem to be what happens in uCNC (they both seem relative to the absolute machine position),I've had a dig around, and i think the
l20
special case was added by LinuxCNC, and it looks like thereg10 l2
andg10 l20
are not affected by incremental mode:https://linuxcnc.org/docs/html/gcode/g-code.html#gcode:g10-l2 https://linuxcnc.org/docs/html/gcode/g-code.html#gcode:g10-l20 relevant code: https://github.com/LinuxCNC/linuxcnc/blob/636da8030cadfad5c37ec130c6d3304030511048/src/emc/rs274ngc/interp_convert.cc#L4723
It looks like in GRBL these also are not affected by incremental mode;
applied here: https://github.com/grbl/grbl/blob/9180094b72821ce68e33fdd779278a533a7bf40c/grbl/gcode.c#L561
before incremental is applied here: https://github.com/grbl/grbl/blob/9180094b72821ce68e33fdd779278a533a7bf40c/grbl/gcode.c#L590
"The NIST RS274NGC Interpreter" also seems to say that these should not be incremental.
What is your hardware https://github.com/tomjnixon/uCNC/tree/my_config based on current master 73f9b5366bf7ffb526cc637b0c822cd04d293308
What was the GCode running
The following snippets can be used to see the behaviour in all four cases: