Qtdragon_hd, 2 probes, 1 probe errors out without reason.

I had this post in advanced configs but I think it was the wrong place to put it. I deleted the other and copied over to this section.
thanks.

Hi,   I added a tool height sensor and a 3dprobe on my milling machine. I use Qtdragon_hd on linuxcnc 2.10 and debian 11.   I have used an or2 component and tied it all to the motion.probe-input. In Halshow everything is as it should be. One probe triggers 1 gate and the motion.probe-input. The other probe triggers the other gate and also triggers the motion.probe-input as is expected.  The tool sensor location and function in versa probe work as expected. The 3d probe on the other hand does not.
 
Whenever I use the probe Z down function or the workpiece to table utility function it will search and trigger the motion.probe-input in halshow but also will abort the process and post "Probe tripped during non-probe move." This doesn't make any sense to me as the process was going as expected until the trigger point and the other probe works fine. A probing move was called and the probe triggered.

Any input or similar experiences that may help me find the culprit would be appreciated.

 

I wonder if instead of you seeing the probe moves you were seeing a positioning move?
The routines usually do a feed move to position, then probe. feed moves are slow so may loo like the probe move.
I'm going to push a little change that will display the motion type on the probe screen.
Then you can see if it is rapiding, feeding, or probing.

Also see the end of this as Basic probe a Versa probe use much of the same code.
He is suggesting a change to hard code the 'pull back', which may be related to your question.
forum.linuxcnc.org/qtvcp/46615-probe-basic-in-qtdragon?start=10

I do the same thing ( 2 probe inputs OR'ed in HAL) . The 3d probe isn't exactly professional grade and caused similar problems as what you stated. Adding a bit of debouncing in HAL cleared it up.
Jim

Oh I hope that is the solution. Thanks Jim.

EDIT- I got it to work! Thanks for your input guys. I'm happy i did not give up. Adding the debounce to the Or2 component worked.

I've tried multiple ways from examples to link the or2 components to debounce but it seems i still don't properly grasp netting pins properly. Can you post how to debounce both inputs to the or2 component plz?

I'm giving it a few more shots, I've found other useful example on the forum. I just have a hard time wrapping my head around an input changing names. 

EDIT #2. After taking the day to figure out how to use classicladder I got this to work. If anyone falls onto this thread and wants info just reply here. It look daunting but if I can do it, trust me, anyone can.

I have come to the next impass. When the 3dprobe is unplugged the relay is not energized and therefore triggers the or2 component. I've tried inverting pins (using _not) in hal and reversing the relay contacts from nc to no. It still gives me the same problem.

To remedy this I'd like to use the pin values from the pins list.  io.control.tool-number, value = 99. I'd like to somehow have this value in series with the 3dprobe input pin so that if 99 is not selected the 3dprobe output pin cannot be on. I'm suggesting putting this in an AND2 component with my previous or2.0.0in(3d probe selector)

EDIT1 - On the same principle i have realised that i could possibly use the NOT function with iocontrol.0.tool-number value=99 to invert the 3dprobe pin when it is not plugged in. If 99 is not selected the 3dprobe input cannot be true. This seems a more simple solution because it is exclusive of all values and the truth table has only 1 rung.

I'd like to not get into classic ladder or python yet I'm a linux noob and this hal stuff is already a step up in my programming. I'm definitely not a programmer/integrator by trade. Thanks for all the help.

This is my current or2 setup for clarification.

#  ---probe signal or tool height sensor---
loadrt or2 count=1
loadrt debounce cfg=2
addf or2.0  servo-thread
addf debounce.0 servo-thread
setp debounce.0.delay 50

#

---

3d probe signals

---

net db-3dprobe-in debounce.0.0.in [HMOT](CARD0).gpio.010.in_not
net 3dprobe-in debounce.0.0.out
net 3dprobe-in => or2.0.in0

#   ----Tool setter

---

net db-toolsetter-in debounce.0.1.in [HMOT](CARD0).gpio.007.in_not
net toolsetter-in debounce.0.1.out
net toolsetter-in => or2.0.in1

net 3dprobe-or-toolsetter <= or2.0.out => motion.probe-input

Your probe has a relay?
There's no need to debounce each OR input. Just debounce the output. Here's an excerpt from my postgui.hal
qtdragon already has code to prevent probing if the defined probe tool isn't loaded in the spindle.
Also, it won't probe to a touchplate if no tool loaded.
Jim
 

Hey thanks for that snippet. I love to learn how to do things in more optimal manners. I will change it asap.