Skip to content
Snippets Groups Projects
Commit e26656d8 authored by Jan David Mol's avatar Jan David Mol
Browse files

L2SS-434: Restructuring

parent 3838155e
No related branches found
No related tags found
1 merge request!150L2SS-434: Add sphinx documentation content
Using Devices Devices
============= ============
The station exposes *devices*, each of which is a remote software object that manages part of the station. Each device has the following properties: RECV
----------
- It has a *state*, The `recv == Device("LTS/RECV/1")` device controls the RCUs, the LBA antennas, and HBA tiles. Central to its operation are the masks:
- Many devices manage and represent hardware in the station,
- It exposes *read-only attributes*, that expose values from within the device or from the hardware it represents,
- It exposes *read-write attributes*, that allow controlling the functionality of the device, or the hardware it represents,
- It exposes *properties*, which are fixed configuration parameters (such as port numbers and timeouts).
To access a device, one creates a `Device` object. For example:: - The `RCU_mask_RW` attribute is an array of `bool[N_RCUs]`. It controls which RCUs will actually be configured, when fields referring to RCUs are set. Any RCU for which the mask is False will not be configured when RCU control points are set.
- The `Ant_mask_RW` attribute is an array of `bool[N_RCUs][N_Antennas_per_RCU]`. It controls which antennas will actually be configured, when fields referring to antennas are set. Any antenna for which the mask is False will not be configured when antenna control points are set.
device = Device("LTS/RECV/1") Typically, `N_RCUs == 32`, and `N_Antennas_per_RCU == 3`.
States
------------
The state of a device is then queried with `device.state()`. Each device can be in one of the following states:
- `DevState.OFF`: The device is not operating,
- `DevState.INIT`: The device is being initialised,
- `DevState.STANDBY`: The device is initialised and ready to be configured further,
- `DevState.ON`: The device is operational.
- `DevState.FAULT`: The device is malfunctioning. Functionality cannot be counted on.
- The `device.state()` function can throw an error, if the device cannot be reached at all. For example, because it's docker container has not been started.
Each device provides the following functions to change state:
- `off()`: Turn the device `OFF` from any state.
- `initialise()`: Initialise the device from the `OFF` state, to bring it to the `STANDBY` state.
- `on()`: Mark the device as operational, from the `STANDBY` state, bringing it to `ON`.
Attributes
------------
The device can be operated in `ON` state, where it exposes *attributes* and *commands*. The attributes can be accessed as python properties, for example::
recv = Device("LTS/RECV/1")
# turn on all LED0s
recv.RCU_LED0_RW = [True] * 32
# retrieve the status of all LED0s
print(recv.RCU_LED0_R)
The attributes with an `_R` suffix are monitoring points, reflecting the state of the hardware, and are thus read-only. The attributes with an `_RW` suffix are control points, reflecting the desired state of the hardware. They are read-write, where writing requests the hardware to set the specified value, and reading returns the last requested value.
Devices
============
RECV
----------
The `recv == Device("LTS/RECV/1")` device controls the RCUs, the LBA antennas, and HBA tiles. Central to its operation are the masks:
- The `RCU_mask_RW` attribute is an array of `bool[N_RCUs]`. It controls which RCUs will actually be configured, when fields referring to RCUs are set. Any RCU for which the mask is False will not be configured when RCU control points are set.
- The `Ant_mask_RW` attribute is an array of `bool[N_RCUs][N_Antennas_per_RCU]`. It controls which antennas will actually be configured, when fields referring to antennas are set. Any antenna for which the mask is False will not be configured when antenna control points are set.
Typically, `N_RCUs == 32`, and `N_Antennas_per_RCU == 3`.
Using Devices
=============
The station exposes *devices*, each of which is a remote software object that manages part of the station. Each device has the following properties:
- It has a *state*,
- Many devices manage and represent hardware in the station,
- It exposes *read-only attributes*, that expose values from within the device or from the hardware it represents,
- It exposes *read-write attributes*, that allow controlling the functionality of the device, or the hardware it represents,
- It exposes *properties*, which are fixed configuration parameters (such as port numbers and timeouts).
To access a device, one creates a `Device` object. For example::
device = Device("LTS/RECV/1")
States
------------
The state of a device is then queried with `device.state()`. Each device can be in one of the following states:
- `DevState.OFF`: The device is not operating,
- `DevState.INIT`: The device is being initialised,
- `DevState.STANDBY`: The device is initialised and ready to be configured further,
- `DevState.ON`: The device is operational.
- `DevState.FAULT`: The device is malfunctioning. Functionality cannot be counted on.
- The `device.state()` function can throw an error, if the device cannot be reached at all. For example, because it's docker container has not been started.
Each device provides the following functions to change state:
- `off()`: Turn the device `OFF` from any state.
- `initialise()`: Initialise the device from the `OFF` state, to bring it to the `STANDBY` state.
- `on()`: Mark the device as operational, from the `STANDBY` state, bringing it to `ON`.
Attributes
------------
The device can be operated in `ON` state, where it exposes *attributes* and *commands*. The attributes can be accessed as python properties, for example::
recv = Device("LTS/RECV/1")
# turn on all LED0s
recv.RCU_LED0_RW = [True] * 32
# retrieve the status of all LED0s
print(recv.RCU_LED0_R)
The attributes with an `_R` suffix are monitoring points, reflecting the state of the hardware, and are thus read-only. The attributes with an `_RW` suffix are control points, reflecting the desired state of the hardware. They are read-write, where writing requests the hardware to set the specified value, and reading returns the last requested value.
...@@ -12,8 +12,8 @@ Welcome to LOFAR2.0 Station Control's documentation! ...@@ -12,8 +12,8 @@ Welcome to LOFAR2.0 Station Control's documentation!
installation installation
remote_interfaces remote_interfaces
devices/using
devices/devices devices/devices
devices/recv
control control
monitoring monitoring
logs logs
......
Installation
==================
You start with checking out the source code, f.e. the master branch, as well as the git submodules we use::
git clone https://git.astron.nl/lofar2.0/tango.git
cd tango
git submodule init
git submodule update
Next, we bootstrap the system. This will build our docker images, start key ones, and load the base configuration. This may take a while::
cd docker-compose
make bootstrap
If you lack access to LOFAR station hardware, load additional configurations to use the simulators instead::
for sim in ../CDB/\*-sim-config.json; do
../sbin/update_ConfigDb.sh ../CDB${sim}-config.json
done
Now we are ready to start the other containers::
make start
and make sure they are all up and running::
make status
You should see the following state:
- Containers `astor`, `hdbpp-viewer`, `jive`, `log-viewer` and `pogo` will have State `Exit 1`. These are containers that are interactive X11 tools, and not needed for now,
- Other containers have either State `Up` or `Exit 0`.
If not, you can inspect why with `docker logs <container>`. Note that the containers will automatically be restarted on failure, and also if you reboot. Stop them explicitly to bring them down (`make stop <container>`).
Initialisation
----------------
The following procedure describes how to initialise the system, which is required after installation and after a system reboot.
The docker containers will automatically restart after a system reboot. But the Linux kernel will lose its required custom settings required by our ELK stack. To reconfigure the kernel parameters, run::
make start elk-configure-host
make restart elk
We can now initialise the station configuration, that is, start all the software devices to control the station hardware, and to initialise the hardware with the configured default settings. Go to http://localhost:8888, start a new *Station Control* notebook, and initiate the software boot sequence::
# reset our boot device
boot.off()
assert boot.state() == DevState.OFF
boot.initialise()
assert boot.state() == DevState.STANDBY
boot.on()
assert boot.state() == DevState.ON
# start and initialise the other devices
boot.initialise_station()
# wait for the devices to be initialised
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment