Device Manager¶
The Device Manager provides supervision and management for a configurable set of devices.
The Device Manager provides a library of Devices which are implementing the communication with the respective controllers in the PLC. Devices are created at the manager start-up by a device factory class. The main components of the Device Manager server are:
- State Machine engine based on SCXML and implemented in RAD. It contains a set of action and activity classes.
- A Device Factory class that create the instances of all device classes at start-up and based on the server configuration.
- A set of Device classes. Each device has two additional classes: one for the device configuration and another one for the interface with the Local Control System (LCS).
- A Facade class that manage the interface between the state machine engine and the device classes.
Device Manager Components without LCS.
The client applications such the fcfgui send commands to the Device Manager using the ZeroMQ protocol (request/reply) and using Google Protocol Buffer serialization. The fcfgui is subscribed via ZeroMQ to the device topic changes published by the Device Manager.
The Device Manager uses the Redis Database to store run-time information about itself and about the devices it controls. In absence of a Local Control System, device classes can connect with the Device Simulator via OPC-UA protocol, see figure above.
In normal operations, device classes connect to the OPC-UA server running inside the windows side of the Beckhoff IPC, e.g .CX2030. This communication is based on the execution of RPC calls (OPC-UA Method profile). Each Device Controller running in the TwinCAT PLC declares a number of methods defining the interface with the Device Manager. Additionally, the device classes subscribe to the status data produced by the device controllers. Each time the status changes, the device classes are notified and they updates the Redis DB and publish the corresponding changes via ZeroMQ.
The PLC OPC-UA Server connects to the device controllers via the vendor specific protocol (ADS). The device controllers trigger the changes in the hardware via the TwinCAT I/O mapping.
Device Manager connecting to a Beckhoff IPC.
Supported Devices¶
Shutters¶
A Shutter device is a general purpose device for controlling a shutter hardware function. The device can control the shutter open/close.
Lamps¶
A Lamp device is a general purpose device for controlling a lamp hardware function. The device can switch a lamp on/off, control the intensity and handle warm-up and cool-down times when this is supported.
Motors¶
A Motor device is a general purpose device that controls different types of motors. It provides the following features:
- Support three different axis types: Linear, Circular and Circular Optimized. Circular Optimized means the motor will use always the shortest path to reach the target position.
- Definition of named positions in user units or encoder values.
- Arbitrary positioning given in user units or encoder values.
- Positioning in absolute or relative units.
- Support for configurable Initialization Sequence.
- Auto disabling when standing.
- Support brake handling.
- Support backlash compensation.
Sensors¶
A Sensor device is a device that collect instrument engineering variables with the aim of monitoring and recording the status of the instrument and their subsystems over time. It can be configured with a variable number of channels that are grouped logically. The Sensor device supports three different channel types: Digital input, Analog input and Integer input.
Derotators¶
A Derotator device is an aggregated motor device that continuously adapt its position according to the field or pupil rotation. It supports four different modes:
- Stationary: Derotator moves to a target position based on the position angle and remains standstill after reaching the target.
- Sky: The Derotator is Continuously moving to compensate for field rotation.
- Elevation: The Derotator is continuously moving to compensate for pupil rotation.
- User: The Derotator is continuously moving according to a customized computation of the position defined by the user.
ADCs¶
An ADC device manages the position of two mirrors with the aim of correcting the atmospheric dispersion.
The device supports two modes:
- Auto: The ADC is correcting continuously the position of the two motors based on the telescope RA/DEC, the environmental parameters and the ADC configuration.
- Off: The ADC moves to a target position and remains standstill after reaching the target.
Device Manager State Machine¶
The Device Manager uses a state machine described in a SCXML format that it is
interpreted by the state machine engine provided by the rad application framework.
(SCXML specification).
Device Manager State Machine Diagram.
Off –> NotReady, event: Startup
The Device Manager starts up and goes automatically to NotOperational/NotReady. Main server objects are instantiated including the basic application that uses the State Machine engine. The Device Manager reads its own configuration and completes its initialisation.
NotReady –> Ready, event: Init
The server connects to each of the device controllers through the device objects. Depending of the device configuration, the connection is to the normal HW or to the simulator. If any of the device objects fails to establish the connection, the server will remain in substate NotReady.
NotOperational/Ready –> Operational/Idle, event: Enable
The Device Managers goes through the enabling state. If Device Controllers are already operational, Device Manager does not affect their state and goes immediately to operational state. If Device Controllers are not operational, Device Manager will trigger the events (via OPC-UA method calls) to reach the operational state for each of the local devices under the manager control. If it does not succeed within the defined timeout (configuration parameter, see Device Manager Configuration), it will reply with a failure remaining in the NotOperational/Ready state. During the transition from NotOperational/Ready to Operational/Idle, the Device Manager downloads the configuration to each Device Controller. If at least one Device Controller cannot reach the operational state, Device Manager will remain in state NotOperational/Ready.
Operational/Idle –> Operational/Error, event: HwFailure
Problems in at least one of the managed devices will bring the Device Manager into a error state (Operational/Error). A typical example would be when the PLC, running the Device Controller, is power cycled.
Operational/Error –> Operational/Idle, event: HwNormal
Under the situation that an error condition is recovered, the Device Manager will go back automatically to Operational/Ready state (event HwNormal). For instance if the network connection is lost, the Device Manager will go to Error but when the network is restored the Device Manager will update its state automatically.
Operational –> NotOperational/Ready, event: Disable
The Device Manager disables the operation of devices by bringing Device Controllers to NotOperational/Ready. In case of error going from Operational to NotOperational/Ready, the end state will be nevertheless NotOperational/Ready.
NotOperational/Ready –> NotOperational/NotReady, event Reset
The subscription to the OPC-UA server will be stopped and sessions of the managed devices are disconnected. In case of error going from Ready to NotReady, the end state will be nevertheless NotReady.
Extract of the current State Machine specification for the Device Manager.
<state id="On">
<initial>
<transition target="NotOperational"/>
</initial>
<state id="NotOperational">
<initial>
<transition target="NotReady"/>
</initial>
<state id="NotReady">
<transition event="Events.Reset" target="NotReady">
<customActionDomain:ActionReset name="ActionReset"/>
</transition>
<transition event="Events.Init" target="Initialising"/>
<transition event="Events.Config">
<customActionDomain:ActionConfig name="ActionConfig"/>
</transition>
</state>
<state id="Initialising">
<onentry>
<customActionDomain:ActionInitStart name="ActionInitStart"/>
</onentry>
<invoke id="ActivityInitialising"/>
<transition event="Events.InitDone" target="Ready">
<customActionDomain:ActionInitDone name="ActionInitDone"/>
</transition>
<transition event="Events.InitError" target="NotReady">
<customActionDomain:ActionInitError name="ActionInitError"/>
</transition>
Configuration¶
Device Manager Configuration¶
The server configuration is a set of files using yaml format.
(YAML specification). YAML is easy to read format
that has been adopted temporary until the integration with CII configuration services.
There are in the web many resources about YAML. One could also validate the format online, see http://yaml.org/spec/
The entry point for the Device Manager configuration is one file that contains the server configuration and the mapping for the device configurations files that should be in separate files for better readability and maintenance. Each device type uses a mapping file defining the real names of the attributes in the OPC-UA address space.
Device Manager configuration files.
server_id
This is the id associated to the specific server. This id is used to associate all server configuration parameters as well as a prefix for the DB keys.
<server id>::req_endpoint
Thi is the endpoint for zeroMQ request/reply. The server will listen to incoming commands using this endpoint.
<server id>::sub_endpoint
This is the endpoint for internal subscriptions.
<server id>::pub_endpoint
This is the endpoint for publishing. Device class will publish using this endpoint.
<server id>::ext_sub_endpoint
This is the endpoint for client subscriptions. Clients can subscribe to the data published by server using this endpoint. The data published by the server will be encapsulated in topics.
<server id>::ext_pub_endpoint
This is the endpoint for zeroMQ internal publishing. Server will publish using this endpoint.
<server id>::db_endpoint
This is the endpoint used by the server for connecting to the Redis DB.
<server id>::db_timeout
This is the server timeout for connecting to the Redis DB.
<server id>::scxml
This is the state machine specification file used by the server.
<server id>::dictionaries
This is the list of dictionary files to be loaded by the server.
<server id>::devices
This is the list of devices active in the server configuration. Only devices listed here will be managed by the server.
<server id>::cmdtout
General command timeout for sending commands to the Local Control System (LCS).
<device id>::cfgfile
Configuration filename for a device.
An example of a server configuration is provided.
server_id : 'ins1.fcs1'
ins1.fcs1:
req_endpoint : "tcp://*:5577"
sub_endpoint : "tcp://localhost:5567"
pub_endpoint : "tcp://*:5567"
ext_pub_endpoint: "tcp://*:5557"
ext_sub_endpoint: "tcp://localhost:5557"
db_endpoint : "127.0.0.1:6379"
db_timeout : 2
scxml : "devmgr/server/sm.xml"
dictionaries : ['dit/stddid/primary.did', 'devmgr/server/fcf.did']
fits_prefix : "FCS1"
devices : ['lamp1', 'shutter1', 'motor1', 'drot1', 'adc1', 'sensor1']
cmdtout : 60000
shutter1:
type: Shutter
cfgfile: "devmgr/server/shutter1.yml"
lamp1:
type: Lamp
cfgfile: "devmgr/server/lamp1.yml"
motor1:
type: Motor
cfgfile: "devmgr/server/motor1.yml"
drot1:
type: Drot
cfgfile: "devmgr/server/drot1.yml"
adc1:
type: Adc
cfgfile: "devmgr/server/adc1.yml"
sensor1:
type: Sensor
cfgfile: "devmgr/server/sensor1.yml"
Device Base Configuration¶
Each device has a common set of configuration parameters.
<device id>::type
It specifies the type of the device. Valid types are: Shutter, Lamp, Motor, Sensor, Drot and Adc.
<device id>::interface
It defines the communication interface that will be used by the device. At present, the only valid value is: Softing. This is the name of the OPC-UA toolkit used to communicate to the LCS (PLC). The needed libraries are included in the installation of the ELT standard machine.
<device id>::identifier
It defines the PLC object identifier.
<device id>::namespace
It defines the OPC-UA address space number.
<device id>::prefix
It defines the prefix for the address space nodeId of the device.
<device id>::simulated
Flag indicating if device is simulated.
<device id>::ignored
Flag indicating if the device is ignored. When a device is ignored, the device will ignore most of the commands received by the server until it receives the stop ignoring command (StopIgn).
<device id>::mapfile
File providing the configuration of the attributes in the OPC address space per each of the supported device types.
An example of a mapping file configuration is included below.
Shutter:
cfg:
low_closed: cfg.bActiveLowClosed
low_fault: cfg.bActiveLowFault
low_open: cfg.bActiveLowOpen
low_switch: cfg.bActiveLowSwitch
ignore_closed: cfg.bIgnoreClosed
ignore_fault: cfg.bIgnoreFault
ignore_open: cfg.bIgnoreOpen
initial_state: cfg.bInitialState
timeout: cfg.nTimeout
stat:
state: stat.nState
substate: stat.nSubstate
local: stat.bLocal
error_code: stat.nErrorCode
rpc:
rpcInit: RPC_Init
rpcEnable: RPC_Enable
rpcDisable: RPC_Disable
rpcClose: RPC_Close
rpcOpen: RPC_Open
rpcStop: RPC_Stop
rpcReset: RPC_Reset
Note
With the information contained in the mapping file combined with the PLC prefix and the namespace, the device obtains the NodeId for each of the attributes and RPCs defined in the ICD with the device controller.
<device id>::fits_prefix
Prefix used by the device when generating the metadata information. This data is included in the FITS file generated by the server at the end of one exposure.
Shutter Specific Configuration¶
The Shutter device defines a set of configuration parameters that will be transferred
to the device controller running in the LCS (PLC). All these parameters are under the
ctrl_config heading.
Warning
The ctrl_config parameters are downloaded to the device controller when the device is not Operational. If the controller is already Operational, the user shall force the transition from Operational to NotOperational/NotReady and back to Operational.
| Config Item | Type | Optional | Default | Description |
|---|---|---|---|---|
| ctrl_config::low_closed | bool | yes | false | If true, the closed signal is active low. |
| ctrl_config::low_fault | bool | yes | false | If true, the fault signal is active low. |
| ctrl_config::low_open | bool | yes | false | If true, the open signal is active low. |
| ctrl_config::low_switch | bool | yes | false | If true, the switch signal is active low. |
| ctrl_config::ignore_closed | bool | yes | false | If true, the closed signal is ignored. |
| ctrl_config::ignore_fault | bool | yes | false | If true, the fault signal is ignored. |
| ctrl_config::ignore_open | bool | yes | false | If true, the open signal is ignored. |
| ctrl_config::initial_state | bool | yes | false | If true, the initial state for shutter will be open. |
| ctrl_config::timeout | uint | yes | 3000 [ms] | Shutter timeout for transitions. |
An example of a shutter configuration is provided below.
shutter1:
type: Shutter
interface: Softing
identifier: PLC1 # OPCUA Object Identifier
prefix: MAIN.Shutter1 # OPCUA attribute prefix
simulated: true
ignored: false
address: opc.tcp://134.171.59.98:4
simaddr: opc.tcp://127.0.0.1:7576 # Simulation address
mapfile: "devmgr/server/mapShutter.yml"
fits_prefix: "SHUT1"
ctrl_config:
low_closed: false # If T, signal is active low
low_fault: false # If T, signal is active low
low_open: false # If T, signal is active low
low_switch: false # If T, signal is active low
ignore_closed: false # If T, ignore the signal
ignore_fault: false # If T, ignore the signal
ignore_open: false # If T, ignore the signal
initial_state: false # If T, initial state is open
timeout: 2000
Lamp Specific Configuration¶
The Lamp device defines a set of configuration parameters that will be transferred
to the device controller running in the LCS (PLC). All these parameters are under the
ctrl_config heading.
Warning
The ctrl_config parameters are downloaded to the device controller when the device is not Operational. If the controller is already Operational, the user shall force the transition from Operational to NotOperational/NotReady and back to Operational.
| Config Item | Type | Optional | Default | Description |
|---|---|---|---|---|
| ctrl_config::low_fault | bool | yes | false | If true, the fault signal is active low. |
| ctrl_config::low_on | bool | yes | false | If true, the on signal is active low. |
| ctrl_config::low_switch | bool | yes | false | If true, the switch signal is active low. |
| ctrl_config::ignore_fault | bool | yes | false | If true, the fault signal is ignored. |
| ctrl_config::invert_analog | bool | yes | false | If true, the analog feedback is active. |
| ctrl_config::initial_state | bool | yes | false | If true, the initial state will be switched on. |
| ctrl_config::analog_threshold | int | yes | 0 [bits] | Analog feedback signal threshold |
| ctrl_config::analog_range | uint | yes | 32767 | Full range of A/D converter for analog output. |
| ctrl_config::cooldown | uint | yes | 0 [s] | Cooldown time. |
| ctrl_config::maxon | uint | yes | 0 [s] | Maximum time for the lamp to be On. |
| ctrl_config::warmup | uint | yes | 0 [s] | Warmup time. |
| ctrl_config::timeout | uint | yes | 3000 [ms] | Lamp timeout for transitions. |
An example of a lamp configuration is provided below. This configuration file can be found in module devmgr/server
lamp1:
type: Lamp
interface: Softing
identifier: PLC1 # OPCUA Object Identifier
prefix: MAIN.Lamp1 # OPCUA attribute prefix
simulated: false
ignored: false
address: opc.tcp://134.171.59.98:4840
simaddr: opc.tcp://134.171.12.182:4840 # Simulation address
mapfile: "devmgr/server/mapLamp.yml"
fits_prefix: "LAMP1"
ctrl_config:
low_fault: false # If T, signal is active low
low_on: false # If T, signal is active low
low_switch: false # If T, signal is active low
initial_state: false # If T, initial state is on
timeout: 2000
Sensor Specific Configuration¶
The sensor devices defines currently no configuration that will be downloaded to the LCS. However it defines the configuration of the sensor channels. The sensor channels are known only at the server side.
| Config Item | Type | Optional | Default | Description |
|---|---|---|---|---|
| ctrl_config::timeout | uint | yes | 3000 [ms] | Sensor timeout for transitions. |
| channels | vector | no | na | List of channels ids. |
| <channel id>::description | string | yes | “” | Channel description. |
| <channel id>::type | string | no | na | Channel type. Allowed types are: DI (bool), AI (double), II (integer), ST (string). |
| <channel id>::header | bool | yes | true | If true, the channel will be included in the metadata FITS file. |
| <channel id>::log | bool | yes | true | If true, the sensor value will be logged (Not available yet !). |
| <channel id>::map | string | no | na | Channel internal mapping to the name in the LCS. |
| <channel id>::prefix | string | no | na | Channel FITS prefix. |
| <channel id>::unit | string | yes | Channel unit. |
An example of a sensor configuration is provided below. This configuration file can be found in module devmgr/server. In this case, the sensor device has two channels: ch1 and ch2.
sensor1:
type: Sensor
alias: "my sensor1"
interface: Softing
identifier: PLC1
prefix: MAIN.IODev1
simulation: false
ignored: false
address: opc.tcp://134.171.59.98:4840
simaddr: opc.tcp://134.171.57.209:4840
mapfile: "devmgr/server/mapSensor.yml"
fits_prefix: "SENSOR1"
ctrl_config:
timeout: 20000
channels: ['ch1', 'ch2']
ch1:
description: "channel1"
fits_prefix: "CH1 STAT"
type: DI
header: true
log: true
unit: mm
map: di1
ch2:
description: "channel2"
fits_prefix: "CH2 STAT"
type: DI
header: true
log: true
unit: dd
map: di2
Motor Specific Configuration¶
The Motor device defines a set of configuration parameters that will be transferred
to the device controller running in the LCS (PLC). All these parameters are under the
ctrl_config heading.
The motor also defines a set of configuration parameters that are only known at the server level, for instance the named positions of the motor.
Warning
The ctrl_config parameters are downloaded to the device controller when the device is not Operational. If the controller is already Operational, the user shall force the transition from Operational to NotOperational/NotReady and back to Operational.
| Config Item | Type | Optional | Default | Description |
|---|---|---|---|---|
| ctrl_config::axis_type | string | yes | LINEAR | Axis type. Allowed options are: LINEAR, CIRCULAR and CIRCULAR_OPT. |
| ctrl_config::min_pos | double | yes | 0 [uu] | Minimum position in user units. |
| ctrl_config::max_pos | double | yes | 0 [uu] | Maximum position in user units. |
| ctrl_config::velocity | double | yes | 1.0 [uu/s] | Default velocity for moving the motor in position mode |
| ctrl_config::active_low_lstop | bool | yes | false | If true, the Lower Stop signal is active low. |
| ctrl_config::active_low_lhw | bool | yes | false | If true, the Lower Hw signal is active low. |
| ctrl_config::active_low_ref | bool | yes | false | If true, the Reference signal is active low. |
| ctrl_config::active_low_index | bool | yes | false | If true, the Index signal is active low. |
| ctrl_config::active_low_ustop | bool | yes | false | If true, the Upper Stop signal is active low. |
| ctrl_config::active_low_uhw | bool | yes | false | If true, the Upper Hw signal is active low. |
| ctrl_config::low_brake | bool | yes | false | If true, the Brake signal is active low. |
| ctrl_config::low_inpos | bool | yes | false | If true, the In Position signal is active low. |
| ctrl_config::backlash | double | yes | 0 [uu] | Backlash compensation. If value is zero means no backlash compensation is active. |
| ctrl_config::disable | bool | yes | false | If true, the power of the motor will be disabled after positioning. |
| ctrl_config::lock | bool | yes | false | If true, the motor position will be locked |
| ctrl_config::lock_pos | double | yes | 0 [uu] | Position that will be locked in case lock configuration is activated. |
| ctrl_config::lock_tolerance | double | yes | 0 [us] | Tolerance of the lock position |
| ctrl_config::tout_init | int | yes | 60000 [ms] | Motor initialisation timeout. |
| ctrl_config::tout_move | int | yes | 60000 [ms] | Motor move timeout. |
| ctrl_config::tout_switch | int | yes | 150000 [ms] | Motor timeout for going out of the switch during initialisation. |
Motor Initialisation¶
Note
The motor has a set of configuration parameters dedicated to the motor initialisation sequence. The initialisation sequence is downloaded to the LCS only when device controller is not operational.
<device id>::initialisation::sequence
List of motor initialization steps. The allowed steps are:
| Step | Description | Parameter 1 | Parameter 2 |
|---|---|---|---|
| END | Finish the sequence, no more actions are performed. | na | na |
| FIND_INDEX | Motor moves until finding the index pulse. | Fast velocity [UU/s] | Slow velocity [UU/s] |
| FIND_REF_LE | Motor moves until finding lower edge of reference switch. | Fast velocity [UU/s] | Slow velocity [UU/s] |
| FIND_REF_UE | Motor moves until finding upper edge of reference switch. | Fast velocity [UU/s] | Slow velocity [UU/s] |
| FIND_LHW | Motor moves until finding lower hardware limit. | Fast velocity [UU/s] | Slow velocity [UU/s] |
| FIND_UHW | Motor moves until finding upper hardware limit. | Fast velocity [UU/s] | Slow velocity [UU/s] |
| DELAY | Motor wait for a fixed amount of time before to continue. | time in [ms] | na |
| MOVE_ABS | Motor moves to an absolute position. | Velocity [UU/s] | Target position [UU] |
| MOVE_REL | Motor moves to a relative position. | Velocity [UU/s] | Target position [UU] |
| CALIB_ABS | Motor calibrates an absolute position. | Position [UU] | na |
| CALIB_REL | Motor calibrates a relative position. | Position [UU] | na |
| CALIB_SWITCH | Motor calibrates switch position. | Position [UU] | na |
Note
Some of the initialisation steps require parameters, for instance the speed of the motor. These parameters are defined together with the initialisation step.
<device id>::initialisation::<init step>::value1
Parameter 1 of the initialisation step.
<device id>::initialisation::<init step>::value2
Parameter 2 of the initialisation step.
Note
In case parameters are not applicable (na) please use 0 instead, for instance END, 0, 0
Named Positions¶
The motor device supports a configuration of named positions that associate specific motor position in user units (UU) to names. The aim of name positions is to facilitate the setting of motor positions by end users.
<device id>::positions::posnames
List of position names ids.
<device id>::positions::<posname id>
Value of the position name in user units (UU).
<device id>::positions::tolerance
Tolerance of the named position in user units (UU). If the actual position is within the tolerance, the device will report the named position otherwise its name will be empty.
Note
An example of a motor configuration is provided below. This configuration file can be found in module devmgr/server.
motor1:
type: Motor
interface: Softing
identifier: PLC1 # OPCUA Object Identifier
prefix: MAIN.Synchro1 # OPCUA attribute prefix
simulated: false
ignored: false
address: opc.tcp://134.171.59.98:4840
simaddr: opc.tcp://134.171.57.209:4840 # Simulation address
mapfile: "devmgr/server/mapMotor.yml"
fits_prefix: "MOT1"
ctrl_config:
velocity: 3.0
min_pos: 0.0
max_pos: 359.0
axis_type: CIRCULAR
active_low_lstop: false
active_low_lhw: false
active_low_ref: true
active_low_index: false
active_low_uhw: true
active_low_ustop: false
brake: false
low_brake: false
low_inpos: false
backlash: 0.0
tout_init: 30000
tout_move: 120000
tout_switch: 10000
initialisation:
sequence: ['FIND_LHW', 'FIND_UHW', 'CALIB_ABS', 'END']
FIND_LHW:
value1: 4.0
value2: 4.0
FIND_UHW:
value1: 4.0
value2: 4.0
CALIB_ABS:
value1: 0.0
value2: 0.0
END:
value1: 0.0
value2: 0.0
positions:
posnames: ['ON', 'OFF']
tolerance: 1 # Tolerance in UU
ON: 30
OFF: 100
Derotator Specific Configuration¶
As for the other devices, the Derotator device defines a set of configuration
parameters that will be transferred to the device controller running in the LCS
(PLC). All these parameters are under the ctrl_config heading.
Since the Derotator is just an aggregated motor device, it includes all Motor configuration parameters (see fcf_devmgr_motor_config_ref) plus few derotator specific ones.
Warning
The ctrl_config parameters are downloaded to the device controller when the device is not Operational. If the controller is already Operational, the user shall force the transition from Operational to NotOperational/NotReady and back to Operational.
| Config Item | Type | Optional | Default | Description |
|---|---|---|---|---|
| ctrl_config::dir_sign | int | yes | 1 | Motor direction sign |
| ctrl_config::focus_sign | int | yes | -1 | Focus direction sign. |
| ctrl_config::trk_period | int | yes | 20 [ms] | Period of the tracking corrections within the PLC. |
| ctrl_config::stat_ref | double | yes | 0.0 [uu] | Reference position for stationary mode. |
| ctrl_config::sky_ref | double | yes | 0.0 [uu] | Reference position for sky mode. |
| ctrl_config::user_ref | double | yes | 0.0 [uu] | Reference position for user mode. |
| ctrl_config::user_par1 | double | yes | 0.0 | Specific parameter 1 for user mode. |
| ctrl_config::user_par2 | double | yes | 0.0 | Specific parameter 2 for user mode. |
| ctrl_config::user_par3 | double | yes | 0.0 | Specific parameter 3 for user mode. |
| ctrl_config::user_par4 | double | yes | 0.0 | Specific parameter 4 for user mode. |
Note
An example of a Adc configuration is provided below. This configuration file can be found in module devmgr/server.
drot1:
type: Drot
interface: Softing
identifier: PLC1 # OPCUA Object Identifier
prefix: MAIN_FAST.drot # OPCUA attribute prefix
simulated: false
ignored: false
address: opc.tcp://134.171.59.98:4840
simaddr: opc.tcp://134.171.57.209:4840 # Simulation address
mapfile: "devmgr/server/mapDrot.yml"
fits_prefix: "DROT1"
ctrl_config:
latitude: -0.429833092
longitude: 1.228800386
velocity: 3.0
min_pos: -359
max_pos: 359.0
axis_type: CIRCULAR
active_low_lstop: false
active_low_lhw: false
active_low_ref: true
active_low_index: false
active_low_uhw: true
active_low_ustop: false
brake: false
low_brake: false
low_inpos: false
backlash: 0.0
tout_init: 30000
tout_move: 120000
tout_switch: 10000
initialisation:
sequence: ['FIND_LHW', 'FIND_UHW', 'CALIB_ABS', 'END']
FIND_LHW:
value1: 4.0
value2: 4.0
FIND_UHW:
value1: 4.0
value2: 4.0
CALIB_ABS:
value1: 0.0
value2: 0.0
END:
value1: 0.0
value2: 0.0
positions:
posnames: ['ON', 'OFF']
tolerance: 1 # Tolerance in UU
ON: 30
OFF: 100
Derotator Control¶
Operation modes¶
| Alias | Name | Description |
|---|---|---|
| eng | Engineering | Under this mode, the Derotator behaves like a normal motor. This means it can be moved in user units and encoders. |
| stat | Stationary | Under this mode, the Derotator is stationary and it can be positioned at given angle according the following formula: pos := stat_ref + dir_sign * (posang)/2.0; |
| sky | Sky | The Derotator tracks following the field rotation. fieldRotation := parallactic - focus_sign * altitude; pos := sky_ref + dir_sign * (posang - fieldRotation)/2; angleOnSky := posang; modeAngle := angleOnSky; |
| elev | Elevation | The Derotator tracks following the pupil rotation. pos := elev_ref + (focus_sign * dir_sign * altitude) /2.0; angleOnSky := parallactic; modeAngle := angleOnSky; |
| user | User | The Derotator tracks according user custom computation. |
ADC Specific Configuration¶
As for the other devices, the ADC device defines a set of configuration
parameters that will be transferred to the device controller running in the LCS
(PLC). These parameters are under the ctrl_config heading. Considering that
the ADC is a multi-axis device, it includes as well the configuration of two
standard motor devices. The configuration of each of the motor devices is defined
in separate files and they correspond to the configuration of a standard motor
device (see fcf_devmgr_motor_config_ref).
Warning
The ctrl_config parameters are downloaded to the device controller when the device is not Operational. If the controller is already Operational, the user shall force the transition from Operational to NotOperational/NotReady and back to Operational.
| Config Item | Type | Optional | Default | Description |
|---|---|---|---|---|
| ctrl_config::axes | list | no | List of motors controlled by the ADC | |
| ctrl_config::trk_period | int | yes | 20 [ms] | Period of the tracking corrections within the PLC. |
| ctrl_config::pslope | double | yes | 0.0023 [arcsec/mbar] | Pressure slope. |
| ctrl_config::poffset | double | yes | 743.0 [mbar] | Pressure offset. |
| ctrl_config::tslope | double | yes | -0.0061 [arcsec/C] | Temperature slope. |
| ctrl_config::toffset | double | yes | 12 [C] | Temperature offset. |
| ctrl_config::afactor | double | yes | 3.32 [1/arcsec] | A Factor |
| ctrl_config::zdlimit | double | yes | 0.0174533 | Zenith distance limit |
| ctrl_config::minelev | double | yes | 27.64 [deg] | Minimum Elevation. |
| ctrl_config::mot1_signoff | int | yes | 1 | Motor 1 sign for off mode |
| ctrl_config::mot1_signauto | int | yes | 1 | Motor 1 sign for auto mode |
| ctrl_config::mot1_signphi | int | yes | 1 | Motor 1 sign for phi |
| ctrl_config::mot1_refoff | double | yes | 0 [deg] | Motor 1 offset for off mode |
| ctrl_config::mot1_refauto | double | yes | 0 [deg] | Motor 1 offset for auto mode |
| ctrl_config::mot1_coffset | double | yes | 1.7387 [arcsec] | Motor 1 C parameter |
| ctrl_config::mot1_poffset | double | yes | 90 [deg] | Motor 1 Position offset |
| ctrl_config::mot1_drotfactor | double | yes | 2 | Motor 1 derotator offset |
| ctrl_config::mot2_signoff | int | yes | 1 | Motor 2 sign for off mode |
| ctrl_config::mot2_signauto | int | yes | 1 | Motor 2 sign for auto mode |
| ctrl_config::mot2_signphi | int | yes | 1 | Motor 2 sign for phi |
| ctrl_config::mot2_refoff | double | yes | 0 [deg] | Motor 2 reference position for off mode |
| ctrl_config::mot2_refauto | double | yes | 0 [deg] | Motor 2 reference position for auto mode |
| ctrl_config::mot2_coffset | double | yes | 1.7387 [arcsec] | Motor 2 C parameter |
| ctrl_config::mot2_poffset | double | yes | 90 [deg] | Motor 2 Position offset |
| ctrl_config::mot2_drotfactor | double | yes | 2 | Motor 2 derotator offset |
| <motor1>::prefix | string | no | Internal name used by the ADC for motor1 (fixed) | |
| <motor1>::cfgfile | string | no | File path for the motor 1 configuration. | |
| <motor2>::prefix | string | no | Internal name used by the ADC for motor2 (fixed) | |
| <motor2>::cfgfile | string | no | File path for the motor 2 configuration. | |
Note
An example of a Adc configuration is provided below. This configuration file can be found in module devmgr/server.
adc1:
type: Adc
interface: Softing
identifier: PLC1 # OPCUA Object Identifier
prefix: MAIN_FAST.adc # OPCUA attribute prefix
simulated: false
ignored: false
address: opc.tcp://134.171.59.98:4840
simaddr: opc.tcp://134.171.57.209:4840 # Simulation address
mapfile: "devmgr/server/mapAdc.yml"
fits_prefix: "ADC1"
ctrl_config:
axes: ['adc1_motor1', 'adc1_motor2']
adc1_motor1:
prefix: "motor1"
cfgfile: "devmgr/server/adc1Motor1.yml"
adc1_motor2:
prefix: "motor2"
cfgfile: "devmgr/server/adc1Motor2.yml"
ADC Control¶
Operation modes¶
The ADC operates two motorized functions. In engineering mode, each motor can be controlled independently.
| Alias | Name | Description |
|---|---|---|
| eng | Engineering | Under this mode, the ADC behaves like a normal motor. This means that each motor can be moved in user units and encoders. |
| off | Off | Under this mode, the ADC is stationary and it can be positioned at given angle according the following formula: pos := off_ref + sign_off * posang; |
| auto | Auto | The ADC tracks following a default formula. This formula can be replaced to accommodate to instrument specific requirements. |
Database Attributes¶
The Device Manager uses the Redis DB to store the actual server configuration and run-time parameters. The Redis keys used by the server follow a hierarchical naming convention starting with the id of the server. Specific keys for devices use the id of the device in the name. The DB keys can be monitored using the dbbrowser utility. All Device Manager keys have a flat structure in Redis DB.
dbbrowser utility
Server configuration¶
The server store into the Redis DB the actual values of the server configuration parameters. This helps to verify whether the configuration has been loaded correctly. For details of the server configuration parameters, see Device Manager Configuration.
| Redis Key |
|---|
| <server id>.cfg.db_endpoint |
| <server id>.cfg.db_timeout |
| <server id>.cfg.device |
| <server id>.cfg.dictionaries |
| <server id>.cfg.filename |
| <server id>.cfg.loglevel |
| <server id>.cfg.req_endpoint |
| <server id>.cfg.scxml |
Server Status¶
The server store into the Redis DB the string representation of its state and substate.
| Redis Key |
|---|
| <server id>.cfg.state_str |
| <server id>.cfg.substate_str |
Common Device Keys¶
Each device has a number of common Redis DB keys.
| Redis Key |
|---|
| <server id>.<device id>.cfg.address |
| <server id>.<device id>.cfg.simaddr |
| <server id>.<device id>.cfg.cfgfile |
| <server id>.<device id>.cfg.fits_prefix |
| <server id>.<device id>.cfg.ignored |
| <server id>.<device id>.cfg.simulated |
| <server id>.<device id>.cfg.namespace |
| <server id>.<device id>.cfg.prefix |
| <server id>.<device id>.cfg.type |
Shutter¶
Each shutter device has the following Redis DB keys:
| Redis Key |
|---|
| <server id>.<device id>.lcs.cfg.ignore_closed |
| <server id>.<device id>.lcs.cfg.ignore_fault |
| <server id>.<device id>.lcs.cfg.ignore_open |
| <server id>.<device id>.lcs.cfg.initial_state |
| <server id>.<device id>.lcs.cfg.low_closed |
| <server id>.<device id>.lcs.cfg.low_fault |
| <server id>.<device id>.lcs.cfg.low_open |
| <server id>.<device id>.lcs.cfg.low_switch |
| <server id>.<device id>.lcs.cfg.timeout |
| <server id>.<device id>.lcs.stat.error_code |
| <server id>.<device id>.lcs.stat.error_str |
| <server id>.<device id>.lcs.stat.local |
| <server id>.<device id>.lcs.stat.state |
| <server id>.<device id>.lcs.stat.substate |
Lamp¶
Each lamp device has the following Redis DB keys:
| Redis Key |
|---|
| <server id>.<device id>.lcs.cfg.analog_range |
| <server id>.<device id>.lcs.cfg.analog_threshold |
| <server id>.<device id>.lcs.cfg.cooldown |
| <server id>.<device id>.lcs.cfg.ignore_fault |
| <server id>.<device id>.lcs.cfg.initial_state |
| <server id>.<device id>.lcs.cfg.invert_analog |
| <server id>.<device id>.lcs.cfg.low_fault |
| <server id>.<device id>.lcs.cfg.low_on |
| <server id>.<device id>.lcs.cfg.low_switch |
| <server id>.<device id>.lcs.cfg.maxon |
| <server id>.<device id>.lcs.cfg.timeout |
| <server id>.<device id>.lcs.cfg.warmup |
| <server id>.<device id>.lcs.stat.error_code |
| <server id>.<device id>.lcs.stat.error_str |
| <server id>.<device id>.lcs.stat.intensity |
| <server id>.<device id>.lcs.stat.local |
| <server id>.<device id>.lcs.stat.state |
| <server id>.<device id>.lcs.stat.substate |
Sensor¶
Each sensor device has the following Redis DB keys:
| Redis Key |
|---|
| <server id>.<device id>.cfg.channels.<channel id>.description |
| <server id>.<device id>.cfg.channels.<channel id>.fits_prefix |
| <server id>.<device id>.cfg.channels.<channel id>.header |
| <server id>.<device id>.cfg.channels.<channel id>.log |
| <server id>.<device id>.cfg.channels.<channel id>.map |
| <server id>.<device id>.cfg.channels.<channel id>.type |
| <server id>.<device id>.cfg.channels.<channel id>.unit |
| <server id>.<device id>.lcs.stat.<channel id> |
| <server id>.<device id>.lcs.stat.state |
| <server id>.<device id>.lcs.stat.substate |
Motor¶
Each motor device has the following Redis DB keys:
| Redis Key |
|---|
| <server id>.<device id>.lcs.cfg.active_low_indec |
| <server id>.<device id>.lcs.cfg.active_low_lhw |
| <server id>.<device id>.lcs.cfg.active_low_lstop |
| <server id>.<device id>.lcs.cfg.active_low_ref |
| <server id>.<device id>.lcs.cfg.active_low_uhw |
| <server id>.<device id>.lcs.cfg.active_low_ustop |
| <server id>.<device id>.lcs.cfg.axis_type |
| <server id>.<device id>.lcs.cfg.backlash |
| <server id>.<device id>.lcs.cfg.brake |
| <server id>.<device id>.lcs.cfg.check_inpos |
| <server id>.<device id>.lcs.cfg.disable |
| <server id>.<device id>.lcs.cfg.exec_post_init |
| <server id>.<device id>.lcs.cfg.exec_post_move |
| <server id>.<device id>.lcs.cfg.exec_pre_init |
| <server id>.<device id>.lcs.cfg.exec_pre_move |
| <server id>.<device id>.lcs.cfg.init_seq<number>_action |
| <server id>.<device id>.lcs.cfg.init_seq<number>_value1 |
| <server id>.<device id>.lcs.cfg.init_seq<number>_value2 |
| <server id>.<device id>.lcs.cfg.lock |
| <server id>.<device id>.lcs.cfg.lock_pos |
| <server id>.<device id>.lcs.cfg.lock_tolerance |
| <server id>.<device id>.lcs.cfg.low_brake |
| <server id>.<device id>.lcs.cfg.low_inpos |
| <server id>.<device id>.lcs.cfg.max_pos |
| <server id>.<device id>.lcs.cfg.min_pos |
| <server id>.<device id>.lcs.cfg.tout_init |
| <server id>.<device id>.lcs.cfg.tout_move |
| <server id>.<device id>.lcs.cfg.tout_switch |
| <server id>.<device id>.lcs.cfg.velocity |
| <server id>.<device id>.lcs.stat.axis_brake |
| <server id>.<device id>.lcs.stat.axis_enable |
| <server id>.<device id>.lcs.stat.axis_info_data1 |
| <server id>.<device id>.lcs.stat.inposition |
| <server id>.<device id>.lcs.stat.lock |
| <server id>.<device id>.lcs.stat.ready |
| <server id>.<device id>.lcs.stat.error_code |
| <server id>.<device id>.lcs.stat.error_str |
| <server id>.<device id>.lcs.stat.init_action |
| <server id>.<device id>.lcs.stat.init_step |
| <server id>.<device id>.lcs.stat.initialised |
| <server id>.<device id>.lcs.stat.local |
| <server id>.<device id>.lcs.stat.mode |
| <server id>.<device id>.lcs.stat.pos_actual |
| <server id>.<device id>.lcs.stat.pos_error |
| <server id>.<device id>.lcs.stat.pos_target |
| <server id>.<device id>.lcs.stat.scale_factor |
| <server id>.<device id>.lcs.stat.signal_index |
| <server id>.<device id>.lcs.stat.signal_lhw |
| <server id>.<device id>.lcs.stat.signal_lstop |
| <server id>.<device id>.lcs.stat.signal_ref |
| <server id>.<device id>.lcs.stat.signal_uhw |
| <server id>.<device id>.lcs.stat.signal_ustop |
| <server id>.<device id>.lcs.stat.state |
| <server id>.<device id>.lcs.stat.substate |
| <server id>.<device id>.lcs.stat.vel_actual |
| <server id>.<device id>.pos_actual_name |
| <server id>.<device id>.pos_enc |
| <server id>.<device id>.target_enc |
Derotator¶
The Derotator device uses the same set of Redis keys as the Motor device plus some additional ones that are described below:
| Redis Key |
|---|
| <server id>.<device id>.lcs.cfg.trk_period |
| <server id>.<device id>.lcs.cfg.user_par1 |
| <server id>.<device id>.lcs.cfg.user_par2 |
| <server id>.<device id>.lcs.cfg.user_par3 |
| <server id>.<device id>.lcs.cfg.user_par4 |
| <server id>.<device id>.lcs.cfg.user_ref |
| <server id>.<device id>.lcs.cfg.sky_ref |
| <server id>.<device id>.lcs.cfg.stat_ref |
| <server id>.<device id>.lcs.stat.angle_on_sky |
| <server id>.<device id>.lcs.stat.alpha |
| <server id>.<device id>.lcs.stat.delta |
| <server id>.<device id>.lcs.stat.track_mode |
ADC¶
The Adc device uses the following set of Redis keys:
| Redis Key |
|---|
| <server id>.<device id>.lcs.cfg.trk_period |
| <server id>.<device id>.lcs.cfg.afactor |
| <server id>.<device id>.lcs.cfg.minelev |
| <server id>.<device id>.lcs.cfg.poffset |
| <server id>.<device id>.lcs.cfg.pslope |
| <server id>.<device id>.lcs.cfg.toffset |
| <server id>.<device id>.lcs.cfg.tslope |
| <server id>.<device id>.lcs.cfg.zdlimit |
| <server id>.<device id>.lcs.cfg.mot1_coffset |
| <server id>.<device id>.lcs.cfg.mot1_drotfactor |
| <server id>.<device id>.lcs.cfg.mot1_poffset |
| <server id>.<device id>.lcs.cfg.mot1_refauto |
| <server id>.<device id>.lcs.cfg.mot1_refoff |
| <server id>.<device id>.lcs.cfg.mot2_coffset |
| <server id>.<device id>.lcs.cfg.mot2_drotfactor |
| <server id>.<device id>.lcs.cfg.mot2_poffset |
| <server id>.<device id>.lcs.cfg.mot2_refauto |
| <server id>.<device id>.lcs.cfg.mot2_refoff |
| <server id>.<device id>.cfg.ignored |
| <server id>.<device id>.cfg.simulated |
| <server id>.<device id>.lcs.stat.alpha |
| <server id>.<device id>.lcs.stat.delta |
| <server id>.<device id>.lcs.stat.error_code |
| <server id>.<device id>.lcs.stat.error_str |
| <server id>.<device id>.lcs.stat.local |
| <server id>.<device id>.lcs.stat.state |
| <server id>.<device id>.lcs.stat.substate |
| <server id>.<device id>.lcs.stat.track_mode |
| <server id>.<device id>.lcs.stat.motor1.axis_brake |
| <server id>.<device id>.lcs.stat.motor1.axis_enable |
| <server id>.<device id>.lcs.stat.motor1.axis_lock |
| <server id>.<device id>.lcs.stat.motor1.local |
| <server id>.<device id>.lcs.stat.motor1.pos_actual |
| <server id>.<device id>.lcs.stat.motor1.pos_enc |
| <server id>.<device id>.lcs.stat.motor1.scale_factor |
| <server id>.<device id>.lcs.stat.motor2.axis_brake |
| <server id>.<device id>.lcs.stat.motor2.axis_enable |
| <server id>.<device id>.lcs.stat.motor2.axis_lock |
| <server id>.<device id>.lcs.stat.motor2.local |
| <server id>.<device id>.lcs.stat.motor2.pos_actual |
| <server id>.<device id>.lcs.stat.motor2.pos_enc |
| <server id>.<device id>.lcs.stat.motor2.scale_factor |
| <server id>.<device id>.motor1.pos_enc |
| <server id>.<device id>.motor2.pos_enc |
Commands¶
The commands currently supported by the server are listed here: List of Commands.
Serialization¶
The Device Manager uses the Google Protocol Buffer for serialising commands.
Note
Each command has two parts: a request and its corresponding reply, see the example below taken from the modif module.
message ReqInit {
}
message RepInit {
optional ReplyInfo info = 1;
optional string reply = 2;
}
message Timestamp {
optional int64 seconds = 1;
optional int32 nanos = 2;
}
message ReplyInfo {
optional Timestamp timestamp = 1;
optional bool error = 2;
optional bool aborted = 3;
optional bool timeout = 4;
optional bool completed = 5;
}
Setup Command¶
The command Setup is intended to produce a change in the run-time configuration. It is is possible to switch a lamp on, close a shutter or move a motor in separate messages or within the same one. This means the contents of the message varies. The DevMgr will de-serialise the message and communicate to the corresponding PLCs the actions to be taken.
The DevMgr is not blocked when receiving concurrent Setup commands (messages). It executes them is separate worker threads that are spawn per each new Setup command. The threads will be running until the commands are executed successfully, an error occurs, the timeout is elapsed or a Stop command is received, see figure below.
Device Manager Setup worker threads.
Note
A Stop command finalizes all ongoing worker threads being handled by the Device Manager.
Warning
Conflicting requests across different Setup commands running in parallel are not handled by the Device Manager. They are pushed down to the PLC. The PLC is resolving depending of the actual status. This means if you send two consecutive commands with contradictory requests, most likely the second one will get an error from the PLC. The exact behaviour will depend on the specific Device Controller implementation.
The Protobuf definition of the Setup command request is shown below.
message ReqSetup {
repeated Fcs fcs = 1;
}
message Fcs {
required string id = 1;
repeated Lamp lamp = 2;
repeated Shutter shutter = 3;
repeated Motor motor = 4;
repeated Drot drot = 5;
repeated Adc adc = 6;
}
message Lamp {
required string id = 1;
optional float intensity = 2;
optional uint32 time = 3;
enum ActionLamp {
ON = 0;
OFF = 1;
}
optional ActionLamp action = 4;
}
message Shutter {
required string id = 1;
enum ActionShutter {
OPEN = 0;
CLOSE = 1;
}
optional ActionShutter action = 2;
}
message Motor {
required string id = 1;
optional string name = 2;
optional float pos = 3;
optional int64 enc = 4;
optional float speed = 5;
enum PosUnit {
ENC = 100;
UU = 101;
}
optional PosUnit unit = 6;
enum ActionMotor {
MOVE_REL = 50;
MOVE_ABS = 51;
MOVE_BY_NAME = 52;
MOVE_BY_SPEED = 53;
}
optional ActionMotor action = 7;
}
message Drot {
required string id = 1;
optional string name = 2;
optional float pos = 3;
optional int64 enc = 4;
optional float speed = 5;
enum PosUnit {
ENC = 100;
UU = 101;
}
optional PosUnit unit = 6;
enum ActionDrot {
MOVE_REL = 50;
MOVE_ABS = 51;
MOVE_BY_NAME = 52;
MOVE_BY_SPEED = 53;
MOVE_BY_POSANG= 54;
START_TRACK = 100;
STOP_TRACK = 101;
}
enum ModeName {
SKY = 2;
ELEV = 3;
USER = 4;
}
optional ModeName mode = 7;
optional ActionDrot action = 8;
}
message Adc {
required string id = 1;
optional string name = 2;
enum AxisId {
ALL = 0;
ADC1 = 1;
ADC2 = 2;
}
optional AxisId axisid = 3;
optional float pos = 4;
optional int64 enc = 5;
optional float speed = 6;
enum PosUnit {
ENC = 100;
UU = 101;
}
optional PosUnit unit = 7;
enum ActionAdc {
MOVE_REL = 50;
MOVE_ABS = 51;
MOVE_BY_NAME = 52;
MOVE_BY_SPEED = 53;
MOVE_BY_POSANG= 54;
START_TRACK = 100;
STOP_TRACK = 101;
}
optional ActionAdc action = 8;
}
message RepSetup {
optional ReplyInfo info = 1;
optional string reply = 2;
}
Status Command¶
The status command provides information about each device controlled by the devmgr. An example of the output generated by the Status command is shown below.
devmgrClient 5000 localhost 5577 modif.ReqStatus ""
shutter1.simulated = true
shutter1.lcs.state = Operational
shutter1.lcs.substate = Close
lamp1.simulated = true
lamp1.lcs.state = Operational
lamp1.lcs.substate = Off
lamp1.lcs.intensity = 0.000000
motor1.simulated = true
motor1.lcs.state = Operational
motor1.lcs.substate = Standstill
motor1.lcs.pos_target = 30.000000
motor1.lcs.pos_actual = 30.002197
motor1.lcs.vel_actual = 0.000000
motor1.lcs.axis_enable = true
motor1.pos_actual_name = ON
motor1.pos_enc = 341
Ignore Command¶
This command tells the devmgr to ignore completely a device. It can be used when there are hardware failures or when the hardware is not yet available. The following example shows a sequence that ignore the device lamp1, get the status of the devices and then stop ignoring the device.
Note
When a device is ignored, no other information is provided for this device when processing the status command.
devmgrClient 5000 localhost 5577 modif.ReqIgnore "lamp1"
devmgrClient 5000 localhost 5577 modif.ReqStatus ""
shutter1.simulated = true
shutter1.lcs.state = Operational
shutter1.lcs.substate = Close
lamp1.ignored = true
motor1.simulated = true
motor1.lcs.state = Operational
motor1.lcs.substate = Standstill
motor1.lcs.pos_target = 30.000000
motor1.lcs.pos_actual = 30.002197
motor1.lcs.vel_actual = 0.000000
motor1.lcs.axis_enable = true
motor1.pos_actual_name = ON
motor1.pos_enc = 341
devmgrClient 5000 localhost 5577 modif.ReqStopIgn "lamp1"
Simulate Command¶
This command tells the devmgr to use the simulation address of the device. If the devmgr is already connected, it will disconnect from the normal address and connect to the simulation one. When the simulation is stopped it revert the actions.
The purpose of the simulation is to be able to validate the response of the devmgr under different error conditions. It also allows to test the high-level SW when the HW is not yet available.
devmgrClient 5000 localhost 5577 modif.ReqSimulate "lamp1"
devmgrClient 5000 localhost 5577 modif.ReqStatus ""
shutter1.simulated = true
shutter1.lcs.state = Operational
shutter1.lcs.substate = Close
lamp1.simulated = true
lamp1.lcs.state = Operational
lamp1.lcs.substate = Off
lamp1.lcs.intensity = 0.000000
motor1.simulated = true
motor1.lcs.state = Operational
motor1.lcs.substate = Standstill
motor1.lcs.pos_target = 30.000000
motor1.lcs.pos_actual = 30.002197
motor1.lcs.vel_actual = 0.000000
motor1.lcs.axis_enable = true
motor1.pos_actual_name = ON
motor1.pos_enc = 341
devmgrClient 5000 localhost 5577 modif.ReqStopSim "lamp1"
Troubleshooting¶
Logging¶
The devmgr has implemented six logging levels that gives to the developer additional information for troubleshooting.
| Name | Verbosity | Description |
|---|---|---|
| ERROR | very low | Provide logging only in case errors. |
| INFO | low | Provide information for the most important actions (default). |
| DEBUG | medium | Provide additional information for the developer. |
| DEBUG2 | high | Includes more details such as Node IDs of OPC-UA attributes |
| DEBUG3 | high | Includes the logging of each subscription event. |
| TRACE | very high | Includes all the function tracing. |
To activate a new logging, the command SetLog shall be used. See the example below.
devmgrClient 5000 localhost 5577 modif.ReqSetLog "DEBUG"
OPC-UA Client¶
Sometimes is better to check the status of the PLC using an OPC-UA client. One of the best tools available is UaExpert from Unified Automation. This tool enables control and monitor of all variables of the devices independently of the devmgr. The user can trigger the execution of RPCs and monitor the device state changes. UaExpert is a essential tool for troubleshooting.
UaExpert OPC-UA client.