out of sync gcode lister / missing status update?

More
19 Oct 2019 12:14 #148316 by Reinhard
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?

Please Log in or Create an account to join the conversation.

More
19 Oct 2019 15:55 #148337 by cmorley
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

Please Log in or Create an account to join the conversation.

More
20 Oct 2019 05:30 #148387 by Reinhard
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:
emcmotStatus->id = tpGetExecId(&emcmotDebug->coord_tp);
and another fragment like this:
*(emcmot_hal_data->program_line) = emcmotStatus->id;
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.

Please Log in or Create an account to join the conversation.

More
23 Oct 2019 23:05 #148650 by andypugh
Some commands don't have a slot to pass a line number in.

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

Please Log in or Create an account to join the conversation.

More
24 Oct 2019 02:43 #148667 by Reinhard
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 ;)

Please Log in or Create an account to join the conversation.

More
25 Oct 2019 14:54 #148797 by Reinhard

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 :cheer:
.

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? ;)

Please Log in or Create an account to join the conversation.

More
26 Oct 2019 06:04 #148814 by Reinhard
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 :ohmy:
Attachments:

Please Log in or Create an account to join the conversation.

More
28 Oct 2019 00:16 #148945 by andypugh

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? ;)


This might all get sorted out if the state-tags branch is merged. Or it might not, I am fuzzy on the details of what that branch does.

Please Log in or Create an account to join the conversation.

More
29 Oct 2019 15:49 #149057 by Reinhard
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 ;)

Please Log in or Create an account to join the conversation.

Time to create page: 0.196 seconds
Powered by Kunena Forum