M66 Wait For Arc-OK: L1 or L3?

Hi there,

I use "M66 P0 L1 Q2" to find out when the plasma arc transfers to the cutting material. Would there be any advantage toward timing accuracy if "M66 P0 L3 Q2" was to be used instead? I assume a L1 rise is for analog and L3 high-state is for digital and if this is correct, can the rise moment vary from one event to another even though I would guess that the arc-ok signal is either on or off?

I am having times when axis movement starts sooner than it should and other times, during the same job, that the timing is better. I'm not by the machine to test at the moment, but am curious enough to ask.

Thank you...
Paul

Hi John,

Thanks for the reply. I have ARC-OK data coming from the cutter going to a C-10 breakout board's input.

I probably use your subroutine (thanks), but I only do the touchoff, itself, within the subroutine. After it finds the top of the material and zero's out, the sub is over and the main gcode sets the pierce height, fire, delay, cut height, etc.

I don' t think that would introduce any variances by not completing all the above within the sub. ..? I will look into other areas. I was just hoping for a quick fix, I guess.

Thanks...
Paul

Might be false triggering. I changed the input to another pin on the same breakout board and made a few cuts. So far, all ARC-OK timing is good.

Can a single pin on a breakout board go bad?

A single pin that got connected to something nasty might

It may just be that the pin is slightly more susceptible to noise.
Plasma systems are notoriously noisy so its probably not a bad
idea to debounce_all_ inputs

Thanks. I think I could use debounce on a few pins. I get the occational limit switch trip at times. That hasn't happened since adding capacitors across those connections.

Thanks again.

andypugh wrote:

You can debounce in software. Then it's easy to change the time constant:

www.linuxcnc.org/docs/html/man/man9/debounce.9.html

Much simpler (I mean convenient. I'm sure it's not simple!). I should have known you would already have a way to address this...

Thank You

Very nice. I now am using debounce for all inputs. Haven't ran the table too much, but haven't noticed any false triggers so far. Thanks again.

Paul

OK - On the slim chance this happens to someone else looking for a solution, I'm fairly sure I figured out the whole problem. I may have had false arc-ok triggering, but that wouldn't have been the only thing.

Earlier in life, and for another reason, I changed my M66 wait time from 5 seconds to 2 seconds. That worked without any troubles when I ran a high frequency start cutter that could fire the arc while the air was still flowing. I'm now running a cutter that has to shut down the air flow in order to fire the torch. That takes time and the M66 timer must have been timing out a bit too early for this setup.

I am now programmed back to 5 seconds and after 150 pierces, not one delay problem. I kind of figured this out, in part, because I never noticed the first pierce ever moving too soon. I would have guessed all subsequent pierces would have been running into the problem, but maybe I was only noticing the really early (no) delays.

Again - thank for your help...

Paul