AKD EtherCAT Flexible PDO Mapping Size Limitations and Padding

Background

The AKD drive supports flexible EtherCAT PDO mapping.  The 4 available flexible RxPDO’s (PDO data for receive direction, commands from master to drive) are mapped using objects 1600h, 1601h, 1602h, and 1603h.  Each one of these RxPDOs is limited to a maximum size of 8 bytes, but historically the sum total size for all four RxPDOs was limited to 20 bytes.  This sum total size for all four RxPDOs was changed in firmware version 1-16-00-002 to 32 bytes, dependent on setting ECAT.LEGACYREV=0.

TxPDO’s have always supported 32 byte of data.

 

Typo in Manual

There is a typo in the AKD EtherCAT manual, stating that flexible RxPDO’s are limited to 20 bytes for all firmware versions < 1.16 and > 1.17.  This is incorrect.

 

 

Parameter Description

The ECAT.LEGACYREV parameter exists beginning in firmware version 1-16-00-001 but was not fully implemented.  The full function of the parameter is available beginning in firmware version 1-16-00-002.  Only 20 bytes are supported for RxPDO’s in firmware ≤ 1.16.00.001, regardless of ECAT.LEGACYREV.  32 bytes are supported for RxPDO’s in firmware ≥ 1.16.00.002 with ECAT.LEGACYREV = 0.

Firmware Version	ECAT.LEGACYREV	RxPDO Bytes Available
FW ≤ 1.16.00.001	0 or 1	20
FW ≥ 1.16.00.002	1	20
FW ≥ 1.16.00.002	0	32

 

PDO size limitations

• Each individual PDO (8 total; 4 in each direction) are limited to a maximum size of 8 bytes each.
• For FW versions 1.16.00.001 or earlier, the maximum total number of bytes in the RX direction is 20 bytes. This is the sum of the number of bytes in all 4 RXPDOs.
  • Example: RXPDO1=8 bytes, RXPDO2=8 bytes, RXPDO3=4 bytes, RXPDO4=0 bytes; 8+8+4=20. No additional objects can be mapped in this example since the maximum is reached.
• For FW versions 1.16.00.002 and later the maximum total number of bytes in the RX direction is 32 bytes. This is the sum of the number of bytes in all 4 RXPDOs.
  • Example: RXPDO1=8 bytes, RXPDO2=8 bytes, RXPDO3=8 bytes, RXPDO4=8 bytes; 8+8+8+8=32. 
• For all FW versions the total number of bytes in the TX direction is 32 bytes.  This is the sum of the number of bytes in all 4 TXPDOs.
  • Example: TXPDO1=8 bytes, TXPDO2=8 bytes, TXPDO3=8 bytes, TXPDO4=8 bytes; 8+8+8+8=32.

 

TwinCAT Buffer Error

A buffer size error will occur in TwinCAT upon rescanning for drives and activating the configuration, under the following conditions:

• FW ≤1.16.00.001 (regardless of ECAT.LEGACYREV), or FW ≥1.16.00.002 with ECAT.LEGACYREV=1
• And more than 20 bytes are mapped in TwinCAT in the RX direction

Error description: “Overlapping Sync Manager configuration (consider 3-buffer SM are consuming the buffer size 3 times)”

 

Documented Implementation of ECAT.LEGACYREV

The Workbench Help and firmware release notes state that ECAT.LEGACYREV started in version 1.16.00.001.  While the parameter was created in this firmware version, the function was not fully implemented until version 1.16.00.002.

From Workbench Help:

From the release notes:

 

ESI File Content

The ECAT.LEGACYREV parameter should be set using Workbench prior to scanning from the EtherCAT master.  If the setting is changed, the drive(s) should be rescanned.

If ECAT.LEGACYREV=1 upon Scan of Devices, then the master uses the ESI file content corresponding to the revision number 0x00000002.

If ECAT.LEGACYREV=0 upon Scan of Devices, then the master uses the ESI file content corresponding to the actual given FW revision of the drive.

 

Alignment or Padding

An odd number of bytes in a PDO mapping is not allowed.  The AKD uses 16-bit alignment boundaries, which means the number of bytes in an individual PDO can’t be an odd number. This is primarily relevant when adding SINT or 1 byte objects to the PDO mapping (e.g. 6060h sub 0 modes of operation, 6061h sub 0 modes of operation display, etc.).  Padding is needed to make the PDO size an even number of bytes.  There are “dummy” objects that can be used for this purpose.

Direction	Object for Padding “Dummy”	Firmware
Rx	0000h sub 0	Only newer firmware
Rx	0002h sub 0	All
Tx	2002h sub 1	All

 

Rx direction:

These are data types defined in CiA 301:

0002h DEFTYPE INTEGER8

0003h DEFTYPE INTEGER16

0004h DEFTYPE INTEGER32

0005h DEFTYPE UNSIGNED8

0006h DEFTYPE UNSIGNED16

0007h DEFTYPE UNSIGNED32

However, there is only a need to use object 0002h for an 8bit padding.  These other objects have not been tested in the AKD.

These can only be used in Rx direction.  The type is ignored, so signed and unsigned are treated as the same data type.

The order of placement of the dummy object (0000h or 0002h) within the PDO is important. The dummy object should be placed right after the 1 byte object it is providing padding for.  (TwinCAT will still go into OP if the dummy object is before the 1 byte object, but it indicates that something is wrong.  There are no configuration errors or warnings reported, but it indicates a run error.)

Example:

 

Tx direction:

In the Tx direction (actual values), any one of the subindexes 1-4 of the manufacturer status object 2002h (2002h sub 1 - sub 4 ) can be used to make the TxPDO length even. Like the RxPDOs, the order of placement of the manufacturer status object within the PDO important.

Example:

 

Back to top