Making M62/M63 codes failsafe

More
13 Jul 2022 01:18 #247197 by Limedodge
Is there a way to modify any settings to make M62 failsafe (revert to low) in the event of a program crash or emergency stop?  for example, a "following error" or something.

I'm using M62/M63 it to fire a laser and it works great until you manually stop motion or hangup.  Then the digital out stays high and the laser continues to fire.  Only after a deliberate (non zero) motion with M63 does it shut off.  For safety reasons, not ideal.

I'm using a 7i96 digital output pin if there's hardware solution someone is aware of

Thanks

 

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

More
13 Jul 2022 01:48 #247201 by tommylight
Sending it through an AND component with the other input wired to machine-is-enabled or PWM-enable or mode-is-auto or.... should do the trick just fine.
That will stop the laser when any of those pins stops.
This is all in HAL.

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

More
13 Jul 2022 13:35 #247234 by Limedodge
Brilliant.  I'll give that a try.  Thanks
The following user(s) said Thank You: tommylight

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

More
15 Jul 2022 01:48 #247334 by Limedodge
Not the correct forum, but since I started the topic here, I'll continue

The problem with wiring to "motion.motion-enabled" is that if you hit stop, motion is still enabled and the output continues to be high.  If i stop the program mid path, it continues to be high.

I think I need to do some digging and find a pin/signal to tie to that is only high when there is commanded motion.  It get more complicated because in this case I'd need to make sure it's motion in X OR Y (galvos).  Just in case it's a straight X or Y move.  Unless anyone can think of one?

I'm not sure what pin is "mode-is-auto".  Is that an "axis" pin?
 

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

More
15 Jul 2022 02:17 #247335 by tommylight
A quick search through pins results in:
halui.mode.is-auto <<<< can be used as is
motion.teleop-mode <<<< is inverted so requires inversion
I would use the first one.

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

More
15 Jul 2022 02:47 #247340 by MaHa
Replied by MaHa on topic Making M62/M63 codes failsafe
I had the similar problem but a different application. Solved with a small component. net x-vel-cmd and net y-vel-cmd to this component, and check if there is any movement (non-zero). Or use 2 wcomp, out to or2 will do the same.
And have look at motion.motion-type 1: Traverse , 2: Linear feed, 3: Arc feed
 

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

More
15 Jul 2022 10:40 #247363 by andypugh

I had the similar problem but a different application. Solved with a small component. net x-vel-cmd and net y-vel-cmd to this component, and check if there is any movement (non-zero).


There is motion.current-vel to save a step there. Still need the wcomp, and will go true during jogs and rapids.

have look at motion.motion-type 1: Traverse , 2: Linear feed, 3: Arc feed


This might be a good choice, as it remains zero during jogs.

You could also use motion.program-line which is zero when a program is not tunning (and during a toolchange / pause)

Using motion-type needs a bit of HAL logic or possibly a custom component depending on what you are comfortable with.

It's slightly inconvenient that the motion-type is a signed integer, as most of the bit-twiddling components want an unsigned int. So first I think you would need to use conv_s32_u32 to convert.
linuxcnc.org/docs/stable/html/man/man9/conv_s32_u32.9.html

Then I think what I would use might be slightly non obvious, mux_generic. mux_generic can take an unsigned int as an input and have a defined output for each value. If configured as a bit output then you can select the output separately for each motion-type, and can save the and2 by wiring the laser enable through it
linuxcnc.org/docs/stable/html/man/man9/mux_generic.9.html
loadrt conv_s32_u32
loadrt mux_generic config=bb8
...
addf conv_s32_u32.0   servo-thread
addf mux-gen.0        servo-thread
...
net s32_type motion.motion-type => conv_s32_u32.0.in
net u32-type conv_s32_u32.out => mux-gen.00.sel-int
setp mux-gen.00.in-bit-00 0
setp mux-gen.00.in-bit-01 0
net laser-enable mux-gen.00.in-bit-02
net laser-enable mux-gen.00.in-bit-03
setp mux-gen.00.in-bit-04 0
setp mux-gen.00.in-bit-05 0
setp mux-gen.00.in-bit-06 0
setp mux-gen.00.in-bit-07 0
net laser-enable-interlocked mux-gen.00.out-bit

This passes-through the signal laser-enable to laser-enable-interlocked to be used elsewhere if the motion-type is 2 or 3, and sends zero otherwise.

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

More
15 Jul 2022 15:58 #247396 by Limedodge
Yeah, I spent some time thinking about bit banging the motion-type route.  That may be the way to go, but It had occured to me there may be a simpler solution.

NOT the motion-teleop-mode to flip the bit

AND2 motion.teleop-mode with motion.motion-enable

This protects against both conditions I'm worried about

1. "joint X following error" shut down
In this case motion.motion-enable = False and motion.teleop-mode = False (bit flipped to True)
AND2 function = False

2. Manual stop mid lasing path
In this case motion.motion-enable = True and motion.teleop-mode = True (bit flipped to False)
AND2 function = False

Under normal operation both motion.motion-enabled = True and motion.teleop-mode = False (bit flipped to True)
AND2 function = True

Seems like that should catch both of those conditions above with only 2 bitwise operations

Of course there's an additional AND2 with the M62 output pin for actual firing.  All 3 conditions need to be true in order to fire

Am I'm missing something?  Some condition I'm not covered for?  Since it's a laser and glavos, I'm not really doing any jogging.  Nor will I ever need to fire the laser when it's not running a program.  That's how deep holes are made :)
 

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

More
16 Jul 2022 00:47 #247426 by cmorley

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

More
16 Jul 2022 20:25 #247500 by andypugh

Am I'm missing something?  
 

Possibly.  My solution is only two components and is relatively easy to modify if you decide you want laser on G0 too. 
(If you MDI a G0 you probably don't want the laser to enable.)

The setp mux-gen.00input.NN 0 lines are optional, I put them there so that there was a clear table to configure. 
 

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

Time to create page: 0.144 seconds
Powered by Kunena Forum