[LinuxCNC/linuxcnc Issue#246] Run from line does not work with a remapped G-code toolchange routine

#1 – zultron 于 2018-09-20

This sounds similar to the problem reproduced by @SebKuzminsky’s test in a2694ea7, and (ostensibly) fixed in my 13538958: it’s a start-from-line bug in a configuration with remaps.

#2 – zultron 于 2018-09-20

I’m unable to reproduce this from the instructions given above using the latest 2.7 branch, commit 382e52ba. No specific start line was specified, but I doggedly tested each one and still couldn’t reproduce.

One issue I did have following the instructions, it took me a while to figure out whether the reported problem was even being reproduced or not because of the remap line number bug: the program source highlighting jumps all around as it tracks the line numbers of motions in configs/sim/axis/remap/rack-toolchange/ncsubroutines/tool*_move.ngc instead of staying on the line number of the M6 T. This makes it hard to see which source line is actually executing.

I worked around this by adding a bunch of blank space at the beginning of those files so the highlighting disappears, and by turning the G0 into G1 so those lines stay highlit (is that a word?) longer.

Of course the program is designed to make it clear from preview how much of the program is executed, so there should be no confusion there.

Can you confirm that you’re actually reproducing the problem as reported, the entire file executes when using “Run from here,” and that you’re not mistaking the line number jumping problem for early lines falsely appearing to execute?

#3 – KurtJacobson 于 2018-09-20

I just ran the example code on a fresh build of master. It does not run the whole file, but it does perform all the tool changes up to the line that the program was started at.

Full program:
!full-program

Started at line 11:
!start-line_11

#4 – KurtJacobson 于 2018-09-20

I agree with @zultron that it seems to work correctly on 2.7.14

!2 7 14 start-line 11

#5 – zultron 于 2018-09-20

Thanks, @KurtJacobson, I was able to reproduce in master (commit 02ba5a1f).

This is caused by an interaction between the programStartLine implementation, remap, and queue busters.

The programStartLine feature works by queuing up commands from interp as usual; then in task, if the start line hasn’t been reached, the interp queue is truncated. See the code [here][1]. It’s done this way because skipping directly to a line without running through interp would lose all the canon state leading up to that, like speeds and feeds and units and such.

In a subroutine, the interp queue isn’t truncated, because the current line is somewhere inside the subroutine definition, perhaps even in a different file, so comparing the current line with the start line is meaningless. Normally, this is ok, because the canon commands are queued up on the interp list and not issued before the subroutine returns control to the main program, and the interp list is truncated again.

However, the M6 remap yields a queue buster in ncfiles/remaplib/python-stdglue/stdglue.py, in the change_epilog() generator. This causes interp to return control to task, which then starts issuing commands off the queue. Since the queue hasn’t been truncated since the previous line in the main program, whatever has been queued up there is executed. Since the queue buster is in the tool change epilog, that means the entire tool change.

As @KurtJacobson pointed out, only the tool changes before the start line are executed, but the intervening G0 blocks are not. This is expected, since those blocks are in the main program, and are getting truncated as expected.

This must have broken after PR #221, which fixed the queue buster in the change_epilog() function, which had been broken as described in #217.

My first thoughts to fix this are:
– Use the top-level stack context for start line checks; then the interp list can be truncated even within a subroutine or remap
– Or, add an extra bit of state in task that records whether the start line has been reached, and use that to decide whether to truncate the interp list

In any case, the start line feature is an ugly, dirty, gross and disgusting hack, and we’re sure to see future problem even once this particular problem is fixed.

[1]: https://github.com/LinuxCNC/linuxcnc/blob/13538958/src/emc/task/emctaskmain.cc#L626-L643

#6 – Lcvette 于 2020-06-25

We are trying to get this resolved for the Probe Basic Gui, has anyone found a solution to this issue? this is a really great function on most control systems, anyhow just wanted to see if anything was resloved here, seems it went dormant. or maybe if there is a work around? any help greatly appreciated!!

#7 – mozmck 于 2020-06-25

I don’t know if this will do what you need, but I implemented a “simple run from line” feature which simply skips over all code to the line requested and starts execution. It is pretty well tested on 2.7 and has been rebased on 2.8 but not tested there. The commit is here if you want to try it out: https://github.com/mozmck/linuxcnc-mirror/commit/20640d4011a5f312842e0b5adf72d50ec82e77ce

#8 – mozmck 于 2020-06-25

It is at best a workaround, and restarting has to be done on a line which will set all needed state, but it is better than no working run-from-line at all which is what we have in many cases. The case which occasioned this workaround is a similar bug when there is a probe routine in an external file subroutine

#9 – andypugh 于 2020-06-25

Run from line is difficult, as it either needs to do things that are not even in the G-code or rely on the operator to set all state correctly.

I thought that the behaviour was the latter, and I have got into the habit of not even thinking about starting on any line other than a toolchange. I was fairly sure that RFL didn’t start the spindle, for example.

The system could keep track of all state info while dry-running the code, then do a tool-change, spindle start and G0 to where it would have been. (potentially diving straight through the part) before starting. Though I guess in most cases the correct tool would already be in place and the machine would be close to where it ought to be.

I feel nervous about what sounds like yet another shake-up of run-from line as it seems we have already had two unsatisfactory implementations.

However, LinuxCNC is now being used on a number of Plasma cutters, and those do often need to be restarted if they lose the arc.

I am almost starting to think that we might need an INI section to define what behaviour a particular machine should have when running-from-line.

Does state-tags help, I wonder?

#10 – andypugh 于 2020-06-25

“a line that will set all needed state” would need to include arc centre mode, incremental, radius/diameter, units…

Most of these will not be an issue, but I think that units and coordinate system are reset by M2, and would be all too easy to forget.

Is running through a bunch of unnecessary tool changes really such a bad thing? It does at least ensure that the tool changer state is consistent (I think)

#11 – mozmck 于 2020-06-25

@andypugh if you look at my commit I have an INI option to select the RFL function. I had intended to commit that in 2.8 but obviously did not get it done – partly because I have not had time to test it in 2.8. It was indeed created for problems in a plasma cutting machine. I do think the bugs in run-from-line need to be ironed out sometime though – or maybe implemented in a different manner that would be less of what @zultron terms “an ugly, dirty, gross and disgusting hack”?

#12 – andypugh 于 2021-07-06

Run-from-line is still broken in 2.8.2 and Master.
It cycles through all the tool changes up to the starting point.
And if the user has started the spindle before running-from-line this means that it will attempt tool-changes with the spindle running. (The VMC_toolchange Vismach config does this, at least, as the toolchange.ngc does not contain a spindle-stop command.)