Powermax Fire Timing During Airflow?

[urbnsr]

Is there anything I can learn from how the Hypertherm timing of starting the arc happens?

I used to have a cutter that could re-fire the arc during postflow. The Powermax needs to stop the air flow to start the arc and I am running into pierce timing issues. At first, I thought it was in the GCode running LinuxCNC, but I'm now thinking the problem has nothing related to gcode. I've never noticed a timing issue on the first pierce, but somewhat randomly seem to have no pierce time after that first pierce and the torch is down to cut height and cutting too quick. I notice this on a delay of 0.2 second on 3/16" material.

My code goes something like: X/Y move in to position, touch-off, Z to pierce height, M03, M66 P0 L1 Q5, G04 P0.20, Z to cut height, X/Y move to cut.

I have increased the G04 wait to 0.6 seconds which can result in pierce times too long at times, but at least the torch isn't lowering while the torch fires, either. Or that I've noticed. I'm guessing that when LinuxCNC thinks the torch actually started and when the cutter does produce an arc are far enough apart that the wait for arc has expired along with the pierce wait time, but 5 seconds waiting for the arc-ok sig seems like a long time. I'll next try 10 seconds just to make sure unless I learn otherwise.

Any insight appreciated. Thanks!

Paul

[WyoGreen]

I have a powermax 45, and it fires during the post flow. Just last week I did a job where I did a peck-pierce to center mark for some holes to be drilled later on the drill press. The torch fires well above the plate to start the post flow air, then moves across the plate firing briefly at each center point. If it didn't start the post flow first, the first center mark gets messed up because of waiting for the post flow to start.

So I wonder if there is something else going on with your set-up?

Steve

[jimcolt]

All blowback style torches from Hypertherm will re-fire during the cooling post flow, but they must first stop the airflow, then restart it. Each different torch design has slightly different timing based on length and volume of the torch leads etc.

In regards to this varied timing affecting pierce time.....it is recommended that you do not base pierce time from the plasma start signal, rather, you should use the output "arc transferred" contact closure (pins 12 and 14 on the CPC interface on Powermax units). This output is a contact closure that occurs when current is sensed on the work ground cable.....and allows you to start machine motion and or pierce delay timing accurately and repeatably. Relying on the plasma start signal is not accurate or repeatable with any plasma torch.

Jim Colt Hypertherm

[tcaudle]

One of the useful features of a THC is to have the ARC OK as part of the pierce cycle. I don't know what HAL you are using but ti should first fire the torch and the THC Logic should HOLD all motion until it gets a valid arc ok (Transfer on a Hypertherm) signal. That way no matter how long the process or where you are in the cut it won't start the plunge to cut height. Mixed into that is not letting the THC turn on too soon or at least delay the control signals until the torch is well past pierce and plunge time/

You can rig up LINUXCNC to monitor an input for ARC OK and just not release motion until it goes valid.

[urbnsr]

Thanks for the responses.

I am using "M66 P0 L1 Q5" which is tied to the CPC's Arc-OK signal - This will wait 5 seconds from the M03 start for the first motion.digital signal, my Arc-OK input, to raise. After 5 seconds it moves no matter what the arc-ok signal is. Normally, this works. Five seconds seems like a long time if everything is working OK.

I did assume my controller and/or computer was suffering from noise, so I now run all inputs through a debounce filter. I thought this took care of my problem as I had over 200 pierces without seeing a problem. This was on 11 gauge or thinner, so it wasn't a true measure. Went back to my 3/16" job and there the problem returns. As I also mentioned above, I will change it to 10 second wait just to see what happens.

If that doesn't help, I'm back to assuming a noise issue, but wanted to cover this to see what you all think. I'm not sure I noticed this with the previous HF start cutter. I assumed if I had a problem with noise, it would show up there first...?

Also - Tom - Has CandCNC released any LinuxCNC drivers for your THC equipment? I realise we're still in the first quarter of the year, but this seemed like a good opportunity to check.

Again - thanks all. I will try a longer motion hold time to hopefully take care of this.

PK

[tcaudle]

It might work better to do a "while" type loop so when you call the delay you loop until you get an ARC OK
That way you don't need to keep changing times. It just delays until you have a valid arc ok.

I have a policy to not talk about on going projects until I see actual working prototypes. I will say that the current plan for the first release will not be to just have LINUXCNC drivers for the existing hardware . First problem is that the Ether-Cut is based on a MACH3 only pulse card with no LINUXCNC drivers planned. Since that platform is the best selling one, the first LINUXCNC release will be for Ethernet a different pulse card. The DTHCIV and the BoB will remain the same. It's questionable if we will wrap back and do support for the legacy parallel port and the older DTHCII . The answer to how soon you will see the first LINUXCNC Ether-Cut DTHCIV system is: Sometime in the next 60 days. I will make any announcement in our support forum

If you currently have an Ethernet based product from us we will try and make a way to upgrade. If you have the complete controller it would just be a front end replacement and you keep the rest of the control. Older controllers with a parallel port can be upgraded using the same front end replacement

We will continue to build and ship the MACH3 based systems and support both types of interfaces for that series.

[urbnsr]

I tried a few things. Nothing helped. Longer wait-for-arc time, decreased/increased debounce filter settings. Some pierce delays were no good. So I am back to wondering about a noise issue. I have shielded cables and could run a high frequency start cutter without interference. The two differences from the previous cutter I am now thinking about are that the CPC cable from the Hypertherm to the controller is not shielded and the other thing is that I am running the torch lead right along with the shielded cables for both motor and limit/floating head switches.

Is anyone running all leads/cables together without problems? I see cable chains on many setups and assume all are in these chains, but can't say for sure. Next I will try moving the torch lead so it runs away from the rest of the cables.

[urbnsr]

Great - Thanks Tom. I will watch the support forum.

[urbnsr]

OK - In case anyone is interested. I built my own shielded CPC cable and also re-routed the torch lead opposite of some other control/motor cables (also shielded) and after 385 pierces, all good pierce timing. Someday I'll determine which one actually took care of the problem.

Thanks for the replies!

Paul

[tcaudle]

In our system with our CPC cable it is short and designed to run directly to the Digital interface box. THe analog volts at 50:1 simply cannot be allowed to have outside noise or EMI over about .020 Volts or you get bad readings It is never a good idea to run Torch leads in close parallel proximity to control cables. Al lot depends on the controls and how noise immune they are but running conductors in parallel creates a "transformer". Shielding has to be connected tot he only one end and the proper ground and works much better to keep low levels of noise OUT of a sensitive control wire rather than block high current noise or to prevent a cable from transmitting that type signal. The shields are often just ultra thin foil and are not real effective on longer wavelength (lower frequency ) waves

I do not know how sensitive the torch fire (START) circuit is on a Hypertherm but if fired with a relay it would take a lot of external EMI to "unfire" that circuit.