Torsten wrote:
>I agree with Thorsten on the macro issue. We cannot ignore macros/scripts,
>since most devices are controlled by them. To keep the control architecture
>simple, we may want to provide a method to invoke a macro or script such as
>Thorsten's proposed callMacro(), or we could simply use the runOP()
>command. A macro or a script could be viewed as a composite yet "atomic"
>operation after all. I think that the controller should treat a
>macro/script as a black box operation. Macro/script-specific information
>such as expected running time, required resources, and alike should be
>stored in the Device Capability Dataset (DCD).

It seems to me that the best that you can do with a black-box model
for macros is to have:
-metadata as described above;
-a concepual execution model that allows monitoring and some control
of the macro execution by such commands start, pause and terminate
(again as described in Torsten's email) although in some macro
instances some of these commands and corresponding states may never
be valid;
-some method for acquisition and release of control of resources
which are a component in a device.

All of these options require that someone do additional work to
adapt existing macros to a LECIS environment, although the last
aspect may be the most invasive if resource allocation steps aren't
already required in the execution of the macro.

Note that this treats macros very much like Program Invocations
in the Manufacturing Message Specification (ISO 9506) which also
have a conceptual execution model and can have system resources
associated with them.

-Evan K. Wallace
Manufacturing System Integration Division
NIST
ewallace@...