At 11:21 AM 4/12/2001 +0200, Thorsten Richter wrote:
>Macros:
>I don't think device internal macros are out of scope. Each existing lab
>in the world has devices that are using macros, batch files etc.. You will
>have a hard time to tell the chemist, to throw away all its macros because
>of LECIS.
>Of course, device internal macros are a nightmare for device control,
>because we don't know what happens during this time, but I think we have
>to find a way to support them. Even if it would make our lifes easier to
>say, that LECIS does not support internal macros, because they should be
>defined externally.
>Macros are a little different from normal operations, because they can
>change frequently. Furthermore, the internal implementation for a macro
>call will differ from a "normal" operation. In my opinion we should
>support a operation like callMacro() in addition to runOp().

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

Getting back to the black box view. By nature, macros/scripts are very
specific to the device and its processes. I don't think that it would be
realistic to expect a controller to know what's going on during a macro or
script execution. Of course it would be very nice to have this kind of
insight from a deterministic device control point of view. Nevertheless,
the controller should at be able to retrieve some basic status information
about the macro/script execution, such as macro/script executing, failed,
paused, etc. This could be handled through the already existing status
request mechanism. The abort, pause, and resume operations could be applied
to macro and script execution as well. Bottom line, we pretty much have
everything in place already to support macros/scripts.

Torsten