Slow control software for the CTA SCT camera. This software allows the camera operator to control and automatically monitor the SCT camera and ancillary devices.
Use the provided conda environment file to create an Anaconda environment containing all dependencies for the slow control code using the command conda env create -f environment.yml. Alternatively, all the dependencies as specified in that file may be installed separately. Install the sctcamsoft package into the conda environment:
source activate sctcamsoft
cd </installation/path>/sctcamsoft
pip install --upgrade .Compile the protocol buffers module with protoc -I=. --python_out=. ./slow_control.proto.
Developer note: after making changes to the code, the package must be reinstalled for them to take effect.
Configuration is provided using two YAML files. First, config.yml specifies configuration parameters for connecting to devices such as IP addresses and timeout values. Second, commands.yml lists the available commands. There are three types of commands: low level, which cause an action by a specific device; special, which change the mode for how the server interprets commands (e.g. enter repeat mode); and high level, which are a list of commands (which themselves may be of any type). The arguments to commands may be specified by default values in commands.yml or user input.
To run the slow control software, first run the run the server program using sudo python server.py config.yml commands.yml. Running as superuser is necessary for monitoring network activity. When the server is running and configured, run the user input and output programs with python user_input.py config.yml commands.yml and python user_output.py config.yml. When done, close out of all three programs using Ctrl^C.
A script for running all three programs either locally or remotely on the camera server is available along with instructions on the SCT Camera Slow Control Confluence page.
In the user input terminal, type in commands and arguments as defined in commands.yml. View output in the user output terminal. The traceback for all errors handled by the server is printed in the server terminal.
Control and monitoring is available for three devices: camera fans, camera power, and network connection. See commands.yml for a complete list of supported commands. It is possible to set alerts for any numerical monitoring variable.
The slow control software provides high-level commands to automate normal camera operation. Type startup to prepare camera for operation (Operations Manual sec. 5.1 and 5.2). When everything is connected and on, type start_HV to turn on HV, and stop_HV to turn it off. When done taking data, type shutdown to prepare camera for shutdown (Manual sec. 6.1).
The GUI is started via the main.py script in the gui folder. It expects the same parameters as the server itself - a config.yml and a commands.yml file. If testing locally, simply refer to the config and commands file in the repo's root folder. Execute the following from the repo's root.
python sctcamsoft/gui/main.py config.yml commands.ymlIf you're trying to test the GUI against the mock server on your own machine, reconfigure such that host: localhost. Run the mock server first (using the same config and commands file), then start the GUI.
To run the server without connecting to real the SCT's real hardware, run as normal with the --mock option. This will instantiate virtual hardware devices commands will operate against.
If using the main config.yml and commands.yml and running from the repo's root, the call should look like this:
python sctcamsoft/server.py --mock config.yml commands.ymlConnect to the server using the standard user_input.py and user_output.py terminals, or the GUI.
At startup, each mock device pulls its configuration from config.yml. Each device should have a mock attribute, and it's elements represent that device's state (currents, voltages, connection and on/off states, etc) at startup.
Many of the device values also a have "noisy_" option. Setting it to true will make the mocked value the server returns vary a bit around the number defined in hardware_state.yml.