Feature update required.

In the plasmac docs, I noticed that you say:

If Cut Feed Rate in the Run Panel is set to Zero then PlasmaC will use motion.requested-velocity for the THC calculations which is not a very reliable way of velocity based THC and is not recommended.

But in recent days with the release of state tags thanks to Dewey Garrett, there is a new pin calledwhich is the feedrate in device units per minute in real time.

So Plasmac should be updated to use this pin which will be a reliable way to do velocity based THC.

I think John the islander, myself and a few others knew not to do this from way back when the docs were totally wrong. (It was John who painfully discovered the error). Motion.current-vel is the velocity that the TP can give on that line segment and can be constrained by max acceleration . Some of us had resorted to remapping the F code to get the original gcode command into hal.

Then along came Sir Phill on his steed Plasmac to the rescue and I think we convinced him to make a workaround... But now this feed-upm pin exists, it should be used to set the commanded feedrate in Plasmac becasue it will always be correct! Then there is no need for the user to ever use the plasmac feedrate pin (although doing it that way would make no difference.).

I will say its a bit annoying that its not in units/sec and have wondered if there should be another pin or a parameter set it that way as all the other hal values are in units per second.

phillc54 wrote:

So are you saying that in master branch motion.requested-velocity is not a true indication of the F word whereas motion-upm is?

Correct, it can never be depended on! Welcome to the wonder of State tags!

What state tags does is send the state of the interpreter back to shared memory for each planned segment. Previously that info was thrown away after it was parsed by the interpreter. Thats why any attempt to display feed rate previously lagged behind real time.

State Tags does not actually give any method to access the data sent.

So what Dewey did is create a new pin that exposed the feed rate in state tags as a pin in motion. This now replaces the pin Chris Morley created to do the same thing except with State tags, its 4 lines of code...

If you open the /src/emc/motion folder, you can review state-tags.h and motion-priv.h that creates Dewey's new pin. then the pin is published in motion.c and set from state tags in control.c Its actually a good (simple) example of how to create a pin.
Also while visiting command.c, check out the debug pins. These are for developer use and you can publish any motion data there fro debugging as a parameter in HAL motion.

I don't think State tags was ever a "fix" for anything that was wrong. Its purpose was to send the interprter state to shared memory so that the state was finally visible in real time eg. visible when the relevant motion segment was executing. I suspect it may have been used by Tormach as I heard it was done for them but never rolled into master for 5 years... Thanks to Andy!