out of sync gcode lister / missing status update?

Hi,

I did some more tests around the out-of-sync gcode line numbers ...

First I have to say, that my app advances the gcode in sync with axis, so ...
After getting into hal, I linked motion.program-line to an input pin of my module and thought: may be, some pin changes got lost in status feedback ...
... but everything was in sync.

After stripping down the logs to relevant output and comparing them with the processed gcode file, I finally understood, that only motion command create a new feedback line-number in status and motion pin ...

Well, good to know, that motion tells the right line-number.

But - in my opinion M-words, Spindle or feed changes as well as tool change commands are prominent enuf to create a line-number-update in status and for so advance in gcode-lister of UI.

May be, its already there and I only need to change a configuration switch?

If not, where do I have to look at, to achieve line-number feedback on non-motion codes?

It's surely a part of the larger problem of some status being out of sync with current realities. It's a known problem.
A old branch called state-tags was started to address the sync problem - I bet it also improves the line call out problem.

Chris

Hi Chris,

you already mentioned that branch. When you mentioned it for the first time, I gave it a quick scratch - but I did not discover anything aparently different. May be I don't know enuf to know what to look for ...
So if you can shine me a light, I would appreciate it a lot.

I digged a bit deeper for the line number handling. In status there are 3 line numbers: read_line, motion_line and current_line. I logged all three during gcode execution and to me read_line and current_line look completely unsusable. Only motion_line is of some value.

Then in control.c I found this code fragment:and another fragment like this:Program_line is the feedback-line in Hal-world and corresponds to status.task.motion_line
So the tpGetExecId() looks to me, that only motion should trigger a feedback by intention.

That means to me: extending machine-commands with line-number feedback might be a bigger operation.

Hi Andy,

Some commands don't have a slot to pass a line number in.

Yes, I already found out, that it is not possible, to step from given line. So I have to cheat lc ...
Don't know, whether I'll get it. I'll try next WE.
.

Furthermore, non-motion commands execute in literally no time at all. So there isn't much to highlight....

If you think about a running machine only, than you're right.

At work, we run every new program with singlestep and feedoverride set to 0 before starting the next step. In this mode, there is plenty time for every command and i.e. if you change spindle speed and/or feed, its important too.
But the most annoying aspect of the missing feedback is (for me), that I don't have a line information to restart after stop/pause.
On long running 3D-Jobs we stop the job to change inserts of milling head. For that you have to jog machine (in a virtual pause) and the restart the job. That cannot be done without relyable line informations.
Same is true for tool change or manual stops like M0/M1 - to get rid of those incidents I have to reparse the gcode on UI-side - nothing what sounds reasonable/attractive to me

I checked lc for dtg-settings on step with 0 feedrate and it works as expected. So I miss only few things

Reinhard wrote:

andypugh wrote:

Some commands don't have a slot to pass a line number in.

Yes, I already found out, that it is not possible, to step from given line. So I have to cheat lc ...
Don't know, whether I'll get it. I'll try next WE.

I already was successful in cheating lc
... so step from line works
.

andypugh wrote:

Furthermore, non-motion commands execute in literally no time at all. So there isn't much to highlight....

After some extensive tests I'd like to have at least M0/M1 and M6 have line feedback, as they require user interaction (at least without having atc). So it would be nice, to have the gcode lister reflect what's going on.
Would it be possible to add it to the wishlist?

Hi,

to show the discrepancy ...
.

The last movement executed is the "G0 Z30", but DRO does not reflect the position (neither axis, nor my app. Axis runs as check only - linuxcnc is controlled by my app, but toolchange popup is from axis manualtoolchange).
Tool change happens at line 54, but gcode-lister stays at 48 ...

... not obvious for a beginner

Hi Andy,

the state-tags branch is not buildable on current debian. So I activated an older one (stretch) and build it there.
I had to change NML-layer, as many structures have changed.
Finally I got both working and tested (my standard testcase) gmoccapy_2_tools_with_cutter_radius_compensation.ngc

From what I noted - i did not see any difference to current master (2.9).
Did not dive into the sources. So what should be better/different?
Just from using it, I did not see any difference.

So - back to current state: when so many structures changed between 2.8 and 2.9, I think it should be possible, add even more changes