Optimizing for precision and speed

DMA

PDO reads should really be handled by DMA. Let us configure it and see how it goes. It works an then stops, it either randomly disconnects or starts to spew trash values, causing CiA402 state machine errors. Without DMA everything was working and was stable, so it is not power issue. Time to connect logic analyzer to see what is happening. At hand is cheapo FX2 based probe, to make it keep up SPI clock prescaler needs to be bigger, to drop clock frequency from max 41 MHz, to 5.125MHz. At this speed, transmission with DMA is stable back again. What can it be?

Turns out, simple SPI implementation (sending byte by byte) adds significant breaks between each byte. DMA sends all bytes in one go, back to back. SPI addressing can be done in 2 bytes, or 3 bytes (with wait state byte) - second solution is meant to give ESC enough time to fetch valid data from memory into SPI, but there is minimal cycle time value, Tread for that. According to datashet Tread should be at least 240 ns. Using 3 byte addressing with wait state should solve it, and it does, up to 21 MHz. Unfortunately at SPI1 max speed, 41Mhz, with current setup problem persists. Maybe it is caused by current board layout and it could be fixed on next HW revision? Then again, it looks to be fast enough to work on STMBL, and SPI2 on ODrive tops out on 21 MHz anyway so for now it looks good enough - on to next problems.

AX58100 moving towards interrupt mode - PDI interrupt and DC synchronization

It took a bit but now is working too. One needs to adjust settings in TwinCAT: assign Sync Unit to local device

Result is stable sync signal with very low jitter: about 150 ns even in large EtherCAT networks, according to Beckhoff claims

[TODO] oscilloscope shot of SYNC0 signals

Benchmark results

Despite slower SPI clock speed, cycle time is much better than LAN9252:

Polling (blocking SPI). SPI1 at 42 MHz

• Cables connected, ECAT master not connected: [ESC benchmark] 0006 us (0006 top)
• ECAT master connected, slv in OP: [ESC benchmark] 0015 us (0059 top)
• ECAT master connected, slv in OP, network startup hiscore reset: [ESC benchmark] 0015 us (0024 top)

Added CiA402 loopback, SPI1 at 42 MHz:

• ECAT master connected, slv in OP, network startup hiscore reset: [ESC benchmark] 0017 us (0025 top)

DMA SPI + CiA402 loopback. Prescaler 2 (42 MHz), SPI reads from ESC are unstable - transmission errors

• ECAT master connected, slv in OP: [ESC benchmark] 0017 us (0063 top)
• ECAT master connected, slv in OP, network startup hiscore reset: [ESC benchmark] 0017 us (0025 top)

DMA SPI + CiA402 loopback. Prescaler 4 (21 MHz: 2x slower clock), 2 us slower

• Cables connected, ECAT master not connected: [ESC benchmark] 0009 us (0009 top)
• ECAT master connected, slv in OP: [ESC benchmark] 0019 us (0073 top)
• ECAT master connected, slv in OP, network startup hiscore reset: [ESC benchmark] 0019 us (0030 top)

Seems like all that extra work with laying out another HW revision, and switching to new ESC from relatively unknown company, paid out. For now I will continue with AX58100. If anyone feels like stepping up and optimizing LAN9252 driver, PRs are welcome.

AX58100 Board design

LAN9252 indirect register addressing is complex … frankly it feels cumbersome. Building DMA for that is certainly possible (with few state machines and plenty interrupts) but super messy and not that efficient either. The original ESC from Beckhoff, ET1100, was much more straigtforward to work with. To see the difference, just compare SOES HAL files for ET1100 vs LAN9252. Look at line count of respective files should be enough. Unfortunately ET100 costs 2-3 times as much and requires more external elements. Luckily, we can eat the cake and have it too thanks to ASIX, Chinese company I have never heard of before. They got license from Beckhoff and made improved derivative, AX58100. ASIX chips are not really offered via typical western suppliers, but few Aliexpress sellers have it. I risked few dozen of $, and while waiting for shipping I also designed PCB based on LAN9252 second revision. This time STM32F4 Discovery adapter with 3.3V regulator (and separate USB for power) is part of PCB that can be snapped off like ST Link from Nucleo boards.

IBOM can be found here

AX58100 board assembly

Repeating approach that worked with LAN9252, DIG IO ESI was flashed at first, and it was working right off the bat. Board is doing good so far.

AX581000 with SOES

This ESC is based on ET1100, and one of HAL setups in SOES source target this chip. As was with LAN9252, lets implement SPI read/write and go to town.

It is not working. Why? Let us check datasheet and manual for migration from ET1100. To enable SPI PDI, 4K7 pullup resistor to 3v3 is needed on SCS_FUNC. Is it enough? Hardware wise yes, overall no. Some configuration registers are different on AX58100. More head banging against docs ensures. AX58100 datasheet is rather short, what is missing there can be found in ET1100 datasheet. Luckily ASIX has code samples for STM32 Nucleo available on their webpage, and those include ESI files with correct configuration bytes. For SPI setup turns out HIES register (Host Interface Extend Setting and Drive Strength) which is mapped to configuration byte 0x0A, should be set to 0x1a (INT edge pulse length, 8 mA Control + IO 9:0 Drive Select). It is in area covered by checksum, so we need to calculate new one too.

After all that time and head scratching, new board is reaching OP with SOES application. Radiator was added to mitigate overheating while working on getting right PDI configuration in ESI file. Now that it is correct, feels like it is not probably wont needed will test on next boards.

Example: CiA 402 application on AX58100 with STM32F4

In the meantime some things to correct were found in first revision of SPI adapter.

- QFN is annoying to hand solder. TQFP package was selected, there is enough space on PCB

- changed magjacks to cheaper ones

- EEPROM  switched from THT in socket to SMD package: less bulky, cheaper. Swapping chip from board bricked by bad config was never needed. No matter how bad was configuration, new one could be upload over EtherCAT every time.

IBOM can be found here

Design is ready to order and test, but due to performance benchmark results different approach was selected

Luckily SOES has HAL file for LAN9252 with SPI, only SPI config, read and write need to be implemented.

Example SOES application on LAN9252 with STM32F4

And example application is running on custom device. Great.

Speed benchmarking

We already know PDOs size. RxPDO (command from master to servodrive) will be uint16_t controlword + uint32_t position command, TxPDO (feedback from our servo device) is the same size: uint16_t statusword, uint32_t position actual, so it is 6 bytes in, 6 bytes out. We can set it in EasyCAT and see how long does it take to cycle. Then we can tweak PDOs in SOES project, and test speed the same way.

EasyCAT

Measured is PDI communication cycle time (EASYCAT.MainTask();) from start to return.

SSC	MCU	SPI driver	SPI speed	value [us]
EasyCAT	AtM328P	Arduino	8 MHz	196
EasyCAT	STM32F4	Arduino	8 MHz	210
EasyCAT	STM32F4	Arduino	42 MHz	118
EasyCAT	STM32F4	Arduino	42 MHz	107
EasyCAT	STM32F4	SPL	5.25 MHz	123
EasyCAT	STM32F4	SPL	42 MHz	35

SOES

Measured is how long does polled ecat_slv(); take from start to return. No interrupts, should be more deterministic and consistent. STM32F405 at 168 MHz. SPI1 at 42 MHz

• Cables connected, ECAT master not connected: [ESC benchmark] 0028 us (028 top)
• ECAT master connected, slv in OP: [ESC benchmark] 0072 us (0280 top)

Results are… not great for LAN9252 with CoE stack. It was okay with EasyCAT library, but something with SOES setup makes it much slower, and to make things worse timing is not consistent. Considering app notes from Microchip on measuring cycle time (with Slave Stack Code from Beckhoff) this should look way better, and deserves proper investigation.

SOES as Arduino library

At this point it is not much work to port SOES as Arduino library.

Sample project using popular STM32F103 “BluePill” devboard

CiA402 profile implementation

First step is to get CiA 402 state machine diagram, for example from datasheet of some servodrive implementing it. Hiwin has it described well . From this one can calculate commandword masks, command codes for each transition, statusword masks and status codes for each state. Here goes resulting transition table:

Then just retype these codes into .c header, connect it to get state machine code, wire it with object dictionary, set correct ProductCode="#x00020192" (0x192 is 402d, CiA402 profile code)… Oh, and add dummy motion control application: loopback Obj.Position_actual = Obj.Target_position;

CiA402 dummy on STM32F1

TwinCAT configuration

Way to test if node implementation is working is maing it work with TwinCAT. For that one needs to create project, and add point to point motion control with single axis. Connect device, scan for boxes and select new device in axis settings.

To launch project, one needs to enable configuration. If it is first time, fill captcha in prompt window to generate temporary license key for NC module

Configuration should be now active and new device should reach OP (Operational state of EtherCAT state machine). Now it is time to set target velocity and enable controller. Go to Online tab to do it. Then reset errors (F8 key or blue button), and activate axis (F5 or green button).

This is how it should look like. Dummy servo responds to commands, and reports it went exactly where controller requested.

Assembly

PCBs arrived from board house

First one is already assembled. It is dirty from resin-based flux, but looks OK

Connected to Ethernet port, and powered up. Nothing bad happened. Flashed with DIGIO ESI (EtherCAT Slave Info), restarted, opened Simple EtherCAT Explorer and looks it is working.

Now to make it work with microcontroller.

Testing

Lets start with EasyCAT Arduino library on ATMega, using platformio

It is working. How stable is it? Turns out not very much. After random period up, usually few minutes, ESC is either disconnected from master or starts to spew garbage values. What could be wrong? First culprit is power that was supplied from 3V3 regulator on Arduino. Lets add another one, powered from separate USB cable. That worked. For convinience, to have only 1 USB cable connected, 5V line to separate regulator can be pulled from ISCP header

BTW, turns out that LAN9252 lines are not 5V tolerant. Suprise, ESC is working entire time without issues, but is uncomfortably close to absolute maximum rating. Voltage level shifter fixes that.

Now on to port that STM32F4 Discovery board. Built quick adapter using SPI1 pinout exposed on STMBL extension header. Problem with power supply repeats. 3V3 from EVB is not good, another USB cable just to power up ESC is needed.

It is working too. But STMBL is using StdPeriph drivers. Time to ditch Arduino code and port SOES to SPL

Known issues

• Problem with OUT port. It is treated as network termination, following EtherCAT devices connected there are not detected by master.
• Proper separation of chassis ground from device ground with clearance will be needed beyond lab bench stage.
• All components should be on single side to simplify PCBA.
• Few silkscreens were messed up.
• ESC chip in TQFP housing would be easier to hand solder.
• So far EEPROM replacing was never needed, even at most messy initial stages. EEPROM should be SMD, to shave BOM cost and board size.
• Cheaper RJ45 magjack connectors were found (HanRun HR911105A)

TLDR: dont build this version. It worked good enough for my use case (single node development), but if you think of using it for anything practical buy EasyCAT PRO or wait for something better.

Next step: make CoE stack work on new hardware

Starting point was this open source project. Stripped schematic to bare minimum, based on EVB-LAN9252-SPI. Left only SQI PDI, then minified board area. Two layers, almost all components on single side for easier assembly and embedding into target devices.

Adapter board, first revision, straight from KiCad.

IBOM can be found here

Looks good. Board came out similar to EasyCAT Pro. Breakout header is compatible, additionally alongside it has full SQI exposed. Also EEPROM chip is THT in socket for simple swap if ESI flashing goes wrong and bricks device. Now forward to board house of choice, and wait for PCBs to arrive.

Spoiler alert: it worked good enough for what I needed, for practical use you better wait for something better or buy EasyCAT PRO

I am building EtherCAT adapter for open motor controllers like ODrive, STMBL, or your next thing.

Why that matters

We got a known problem in state of art open source robotics. On one side for years we got things like LinuxCNC: multiple axis, builtin PLC, free, field proven. If its not fit for application, every year progress in development tools (toolchains, code etitors, hardware) makes it easier to roll out custom one that will do the job. On he other side, we got plenty of OSS+OSHW actuators: projects like ODrive, STMBL, VESC and many more. Good to power things from BLDC motor in quadcopter, to benchtop laser ploter, to electric scooter, to industrial machining center. What is missing? Good free way to properly connect one to another. This might not sound like a problem for electric scooter, but starts to be when one tries to build robotic arm, quadruped robot or fast CNC machine, and I will explain why.

How OSS motion control used to be done

Legacy way of motion control in open source was to use step-dir over parallel port. It is simple way to control stepper motors working in open loop (without encoders or other sensors), devised back when everyone used PC towers that had LPT. Some modern digital servodrives are still supporting it, but this starts to be problematic for several reasons.

• This is in principle open loop communication. Lost pulse signal will result in quiet position error, as controller computer will not have a way to see target drive position. It is especially not elegant in using step-dir for servo drives position control. Position value is digital on controller side and on servodriver side, but communication channel makes it drop its digital nature, then pick it up again, then prevents actual position feedback to controller. Uuugly.
• It is speed bottleneck: speed of software step generation is limited. Exceeding it will result in errors: lost steps. Depending on PC setup, pushing pulse rates above 20 KHz - 100 KHz starts to be ridden with error. Compose it with open loop, and you only see this errors if it accumulates and becomes real problem (e.g. CNC machine plunges into workpiece few hours in the job).
• Additional I/O (homing, touchprobes, interlocks, signal lights) is limited. Parallel port lines can also be used for IO but they are fixed: both in number (there is only 16 lines total, les than half can be used as inputs), and position (some lines cannot be uset as inputs).
• Self diagnostics is limited: servo drive might detect and identify error state, but has no way to sent its code to controller.

How it is done now (in open source and entry level motion controllers)

LinuxCNC

• Linux CNC with LPT still is viable solution for machines with few stepper motors and limited IO. All drawbacks described above apply, but for CNC router this often is enough
• Linux CNC with Mesa cards: Mesa is company that offers line of extension cards with FPGA, targeting LinuxCNC. Bitfiles source code is open, hardware is proprietary but not expesive. There are multiple connectivity configurations for each card. First is using hardware step signal generation to overcome software stepgen limits. Much more reliable, works all right with servo drives supporting pulse-dir signals. Some cards got analog inputs and outputs and can be used to control older, voltage controlled servo amplifiers but this is really legacy solution for retrofits.
• There is also smart serial (sserial), Mesa specific protocol for modular extensions. It uses RS422 differential transmission for fast, noise resistant communication. If you want to use STMBL servo drives to build CNC machine, this seems to be the preffered way. Problem is STMBLs are hard to buy, and those (and some Mesa servo drives) are the only devices using sserial protocol (that I know of).
• LinuxCNC with proprietary extension cards, from vendors like yurtaev.com. These are adding support for proprietary protocols like SSCNET, MELDAS, Mechatrolink. Cards themselves are not open source, pricing is “contact us”. There is no open servodrive project using these. Drives from industrial vendors like Yaskawa or Mitsubishi will do its job for years, at industrial machine prices.
• LCEC: LinuxCNC with EtherCAT. Software is free. Fast, modular, requires no special hardware on controller side. Generic driver probably will work on computer you already have, available drivers support commodity PCI network cards available for few dollars. This protocol seems to be industrial standard gaining more and more popularity. Servo drives and I/O are available from plenty of industrial vendors. No open source actuators … so far.

Microcontroller based motion controllers

• GRBL, GRBL ports to 32 bit MCUs (ARM, ESP32) and other 32bit MCU CNC controller projects like Smoothieboard. Using USB or Ethernet to connect to desktop running UI, outputing pulse-dir signals for stepper motors. Well known from being used in 3D printers, usually equipped with stepper motor drivers rated for small NEMA 17 sized motors, could work just as well for CNC router (when connected to external stepper drivers). Original 8bit GRBL was limited to 3 axis, its ports and competing project can support up to 6 axis. Pulse-dir signal generation should be faster and more stable than on desktop LPT, rest of limitations is similar.

Mach

Mach is not open source, but is affordable PC based controller with large entry level user base

• Mach 3 / Mach 4 controller using LPT port, limitations to that are described above.
• Mach 3 / Mach 4 with hardware controller: CSMIO, SmoothStepper. This adds hadrware pulse-dir signal generation for more reliability and enough I/O for most CNC applications.
• Mach 4 with EtherCAT driver: several vendors are offering various solutions.

CAN bus

• Application specific protocol over CAN bus. CAN transcievers are cheap, MCUs like STM32F405 used in ODrive got CAN controllers builtin, protocol uses noise resistant transmission over differential pairs. At top speed it is fast enough for few axis at hundreds of Hz; bandwidth does not leave much room for more axis, faster control loops, or additional I/O. Cheap way but non standardized at all: seems like quadruped robot actuators have their data formats, quadcopters their own, and so on. Drawbacks: Linux supports CAN, but AFAIK are there no realtime CAN adapters for Linux available that are not in $$$s range. Cheaper options are USB to CAN adapters like CANtacts, CANable, but USB is not good for realtime required for motion control. Some projects are solving this by running realtime part on This adds another non standard layer

• CAN bus with CANopen devices. CANopen is standarization of data format for various devices commuincating over CAN bus. When it comes to motion control, device profile for servo drive over CAN bus is called CiA (CAN in Automation) 402; industrial servodrives implementing this profile are available from number of vendors. This approach would still have some of the drawbacks of using custom CAN protocols (no affordable realtime CAN adapter for PC controller, limited speed and bandwidth in comparison to Ethernet based protocols). Apparently this is not popular solution in open source, no wonder.

Summary

I am sure I ommited some motion control solutions from this market segment. Let me know if I need to correct something.

How it could be done

We need simple to use, low cost and powerful solution that is compatible with industry standards, that is not totally owned by That One Company Behind It. And we need to make it completely open source, so we can do with it what we want. From all the options above, solution that is nearest to this all is EtherCAT. It gives us fast controller on the cheap, plenty of I/O and actuators to choose from numerous vendors, is properly supported with LinuxCNC, has multiple open source master libraries (SOEM, EtherLab) and more.

What is there to be done

Licensing

EtherCAT Technology Group (ETG) calls it open network, but it is not open as in GPL or MIT license. It means anyone can sign up to be member of ETG and get access to documentation, code samples and code generation tools, for free. It comes however with obligation not disclose any of these materials to anyone who is not member of ETG. EtherCAT trademark licensing implies also that no device can be sold with EtherCAT markings if vendor offering it has no valid Conformance Testing Tool license. Official code stack from Beckhoff is called Slave Stack Code. Licensing on that code prohibits it from being used in open source projects. Luckily there is alternative, GPL licensed stack: SOES from Open EtherCAT Society. This means following project is going to be under GPL too.

TLDR one should be good with using EtherCAT in OSS project if he use SOES, and does not sell anything marked with EtherCAT logo or name

Select motion control protocol

EtherCAT itself is only data link layer. One could roll out his own protocol on top of it, but what we want is to adapt standard protocols for interoperability with devices available on the market. Most popular protocol for EtherCAT is CoE: CANopen over EtherCAT, that mirrors CANopen way of working with Object Dictionary and Protocol Data Objects, but uses EtherCAT network instead of CAN bus. For motion control over EtherCAT, it means CoE CiA402. There is alternative protocol, SERCOS over EtherCAT, which seems to be way less popular and (for new, open source projects) has no real edge over CoE CiA402 that I know of.

This project will focus on CiA402, and will start by implementing its csp mode (cyclic synchronous position), as most convinient to use with CNC controllers like LinuxCNC.

Get hardware

Select ESC (Ethercat Slave Controller) chip

EtherCAT does not require special hardware on controller (master) side, generic Ethernet adapter is all that is needed. On slave side, hardware support is neecessary in form of dedicated ESC chip. Well, it can be also done with FPGA and IP cores are available for purchase but I am going to leave this aside for now.

• Original ESC is ET1100 from Beckhoff. It exposes 32 configurable GPIO for simple use cases like distributed digital I/O terminals. For more complex devices, parallel (FSMC, faster one) and SPI (in slave mode, noticeably slower) interfaces for slave device microcontroller (PDI) are available. It is offered in BGA 128 pin package. Along is offered its smaller brother ET1200, packed in QFN48, exposing SPI and half of GPIO. Both chips are at least 20$ per piece, and need external PHYs to work with Ethernet. For small I/O terminals common cost-saving setup is one terminal with Ethernet PHYs, RJ 45 connectors and following smaller terminals connected over local EBUS, but servodrives usually are connected with Ethernet cable and so PHYs are needed.
• More affordable option is LAN9252 from Microchip. Offered in 64 pin QFN and TQFP, it has 16 bit GPIO, or parallel interface (8 or 16 bit), or serial PDI: SPI or SQI, with much higher speed (at the cost of more complex register access). It has Ethernet PHY built in for cost saving and easier board design, and is sold for half the price of ET1100: 10-12$ (or was, before global chip shortage started)
• Then there are XMC4300 and XMC4800 from XMC: Cortex M4 microcontrollers with ESC builtin on AHB internal bus, PDI faster than FSMC. Fast option for higher end new design, not fit for this project (which for now aims to connect existing motor controllers, not create new one)
• Recently, AX58100 from ASIX arrived on the marked. It is licensed ET1100 derivative with improvements. It supports additional IO options: SPI master, Step-Dir controller, 3 phase PWM generator, encoder interface. Its SPI PDI supports higher clock speeds, IO lines are usually 5V tolerant, and chip includes builtin Ethernet PHYs. This chip is not available through western retailers.
• Finally, ASIX revealed AX58200: Cortex M4 based probably on Nuvoton M481W, with builtin ESC (and Ethernet PHYs). Chip is not offered by western retailers. On paper it looks like best choice for greenfield designs, but again this project aims not to be greenfield design.

We will start with cheap, simple to use ESC from known well brand that is available from typical vendors. That is Microchip LAN9252, and we will see how it fares

Adapter board

First thing to consider is which ESC interface is going to be used. CiA 402 will not work with just GPIO, it requires some PDI. We are limited by exposed extension ports on existing OSS-OSHW motion control projects. STMBL exposes SPI1 of STM32F405. ODrive has SPI2 from same MCU. Parallel PDI, called HBI (high bandwidth interface) in LAN9252 docs and FSMC in STM32 docs, is faster, but would eat too many already used pins. We have to make it with SPI.

There are a few LAN 9252 dev boards with SPI exposed. There is range of official evaluation boards from Microchip. Then there is EasyCAT: third party Arduino shield with LAN9252, made by some Italian company that offers it with simple to use code generation tool (which unfortunately is not realy CoE compatible). Same company offers also EasyCAT Pro: small, bare minimum LAN9252 board with SPI breakout, even smaller than EVB-LAN9252-SPI. Its form factor is easier to embed into projects than Arduino shield. At 50 EUR it is pretty affordable, and would be good place to start.

Entire point of this project is to make high performance, end to end open source motion control. It will start from custom LAN9252-SPI board design

Software

Select software stack

Only available open source solution is SOES, released under GPL ver. 2

Execute TODO list

Stuff I already know will be needed:

• Make SPI adapter reach OP with blinky application
• CiA 402 device profile implementation
• uint test CiA402 state machine
• CiA 402 dummy project: loopback device (to test setups and serve as template)
• PR for OSS servo drive projects, adding EtherCAT support
• documentation on setup with LinuxCNC

Disclaimer

The EtherCAT Technology, the trade name and logo “EtherCAT” are the intellectual property of, and protected by Beckhoff Automation GmbH.