Mach not stopping at M03 command to wait for ARC OK signal Ethercut DTHCIV

[motoguy]

Been fighting an issue. I've got a 50' torch on my Bulltear/CandCNC/Mach3 table. I had an issue with my torch starting movement before the arc fired. Luke at CandCNC sent me a "special files" package, which included a modified M03.m1s file. This is supposed to force Mach to wait for an ARC OK signal before allowing further movement, for the long torch leads. I installed the file in my Mach3_>macros->DTHC-IVSuperTHC folder, replacing the existing M3.m1s file (which I renamed M3.m1s.old).

I'm still having an issue with the torch moving before the ARC OK signal is received. Sometimes. Yeah.

On one file, cutting 1/4" steel, I tested it. THC set to "Auto/ON" in Mach (both buttons green). Shut plasma off, so no ARC OK signal can be received. Press run. Mach runs right up to the M03 line (320), waits, then steps back one command line (310). Torch sits still, waiting for the ARC OK signal. Perfect.

Try again, on file cutting on 11 ga. THC set to "Auto/ON" in Mach (both buttons green). Plasma off. Press run. Mach blows past the M03 command (line 310), and stops at line 360. This line begins my lead-in. The torch moves about .2 along this lead-in path (x axis), then stops. It's not a "hard" stop, like a regular movement. More like it STARTS to move, then the motor loses power (it coasts to a stop, vs a controlled stop). This file is cutting a bunch of letters. I've tested the torch on different letters, with different lead in points. Each time, the torch blows past the M03, and starts down the programmed lead-in patch (some x, some y, some "angled...it follows them all).

Here is a snippet from the file where it's working ok. Mach stops at line 320, pauses, then goes back to highlight line 310.

(Deleted long g code since it wasn't the problem)

HERE is a snippet from the file that is NOT working correctly. On this file, Mach blows past the M03 (line 310) command, and stops on line 360 while torch begins, then ramps down, movement:

(Deleted long g-code since it wasn't the culprit)

Any ideas on this? It's odd, but it seems I only run into this when cutting thin stuff. Maybe I only notice it then.

[BTA Plasma]

On 50' leads without an air solenoid (Hypertherm) a longer than stock pierce delays are inevitable. Expect a zero delay to be in the range of .9-1.1 seconds. Big tables require longer leads. On a Thermal Dynamics they store air pressure on the strait end of the machine torch and have a solenoid kicking it out immediately. On long leads with a Hypertherm there is a wait for air pressure to build from the power source to the torch tip. I can only theorize that the 50 lead has a way of letting the power source know that it is a 50 lead and has built in latency for that lead length.

[BTA Plasma]

Arc ok has changed in the ethercut system. The hooks for movement before arc ok signal is established are gone in one of the macros with the ethercut. It relies initially on the Pierce delay timing. We have a custom macro that Tom wrote for use with hi-frequency that has a long delay before arc is established that may work better for you. I cannot remember the reason it was altered from the older systems but it MAY have something to do with the way arc ok is sampled.

[motoguy]

Matt,

I'd like to try that. Although, supposedly the M03.m1s file Luke sent forces the M03 to hold movement until ARC OK is sensed. Sounds similar to what you are describing.

[BTA Plasma]

Fine cut 10ga will send an arc ok rapidly and you may have missed it. There may be a .2 -.3 latency. Not quite sure on that for a 50 foot lead but youll have to play with your pierce delay to make sure. Do some test lines and if you have to edit the P.xx in the gcode to get different pierce delays.

[BTA Plasma]

45a 10ga and 45a finecut will be different. Fine cut will use a smaller orifice hole and a stronger beam IIRC the reaction may be quicker.

[motoguy]

I'm not changing the actual tip/hardware. I'm not even cutting anything while I test (after this mess I made cutting earlier). Just choosing different tools in the program, then dry running the program.

Playing with the Px, looks like I need a pierce delay of at least 1 second to keep the torch from moving prior to arc starting. I thought I had changed that early on to test, but maybe I fat fingered it. Guess all my tools will start with pierce delay of 1 second min.

Of course, now the torch waits for the ARC OK, fires before moving, then sits there forever (or what seems like it, probably 1 second) blowing big divots before it starts moving. I'm cutting text on a metal badge/placard for a customer. Some of the cuts aren't much bigger than kerf width, so the divots are an issue. The cuts are fine once it starts, but getting really botched starts/lead-ins. Maybe I'll increase the over cut, to see if it can fix the botched initial cut area. I thought the modified M03.m1s file forced the torch to stop movement until the ARC OK signal was received, and the pierce delay time would start AFTER that. This does not appear to be the case.

Any way to stop the torch from moving until it gets ARC OK, then have it start moving immediately/correct delay time? If not, would a regular 25' lead fix this problem? This may be why I've been having such an issue getting good starts on thin stuff.

[BTA Plasma]

Put the old macro in and play with ramp lead in and your pierce delay

[BTA Plasma]

The other way is to jumper arc ok

[Thor]

I have same issue, mine is 35' lead

What I have found, if pierce delay is less than 1 full sec it doesnt wait for arc ok it just goes, longer than 1 sec and it seems to wait just fine. I typically run a .3 sec longer delay than the book says and it seems to be ok, but still notice on thin sheet that the arc is visibly firing as the Z is moving down to cut ht.

I'm starting to wonder if the new Linux system will fix it as it seems to be more a timing problem than anything, and Mach has issues with timing that Linux is supposed to fix from what I understand

[tcaudle]

If you have the EtherCut Upgrade installed then all you need to do is contact us for a custom M3 that loops (stopping further code execution ) until it gets a valid ARC OK . Works on longer hoses, older TD machines or any plasma where there is a long delay between when you tell it to fire (Torch on) and the actual start of the arc and current starts to flow.

Has to do with the latency of MACH and Windows and the inputs. LINUX has no latency because it uses no buffers to store motion.

[Thor]

I've also noticed that if dthc is turned off and on manual, that it seems like it ignores the pierce delay even more and starts moving sooner yet.

Will the custom M3 fix that as well? kinda sounds like it might. I'll have to email you for that.

[motoguy]

Tom,

Is the M3.m1s file dated 8/19/15 the new / updated file (as opposed to the old one, dated 3/27/07)? If so, I've installed it, and it doesn't appear to lock the torch until ARC OK is achieved (without messing with pierce delay, as mentioned above). Also in the package is an M4.m1s file, dated 8/19/15. There is no mention of this in the instructions. Do I need to do anything with this?

My directory structure is c:\Mach3\macros\. There I have the option of these folders: DTHC-IVSuperTHC, Ether-Cut_UG1, EtherCutPlasma-Metric (and a couple of router/mill folders). I've placed the 8/19/15 dated M3.m1s file in each folder, and don't seem to notice a difference. Actually, with the new file, the torch takes off completely, attempting to cut the entire part (without an ARC ON signal). So, I go back to the old one.

If you prefer this to be on the CandCNC forum, let me know. I've posted a thread on the issue there as well. Frankly, I often receive support here and it seems that I rarely get a response on the other forum.

[Thor]

Ok, I did the file mod like what moto msg me and is on the candcnc forum. My table is a whole different machine now and acts like it should on pierces, instead of firing the torch on the way down to cut ht it fires at .150 and waits the appropriate time then drops to cut. Have not tried it yet without dthc on, I know before with dthc off it fired even later like during the lead in move so this should help alot. Before I was getting around it by upping the pierce delay time, but even that never seemed consistent.

[motoguy]

If you shut the dthc off, it will ignore the new file, and do the same thing it used to do. It will start moving way early, it will not wait for any ARC OK before it starts moving, etc. It only works properly with the DTHC turned on.

For those trying to follow along, the modified m3.m1s file that Luke initially sent me was incorrect (did not have correct code in it). On the candcnc forum Tom posted what the text of the modified file should be. When I put that text in the m3.m1s file, it started working great. As Thor mentions, it transformed the behavior of my table with 50' lead. Very happy at this point.