(abort, MSG) in O-sub

andypugh wrote:

h_munktell wrote:

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.

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

mhaberler wrote:

andypugh wrote:

h_munktell wrote:

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

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

mhaberler wrote:

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

; 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