Random arc signal lost

rodw wrote:

phillc54 wrote:

Well I can only act on the feedback I get.

Yeh, I know and you go above and beyond. No other LCNC developer has gone as far as you have building a config.

phillc54 wrote:

Just because you have not experienced contact bounce doesn't mean that it does not exist.

Yes but does it exist with an arcOK signal? Or have the manufacturer's already dealt with it? I keep discovering stuff that Hypertherm already know.

phillc54 wrote:

I have never experienced contact wetting issues but I do agree that it does exist.

Same here. It was not a big issue on my machine but it seemed to be a bigger issue for the Hypertherm users so I did something about it becasue they had bought hardware on my recommendation. It still needs some work and bringing into line with recent changes to plasmac. But right now I just don't have the time to tidy it up. (It works for me)

@Snowgoer, you have done an amazing job debugging Plasmac so don't give up!

@Rod, to your point, it does make me want to take my Hypertherm apart and trace the wires for the Arc OK to the circuit board, and see if the board has any kind of circuitry on the contact side of the relay, or if it really is just an interface with the relay contacts that is provided to the CPC port. I guess in fairness, I am making an assumption that it is. But I also think that by the same token, if they were worried about contact oxidation and min current, they would have very specific requirements about what voltages, etc need to be run through that circuit. I may take her apart this weekend and have a peek.

I honestly love working on my table, and working on Plasmac. It's one of the things I enjoy most in the garage. Even when we have spirited debates

For the record, I value everyone's opinion on here, and I really appreciate everything everyone does to move this stuff forward!

rodw wrote:

snowgoer540 wrote:

As stated, I suspect the resistor reduces the hysteresis present.

But that statement ignores the physics and the maths.

The main thing is for you, you have a result and your table works. But my table does not require it. Thats the thing we are all our own system integrators. Its up to us to solve our own problems. We don't need over regulation of our builds.

I honestly can't remember when that plot was taken. I sold my Everlast years ago. But I do know the resistor was not an instant fix. It took a few goes to burn through the oxide. Then it never missed a beat!

The resolution of halscope is reduced by the number of signals monitored. I shared that becasue It is already in the Linuxcnc docs. Halscope is limited to 1 ms resolution (or whatever your servo thread is set at). Anything that happens between cycles through the servo thread is of no interest becasue Linuxcnc won't see it.

I've often said plasma is not an entry level sport. its bloody hard! There is no place for assumptions or guesses. We need hard data.
I found that the data accumulated from one 6" cut took a week to evaluate and understand. Sometimes, I found that lead to another whole range of testing to test a further hypothesis. Sometimes my hypotheses was right, sometimes it was wrong. If I suspect something, I test for it. Then I know.

At the end of the day, I'm really trying to learn as much as I can. I suspect that we are both right for at least two reasons:

First, dry contact switches definitely have bounce. I've been reading on debounce as much as I can, and I have learned that a lot of debounce is measured sub 1ms, in the ns range, and sometimes even us (I dont know how to make the special symbol for pico lol) for the really really good switches. I agree that anything that happens between cycles may be of no interest to linuxcnc, but ONLY IF the state change between cycles... Meaning I wonder if when problems occur it's because the ripples span the cycles and cause issue. I guess that's why they usually refer to it as "noise", because it's unpredictable and annoying (in the noisy state, we can predict the noise itself here).

Second, I've learned through the reading that just loading the circuit can in fact reduce the electrical noise caused by the bounce that is present.

In your case, I think it's likely that the increased current burnt the oxidation layer as you stated, and worked to reduce the bounce present enough that your table was very happy, and decided to go to work

We don't need over regulation of our builds.

Not sure what this means.

Anything that happens between cycles through the servo thread is of no interest becasue Linuxcnc won't see it.

True, but that is only relevant if there is no contact bounce at the time of the signal read.

FWIW I do know that years ago we used to set a 50uS debounce for all mechanical contacts.

phillc54 wrote:

True, but that is only relevant if there is no contact bounce at the time of the signal read.

Phill, you always have a way of saying what I'm thinking much more concisely. I have to figure out how you do that.

FWIW I do know that years ago we used to set a 50uS debounce for all mechanical contacts.

This jives with what I have been reading. Even at 5ms, I'm not convinced .005s is enough to be noticeable in cut quality.

rodw wrote:

If you want a turnkey Linuxcnc plasma system, there is always Tormach.

Or Toma CNC !
Rod, you letting me down,

The proposed docs for the proposed debounce:
home.iprimus.com.au/phillcarter/plasma/p...ml#_contact_debounce
Note that this will only affect newly created configurations.