(abort, MSG) in O-sub
- h_munktell
- Offline
- Junior Member
Less
More
- Posts: 31
- Thank you received: 0
04 Jan 2013 02:55 #28352
by h_munktell
Thanks, but tried this, hope it was kind of this you thought of?, with no success:
Replied by h_munktell on topic (abort, MSG) in O-sub
I suspect that message printing happens in the user-space process, and is not added to the real-time queue.Same thing, which is extremely strange. If the code where to be compiled by a high level compiler, I could have understod that the second if statement would be optimized into the first. But to my knowlege this is a interpreter(?) language and that should not happen.
One workaround might be to interleave a motion-synchronised command, such as an M67 or M62.
Thanks, but tried this, hope it was kind of this you thought of?, with no success:
o100 if [#5070 EQ 1] (Probe sucessfull)
(MSG, Probe successful!)
G10 L20 P[#5220] z[#3] (Set Z touch off point coordinate)
G0 Z [#4] (Retract Z)
o100 else (Probe failed)
G90 G53 G0 Z-1 (Retract to safe Z)
M62 P #<_ini[pins]probing> ; turn on probing led for testing purposes
G53 G0 Z0
(abort, Probe failed!)
o100 endif
Please Log in or Create an account to join the conversation.
04 Jan 2013 02:56 #28353
by mhaberler
Replied by mhaberler on topic (abort, MSG) in O-sub
yes, because the abort command causes a flush of the interpreter queue long before the execution even gets to the instruction before the abort
you _must_ use a 'queuebuster operation' before the abort which are tool change, input read, probe.
Reading a pin and ignoring the value is your best bet right now.
I'll look into faking a queue buster with remapping.
- Michael
you _must_ use a 'queuebuster operation' before the abort which are tool change, input read, probe.
Reading a pin and ignoring the value is your best bet right now.
I'll look into faking a queue buster with remapping.
- Michael
Please Log in or Create an account to join the conversation.
- h_munktell
- Offline
- Junior Member
Less
More
- Posts: 31
- Thank you received: 0
04 Jan 2013 03:00 #28354
by h_munktell
Hi, thanks. Tried this and it works, now I only need to fin out the INTERP_EXECUTE_FINISH thing and write a own M code... :
Replied by h_munktell on topic (abort, MSG) in O-sub
I suspect that message printing happens in the user-space process, and is not added to the real-time queue.Same thing, which is extremely strange. If the code where to be compiled by a high level compiler, I could have understod that the second if statement would be optimized into the first. But to my knowlege this is a interpreter(?) language and that should not happen.
One workaround might be to interleave a motion-synchronised command, such as an M67 or M62.
yes, forcing the interpreter queue to finish by a 'read pin' command should work
unfortunately the interpreter as it stands doesnt have a command to 'wait until queue executed up to here', but it would be relatively simple to add by a M- or G-code which returns INTERP_EXECUTE_FINISH
- Michael
Hi, thanks. Tried this and it works, now I only need to fin out the INTERP_EXECUTE_FINISH thing and write a own M code... :
o100 if [#5070 EQ 1] (Probe sucessfull)
(MSG, Probe successful!)
G10 L20 P[#5220] z[#3] (Set Z touch off point coordinate)
G0 Z [#4] (Retract Z)
o100 else (Probe failed)
G90 G53 G0 Z0 (Retract to safe Z)
M66 P #<_ini[pins]changed> L1 Q#<_ini[dwell]ack_secs>
(abort, Probe failed!)
o100 endif
Please Log in or Create an account to join the conversation.
- h_munktell
- Offline
- Junior Member
Less
More
- Posts: 31
- Thank you received: 0
04 Jan 2013 03:15 #28355
by h_munktell
Replied by h_munktell on topic (abort, MSG) in O-sub
Found the manual page for task and intr synch, INTERP_EXECUTE_FINISH etc:
www.linuxcnc.org/docs/devel/html/remap/s...mc_program_execution
Reading into it right now.
Reading into it right now.
Please Log in or Create an account to join the conversation.
04 Jan 2013 05:21 #28357
by mhaberler
Replied by mhaberler on topic (abort, MSG) in O-sub
I added an example to master:
git.linuxcnc.org/gitweb?p=linuxcnc.git;a...7cfdebd9df8ec1e1c398
- Michael
git.linuxcnc.org/gitweb?p=linuxcnc.git;a...7cfdebd9df8ec1e1c398
- Michael
Please Log in or Create an account to join the conversation.
- h_munktell
- Offline
- Junior Member
Less
More
- Posts: 31
- Thank you received: 0
04 Jan 2013 05:22 #28358
by h_munktell
Did not see your post before my last posts. I now understand the execution in interpreter and task, very helpfull, thanks! So, I do a bogus read as you said and it's working great. However, it would be nice to have a own defined M-code that had the 'queuebuster operation' .
Replied by h_munktell on topic (abort, MSG) in O-sub
yes, because the abort command causes a flush of the interpreter queue long before the execution even gets to the instruction before the abort
you _must_ use a 'queuebuster operation' before the abort which are tool change, input read, probe.
Reading a pin and ignoring the value is your best bet right now.
I'll look into faking a queue buster with remapping.
- Michael
Did not see your post before my last posts. I now understand the execution in interpreter and task, very helpfull, thanks! So, I do a bogus read as you said and it's working great. However, it would be nice to have a own defined M-code that had the 'queuebuster operation' .
; this is called from gladevcp MDI action with the following
; MDI command:
; O<probe> call [${pfeed-f}] [${dist}] [${probeplate}] [${z_safe-f}]
O<probe> sub
M73 (Save modal state)
G49 (cancel dynamic tool length offset)
G91 (relative mode)
F #1 (Set feed)
G38.3 Z #2 (Probe towards workpiece)
o100 if [#5070 EQ 1] (Probe sucessfull)
(MSG, Probe successful!)
G10 L20 P[#5220] z[#3] (Set Z touch off point coordinate)
G0 Z [#4] (Retract Z)
o100 else (Probe failed)
G90 G53 G0 Z0 (Retract to safe Z)
M66 P0 L0 ;Bogus read, need to have a "queuebuster" here to synch task and interpreter
(abort, Probe failed!)
o100 endif
O<probe> endsub
Please Log in or Create an account to join the conversation.
04 Jan 2013 05:26 #28359
by mhaberler
Replied by mhaberler on topic (abort, MSG) in O-sub
changing the G-code into an M-code is left as an exercise for the reader
-m
-m
The following user(s) said Thank You: h_munktell
Please Log in or Create an account to join the conversation.
- h_munktell
- Offline
- Junior Member
Less
More
- Posts: 31
- Thank you received: 0
04 Jan 2013 05:35 #28360
by h_munktell
Replied by h_munktell on topic (abort, MSG) in O-sub
Again, forum post race condition Checked the new example and implemented G70, works like a treat Will look into to change to M-code (without help, documentation is sure enough )
ps. Note to forum admin, would be nice to have a function that notice you when hitting post if there is new messages posted after you started to write your post
ps. Note to forum admin, would be nice to have a function that notice you when hitting post if there is new messages posted after you started to write your post
Please Log in or Create an account to join the conversation.
04 Jan 2013 06:17 #28361
by BigJohnT
Replied by BigJohnT on topic (abort, MSG) in O-sub
That's only available in pay forum software I assume... you should have seen what we had before!
John
John
Please Log in or Create an account to join the conversation.
Time to create page: 0.116 seconds