Feature update required.

More
13 Jun 2020 22:19 #171511 by rodw
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 called
motion.feed-upm
which 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.

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

More
14 Jun 2020 00:22 #171519 by phillc54
Replied by phillc54 on topic Feature update required.
I was just looking at what is required to effect this change and noticed a long standing bug that shows no-one has tried this 'feature'.
The plasmac.requested-velocity pin and the motion.requested-velocity pin are not even connected in hal...
A good thing in one way as it means whatever I do for this it won't break anything.

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

More
14 Jun 2020 02:24 #171528 by phillc54
Replied by phillc54 on topic Feature update required.
So are you saying that in master branch motion.requested-velocity is not a true indication of the F word whereas motion-upm is?

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

More
14 Jun 2020 02:38 #171530 by rodw
Replied by rodw on topic Feature update required.
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.

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

More
14 Jun 2020 02:39 #171531 by rodw
Replied by rodw on topic Feature update required.

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!

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

More
14 Jun 2020 02:40 #171532 by phillc54
Replied by phillc54 on topic Feature update required.
But I thought state tags fixed the pins that were wrong so that now requested-velocity should correctly reflect the F word.

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

More
14 Jun 2020 02:41 #171533 by phillc54
Replied by phillc54 on topic Feature update required.

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!

So what was the point of state stags if it didn't fix whatever was wrong?

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

More
14 Jun 2020 02:52 - 14 Jun 2020 02:53 #171534 by rodw
Replied by rodw on topic Feature update required.
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.
Last edit: 14 Jun 2020 02:53 by rodw.
The following user(s) said Thank You: thefabricator03

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

More
14 Jun 2020 02:58 #171535 by rodw
Replied by rodw on topic Feature update required.
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!

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

More
14 Jun 2020 02:59 #171536 by phillc54
Replied by phillc54 on topic Feature update required.

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.).

Well it does a bit, you would need to set all your material cut speeds to zero and you wouldn't be able to use the wizards as they are. To me it kinda defeats the purpose of the materials file, may as well do everything in gcode.

For me there would need to be a different set of calculations for 2.8 and master, maybe different wizards. It seems like a lot of work for no gain.

F#<_hal[plasmac.cut-feed-rate]> may look a bit odd but it does work and it works well.

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

Moderators: snowgoer540
Time to create page: 0.134 seconds
Powered by Kunena Forum