Gcode preview and remap

Hello,
I'm using a Remap M6 Gcode routine to control my toolchanger, this routine has several if statements.
It works great the changer does what it should perfectly !

But if I start a programm in auto mode, with several toolchanges, the Gcode preview ( I mean the window that shows the next lines in Gcode) will stuck in the first toolchange routine. It does not return to the code when the routine is done, so it is impossible to see what line of code comes next, it just jumps through the remap Hcode sript line by line ...

Is there any way to hide this routines ?

I mean this remap scripts should not be shown in the preview, the interpreter will not follow the if statements at all, so it makes no sense anyway and of course the biggest problem is that it won't leave this script.

I'm using the latest version of gmoccapy.

Thank you all


Greets Rene

Hallo Rene,

Have you tested with gscreen and or axis?

Norbert

Exact same problem in tkemc. It appears to be a bug in the underlying LinuxCNC code and cannot be fixed by changing the tcl code. It appears as if there's code that's doing some significant lookahead, as the job tends to be stuck inside the M6 handling subroutine until after the last M6 in the g-code file.

Yes. It appears as if the program is stuck in the g-code subroutine handling M6, but i do not believe this problem occurs after the last M6 in a g-code file. So for g-code files with one M6 command it works as it should.

emc_program_line is returning the correct line number associated with the main program or current subroutine, however,

emc_program is incorrectly returning the name of the subroutine file instead of the main program (in most cases) after the subroutine handling the remapped M6 has returned.

Hallo,

a very dirty fix would be to add a test to /linuxcnc/lib/gladevcp/hal_sourceview.py at line 81, after the line

fn = self.filename

Then the gcode window will not be filled with the remaped code, if it is called change.ngc

The problem is caused IMHO, due to the reason, that the remap emits a file changed signal, but when it ends, there is not emmited the signal again from the running main program.

It would be possible to exclude also any program, beginning with "remap_", so it would be possible to exclude all remap stuff.

What do the reals developers think about excluding files to be displayed?
I tested that with gmoccapy_tool_sensor.ini


On the other way, the test for remaped code could be done in hal-glib / GStat. Does someone know if a remaped state signal is set during remap?



Norbert

a very dirty fix would be to add a test to /linuxcnc/lib/gladevcp/hal_sourceview.py at line 81

This might work for one GUI in some configurations, but would be better if it worked for all GUIs and could ignore the line number otherwise it just shows the wrong g-code line in the main program while you prevent it from loading the subroutine file. Unfortunately, there's no easy way to work around this bug and make it behave the way it should.

This isn't the behaviour I am seeing in the VM where I am testing a remapped T-word

I think this is likely due to the fact that you've remapped T instead of M6. I think there's additional problems caused when the M6 subroutine calls M6 (special code prevents recursion by ignoring the mapping when M6 is called inside the M6-mapped subroutine.) To be certain, before i included M6 in the tool-change subroutine i had far fewer problems.