New pin motion.base-feedrate in master branch

Chris Morley has just released a new feature to master branch that creates a new hal pin
This pin is set by the F code sent in your Gcode so if Plasmac were to use this pin, there would be no need to pass the feedrate back to Plasmac with:
F#<_hal[plasmac.cut-feed-rate]>

I've tested this as working here this morning. For more info type man motion at the command prompt or consult the motion docs for master branch.

It just gets better and better for plasma cutting!

So Phil, time for an upgrade!

And great work Chris!

It's not in master yet Rod ..that's a testing branch.
This does what you guys need though yes?
Do you use reverse run - I haven't tested it with reverse run.

Chris

cmorley wrote: This does what you guys need though yes?

If it does as advertised then YES.

Do you use reverse run - I haven't tested it with reverse run.

Reverse run is used manually for error recovery so for plasma users it would not be a major concern if velocity was reported wrongly during reverse run

Thanks again Chris

Ooops sorry, I jumped the gun. I'm compiling Chris's test branch now...

cmorley wrote: It's not in master yet Rod ..that's a testing branch.
This does what you guys need though yes?
Do you use reverse run - I haven't tested it with reverse run.

Chris

Tested and working on the Spaceship!

The only consideration is that it shows exactly what the F command is. (in my case 1425 mm/min)
Should it show feedrate per second to be consistent with all the other velocities? (eg. 1425/60 = 23.75)
How does Phill use it in Plasmac?

Rod,

Can you explain exactly what this means for the uneducated? Is it just a cleaner way to do the same thing Phil has done?

Also what exactly is state tags again?

rodw wrote: The only consideration is that it shows exactly what the F command is. (in my case 1425 mm/min)
Should it show feedrate per second to be consistent with all the other velocities? (eg. 1425/60 = 23.75)

IMHO it is supposed to reflect what was in the GCode so it should be units/minute.

How does Phill use it in Plasmac?

Phill doesn't even think about it until it is in master. :lol:

thefabricator03 wrote: Rod,

Can you explain exactly what this means for the uneducated? Is it just a cleaner way to do the same thing Phil has done?

Also what exactly is state tags again?

I would not say it was cleaner. It was just more comprehensive so a lot more parameters were made available. There is an experimental branch in git. I thought it was paid for by Tormach but then nobody bothered to incorporate it into the core code. It touched a lot of code but those touches was mostly adding additional messaging. So now its 5 or so years behind, maybe more.

Phill, start thinking as I think Chris should push it.

yes it's in units per minute, as per the F code.
It certainly can be in units per second if that's better I suppose.
I was thinking the pin name should be changed to motion.fcode

The units can be different depending on the current units mode and axis type.
Ie if rotating its degrees per minute, if in imperial mode it's feet per minute.
That's just how gcode works, so should probably trap those things.

I quickly looked at statetags and it needs work to merge. It's surely better in the long run - I'm just not sure i'm up to the task yet and developers seemed to have dried up alot on linuxcnc...

Chris
I believe you guys use remap for this at the moment? Using this would lower the bar for users - Remap is a pain

cmorley wrote: I believe you guys use remap for this at the moment? Using this would lower the bar for users - Remap is a pain

No, we did use remap but as you said it is a pain so we gave it away.

At the moment we read the F word from a hal pin and use the hal pin value as our target.