Frederic,

Am 29.07.2013 um 23:28 schrieb Frederic RIBLE <[email protected]>:

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

The issue you describe is a restriction of the current interpreter and 
execution system, and independent of the version.

See here:

- for a description which causes this behavior: Readahead of the interpreter: 
http://www.linuxcnc.org/docs/devel/html/remap/structure.html#_task_and_interpreter_interaction_queueing_and_read_ahead
- for an outline of a possible solution to the problem: 
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?SourceContext

I have in the past removed a gross hack which made the motion line number 
completely meaningless with respect to source location in MDI in the past - see 
the repo history for 'motion id zero' which is only a first step towards at a 
solution

so:

- is it an ugly deficiency which warrants repair? surely yes
- is it important/can it be done: yes
- how can you get there: you need to find a developer who is willing to work on 
a fundamental structural deficiency for an extended period of time, involving 
several components, and see it through
- would that be me: no, my plate is full with other stuff

Please file it as an enhancement request in the tracker so it is not lost

- Michael






> 
> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/emc-developers


------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers

Reply via email to