Lenze ECSxM via EMF2192IB (EtherCAT): CiA402 compatibility and configuration iss

Hi everyone,I'm looking for some help from the community with configuring a Lenze drive setup to work with LinuxCNC via the(lcnc-ethercat) driver.The Hardware:

• Axis module: Lenze ECSxM
• Communication module: Lenze EMF2192IB (EtherCAT)

The Issue: I am trying to configure the axis module control using the standard CiA402 profile. However, during diagnostics, I ran into some mapping issues:

1. When running the

   ethercat pdos

   command, the core CiA402 profile indices like

   0x6060

   (Modes of Operation) and

   0x6061

   (Modes of Operation Display) are missing. From what I’ve gathered in the Lenze documentation, these parameters seem to be strictly hardcoded into SDOs.
2. When running

   ethercat sdos

   , the master only returns unnamed indices strictly within the

   0x2000

   to

   0x5801

   range. Nothing above this pool is visible (objects from

   0x6000

   onwards are missing entirely).

Given this situation, I have a few questions for the experts here:

1. Is it actually possible to get the ECSxM + EMF2192IB combo running properly under the standard CiA402 profile in LinuxCNC? Does a native driver/component for

   ethercat-cia402

   support this particular hardware?
2. If the standard profile isn't supported out of the box due to Lenze's proprietary layout, what is the best way to handle the control? Do I need to manually map the Lenze-specific SDOs/PDOs (from the

   0x2000

   -

   0x5000

   range) into HAL, or should I write a custom XML config to handle PDO Mapping via SDO download?
3. If anyone has successfully configured this or has a working

   ethercat-conf.xml

   example for this generation of Lenze inverters, could you please share it?

Any advice, pointers, or examples would be greatly appreciated!Cheers!

Not all drives are cia402 compatible. Yours probably isn't.
you need to share more info eg.
ethercat pdos > pdos.txt 
ethercat sdos > sdos.txt
and also try using lcec_configgen > configgen.xml (but there are some optional command line switches) It may create your XML for you.

Title Idea: Lenze ECSxM EtherCAT (CiA402) configuration issue – Drive stuck in PREOP E with Bus Error 20000OS and Hardware Environment:OS / Core: Debian Linux with RT (Realtime) kernel, LinuxCNC version 2.9.4.Driver / Module: linuxcnc-ethercat (the lcec module by Sittner).Servo Drive: Lenze ECSxM (Identified on the bus as: Vendor ID 0x0000003b, Product Code 0x014e7bc0).Network Interface: Integrated Realtek Ethernet adapter. The driver runs in standard generic emulation mode.PC & Realtime Optimization:One CPU core is completely isolated at the GRUB bootloader level (isolcpus) specifically for the LinuxCNC Servo Thread.The Ethernet port dedicated to the EtherCAT bus is completely disconnected from the Linux network stack (all IP addresses removed, any third-party internet traffic is blocked) to eliminate OS-induced jitter.The isolated core and the NIC show excellent results during the standard LinuxCNC Latency Test.Step-by-Step Troubleshooting HistoryStep 1. Initial INI File Adjustments (cia402.ini)The initial configuration had maximum velocity mismatches. Trajectory limits under [DISPLAY] and [TRAJ] were raised to 100.0 to match the simulated X and Z axes (MAX_VELOCITY = 100.0). For the physical Y-axis (Lenze drive, [JOINT_1]), following error limits were adjusted, and homing speeds (HOME_SEARCH_VEL / HOME_LATCH_VEL) were changed from 0.0 to -10.0 and 2.0 to prevent initial startup errors.Step 2. First Run & LCEC CrashRunning linuxcnc /home/debian/devel/cia402.ini resulted in a critical HAL initialization failure:Failed to register PDO entry: No such file or directory
LCEC: master 0 PDO entry registration failed
./cia402.hal:9: insmod for lcec failed, returned -1
This indicated that the ethercat-conf.xml file requested PDO variables that did not match the physical memory layout of the servo amplifier.Step 3. SDO and XML Profile DiagnosticThe ethercat sdos output showed proprietary Lenze arrays (indices like 0x58df, 0x58de). However, running ethercat xml read the ESI profile directly from the drive's EEPROM and revealed the following true CoE / CiA402 structure:Device Name: Servo ECSxM CiA 402RxPDO (Sm="2", idx="1600"): Contains standard 0x6040 (Control word), 0x60b8 (TP Function), 0x607a (Target position), 0x60ff (Target velocity), and an output array from 0x58e1:07 to 0x58e1:12. Total size: 192 bits (24 bytes).TxPDO (Sm="3", idx="1a00"): Starts with a specific 14-bit empty alignment gap (Index 0x0000, BitLen 14), followed by service bits 1800:09 and 1800:07, status word 0x6041, touch-probe registers 60b9-60bb, actual position 0x6064, and an input array from 0x58e0:09 to 0x58e0:12. Total size: 208 bits (26 bytes).Step 4. Adapting XML Syntax to the lcec_conf ParserWe had to match the specific strict XML syntax expected by this particular linuxcnc-ethercat build:vendor="59" product="21920704" type="cia402" threw Invalid slave attribute vendor.vendor="0x3b" product="0x014e7bc0" type="lcec_cia402" threw Cannot find slave type lcec_cia402.Ultimately, we discovered the working format for this build: it requires vid and pid attributes written as 8-character uppercase HEX strings without the 0x prefix (e.g., vid="0000003B" pid="014E7BC0"), along with type="generic" configPdos="true". All entry types must use halType (u32, s32, bit) instead of dataType.Step 5. Handling the 14-bit Alignment Gap in TxPDODeclaring the gap as <pdoEntry idx="0000" subIdx="00" bitLen="14" halPin="gap" halType="raw"/> caused a crash: Invalid pdoEntry halType raw. Stripping the HAL attributes completely allowed the XML parser to pass, but the 14 bits were seemingly ignored in the total Sync Manager size calculation. Later, we tried using a dummy entry without a pin assignment, like <pdoEntry idx="0000" subIdx="00" bitLen="14" halType="u32"/>.Step 6. HAL File Synchronization (cia402.hal)Once the XML was accepted, HAL failed with Pin 'lcec.0.0.status-word' does not exist because under type="generic" the pins are named strictly after the halPin attribute. The HAL file was fully updated to use the new lcec.0.0.cia-controlword and lcec.0.0.cia-statusword pins. Virtual feedback loops (motor-pos-cmd => motor-pos-fb) were also added to the simulated X (Joint 0) and Z (Joint 2) axes to satisfy the XYZ trajectory planner constraints.Following these changes, the Axis GUI opens successfully without any internal HAL or LinuxCNC errors.Step 7. The Main Problem: PREOP E and Error Code 20000Even though the GUI loads, the Lenze ECSxM drive immediately drops the bus into PREOP E (Pre-Operational with Error) and locks LinuxCNC in a permanent E-Stop (АВОСТ) state.sudo dmesg reveals bus warnings: EtherCAT WARNING: 6 datagrams UNMATCHED! and was SKIPPED.Checking the drive's internal Bus Status register (C1830) using ethercat upload -p 0 0x58d9 00 --type uint32 consistently returns 0x00004E20 (Decimal: 20000). In Lenze module documentation, this code translates to "Invalid Parameter Set / Sync Manager Configuration Error" or "Waiting for Phase Synchronization".Step 8. Distributed Clocks (DC) & Clock Sync AttemptsTo fix the 20000 code, we tested several clock synchronization strategies:Adding addf lcec.sync-clock servo-thread or lcec.sync-clocks to cia402.hal failed with function not found (this lcec build handles DC entirely via the XML config).In ethercat-conf.xml, we shifted the master period to 1000000 (1 ms) and cycled through <dcConf> configurations: assignActivate="300", hex assignActivate="0x0300", and added a phase offset sync0Shift="250000".We also attempted to completely disable DC (Free-Run / SM-Sync mode) by using assignActivate="0000", assignActivate="0x0210", or removing the <dcConf /> tag altogether.Result: ESC registers 0x092c and 0x0910 indicate that the drive sees the master's time but reports a massive System Time Offset (~2.7 seconds). The Lenze drive ignores the mode changes and remains stuck at code 20000. We also tried shifting the PDO map to the alternative standard TwinCAT ESI indices (1601 / 1a01 instead of 1600 / 1a00), but the 20000 error persists.Questions for the Community:Lenze ECS Error Code 20000: When dealing with Lenze ECS CoE modules under linuxcnc-ethercat, what exactly triggers the 20000 (0x4E20) bus status? Is it strictly a DC phase synchronization timeout, or is it a Sync Manager length mismatch?TxPDO 14-bit Alignment Gap: How should the 0x0000 index with a 14-bit length be mapped in ethercat-conf.xml for a generic slave so that the lcec driver counts it toward the total SM3 size (which must be exactly 26 bytes) without triggering a halType parsing error?PDO Mapping via SDOs: Does the Lenze ECS series require explicit PDO mapping commands via <initCmds> in the XML configuration, or should the master automatically handle the structure when type="generic" and configPdos="true" are set?Realtek NIC Impact: Could the standard generic Linux EtherCAT driver on an integrated Realtek chip cause a phase drift large enough (~2.7s offset in register 0x0910) to make Lenze reject DC synchronization entirely? Should I force a specific native driver or swap to an Intel NIC?
1. Enabling the Network Interface (Bringing the Link UP)The network card was initially disabled at the OS level (status DOWN), which prevented the EtherCAT master from sending any packets.Action taken: Forced the network interface enp2s0 to turn on using the following command:bashsudo ip link set enp2s0 up
2. CPU Core Isolation for Real-Time (In the GRUB Configuration)The standard network card driver (generic) was delaying packets, causing LinuxCNC to freeze and EtherCAT to trigger datagram timeouts.Action taken: Corrected the Linux kernel boot parameters line in /etc/default/grub. This isolated the 4th CPU core (index 3) exclusively for real-time and EtherCAT tasks and completely disabled power-saving sleep modes:iniGRUB_CMDLINE_LINUX_DEFAULT="quiet isolcpus=3 nohz_full=3 rcu_nocbs=3 intel_idle.max_cstate=0 processor.max_cstate=0 idle=poll"
(Changes were applied via sudo update-grub followed by a system reboot).
3. Binding the MAC Address to the EtherCAT MasterThis tells the EtherCAT service which specific physical port on the PC to use for communicating with the Lenze drive.Action taken: Added your card's unique hardware MAC address into the main EtherCAT service configuration file (under the line MASTER0_DEVICE="00:e0:26:32:3a:40").4. Preparing to Disable Hardware Optimizations (Offloading)Because EtherCAT communicates using raw Ethernet frames without IP addresses, the network chip was attempting to reassemble them. This resulted in thousands of transmission errors (Tx errors). To fix this, we prepared a command to disable all chip optimizations using the ethtool utility:bashsudo ethtool -K enp2s0 tx off rx off sg off tso off gso off gro off lro off


I am also providing a PDF with screenshots from TwinCAT taken from the machine where this axis module ECSCM048C4B was installed, together with the communication module EMF2192IB mounted on top (I think this will be useful).Additionally, I downloaded the XML for the EMF2192IB from TwinCAT, named Lenze_EMF2192_20101005.xml.I am also including the INI, HAL, and ethercat-config.xml files that I created with the help of artificial intelligence, as well as the command‑line outputs.            

Hi everyone,
Could you please advise what to do in this situation:

When reading the PDOs, I see CiA402 indices.

But when reading the SDOs, I get indices mapped at 0x1600 and 0x1A00, which belong to the hardware interface (AIF). This mapping seems to be specific to Lenze.

Previously, the drive worked under CiA402 on a dismantled machine controlled by TwinCAT.

Now, when I try to automatically generate the XML via lcec_configgen, the XML is created with the hardware-specific indices instead of the CiA402 ones.

Has anyone dealt with this mismatch between CiA402 and Lenze’s AIF mapping? Is there a way to force or configure the XML generation so it uses CiA402 indices instead of the hardware-specific ones?

Thanks in advance for your help!

Have you tried it? It should work but you need to share sdos, pdos and configgen xml

debian@debian:~$ ethercat slaves -v
=== Master 0, Slave 0 ===
Device: Main
State: PREOP
Flag: +
Identity:
Vendor Id: 0x0000003b
Product code: 0x014e7bc0
Revision number: 0x00000001
Serial number: 0x00000000
DL information:
FMMU bit operation: no
Distributed clocks: yes, 64 bit
DC system time transmission delay: 0 ns
Port Type Link Loop Signal NextSlave RxTime [ns] Diff [ns] NextDc [ns]
0* MII up open yes - 459143642 0 0
1 MII down closed no - - - -
2 N/A down closed no - - - -
3 N/A down closed no - - - -
Mailboxes:
Bootstrap RX: 0x1000/244, TX: 0x10f4/244
Standard RX: 0x1000/256, TX: 0x1100/256
Supported protocols: CoE, FoE
General:
Group: Drives
Image name:
Order number: Servo ECSxM CiA 402
Device name: Servo ECSxM CiA 402
CoE details:
Enable SDO: yes
Enable SDO Info: yes
Enable PDO Assign: no
Enable PDO Configuration: no
Enable Upload at startup: no
Enable SDO complete access: yes
Flags:
Enable SafeOp: no
Enable notLRW: no
Current consumption: 0 mA



debian@debian:~$ ethercat sdos
SDO 0x1000, "Device type"
0x1000:00, r-r-r-, uint32, 32 bit, "Device type"
SDO 0x1008, "Device name"
0x1008:00, r-r-r-, string, 176 bit, "Device name"
SDO 0x1009, "Hardware version"
0x1009:00, r-r-r-, string, 16 bit, "Hardware version"
SDO 0x100a, "Software version"
0x100a:00, r-r-r-, string, 88 bit, "Software version"
SDO 0x1018, "Identity"
0x1018:00, r-r-r-, uint8, 8 bit, "SubIndex 000"
0x1018:01, r-r-r-, uint32, 32 bit, "Vendor ID"
0x1018:02, rwrwrw, uint32, 32 bit, "Product code"
0x1018:03, r-r-r-, uint32, 32 bit, "Revision"
0x1018:04, r-r-r-, uint32, 32 bit, "Serial number"
SDO 0x1600, "IO Outputs"
0x1600:00, rwr-r-, uint8, 8 bit, "SubIndex 000"
0x1600:01, rwr-r-, uint32, 32 bit, "SubIndex 001"
0x1600:02, rwr-r-, uint32, 32 bit, "SubIndex 002"
0x1600:03, rwr-r-, uint32, 32 bit, "SubIndex 003"
0x1600:04, rwr-r-, uint32, 32 bit, "SubIndex 004"
0x1600:05, rwr-r-, uint32, 32 bit, "SubIndex 005"
0x1600:06, rwr-r-, uint32, 32 bit, "SubIndex 006"
0x1600:07, rwr-r-, uint32, 32 bit, "SubIndex 007"
0x1600:08, rwr-r-, uint32, 32 bit, "SubIndex 008"
0x1600:09, rwr-r-, uint32, 32 bit, "SubIndex 009"
0x1600:0a, rwr-r-, uint32, 32 bit, "SubIndex 010"
0x1600:0b, rwr-r-, uint32, 32 bit, "SubIndex 011"
0x1600:0c, rwr-r-, uint32, 32 bit, "SubIndex 012"
SDO 0x1800, "IO Inputs"
0x1800:00, r-r-r-, uint8, 8 bit, "SubIndex 000"
0x1800:01,

---

, type 0000, 0 bit, "SubIndex 001"
0x1800:02,

---

, type 0000, 0 bit, "SubIndex 002"
0x1800:03,

---

, type 0000, 0 bit, "SubIndex 003"
0x1800:04,

---

, type 0000, 0 bit, "SubIndex 004"
0x1800:05,

---

, type 0000, 0 bit, "SubIndex 005"
0x1800:06,

---

, type 0000, 0 bit, "SubIndex 006"
0x1800:07, r-r-r-, bool, 1 bit, "TxPDO State"
0x1800:08,

---

, type 0000, 0 bit, "SubIndex 008"
0x1800:09, r-r-r-, bool, 1 bit, "TxPDO Toggle"
SDO 0x1a00, "IO Inputs"
0x1a00:00, rwr-r-, uint8, 8 bit, "SubIndex 000"
0x1a00:01, rwr-r-, uint32, 32 bit, "SubIndex 001"
0x1a00:02, rwr-r-, uint32, 32 bit, "SubIndex 002"
0x1a00:03, rwr-r-, uint32, 32 bit, "SubIndex 003"
0x1a00:04, rwr-r-, uint32, 32 bit, "SubIndex 004"
0x1a00:05, rwr-r-, uint32, 32 bit, "SubIndex 005"
0x1a00:06, rwr-r-, uint32, 32 bit, "SubIndex 006"
0x1a00:07, rwr-r-, uint32, 32 bit, "SubIndex 007"
0x1a00:08, rwr-r-, uint32, 32 bit, "SubIndex 008"
0x1a00:09, rwr-r-, uint32, 32 bit, "SubIndex 009"
0x1a00:0a, rwr-r-, uint32, 32 bit, "SubIndex 010"
0x1a00:0b, rwr-r-, uint32, 32 bit, "SubIndex 011"
0x1a00:0c, rwr-r-, uint32, 32 bit, "SubIndex 012"
0x1a00:0d, rwr-r-, uint32, 32 bit, "SubIndex 013"
0x1a00:0e, rwr-r-, uint32, 32 bit, "SubIndex 014"
0x1a00:0f, rwr-r-, uint32, 32 bit, "SubIndex 015"
SDO 0x1c00, "Sync manager type"
0x1c00:00, r-r-r-, uint8, 8 bit, "SubIndex 000"
0x1c00:01, r-r-r-, uint8, 8 bit, "SubIndex 001"
0x1c00:02, r-r-r-, uint8, 8 bit, "SubIndex 002"
0x1c00:03, r-r-r-, uint8, 8 bit, "SubIndex 003"
0x1c00:04, r-r-r-, uint8, 8 bit, "SubIndex 004"
SDO 0x1c12, "RxPDO assign"
0x1c12:00, r-r-r-, uint8, 8 bit, "SubIndex 000"
0x1c12:01, r-r-r-, uint16, 16 bit, "SubIndex 001"
SDO 0x1c13, "TxPDO assign"
0x1c13:00, r-r-r-, uint8, 8 bit, "SubIndex 000"
0x1c13:01, r-r-r-, uint16, 16 bit, "SubIndex 001"
SDO 0x1c32, "SM output parameter"
0x1c32:00, r-r-r-, uint8, 8 bit, "SubIndex 000"
0x1c32:01, rwrwrw, uint16, 16 bit, "Synchronization Type"
0x1c32:02, rwrwrw, uint32, 32 bit, "Cycle Time"
0x1c32:03, r-r-r-, uint32, 32 bit, "Shift Time"
0x1c32:04, r-r-r-, uint16, 16 bit, "Synchronization Types supported"
0x1c32:05, r-r-r-, uint32, 32 bit, "Minimum Cycle Time"
0x1c32:06, r-r-r-, uint32, 32 bit, "Calc and Copy Time"
0x1c32:07, r-r-r-, type 0000, 0 bit, "Minimum fast cycle time"
0x1c32:08, r-r-r-, uint16, 16 bit, "Get Cycle Time"
0x1c32:09, r-r-r-, uint32, 32 bit, "Delay Time"
0x1c32:0a, r-r-r-, uint32, 32 bit, "Sync0 Cycle Time"
0x1c32:0b, r-r-r-, uint32, 32 bit, "Cycle Time Too Small"
0x1c32:0c, r-r-r-, uint32, 32 bit, "SM-Event missed"
0x1c32:0d, r-r-r-, uint32, 32 bit, "Shift Time Too Short"
0x1c32:0e, r-r-r-, uint32, 32 bit, "RxPDO Toggle Failed"
0x1c32:0f, r-r-r-, type 0000, 0 bit, "Minimum Cycle Distance"
0x1c32:10, r-r-r-, type 0000, 0 bit, "Maximum Cycle Distance"
0x1c32:11, r-r-r-, type 0000, 0 bit, "Minimum SM SYNC Distance"
0x1c32:12, r-r-r-, type 0000, 0 bit, "Maximum SM SYNC Distance"
0x1c32:13, r-r-r-, type 0000, 0 bit, "SubIndex 019"
0x1c32:14, r-r-r-, type 0000, 0 bit, "SubIndex 020"
0x1c32:15, r-r-r-, type 0000, 0 bit, "SubIndex 021"
0x1c32:16, r-r-r-, type 0000, 0 bit, "SubIndex 022"
0x1c32:17, r-r-r-, type 0000, 0 bit, "SubIndex 023"
0x1c32:18, r-r-r-, type 0000, 0 bit, "SubIndex 024"
0x1c32:19, r-r-r-, type 0000, 0 bit, "SubIndex 025"
0x1c32:1a, r-r-r-, type 0000, 0 bit, "SubIndex 026"
0x1c32:1b, r-r-r-, type 0000, 0 bit, "SubIndex 027"
0x1c32:1c, r-r-r-, type 0000, 0 bit, "SubIndex 028"
0x1c32:1d, r-r-r-, type 0000, 0 bit, "SubIndex 029"
0x1c32:1e, r-r-r-, type 0000, 0 bit, "SubIndex 030"
0x1c32:1f, r-r-r-, type 0000, 0 bit, "SubIndex 031"
0x1c32:20, r-r-r-, bool, 1 bit, "Sync Error"
SDO 0x1c33, "SM input parameter"
0x1c33:00, r-r-r-, uint8, 8 bit, "SubIndex 000"
0x1c33:01, rwrwrw, uint16, 16 bit, "Synchronization Type"
0x1c33:02, rwrwrw, uint32, 32 bit, "Cycle Time"
0x1c33:03, r-r-r-, uint32, 32 bit, "Shift Time"
0x1c33:04, r-r-r-, uint16, 16 bit, "Synchronization Types supported"
0x1c33:05, r-r-r-, uint32, 32 bit, "Minimum Cycle Time"
0x1c33:06, r-r-r-, uint32, 32 bit, "Calc and Copy Time"
0x1c33:07, r-r-r-, type 0000, 0 bit, "Minimum fast cycle time"
0x1c33:08, r-r-r-, uint16, 16 bit, "Get Cycle Time"
0x1c33:09, r-r-r-, uint32, 32 bit, "Delay Time"
0x1c33:0a, r-r-r-, uint32, 32 bit, "Sync0 Cycle Time"
0x1c33:0b, r-r-r-, uint32, 32 bit, "Cycle Time Too Small"
0x1c33:0c, r-r-r-, uint32, 32 bit, "SM-Event missed"
0x1c33:0d, r-r-r-, uint32, 32 bit, "Shift Time Too Short"
0x1c33:0e, r-r-r-, uint32, 32 bit, "RxPDO Toggle Failed"
0x1c33:0f, r-r-r-, type 0000, 0 bit, "Minimum Cycle Distance"
0x1c33:10, r-r-r-, type 0000, 0 bit, "Maximum Cycle Distance"
0x1c33:11, r-r-r-, type 0000, 0 bit, "Minimum SM SYNC Distance"
0x1c33:12, r-r-r-, type 0000, 0 bit, "Maximum SM SYNC Distance"
0x1c33:13, r-r-r-, type 0000, 0 bit, "SubIndex 019"
0x1c33:14, r-r-r-, type 0000, 0 bit, "SubIndex 020"
0x1c33:15, r-r-r-, type 0000, 0 bit, "SubIndex 021"
0x1c33:16, r-r-r-, type 0000, 0 bit, "SubIndex 022"
0x1c33:17, r-r-r-, type 0000, 0 bit, "SubIndex 023"
0x1c33:18, r-r-r-, type 0000, 0 bit, "SubIndex 024"
0x1c33:19, r-r-r-, type 0000, 0 bit, "SubIndex 025"
0x1c33:1a, r-r-r-, type 0000, 0 bit, "SubIndex 026"
0x1c33:1b, r-r-r-, type 0000, 0 bit, "SubIndex 027"
0x1c33:1c, r-r-r-, type 0000, 0 bit, "SubIndex 028"
0x1c33:1d, r-r-r-, type 0000, 0 bit, "SubIndex 029"
0x1c33:1e, r-r-r-, type 0000, 0 bit, "SubIndex 030"
0x1c33:1f, r-r-r-, type 0000, 0 bit, "SubIndex 031"
0x1c33:20, r-r-r-, bool, 1 bit, "Sync Error"
SDO 0x58a4, "(C1883) Process data monitoring time"
0x58a4:00, rwrwrw, uint32, 32 bit, "(C1883) Process data monitoring time"
SDO 0x58a5, "(C1882) Process data monitoring reaction"
0x58a5:00, rwrwrw, uint32, 32 bit, "(C1882) Process data monitoring reaction"
SDO 0x58c5, "(C1850) Station alias"
0x58c5:00, rwrwrw, uint32, 32 bit, "(C1850) Station alias"
SDO 0x58d9, "(C1830) EtherCAT bus state"
0x58d9:00, r-r-r-, uint32, 32 bit, "(C1830) EtherCAT bus state"
SDO 0x58df, "(C1825) Outputs (32 Bit values)"
0x58df:00, r-r-r-, uint8, 8 bit, "SubIndex 000"
0x58df:01, r-r-r-, uint32, 32 bit, "SubIndex 001"
0x58df:02, r-r-r-, uint32, 32 bit, "SubIndex 002"
0x58df:03, r-r-r-, uint32, 32 bit, "SubIndex 003"
0x58df:04, r-r-r-, uint32, 32 bit, "SubIndex 004"
0x58df:05, r-r-r-, uint32, 32 bit, "SubIndex 005"
0x58df:06, r-r-r-, uint32, 32 bit, "SubIndex 006"
0x58df:07, r-r-r-, uint32, 32 bit, "SubIndex 007"
0x58df:08, r-r-r-, uint32, 32 bit, "SubIndex 008"
0x58df:09, r-r-r-, uint32, 32 bit, "SubIndex 009"
0x58df:0a, r-r-r-, uint32, 32 bit, "SubIndex 010"
0x58df:0b, r-r-r-, uint32, 32 bit, "SubIndex 011"
SDO 0x58de, "(C1824) Inputs (32 Bit values)"
0x58de:00, r-r-r-, uint8, 8 bit, "SubIndex 000"
0x58de:01, r-r-r-, uint32, 32 bit, "SubIndex 001"
0x58de:02, r-r-r-, uint32, 32 bit, "SubIndex 002"
0x58de:03, r-r-r-, uint32, 32 bit, "SubIndex 003"
0x58de:04, r-r-r-, uint32, 32 bit, "SubIndex 004"
0x58de:05, r-r-r-, uint32, 32 bit, "SubIndex 005"
0x58de:06, r-r-r-, uint32, 32 bit, "SubIndex 006"
0x58de:07, r-r-r-, uint32, 32 bit, "SubIndex 007"
0x58de:08, r-r-r-, uint32, 32 bit, "SubIndex 008"
0x58de:09, r-r-r-, uint32, 32 bit, "SubIndex 009"
0x58de:0a, r-r-r-, uint32, 32 bit, "SubIndex 010"
0x58de:0b, r-r-r-, uint32, 32 bit, "SubIndex 011"
SDO 0x58e1, "(C1823) Outputs"
0x58e1:00, r-r-r-, uint8, 8 bit, "SubIndex 000"
0x58e1:01, r-r-r-, uint16, 16 bit, "SubIndex 001"
0x58e1:02, r-r-r-, uint16, 16 bit, "SubIndex 002"
0x58e1:03, r-r-r-, uint16, 16 bit, "SubIndex 003"
0x58e1:04, r-r-r-, uint16, 16 bit, "SubIndex 004"
0x58e1:05, r-r-r-, uint16, 16 bit, "SubIndex 005"
0x58e1:06, r-r-r-, uint16, 16 bit, "SubIndex 006"
0x58e1:07, r-r-r-, uint16, 16 bit, "SubIndex 007"
0x58e1:08, r-r-r-, uint16, 16 bit, "SubIndex 008"
0x58e1:09, r-r-r-, uint16, 16 bit, "SubIndex 009"
0x58e1:0a, r-r-r-, uint16, 16 bit, "SubIndex 010"
0x58e1:0b, r-r-r-, uint16, 16 bit, "SubIndex 011"
0x58e1:0c, r-r-r-, uint16, 16 bit, "SubIndex 012"
SDO 0x58e0, "(C1822) Inputs"
0x58e0:00, r-r-r-, uint8, 8 bit, "SubIndex 000"
0x58e0:01, r-r-r-, uint16, 16 bit, "SubIndex 001"
0x58e0:02, r-r-r-, uint16, 16 bit, "SubIndex 002"
0x58e0:03, r-r-r-, uint16, 16 bit, "SubIndex 003"
0x58e0:04, r-r-r-, uint16, 16 bit, "SubIndex 004"
0x58e0:05, r-r-r-, uint16, 16 bit, "SubIndex 005"
0x58e0:06, r-r-r-, uint16, 16 bit, "SubIndex 006"
0x58e0:07, r-r-r-, uint16, 16 bit, "SubIndex 007"
0x58e0:08, r-r-r-, uint16, 16 bit, "SubIndex 008"
0x58e0:09, r-r-r-, uint16, 16 bit, "SubIndex 009"
0x58e0:0a, r-r-r-, uint16, 16 bit, "SubIndex 010"
0x58e0:0b, r-r-r-, uint16, 16 bit, "SubIndex 011"
0x58e0:0c, r-r-r-, uint16, 16 bit, "SubIndex 012"
SDO 0x58ec, "(C1811) Software creation date"
0x58ec:00, r-r-r-, string, 136 bit, "(C1811) Software creation date"
SDO 0x58ed, "(C1810) Software identification code"
0x58ed:00, r-r-r-, string, 112 bit, "(C1810) Software identification code"



debian@debian:~$ ethercat pdos
SM0: PhysAddr 0x1000, DefaultSize 256, ControlRegister 0x26, Enable 1
SM1: PhysAddr 0x1100, DefaultSize 256, ControlRegister 0x22, Enable 1
SM2: PhysAddr 0x1200, DefaultSize 24, ControlRegister 0x24, Enable 1
RxPDO 0x1600 "IO Outputs"
PDO entry 0x6040:00, 16 bit, "Control word"
PDO entry 0x60b8:00, 16 bit, "TP Function"
PDO entry 0x607a:00, 32 bit, "Target position"
PDO entry 0x60ff:00, 32 bit, "Target velocity"
PDO entry 0x58e1:07, 16 bit, "SubIndex 007"
PDO entry 0x58e1:08, 16 bit, "SubIndex 008"
PDO entry 0x58e1:09, 16 bit, "SubIndex 009"
PDO entry 0x58e1:0a, 16 bit, "SubIndex 010"
PDO entry 0x58e1:0b, 16 bit, "SubIndex 011"
PDO entry 0x58e1:0c, 16 bit, "SubIndex 012"
SM3: PhysAddr 0x1900, DefaultSize 26, ControlRegister 0x20, Enable 1
TxPDO 0x1a00 "IO Inputs"
PDO entry 0x0000:00, 14 bit, ""
PDO entry 0x1800:09, 1 bit, "TxPDO Toggle"
PDO entry 0x1800:07, 1 bit, "TxPDO State"
PDO entry 0x6041:00, 16 bit, "Status word"
PDO entry 0x60b9:00, 16 bit, "TP Status"
PDO entry 0x6064:00, 32 bit, "Position actual value"
PDO entry 0x60ba:00, 32 bit, "TP Pos1 pos value"
PDO entry 0x60bb:00, 32 bit, "TP Pos1 neg value"
PDO entry 0x58e0:09, 16 bit, "SubIndex 009"
PDO entry 0x58e0:0a, 16 bit, "SubIndex 010"
PDO entry 0x58e0:0b, 16 bit, "SubIndex 011"
PDO entry 0x58e0:0c, 16 bit, "SubIndex 012"



debian@debian:~$ sudo ethercat upload -p 0 0x1A00 00 -t uint8
0x0f 15
debian@debian:~$ sudo ethercat upload -p 0 0x1A00 01 -t uint32
0x0000000e 14
debian@debian:~$ sudo ethercat upload -p 0 0x1A00 0x02 -t uint32
0x18000901 402655489
debian@debian:~$ sudo ethercat upload -p 0 0x1A00 0x03 -t uint32
0x18000701 402654977
debian@debian:~$ sudo ethercat upload -p 0 0x1A00 0x04 -t uint32
0x58e00110 1491075344
debian@debian:~$ sudo ethercat upload -p 0 0x1A00 0x05 -t uint32
0x58e00210 1491075600
debian@debian:~$ sudo ethercat upload -p 0 0x1A00 0x06 -t uint32
0x58e00310 1491075856
debian@debian:~$ sudo ethercat upload -p 0 0x1A00 0x07 -t uint32
0x58e00410 1491076112
debian@debian:~$ sudo ethercat upload -p 0 0x1A00 0x08 -t uint32
0x58e00510 1491076368
debian@debian:~$ sudo ethercat upload -p 0 0x1A00 0x09 -t uint32
0x58e00610 1491076624
debian@debian:~$ sudo ethercat upload -p 0 0x1A00 0x0a -t uint32
0x58e00710 1491076880
debian@debian:~$
debian@debian:~$
debian@debian:~$
debian@debian:~$
debian@debian:~$ sudo ethercat upload -p 0 0x6064 00 -t uint32
0xfffd1990 4294777232
debian@debian:~$ sudo ethercat upload -p 0 0x6064 00 -t uint32
0xfffdabd2 4294814674
debian@debian:~$ sudo ethercat upload -p 0 0x6064 00 -t uint32
0xfffeab25 4294880037
debian@debian:~$ sudo ethercat upload -p 0 0x6064 00 -t uint32
0x000001a6 422
debian@debian:~$ sudo ethercat upload -p 0 0x6064 00 -t uint32
0x0000569c 22172
debian@debian:~$ sudo ethercat upload -p 0 0x6064 00 -t uint32
0x0000ac55 44117



I want to share some critical findings regarding the integration of the Lenze ECSxM multi-axis servo drive equipped with the EMF2192IB EtherCAT communication module into LhntxBNB (uring linuxcnc-ethercat / lcec). This setup has a very specific architectural layout that completely misleads standard auto-configuration tools.Here is the exact breakdown of the contradictions and hidden traps we discovered under the hood:1. The Core Issue: SDO Mapping vs. Live PDO RealityThe Live Test: When I manually switch the drive to the PREOP + state using the ethercat CLI tool and manually turn the motor shaft by hand, I can see the encoder ticks updating live in the 0x6064 (Position Actual Value) register. This confirms that the CiA 402 profile layer is working inside the drive.The SDO Mapping Contradiction: However, when I look at the actual SDO mapping data for 0x1A00, the sub-indexes point to Lenze's internal, proprietary AIF registers (like 0x58E0) rather than the standard CiA 402 objects.2. Hidden Technical Padding at the Very BeginningWe discovered that the drive forces a fixed bit layout that starts with technical data instead of the control/status registers. Specifically, there is a hidden padding at the very beginning of the TxPDO stream:The first 14 bits are completely occupied by the internal AIF interface system flags (0x0000:00).The next 2 bits contain the drive's internal state/toggle register (0x1800:09).Only after these initial 16 bits does the standard CiA 402 0x6041 Statusword actually begin.3. No Distributed Clocks (Strictly Free Run Mode)By uploading the synchronization manager parameters directly from the drive via CoE, we checked indexes 0x1C32:01 and 0x1C33:01. Both returned 0x0000 (0).This explicitly proves that Distributed Clocks (DC) hardware synchronization is disabled in the drive firmware. The device operates strictly in Free Run mode. Any attempt by the master to force a strict DC cycle or reference clock sync results in frame timeouts and connection drops.4. Why Automatic Configuration (lcec) Crashes ImmediatelyWhen running automatic configuration tools (such as ethercat config > ... or standard generic driver discovery), the master relies strictly on the statib SDN lapphnf tables reported by the drive.As a result:It generates an XML file filled with internal AIF indexes instead of CiA 402 objects.It completely misses the 14-bit hidden padding at the very beginning of the stream. Because of this, the entire data stream shifts by 14 bits, the parser reads garbage, and lcec crashes immediately.It tries to initialize DC synchronization which the drive rejects.

Sometimes I think prior knowledge of other Ethercat environments just adds to the confusion. Twincat is useless to me.
Does the XML you provided work?
It looks like it should.
If there truly is a 14 byte offset, you just need to add some dummy registers to account for them.

Please take the time to format you replies, the data you provide is very difficult to read.