Run-from-line and v.2.7.3
git.linuxcnc.org/gitweb?p=linuxcnc.git;a...ba9a44fe3f2836861262
This is meant to _fix_ a bug. Perhaps you were getting lucky with the bug working in your favour?
Please Log in or Create an account to join the conversation.
There are times I get by because I have flat, uncut material under the torch. The torch drags a little while moving to the next pierce. There are times that the torch goes for this un-intended probe in a void of material, so that resulting drag would hit the edge of material and move it out of place. Basically ruining the job.
I will re-read the bug description a few more times to see what sinks in. If it is the same thing, I respectfully request the bug to be unfixed
![:) :)](/media/kunena/emoticons/smile.png)
Please Log in or Create an account to join the conversation.
What we normally do in the event that a plasma job does not compete successfully is stop the program and edit or comment out the cuts, probes and moves that have been competed successfully. We leave the preamble and save the new file. Then load and run the edited file.
I keep a piece of scrap handy to put under the torch/probe in case it probes or lights where there is no material.
Rick G
Please Log in or Create an account to join the conversation.
I assume these resulting new operations are not a competing fix - meaning that in order to fix one thing, these actions are necessary.
The other thing, probably more important, I wonder if there are other unintended actions that are a by-product of this that have yet to be detected.
Paul
Please Log in or Create an account to join the conversation.
OK - More testing done. What I am finding is that LinuxCNC now looks in the touchoff subroutine and performs only the G38.2 even thought the call to the sub is earlier in the gcode file. If I replace the call to the sub with the contents of the sub, run-from-line works as I expect (it doesn't perform the G38.2). .
Do you have any remaps in your INI file?
Just to be sure that the system is erroneously calling a sub you could try adding some (debug, about to probe) / (debug, probe result #5399) to the subroutine.
(I guessed 5399, use the right number).
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
Just to be sure that the system is erroneously calling a sub you could try adding some (debug, about to probe) / (debug, probe result #5399) to the subroutine.
I think Andy has a great idea there.
After successful probing, parameters 5061 to 5069 will be set to the coordinates of X, Y, Z, A, B, C, U, V, W of the location of the controlled point at the time the probe changed state. After unsuccessful probing, they are set to the coordinates of the programmed point. Parameter 5070 is set to 1 if the probe succeeded and 0 if the probe failed. If the probing operation failed, G38.2 and G38.4 will signal an error by posting an message on screen if the selected GUI supports that. And by halting program execution.
Rick G
Please Log in or Create an account to join the conversation.
I need to add debugging to check probe status, but I'm not sure how the answer affects the issue. What happens in almost all cases where I need to restart via run-from-line, is that I loose the plasma torch arc, so an and2 condition stops motion. In many cases, the cut is tight and at the end of that section any ways. All I need to do is find the next rapid move after this section and restart from there. As it worked before, the controller would rapid to the next section to cut and continue on. So the probe status doesn't seem important. It will be called as programmed before that next pierce.
Also - I know I could take better notes, but this last job where I ran into this was the second time to cut this part. I should have fixed the area that looses arc, and I have had other jobs where this has happened which uses the same gcode file "template" meaning that all probing is accomplished throughout the job via my touchoff subroutine. I could always run-from-line without this phantom probing with 2.7.0 and earlier. They have all had to have followed at least one touchoff routine.
I don't see any remaps in my ini (file now attached).
Again - Maybe I am missing something from your perspective. The request to unfix should have been read more as a joke. Well, maybe........
![;) ;)](/media/kunena/emoticons/wink.png)
Please Log in or Create an account to join the conversation.
The rest of your sub does not seem to run as the the Z does not lift after the probe.
Perhaps...
G38.2 Z-100 F3001.0 (debug, probe result #5061)
Are you using M53 for feed stop control?
In the mean time what happens if you position the machine with a mdi move to the coordinates of the next line to run?
If I run-from-line at "G01 X250.000 F2000.000", it will -Z until the probe switch is engaged and hold that Z position while moving X to 250.000.
So before run-from-line "G01 X250.000 F2000.000" position the machine at X250.000 .
Rick G
Please Log in or Create an account to join the conversation.
If you precede the call to the probe routine with a / then it won't be called if block-skip is on.
So, a troublesome workaround might be.
block skip on
run from line
block-skip off.
Please Log in or Create an account to join the conversation.