How the Aux Key Triggered Macros behave when Part Program is running

[nandkishork59]

1. If the prat program is running in terms of say axis motions, will the Aux Key based simple Macro consisting of simple M94/M95 commands have its effect? e.g. start stop chip conveyor manually (this is only an academic example. The obvious correct approach is put this in PLC..... ). Will the ongoing axis motions stop in such a case? While writing this I realize that I can & SHALL check this myself.
2. If the Part Program is halted ...SPECIFICALLY DUE TO SINGLE BLOCK, can (should) we trigger execution of Aux Key based Macros?
3. If yes, with all care taken, can such Aux Key triggered macros contain axis motions of their own?

I want to remember a Z position reached many blocks much earlier to a currently searched X-Y position block, go to the beginning of that block in single block mode - some what similar to tool check - and when the program is waiting there for cycle start, I wish to execute the Aux Key based Macro for going to the remembered Z position and then do cycle start after removing single block. This is a kind of customized interrupted cut recovery.

4. Whether such macro can (should) also be triggered in a Feedhold condition occurring in the main program - is one more question.

rgds

[cncsnw]

1. No.
2. No.
3. n/a

Is the Z you want to remember, and go to, the same Z that it would have been cutting at in that block, if it had simply run from the beginning without interruption?

If so, and if it was reached as a simple coordinate move (rather than a probing move, or using jogging during an M0 pause), then Search or Resume should do what you want by default.

If the Z you want to search or resume at is what it would have been cutting at in that block, but it was reached through an indeterminate move such as probing or user jogging during M0, then you will need to add some custom macro programming around that Z move. Something similar to this:

Code: Select all

IF [#4202 != 0] THEN GOTO 20
  M115/Z P3 F20  ; move Z to an unknowable coordinate
  #150 = #5043    ; save Z coordinate in a static variable
  GOTO 30
N20
  G0 Z#150
N30

That way, in a normal run it does the probing on Z, and saves the resulting value in variable #150; but when processing moves to find a search or resume point, it instead acts as if Z was unconditionally moved to the last coordinate value that was stored in variable #150.

You would probably want the code path for Graphing (when #4201 != 0) to go to the same alternate code, so that graphing shows a sensible Z level, and so that graphing does not change the value stored in variable #150. So the IF condition should probably be [#4201 != 0 || #4202 != 0].

[nandkishork59]

Hello @cncsnw .... thanks for your detailed response which certainly exceeded expectations and pointed out the exact missing link in my communication that the latest Z motion was indeed indeterminate and probing type.
Your answer is comprehensive and actionable. I had tried many things (around the theme of #150 = #5043) except the most critical jump during search.
Thanks a ton again.... I am reasonably sure that this will solve my problem.
rgds