I just did a dry run of a g-code with M00 (I tried the M01 recommended by nicads, but it did not pause) manually inserted in after a cut finishes and moves to the next start position. I think that will work perfectly, as it pauses the program, and waits for me to press start for the next cut, once the torch has cooled and is ready to run again.
Now I just need to figure out how to make the post-processor do that for me. But it isn’t that hard to manually add them.
are you running the regular CF or Pro? it’s always worked for me on the regular CF. haven’t tried it on the pro yet.
Running on the Pro with THC
ahhh, well that could be why… not sure how the pro handles certain codes.
your handle should have the “Crossfire Pro” added to it.
I’ll have to try that as well.
Looking at the f360 post file - putting the delay a little earlier in the function would do what you want. The section you want has a comment “BEFORE M3” on line 387.
Here’s my updated 1.5.1 F360 post file. It has a pre and post delay property defined and you can set them how you like (or set them to zero to turn it off).
(Remove the .tap extension)
FireControl-v1.5.1.cps.tap (19.1 KB)
As always - this is not supported by LS, and I don’t yet know if this is the best way to do this, but it will work. When they come out with a new post (i.e. 1.6) then you’ll have to move the changes forward if they are still relevant.
I like what you did there…
I built upon yours, giving the option for a M0 (pause for operator input) to be entered into the code after the torch head moves to the location of an additional cut. It also counts the number of cuts in the program, and displays that in the code.
Let me know what you think.
FireControl-v1.5.2.cps.tap (19.6 KB)
I’ll check it out. Another way to do stops with M0 is by breaking up your setup in f360 manufacturing. You create a 1st 2d profile cut and choose the contour(s) you want to cut, then you do a manual NC (m0) and then create another 2d profile to cut and so on. The manual NC let’s you put in whatever g-code, comments, etc you want in the setup and they will appear in the post file output based on the order you specify.
In my example, I wanted certain settings to apply to the first hole, and other settings to apply to the rest of the part. I put a comment in between them as an example. You can reorder the manual NC’s as needed.
You may find that useful as well if you were not already familiar with…most of the NC’s in F360 are not for plasma, but many are generic and should work. I’m still learning F360. Others may know of better or other ways to do this.
I’m having the same issue here. When cutting a file that has two pierces, the torch fires after it starts moving on the second pierce. I am using sheet cam however with a PM45XP. I added a 3 second pause after cut in sheet cam, but still have the same issue. I still need to test it with a longer pause after cut. @James5 was telling me he’s had to use up to 13 seconds of a pause to keep one of his programs cutting all the way through.
I recommend simply increasing your pierce delay to account for the delay between relay on and torch on.
I will try that. I had increased it a bit in fire control (maybe %40 which I realize is only .04 sec) and saw it cut a tiny bit more of the patch than before. I just wasn’t sure that was the “correct” solution to the problem. Would I need a different tool profile for initial pierces then since this only happens on subsequent pierces in the job?
Thanks Daniel, the issue is that the delay time varies based on the length of the cut, for the torch head to cool.
I have worked around the issue at this point by editing the post-process to add a pause (g-code M0) before any cut after the first one, So I can wait for the torch to be ready, and continue cutting. As I have shared in the previously posted “FireControl-v1.5.2.cps.tap” attachment.
I understand what you are saying, but pierce delay is after the torch has fired - having it sit for 1+ seconds when it’s blasting metal (or thinking it is) creates some other issues. That’s why I created the delays in the post after torch off and/or before torch on, but I’ve run into a few cases where a stop would be better so I can listen to the machine, but that creates a ton of handholding. I feel like I must be missing something.
He’s saying between relay on and torch on. Meaning the relay tells torch to run on, but the torch is not instant, but maybe .25 sec behind?
Why then do my initial pierces seem fine?
@brownfox This thread is mostly dealing with Miller plasmas and their quirks that @James5 is working out. The delays he is adding are for allowing the torch to cool. Something you don’t need to worry about and seems to be a Miller thing. The delays you need are for allowing the torch long enough to pierce. Hypertherm measures pierce delay starting once the arc has ignited where as Firecontrol begins counting as soon as it has told the relay to close. The difference between Hypertherm book and Firecontrol should be a fixed amount of time, ie the time from Firecontrol triggering the relay to pilot on. But none of us know exactly what that time is. I believe Langmuir has said in the future Firecontrol will have the ability to measure this via the VIM but for now it’s just a guess. It should be a constant though, not a percentage. Try adding 0.2s to Hypertherm book for pierce delay setting. You will not need other rules.
If you continue to have problems, it may be better to start a new thread. Post the generated gcode.
@James5 FWIW I think @langmuir-daniel reply was directed at @brownfox.
I Yep I’ve added .3 to my pierce delay and follow up pierces are fine now. I’m cursed with wanting to understand a solution once I’ve found it, so I still wonder why my initial pierces work, but I’m doing ok now.
I saw a thread where @jimcolt started a post by saying the hypertherm book specs were right on, but I lost it. I’m trying to find it to fully read and understand.
He’s most likely correct. But those are from when the arc establishes vs the FireControl measurement from when it says “fire” to the torch. The relay closing delay is the constant needed to be added to the published HT pierce times so we can account for the relay closing time until Langmuir figures out how to read when the arc is really established vs just when it issues the fire command.
Agreed, but I find it odd that a major manufacturer is ‘out of the norm’ on this. The post flows I’m seeing don’t seem normal to me. I’m totally open to I’m doing something wrong - it’s not like I’m old hat at this.
so i performed the update tonight before cutting a big piece of plate.
machine was running just fine before the update, now after the update, it just rams the head into the metal and drags it along.
what the hell is wrong?
