THC firmware 1.09, Bug?

I performed the update to the THC controller to v1.09, and now if an arc in not created, Crossfire does not error out and stop the program.

Is there a bug in the control software, that is not properly talking to Crossfire v20.3?

the code is created in Fusion360 using the crossfire post v1.5. the same design that would stop the program with the old firmware, does not stop the program with the new firmware

1 Like

It does error out, its just that we increased the delay between when the plasma cutter misfires and when FireControl throws the alarm. The reason we did this was because a surprising number of customers were using insufficiently short pierce delay (motion before firing) and rightfully getting an arc voltage lost error but chalked it up to the THC not working instead of recognizing that it was their pierce delay. We weren’t stoked on increasing it, but it was the lesser of two evils so to speak.

1 Like

I am running with a Miller 625 Extreme torch, and the machine seems to have a variable “cool down” period between cuts.
With the old THC firmware, Crossfire would error out between cuts and I would have to restart the program between each cut, it was preferable to how it is now, where the program will keep running when the torch has not re-fired, missing whole cuts, or parts of cuts until the Miller has “cooled” enough to start a new arc.

I have tried putting delay times into the G-code before the secondary cuts, but the delay time is variable, where a longer cut requires a longer cool down.

Or is there a way to add a need for user input between cuts to the post-processor, or directly to the G-Code?

I am currently having to make a separate g-code for each cut, which is very in-efficient.

Would it be possible for me to get a copy of the old firmware? Or if there was a way to set that delay back to the old value?

1 Like

If you’re running Sheetcam you can add a post cut delay to get back to the setting you feel works for you.

2 Likes

what james said or you can manually edit the gcode fileand add a pause before the next cut. you would have to press start to continue the next cut.

Add an M01 right after the M5. for some designs I add an M01 after every 5 M5’s or so to allow the compressor to fill back up and things to cool down.

Hey - I’ve got 625 Extreme as well. See my post Adventures in metal cutting - it might help. I’m still playing around with settings - I don’t have it where I want it yet, but I’m hoping to find a magic formula that works. I like the idea of adding time to end of cut instead of pierce delay to allow the torch to “reset/cool down”, but hoping LS might add an arc ok signal at some point which will eliminate need for pauses.

Also - there’s a post further down about modifying the post for Fusion 360 to implement same feature that Sheetcam has in Fusion360 - adding time to end of cut.

Thanks James.

I read your post. I will try modifying the post processing file, like you did. Do you know if there is a way to automatically get the delay to be after the move to the new cut position?

That is where I have been manually placing my delays directly into the code, so the air that continues to come out of the torch isn’t blowing into the water in the tank, but on uncut metal.

I may continue manually adding the delays, so I can adjust their length, based on the length of the cut made.

nevermind, you want it to automatically to it. maybe you can add it to the post processor somehow

To do that, you’d have to find the section that starts the cut and put the delay value there. Should be doable - I’ll look at the post file again this weekend.

After playing with it today, I had good results, but I did notice that some of my g-code I made before the delay modifications ran well in some scenarios - it definitely looks like the time the torch was on adjusts the post flow timing in the 625, so it will vary depending on what you are doing. Some things went great, others missed the pierce and torch was moving when it fired. I’m thinking 3 seconds is the max post flow and a safe value. Worst case, your cut takes a few extra seconds. As I get more experience running it, I’ll update the forum posting I’ve got going with any new info. Good luck!

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)

1 Like

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.

mnc1

mnc3

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.

1 Like

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?