Probe Basic subroutine parameter - #5210?
09 Sep 2024 02:21 #309702
by spumco
Probe Basic subroutine parameter - #5210? was created by spumco
Updated PB and need to re-do all the numbered parameters in my customized tool change subroutines.
While digesting the subroutines, I found that parameter #5210 is used twice:
unload_spindle.ngc
M61 Q0
G49
#5210 = 0
#3991 = 0
M13
M61 Q#3991 G43 H#3991 #5210 = 0
According to the LCNC docs, #5210 appears to be written by LCNC if G52 or G92 offset is applied. I'm guessing this is not normally a user-writable parameter.
Is this an error, or am I misunderstanding something?
While digesting the subroutines, I found that parameter #5210 is used twice:
unload_spindle.ngc
M61 Q0
G49
#5210 = 0
#3991 = 0
M13
M61 Q#3991 G43 H#3991 #5210 = 0
According to the LCNC docs, #5210 appears to be written by LCNC if G52 or G92 offset is applied. I'm guessing this is not normally a user-writable parameter.
Is this an error, or am I misunderstanding something?
Please Log in or Create an account to join the conversation.
09 Sep 2024 05:56 #309710
by Aciera
Replied by Aciera on topic Probe Basic subroutine parameter - #5210?
I'm not familiar with PB but this does seem a problematic way of doing things.
One problem with writing #5210 directly like that is that the python status channel gets out of sync with the actual state because this does not set the values of the 'g92_offset' attribute (which is supposed to reflect the currently active g92/g52 offset values) to zero.
While this may not a problem for the GUI it might well upset a custom python component.
One problem with writing #5210 directly like that is that the python status channel gets out of sync with the actual state because this does not set the values of the 'g92_offset' attribute (which is supposed to reflect the currently active g92/g52 offset values) to zero.
While this may not a problem for the GUI it might well upset a custom python component.
The following user(s) said Thank You: spumco
Please Log in or Create an account to join the conversation.
09 Sep 2024 06:07 #309711
by Aciera
Replied by Aciera on topic Probe Basic subroutine parameter - #5210?
Also note that this seems to be used in the GUI:
./src/probe_basic/probe_basic.ui:7592: <string>M61 Q0 G49 #5210 = 0 #3991 = 0</string>
./src/probe_basic/probe_basic.ui:9605: <string>M61 Q0 G49 #5210 = 0 #3991 = 0</string>
Please Log in or Create an account to join the conversation.
09 Sep 2024 15:03 - 09 Sep 2024 15:15 #309754
by spumco
Replied by spumco on topic Probe Basic subroutine parameter - #5210?
Looks like I asked this question a couple years ago. Memory failing.
forum.linuxcnc.org/qtpyvcp/46414-probe-b...eter-question#247625
If #5210 is intended (in LCNC) to be a 'flag' which indicates a G52/92 offset is applied, then writing to #5210 directly seems to be the wrong way to clear offsets. And may, in fact, not clear out any offsets.
If the PB toolchange intention is to disable G52 or G92 offsets, G92.2 (or 92.1) could be called in the subroutine and a check for #5210 = 0 could be made to ensure the offsets are cleared.
Or a comparison made: if #5210 = 1, then G92.2 (or something like that).
I'll have to test this out and see if manually zeroing #5210 changes applied G52/92 offsets.
forum.linuxcnc.org/qtpyvcp/46414-probe-b...eter-question#247625
If #5210 is intended (in LCNC) to be a 'flag' which indicates a G52/92 offset is applied, then writing to #5210 directly seems to be the wrong way to clear offsets. And may, in fact, not clear out any offsets.
If the PB toolchange intention is to disable G52 or G92 offsets, G92.2 (or 92.1) could be called in the subroutine and a check for #5210 = 0 could be made to ensure the offsets are cleared.
Or a comparison made: if #5210 = 1, then G92.2 (or something like that).
I'll have to test this out and see if manually zeroing #5210 changes applied G52/92 offsets.
Last edit: 09 Sep 2024 15:15 by spumco.
Please Log in or Create an account to join the conversation.
09 Sep 2024 16:06 #309755
by Aciera
The problem with things like this is that it may work fine for 99% of the configs but cause inexplicable behavior for the other 1%. The simple fact that this gets the python status channel out of sync would be enough for me to reject this solution. It seems strange that '#5210 = 0' was chosen rather than 'G92.2' particularly since these are used in MDI commands and ngc routines.
Replied by Aciera on topic Probe Basic subroutine parameter - #5210?
I'll have to test this out and see if manually zeroing #5210 changes applied G52/92 offsets.
The problem with things like this is that it may work fine for 99% of the configs but cause inexplicable behavior for the other 1%. The simple fact that this gets the python status channel out of sync would be enough for me to reject this solution. It seems strange that '#5210 = 0' was chosen rather than 'G92.2' particularly since these are used in MDI commands and ngc routines.
Please Log in or Create an account to join the conversation.
09 Sep 2024 16:16 #309756
by spumco
Replied by spumco on topic Probe Basic subroutine parameter - #5210?
If one interprets the explanation of #5210's function as being "disable G52 & G92 offsets", then it's perfectly appropriate to use it they way they did.
Assuming we're right about the fact that it's a flag (not a switch), my suspicion is that the ATC subroutine author(s) simply misinterpreted the purpose of #5210.
Assuming we're right about the fact that it's a flag (not a switch), my suspicion is that the ATC subroutine author(s) simply misinterpreted the purpose of #5210.
Please Log in or Create an account to join the conversation.
09 Sep 2024 16:27 - 09 Sep 2024 16:58 #309757
by Aciera
I certainly hope there is no such wording in any of the documentation.
[edit]
As an illustration here is what 'G92.2' does (setting #5210 happens in this line 'pars[5210] = 0.0;'):
Replied by Aciera on topic Probe Basic subroutine parameter - #5210?
If one interprets the explanation of #5210's function as being "disable G52 & G92 offsets", then it's perfectly appropriate to use it they way they did.
I certainly hope there is no such wording in any of the documentation.
[edit]
As an illustration here is what 'G92.2' does (setting #5210 happens in this line 'pars[5210] = 0.0;'):
Attachments:
Last edit: 09 Sep 2024 16:58 by Aciera.
The following user(s) said Thank You: spumco
Please Log in or Create an account to join the conversation.
09 Sep 2024 18:21 #309767
by spumco
I think it's not painfully obvious - at least to me. The G-code Overview section:
I think it's possible to misinterpret that statement.
Not until you dig deeper in other sections of the manual is the behavior a bit more clear. From G-code/Coordinates/G92 Persistence Caution (5.3):
I think the solution is to remove the #5210 parameter, and add G92.2 to the very beginning of the toolchange sequence, and G92.3 to the very end. That way any offsets used in a program are restored and not just erased after a tool change.
Replied by spumco on topic Probe Basic subroutine parameter - #5210?
I certainly hope there is no such wording in any of the documentation.
I think it's not painfully obvious - at least to me. The G-code Overview section:
[i]5210[/i] - 1 if "G52" or "G92" offset is currently applied, 0 otherwise.I think it's possible to misinterpret that statement.
Not until you dig deeper in other sections of the manual is the behavior a bit more clear. From G-code/Coordinates/G92 Persistence Caution (5.3):
...where 5210 is the [i]G92[/i] enable flag (1 for enabled, 0 for disabled)...I think the solution is to remove the #5210 parameter, and add G92.2 to the very beginning of the toolchange sequence, and G92.3 to the very end. That way any offsets used in a program are restored and not just erased after a tool change.
Please Log in or Create an account to join the conversation.
09 Sep 2024 18:57 - 09 Sep 2024 19:09 #309773
by Aciera
Replied by Aciera on topic Probe Basic subroutine parameter - #5210?
To be absolutely honest I don't really understand why they are setting #5210 = 0 in the first place.
What does unloading the spindle have to do with g92/g52?
Also here:
M61 Q#3991 G43 H#3991 #5210 = 0
Why the need to set #5210 = 0?
[edit]
The more I look at it the more this looks like a mistake to me. It just simply does not seem to make any sense at all.
What does unloading the spindle have to do with g92/g52?
Also here:
M61 Q#3991 G43 H#3991 #5210 = 0
Why the need to set #5210 = 0?
[edit]
The more I look at it the more this looks like a mistake to me. It just simply does not seem to make any sense at all.
Last edit: 09 Sep 2024 19:09 by Aciera.
Please Log in or Create an account to join the conversation.
09 Sep 2024 19:24 #309779
by spumco
Replied by spumco on topic Probe Basic subroutine parameter - #5210?
BTW, the "M61..." is from one of the GUI screen buttons (UNLOAD SPINDLE BUTTON)
Looking back at the old thread I linked, it's pretty clear I - and the PB Dev who was responding - thought #5210 was for setting/clearing G52/92 offsets.
I don't know why the author would want to clear the offsets during a spindle unload. The original subroutines had a bunch of numbered parameters added by the authors - this may have been a mistake and they overlooked the fact that #5210 was already in use.
And yes, I, too, am convinced this is a mistake. I'll raise an issue on PB-GH tonight.
Thanks for kicking this around with me.
Looking back at the old thread I linked, it's pretty clear I - and the PB Dev who was responding - thought #5210 was for setting/clearing G52/92 offsets.
I don't know why the author would want to clear the offsets during a spindle unload. The original subroutines had a bunch of numbered parameters added by the authors - this may have been a mistake and they overlooked the fact that #5210 was already in use.
And yes, I, too, am convinced this is a mistake. I'll raise an issue on PB-GH tonight.
Thanks for kicking this around with me.
Please Log in or Create an account to join the conversation.
Time to create page: 0.099 seconds