Crossfire Pro Pierce Delay

[JediTanker]

While reading another topic, I came across this statement:

@Greg9504

The CrossfirePro has an inherent delay of about 0.3 to 0.5 seconds (relay closing) that needs to be added to the machine published pierce delay.

I didn’t want to highjack the topic so started a new one. However, can someone (Greg maybe) talk a little more about this. It is the first time I have come across it in the topics that I have read.

[Greg9504]

Powermax 45XP -- consumable life?

The reason is because the book setting delay times start AFTER the arc starts. There is a sizeable delay between when the torch is triggered and when the arc starts. In a future firmware release we plan on giving users the option to have pierce delay start after arc voltage is sensed by the THC, but for now you must account for the delay between trigger on and arc on.

If you search “pierce delay” you’ll find a lot of posts where people with mostly Hypertherm plasma cutters complain about errors from Firecontrol (Error: Torch starts moving…). This is because people first use the published pierce delay values found in the Hypertherm manuals. The problem is that Hypertherm measures this value from the moment the arc is ignited. CrossfirePro measures this value starting from the time the command was issued. What this means is that the published values in the Hypertherm manuals are too short. So to get around this you have add a set amount to the published values.

Hypertherm provides what is known as the “arc transferred” or “arc OK” output from their cutters. The CNC controller can then monitor that signal to know when to start the pierce delay timer. In May 2020 Langmuir suggested support for this would be coming…

Powermax 45XP -- consumable life?

Yes its always been in the plans, its actually very simple to implement softwarewise, but the biggest challenge is being able to support functionality with and without THC (where you dont have a voltage signal to start the delay timer from).

To further complicate the issue, Hypertherm ‘first fire’ can result in a longer delay. The arc ok method would negate having to worry about this, in practice for myself I haven’t found it to be a problem.

You can read more about it here

FireControl 20.5 Now Available for Download!

Found this at Plasma Spider. I think this should answer all the questions on hows and whys of the first delay is different than subsequent… and why it would be good for FireControl to use one of the available aux inputs to monitor the arc transfer signal. There is not 2 second delay built into the Powermax65 or 85. There is a very slight (maybe 200 milisecond) delay when the torch is in postflow…as the air flow has to stop and the torch must refire…but it is nowhere near 2 seconds. Try firi…

[JediTanker]

I have yet to get the error, but I am running an Everlast not Hypertherm. Is it recommended to add the extra time regardless of machine brand? I have thought my pierces a little sloppy, and was eventually going to monkey around with trying dial in better values, but it always seems there is something more important to do.

[Greg9504]

If you are not getting errors then I wouldn’t worry about it. If you think they might be a little long (leaving a large divot) then you could use the feature within Firecontrol that allows you to decrease the pierce delay without having to regen the gcode. Once you get the error you know you’ve gone too short.