Another plasma component...

Just back to the graph for a moment. What is being measured is the difference between average volts and current volts over the change in time (volts/sec.).

The torch stable operating voltage at about 102.5 volts before the kerf crossing.
With our guessed dv/dt threshold of 500, the kerf crossing would kick in at about 106.7 volts and the average at that time is 103.3.
We were not using a THC so I have no idea what affect that might make. I'm not sure, but I suspect that the servo thread is too fast for THC operations so it might be worth moving the THC to its own slower thread. This implies that it needs to be broken out of the component and run as a separate component. So a kerf crossing component in the servo thread might see the change before a slower THC component had time to change the height....

Item 1:
A bit more research has turned up another variable, transfer height....
It seems that after touch off the torch should go to transfer height then fire. After ark ok and a delay it should then go to pierce height...
Should I add this in or should I stick to going directly to pierce height?
If I add it in then I guess the height and the delay need to be user selectable.

Item 2:
I have another idea about torch touchoff (or probing or whatever it should be called):
Add another input named probe which can be used for either ohmic or some other type of probe.
Add a variable named probe_offset which is the offset of the probe when activated to the top of the workpiece.
When probing:
If: we get a probe input then use this as the probe success.
Else: if we get a float_switch input then use this as the probe success.

Here are some thoughts on this.

1. What is your intended user of this component? If it is the hobbyist/small shop using a modern air plasma then this is over the top and will not improve their cut quality or consumable life. Older HF units may get some benefit from this by way of improved start times. Higher end oxygen or mixed gas plasma units that use HF start ( late model industrial) will benefit from this approach.

2. My system currently uses ohmic sensing with automatic fall back to the float switch if contact is not sensed. The two inputs are joined by an OR2 hal component and the source of the probe signal is checked when the state changes. Ohmic sensing isn't easy, you need to check for a number of error conditions and try and clear them or pause for operator intervention ( I do this using a Gcode probing subroutine). Remember good IHS is the holly grail of plasma cutting with air plasma.

3. Rod W. has the right plan. Separate components for each function that are either joined together by hal file or an overall component is the way to go. The plasma world is very fragmented with different hardware in many installations, an easy way to customize functionality to deal with unique hardware and CAM solutions is much easier to handle if presented in bite sized pieces.

John

The original intended user is me, definitely a hobbyist, using air plasma, zero experience...
After a lot of forum reading (here and elsewhere) I thought that single component would suit my purpose as it would lead to a simpler hal file.
I got the basics working (in sim mode) and as it is relatively easy to add extra functions without much additional overhead it grew from there so I decided to share what I came up with in the hope that someone may find it useful and also for feedback as to what is really required.
I was also hoping that a new (to linuxcnc) user may find it a relatively easy way to get a functional plasma system up and running.

islander261 wrote: 3. Rod W. has the right plan. Separate components for each function that are either joined together by hal file or an overall component is the way to go.

There are a few reasons I think like this

1. That is consistent with the LinuxCNC component approach. Many standard components are < 10 lines of code.

2. I was always taught that if you could not see a procedure on a single screen or page, it is too long and it needs to be broken up.

3. I was adding pieces of the puzzle on a progressive basis.

4. Many of the pieces are totally unrelated. Eg corner lock/velocity anti-dive and torch sampling have nothing in common.

5. A small component is much easier to debug where we don't have access to a debugger to step through code in an interrupt service routine environment.

But Phil, you have worked out how to use git so you have a great opportunity to get your code included in LinuxCNC then I have so keep up the good work. Like you I knew nothing about CNC or plasma when I started!

The good news is I finally found my mouse for my Linuxcnc box today so I might be able to try some of this stuff!

rodw wrote:But Phil, you have worked out how to use git

Attached is my goto doc when using git.
Some of the url's may be out of date but...

Thanks Phil, now everything except reverse run is in master, I might see if I can clone master branch and see if somebody will incorporate some of my components into master.

the main problem for the pierce is the material that boils and inexorably ruins the nozzle. generally it is improved by starting first at very low speed so that the melted material is left behind by saving the nozzle.
thanks for the job

rodw wrote:
The good news is I finally found my mouse for my Linuxcnc box today so I might be able to try some of this stuff!

:woohoo: You lost your mouse ??? Do you own any cats ?

tommylight wrote: :woohoo: You lost your mouse ??? Do you own any cats ?

No but I think I'll have to blame my dog for finding it as she was at my new shed today as I found this lifeless mouse on my floor!!!

Been looking for it for a fortnight!