CSS Scan System

Automation of beam line experiments requires more flexibility than the control of an accelerator. The sample environment devices to control as well as requirements for their operation can change daily. Tools that allow stable automation of an accelerator are not practical in such a dynamic environment. On the other hand, falling back to generic scripts opens too much room for error. The Scan System offers an intermediate approach. Scans can be submitted in numerous ways, from pre-configured operator interface panels, graphical scan editors, scripts, the command line, or a web interface. At the same time, each scan is assembled from a well-defined set of scan commands, each one with robust features like error checking, time-out handling and read-back verification. Integrated into Control System Studio (CSS)[1], scans can be monitored, paused, modified or aborted as needed. We present details of the implementation and first usage experience. BEAM LINE EXPERIMENTS A beam line control system interfaces to various devices, for instance motors, temperature controllers, detectors. Beam line users need to control these devices at a safe distance from the beam. Experiments further necessitate automation, since manual control over many hours of operation would be impractical. Finally, experiment readings need to be saved and later analyzed for scientific information. The Python scripting language offers access to devices via Process Variables (PVs) in the Experimental Physics and Industrial Control System (EPICS)[2]. Especially for simple experiments, it is tempting to combine automation logic, data acquisition, and associated user interface within one piece of scripted software. It is easy to create such scripts from scratch. They can be modified as needed to include new automation requirements. The monolithic script approach has considerable disadvantages: Ad-hoc scripts tend to only function satisfactorily until there are errors, for example network issues or devices responding in unexpected ways. Such potential errors tend to be overlooked when writing “a simple script”. The experiment may often continue, only for users to learn much later that the acquired data is of no use. Standalone scripts typically run until they finish. There is no way general to monitor their progress, to pause or abort them in a graceful manner. Such a basic script may close the beam line shutter at the end of an experiment, but only if the script is allowed to execute until its last line. If the user or an error aborts the script earlier, the beam line shutter may accidentally remain open! From a software engineering standpoint, a disjunctive collection of custom, standalone scripts will also be hard to maintain in the long run.