Making M62/M63 codes failsafe
13 Jul 2022 01:18 #247197
by Limedodge
Making M62/M63 codes failsafe was created 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
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.
- tommylight
-
- Away
- Moderator
-
Less
More
- Posts: 18563
- Thank you received: 6218
13 Jul 2022 01:48 #247201
by tommylight
Replied by tommylight on topic Making M62/M63 codes failsafe
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.
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.
13 Jul 2022 13:35 #247234
by Limedodge
Replied by Limedodge on topic Making M62/M63 codes failsafe
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.
15 Jul 2022 01:48 #247334
by Limedodge
Replied by Limedodge on topic Making M62/M63 codes failsafe
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?
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.
- tommylight
-
- Away
- Moderator
-
Less
More
- Posts: 18563
- Thank you received: 6218
15 Jul 2022 02:17 #247335
by tommylight
Replied by tommylight on topic Making M62/M63 codes failsafe
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.
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.
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
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.
15 Jul 2022 10:40 #247363
by andypugh
There is motion.current-vel to save a step there. Still need the wcomp, and will go true during jogs and rapids.
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
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.
Replied by andypugh 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).
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.
15 Jul 2022 15:58 #247396
by Limedodge
Replied by Limedodge on topic Making M62/M63 codes failsafe
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![:) :)](/media/kunena/emoticons/smile.png)
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
![:) :)](/media/kunena/emoticons/smile.png)
Please Log in or Create an account to join the conversation.
16 Jul 2022 00:47 #247426
by cmorley
Replied by cmorley on topic Making M62/M63 codes failsafe
This might be helpful:
linuxcnc.org/docs/devel/html/remap/remap...g_dealing_with_abort
linuxcnc.org/docs/devel/html/remap/remap...g_dealing_with_abort
Please Log in or Create an account to join the conversation.
16 Jul 2022 20:25 #247500
by andypugh
(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.
Replied by andypugh on topic Making M62/M63 codes failsafe
Possibly. My solution is only two components and is relatively easy to modify if you decide you want laser on G0 too.Am I'm missing something?
(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.099 seconds