Realtime Port Configuration
The voraus EtherCAT Master provides two interfaces for exposing PDO variables:
OPC UA
voraus realtime port
The port configuration is used to configure these interfaces and assign variables to them.
Default Configuration
By default, the master assigns all PDO variables to the OPC UA interface, as defined in the default configuration in the file
/etc/voraus/voraus-ethercat-master/port_config.json.
Since OPC UA is not a realtime protocol, the timeout is disabled by default.
{
"ports": {
"ecat-internal-opcua": {
"_comment": "By default, all variables will be exposed via OPC UA.",
"timeout_cycles": 0,
"requires": "*",
"provides": "*",
"echoes": "*"
}
}
}
Add a Realtime Port
The default configuration file can be modified or overwritten, or a custom configuration file can be provided (see Configuration).
Additional realtime ports can be appended to the ports list:
{
"ports": {
"ecat-internal-opcua": {
"_comment": "By default, all variables will be exposed via OPC UA.",
"timeout_cycles": 0,
"requires": "*",
"provides": "*",
"echoes": "*"
},
"my-robot-port": {
"timeout_cycles": 2,
"requires": "Drive*",
"provides": "Drive*"
},
"my-di-port": {
"provides": [
"IOModule.DI8.Inputs.DigitalInput 1",
"IOModule.DI8.Inputs.DigitalInput 2"
]
}
}
}
Field Descriptions
ports: A mapping of port names to their configuration objects.
Note: “ecat-internal-opcua” is used internally to map variables to the OPC UA server. All variables assigned to this port will be exposed externally via OPC UA.
timeout_cycles: (integer) Timeout in number of cycles for the port. The EtherCAT master will go into an error state after N cycles if no data is updated on this port. I.e. a timeout value of 1 means that the master will immediately go into an error state if data was not updated. A value of 0 means the timeout is disabled. The default value is 3 cycles. Note: the master only checks that any input on this port was written - not each single PDO.
requires: (string or array of strings) Output variables that the port requires from the application (e.g. Digital Output, Controlword).
provides: (string or array of strings) Input variables that the port provides to the application (e.g. Digital Input, Statusword).
echoes: (string or array of strings) Output variables that will be echoed to input variables. This can be useful in setups with multiple ports with different access restrictions. E.g. if application A writes a controlword to port A as output, then application B can read that controlword as input on another port B (read-only).
Note: OPC UA and voraus realtime port handle read/write permissions differently. Echoed variables for the OPC UA server will be added to the “Outputs” node (like required variables), but with read-only access. For realtime ports, echoed variables will appear as “inputs” to the application (like provided variables). I.e the OPC UA server will only add ‘echoed’ variables if they are not already in the ‘required’ list.
_comment: For documentation purposes only; ignored by the application.
All fields are optional and use defaults if not specified. The default variable assignment is empty and the default timeout is 3 cycles.
Wildcard Patterns and Matching Behavior
Glob-style wildcard patterns (e.g. *DigitalInput or Drive[1-4]*) can be used in requires, provides, and echoes fields to control which variables are accessible through each port.
The matching behavior differs between required variables and provided/echoed variables.
For required variables, each variable can only be assigned exclusively to one port (to avoid conflicts).
Matches are processed in the order from most-specific to least-specific (e.g. Term 1* is more specific than Term* - assuming that multiple terminals Term 1*, Term 2*, … exist).
Matches that cannot be resolved unambiguously will be treated as errors.
For provided and echoed variables, multiple matches are allowed (e.g. * will always resolve to all variables).