Run-from-line and v.2.7.3

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

Paul wrote: 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).

Some discussion here:

sourceforge.net/p/emc/mailman/message/34839325/

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