New pin motion.base-feedrate in master branch

andypugh wrote: I actually have no idea.

I _think_ that it mainly keeps the "status" stuff up to date.
I think ideally Chris' extra HAL pin would be added too. And maybe a few more.

Andy, I'm glad you have no idea The issue with State tags when I've looked at it in the past is that there is no mechanism to extract the new tags data in Hal.

And today proves exactly that!

I have run this up on my plasma table and can confirm nothing has broken. But also no pins show the tags.

I think what is needed is a component that publishes the tags so they can be read in Hal.

Any ideas how a component can access the tags structure? If we could get that far, this would be useful and replace Chris's feedrate pin.

cmorley wrote: Eventually I'll just do what I think is best at the moment and if people don;t like it they can come take this lead

Chris, I think Phill's Reverse run could be included in V 2.8. It has more than enough testing over the last 12 months to prove it does not break anything. It would be great if you two guys could make that happen.

I have seen references to StateTags for a few years now and it would be nice to know exactly what State Tags does and what issues it fixes.
I have read here (or maybe seen on the list) that Tormach uses State Tags, does anyone know how they use it and what benefits are gained.

phillc54 wrote: I have seen references to StateTags for a few years now and it would be nice to know exactly what State Tags does and what issues it fixes.
I have read here (or maybe seen on the list) that Tormach uses State Tags, does anyone know how they use it and what benefits are gained.

I think the intent is to publish the gcode parameters that are thrown away after they are read and tokenised to motion.

My understanding is that it adds an additional structure to emcmot_command_t around line 209 in
github.com/LinuxCNC/linuxcnc/blob/andypu.../emc/motion/motion.h

And that structure is defined in
github.com/LinuxCNC/linuxcnc/blob/andypu...c/motion/state_tag.h

So in motion.c github.com/LinuxCNC/linuxcnc/blob/andypu.../emc/motion/motion.c
It should be able to add new pins for the tags as they are known in this code.

I don't know the python stuff at all, but I assumed that data is available in linuxcnc.org/docs/2.6/html/common/python-interface.html but I may be way off.

So now with Andy's foundation work, maybe Chris can advise how to publish those pins.

I am still none the wiser, I had a bit of a grep but there is not much in the way of documentation.

I also noted several runtest failures that I guess will require investigation (I had no failure in 2.8 or master)

Phill, this issue may help but really I am in the dark a bit too.
github.com/LinuxCNC/linuxcnc/issues/440
This was raised by PCW when Islander261 finally worked out that motion.requested.vel was not docuemented correctly.

I spent a number of hours exploring the code in the /src/emc folder and the relationships between cannon, task and motion to see if I could do what Cam has achieved but gave up.

Basically, each module is firewalled from each other and use interprocess messages to communicate. A global status structure is maintained. From memory, this is EMCMOTSTATUS and it is based on the structure I linked to.

State tags added an extra structure to this global structure and it is updated by cannon before motion commands are tokenised and passed to the trajectory planner.

But I think the missing link is publishing this additional data to hal so it can be used. It will be interesting to hear feedback from Cam and Andy.

I'd really appreciate an explanation of how this works and why so this thread would be a good spot to do this.

So the state tags are updated in
github.com/LinuxCNC/linuxcnc/blob/andypu...4ngc/interp_write.cc
in procedure on line 210

So at this point I'm assuming the rs274 code has been parsed and the status (and state) is written to the other rmodules