Baffling Issue With Torch Not Firing When It Should And Firing When It Should'nt

Not only am I a "newbie" to LinuxCNC, but I am a convert from the Land Of OpenBuilds/ Arduino... so please bear with me, ok?

I have built a 60x54 inch plasma table which used to be run by an Arduino Mega 2560; after becoming disillusioned with the limitations of GRBL (like how difficult it is to add a THC that actually works, it's small sub-set of G-codes & virtually non-existent M-codes), I decided to make the switch to LinuxCNC. 
I re-built an old Dell Optiplex 755 (Core2Duo, 2.8 gHz) running Debian 12 with 4 gb of RAM; the kernel is the 5.4.258-rtai-amd64, and I am running LinuxCNC 2.9.3 from the linuxcnc repository. 
The Dell has an on-board parallel port (0x378 IRQ 7) and a ASix Electronics A91100 PCIe parallel port card (0xdcf0 IRQ 11); they are both recognized and functional.  Surprisingly, the card did not need specific drivers -- I simply added a conf file in the /etc/modules-load.d directory setting the port addresses & IRQ's and it worked perfectly.
The two parallel port break-out boards are SainSmart ST-v3 5-axis parallel controllers; you can see from my machine backup .HAL file how they are wired, physically.
My plasma cutter is an Everlast PowerPlasma 82i, and I am using a "brain-dead" THC designed by "Swolebro" (Arduino Mega 2560 based) and QtPlasmac running in Mode 2 (just up-down signals from the THC).

A backup of my machine is attached to this post for review.

My problem is that the torch triggers when it shouldn't:
1.  On plasma power-on if LinuxCNC is already running;
2.  On LinuxCNC power-on if the plasma is running when LinuxCNC loads;
3.  On computer power-up if the plasma is running when the PC starts;
4.  After cycle start, after the torch initially fails to fire at pierce height on an M3 S1 G-code, it fires when I press Cycle Stop.

The torch WILL NOT trigger when:
1. Cycle is started, torch probes, then rises to pierce height but the torch will not fireon an M3 S1 G-code -- but the cycle continues to run motion;
 
However, the torch will fire perfectly when Torch Pulse is pressed.

My plasma switches ground from the plasma for the torch-on, and my wiring is "Torch On -" wire from the plasma input to relay common and "Torch On +" wire from the plasma input to relay "NO" terminal.  The fact that Torch Pulse works perfectly tells me that my wiring is correct.

A run of HAL Scope show that plasmac.torch-on was not being switched at all -- it was a flat line throughout the M3 S1 command until I hit Cycle Stop; only then did it ramp, at least until the Everlast's 3-second rule shut the torch down.

Perhaps one of you "gurus" can figure out what the problem is?  That would really be appreciated!

John Carter
CCW Transport Services Inc.

 

I thought the relay on those 5 Axis BOBs was pin 17, not 14

PCW wrote:

I thought the relay on those 5 Axis BOBs was pin 17, not 14
 



 

Not according to this pin-out diagram I found... If I had it on the wrong pin, I wouldn't think that the torch would fire on "Torch Pulse" at all.

John
 

tommylight wrote:

1. Should happen ONLY if the torch is on in LinuxCNC, otherwise something wrong
2. Happens only if the output is inverted, other possibilities, skipping for now
3. That is normal with parallel ports, see below
4. Again, only if output pin is inverted
If it works with Torch pulse .... well that throws everything out of the window as it makes no sense compared to some above points, or points to some wiring issues or bad interference/potential difference
Things to fix/check:
M3 S1 must also have $0 so it becomes
M3 $0 S1
Parallel ports send status signals on powering up the PC, so that will fire the torch and there is not much to do with built in ports since you are using a BOB, without a BOB it is easy to check what output pin does not change state during boot and use that pin for torch on.
Add on parallel port usually do not send signals at all on boot, so you have the option of using the second card for torch on with BOB
Try using the BOB wired to add on card for torch on, edit the hal file accordingly, do some tests and report back
 

Well, tommylight, no easy fix here I guess; I did as suggested (switched the torch over to the other board's relay & switched it in the HAL file) and... same thing.
I'm curious, though, about your statement about pin 14 being inverted... if that were the case, would there be a way to reset it to a non-inverted state, seeing as it was never intentionally inverted to begin with?  And how did it get inverted if it wasn't intentionally inverted in the HAL file?  What statement would I use to do so?
As for the G-code -- below is a snippet from the test cut file I am using; it was produced by the Autodesk post processor in Fusion 360 (I love that program, but not enough to pay for it!):

(1001 CUT TEST)
(MACHINE)
(  VENDOR JDS GARAGE)
(  MODEL PLASMA TABLE)
(  DESCRIPTION THIS MACHINE HAS XY AXIS ON THE TABLE AND Z AXIS ON THE HEAD)
N10 G21
N15 G90 G40
N20 G17 G91.1
N25 G64 P0.254 Q0.254
N30 M52 P1.
N35 M65 P2.
N40 M65 P3.
N45 M68 E3 Q0.

(2D PROFILE3)
(

---

)
(- NORMAL OPERATION. -)
(

---

)
(PLASMA CUTTING)
(THROUGH CUTTING)

N55 M66 P3. L3 Q1.
N60 F#<_hal[plasmac.cut-feed-rate]>
N65 G0 X84.66988 Y19.8734
N70 M3 $0 S1
N75 G1 X89. Y22.3734
N80 Y29.
N85 X71.
N90 Y11.
N95 X89.
N100 Y22.3734
N105 Y22.8734
N110 X84.66988 Y25.3734
N115 M5
N120 G0 X42.23084 Y17.68223
N125 M3 $0 S1
N130 G1 X46.49632 Y20.291
( End of snippet)

Ahh, that is the Sainsmart model without the 0-10V output so
has a different pinout.

Is the relay on when the machine is off? That's an issue with the
other model (and the output state is not guaranteed a power up)

Tommylight, before we get into that, I want to add some information that might give you a little more insight.

After switching the torch to the second card, I noticed that the board LED's for RELAY, IN5 and IN4 on the second card were lit; the RELAY LED on the primary card was also lit. Doesn't that indicate that SOMETHING is sending a high signal to both relays? The IN4 and IN5 are inconsequential -- those are the UP & DOWN pins from the THC. But both relays being powered with no running command or even with LinuxCNC running -- not normal.

Also, after switching the boards, I decided to try to run that program all the way through -- didn't work. The torch probed, didn't light off, moved on, then came on halfway through the 2nd side of the first square hole -- went out in the middle of the 4th side; came on again about halfway through the large circle but went out about 90 degrees further on.

It's almost as if there is something delaying the G-code being actually carried out...

John

@PCW
Do you mean with the LinuxCNC machine off? Yes -- I was just telling Tommylight that I noticed that the RELAY led on both cards is lit even without LinuxCNC running.

Is there a fix for that?

tommylight wrote:

I was pretty sure something is amiss from your detailed explanation, so now we go into "eliminate" mode:
1.
-Plasma OFF
-remove both parallel cables from the BOB's
-BOB's powered OFF
-turn ON plasma
Does it start?
2.
-same as above but BOB's powered ON
result?
3.
-plasma OFF
-plug one parallel cable
-BOB's OFF
-turn plasma ON
-same with the other cable, ONLY 1 cable at a time
4.
-same as above with BOB's powered ON and one cable at a time
5.
Same as above with BOTH cables and BOB's powered OFF then with BOB's powered on
 

OK -- the results are in...

With both cards plugged in but power off == plasma fires when powered on;
With the primary card unplugged (the one the torch is NOT on) == plasma fires when powered on;
With the primary card plugged in and the secondary card (the one the torch IS on) unplugged == plasma DOES NOT fire when powered on;

Same results with one or both cards powered on -- the torch only fires when the card it is on is connected, powered or not.

John