Articles

EtherCAT is an Ethernet-based fieldbus system, invented by Beckhoff Automation. The protocol is standardized in IEC 61158 and is particularly well suitable for to fast and precise multi-axis motor control thanks to its microsecond-level synchronization. EtherCAT is structured into physical, data link, and application layers.  Data communication between devices occurs on the physical layer over a 100 BASE-TX.  Data packets are formatted on the data link layer according to IEC 61158-3/-4.  The application layer contains the object dictionary, a standardized format for storing and retrieving data internal to the drive, along with functions to handle data formatting and communication.  The drive stores object dictionary items in non-volatile memory so they can be used to configure, control and provide feedback from the drive.

The EtherCAT network is wired with a shielded twisted pair with 2 pairs of wires. CAT 5, 6, or 7 may be used. The EtherCAT PHY supports auto negotiation and auto crossover.

The Object Dictionary contains data in a predefined format accessible over the network using a 16-bit index, and an 8-bit sub-index.  The overall layout is provided in Table 1. 

Table 1: EtherCAT Object Dictionary Layout

Both single and array type variable are stored in the dictionary.  Where arrays are used, the 8-bit sub index must be included to address individual items in the array.

Objects may be read only or read/write.  Read only objects include data automatically generated by the drive, such as motor speed, and informational fields such as the device name.  Writable fields allow for drive operation to be configured to end application requirements.  Some fields may not be writable in a specific operational mode or may require an additional write to the store parameters object.

The Modes of Operation supported (object 0x6060) are the following:

• Profile Position Mode
• Velocity Mode
• Profile Velocity Mode
• Profile Torque Mode
• Cyclic Sync Position
• Cyclic Sync Velocity
• Cyclic Sync Torque

The NMT state machine defines the communication behavior of an EtherCAT device. The EtherCAT NMT state machine consists of an Initialization state, a Pre-operational state, a Safe Operational state, an Operational state, and a Stopped state. After power-on or reset, the device enters the Initialization state. After the device initialization is finished, the device automatically transits to Pre-operational state and indicates this transition by sending the boot-up message. All EtherCAT devices are regarded as NMT slaves. An NMT slave is uniquely identified in the network by its node-ID, a value in the range of [1 - 127].

The NMT protocol is transmitted by the EtherCAT master in the network. The reception of the NMT protocol forces the EtherCAT device to make the transition into the commanded NMT state.

Figure 2: FSA State Transitions

The PDS FSA defines the PDS status and the possible control sequence of the PDS. A single state represents a special internal or external behavior. The state of the PDS also determines which commands are accepted. For example, it is only possible to start a point-to-point move when the drive is in the operation enabled state.

The numbered transitions of the state machine are stimulated by the actions described in the following table.  Other transitions are not possible.

Table 2: FSA Transitions

Example: To transition the drive to Operation Enabled state after power up and NMT Operational state, set control word to 0x6 (shutdown), then 0x7 (switch on), then 0x0f (enable operation.)

If a state transition is requested, the related actions shall be processed completely before transitioning to the new state.

Drive function is disabled implies no energy shall be supplied to the motor. Target or set-point values (e.g. torque, velocity, position) shall be not processed.

Drive function is enabled implies that energy may be supplied to the motor. Target or set-point values shall be processed.

If a fault is detected in the drive device, there shall be a transition to the fault reaction active state. In this state, the PDS shall execute a special fault reaction. After the execution of this fault reaction, the drive device shall switch automatically to the fault state. This state shall only be left by the fault reset command, but only if the fault is no longer active.

Figure 2 indicates for each state what conditions exist.

Real-time data transfer is performed by means of "Process Data Objects (PDO)".

The PDO correspond to groups of objects in the object dictionary and provide the interface to the application objects. Due to the limitations of the system, a PDO data payload is limited to 8 bytes.

There are two kinds of use for PDO. The first is data transmission in Transmit-PDO (TPDO), and the second data reception from Receive-PDO (RPDO). EtherCAT devices supporting TPDO are PDO producer and EtherCAT devices supporting RPDO are called PDO consumer.

Roboteq’s EtherCAT implementation is CANOpen over EtherCAT (COE). Support CANOpen DS402 Profile and Operating modes:

• Cyclic sync torque
• Cyclic sync velocity
• Cyclic sync position
• Profile position
• Profile velocity
• Position
• Velocity
• Torque

The full COE dictionary is shared with this of Roboteq’s CAN. For the descriptions of all supported DS402 objects, please refer to the “CAN Networking Manual” documentation.

0x1000     Device Type

This object contains the device type, an unsigned 32-bit constant.  This object is read only.

Table 6: Device Type

The additional information defines 2 device types with and without safety for CiA402.

• Servo Drive without safety: 0x02
• Servo Drive with safety: 0x0A
• Stepper Motor without safety: 0x04
• Stepper Motor with safety: 0x0C

The default value is 0x02192 which identifies as a servo drive, CiA402 compliant device.

0x1001     Error Register

This object contains an unsigned, 8-bit variable that provides error information for the device.  This is used as part of the Emergency Message object. Un-used bits will always be set to 0 values. If a specific error occurs the corresponding bit shall be set to 1. The generic error shall be signaled at any error.

Table 7: Error Register Bits

0x1003     Pre-defined Error Field

This object is an array of unsigned 32-bit values containing an error count at sub-index 0x00, and each specific error code at each index from 01 to 08.  Each of the errors on the device are also signaled in the emergency object. Each new error is stored in sub-index 01. Older errors are automatically moved to the next higher sub-index. Writing a value of 0x00 to sub-index will delete the entire error history. Writing other values than 0x00 are not allowed and will lead to an abort message (error code: 0609 0030h). 10 sub-indices are supported and as such a maximum number of the 10 last errors are stored. Bits 0-15 represent the error code. Bits 16-31 are optional additional information.

Table 8: Structure of the Pre-defined Error Field

Table 9 shows the defined errors.

Table 9: RoboteQ Error Codes

0x1008     Manufacturer Device Name

This object contains the manufacturer device name in a STRING format of up to 6 characters.  This the device hardware family “RoboMC”.

0x1009     Manufacturer Hardware Version

This object contains the manufacturer hardware version for the drive in a STRING format of 3 characters.

0x100A    Manufacturer Software Version

This object contains the 4-digit manufacturer software version for the drive in a STRING format of 3 characters. The software version is formatted as follows:

Table 10: Structure of Software Version

0x100C     Guard Time

The objects at index 100Ch and 100Dh indicates the configured guard time respectively the life

time factor. The life time factor multiplied with the guard time gives the life time for the life guarding protocol. The value shall be given in multiple of ms. The value 0f 0x0000 disables the life guarding. Default value is 0x0000.

0x100D    Life Time Factor

The life time factor multiplied with the guard time gives the life time for the life guarding protocol. The value of 0x00 disables the life guarding. Default value is 0x00.

0x1016     Consumer Heartbeat Time

This object indicates the expected heartbeat cycle times. Monitoring of the heartbeat producer starts after the reception of the first heartbeat.

Table 11: Consumer Heartbeat Time bits

0x1017     Producer Heartbeat Time

This object indicates the configured cycle time of the heartbeat. The value shall be given in multiples of 1 ms. A value of 0 disables the producer heartbeat.0x1018     Identity

0x1018     Identity

This object shall provide general identification information of the EtherCAT device.

Sub-index 0x01 shall contain the unique value1 that is allocated uniquely to each vendor of a EtherCAT device. The value 0000 0000h shall indicate an invalid vendor-ID.

Sub-index 0x02 shall contain the unique value that identifies a specific type of EtherCAT devices. The value of 0000 0000h shall be reserved.

Sub-index 0x03 shall contain the major revision number and the minor revision number of the revision of the EtherCAT device (see Table 12). The major revision number shall identify a specific EtherCAT behavior. That means if the EtherCAT functionality is different, the major revision number shall be incremented. The minor revision number shall identify different versions of EtherCAT device with the same EtherCAT behavior. The value of 0x00000000 shall be reserved.

Table 12: Structure of revision number

Runtime Commands (0x2000 – 0x20FF)

More information regarding the runtime commands can be found in the “Advanced Brushed and Brushless Digital Motor Controllers” document in Section 15: Command References.

Runtime Queries (0x2100 – 0x21FF)

More information regarding the runtime commands can be found in the “Advanced Brushed and Brushless Digital Motor Controllers” document in Section 15: Command References.