qtplasmac lost arc = turn off and on again?

Hi all, I may be missing something, but if I lose the arc ok on piercing I can't seem to get another arc until I quit out of qtplasmac and come back in. This is true for resuming the program, or starting a new cycle. Even turning on 'ignore ok' doesn't get the arc back until closing and reopening qtplasmac. Same for toggling the torch enable, dismissing errors, etc. Any ideas?

Have you tried waiting a full minute, to see if arc occurs after a full 60 second wait? This is the behavior I had. It's unnerving, waiting for a full minute of complete silence, then a sudden arc blast again! Made me jump every time.

Fortunately, there is an easy fix for this (if your problem is the same as mine). Set the Retry Delay to a more reasonable number. I have no idea why mine was set to 60 by default. I changed to 2 or 3, forget which, and now retries happen much more quickly after a failed pierce.

The Retry Delay setting is found in the Parameters tab.

Retry delay was indeed 60 - I bet you're right!

I see what's causing the issue in the code.  We will push a fix after a bit. Fix pushed.

For anyone who runs into this, just change the retry delay in the arc section of the parameters tab.

Thanks for the inadvertent bug report

snowgoer540 post=259510 userid=26427

Thanks for the inadvertent bug report

Ha, well I thought of reporting this before but figured maybe I was the only one running into it.

I noticed yesterday that the official docs show a Retry Delay of 60 in the screenshot, here: www.linuxcnc.org/docs/devel/html/plasma/...ml#qt_parameters-tab

Thanks for the fix!

Was the original intent for this function to address duty cycle limits? Would explain making it long.

caretech wrote:

I noticed yesterday that the official docs show a Retry Delay of 60 in the screenshot, here: www.linuxcnc.org/docs/devel/html/plasma/...ml#qt_parameters-tab

Good catch, I updated that as well.

Mud wrote:

Was the original intent for this function to address duty cycle limits? Would explain making it long.

I believe the intent for having an adjustable retry delay had to do with the fact that some power sources wont retry immediately (if a delay of a certain length hasn't elapsed). Hypertherm for example, requires no delay to attempt to restart the arc. Others do.

The code in the handler defaulted this parameter to 0 if it was not present in the preferences file (which it never is upon the very first run of the GUI). The issue was that the minimum value for the spinbox you see in the GUI was 1. When that happens, qtvcp apparently defaults to the maximum value, rather than the minimum value. The maximum value for the spinbox was set at 60.