FireControl 20.5 Now Available for Download!

Nothing%20To%20See%20Here
claim-fake-news-disputed

3 Likes

What’s to stop you from dead ending the machine to 0,0 and hitting set zero? Sure a homing routine with limit switches is a bit more graceful, you may not hear the motors scream, but if you are up against the physical limits those shouldn’t change.

When I needed a bit more control over zero (center of sheet for bolt circle holes), I’ve marked the sheet center, then lined up the torch over the center mark (using an Easyscriber in the torch makes this a bit more precise), then pressing the zero axis button. I’ve recovered from torch misfires this way, and from FC crashes, this does require lining up to the center mark again.

I agree with some of your complaints but I’m hopeful most of those will be addressed in future versions of FC. Have you submitted bug reports for your repeatable problems (program validation lock up)? They can’t fix what they don’t know about.

The problem with Mach 3, is that it is dead. There’s no new development being done on it. Sure it may do almost everything now, but what about in 5 years from now on the latest OS? It’s not a piece of software to base the success or failure of your company (Langmuir) on when you have zero control over it.

1 Like

@Greg9504 , you make good points. I am planning on adding a permanent laser pointer that I can use to refind zero in the future, I’ve been using a magnetic one so far, the only issue with this is that even at the finest movement speed it’s kind of hard not to overshoot when slewing the head.

While I agree with the notion of building their future success on a new platform, my issue is that I need a machine that does it now. In five years from now I’ll be using something completely different by then.

Point made as well that I should be trying to capture the failures to upload to support rather than just complaining about them. I’ll make an effort to do just that.

Your input was helpful and appreciated

That sounds great! I can’t wait until you guys finally make it so the original Crossfire owners can use Fire Control…any update on the upgrade availability?

Murphy’s law in full display here. Just days after stating I’ve had only one issue with Firecontrol, I run into something I have never seen before.

Cutting 18g and the first loop cuts as usual, fine. Every subsequent loop, the torch moves to the beginning runs IHS and begins the loop without firing the torch until about 1" into the loop. Every loop after the first does this.

IF I stop the program after each cut and wait till post flow ceases, and initiate “run from here” for the next loop, they all cut normally, fine.

Nothing in my workflow has changed OTHER than cutting at 275ipm. I typically cut thicker metal…
Same CAM setup process as the hundreds of other tool paths I have exported and ran other than setting up a new tool with the faster cut rate.

Any thoughts?

Thanks

my noob first reaction is your pierce delay and what machine are you running?

Running Hypertherm 45XP.
When cutting 16g my pierce delay was .1 with a cut rate of 249ipm according to Hypertherm charts.
So I figured on 18g I would drop pierce delay to .09 and increase cut rate to 275ipm.

All my actual tool path settings are unchanged from every other file I’ve cut since March when I got started. I even power cycled all my components. Wondering if it could be consumables or possibly a clogged shield hole(s)?

I don’t own a hypertherm but I have read countless threads on here of people putting the Pierce delay to what hypertherm recommends, but they have to run a longer Pierce delay as the Langmuir unit actually starts the Pierce time differently

YES! I’m not alone, I have been battling this since the “upgrade”…

I have to add .4 sec to every Hypertherm posted pierce delay time to get it to work with my 45XP

2 Likes

So you’ve had good results with Firecontrol when adding that .4 to Hypertherms pierce delays? I’m baffled that this issue never occurred for me until increasing to 275ipm.

I’m gonna run some test files to see if I can pinpoint the hiccup.

Thank you for that suggestion.

I created a simple 6 loop cut file and duplicated it 4 times.
18g 275ipm .1 Pierce = Complete first loop, incomplete remaining 5 loops
18g 275ipm .5 pierce = Completed all loops but the first loop was noticeably longer pierce delay(thereby a “dirtier cut” than the last 5)

I duplicated these programs changing only to 16g and 249ipm with the exact same results.

Some things to note:
This is running the Windows Firecontrol 20.5 in Parallels on my MacBook Pro. I had to stop using the Mac version off Firecontrol when I upgraded top Mac OS 11 because Firecontrol does not communicate with the table electronics currently when launched on Mac OS 11.

Prior to upgrading to Mac OS 11, this “pierce/incomplete loop” issue never existed for me in FireControl 20.5 Mac version. It also had never existed for me running Firecontrol 20.4 in Parallels on the MacBook Pro.

This leads me to believe there is indeed a hiccup somewhere in the 20.5 version of Firecontrol for Windows with regard to First loop pierce delay and every subsequent loop in that program.

The adding .4 to the Hypertherm pierce delays does work but with the extended pierce delay on the first loop, it’s obviously not ideal.

Hopefully this helps Langmuir focus in a bit on how to reproduce the issue. Looking forward to a Mac OS 11 stable version of FireControl as well as a rectified pierce delay for the Windows version.

It’s interesting you didn’t need to do that before. The extra time is due to how the Crossfire measures the time & how the Hypertherm tables do.

HT measures from when the torch relays trigger & current starts to flow. That’s a bit if a delay from when the controller tells it to fire but it doesn’t matter because they get a signal from the relay that it has closed.

The Crossfire starts the clock when the fire command is processed. Because they don’t get a relay triggering signal back it can’t tell when the torch actually starts to fire. So we add .4 to the HT published delay times in order to make sure it’s been triggered.

Things like this feedback circuit are why HTs are the top of the heap. But they come with an extra 0 on the price tag :slightly_smiling_face:

Not sure why you didn’t need it before unless there was some lag in the computer side processing that has now been eliminated and you lost the benefit of a computer induced delay.

2 Likes

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 firing the torch with a switch (pushbutton) directly on the plasma…fire it once and then release the button…you will hear postflow…push the button again during the postflow and the torch will fire almost immediately.

If it does not fire for 2 seconds…contact me directly and I can help you troubleshoot.

Update: I was curious about the actual time difference between the original firing of a Powermax65/85 torch and when you fire it during the post cooling flow. For the original start there is a slight delay of about 100 to 200 milliseconds (varies with torch lead length) as it takes a while for pressure to build at the torch. When the start signal for the plasma is activated during post flow (cooling flow that occurs after each cut cycle for about 10 seconds), the air flow is shut off at the power supply solenoid, it takes a few milliseconds for the air pressure in the torch to drop close to zero, which allows the spring loaded electrode to contact the nozzle…then the solenoid is reactivated to start the process. Our engineers tell me that during post flow a system with 25’ torch leads takes 400 miliseconds to fire (after the start signal is active), and with a 75’ torch lead can take 900 miliseconds.

Most cnc plasma machines use the arc transferred output from the plasma (contact closure between pins 12 and 14 on the interface plug) to indicate the arc has transferred before the part program progresses beyond the plasma start command. If you are just relying on a timer between the issuing of the start signal and the start of machine motion…then there will be differences that can cause cut quality issues with most plasma systems.

Jim Colt jim.colt@hypertherm.com

original post

Not sure they can. Hypertherm is on the top of the heap because of their continuous R&D. They have patents on this stuff going back decades. That sux circuitry likely is covered by a patent which may be why you don’t see it on every plasma cutter on the market. If it is Langmuir would have to license it to provide an interface. Since HT sells tables they might not be inclined to do that :smile:

@jamesdhatch The “arc OK” signal is provided on the Hypertherm CPC port and wired with the Hypertherm supplied interface cables. It’s the correct way to handle pierce delays. I don’t believe there is anything legally stopping Langmuir from using the signal, in fact they are encouraged to use it. Other systems such as CANDCNC provide support for it. And finally here is a post from Langmuir way back in May where they say support is planned:

Note the post 2 above that one where @jimcolt recommends using the 12/14 contacts for arc ok.

I sure hope it’s not. It’s just a voltage signal - my Miller has it (perhaps they licensed it though) - the software just needs to check it’s on/off state and move it it’s active. Or wait for signal event and then move. I wonder if more complex due to different plasmas implementing the signal differently? I think one problem may be there’s no place on the board for it? I wouldn’t have any issues being a test user if LS wanted to provide some experimental software / wiring instructions. I really want to get that working…

Good point.

That means they must still be struggling with this part: “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).”

I cut about 15hrs a week consistently for 2 years. I have 2 xfires and 1 pro. For the price hard to complain and I do feel like some of us are beta testers at times. My 20.5 has been randomly freezing atleast once a day and during cutting, that is straight up annoying. I have had Z axis issues alot. Im not a fan of the new upgrade simply bc its not reliable. I can get by and get done what I gotta get done but most days are a battle. I have about 800 pierces and 4500 inches of cut a day. I from experience like this company and machine at times but the PRO in the name I agree is not ideal, not dissing them by any means. I just finished cutting my taller stansion plates and will install them tomo. That should help eliminate some issues Iv had. I will also be making a taller water table. I use the xp65 and use to use the xp 45. As for the pierce delay, I add them to all my cut files and YES they def need longer pierces per the HYP manual. The cut speeds are pretty on point. Im a biz owner and I know what it takes to create and operate/scale a biz. I commend this company and am grateful for them, unfortunately FC as much as I do like it, has been freezing alot more on me lately.

2 Likes

I also have a thread started called any Pros using the Pro with success. So i’ll post this on there.
I finally got the 3" stansion plates on. I’ll make my new water table about 1.5" taller so that will still help with splash up. I will be getting a silicone cup to try out also. By raising the rails it allowed me to push my torch down more so its better balanced.

FC completely FROZE again on me yesterday (happens at least once a day) when it does this, the zero coordinates are completely gone. This SUX a big one bc in order to save material it takes 10-15 minutes of getting it back to where you hope it will be good. With accurate parts its difficult, with parts that aren’t based off much accuracy not a big deal. But this is now my number one issue aside from misfires or mechanical issues. FC is just not reliable with the 20.5 patch for me.

I also took and squared off an edge on all the lead screws. Except one the X lead screw. that thing slipped on my yesteday ruining a sheet. I need a new screw in it also bc the one is stripped. The Z axis got hung up also, but I think that is cause I sprayed it with lube. I blow it out an it eventually runs good for a while. Also having the Z axis farther up really helps keep debris and water off of it.

2 Likes