iNetic has created the iMR and the iND integrated solution using the Circulo and the Integro drives from Synapticon.

These drive use EtherCAT for communication. But what it is EtherCAT?

EtherCAT is defined by the EtherCAT user group in the IEC-Standard 61158 and defines the bus system and how the drive slave communicates with a master on the physical and basic communication levels.

CANopen is standardized by CiA and the CiA 301 describes the CANopen application layer and the communication profile.

This describes how to transfer content between a master and a slave and how to realize the real time requirements.

CoE specifies how the CANopen protocol is used in the EtherCAT environment.

CiA 402 is the device profile for drives and motion control applications. CiA 402 defines how drives communicate with the masters:

The object number designates where to find, or send, the required information and all basic functionality; for example, how to switch on a drive, how to recover faults, drive specific state machines.

Complying with CiA 402 makes drives interchangeable among different manufacturers as all drives work similarly and have the same basic data on the same address. Manufacturer specific areas define how to handle special features.

Masters are based on these standards and offer an abstraction layer; therefore, only minor knowledge about the standards is required. The system offers an interface (usually graphical), so that the system can be configured as needed. The user need not be concerned about protocols, such as starting up the communication, fault and recovery procedures, PDO mapping, and communication supervision, because this is handled by the master. Usually, process values can be set by the user directly through the API of a master software without having to worry about the details.

Nevertheless, having basic knowledge of the basic principles will help to establish the connection with these masters, bug fixing and fault diagnosis.

If a commercial master is not used and the interface to a SOMANET drive is manually implemented or the system is realized with the use of free basic solutions, such as SOEM, a deep knowledge of the standard is required.

TAll operable data in a CANopen device, including communication data and application data, is stored in an object dictionary. Each data can be accessed with a 16-bit index and an optional 8-bit subindex. For example, the measurement “Velocity actual value” is stored in 0x606C, and the configuration “Brake output voltage” is stored in 0x2004:10. A complete object dictionary of SOMANET servo drives with firmware v5.0 can be found here.

Each CiA compliant device has a specific ESI file (EtherCAT Slave Information). Besides other device specific information, the ESI file contains the object dictionary.

To read/write data in a CANopen device, two methods as shown below are generally used.

SDO (Service Data Objects) can provide direct access to reading/writing any object entries in an object dictionary. However, this is performed on demand and not cyclically, so it is mainly used for changing configurations, reading error codes or other actions on demand.

All objects can be read, but only some can be written as well (RO / read only <-> RW read write).

PDO (Process Data Objects) can provide real-time data transfer in a cyclic manner; it is mainly used to transfer time-sensitive cyclical application data such as controlword/statusword, target/actual velocity etc. There are two kinds of PDOs: Transmit PDO (TPDO) and Receive PDO (RPDO), which provide slave-to-master and master-to-slave data transfer respectively. To configure a PDO, two objects in the object dictionary must be configured by means of SDO. The first is the PDO parameter and the second PDO mapping. The PDO parameter describes the communication capabilities of the PDO while PDO mapping determines which object shall be mapped to this PDO to be transferred in real-time cyclically. By default, our standard PDO configuration already covers common application data so there is no need to configure “from scratch”.

CANopen defines profiles for specific devices as IO-modules, sensors or drives. The profile for power drives is defined in CiA 402.

CiA 402 compliant drives have the same basic functionality and can easily be interchanged, even when they have manufacturer specific objects.

In CiA 402, it is specified that the behavior of a Power Drive System (PDS) should be controlled by a Finite State Automaton (FSA). The PDS FSA has many states, and each state shall support a specific set of functions. For example, moving a motor is only possible in the state “Operation enabled”. State transitions can be triggered by writing the object “0x6040 Controlword” or internal fault signals (which transits the state to “Fault reaction active”) and the current state of the FSA can be read from the object “0x6041 Statusword”. See: Using Statusword and Controlword for a detailed description and illustration.

The behavior of a Power Drive System is also determined by the activated mode of operation. The mode of operation can be selected by writing the object “0x6060 Modes of operation”. It defines how users would like to move the motor (for example, by setting the target torque/velocity/position with a self-defined trajectory in profile modes, or by updating the torque/velocity/position cyclically in cyclic synchronous modes). The aforementioned Controlword and Statusword also have some specific operation mode-specific bits to extend functionalities. Refer to this page for the definitions of all modes of operation that SOMANET supports.

The figure below depicts the EtherCAT state machine and describes which communication is possible in which state.

The figure below specifies the drive state machine with its state transitions based on user commands and internal drive faults.

Refer to Using Statusword and Controlword for details on how to manipulate the state machine.

There is a standard set of PDO that consists of input objects (TxPDO) and output objects (RxPDO) in the firmware. The set covers almost all application data that will be used in real applications, generally configuration is not necessary.

However, if there are objects that are more suitable for the application, an individual set of PDO can be created by the following procedure:

1. Ensure that the desired object is PDO mappable (this can be checked in the object dictionary)
2. Switch EtherCAT state to Pre-operational
3. Disable PDO distribution by setting 0 to 0x1C12:00 (for RxPDO) or setting 0 to 0x1C13:00 (for TxPDO)
4. Disable one of the PDO mapping objects by setting its subindex 0 to 0
5. Enter the objects that should be mapped to the mapping entry subindices 1 to n
6. Set subindex 0 to the number n of used entries
7. Enable PDO distribution by setting 0x1C12:00 or 0x1C13:00 to their original values, by default 3 and 4 respectively

Changing the PDO mapping will not permanently be stored on the drive. The reconfiguration must be done on every new start of the drive.

Many commercial masters provide the possibility to change the PDO mapping when configuring a device. The master will then change the PDO mapping automatically after every boot-up before enabling the operational state of the drive.

The communication frequency of EtherCAT systems is determined by the master’s update rate, which is often represented as cycle time. Usually, the cycle time should be set between 250 μs and 8 ms. There are a few tips that may help to find the most appropriate cycle time based on the application and situation.

• When the cycle time is lower than 1 ms, a high performance of the hardware system is required.
• SOMANET drives have a sample time of 250 μs internally; therefore, if the master’s cycle time is set below this value, the application performance will generally not improve noticeably.
• In real-time applications, commands are sent to the slaves with a step size that depends on the master’s update rate; if the application requires fast command changes, a slow cycle time will have negative effects on control performance. If the control performance is limited by the hardware system, the control loop should be tuned relatively soft, or an FIR filter should be considered.

In EtherCAT systems, the clocks of master and slave(s) can be synchronized based on a Distributed Clock (DC) technology. This is especially important when multiple slaves are present and complex synchronous motions are required. When no distributed clock is available, the clocks on the slave and master devices will drift, and this will cause a cycle to periodically either miss a command, or complete before the command arrives at the controller. This will effectively either double the input command or see no change to the input command. For additional details, refer to Distributed clocks (DC clocks).