New pin motion.base-feedrate in master branch

That HAL pin must be requested-vel?
Does your HAL pin suffer from the not-synched-to-motion problem?
Maybe it's not much of a problem usually.. only comes up if you change the feedrate in the program - status shows the last feed code in the program as soon as the interpreter reads that far ahead.

Chris

So Phill, do we only need this for cornerlock? Thats my understanding. I just wondered if you used it for anything else.

I had a bit of a play swappiing some pins around but did not see the cornerlock ever cut in even without me changing anything. But it should have. Does it need to be cutting for it to kick in? I was only dry cutting.

Also, what was the purpose of the pin plasmac.requested_velocity? I could not see it was used.

Chris, leave it as it is in device units per minute. I assume you meant inches per minute, not feet per minute. It seems internally the Plasmac component converts velocities per second to device units per minute.

I have ventured into state tags for a look. I don't think its terribly hard, just lots of it becasue the tags structure need updating at every point a message is sent. So its lots of cut and paste. But everybody ran scared when they saw how many changes in the commits with out looking at what they are. Also, you could cheat and write new task and io modules so they could be deployed without breaking anything. I was able to copy a couple of folders and update the make files in about 30 minutes to create my own task and io modules (which were exact copies of milltask and io modules) but heck it all compiled with master branch.

So by using fcode pin you could have different feedrate in the program and wouldn't need to adjust the gui spinbutton at the right moment.

The nice thing here is if we do get statetags we could just rip out my new NML message and add the HAL pin to the new statetag code (I assume anyways)

I'll wait to see if any other developers comment on the code and if all good, i'll clean it up a merge it in a few days. The pin name will change.

Thanks Rod for testing!

Chris

phillc54 wrote:

Also, what was the purpose of the pin plasmac.requested_velocity? I could not see it was used.

I must have left that in after i ripped out the remap junk, I am sure it is not used.

Its used in some calculations but only in the absence of a cutting velocity so it has no effect. I might have a look at using that pin and changing the corner lock code to just use requested velocity and see how it goes.

Well this looks pretty simple to incorporate into plasmac.comp

At line 908, change this:
Where in hal you do tis:
We just have to change the plasma pin name becasue the term velocity implies it is in machine units per second.
I should get a chance to try that and update my postprocessor in a few hours.

I don't think there is any need to use any conditional code becasue if you don't have a feed rate, you are going to get a gcode error well before this code has any effect.

cmorley wrote:

So by using fcode pin you could have different feedrate in the program and wouldn't need to adjust the gui spinbutton at the right moment.

I think the feedrate stays in the GUI becasue its set in the materials list and a user (or a postprocessor) can ask plasmac to retrieve a given material to use for the cut job from Gcode. This sets up all of the hal environment but the one thing it could not do in Hal was set the feedrate. That had to happen in Gcode.

So after a lot of prodding, Phill tried to use remap and found it was a pain. Then he tried using the tool changer but plasma cutting parameters are so vastly different to a milling machine, this did not work. So then loading the materials for given material number and setting the feedrate became:

This made Plasmac the master of everything when typically the postprocessor is the master.

So this pin will avoid the kludge of the hal pin and allow gcode to be written normally. But managing the materials is still required. I think I have over 80 materials defined for my machine based on the manufacturer's cut charts.

phillc54 wrote:

So this pin will avoid the kludge of the hal pin and allow gcode to be written normally. But managing the materials is still required. I think I have over 80 materials defined for my machine based on the manufacturer's cut charts.

As far as PlasmaC is concerned I need to think a lot more about this but at the moment I cannot see any advantage for PlasmaC to use this new pin.
I can definitely see an advantage for plasma users that don't use PlasmaC.

Probably correct. But it won't break anything and will allow any user to program their own feed rates. That would result in a more robust system and possibly one less support vector. If you set the feedrate using the Plasmac feedrate pin, this pin is updated. So once the pin exists, I think for the sake of a 60 second edit in the code, it would be worth using.