Random arc signal lost

phillc54 wrote:

snowgoer540 wrote: 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..

It would be nice to see a before and after from Cody's table.

What, my table isn't good enough?! :laugh:

Yea, I agree. I will have to learn halscope so I can teach him. The challenge is that he has almost 0 internet service at his place, and he's in Michigan ~8-9 hours away from me haha.

So do you think that debouncing the arc-ok should be done by default?

Also, I'm not sure if it got lost in the relay/resistor talk, but Rod confirmed that it's likely his Ohmic component that doesnt listen to the Ohmic Enable check box as his table doesnt have it because he's several iterations behind.

I guess that leaves the MDI stuff and a log file generator if you're so inclined.

snowgoer540 wrote:

phillc54 wrote: It would be nice to see a before and after from Cody's table.

What, my table isn't good enough?! :laugh:

Just that his seemed to consistently fail...

Yea, I agree. I will have to learn halscope so I can teach him. The challenge is that he has almost 0 internet service at his place, and he's in Michigan ~8-9 hours away from me haha.

Oh, that is a bit difficult then

So do you think that debouncing the arc-ok should be done by default?

Maybe a good idea for new configs...

Also, I'm not sure if it got lost in the relay/resistor talk, but Rod confirmed that it's likely his Ohmic component that doesnt listen to the Ohmic Enable check box as his table doesnt have it because he's several iterations behind.

Yes, I did see that.

I guess that leaves the MDI stuff and a log file generator if you're so inclined.

Only a short list then.

phillc54 wrote: Just that his seemed to consistently fail...

Yea, I'd love to plot that table. Mine did it sometimes, but not nearly as consistent as his.

Oh, that is a bit difficult then

I think the real difficulty is getting halscope to work lol

Maybe a good idea for new configs...

And at least one more config that's existing

Yes, I did see that.

Ok cool

Only a short list then.

Haha, sorry, I'd say I'll try to keep the new ideas to a minimum, but I already had at least one or two more. On the bright side, it seems like a lot of bugs are ironed out! Curious, when 2.8 is released, will you continue to develop against 2.8, or will you move to developing for 2.9?

snowgoer540 wrote:

phillc54 wrote: Only a short list then.

Haha, sorry, I'd say I'll try to keep the new ideas to a minimum, but I already had at least one or two more. On the bright side, it seems like a lot of bugs are ironed out! Curious, when 2.8 is released, will you continue to develop against 2.8, or will you move to developing for 2.9?

Depends on the feature. Because PlasmaC is only a machine config and not core LinuxCNC code then mostly it will be 2.8 + master. Bugs fixes definitely for both and new features for both unless it is reliant on something different in master. 2.8.0 is only the first 2.8 release, there will be others.

phillc54 wrote:

snowgoer540 wrote:

phillc54 wrote: Only a short list then.

Haha, sorry, I'd say I'll try to keep the new ideas to a minimum, but I already had at least one or two more. On the bright side, it seems like a lot of bugs are ironed out! Curious, when 2.8 is released, will you continue to develop against 2.8, or will you move to developing for 2.9?

Depends on the feature. Because PlasmaC is only a machine config and not core LinuxCNC code then mostly it will be 2.8 + master. Bugs fixes definitely for both and new features for both unless it is reliant on something different in master. 2.8.0 is only the first 2.8 release, there will be others.

Fair enough, that makes sense. Never really been paying attention to the release cycle, so I didnt know they went 2.8.0, 2.8.1, etc. I figured they released 2.8 then went on to working on 2.9.

I do agree that ArcOK needs a bit of dead time and i did mention it somewhere regarding PlasmaC.
This is valid for both mode 0 and mode 1, due to several reasons:
When piercing thicker material the voltage and current will vary wildly so both modes will see ArcOK going on and off very quickly due to material being removed at an unpredictable rate.
Also depending on the plasma source, some will not have any capacitors on the output so will wary a lot, some do have them so they are less prone to voltage variations, while the new-ish inverter ones have capacitors abut also have automatic current regulation so until that kicks in there will be some variations in voltage.
In "my" config (again someone else started that config) i have a 0.1 second delay for the ArcOK and that has proven plenty even for THCAD using a parallel port for over 7 months, it never fails in mode 0 generating the ArcOK signal from the voltage.

I am thinking of adding the debounce to new configs only as I am a bit apprehensive about trying to modify existing <machine-name>_connections.hal in case any existing users have added debounce to any other inputs.

phillc54 wrote: I am thinking of adding the debounce to new configs only as I am a bit apprehensive about trying to modify existing <machine-name>_connections.hal in case any existing users have added debounce to any other inputs.

I agree. But how about just putting a note in the manual with the code and saying where it has to be put (if that's possible)

Isn’t possible to put warning message with check box to don’t show again about the old debounce config?

Edited and added more info to the above post, sorry had to attend installing the roofing on the "hut" or "tent" or whatever that thing outside my shop is called.