Probe /Tool setter trip stops program run ???

OK no luck here. It appears that Tormach removed the library as I get a no such file or directory error when trying to load the function.

Another one of those " Close but No Cigar" functions. My PP file folder is getting full of them now.

SO back to looking for a function to compare to to block the probe pin when not probing.

( TP

It would be very trivial if you used a custom component but I suspcet halcomp is removed from your systemmto. Maybe you can create the hal file on another machine
Something like this in one line of code

You could also take the gcode approach using a digital input M62-M65 and and2. This is simple and works well

Oops I missed a ; at the end of a line

Do custom user M-codes (M100-199) work in Path Pilot? If they do you could set up a couple custom M-codes that link and unlink the hal pin for the probe input.

I looked at mcodes and subs and physical relays,etc but it ends up as something you have to remember to turn on and off and OLD code will not work without mods.

It could be done with a and2 and use motion.motion-type(5) BUT motion-type is a s32 value so it cannot be compared to a bit Also looked at conv_s32_bit to cnvert that s32 value to a bit, BUT you cannot load it in PP (

( TP

Did you check the PP log and see if it showing where the probe/setter is getting tripped? it may be a piece of PP code that is in error or due to modifications is not working correctly.

THe main problem is larger machine always create a resonate freq that tends to rattle the limit switches. The main culprit is teh Z top limit and seeing how with a BP CNC the quill IS a ballscrew you have to protect the quill from bottoming out on the high limit it HAS to be there.

ALSO there are times where we preload things while the machine is running like changing out the probe or tool setter. IF you do that in PP then it trips the machine offline and stops.

The function is really a silly function. IF you want it it should be an option you can turn ON/OFF with a mcode. THe normal function should default to OFF then you can turn it ON when you want it.

What I have to do now is to use a pair of relays to BLOCK the probe / toolsetter signals . For each probe I have to crowbar across the inputs so that PP thinks there are not active. BUT when you need to use the probe /toolsetter you have to REMEMBER to release the relay so PP can see the signals again.

NO ONE in teh CNC world does it like Linuxcnc is doing it. (;-(

( TP

So far NOTHING can be done in HAL to stop it as it is based in the core of LinuxCNC. But you are welcome to try to. THe only way so far was to use
motion.mode and that gives a value of 5 for probing BUT that is a value and the or2 requires a bit so there is no way to compare the two in HAL
No one said said the machine ratlled like an earthquake but it does hit the resonate frequancy of the switches. ANYONE that has run a Bridgeport for very long know this problem ( ABOUT 3600 rpm and a resonable deep cut will trip the upper quil limit. Never the lower. Never the table switches.

Also EVERY machine resonates to one point or another and IF it hits the resonat frequency of a switch it will ratlle it. Hit the resonate freq of a tool and it will chatter. OPITCAL switchs are imune to it thought (

Now you are more than welcome to show us how to do it in HAL . I am always open to learning a new trick.

Just a thought, ( TP