g-code windows not showing currently executing line / file

[rmu75]

Here are the steps I follow to reproduce the issue:

1. open g-code file that runs a macro defined in a different file
2. single step into macro
3. observe that line number changes and currently executing line marker is jumping around, but file stays the same (tested in gmoccapy, axis, probe_basic and qtdragon).

This is what I expected to happen:

When entering the macro file, change display to file that contains macro definition

Information about my hardware and software:

• linuxcnc 2.8, 2.9, current master, probably earlier versions

I investigated a bit. This is not (only) a problem of the GUIs. EMC_TASK_STAT contains fields for the filename, currently "executing" line (currentLine), the line that corresponds to the current move (motionLine) and the line up to which the interpreter read the current file.

Because of look ahead in the interpreter, there can be significant differences between currentLine and motionLine and the filename is possibly not current.

Regarding the filename, https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/nml_intf/emc_nml.hh#L1199C24-L1199C24 isn't very clear. I propose to define currentLine and file to be the line/filename where currently moving motion segment was created, therefore treat currentLine and filename just like active G/M-codes. Then it would be possible for the GUIs to display the proper file.

[andypugh]

It's always been like this, since subroutines were first added.

motion.program-line should indicate the currently executing program line, as this is added to each command in the motion queue. (This is also why only motion lines show up in the highlight too, as most modal codes do not result in an item being pushed to the queue, but rather modify the next item).

However, as you have noted, nothing seems to know what the currently-executing program is.

It is probably simpler to just not update the highlight when the system knows that a subroutine or remap is operating. If it can know...

[rmu75]

State tag not only includes the line number but also the file name, so the information is available -- it is just a matter of making the information available.

The changes to enable a more sensible behaviour are not that intrusive, I'm currently preparing a PR. With those changes a newer version of my DRO app can display G-Code preview and it is nicely following macros.

[rmu75]

Seems I was getting ahead of myself, state tag doesn't include the filename, but can be made to include it.

[andypugh]

Does the state-tag include info on whether the system is in main, sub or remap? I am not sure that changing the displayed G-code file is necessary. I think that people would expect to see the file that they loaded displayed, but with the highlight on the subroutine call or remapped code.

[rmu75]

The state tag does include a flag GM_FLAG_EXTERNAL_FILE. It is not really useable as is to highlight the line containing the macro because currentLine is set to whatever linenumber the interpreter is at, which in this case is neither the line of executing motion nor the line of the macro call.

I don't know what other people would expect, but I would find it very nice if it was possible to see what exactly a probe routine or remapped tool changing really is doing while single stepping through it. GUI screens don't have to implement it though.

[c-morley]

https://github.com/LinuxCNC/linuxcnc/blob/master/lib/python/hal_glib.py#L283

I think call level can give a clue

[rmu75]

https://github.com/LinuxCNC/linuxcnc/blob/master/lib/python/hal_glib.py#L283

I think call level can give a clue

I think call level is just the depth of the call stack. That would also "skip" macros that are defined in the main file.

[andypugh]

Is it possible to change the displayed G-code file without re-running the preview? Re-running preview mid-run could get messy.

[rmu75]

It is "just" a matter of the GUI to open/display multiple text files (and probably cache visited files in memory as long as the program is running). I don't see why and how the preview would depend on the g-code display.

Axis is using a Tk text widget. Don't know what would be best, you could keep multiple widgets around and swap them out, or swap/replace the text (which could be slow with very large files, but those probably don't contain macros).

Don't know about the other GUIs, I think the Qt GUIs are using qscintilla.