New pin motion.base-feedrate in master branch

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.

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

Cornerlock only from memory.

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.

I think you need Arc OK plus THC Active

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.

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.