Advanced Search

The remote uses the RS422 protocol with a baud rate of 57600, configured for 8 data bits, no parity, and 1 stop bit (8N1).

For testing, I wrote a Python module to communicate with the remote via a COM-to-RS422 adapter, though I suspect it’s not very reliable.

My idea is to create a custom real-time LinuxCNC component, similar to the mesa_modbus component, and possibly use the internal hostmot2 C-API functions (hm2_pktuart_send(), hm2_pktuart_read(), and hm2_pktuart_setup()) to directly push and pull byte arrays into the FPGA’s transmit and receive FIFOs during the real-time servo thread.


 

can you supply a sample program ?

Japoo_Ness wrote:

Lastly, I’d love to get your advice on the best learning path to fully grasp how Mesa cards interface with LinuxCNC. Should I just wire everything up on the test bench and learn by trial and error, or is there a specific documentation, manual, or forum thread you'd recommend reading first to avoid spinning my wheels?

Depends a lot, but documentation is a nice start, browsing this forum helps a lot, and there are tutorials/howto's for near everything be it very nice or chaotic written by me.
But nothing can replace the hands on approach: wire stuff and test while reading and checking pictures.
-
This last is how i learned last few days that Pico2W is utterly useless as a flight controller, for many, many reasons, but mostly their (anything RPI) being convoluted and disorganized beyond belief for something normal people should use, requiring hundreds of libraries, and never ever consistently building firmware without complaint.
No wonder ESP32 won, much cheaper and much faster and most importantly with flash memory.
Next, use that Pico2w for LinuxCNC, oh joy!

What protocol does the pendant use?

Hi everyone,

I've just purchased the host PC and I'm waiting for it to arrive so I can set up the RT-OS and start digging into the retrofit.

To practice on the bench and learn the ins and outs of LinuxCNC, I put together a Mesa hardware stack: 7i97T + 7i74 + 7i84U + 7i73.

I have a quick question regarding the initial configuration workflow. From what I’ve gathered reading through the forum and docs, the easiest path forward seems to be:

Use mesaflash to flash the proper binary (.bin) to the 7i97T so it supports the Smart Serial expansion through the 7i74.

Once the main FPGA board has that specific firmware, use mesact to configure the machine basics, pinout, and closed-loop settings.

Regarding step 1: Is mesaflash strictly necessary for this, or can I flash the firmware directly from within mesact? From what I've seen in recent updates, it looks like mesact has a built-in flashing utility that might work for this. Is that correct and reliable for ethernet cards?

Lastly, I’d love to get your advice on the best learning path to fully grasp how Mesa cards interface with LinuxCNC. Should I just wire everything up on the test bench and learn by trial and error, or is there a specific documentation, manual, or forum thread you'd recommend reading first to avoid spinning my wheels?

Thanks a lot for all the help!

I understand how to use Modbus, thanks.
How do I use Channel 6: pktUART (RS-422 for the pendant)? Is it the same as Modbus?

The pktuart driver creates no hal pins

for modbus, you would use hm2_modbus:

man hm2_modbus

and mesambccc:

man mesambccc


 

After updating LinuxCNC, it starts normally. I load it using:
loadrt hm2_pci config="num_encoders=3 num_pwmgens=0 num_stepgens=0 sserial_port_0=000000 num_pktuarts=2"

However, I have another problem: I can’t find any pins like these:
hm2_5i25.0.pktuart.0.tx-data
hm2_5i25.0.pktuart.0.tx-bytes
hm2_5i25.0.pktuart.0.rx-data
hm2_5i25.0.pktuart.0.rx-bytes

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 Endian:

Thanks for your reply and sorry for the delay in responding, it completely slipped my mind...

The EL7221-9014 and ZB8610 modules have arrived, but I had to request the motor and cables. The supplier told me they'll arrive this week! I'm dying to have everything so I can start working! I think I included homing among the capabilities of the EL7221-9014 module in my previous description, and it's true what you said, the module doesn't hom, although it does have probing. Regarding the latter, it's not absolutely necessary for me; I'll use LinuxCNC's homing. What I would like, as I explained before, is to use the module in speed mode with its internal control...

As soon as I have everything, I'll start testing. I'll update you. Regards and thanks.

Yes, too old to run MODBUS which requires a PktUART version >1:


hm2/hm2_5i25.0: inconsistent Module Descriptor for PktUART Transmit Channel, not loading driver
hm2/hm2_5i25.0: Version = 3, expected 0


Also with this firmware there is no sserial port 1
(all channels = 0..7 are port 0)

I am starting this thread to seek information and guidance, with the hope that it may also serve as a helpful resource for others facing similar challenges.I am currently considering retrofitting my machine as the most practical option, given the scarcity and high cost of original replacement parts. With that in mind, I would appreciate any advice on the best approach to begin this project.

Firmware flashed without any errors. However, when launching my configuration, I receive errors.

Could this be because of the old Linux?

Or am I loading it wrong?
loadrt hm2_pci config="num_encoders=3 num_pwmgens=0 num_stepgens=0 sserial_port_0=000000 sserial_port_1=00000000"

Terminal output:

Note: Using POSIX realtime
hm2/hm2_5i25.0: inconsistent Module Descriptor for PktUART Transmit Channel, not loading driver
hm2/hm2_5i25.0: Version = 3, expected 0
hm2/hm2_5i25.0: NumRegisters = 4, expected 4
hm2/hm2_5i25.0: InstanceStride = 0x00000004, expected 0x00000004
hm2/hm2_5i25.0: MultipleRegisters = 0x0000000F, expected 0x0000000F
hm2/hm2_5i25.0: inconsistent Module Descriptor!
hm2/hm2_5i25.0: failed to parse Module Descriptor 5
hm2_5i25.0: board fails HM2 registration
RTAPI_PCI: Unmapped 65536 bytes at 0x7f733da96000
Driver probe function failed!
hm2_pci: error registering PCI driver
hm2_pci: rtapi_app_main: Operation not permitted (-1)

Thanks a lot for your time and support!

That's absolutely right; I'm trying to get it to look like your screenshot, but everything is on the same plane for me,