Probe /Tool setter trip stops program run ???

Not exactly sure what all that is about, but i am sure that everything can be done in hal so probe trip does not stop a running program.
Never ever heard or seen a machine rattling so much that it rips the limits switches, by that time the tool would have been long gone. Probably the building would be gone also.

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

the reason why there is no function in hal for that.  it is to be solved with basis function.  a custom function is nicer.  rod had already made a suggestion and I signed what he said unseen.  I'm on the road right now and I still don't understand the problem exactly.  but I suggest sleep on it a night or two and start over.  What I see is that the sensor triggers while working.  correct?  and actually a custom function is very elegant.  I assume that you have problems with the programming.  but a friendly question will help you.  otherwise with a basic function, a custom m code would be the solution.  you can easily turn the sensor on and off with halcmd linkpin or unlinkpin in m code function. 

I still think looking at what PP is saying is going on will help understand the issue.  PP has many probing calls within it that may be the issue not the hal.   you may see an error message or something there in the pathpilot.txt that may point to the issue.   
There's probe/setter stuff in probing.py, mill_probe.py, constants.py and tormach_mill_ui.py and a few others.

You have a symptom without looking at the data for it and tracking down where the error occurs in PP may help.   
There may be nothing granted but I would check.

Vmax549 wrote:

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
 

I've been having a similar problem... sensitive wireless spindle probe triggering when it's in the rack, stopping a program.

I think an M-code to disconnect the probe input signal would be fairly easy.  If the M-code were put in the INI file NGC startup sequence, 'old' programs would not need to be edited.

Any probing routines would need to be edited to include the M-code (connect/disconnect), as would any manual/MDI probing.

I don't really know anything about remaps, but perhaps G38.n could be modified to require the new M-code be inactive without erroring out.

Just a thought...

-R

I beleive that a patch is not the answer but a FIX in Linucnc would be the answer. It is a silly function to start with and realy serves no purpose. That function should be used with a Mcode switch to turn it on and off.

( TP