Random arc signal lost

Mind you in the second schematic the resistor is between the relay contact and the (input) pin, so it actually adds the resistors value to the input impedance and thus the current is even smaller.
In the first schematic the resistor is in parallel to the input impedance and thus the combined resistance is lower, ergo the current larger.

That's how I see it anyway.

In any case, rods analysis seems entirely plausible and is a good showcase as to why relays have a minimum current rating.

Never had the relay issue and i do use them a lot, but i tend to use quality ones so they never fail.

rodw wrote:

Granted, the 7i96 is different becasue it uses a opto isolated relay on all inputs. Maybe it does need to be in series on that board.

Series resistor would just worsen this issue.

Never had anything from Everlast, so i'll take your word for it.

It's been a busy day at work, I couldnt keep up.

Perhaps my posts were read in the wrong tone. I wasn't trying to say anyone was wrong, I was trying to understand, which while I understand why the resistor must be in parallel with the pull up resistor, and lower resistance ccauses the circuit to pull more amperage, I don't understand exactly where the resistor is in the system and how it interfaces with whats in the MESA card to do that...

At any rate, yes, I'm aware that software doesn't debounce current. However, there is a lot of hysteresis when a relay makes contact, just like a button or a switch, which I'm sure could be seen with halscope if I ever bother to learn it What debounce does do is ignore that hysteresis until it settles down, so LinuxCNC can be SURE whether or not the input is ON or OFF. A switch "bounce" plot example of what needs to be ignored with debounce:



What Phill and I thought was going on (at least with Cody and My Hypertherms, but this will affect all dry contact arc-ok's) is that because there is no debounce on the arc-ok signal by default, but it's a dry contact relay. LinuxCNC is fast enough to read the hysteresis in the switching and as such sees it go from ON to OFF and thinks of this as losing the arc-ok (because technically it did, even though the torch didn't really flame out). For Cody, his table was unusable, he would routinely experience super short torch fires, with a valid arc lost error.

But alas, it's fixed! The hal connections file I made him for his table this morning, which now includes a debounce on the arc-ok input solved his problem. His table works 100% perfect now. And his wasn't intermittent, it just plain didn't work. I mean think about it, it's a switch, we debounce every other form of physical switching, Arc-OK should be debounced by default too.

@Rod, I suspect that your resistor method works because it reduces the hysteresis involved with the Arc-OK going true. Perhaps the .1A of current causes a spark and temporarily "welds" the contacts together... something that probably doesn't happen with 5mA of current (I'd love to see some halscope plots of your method vs a power source that doesnt have a resistor). At any rate, I hesitate to both recommend a resistor that gets hot as a solution, and add it to my table because in addition to the extra heat I'm not sure it's the same for every MESA card, and frankly, I don't fully understand why it works. Debouncing the input, I understand, and it works.

phillc54 wrote:

Glad you got it going, it will be interesting to see if it performs reliably. Did you need to change the debounce value at all.

I think there are two different issues being discussed here, one is using the debounce component to nullify contact bounce and the other is the minimum current required to flow through the relay contacts.

No, no need on this end to change the period from 5. I told him if it comes back at all, to let me know. I do plan to try to grab some halscope plots of my table.

I agree, we are talking too different issues for sure.

For the minimum current through a relay, my albeit short, research said that it's a number manufactures use based around reliability limits and making sure there are guidelines to establish mean time to failure. In our use case, I'm not sure it matters a whole lot, if it did, I would think it would be mentioned in the power source manuals. But admittedly I'd be willing to be proven wrong.