-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Program abort hides active G52/G92 from DRO #2908
Comments
(abort, xxxxx) should probably always have an ON_ABORT in the INI. Though I am not sure what would help here. Possibly an M2? |
The workaround from #2745 works here as well. Basically a change of the active work offset system (ie g5x) will set the DRO right. [Edit] |
Just to be clear, this happens whenever a program aborts, not just when it's caused by the magic comment (abort, ....) |
I wonder if this is connected to the confusion of resetting G52/G92 on M2/M30. also 'interp_convert.cc' comments: while 'INI' documentation seems to have only ever mentioned ' config start up':
|
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'. |
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': |
Further testing shows that after an abort the MDI command: while the parameters will show the offset (correctly): If we issue MDI command 'm2': If we manipulate WCS by (eg MDI command 'G59' the .stat.g92 offsets values come back (now correct) : while the parameter values remain zero (still wrong): now we issue MDI g92.3 (should activate G92 with the stored values): As a conclusion:
All of these seem to be updated independently and unfortunately also inconsistenly. |
I really wonder where the values on the status channel are written to in the source code.
while at the same time I get these from a printout in 'interp_write.cc' line 216: |
I guess the basic problem is that the program aborts when the read-ahead ingests an abort condition, while execution is still somewhere behind. |
Using a current RIP installation of 2.9.2:
Note: the DRO shows 'X: 0, Y: 0, Z: 0' and no active G92 offset
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:
only that the tool will move to 'X:100' after the 'G0 X0' command.
This seems related to this issue:
#2745
The text was updated successfully, but these errors were encountered: