Run-from-line and v.2.7.3

While I admit that I don't fully understand the bug description, I believe mine does not match. It looks like the posted bug will skip some lines AFTER the line which is selected for run-from-line. What I have here is only a G38.2 that is in an external file subroutine that is called before the run-from-line.

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

This does not answer your question, as I said before we do not use run from line.
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

Yeah - Editing the job file is always an option. Easy enough to do, but I want to bring this up for a couple of reasons:

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

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

Well - Many things going over my head as usual, but from reading John Morris's post, it sounds like the previous G38.1 is causing the behavior. If this is true, why does this only happen when the G38.1 is in the external subroutine and not in the main file? If the probe's results are unknown, it would be unknown both in the main file and in the subroutine.

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........

I think Andy's idea is to see if the "phantom Z move" is the g38.2 probe line is being run again, rather than just a Z move.
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