New pin motion.base-feedrate in master branch

There is a discussion on the maillist - it seems we have a couple single points of failure - currently only one? two? people can do some requirements.

The ball is ...rocking

Chris

So it just needs a nudge to make it roll...

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

block is one line of gcode
settings is the current interpreter settings
Statetag is new but obviously must be the current gcode state

Chris

cmorley wrote:

Code:

Interp::write_state_tag(block_pointer block, setup_pointer settings, StateTag &state)

block is one line of gcode
settings is the current interpreter settings
Statetag is new but obviously must be the current gcode state

Chris

Yes the StateTag structure is added to the emcmot_hal_data structure
So Chris if you have a look at motion.c Line 335, there is a procedure called init_hal_io that defines the motion pins. I'm sure you know this

Something like this should find the feed rate See: github.com/LinuxCNC/linuxcnc/blob/andypu...c/motion/state_tag.h

And finally, a definition of what State tags does in that file


So let me know when you have a feed rate pin using State tags