Another plasma component...

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

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

Phill

Reading Gcode variables from the HAL does have a few restrictions. I used this method extensively in my plasma application to choose between cut parameters passed from the PP or use the ones from the GUI. It all works fine as long as you do it before any motion, I did all mine in the machine setup preamble and at tool changes. I seem to recall that once the look ahead is running this function doesn't work reliably. It may work when the motion is stopped for some reason. I think I remember others having problems when trying this in the middle of a file.

I am not too worried about how you implement THC enable from Gcode. Your proposed tool table solution will work, I can just change tools to one that uses the THC the way I want. With my application I have a number of tools in SC that vary only in feedrate and whether the THC is enabled or not, I just choose the correct tool for each cut between cuts. Please make the skip IHS type so it works correctly with the selected THC function, I do it externally now with my hacked version of your branch. Your method does potentially make the tool table grow large, maybe even doubling the number of entries if you need a THC enable/disable set of cut parameters for each material and cut current.

Thank you for all the hard work on the Plasmac branch. My machine is working nicely right now. Because I am now working an outside job at the busiest time of year for my own production work I will not be updating to the newer versions until I have more time in about 2 months. Sorry but the old " If it isn't broken don't fix it" is driving the show for me right now.

John

So why would a torch on command like M3 signal a diffrent pin then torch pulse. I have torch_on in the machine.hal set to pin 7 which should be the last output on TB6 but when I run a M3S1 comand pin 6 goes high and triggers another relay. When I push the torch pulse button on the GUI it triggers pin 7 and my opto22 turns on.

jtknives, it sounds like you have spindle.0.on connected to the other relay somehow. It should be connected to plasmac.spindle-on in hal.

Just recapping, spindle.0.on goes high on a M3 and I guess plasmac internally connects it to your torch on relay but the pulse button just triggers the torch on relay bypassing spindle.0.on

Dee436 wrote:

I think I have success.

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

Dee, you are welcome. its been good to have some less experienced people on board through this testing phase. here's my take on your problem.

You say things work at a lower voltage and not at a high voltage, I suspect you have your THC on delay set to too short a time period. Try 1.5 seconds or greater. Torch arcs are sampled as the THC is enabled. Without THC, when the torch pierces, the arc voltages goes up high very quickly, maybe say 50 volts over the cut voltage, then it starts to fall quickly for maybe 40 volts then tapers off over the last 10 volts until it settles nicely on the cut voltage and stays there. So if you sample too soon, you will be too high again. Over 2 machines from 1.6mm to 16mm, I have seen 1.5 seconds is the shortest period to be safe. On some materials, you could probably go as low as 0.5 seconds but I've erred on the side of caution.

You can also change the PID settings in the config tab.

You can use halscope to observe this in real time. In fact it might be interesting to reprogram the Plasmac halshow button to open halscope.

islander261 wrote:

Phill

I seem to recall that once the look ahead is running this function doesn't work reliably. It may work when the motion is stopped for some reason. I think I remember others having problems when trying this in the middle of a file.

John

Its my understanding that hal variables are only officially passed to the gcode once at the start of a program. if changes are reflected at any time during a program, it is a bonus but can't be guaranteed.

Hi,

Just a random plasma update to our highly respected Linuxcnc members.
Maybe people ever seen this brand www.caterpillar.com



They are cutting with Linuxcnc plasma soon at headquarters distributor in Holland (PON). I hope to get the order soon.

Just want you to let you know that linuxcnc even does a job for Catterpillar Equipment soon.
It's that Linuxcnc has become a higher market level thanks to the linux users and developpers.

Rod,

Its my understanding that hal variables are only officially passed to the gcode once at the start of a program

That's right. The ngc intepreter does it once.
But it would be better to expand the ngc intepreter with the possibility to pass a realtime value to it.
This can be used for upslope or downslope, not like 4 takt but real value's. Some things are i think pre calculated like milling machines with spindle speed related to diameter of material. So if Andy know's a way to pass real time value's into the currently executed g-code process. I would smile for a week.