program line counter with subroutine files

grandixximo commented 2 years ago

Here are the steps I follow to reproduce the issue:

1.Extract attached nc_files.zip to [DISPLAY] PROGRAM_PREFIX 2.run test.ngc 3.observe program line counter

This is what I expected to happen:

Program line counter should either stay on subroutine call, or the subroutine should be loaded in the UI and counted.

This is what happened instead:

Counter is counting program lines on the wrong file, it's not really executing the line displayed in UI code preview.

It worked properly before this:

Never

Information about my hardware and software:

I am using this Linux distribution and version (often, shown by lsb_release -a): Debian 10 Buster
I am using this kernel version (shown by uname -a): 4.19.0-20-amd64
I am running ...
- [x] A binary version from linuxcnc.org (including buildbot.linuxcnc.org)
- [ ] A binary I built myself
- [ ] A binary version from some other source besides linuxcnc.org
I am using this LinuxCNC version (shown in package manager or, for git versions, scripts/get-version-from-git):2.9.0-pre0-6210-g28d82b0a7
I am using this user interface (GUI) (e.g., AXIS, Touchy, gmoccapy, etc):tested on AXIS gmoccapy and Touchy
I am using this interface hardware vendor and chipset (e.g., parallel port, ethernet port, FPGA card): sim

More of a feature request than a bug. Would be interested in knowing how hard such a change would be. I had a quick look at the code, and from what I can understand (which is not much) seems quite complicated to get proper behavior.

hansu commented 2 years ago

Can you provide your test file test.ngc ?

grandixximo commented 2 years ago

nc_files.zip

hansu commented 2 years ago

Okay, the interpreter sends out the 'line-changed'-signal with the line corresponding to the current file, in case of the external subroutine it points to that file but still displays the initial file. I bit weird that this has not bothered anyone before.

So two possibilities here:

Don't emit a 'line-changed' signals when in a subroutine. But as we don't know (I think so) if the subroutine is in an external file or not, it will never display the line of a subroutine --> not really good.
Emit the 'file-loaded' signal also when calling a subroutine from an external file

@robEllenberg @snowgoer540 may want to leave comment here?

andypugh commented 2 years ago

It's bothered lots of people, but nobody has ever got round to fixing it. :-)

To an extent it really doesn't matter.

But it would be more elegant to just sit on the subroutine call line, or the remapped G-code, whilst executing the other file. I don't think loading the subroutine file into the preview window is worth the bother.

Part of the issue with fixing this is that it would need a separate fix for each GUI, I think.

hansu commented 2 years ago

It's bothered lots of people, but nobody has ever got round to fixing it. :-)

It seems like a big obstacle to work on these signals...

But it would be more elegant to just sit on the subroutine call line, or the remapped G-code, whilst executing the other file.

If the subroutine is inside an external file, yes maybe. But if it's in the same file, it would be weird to not jump to the line.

Part of the issue with fixing this is that it would need a separate fix for each GUI, I think.

Yes probably. But ideally not as they are already reacting on this signal.

c-morley commented 2 years ago

This is a know and somewhat worked around problem. maybe not the line number but the subroutine/remap file being loaded. qtvcp/gladevcp based screens use hal_glib library for most status info. In hal_glib there is a line like this:

        # Only update file if call level is 0, which
        # means we are not executing a subroutine/remap
        # This avoids emitting signals for bogus file names below
        if self.stat.call_level == 0:
            self.old['file']  = self.stat.file

I suppose we could add something similar for line number.

A proper fix would take some thinking for sure.

cakeslob commented 2 years ago

But it would be more elegant to just sit on the subroutine call line, or the remapped G-code, whilst executing the other file.

I find it problematic using axis with a remapped M6, and wish it did this.

hansu commented 2 years ago

So desired behaviour would be

for remapped commands: stay on this line
for subroutines either stay on this line or jump to the sub when in the same file

Also the issue that the line number is only updated on motion commands is also related to this.

I think we can't postpone this all the time. I would volunteer digging into this but I would need some help. Who can support me? At least point me to where the interpreter starts and so on.

jallwine commented 2 years ago

Not sure how relevant this is any more, but it seems to lay out how complex the issue is: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?LineNumbers

hansu commented 2 years ago

This explains it a bit why that is postponed all the time :smile: Thanks.

LinuxCNC / linuxcnc