Finite State Machine

The main component of the Argos Subsystem LAS is the LaserController. It behaviour is described by a finite state machine (FSM). The latest version of this FSM can be found in the Argos repository as an UXF file. For viewing and editing the FSM, the open-source tool UMLet is necessary. The FSM of the LaserController looks like this:


Scenarios in the READY state

  1. No light for one laser. This might have the following reasons:
    • Laser is out of order
    • Someone put laser in stand-by mode
    • Something is in the light path (e.g. moth)
  2. No light for all lasers. The reasons might be:
    • Power outage
    • All lasers are out of order
    • Something is in the light paths (a lot of moths)
    • All lasers are in stand-by mode



The construction of the LAS objects like lasers, motors and finite state machine (FSM) is complex. At the moment, the construction is about 200 (November 2011) lines long. Among other things, the LAS loop requires the end points of the basdard services, which are are buried in the configuration files. That means, if someone changes the end point parameters in one configuration file, the LAS loop script has to be updated as well. The risks is that people will forget to update the relevant scripts.

Argos will construct the LAS objects for several occasions:
  1. Simulation: We want to test the LAS system with our device simulators
  2. MPE: The laser system will be assembled there. MPE wants to test the system including the LAS control software.
  3. LBT: There will be two LAS instances: one for SX side and for DX side.
In this situation, it is risky that one change in the LAS object construction will require updating many Python scripts. In order to avoid duplication, the LAS objects construction should be done in place and only differ by the used configuration. It would be great to have a configuration for simulation, MPE and LBT SX/DX.

Furthermore, the LAS object construction requires parameters like nominal position. There should be a central place for these parameters in order to avoid data duplication.

As a workaround, the LAS objects construction is repeated by copying and pasting the relevant instructions. For example, any change in the construction of the FSM requires the editing of several files now.


One solution is a configuration object, i.e. a simple data structure without logic. Having such an object has the following advantages:
  1. Factories can retrieve the necessary settings for the LAS objects from the configuration object. These factories will be the central place for building the LAS objects.
  2. The configuration files can be generated automatically. Problem: Is there enough man-power available for doing this? To keep the configuration object up-to-date with the basdard device configuration files, it is possible to generate the configuration objects from these configuration files.
The SVN repository contains one incomplete example for the LAS configuration object: branches/kulas/las_configuration_object/


As of 2011-12-09, there are several possibilities for a central configuration. The following table evaluates the the different central configuration file approaches:
  Specification of .cfg file location Loading .cfg file in property tree Enforcement of ADAPTER settings Automatic generation of cfg files
coding effort - (extracting parameters from ADAPTER) ++(no coding) ++(no coding) --(lot of coding)
user flexible (0) ++ ++ --(user must follow standards) ++
NFS required? (1) -- -- ++ ++
simple service monitoring ++ -- -+ (enforce file name standards) ++
service name standards -- -- ++ ++
  • (0): How much freedom has the user for choosing the ADAPTER settings and configuration file names?
  • (1): The ARGOS subsystem services and device services will run on serveral computers. The central configuration file must contain all relevant settings for contacting these services. If the central configuration file refers to other configuration files (e.g. device specific configurations), a shared file system like NFS is necessary in order to avoid problems with out-dated settings. a shared files system like NFS

Example: Specification of File Location

DX.LAS.CONFIG_PATH:String= "/path/to/las.cfg"



DX.LAS.LASERS.CONFIG_PATH:String= "lasers.cfg"

DX.LAS.PERISCOPE_1A.CONFIG_PATH:String= "periscope_1A.cfg"

DX.LAS.PERISCOPE_1B.CONFIG_PATH:String= "periscope_1B.cfg"

DX.LAS.PERISCOPE_2A.CONFIG_PATH:String= "periscope_2A.cfg"

Example: Loading Configuration File into Property Tree

DX.LAS.LASERS.CONFIG= "lasers.cfg"

DX.LAS.PERISCOPE_1A.CONFIG= "periscope_1A.cfg"

Example: Enforcement of ADAPTER Settings

PREFIX= "argos_mpe"



DX.LAS.ENDPOINT.PORT:String= "20000"




DX.LASERS.DEVICES:SeqString= ["DEV1", "DEV2", "DEV3"]

Proposed LAS Engineering GUI for the Lab


Topic revision: r4 - 07 Aug 2018, AndrewColson
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback