-- SOLVED -- Inconsistent Probe Performance...

I'm stumped -- I just cannot get my probe to work correctly.

Attached is my config archive for review.

My system is a Dell Optiplex 7040 Core-i7, 32 gb RAM, 512 gb SSD, 2 tb hard drive
MosChip PCI 9865 Parallel Card (0xd010) Port 0 Configured As Output
Asix Electronics Corporation AX99100 PCIe Parallel Card (0xb010) Port 1, Configured As Input
Debian Linux 12.7 (Bookworm), Cinnamon Version, Kernel 6.9.7+bpo-rt-amd64
LinuxCNC v2.9.3 compiled from source to DEB then installed through Synaptic.

The table is a DIY using steppers, a SainSmart controller card / breakout board on Port 0, and a bare breakout board with pull-down resistors on Port 1 pins 2-9 for inputs from my proximity limit switches; each axis has a home-min switch and a max switch (8 switches total).

The table homes perfectly.  When I do a probe test right after homing, it works like expected -- dropping to probe height, slowing to contact, stopping for a few seconds, then rising to pierce height until the timer expires.  When I move to a work coordinate position, the probe test again works perfectly.

Unfortunately,  that all blows up when I attempt to run a G-Code program (example below).  As you can see in the attached video, the torch drops, makes contact, then immediately rises to safe height -- the program pauses with the error "pierce height would exceed Z axis maximum limit".

I have tried all sorts of values, but nothing seems to do any good; I don't see anything in the program that would cause it.

Perhaps one of our "resident Guru's" can give me some insight into this & help me get it to probe properly?

Config Backup:   
Picture Of Z-Axis:   
YouTube Video of Z-Axis Motion During G-Code Program:  youtube.com/shorts/k12akteEZmI?feature=share

(Drawing name : Air Connection Plate For Lowboy Neck v5)
(Program Name : AirConnector)
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)

N50 M190 P1.
N60 F#<_hal[plasmac.cut-feed-rate]>
N65 G0 X111.149 Y67.376
N70 M3 $0 S1
N75 G1 X109.362 Y72.045
N80 G3 X105.479 Y75.195 I-4.67 J-1.788
N90 X95.472 Y26.873 I-3.886 J-24.392
N95 G1 X95.999 Y26.739
N100 X95.999 Y23.749
N105 X107.299 Y23.749
N110 X107.299 Y26.224
N115 X107.299 Y26.765
N120 X107.822 Y26.901
N125 G3 X100.495 Y75.479 I-6.229 J23.902
N130 X96.281 Y72.789 I0.222 J-4.995
N135 G1 X93.976 Y68.352
N140 M5
N145 X171.948 Y55.76
N150 M3 $0 S1
N155 G1 X169.448 Y60.09
N160 G3 X165.118 Y62.59 I-4.33 J-2.5
N165 X165.118 Y38.99 I0 J-11.8
N170 X165.118 Y62.59 I0 J11.8
N175 X160.266 Y61.547 I0 J-11.8
N180 X157.347 Y57.487 I2.056 J-4.558
N185 G1 X156.848 Y52.512
N190 M5
N195 X44.841 Y55.743
N200 G0 X44.841 Y55.743
N205 M3 $0 S1
N210 G1 X42.341 Y60.073
N215 G3 X38.011 Y62.573 I-4.33 J-2.5
N220 X38.011 Y38.973 I0 J-11.8
N225 X38.011 Y62.573 I0 J11.8
N230 X33.16 Y61.53 I0 J-11.8
N235 X30.24 Y57.47 I2.056 J-4.558
N240 G1 X29.742 Y52.495
N245 M5
N250 G0 X-7.53 Y66.216
N255 M3 $0 S1
N260 G1 X-3.2 Y68.716
N265 G3 X-0.7 Y73.046 I-2.5 J4.33
N270 G1 X-0.7 Y101.6
N275 X-0.7 Y102.3
N280 X203.2 Y102.3
N285 X203.9 Y102.3
N290 X203.9 Y38.1
N295 G2 X165.1 Y-0.7 I-38.8 J0
N300 G1 X38.1 Y-0.7
N305 G2 X-0.7 Y38.1 I0 J38.8
N310 G1 X-0.7 Y73.046
N315 X-0.7 Y78.046
N320 G3 X-3.2 Y82.376 I-5 J0
N325 G1 X-7.53 Y84.876
N330 M5
N335 M5
N340 G0 X0 Y0
N345 M30
 

My guess is it might be the lack of debouncing on critical inputs.

The dbounce components are loaded but the raw parallel port signals
are routed to Plasmac and the dbounce component inputs, but the signal
paths should be:

parallel port pin --> dbouncex.in --> dbouncex.out --> Plasmac

That is you have for example:

net plasmac:float-switch <= parport.0.pin-12-in-not
net plasmac:float-switch   => db_float.in

when it should be something like:

net raw-float-switch <= parport.0.pin-12-in-not
net raw-float-switch   => db_float.in
net plasmac:float-switch   => db_float.out

or the equivalent:

net raw-float-switch <= parport.0.pin-12-in-not => db_float.in
net plasmac:float-switch   => db_float.out

also the debounce times were not set (so would default to 5 servo-thread periods so 5 ms)


 

We kinda do things in a convoluted way, the dbounce component pins are connected by qtplasmac_comp.hal which is in hallib.

qtplasma_comp.hal:


The times should be set in custom.hal but for some reason in this config they are in custom.hal.new_values and probably should be copied to custom .hal for convenience.

custom.hal:


custom.hal.new_values

OK did not see that hal file (and grep'ed for the db.out pins and did not find them in the supplied hal files)
back to square one I guess...

Try changing the line below this in your hal file:
from:


to:

phillc54 wrote:

Try changing the line below this in your hal file:

# ---JOINT ASSOCIATED WITH THE Z AXIS---

from:

[code]net plasmac:axis-position joint.2.pos-fb => plasmac.axis-z-position

to:
[code]net plasmac:axis-position joint.3.pos-fb => plasmac.axis-z-position

[/code][/code]



 

Ahhh... I never noticed that, but it makes sense.

When I created that machine config in StepConf, it did not insert a [JOINT_2] block in the [AXIS_Y] block -- I had to manually copy & paste the [JOINT_1] block to add a [JOINT_2] block. I didn't notice that it had linked the Z axis to [JOINT_2] over in the .HAL file.

I'll give that a try in the morning, but that's probably the problem.  Thanks a bunch!!

PCW wrote:

My guess is it might be the lack of debouncing on critical inputs.

The dbounce components are loaded but the raw parallel port signals
are routed to Plasmac and the dbounce component inputs, but the signal
paths should be:

parallel port pin --> dbouncex.in --> dbouncex.out --> Plasmac

That is you have for example:

net plasmac:float-switch <= parport.0.pin-12-in-not
net plasmac:float-switch   => db_float.in

when it should be something like:

net raw-float-switch <= parport.0.pin-12-in-not
net raw-float-switch   => db_float.in
net plasmac:float-switch   => db_float.out

or the equivalent:

net raw-float-switch <= parport.0.pin-12-in-not => db_float.in
net plasmac:float-switch   => db_float.out

also the debounce times were not set (so would default to 5 servo-thread periods so 5 ms)
 

I'm using proximity switches, so there is no appreciable bounce.  With the exception of the line you pointed out, this is the same HAL code I have used in several iterations of this machine -- and I've never had a problem with a lack of debouncing before.
I'm sure that the wrong joint assignment is the problem -- I'll know in the morning for sure, but the previous iteration of the machine worked just fine before I added the THCAD-2 to the machine.

phillc54 wrote:

Try changing the line below this in your hal file:

# ---JOINT ASSOCIATED WITH THE Z AXIS---

from:

[code]net plasmac:axis-position joint.2.pos-fb => plasmac.axis-z-position


to:
[code]net plasmac:axis-position joint.3.pos-fb => plasmac.axis-z-position

[/code][/code]
 

I couldn't wait -- I went out to the shop & made the change tonight.

Problem solved -- it ran the whole G-Code program just like it should (no plasma though).  I'll try the actual cut tomorrow, but I'm confident that the issue is solved now.

Again, many thanks!!!

ISSUE SOLVED NOW -- PROBING WORKS JUST AS IT SHOULD.