(abort, MSG) in O-sub

More
04 Jan 2013 02:55 #28352 by h_munktell
Replied by h_munktell on topic (abort, MSG) in O-sub

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.

I suspect that message printing happens in the user-space process, and is not added to the real-time queue.
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.

More
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

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

More
04 Jan 2013 03:00 #28354 by h_munktell
Replied by h_munktell on topic (abort, MSG) in O-sub

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.

I suspect that message printing happens in the user-space process, and is not added to the real-time queue.
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.

More
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.

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

More
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

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

More
04 Jan 2013 05:22 #28358 by h_munktell
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.

More
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
The following user(s) said Thank You: h_munktell

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

More
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

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

More
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

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

Time to create page: 0.112 seconds
Powered by Kunena Forum