Gcode preview and remap

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.

orangecat wrote: 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.

This isn't the behaviour I am seeing in the VM where I am testing a remapped T-word
(lathe-style tool changing)

The first tool-change is highlighting the wrong line in the program, but the second and third don't even make that error.
None of the tool changes alter the displayed G-code file.

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.

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

My T-remap calls both M6 and T.

What version are you running? I guess it must be 2.6 or Master to even _have_ remapping.

Hallo,

as far as I found, the problem is the signal "file-loaded", emitted from GStat. It is emitted, at the time the remapped subroutine is loaded, but not emitted again when the subroutine ends and the work on the main program goes on. If that signal would be emitted, all would be fine.

Unfortunately my C++ knowledge is so week, that I do not understand the behavior. I tried to understand beginning with:

[linuxcnc.git] / src / emc / rs274ngc / interp_remap.cc

There is a part

bool Interp::remap_in_progress(const char *code)

with may help, but as far as I see, it is not exported to the python bindings.

[linuxcnc.git] / src / emc / rs274ngc / pyinterp1.cc

If that would be exported, we could check in GStat for remaped in progress and avoid emitting the file-loaded signal.
That should work on all GUI.

The best solution would be that the file-loaded signal is emitted also at the time the interpreter returns to the main program, as that would result in showing the work on the subroutine and also the ongoing steps of the main program. But where to implement that?

May be someone can help.

Norbert