EMC interpreter wish list

[Ray Henry <rehenry-at-up.net>]

Fred

I'm attempting to get my head around operational aspects of the interpreter
that EMC uses in the integrated environment.  The following discussion
makes reference to the emcsh and Tcl commands that may be passed from it to
the command interpreter.  Since I have very limited comprehension of C and
none of C++, correct me where my discussion run astray.


Auto Mode Discussion
--------------------
In auto mode, the EMC interpreter runs a single program, one time.  This
program is passed to it by the user interface. "In the integrated
interpreter, programs are recognized and handled by the user interface of
the EMC control system." (RS274NGC_TOC 18)  It does this in linear fashion
from the first block passed to the last block passed. 

While the interpreter is running there is very little control that can be
exercised over its operation.  Execution may be immediately terminated
using emc_abort or paused using emc_pause. I understand that this is
necessary because "The interpreter maintains a model of the machine while
it is interpreting and uses the model in determining what canonical
machining functions to call and what their arguments should be."
(RS274NGC_TOC 8)   

When the action of the interpreter is aborted, all memory of the operating
program and operating line is pretty much forgotten -- the program portions
of the internal model evaporate.  The program reported by emc_program
changes to "none" although the last filename is saved somewhere in there
because emc_run will restart the last program without interface assistance.
 Also when emc_abort is issued, the line number reported by
emc_program_line drops to "0." 

While auto mode is active, the effect of pause is just like feedhold on
many machines -- the motion controller is stopped in process at the moment
the interpreter receives the emc_pause command.  While it is paused, the
interpreter will permit the execution of the next single block in the
program using emc_step.  The first step after pause completes the block the
interpreter was executing when paused.  While paused, the interpreter will
also accept a command to resume. This suggest to me that pause simply
freezes motion commands.

The command emc_run, with a start line, sets up the interpreter with the
proper machine model so that it can begin machine motion from the line
given.  But when this feature is used, the machine operator better be
pretty damn sure that there isn't anything hard between where the tool is
located before the interpreter reaches the start line and where it will be
when the restarted program has completed the first full set of axis motions. 

I see from tests here that issuing an <emc_mode manual> while running a
part program file aborts the running program and changes the program status
to manual.  Issuing an <emc_mode mdi> appears to have no effect other than
changing the state reported by emc_program_status and locking out emc_step.
 (I imagine several folk asking themselves, "Why would anyone, other than
someone named 'Ray,' issue either of those commands while running.")  

If the above discussion is a complete and accurate description of the ways
in which we can touch the interpreter while it is running a program, then I
have four things I'd like to see developed.


Things I'd like to see
----------------------

1 - I'd like to see the interpreter trap the manual mode command unless
auto mode is idle. (end of program, e-stop or abort.)  This can be done in
Tcl for its commands and widgets, but that doesn't help with a hard wired
operator interface. 

2 - I'd like to see the addition of a conditional pause.  End-of-block is
the first condition that comes to mind though one might use it for any good
program word. (even n words)  Perhaps it could be invoked by adding a
variable to the emc_pause command (emc_pause eob) in emcsh and pass the
value of that variable to a conditional in the interpreter.  If the
emc_pause command had an empty value the action of pause would be it's
current action.  If the variable had a value to pass, the interpreter would
delay the action of pause until it was ready to issue the next block of
canonical calls after the block containing the value passed to pause.  

The immediate machining effect of such an end-of-block call would be to
allow a cut to complete rather than marring surface finish by pressing
pause and then step to the eob.  Another example might be a pause with a
g87 so the interpreter would pause execution before it began the back bore
canned program.  An operator might want to check the condition of a bore
before this critical operation during a setup.  

Yes each of these actions could be programmed in with (m0), but that
requires more advanced planning.  It also requires program changes when the
setup is ready for production.  On some machines I've worked with there is
an ignore the m0 command switch. The conditional pause command would be
much more flexible. 

3 - I'd like to be able to switch on pause when <emc_run ###> has read to
the line number given it and is ready to make the first machine move.  

4 - I'd like to be able to place a paused program in mdi and accept blocks
from the keyboard.  These blocks might interfere with the read ahead and
would no doubt affect the internal machine model.  

I'd use this feature to place the tool correctly for restart and to move a
tool out of the way for size checks during a setup.  



If there is anything that I can do to help, let me know.  

I feel a little bit like a kid writing to Santa, except I'm the old,
overweight, graybeard.

Ray