Run-from-line and v.2.7.3

I am wondering what was fixed with the run-from-line in LinuxCNC v.2.7.3?

I normally don't like to use run-from-line, but there are times where I need to use it. I used to get interesting results, I assume, while using G64 as I think LinuxCNC used G64 P0 settings if using the run-from-line feature. I had not noticed any widely used path deviations for some time, though.

I just got around to upgrading to v.2.7.3 and almost right away I needed to use the run-from-line feature and noticed something else unusual: The first un-programmed move I get is a negative Z axis dive into the material and then a coordinated axis move to the first programmed location in my gcode file (which drags the torch along the material for a bit). All is well after that as far as I can tell.

Can I eliminate or disable this initial action without downgrading versions?

Thank you...

Paul

Paul wrote: The first un-programmed move I get is a negative Z axis dive into the material and then a coordinated axis move to the first programmed location in my gcode file (which drags the torch along the material for a bit).

Do you also see this in a simulated configuration?

I am wondering if this unprogrammed move is actually something to do with a THC control and the entry-conditions not being correct.

I cannot duplicate this action in any simulated configuration that I have tried. I thought it might have to do with my touch off routine - at least the probing portion - but simulated config can access the routine, but doesn't use it when running from a line (unless the first line is the touch-off routine).

THC is available, but disabled.

So, it seems to be something specific to your setup and run-from-line, rather than a general run-from-line thing.

Is there anything clever active in the HAL file? Some offset component linked to the (disabled) THC?

It could be something specific to my setup - I am using the thcud component. I do know that I did not change anything since 2.7.0 (at least) and my setup worked before upgrading recently to the latest 2.7.3.

It appears to be probing tonight, but not sure what pin it is expecting as it trips through my touch-off probe pin, so now it stops motion on it's way down and then errors:

"Probe is already tripped when starting G38.2 or G38.3 move"

My probe switch is tripped at this time. The line I started on was a G00 X/Y move to the next pierce.

Paul

It would help if you posted your hal file, a short g code that shows the problem as well as your probe routine/sub.


Rick G

OK - More testing done. What I am finding is that LinuxCNC now looks in the touchoff subroutine and performs only the G38.2 even though 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). If I remove the G38.2 from the sub, nothing else in the sub seems to matter when running from line.

Sample test GCode fle:
Touch-off routine:
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.

I did remove preample and other info wanting to remove anything that may interfere with this test. Again - I haven't changed my setup, so I still wonder what has changed in v.2.7.3, but I can imagine that I can't understand the answer, too.

Thanks for any insight...

Yes, I have found that run-from-line does not work properly if you call subroutines (at least if there are also G38.2 moves as well). The only workaround I found was to not use subroutines.

What version of linuxcnc did this work on? Were you using subroutines there as well?

I am not 100% sure of the version previously, but believe it was 2.7.0. I don't update it very often and think it was September. And, yes, I used subroutines with the last version I had. I did not notice any issues then.

There may be more to it. After I placed the contents of my subroutine directly in the main file, I had another unusual reaction that I need to look at closer, but after I removed just the G38.2 from the main file, the run from line seem to raise the Z axis up suspiciously close to the touch-off switch offset of 9.9mm from the Z's current location even if Z was not at 0 or less than 0. The run-from-line did not raise the Z while the call the the sub was in place and the G38.2 probe only was removed from the sub routine.

Like I mentioned, I need to test that out more, too.

I did pull a backup in order to finish a job. It was v.2.7.0 which works fine. I never ran a version in between. I would rather not convert all current jobs to not use a subroutine.