5. EtherCAT communication

EtherCAT is an open real-time Ethernet protocol originally developed by Beckhoff Automation. When communicating with a Mecademic robot over EtherCAT, you can achieve guaranteed response times of 1 ms (see Cycle time for caveats).

Mecademic robots, when controlled via EtherCAT, use cyclic data exchanges to manage robot state and motion, as defined in Communicating over cyclic protocols.

Refer to our Support Center for specific PLC examples.

5.1. Overview

5.1.1. Connection types

With EtherCAT, you can connect several Mecademic robots in various network topologies, including line, star, tree, or ring, as each robot has a unique node address. This allows targeted access to a specific robot, even if your network topology changes.

5.1.2. ESI file

Each EtherCAT slave device is described by an EtherCAT Slave Information (ESI) file that describes its identity, capabilities, and cyclic payload. The EtherCAT controllers (PLC) use this file to properly identify detected EtherCAT slave devices, such as a Mecademic robot.

It can be found in the zip file that contains your robot’s firmware update package (Meca500_EtherCAT_ESI_vX.X.X.X.xml) .

5.1.3. Enabling EtherCAT

The default communication protocol of the robot is the Ethernet TCP/IP protocol. This protocol is required for jogging the robot through the MecaPortal.

To switch to EtherCAT, use the Network configuration panel in the MecaPortal configuration menu.

Alternatively, you can use the SwitchToEtherCAT command, which can be entered in the MecaPortal code editor or sent to the robot via the TCP/IP API.

This command is persistent. The robot will remain in EtherCAT mode even after being rebooted.

Warning

When the robot is in EtherCAT mode, TCP/IP or EtherNet/IP communication is not possible (e.g., you cannot use the robot’s web interface or other cyclic protocols).

5.1.4. Disabling EtherCAT

To disable EtherCAT (and restore standard TCP/IP communication mode), use the RobotControl PDO (see Table 4) or perform a Network configuration reset.

5.1.5. LEDs

Your robot has three green LEDs on its base, labeled Link/Act IN, Link/Act OUT, and Run. When EtherCAT communication is enabled, these three LEDs indicate the state of the EtherCAT connection, as summarized in Table 26.

Table 26 EtherCAT LED description

LED	Name	LED State	EtherCAT state
Link/Act IN	IN port link	On	Link is active but there is no activity
		Blinking	Link is active and there is activity
		Off	Link is inactive
Link/Act OUT	OUT port link	On	Link is active but there is no activity
		Blinking	Link is active and there is activity
		Off	Link is inactive
Run	Run	On	Operational
		Blinking	Pre-Operational
		Single flash	Safe-Operational
		Flashing	Initialization or Bootstrap
		Off	Init

5.2. PDO Mapping

The process data objects (PDOs) provide the interface to the application objects. PDOs are used to transfer data via cyclic communications in real time. PDOs can be reception PDOs (RxPDOs), which receive data from the EtherCAT master (the PLC or the industrial PC), or transmission PDOs (TxPDOs), which send the current value from the slave (the Mecademic robot) to the EtherCAT master. In the previous subsection, we listed the PDOs in the object dictionary. PDO assignment is summarized in the next two tables.

Table 27 RxPDOs

PDO	Object(s)	Name	Note
1600h	7200h	RobotControl	Mandatory. See Table 4.
1601h	7310h	MotionControl	Mandatory. See Table 5.
1602h	7305h, 7306h	Movement	Mandatory. See Table 6.
1610h	7400h	HostTime	Mandatory. See Table 9.
1611h	7410h	BrakesControl	Mandatory. See Table 10.
1620h	7420h	DynamicDataConfiguration 0	Mandatory. See Table 11.
1621h	7421h	DynamicDataConfiguration 1	Mandatory. See Table 11.
1622h	7422h	DynamicDataConfiguration 2	Mandatory. See Table 11.
1623h	7423h	DynamicDataConfiguration 3	Mandatory. See Table 11.

Table 28 TxPDOs

PDO	Object	Name	Note
1A00h	6010h	RobotStatus	Mandatory. See Table 13.
1A01h	6015h	MotionStatus	Mandatory. See Table 14.
1A02h	6030h	TargetJointSet	Mandatory. See Table 15.
1A03h	6031h	TargetEndEffectorPose	Mandatory. See Table 16.
1A08h	6046h	TargetConfiguration	Mandatory. See Table 17.
1A09h	6050h	WRF	Mandatory. See Table 18.
1A0Ah	6051h	TRF	Mandatory. See Table 19.
1A10h	6060h	RobotTimestamp	Mandatory. See Table 20.
1A11h	6065h	SafetyStatus	Mandatory. See Table 21.
1A20h	6070h	DynamicData index 0	Mandatory. See Table 22.
1A21h	6071h	DynamicData index 1	Mandatory. See Table 23.
1A22h	6072h	DynamicData index 2	Mandatory. See Table 24.
1A23h	6073h	DynamicData index 3	Mandatory. See Table 25.

5.3. PDO (cyclic) data

Using the PDO data to control and monitor Mecademic robots with EtherCAT is explained in Section 4 of this manual.

The cyclic data format is the same for PROFINET, EtherNet/IP, and EtherCAT protocols. Therefore, it is easy to migrate a robot-controlling application on a controller/PLC between these different protocols.

Please refer to the robot’s ESI file for the list of cyclic input/output fields. Refer to Section 4 for instructions on how to use these cyclic fields.

Note that 16- and 32-bit integer values in the cyclic data use big-endian byte order. Some PLCs may need to be configured accordingly.

5.4. Cycle time

Mecademic robots support an EtherCAT cycle time of 1 ms.

Although the robot always replies immediately to every received packet (even if faster than 1 ms), network timing jitter may prevent the robot from returning updated data in each response. Two consecutive packets received within ~800 microseconds may result in a response with the same cyclic data as the previous response, as the robot had insufficient time to process the previous packet.

This repeated data is not problematic if the EtherCAT master application is correctly implemented. The application must repeat any action request in its cyclic data until the corresponding confirmation is received in the robot’s response (e.g., a status bit matching a request, or a MoveId confirmation for a posted motion command). Please refer to Communicating over cyclic protocols for details.