When a gcode subroutine is executing after being called by a "O<...> call" statement, the "file" variable of "LinuxCNC Status" window is not updated properly: the filename for the subroutine appears for short time in this variable, then the variable come back to the calling gcode filename, before end of subroutine execution. This prevents proper display of current G-Code statements in gscreen or gmoccapy.
The issue can be easily seen by observing content of "LinuxCNC Status" window when a long subroutine is executing. I have discovered this issue by trying to mix Gscreen with remap M6, but the problem is not linked to remap. ( see http://www.linuxcnc.org/index.php/english/forum/41-guis/26819-gscreen--remap-m6-issue ). It that case the issue is really annoying because the displayed G-Code file in Gremlin and Gscreen is not the one really in execution phase => no more proper display of toolpath. Looks like there is some king of "dephasing" problem between the reported filename in "file" variable on the one really in execution state. I see also strange behaviour for "current_line" variables. The line really in execution is properly given by "motion_line", but not in "current_line". I run 2.6.0-pre0-4621 Frederic ------------------------------------------------------------------------------ Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
