ESI and PDO mapping: review the complete configuration chain
An ESI describes device capabilities. Your master configuration and the device’s active assignments determine what actually appears in the process image.
Updated November 4, 2026 · PcPart24 engineering notes
Use a safe test setup and follow the equipment manufacturer’s commissioning procedures. These checks guide investigation; the device documentation determines supported behavior.
1. Match the exact slave
Check vendor ID, product code and revision against the discovered device. Use the device vendor’s supported ESI version and revision rules. A similar product name is not enough to establish compatibility. Keep the original file and record any local edits.
2. Identify fixed and configurable PDOs
Read which PDOs are fixed, selectable or dynamically mappable. Do not assume every device permits the same startup writes. For CoE devices, review the applicable assignment and mapping objects and the vendor’s documented state requirements.
3. Count bits before bytes
List every mapped entry with index, subindex, data type, signedness and bit length. Add explicit padding and alignment. Reconcile bit totals with the Sync Manager process-data lengths, then verify host-side packing and endianness.
4. Verify assignments and startup ordering
Where supported, check RxPDO and TxPDO assignment objects, commonly 0x1C12 and 0x1C13, and their referenced mapping entries. Review startup commands, values, transition timing and abort codes. Fixed-map and non-CoE devices may follow different mechanisms.
5. Reconcile ESI, ENI and application layout
Compare the ESI capabilities, generated master configuration, discovered active assignments and application process-image offsets. Record a table from device entry to host variable. Optional slots, module order and firmware revisions can change that table.
6. Test with recognizable patterns
Use a safe test configuration and known input/output patterns to check byte order, sign extension and individual bit positions. Confirm watchdog and state-transition behavior separately. Correct data length alone does not demonstrate correct signal meaning or real-time performance.
A useful deliverable
A review should leave an identity/version record, an entry-to-offset mapping table, the configuration differences found, and a reproducible test plan. State what was observed on hardware and what remains a configuration hypothesis.
Need help reviewing your configuration?
Start with the observed behavior and your intended outcome. We can scope an offline review before any development work.
Discuss an EtherCAT reviewAll engineering notes · EtherCAT services
EtherCAT is a registered trademark of Beckhoff Automation GmbH. PcPart24 is an independent service provider.