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....

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

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!

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

tommylight wrote:

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!