Probe /Tool setter trip stops program run ???

More
16 Apr 2022 19:36 #240421 by chris@cnc
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. 

Please Log in or Create an account to join the conversation.

More
17 Apr 2022 00:59 #240433 by smgvbest
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.

Please Log in or Create an account to join the conversation.

More
17 Apr 2022 04:14 #240439 by spumco

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

Please Log in or Create an account to join the conversation.

More
17 Apr 2022 14:07 #240469 by Vmax549
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

Please Log in or Create an account to join the conversation.

More
17 Apr 2022 14:45 #240470 by snowgoer540
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.

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.

Please Log in or Create an account to join the conversation.

More
17 Apr 2022 21:53 #240498 by Vmax549
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

Please Log in or Create an account to join the conversation.

More
20 Apr 2022 11:58 - 20 Apr 2022 12:20 #240731 by andypugh

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


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
 
Last edit: 20 Apr 2022 12:20 by andypugh.
The following user(s) said Thank You: tommylight, verser, snowgoer540, zu4lu, spumco

Please Log in or Create an account to join the conversation.

More
20 Apr 2022 17:09 #240739 by Vmax549
HI Andy have you ever tried to save the probe while jogging ???

(;-) TP

Please Log in or Create an account to join the conversation.

More
05 May 2023 02:31 - 05 May 2023 02:34 #270693 by spumco

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:
net MOTION-TYPE         <=  motion.motion-type
net MOTION-TYPE         =>  conv-s32-u32.0.in
net MOTION-TYPE-U       <=  conv-s32-u32.0.out
net MOTION-TYPE-U       =>  demux.0.sel-u32
net PROBING             <=  demux.0.out-05
net PROBING             =>  and2.16.in0
net PROBE-PIN           <=  [HMOT](CARD0).7i76.0.0.input-03-not
net PROBE-PIN           =>  and2.16.in1
net PROBE-CHECKED       <=  and2.16.out
net PROBE-CHECKED       =>  motion.probe-input

Thank you Andy.
Last edit: 05 May 2023 02:34 by spumco.

Please Log in or Create an account to join the conversation.

Moderators: cncbasher
Time to create page: 0.310 seconds
Powered by Kunena Forum