"Bug" while calling subroutine with abort
- DEVILHUNTER
- Offline
- Junior Member
-
Less
More
- Posts: 29
- Thank you received: 8
17 Oct 2021 17:44 #223405
by DEVILHUNTER
"Bug" while calling subroutine with abort was created by DEVILHUNTER
I have been a LinuxCNC user for several years and always wanted to give something back. Today just solved a problem I had for a while and was driving me a little crazy, so I thought it was a great way to start.
I'm running my DIY mill with a production batch and I wanted to make it as unatended as possible, so I added a touch probe system to check if the tool was broken. Modified the post procesor so before each tool change, it calls an o-world subroutine that checks the tool.
I also added a DIY umbrella style ATC, but because a mechanical problem (that already solved), sometimes the spindle didn't grab the tool well. When that happened, the tool didn't fall but could rattle a lot, really scary with a high speed spindle. So decided to do the checking after each tool change and before starting the spindle. So also changed the subroutine to check if the tool was longer than expected.
So after that, I could not longer load the main program that calls the sobroutine, as it aborted automatically. Spend a while looking for the misspell and could not find any, plus the weirdest thing was that if I called the sub on MDI, it worked as expected. This is the problematic part of the code:
So when I tried to load my main program, it could not load and get an "error in line X" msg (the call line) plus a "broken tool" alarm. What I understand is happening is that, while loading the main program, LinuxCNC has to read the whole program and subroutines but without executing any machine movement. The problem is the touch movement to Z-0.5 made the "o101 if" conditional to be true although the machine has not moved at all, and the abort command was executed althougth it was just reading the program. So changed the order of the conditional, so the first one is not true like this:
And not it works. It's kinda weird because the "o101 elseif" statment should get true while reading the main program and abort again, but it's not happening. So I think this is a bug on the interpreter and can be solved in future versions.
I'm running my DIY mill with a production batch and I wanted to make it as unatended as possible, so I added a touch probe system to check if the tool was broken. Modified the post procesor so before each tool change, it calls an o-world subroutine that checks the tool.
I also added a DIY umbrella style ATC, but because a mechanical problem (that already solved), sometimes the spindle didn't grab the tool well. When that happened, the tool didn't fall but could rattle a lot, really scary with a high speed spindle. So decided to do the checking after each tool change and before starting the spindle. So also changed the subroutine to check if the tool was longer than expected.
So after that, I could not longer load the main program that calls the sobroutine, as it aborted automatically. Spend a while looking for the misspell and could not find any, plus the weirdest thing was that if I called the sub on MDI, it worked as expected. This is the problematic part of the code:
#<touch_distance> = 0.5
#<touch_tolerance> = 0.2
(Touching)
G38.2 Z-#<touch_distance> F#<touch_speed>
(Checking tool lenght)
o101 if [#<_z> LT -#<touch_tolerance>]
(abort, Broken tool #<_current_tool>)
o101 elseif [#<_z> GT #<touch_tolerance>]
(abort, Tool #<_current_tool> not clamped in spindle)
o101 endifSo when I tried to load my main program, it could not load and get an "error in line X" msg (the call line) plus a "broken tool" alarm. What I understand is happening is that, while loading the main program, LinuxCNC has to read the whole program and subroutines but without executing any machine movement. The problem is the touch movement to Z-0.5 made the "o101 if" conditional to be true although the machine has not moved at all, and the abort command was executed althougth it was just reading the program. So changed the order of the conditional, so the first one is not true like this:
(Checking tool lenght)
o101 if [#<_z> GT #<touch_tolerance>]
(abort, Tool #<_current_tool> not clamped in spindle)
o101 elseif [#<_z> LT -#<touch_tolerance>]
(abort, Broken tool #<_current_tool>)
o101 endifAnd not it works. It's kinda weird because the "o101 elseif" statment should get true while reading the main program and abort again, but it's not happening. So I think this is a bug on the interpreter and can be solved in future versions.
Please Log in or Create an account to join the conversation.
- andypugh
-
- Offline
- Moderator
-
Less
More
- Posts: 23310
- Thank you received: 4858
21 Oct 2021 22:04 #223841
by andypugh
Replied by andypugh on topic "Bug" while calling subroutine with abort
I am not sure if this is a true bug, as a way is provided to workaround what is actually a quirk of the graphical preview. (If I understand your description correctly).
The workaround is to use the system parameter
linuxcnc.org/docs/2.8/html/gcode/overview.html#gcode:parameters
"#<_task> - 1.0 if the executing interpreter instance is part of milltask, 0.0 otherwise. Sometimes it is necessary to treat this case specially to retain proper preview, for instance when testing the success of a probe (G38.n) by inspecting #5070, which will always fail in the preview interpreter (e.g. Axis)."
So you could try:
The workaround is to use the system parameter
linuxcnc.org/docs/2.8/html/gcode/overview.html#gcode:parameters
"#<_task> - 1.0 if the executing interpreter instance is part of milltask, 0.0 otherwise. Sometimes it is necessary to treat this case specially to retain proper preview, for instance when testing the success of a probe (G38.n) by inspecting #5070, which will always fail in the preview interpreter (e.g. Axis)."
So you could try:
(Checking tool length)
o101 if [#<_task> EQ 0]
(preview, do nothing)
o101 elseif [#<_z> GT #<touch_tolerance>]
(abort, Tool #<_current_tool> not clamped in spindle)
o101 elseif [#<_z> LT -#<touch_tolerance>]
(abort, Broken tool #<_current_tool>)
o101 endifPlease Log in or Create an account to join the conversation.
- DEVILHUNTER
- Offline
- Junior Member
-
Less
More
- Posts: 29
- Thank you received: 8
13 Nov 2021 09:34 #226289
by DEVILHUNTER
Replied by DEVILHUNTER on topic "Bug" while calling subroutine with abort
You are totally right, thanks Andy! Shomehow all the times I have read the parameters page I always missed about this point.
I have added a conditional with the parameter #5070 because if the tool was broken more than the touch distance the parameter #5063 was not written and the subroutine did not abort. Now It works flawlessly.
I have added a conditional with the parameter #5070 because if the tool was broken more than the touch distance the parameter #5063 was not written and the subroutine did not abort. Now It works flawlessly.
(Checking tool length)
o101 if [#<_task> EQ 0]
(preview, do nothing)
o101 elseif [#<_z> GT #<touch_tolerance>]
(abort, Tool #<_current_tool> not clamped in spindle)
o101 elseif [[#<_z> LT -#<touch_tolerance>] OR [#5070 LT 1]]
(abort, Broken tool #<_current_tool>)
o101 endifPlease Log in or Create an account to join the conversation.
Time to create page: 0.071 seconds