Gcode preview and remap

More
25 May 2014 16:11 #47302 by REEEN
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

Please Log in or Create an account to join the conversation.

More
27 May 2014 17:35 #47389 by andypugh
Replied by andypugh on topic Gcode preview and remap
This might actually be specific to Gmoccapy. It might be worth asking in the GUI section.

Please Log in or Create an account to join the conversation.

More
28 May 2014 04:14 #47420 by newbynobi
Replied by newbynobi on topic Gcode preview and remap
Hallo Rene,

Have you tested with gscreen and or axis?

Norbert

Please Log in or Create an account to join the conversation.

More
26 Jul 2014 15:23 #49163 by orangecat
Replied by orangecat on topic Gcode preview and remap
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.

Please Log in or Create an account to join the conversation.

More
26 Jul 2014 17:47 #49167 by andypugh
Replied by andypugh on topic Gcode preview and remap

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


Oddly I have the opposite problem. I make lots of things using pre-defined macros, but the Axis G-code display doesn't know this, and as my code runs through the macros is actually highlights the corresponding line in the "LinuxCNC" splash G-code.

Are you saying that with a remapped M6 the G-code listing changes to show the remapped G-code, then doesn't return to showing the main G-code listing?

Please Log in or Create an account to join the conversation.

More
27 Jul 2014 01:53 #49176 by orangecat
Replied by orangecat on topic Gcode preview and remap
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.

Please Log in or Create an account to join the conversation.

More
28 Jul 2014 01:06 - 28 Jul 2014 03:41 #49191 by newbynobi
Replied by newbynobi on topic 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
if fn.split(os.sep)[-1] == "change.ngc":
    return

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
Last edit: 28 Jul 2014 03:41 by newbynobi.

Please Log in or Create an account to join the conversation.

More
28 Jul 2014 03:48 - 28 Jul 2014 06:01 #49195 by orangecat
Replied by orangecat on topic Gcode preview and remap

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.
Last edit: 28 Jul 2014 06:01 by orangecat.

Please Log in or Create an account to join the conversation.

More
28 Jul 2014 04:14 #49196 by andypugh
Replied by andypugh on topic Gcode preview and remap

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

Please Log in or Create an account to join the conversation.

More
28 Jul 2014 05:35 #49199 by orangecat
Replied by orangecat on topic Gcode preview and remap

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.

Please Log in or Create an account to join the conversation.

Time to create page: 0.078 seconds
Powered by Kunena Forum