Probe /Tool setter trip stops program run ???

Since you're running PathPilot, which has been forked from the main project quite some time ago, a "fix" in LinuxCNC would not be the answer.

There are several ways to make LinuxCNC do what you are after, all of which are simple to implement outside of PathPilot's world (which removed halcompile, etc.). That said even if the source code for the LinuxCNC project was changed, it would not end up in PathPilot unless their software engineers decided to pull it into their project.

That's why I suggested you reach out to Tormach a few posts ago. They may be amenable to providing you find a solution to your problem (assuming you are running one of their mills). Otherwise, you are probably stuck installing halcompile and "patching" PathPilot.

snowgoer540 wrote:

Otherwise, I have had really good response from Tormach with emailing them ideas and beta testing. You might try opening some discussion with them if it's worth it to you.

Well Here is how we work updates. When I get PP to state that everyone likes it and it does the job then we lock it down on teh machine and NEVER update again unless it is crutial to do so. we do not update just because someone updated the shape or color of a button (

Tormch pretty much thinks I am wasting their time BUT the guys here do like the feel of it but in many ways feel it is still some what primative compared to a commercial controller (Fanuc,Haas). I have already remapped several of the G/M codes to act like a Haas and or Fanuc.

So hopefully I will find a programer that can hack the Linuxcnc portion and disable that Probing lockout function for us.

THEN we lock it down for the long run.

( TP

Vmax549 wrote:

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

I think that attempting to protect the probe from G0 and G1 moves is a good idea. 

There is a way to do what you want in HAL, but it takes a number of functions to do it. 

We can use demux to convert the motion-mode into a bit output, though inconveniently motion-type is signed and demux wants unsigned, so we need to also use conv_s32_u32 and also an and2 to disable the probe input

HI Andy have you ever tried to save the probe while jogging ???

( TP

andypugh wrote:

Code:

loadrt demux personality=7 loadrt conv_s32_u32 loadrt and2 count=1 ... addf demux.0  servo-thread addf conv_s32_u32.0  servo-thread addf and2.0.servo-thread ... net m-type motion.motion-type conv_s32_u32.0.in net m-type-u conv_s32_u32.0.out demux.0.sel-u32 net probing demux.0.out-05 and2.0.in0 net probe-pin {your probe source) and2.0.in1 net checked-probe and2.0.out motion.probe-input

Late update, but Andy's method is working quite well.

I don't know if LCNC has been changed since he posted the HAL code snippet, but I found that conv_s32_u32 pin names are:

conv-s32-u32.in
conv-s32-u32.out
Note the hyphen and not an underscore.

This does not affect the loadrt/addf names - those still use underscores as originally posted.
So mine looks like this:
Thank you Andy.