Plasmac.comp 2.9.3 and on - gets Stuck in wrong state and stops

[rodw-au]

This forum thread confirms this is a rare issue but it has been around for a long time when I reported it here recently.
https://forum.linuxcnc.org/plasmac/55687-2-9-3-stuck-in-wrong-state-and-stops#324665
I thought the bug report should move to the official issues register for broader consideration.

ISSUE: Sometimes, Plasmac freezes. Moving the float switch by hand seems to clear the error and the cut proceeds.

The customer has an IT Savvy brother who investigated this in depth and reports:

I added a whole bunch of debugging logs to my plasmac code and recreated the situation.
I thought there was an issue in qtplasmac_handler but all this happens in plasmac.comp

the simulator isn't super fast like the machine, so I could be creating timing issues etc, but the fact that it's mirroring your machine exactly makes me feel better about that.

On my simulator I have a control panel that I made that injects inputs, because I have no hardware (obviously!).

Obviously these voltages need conversion, but that's not important to me so I just leave them as raw!

Actions on the simulator:
Homed the machine and enabled the torch
Started a job
While the thing was moving to start the cut, I set the ohmic volts right up
When it tried to do the ohmic sensing it failed with the message "pierce height would exceed Z axis maximum limit". This stopped the machine
Pressed the pulse button. The button shows the countdown timer, but the torch does not fire
Triggered the float switch
Pressed the pulse button. The countdown timer shows and the torch fires

Diagnostics:
The IDLE state code has a whole bunch of conditional statements at the start of it.

1. If stuff...
2. ...else if((tool == CUTTING || tool == SPOTTING || probe_test) && (stop_type == NONE || stop_type == WAIT) && homed)
3. ...else if(!program_is_paused && stop_type == PAUSE)
4. ...else if(torch_pulse_start && torch_enable && !breakaway && !float_switch && !ohmic_probe)

On face value, it should be able to pulse the torch
However, when it stops in this way (and apparently other ways too), the state is going:
PROBE_HEIGHT (to find the plate to start cutting)
program_pause = TRUE;
stop_type = PAUSE
MAX_HEIGHT (because I mucked with the ohmic sensing)
END_CUT
IDLE
Then when it comes around in the idle loop, it's hitting "else if(!program_is_paused && stop_type == PAUSE)". This is then setting the stop_type back to NONE
Is there a Timing issue here? program_is_paused is a signal coming in, presumably in response to the out pin program_pause

THEN, when you push pulse, it ends up hitting condition No. 2 from my list above and therefore will not pulse.
The values used in condition 2 at this time are
tool: 1, probe_test: 0, stop_type: 0, homed: 1

Float switch hack:
If you trigger the float switch after all this, the stop type changes to 3 (PAUSE).
Ultimately that means that condition No. 2 from the above doesn't get triggered and it's free to run the pulse.
The values for condition 2 this time around are:
tool: 1, probe_test: 0, stop_type: 3, homed: 1

Ideas:
If you just wanted to hack the pulsing, that would be easy enough to bodge up by adding "!torch_pulse_start" to condition 2 or re-ordering the conditions
Maybe alter condition 3 or the handling therein to consider program_pause to cater for this weirdness - dunno, you'd have to be super careful mucking with that! Or even add a flag that stays for a few iterations to buy some time

Rod's thoughts (me)
I wondered if my ohmic3.comp used for Ohmic sensing had anything to do with this issue and I reviewed it and concluded it was bug free.
Ref: https://github.com/rodw-au/showstopper/blob/master/components/ohmic3.comp
Whilst not in the Linuxcnc collection, a lot of people have used this component for a number of years without issue.
The customer confirmed this with: I agree with Rod that this isn't anything to do with his ohmic stuff. He went on to say:
I just grab the ohmic slider and ramp it all the way up because I know it triggers the fault.

Rod's Further Evaluation
Both ohmic3.comp and plasmac.comp use motion.motion.type. I wondered if it were possible that a bug in the core code generated spurious data here. However when I reviewed both ohmic3.comp and plasmac.comp neither component uses this value for anything to do with probing. plasmac.comp just uses this value to deterimine if the machine is traversing (eg. rapids G0)

It would be great if this detailed information would help nail this bug.

[phillc54]

https://forum.linuxcnc.org/plasmac/55687-2-9-3-stuck-in-wrong-state-and-stops#324725

[snowgoer540]

Closing this issue - Root cause identified as modified HAL configuration

After reviewing the detailed analysis provided and cross-referencing with the forum discussion, this appears to be caused by user modifications to the HAL configuration rather than a bug in plasmac.comp.

Root Cause Analysis

The issue stems from disconnecting the critical feedback loop between halui.program.is-paused and plasmac.program-is-paused. This connection is essential for proper state machine operation. Further, I can duplicate the torch pulse not working after hitting the probing error by using halshow to "unlinkp halui.program.is-paused".

Normal Operation:

1. plasmac detects an error condition (e.g., "pierce height would exceed Z axis maximum limit")
2. Sets program_pause = TRUE (output pin)
3. LinuxCNC pauses the program and sets halui.program.is-paused = TRUE
4. This feeds back to plasmac.program-is-paused (input pin)
5. State machine properly handles the paused state

With Broken HAL Connection:

1. Steps 1-2 occur normally
2. LinuxCNC may pause, but the feedback to plasmac is broken
3. plasmac.program-is-paused remains FALSE
4. This condition in IDLE state executes incorrectly:

   }else if(!program_is_paused && stop_type == PAUSE){
       stop_type = NONE;  // Clears pause state prematurely

5. State machine loses track of the pause state
6. Subsequent torch pulse attempts fail because the cutting condition matches first

Why the "Float Switch Fix" Works:

Triggering the float switch re-establishes a pause state, temporarily masking the broken feedback loop.

Solution

Restore the proper HAL connection:

net program-is-paused halui.program.is-paused => plasmac.program-is-paused

Conclusion

While the detailed debugging work was thorough, this issue is caused by removing essential HAL connections that are required for proper plasmac operation. The plasmac component is functioning as designed - it requires the complete control loop to be intact.

Modifying HAL files should only be done with full understanding of the signal relationships. Critical feedback loops like program pause/resume status should not be disconnected.

Closing as not a bug - user configuration issue.

[andypugh]

It is possible to tell if a pin is connected.
It's rare to bother, but if it is critical, then there may be an argument for it.
I don't think that the .comp can tell what it is connected to.

https://sourceforge.net/p/emc/mailman/emc-developers/thread/20101030161340.GA17536%40unpythonic.net/#msg26519176

[snowgoer540]

Checking for these types of connections is in fact something Phill and I have discussed in the past. Admittedly at the time it was with reference to the GUI checking to make sure the pertinent connections were all made, and of course that only works if you're using the component with said GUI. I didn't know about the trick for checking at the RT component level.

Either way, we decided against it. These particular connections are made by files the average user wouldn't know or care about messing with. We concluded that for these types of critical connections, you'd have to deliberately unlink them and so it's assumed that anyone who messes with them knows what they're doing ... or at least thinks they know what they are doing.

It's also inevitable that someone would argue a legitimate need, and any such check would yell at them every time it's mucked with.

[rodw-au]

Thanks for the detailed clarification. QtPlasmac is arguably the most complex GUI that is included with LinuxCNC. Unlike most other GUI's, it is based around a paradigm followed by the developers, (Phil and Carl). This paradigm does not suit all machines or use cases. Unlike other GUI's, its very difficult to modify a QTplasmac config to suit a use case the developers have not envisaged when developing their paradigm. Emerging examples of this include ethercat controlled plasma machines that have many more cutting parameters available for the user and a recent analog controlled Hypertherm machine that can adjust cutting current in real time which should provide better cut quality when cutting corners if implemented as Hypertherm intended (A plasma machine is a constant current device so when cutting corners, moving from controlling voltage to controlling current as the process control variable is highly desirable). Another example is the use of capacitance height control and probing. While mainly for laser cutting which has been implemented with QTplasmac, it could be used for plasma cutting and it would obsolete the tried and tested touch off routine because height is measured accurately with out the need to touch the material. This configuration error subject of this issue was because a high end pendant control was integrated into the config.

It would be appreciated if the QTplasmac docs were extended to cover the critical hal pins it requires so users who push the boundaries beyond the expected paradigm have some guidelines.

[snowgoer540]

This is not a documentation or "paradigm" problem - the LinuxCNC docs, man pages, HAL files referenced in the INI file, source code, and tools like halcmd already provide the answers. We have documented it; we can’t read or understand it for you.

The entitlement required to profit from thousands of hours of volunteer work while simultaneously criticizing it and asking for more is genuinely remarkable.