QTPlasmaC Crashing bug report

I would like to start out by saying QTPlasmaC is sweet! All involved in its creation should be commended. I do want to report a bug though, and hopefully get some ideas to fix my issue.

I am updated to version 1.0.5. (The latest at the time of writing this) I was cutting some stuff out tonight and I kept getting an error while cutting that would result in a complete crash of the software.


I switched over to PlasmaC (Not QT) and ran the same file. I got a pause program over there saying that my float switch activated. The big difference is it didn't crash the tool over in PlasmaC. It just paused, and would allow me to resume. So the fact it is crashing instead of pausing is the bug.

Now my question. I think the float switch activating during cut is an EMI issue that I don't have the expertise or equipment or knowledge to track down. Is there a way to deactivate the float switch during the cut, then reactivate it for the next pierce so the controller stops reading any signals coming from it while cutting? If not, is there a way to add debounce or something like that so that false signals don't interrupt? I didn't see anything in the config for that. I probably missed it. I saw the Arc OK debounce.

My controller is the 7i96. It is an awesome controller, but a little too sensitive for it's own good in my noisy, crappy cheap table, environment.

Thanks in advance.

Can you click "Show Details" on the error message and post the result.

There is debounce on the float switch in the connections.hal file.

linuxcnc.org/docs/devel/html/plasma/qtpl...ml#_contact_debounce

phillc54 wrote:

Can you click "Show Details" on the error message and post the result.

There is debounce on the float switch in the connections.hal file.

linuxcnc.org/docs/devel/html/plasma/qtpl...ml#_contact_debounce

Thanks Phill. I will go find the debounce setting in the .hal. I figured you already had my back on this one. Haha

As far as clicking "show details". I tried. Any button I pressed would crash the software. Show details, about, retry, the little x at the top. All attempts resulted with a crash.

Nick7251 wrote:

As far as clicking "show details". I tried. Any button I pressed would crash the software. Show details, about, retry, the little x at the top. All attempts resulted with a crash.

If you were running from a terminal was the a error message in the terminal. If you weren't running from a terminal can you try that.

Is there a way to deactivate the float switch during the cut, then reactivate it for the next pierce so the controller stops reading any signals coming from it while cutting?

This is untested but you may be able to enable ohmic sensing, this then has a hal pin plasmac.ohmic-enable which is only active while probing. You could connect this to a relay and run you float switch signal through the relay contacts.
I would not recommend doing this if you don't have a breakaway switch for safety reasons.

Yeah I can try that. I hope I'll get a chance to try tomorrow. If not it won't be until Saturday until I can get back out there.

Also I don't have a breakaway yet so I won't try the ohmic hack advice you offered. I hope to replicate the error to get you a log file, then fix it with debounce.

It might be worthwhile posting a compressed copy of your config, you can do that from the Parameters tab.

I rebooted my machine last night before coming in the house. I don't know if that has something to do with it, but now when the float switch gets tripped while cutting, it pauses the program as designed, and is no longer crashing. So I couldn't get a crash report.

Now I will play with the debounce and see if I can eliminate the float switch falsely tripping. I don't think it is getting pushed by the material because the THC isn't doing it's job. Not outside of possibilities, but I was looking pretty close last night at that and it didn't appear to be happening.

I've have had a chance to record in the terminal when the tool crashes. I saved the report on my other computer and don't have it available to post. But I know what it says. Basically an arc OK signal lost on initial arc is causing the tool to crash. You can duplicate this by removing your ground clamp and running a job. I had an issue with QTPlasmaC sampling for Arc OK before my hypertherm is giving the signal. I thought this issue was from the float switch getting triggered, but I was wrong.

I have the issue resolved by adding time to the arc ok debounce value. So I don't want to get into that. It is working great now. But the tool still has the bug of crashing if arc ok is lost.

Also I had a crash tonight in the middle of a long job when I hit pause. Luckily it was easy to recover. But non the less the tool crashed and shut down.

Thought I would log my findings if you want to try to duplicate them. Maybe it is just my build, and not a bug at all.