Another plasma component...

Milltask is created as a named binary by the submakefile:
github.com/LinuxCNC/linuxcnc/blob/0f91c5...emc/task/Submakefile

(I made up the phrase "named binary" as I am not particularly accomplished with build systems, all my LinuxCNC work has slotted into the existing build)

Well Andy this turned out far simpler than I imagined. It took all of 10 minutes.
1. Copied the src/emc/task folder to src/emc/plasma
2. Edited the submake file to compile plasmatask
3. Commented out these lines in the sub make file as I was getting a duplicate main() function between plasma and task 4. added the new /emc/plasma folder to the main Makefile in the /src folder
5. Compiled using make
6. changed my ini file to use plasmatask instead of milltask

And my machine ran as normal with the new task system!

How could we add new pins from here? It would be nice to alter the iocontrol module to provide plasma specific signals.Could we make a new module for plasma iocontrol in a similar way to what I've just done? (eg. ioplasma)

I might mention it would be really nice if the StateTags branch was merged to master as then we should be able to save the user commanded feedrate and do away with remapping totally!

So now, I think we could alter the whole tool handling system to suit plasma. I'm not sure Phil will be up to the challenge when he's staring at the finish line.

rodw wrote: It would be nice to alter the iocontrol module to provide plasma specific signals.Could we make a new module for plasma iocontrol in a similar way to what I've just done? (eg. ioplasma)

Hmm, further study of the source and I answered my own question. Yes it is possible and by default linuxcnc comes with two iocontrol modules io and iov2 which can be selected in the EMCIO section of the ini config. From what I understand, this would allow addition of plasma specific pins to iocontrol.

There still needs to be a component as io and milltask execute in userspace so can't do torch height control

I think I have finally got tool handling sorted.

I'll describe how it works and if there are no (or not too many) objections I will clean it up and push it some time tomorrow.

MANUAL:
Manual selection of tools reverts to a combobox which now shows tool number and description.
Every gcode file will now need to have the feed specified, it can be:
F#<_hal[plasmac.cut-feed-rate]> - which will read the feed rate from the active tool.
Fn - with n being whatever feed rate you want. If using this you need to set the active tool feed rate to 0.

AUTO:
To specify an automatic tool change use M190 Pn (n being the plasmac tool number).
Then on the next line use M66 P3 L3 Q1 this is a handshake to let gcode know that the plasmac tool parameters are valid for the next cut.
Any number of tool changes can be made in a file but only ONE for each cut.

One upside to this is that Gmoccapy now reports the F word correctly.
One downside is that running imperial code in a metric machine and vice versa cause inverted feed rates. I will have a look at that later but cannot promise anything.

THC enable/disable is also done from the tool now so I will add three radiobuttons in a group:
On - THC is on for the duration
Off - THC is off for the duration
Auto - THC is controlled by the cut parameters of the active tool.

Hopefully this meets with your approval.

Cheers, Phill.

Phill, I think that seems workable given the constraints you are faced with. Its pretty amazing really to be able to achieve this. The M66 P3 L3 Q1 is designed for this sort of thing. So we are commanding a user space component to do something and we wait until it says it finished before proceeding with the gcode program. This is no different to the way Fanuc M40 external relays work for indexing etc.

The only thing I would like to see would be a disable pin (that defaults to enabled) on the plasmac component, and just leave it disconnected in your final version.

If the user wants to use it to disable THC from Gcode or from any other signal, he can do so just by connecting it. Many external THC's have a disable input so I think plasmac should have one too. People migrating from another system where they use sheetcam are likely to be accustomed to setting up automated cut rules in their post processor that disables THC. Even Hypertherm supports this feature.

So in summary, I would like to use auto or always on THC settings and be able to disable THC when I want to override the system. If I used auto, every tool would be set to on. Once stable, I'm looking forward to cleaning up my sheetcam post processor to make it plasmac specific.

I think I have success.

My plasma came without any cut charts so my first cuts with THC enabled I left the setting at 122 volts, this had the torch pogoing up and down. I then disabled the THC and did a cut at the correct torch height while monitoring the voltage, this gave me a value of 100 volts. I set this in the run config and made a few small cuts with the THC enabled, the voltage stayed pretty stable and the torch was rock steady too.

I then tried the auto volts but this had the torch pogoing up and down again, I am wondering if it read a higher voltage at pierce and tried to use that for the cut voltage. Not a big deal for me as I will work out required voltage through test cuts.

Thanks to Phill, John, and Rod for their help along the way, I would have still been floundering without it