dead fields in EMC_STAT?

Hi,

I wanted to show active gcodes in UI, but I had to realize, that these fields are not updated from hal side.
Same is true for active_mcodes and cycle_time.

is this a problem of simulator run, or do I have to change configuration to get that values updated on time?

You may be describing the problem of the tp being ahead of the actual machine.
Some status is reported not in sych with the motion.
The state_tags branch was intended to fix this - but no one has worked on that in a long time afaik.

There is also some (one?) eg spindle (css) rpm calculated and not sent back through Status - so id reported as maximum RPM rather then the actual RPM.
There is a work around for that one using hal_glib.

Chris

Hi Cris,

thank you for your attention and reply!
.

You may be describing the problem of the tp being ahead of the actual machine.

Sorry, but I don't understand you at all. Can you say it with different words, please?
.

There is a work around for that one using hal_glib.

I won't say, that I already understand hal_glib - just skimmed it ...
From what I remember - hal_glib uses linuxcnc.stat as well.
I reimplemented linuxcnc.stat for java and I already have a synchronized gcode lister working, as well as signals, leds and of cause: dros.
I got curious about what information could be valuable for me and I looked at the NML class definitions.
So I found active_gcode, active_mcode and cycletime.
My mill at work shows the active gcodes in advance for every ongoing gcode. That's quite handy and I like it.

Call me stupid, but I thought, the naming explains behaviour, so I wanted to get rid of those values.
Could not imagine, that the fields where just a "letter of intent" from the days long long ago ...

Ok - so if its not my fault, I continue investigation about active informations.

Thank you so far!

Cheers Reinhard

I used the wrong terms anyways
.
I believe it's EMCTASK that makes the motion commands queue
linuxcnc.org/docs/2.8/html/code/code-not...rchitecture_overview

So EMCTASK runs as fast as it can to stack up motion commands for EMCMOTion.
Some status items say like block delete gets set in TASK (when it makes a motion command) and is sent out through status right away rather then when EMCMOTion reads that motion command

So for instance if the program is really short EMCTASK can be done before the first actual motion is completed by EMCMOTion and then some status will report whatever EMCTASK last set them to.

I would expect active gcode to be one of the status details reported wrong sometimes.

Hal_glib does use status but for a couple variables it checks the HAL pin to to get the real up-to-date information. It's a work around and can't fix everything.

So for instance if the program is really short EMCTASK can be done before the first actual motion is completed by EMCMOTion and then some status will report whatever EMCTASK last set them to.

That's right.
I use the axis demo gcode for testing. There all tasks are done before starting the game.
.

I would expect active gcode to be one of the status details reported wrong sometimes.

Hm, that array gets no changes during run. Same is true for cycle time.

At work we test gcode with singlestep and feed override set to 0. So when you press start, nothing will happen. Just the dtg-Values change, as well as the active GCodes. That's quite nice and you can see, what will happen, when you change feed override to non-zero.

So from my point of view active_gcode is not a task information, but a motion information.
It may be true, that this information slows motion down, so the information was disabled.

I guess cycle_time could be implemented in UI-client. I'll go for it.
Stil a lot NML to learn ...

Gcode changes during run when I test it.
it depends a lot on the gcode.
If there are queue buster codes then task has to wait for motion to catch up so then status become current again.

We all agree that status should be current - it's just difficult to fix.
State-tags branch would be a great start.

Chris