[LinuxCNC/linuxcnc Issue#126] coordinate system changed to G54 on Abort and program end

#1 – jepler 于 2016-08-14

@SebKuzminsky I can remove the affects 2.6/2.7 labels from this bug now, right?

#2 – SebKuzminsky 于 2016-08-14

I tried to fix this in 2.6 (and merged up to 2.7 and master), but my patches introduced other problems. I reverted my problematic fix in 2.6 and 2.7, but left it in master. I intend to fix the remaining issues in master, and we can then consider whether it’s worth backporting to the stable release branches.

#3 – SebKuzminsky 于 2016-08-14

I now think my original bug report was partially in error.

In 2.6, commit 48daf71 (before my broken Task changes), running a program to completion (ie, M2) has the documented behavior, at least as far as coordinate systems are concerned: the active coordinate system is reset to G54, independent of what was active in the program when the M2 was encountered. This is reflected in both the active gcodes list in the Status buffer, and in the coordinate system and coordinate system offsets in the Status buffer.

However, in that commit, aborting a program that has changed the coordinate system results in the inconsistent state originally reported by @zultron: the Status buffer’s “active gcodes” correctly include G54, but the Status buffer incorrectly indicates the coordinate system and coordinate system offsets that were active at the time of Abort.

#4 – zultron 于 2016-08-19

@SebKuzminsky, I see #138 may be a duplicate of this issue, my apologies.

I want to note that the change to G54 after an M2 is done deliberately in convert_stop(), whereas the coordinate system (or systems!) in effect after abort depends on the particular program; see my comment in #138. Also, I have a modified statbuffer-g5x-abort test in the updated state tags branch that demonstrates this subtlety.

#5 – VladAlpha 于 2016-08-22

Is there a document or standard somewhere that shows what ‘correct’
behavior should be expected wrt coordinate changes on m2 or abort or any
other state change? I am sitting on an oldish version and will upgrade v
soon and would be happy to know what to expect. This is not clear here.

Thanks!

On Aug 19, 2016 00:16, “John Morris” notifications@github.com wrote:

> @SebKuzminsky https://github.com/SebKuzminsky, I see #138
> https://github.com/LinuxCNC/linuxcnc/issues/138 may be a duplicate of
> this issue, my apologies.
>
> I want to note that the change to G54 after an M2 is done deliberately in
> convert_stop(), whereas the coordinate system (or systems!) in effect
> after abort depends on the particular program; see my comment in #138
> https://github.com/LinuxCNC/linuxcnc/issues/138. Also, I have a
> modified statbuffer-g5x-abort test in the updated state tags branch
> https://github.com/zultron/machinekit/tree/state-tags-master-lcnc-2.7
> that demonstrates this subtlety.
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> https://github.com/LinuxCNC/linuxcnc/issues/126#issuecomment-240923760,
> or mute the thread
> https://github.com/notifications/unsubscribe-auth/ACafMl7ULwrl3GyGaH1KSTBPVlSpbsKKks5qhS36gaJpZM4JXlnM
> .

#6 – SebKuzminsky 于 2016-08-22

@VladAlpha, the behavior on program end (M2 or M30) is documented here: http://www.linuxcnc.org/docs/html/gcode/m-code.html#mcode:m2-m30

The behavior of Abort is poorly documented, which is part of why I messed it up earlier. Here’s the meager docs I could find:
– http://linuxcnc.org/docs/2.7/html/code/code-notes.html#_abort
– http://linuxcnc.org/docs/2.7/html/code/nml-messages.html#emctaskaborttype
– http://linuxcnc.org/docs/2.7/html/gcode/coordinates.html#settingg92_values
– http://linuxcnc.org/docs/2.7/html/gcode/m-code.html#mcode:m73
– and my favourite, http://linuxcnc.org/docs/2.7/html/user/user-intro.html#modesof_operation, which says Abort is “self explanatory”…

I’d like to add documentation on what exactly Abort does, as part of the fix for this issue. I’ll sum up my goal here as: Abort should keep doing the thing it’s always done, but without the bugs

#7 – zultron 于 2016-08-22

Here’s what abort has always done, or anyway done since at least 2.6 (please check my statements):
– Preview: offsets in effect at last executing block will be set, as visible in DROs and origin
– Interp: offsets will be visible in the status buffer and through MDI motion commands as follows:
– If a queue buster follows the currently executing block in a program, offsets in effect at the queue buster will be set
– If no queue buster, and the program ends with M02 or M30, offsets will be reset to G54 coords

There’s a bug in there for sure, but what’s the expected state after abort? I see three options;

1) IMO, the state as visible in preview, i.e. offsets in effect at last executing block, is what people would expect (and besides, what they would most likely see), and interp state should be reset to match.

2) Another alternative is to call interp’s state the expected state, and update preview to match interp’s offsets. I can’t imagine anyone would expect that, though, particularly the case where interp stops with offsets preceding a queue buster; that could be pretty arbitrary, and leave operators scratching their head over where those offsets came from.

3) The third alternative I see is to reset everything, as though an MDI M02 followed the abort. IMO, this is undesirable, since resetting so much state makes the program difficult to resume (e.g. using ‘start from line’) or debug, and since clearing work offsets but leaving any G52 temporary offsets in effect leaves things in another head-scratching state.

#8 – Sigma1912 于 2025-06-05

I cannot reproduce this on 2.10 (master)

Maybe this can be closed?

#9 – andypugh 于 2025-06-05

@Sigma1912 What can’t you reproduce? I have read this through and I am not clear.
M2 does reset to G54 (and should, apparently)
Did you explicity abort and not see a reset to G54? I tested with a bad G-code in MDI, but I have not yet decided if that issues an abort.

#10 – Sigma1912 于 2025-06-05

I cannot reproduce this:

> even though you have mdi’ed say g57 – when you abort a program or a program stops – it defaults back to g54

Note that I interpret ‘abort a program’ as stopping it before it ends.

– a program ending in ‘m2’/’m30’ WILL indeed default back to g54 (As I understand it, that is intended)
– a program using ‘%’ (no ‘m2’/’m30’) will not default back to g54
– a program stop will not revert back to g54
– a program aborting can do strange things.

#11 – andypugh 于 2025-06-16

Yes, I concur, having done some basic testing.