Program abort hides active G52/G92 from DRO

[Sigma1912]

Using a current RIP installation of 2.9.2:

1. Start 'configs/sim/axis/axis_mm' and home the machine

2. Load a gcode like this:

   g10 l2 p0 x0y0z0
   g92 x100
   (abort,program aborted)
   m2

3. Run the above Gcode which will abort with message 'program aborted' Note: the DRO shows 'X: 0, Y: 0, Z: 0' and no active G92 offset

4. Run this command in MDI: G0 X0

We would expect no tool movement as the DRO shows the tool in X=0, however the tool moves to the new position 'X=-100'. Apparently the Abort cleared the G92 offset from the DRO but left it active in the background.
Note that changing the active work offset system (eg G55 and then back to G54) will set the DRO right.

This is equally true for G52:

g10 l2 p0 x0y0z0
g52 x100
(abort,program aborted)
m2

only that the tool will move to 'X:100' after the 'G0 X0' command.

This seems related to this issue: https://github.com/LinuxCNC/linuxcnc/issues/2745

[andypugh]

(abort, xxxxx) should probably always have an ON_ABORT in the INI. Though I am not sure what would help here. Possibly an M2?

[Sigma1912]

The workaround from #2745 works here as well. Basically a change of the active work offset system (ie g5x) will set the DRO right. (Note that M2 should not be used inside a subroutine.) However, given that a default configuration does not come with an 'on_abort' subroutine call it seems that either the issue should be handled in the source code or an 'on_abort' routine should at least be included as a standard. In my oppinon his is a surprising bug even for reasonably experienced users.

[Edit] Testing shows that 'M2' does not fix this issue while WCS manipulation seems to put things right.

[Sigma1912]

Just to be clear, this happens whenever a program aborts, not just when it's caused by the magic comment (abort, ....)

[Sigma1912]

I wonder if this is connected to the confusion of resetting G52/G92 on M2/M30. 'Coordinate Systems' documentation states: https://linuxcnc.org/docs/html/gcode/coordinates.html `By default, G92 offsets are restored after the machine is started. Programmers that wish for Fanuc behavior, where G92 offsets are cleared at machine start and after a reset or program end, may disable G92 persistence by setting DISABLE_G92_PERSISTENCE = 1 in the [RS274NGC] section of the INI file.

also 'interp_convert.cc' comments:

while 'INI' documentation seems to have only ever mentioned ' config start up': linuxcnc.org/docs/2.8/html/config/ini-config.html

DISABLE_G92_PERSISTENCE = 0 Default 0 Allow to clear the G92 offset automatically when config start-up.

[Sigma1912]

In version 2.9 and master G52,G92 is not reset on M2,M30 regardless of DISABLE_G92_PERSISTENCE setting, that seems to only apply to 'config start-up'. I don't know if it was working in earlier versions.

[Sigma1912]

Further on in 'interp_convert.cc' we find:

And indeed if we run this:

g92.1
(debug, 5210: #5210; 5211: #5211)
g10 l2 p0 x0
g0 x0
g92 x123
(debug, 5210: #5210; 5211: #5211)
m2

and then in MDI: (debug, 5210: #5210; 5211: #5211)

we get this situation

Parameter values are zero but DRO shows G92 offset applied.
issuing G0 X0 shows that the G92 offset is indeed still set to the value shown in the DRO.

Note here that this happens without any abort situation but in a simple gcode that runs just fine.

[Sigma1912]

So if I follow this correctly then the 'G92' offset value in the DRO comes from the status channel ('glcanon.py'):

which seems to bring me back to the issue of the parameters being out of sync with the status channel (#2745).

So (while not good) this does not seem to be what causes the DRO to hide active G92 offsets.

However, if g92 is indeed not to be reset on M2/M30 we may want to remove this from 'interp_conver.cc':

[Sigma1912]

While I have not come up with a better solution I have found the internal 'on_abort' procedure:

The only idea that comes to my mind is to hard code the workaround in here but that seems rather crude.

[Sigma1912]

Further testing shows that after an abort the MDI command: ;py,import linuxcnc;s=linuxcnc.stat();s.poll();print(s.g92_offset) gives (0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0) So the .stat.g92 offsets values have been cleared, hence the DRO also shows zero, which is wrong.

while the parameters will show the offset (correctly): 5210: 1.000000; 5211: -100.000000

If we issue MDI command 'm2': the .stat.g92 offsets values remain unchanged (still wrong) but the parameter values are reset to zero (now also wrong, due to lines 4684-87 in 'interp_conver.cc' as shown above): 5210: 0.000000; 5211: 0.000000

If we manipulate WCS by (eg MDI command 'G59' the .stat.g92 offsets values come back (now correct) : (-100.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0)`

while the parameter values remain zero (still wrong): 5210: 0.000000; 5211: 0.000000

now we issue MDI g92.3 (should activate G92 with the stored values): .stat.g92 offsets values : (0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0) parameters: 5210: 1.000000; 5211: 0.000000 So g92.3 takes the value from parameter 5211 to restore the offset.

As a conclusion: There are at least three states for the g92 offset:

1. An internal state that is actually used for the motion
2. The .stat.g92 offsets values user for the DRO in the GUI
3. The parameter values 5211...5219 from which offset values are restored from

All of these seem to be updated independently and unfortunately also inconsistenly.

[Sigma1912]

I really wonder where the values on the status channel are written to in the source code.

;py,import linuxcnc;s=linuxcnc.stat();s.poll();print(s.g92_offset) gives me (which is the values before running the aborting gcode program): (-99.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0)

while at the same time I get these from a printout in 'interp_write.cc' line 216: settings->parameters[5211], settings->axis_offset_x -100.000000, -100.000000 which both show the correct x-offset value.

[Sigma1912]

I guess the basic problem is that the program aborts when the read-ahead ingests an abort condition, while execution is still somewhere behind. Because some information is updated by the read ahead and some is updated sometime later by motion there is always a discrepancy for a short time but on abort this can become a problem that needs to be handled in the 'on_abort' command as the information in the GUI can not be trusted to reflect the state of the controller.