General Notes - EtherCAT Slave Application
This summary briefly deals with a number of aspects of EtherCAT Slave operation under TwinCAT. More detailed information on this may be found in the corresponding sections of, for instance, the EtherCAT System Documentation.
Diagnosis in real time: WorkingCounter, EtherCAT State and Status
Generally speaking an EtherCAT Slave provides a variety of diagnostic information that can be used by the controlling task.
This diagnostic information relates to differing levels of communication. It therefore has a variety of sources, and is also updated at various times.
Any application that relies on I/O data from a fieldbus being correct and up to date must make diagnostic access to the corresponding underlying layers. EtherCAT and the TwinCAT System Manager offer comprehensive diagnostic elements of this kind. Those diagnostic elements that are helpful to the controlling task for diagnosis that is accurate for the current cycle when in operation (not during commissioning) are discussed below.
In general, an EtherCAT Slave offers
- communication diagnosis typical for a slave (diagnosis of successful participation in the exchange of process data, and correct operating mode)
This diagnosis is the same for all slaves.
as well as - function diagnosis typical for a channel (device-dependent)
See the corresponding device documentation
The colors in Fig. Selection of the diagnostic information of an EtherCAT Slave also correspond to the variable colors in the System Manager, see Fig. Basic EtherCAT Slave Diagnosis in the PLC.
Colour | Meaning |
|---|---|
yellow | Input variables from the Slave to the EtherCAT Master, updated in every cycle |
red | Output variables from the Slave to the EtherCAT Master, updated in every cycle |
green | Information variables for the EtherCAT Master that are updated acyclically. This means that it is possible that in any particular cycle they do not represent the latest possible status. It is therefore useful to read such variables through ADS. |
Fig. Basic EtherCAT Slave Diagnosis in the PLC shows an example of an implementation of basic EtherCAT Slave Diagnosis. A Beckhoff EL3102 (2-channel analogue input terminal) is used here, as it offers both the communication diagnosis typical of a slave and the functional diagnosis that is specific to a channel. Structures are created as input variables in the PLC, each corresponding to the process image.
The following aspects are covered here:
|
Code |
Function |
Implementation |
Application/evaluation |
|---|---|---|---|
|
A |
The EtherCAT Master's diagnostic information updated acyclically (yellow) or provided acyclically (green). |
|
At least the DevState is to be evaluated for the most recent cycle in the PLC. The EtherCAT Master's diagnostic information offers many more possibilities than are treated in the EtherCAT System Documentation. A few keywords:
|
|
B |
In the example chosen (EL3102) the EL3102 comprises two analogue input channels that transmit a single function status for the most recent cycle. |
Status
|
In order for the higher-level PLC task (or corresponding control applications) to be able to rely on correct data, the function status must be evaluated there. Such information is therefore provided with the process data for the most recent cycle. |
|
C |
For every EtherCAT Slave that has cyclic process data, the Master displays, using what is known as a WorkingCounter, whether the slave is participating successfully and without error in the cyclic exchange of process data. This important, elementary information is therefore provided for the most recent cycle in the System Manager
for linking. |
WcState (Working Counter) 0: valid real-time communication in the last cycle 1: invalid real-time communication This may possibly have effects on the process data of other Slaves that are located in the same SyncUnit |
In order for the higher-level PLC task (or corresponding control applications) to be able to rely on correct data, the communication status of the EtherCAT Slave must be evaluated there. Such information is therefore provided with the process data for the most recent cycle. |
|
D |
Diagnostic information of the EtherCAT Master which, while it is represented at the slave for linking, is actually determined by the Master for the Slave concerned and represented there. This information cannot be characterized as real-time, because it
|
State current Status (INIT..OP) of the Slave. The Slave must be in OP (=8) when operating normally. AdsAddr The ADS address is useful for communicating from the PLC/task via ADS with the EtherCAT Slave, e.g. for reading/writing to the CoE. The AMS-NetID of a slave corresponds to the AMS-NetID of the EtherCAT Master; communication with the individual Slave is possible via the port (= EtherCAT address). |
Information variables for the EtherCAT Master that are updated acyclically. This means that it is possible that in any particular cycle they do not represent the latest possible status. It is therefore possible to read such variables through ADS. |
It is strongly recommended that the diagnostic information made available is evaluated so that the application can react accordingly.
CoE Parameter Directory
The CoE parameter directory (CanOpen-over-EtherCAT) is used to manage the set values for the slave concerned. Changes may, in some circumstances, have to be made here when commissioning a relatively complex EtherCAT Slave. It can be accessed through the TwinCAT System Manager, see Fig. EL3102, CoE directory:
 | EtherCAT System Documentation The comprehensive description in the EtherCAT System Documentation (EtherCAT Basics --> CoE Interface) must be observed! |
A few brief extracts:
- Whether changes in the online directory are saved locally in the slave depends on the device. EL terminals (except the EL66xx) are able to save in this way.
- The user must manage the changes to the StartUp list.
Commissioning aid in the TwinCAT System Manager
Commissioning interfaces are being introduced as part of an ongoing process for EL/EP EtherCAT devices. These are available in TwinCAT System Managers from TwinCAT 2.11R2 and above. They are integrated into the System Manager through appropriately extended ESI configuration files.
This commissioning process simultaneously manages
- CoE Parameter Directory
- DC/FreeRun mode
- the available process data records (PDO)
Although the “Process Data”, “DC”, “Startup” and “CoE-Online” that used to be necessary for this are still displayed, it is recommended that, if the commissioning aid is used, the automatically generated settings are not changed by it.
The commissioning tool does not cover every possible application of an EL/EP device. If the available setting options are not adequate, the user can make the DC, PDO and CoE settings manually, as in the past.
EtherCAT State: automatic default behaviour of the TwinCAT System Manager and manual operation
After the operating power is switched on, an EtherCAT Slave must go through the following statuses
- INIT
- PREOP
- SAFEOP
- OP
to ensure sound operation. The EtherCAT Master directs these statuses in accordance with the initialization routines that are defined for commissioning the device by the ES/XML and user settings (Distributed Clocks (DC), PDO, CoE). See also the section on "Principles of Communication, EtherCAT State Machine" in this connection. Depending how much configuration has to be done, and on the overall communication, booting can take up to a few seconds.
The EtherCAT Master itself must go through these routines when starting, until it has reached at least the OP target state.
The target state wanted by the user, and which is brought about automatically at start-up by TwinCAT, can be set in the System Manager. As soon as TwinCAT reaches the status RUN, the TwinCAT EtherCAT Master will approach the target states.
Standard setting
The advanced settings of the EtherCAT Master are set as standard:
- EtherCAT Master: OP
- Slaves: OP
This setting applies equally to all Slaves.
In addition, the target state of any particular Slave can be set in the “Advanced Settings” dialogue; the standard setting is again OP.
Manual Control
There are particular reasons why it may be appropriate to control the states from the application/task/PLC. For instance:
- for diagnostic reasons
- to induce a controlled restart of axes
- because a change in the times involved in starting is desirable
In that case it is appropriate in the PLC application to use the PLC function blocks from the TcEtherCAT.lib, which is available as standard, and to work through the states in a controlled manner using, for instance, FB_EcSetMasterState.
It is then useful to put the settings in the EtherCAT Master to INIT for master and slave.
Note regarding E-Bus current
EL/ES terminals are placed on the DIN rail at a coupler on the terminal strand. A Bus Coupler can supply the EL terminals added to it with the E-bus system voltage of 5 V; a coupler is thereby loadable up to 2 A as a rule. Information on how much current each EL terminal requires from the E-bus supply is available online and in the catalogue. If the added terminals require more current than the coupler can supply, then power feed terminals (e.g. EL9410) must be inserted at appropriate places in the terminal strand.
The pre-calculated theoretical maximum E-Bus current is displayed in the TwinCAT System Manager as a column value. A shortfall is marked by a negative total amount and an exclamation mark; a power feed terminal is to be placed before such a position.
From TwinCAT 2.11 and above, a warning message “E-Bus Power of Terminal...” is output in the logger window when such a configuration is activated:
The same ground potential must be used for the E-Bus supply of all EtherCAT terminals in a terminal block!