Documentation Home Page ◇ RT-LAB Home Page
Pour la documentation en FRANÇAIS, utilisez l'outil de traduction de votre navigateur Chrome, Edge ou Safari. Voir un exemple.
EtherCAT Master
EtherCAT Master
This document describes the procedure of working with EtherCAT Master in RT-LAB versions 10.7 (starting from 10.7.2) and 11.1.1 or later (2019+). The present EtherCAT driver is based on the SOEM library (Simple Open EtherCAT Master).
This driver requires two working Ethernet ports on the simulator on which it will be run. One port is needed for the communication with the host (the Windows PC where RT-LAB is running) while the other port is needed to connect to the network of EtherCAT slaves.
Supported Features
Features | Description |
---|---|
Choice of Operating System | RedHat, OPAL-RTLinux (with come conditions, see Limitations section) |
Slave compatibility | The driver has been tested with some of Beckhoff’s analog I/Os (including 0-10V output, 4-20mA input and 4-20mA output), digital I/Os, and relay terminals as well as servo motors from Elmo. For a full list of supported terminals, please check the list of supported modules at the end of this document. |
Multi master (on separate networks) | You can have several masters running in the same model/machine as long as they are not part of the same EtherCAT network. As an example, this feature can be used when having a large number of terminals that can be divided into groups sharing the same purpose and/or timestep. |
Watchdog | The watchdog attempts to recover slaves in an error state. |
CAN over EtherCAT | EtherCAT protocol can be used on devices equipped with CANopen by SOEM library. |
Files Needed by the Driver
There are two configuration files needed by the driver. One is meant to configure the driver itself and its method of functioning and the other is meant to configure how the data will be exchanged between it and the Simulink model. These two files must be transferred to the simulator when the Simulink model is loading. In order to achieve that, the files need to be added in the model's "Files" list in RT-LAB as shown below:
These two files are described in more detail in the two following sections.
Configuring the Driver
The configuration of the driver along with any extra information about some of the slaves in the network is presented in the "*_cfg.opal" file (seen as "ethercat_master_cfg.opal" file in the image above). We recommend using the configuration from the example models as a working basis.
An example of the file used for configuration when an Elmo drive is present is given below:
OPAL-1.0 Object
EtherCAT::Master::Configuration {
waitSlavesOP = 1
launchWatchdog = 0
networkInterface = eth1
customInitialization {
item {
key = 1
value {
forceGenericDriver=0
options {
Profile:Multimode
InterpolationTime:10
ResetCounter:1
}
}
}
}
}
Here is an example of the configuration when Beckhoff's FC1100 card is present in the slaves chain:
OPAL-1.0 Object
EtherCAT::Master::Configuration {
waitSlavesOP = 1
launchWatchdog = 1
networkInterface = eth1
customInitialization {
item {
key = 1
value {
pdoSetup {
item {
name=BIT_in
type=BIT
direction=SLAVE_TO_MASTER
byteOffset=0
bitOffset=2
}
item {
name=BYTE_out
type=BYTE
direction=MASTER_TO_SLAVE
byteOffset=1
}
}
}
}
}
}
Warning: Please note that the parser is currently quite sensitive and does not accept blank lines or comments.
The description of each of the options is as follows:
Parameter | Description | Accepted Values |
---|---|---|
verbose | If set, the driver will output the slave topology that it is connected to and information about each slave in the network. It will also output the size of the physical memory it is using. Use this feature when preparing the connections.opal file (described further below) and unsure of the position of the slaves within the network. | 0 (not set) or 1 (set) |
waitSlavesOP | If set, the driver will wait for all the slaves in the network to be operational before exchanging data. | 0 (not set) or 1 (set) |
launchWatchdog | If set, the watchdog of the driver will be activated. | 0 (not set) or 1 (set) |
networkInterface | This string represents the name of the Ethernet interface the driver is to use. The example configuration above would allow the driver to communicate with EtherCAT slaves through the "eth1" interface of the simulator.
| A string representing a valid Ethernet interface name within the simulator |
customInitialization | This field is a map; the key is the address of the slave requiring extra configuration information while the value is the configuration itself. For standard I/O operation, this field is not needed; it is, however, required when working with the Elmo drive, the FC1100 card, or when the user wishes to have more advanced control of any of the other supported modules (supported modules list found 45893852). | The field is detailed in the table below |
Each item in the customInitialization list is the configuration of the EtherCAT slave found at the address denoted by the item's key.
The description of each of its fields is as follows:
Parameter | Description | Accepted Values |
---|---|---|
removeCompleteAccessFlag | If set, the driver will remove the complete access flag from the EEPROM copy. This advanced feature is by default set to false. Programming experience with EtherCAT slaves is advisable before changing this setting. This field is not mandatory. | 0 (not set) or 1 (set) |
forceGenericDriver | If set, the driver will communicate with the current slave in the standard way (as opposed to the specific way the Elmo drive or the FC1100 card require). The information placed in the "options" field (see below) will be disregarded. More concretely, when this parameter is set, the driver is notified that the current slave is not an Elmo drive or an FC1100 card. Therefore, do not set this parameter to true when working with the Elmo drive or the FC1100 card. This field is mandatory. | 0 (not set) or 1 (set) |
options | This field is a list of strings representing extra information for the configuration of the slave. The field is only taken into account if the forceGenericDriver field (see above) is set to 0 (false). Currently, only the Elmo drive requires the "options" field. The items of the list must be in a "X:Y" format, where 'X' must be one of the following: "Profile", "InitialValue", "InterpolationTime", or "ResetCounter". The value allowed for 'Y' is the following:
| There are 4 possible list items that can be added. Example:
|
preToSafe | This field is a list of strings representing extra commands that the user might wish to send to the EtherCAT slave once the slave has reached the pre-operational state but before transitioning to the safe-operational state. A command must be in the format described below. NOTE: this option is not available for the Elmo drive. | See below how to format the command |
safeToOp | This field is a list of strings representing extra commands that the user might wish to send to the EtherCAT slave once the slave has reached the safe-operational state but before transitioning to the operational state. A command must be in the format described below. NOTE: this option is not available for the Elmo drive. | See below how to format the command |
safeToPre | This field is a list of strings representing extra commands that the user might wish to send to the EtherCAT slave when the slave is in the safe-operational state, before transitioning down to the pre-operational state. A command must be in the format described below. NOTE: this option is not available for the Elmo drive. | See below how to format the command |
preToInit | This field is a list of strings representing extra commands that the user might wish to send to the EtherCAT slave when the slave is in the pre-operational state, before transitioning down to the init state. A command must be in the format described below. NOTE: this option is not available for the Elmo drive. | See below how to format the command |
pdoSetup | This field is a list of PDO mapping information necessary for configurable cards, such as the FC1100. The field needs to be defined for such cards if cyclic data exchange is to happen. Each element of the list has the following fields:
| See descriptions on the left |
Formatting the commands to be sent when transitioning between states:
- write unsigned integer:
write('X', 'Y', U'Z', 'T')
, where 'X' represents the index, 'Y' represents the subindex, 'Z' represents the size in bits (value must be divisible by 8 to be byte-aligned) and 'T' represents the value to write. 'X', 'Y' must be hexadecimal values while 'Z' has to be a valid unsigned integer representable on 16 bits; 'T' must be a valid unsigned integer representable on 64 bits.
Example:write(A, 0, U16, 16)
- write signed integer:
write('X', 'Y', I'Z', 'T')
, where 'X' represents the index, 'Y' represents the subindex, 'Z' represents the size in bits (value must be divisible by 8 to be byte-aligned) and 'T' represents the value to write. 'X', 'Y' must be hexadecimal values while 'Z' has to be a valid unsigned integer representable on 16 bits; 'T' must be a valid signed integer representable on 64 bits.
Example:write(1, B, I8, -10)
read values:
read('X', 'Y', 'Z', 'T')
, where 'X' represents the index, 'Y' represents the subindex, 'Z' represents the type and 'T' represents the name that will be given to the value read. 'X', 'Y' must be hexadecimal values. 'Z' has to be a string representing a data type. 'T' is a string that will be used to create a connection point with the Simulink model. More on connections in the next section.
Choices for the type:String Description "U8" unsigned integer on 8 bits "I8" signed integer on 8 bits "U16" unsigned integer on 16 bits "I16" signed integer on 16 bits "U32" unsigned integer on 32 bits "I32" signed integer on 32 bits "U64" unsigned integer on 64 bits "S64" signed integer on 64 bits
Example:read(2, 1, I8, myValue)
Making Connections Between the Model and the Driver
The driver can be seen as a middle-man between the signals in the Simulink model and the EtherCAT slaves connected to the simulator. In the model, the data that the user wishes to send to the EtherCAT slaves is connected to blocks called OpOutput. Similarly, the data received from the slaves is connected to blocks named OpInput. The driver will take the data from the OpOutput blocks and send it to the slaves; it will also convey data received from the slaves back to the model through the OpInput blocks. In order to be able to do that, the user needs to bind the Simulink signals (represented as OpInput and OpOutput blocks) to the driver signals. This is done by using a text file named connections.opal which needs to be transferred to the simulator at the same time as the configuration file (as seen in the image above).
Below is an example of a connections.opal file:
OPAL-1.0 Object
List {
item {
configFile=ethercat_master_cfg.opal
id {
EtherCATMaster
}
inputs {
item {
dataInExchanger=1/analogIn0
dataInProcess=OpInput:AnalogIn0
}
}
outputs {
item {
dataInExchanger=2/analogOut0
dataInProcess=OpOutput:AnalogOut0
}
}
}
}
In more detail, "dataInExchanger" represents the signals of the driver, whereas "dataInProcess" represents the signals in the Simulink model.
The number just after "dataInExchanger=" represents the position of slave in the EtherCAT chain topology. The value 0 is reserved for the EtherCAT master, therefore it is never used. Numbering starts at 1, for the first slave connected to the simulator and it increments for each slave connected in the network (following a daisy chain topology). If ever in doubt, the user can activate the verbose mode of the driver, re-load the simulation at which point the entire slave network topology will be outputted in RT-LAB's display. Each slave's information will be displayed, along with its index (address) within the EtherCAT network. This is the index that needs to be used in the connections.opal file.
The name that follows the index in the "dataInExchanger" item is characteristic to the type of the module at that position in the network. For a full description of what names are possible, please consult the table in the following section.
For the "dataInProcess" item, the names that come after "OpInput:" and "OpOutput:" refer to the names of OpInput and OpOutput Simulink blocks. Therefore, it is important to make sure that those names are unique in the model.
List of Supported Modules and How to Connect to Them
The modules listed in the table below have been tested and proved to be compatible with the present EtherCAT master driver. Support of more modules is possible. Please contact Opal-RT Technologies for more information.
The description of supported EtherCAT slave modules and their possible connection points is as follows:
Module name | Description | Possible connections |
---|---|---|
EK1100 | EtherCAT Coupler | - |
EK1101 | EtherCAT Coupler with ID switch | In the "inputs" section of the connections.opal file: "Id". Example: dataInExchanger=2/Id |
EL1018 | 8-channel digital input, 24 V DC, 10 µs | In the "inputs" section of the connections.opal file: "digitalIn" followed by the desired channel number; numbering starts at 0 and ends at 7 (for a total of 8 channels). Examples:
|
EL1124 | 4-channel digital input terminal 5 V DC | In the "inputs" section of the connections.opal file: "digitalIn" followed by the desired channel number; numbering starts at 0 and ends at 3 (for a total of 4 channels). Examples:
|
EL1202 | 2-channel digital input terminal 24 V DC, TON/TOFF 1 µs | In the "inputs" section of the connections.opal file: "digitalIn" followed by the desired channel number; numbering starts at 0 and ends at 1 (for a total of 2 channels). Examples:
|
EL1809 | HD EtherCAT Terminal, 16-channel digital input 24 V DC | In the "inputs" section of the connections.opal file: "digitalIn" followed by the desired channel number; numbering starts at 0 and ends at 15 (for a total of 16 channels). Examples:
|
EL2008 | 8-channel digital output terminal 24 V DC, 0.5 A | In the "outputs" section of the connections.opal file: "digitalOut" followed by the desired channel number; numbering starts at 0 and ends at 7 (for a total of 8 channels). Examples:
|
EL2202 | 2-channel digital output terminal 24 V DC, TON/TOFF 1 µs, push-pull outputs, tri-state | In the "outputs" section of the connections.opal file: "digitalOut" followed by the desired channel number; numbering starts at 0 and ends at 1 (for a total of 2 channels); "Z" followed by the desired channel number; numbering starts at 0 and ends at 1 (for a total of 2 channels). Examples:
|
EL2624 | 4-channel relay output terminal 125 V AC/30 V DC | In the "outputs" section of the connections.opal file: "digitalOut" followed by the desired channel number; numbering starts at 0 and ends at 3 (for a total of 4 channels). Example: dataInExchanger=2/digitalOut0 |
EL2652 | 2-channel relay output, 230 V AC, 300 V DC, 1 A | In the "outputs" section of the connections.opal file: "digitalOut" followed by the desired channel number; numbering starts at 0 and ends at 1 (for a total of 2 channels). Example: dataInExchanger=2/digitalOut0 |
EL3058 | 8-channel analog input terminal 4…20 mA, single-ended, 12 bit | In the "inputs" section of the connections.opal file: "analogIn" followed by the desired channel number; numbering starts at 0 and ends at 7 (for a total of 8 channels); "status" followed by the desired channel number; numbering starts at 0 and ends at 7 (for a total of 8 channels). Examples:
|
EL3068 | 8-channel analog input terminal 0…10 V, single-ended, 12 bit | In the "inputs" section of the connections.opal file: "analogIn" followed by the desired channel number; numbering starts at 0 and ends at 7 (for a total of 8 channels); "status" followed by the desired channel number; numbering starts at 0 and ends at 7 (for a total of 8 channels). Examples:
|
EL3154 | 4-channel analog input, current, 4…20 mA, 16 bit, single-ended | In the "inputs" section of the connections.opal file: "analogIn" followed by the desired channel number; numbering starts at 0 and ends at 3 (for a total of 4 channels); "status" followed by the desired channel number; numbering starts at 0 and ends at 3 (for a total of 4 channels). Examples:
|
EL3208 | 8-channel input terminal PT100 (RTD) | In the "inputs" section of the connections.opal file: "analogIn" followed by the desired channel number; numbering starts at 0 and ends at 7 (for a total of 8 channels); "status" followed by the desired channel number; numbering starts at 0 and ends at 7 (for a total of 8 channels). Examples:
|
EL4008 | 8-channel analog output terminals 0…10 V, 12 bit | In the "outputs" section of the connections.opal file: "analogOut" followed by the desired channel number; numbering starts at 0 and ends at 7 (for a total of 8 channels). Example: dataInExchanger=2/analogOut0 |
EL4028 | 8-channel analog output terminal 4…20 mA, 12bit | In the "outputs" section of the connections.opal file: "analogOut" followed by the desired channel number; numbering starts at 0 and ends at 7 (for a total of 8 channels). Example: dataInExchanger=2/analogOut0 |
EL4038 | 8-channel analog output terminal -10…+10 V, 12 bit | In the "outputs" section of the connections.opal file: "analogOut" followed by the channel number; numbering starts at 0 and ends at 7 (for a total of 8 channels). Example: dataInExchanger=2/analogOut0 |
EL4124 | 4-channel analog output, current, 4…20 mA, 16 bit | In the "outputs" section of the connections.opal file: "analogOut" followed by the desired channel number; numbering starts at 0 and ends at 3 (for a total of 4 channels). Example: dataInExchanger=2/analogOut0 |
EL4134 | 4-channel analog output terminal -10…+10 V, 16 bit | In the "outputs" section of the connections.opal file: "analogOut" followed by the desired channel number; numbering starts at 0 and ends at 3 (for a total of 4 channels). Example: dataInExchanger=2/analogOut0 |
EL4104 | 4-channel analog output terminal 0…10 V, 16 bit | In the "outputs" section of the connections.opal file: "analogOut" followed by the desired channel number; numbering starts at 0 and ends at 3 (for a total of 4 channels). Example: dataInExchanger=2/analogOut0 |
EL3161 | 1-channel analog input terminal 0…10 V, single-ended, 16 bit | In the "inputs" section of the connections.opal file: "analogIn" followed by the channel number 0 "status" followed by the channel number 0. Examples:
|
EL9410 | Power supply terminals for E-bus | - |
FB1111 Dig. In/Out | EtherCAT piggyback controller boards | - |
FC1100 | PCI EtherCAT slave card | In the "outputs" section of the connections.opal file: the name of a PDO entry with direction MASTER_TO_SLAVE as defined in the driver configuration file (see pdoSetup parameter explanation above). In the "inputs" section of the connections.opal file: the name of a PDO entry with direction SLAVE_TO_MASTER as defined in the driver configuration file (see pdoSetup parameter explanation above).
|
Elmo Gold Solo Whistle | Miniature, Stand-alone Network-based Servo Drive (Up to 20 A/100 V and up to 9 A/200 V) | In the "inputs" section of the connections.opal file:
|
As mentioned in the configuration file section, the read command that the user can send between slave states also creates a connection point between the model and the driver.
The name of this connection point is the name given in the command. Giving again the example above, the command read(2, 1, I8, myValue)
, the name of the connection point will be "myValue". Therefore, an example of the "dataInExchanger" is the following: "dataInExchanger=3/myValue".
Note: as a reminder, this feature is not available for the Elmo drive.
Limitations
The current version of the EtherCAT master driver has the following limitations:
- On 64bit platforms, enabling the XHP mode is not possible; if the driver is part of a model that requires XHP enabled, it is advised to group the OpInputs/OpOutputs used by EtherCAT master in a separate subsystem that will operate with XHP = off
- The network interface chosen for the EtherCAT communication must be 100Mb/s
OPAL-RT TECHNOLOGIES, Inc. | 1751, rue Richardson, bureau 1060 | Montréal, Québec Canada H3K 1G6 | opal-rt.com | +1 514-935-2323
Follow OPAL-RT: LinkedIn | Facebook | YouTube | X/Twitter