How good is Ethercat motion control?

Now that I'm using my ethercat machine daily, I'm seeing some odd issues. Sometimes on startup it will trigger error b2 on the drives rapidly. this is apparently a timing conflict with modbus. Happens every dozen start ups.

Today i had a new one. I homed that machine, and then it began triggering joint errors and limits exceeded despite being nowhere near limits. i had to reboot the computer, and then it was fine.

If the machine starts "fine", it stays fine, but there is some flakeyness with the start up sequence.

Another thing I notice is when I tune my servos perfectly in the omron (usb) software, when they start under linux they are resonating, vibrating like 1 micron in travel. I don't know if that's a linuxcnc thing, and ethercat thing, or just a stupid omron thing.

Other than these quirks though, its great and I would not switch back for anything haha.

This is just an interpretation from reading similar issues here(forum), not empirical experience.

But the pattern you describe (random errors on startup, weird state after homing, reboot fixing it, and then everything staying stable) really looks like something in the startup / state synchronization / handshake is sometimes not lining up cleanly.

It doesn’t sound like a continuous motion control problem, more like: sometimes the system and the drives don’t start in exactly the same state (mode, position reference, command bits, etc.), and once that initial state is “clean”, everything behaves fine.

Things like edge-triggered vs level-triggered command bits, timing of enable/mode changes, or initial position/mode sync could easily lead to this kind of “works most of the time, but not always at startup” behavior.

So my guess would be to look closely at the startup sequence and state/mode/position synchronization, rather than at EtherCAT performance or servo tuning itself.

ihavenofish wrote:

--snip--
I don't know if that's a linuxcnc thing, and ethercat thing, or just a stupid omron thing.

Other than these quirks though, its great and I would not switch back for anything haha.

What model number Omron drive is this? Also, are you using some form of CIA402 component with it? Which one?

I have had a keen interest in Omron servos for a while, but never actually worked with one of those. One of my upcoming projects could use one, now knowing there is "some mysterious bug" of sorts really catches my interest. If I manage to carve out some time for this, I would like to acquire the hardware and investigate the problem.

@NWE

Industrial drives like Omron should not show behavior that depends on history or on how many times you repeat a homing cycle. They don’t “degrade” or become inconsistent just because you run the same sequence again and again. If behavior changes depending on history or number of cycles, that’s almost always a bug in the integration logic (state not reset, counters not reinitialized, missing edge detection, incomplete state machine), not in the drive or in EtherCAT(fieldbus) itself

how many CiA402 implementations are we talking about?
which one are you actually using in your setups? For example, are you using the stock cia402.comp, a modified version, or something else on top of LCEC? And with which drives / modes?

I know this thread is about EtherCAT motion control in general, so to avoid derailing it, maybe it makes sense to open a separate thread focused on this specific Omron / CiA402 / startup behavior case, where we can look at the actual component, configuration and state machine logic in detail

NWE wrote:

ihavenofish wrote:

--snip--
I don't know if that's a linuxcnc thing, and ethercat thing, or just a stupid omron thing.

Other than these quirks though, its great and I would not switch back for anything haha.
What model number Omron drive is this? Also, are you using some form of CIA402 component with it? Which one?

I have had a keen interest in Omron servos for a while, but never actually worked with one of those. One of my upcoming projects could use one, now knowing there is "some mysterious bug" of sorts really catches my interest. If I manage to carve out some time for this, I would like to acquire the hardware and investigate the problem.
 

I don't think any of my issues are anything to do with the omron drives. I know 100% the first one is explicitly a conflict between ethercat and modbus naming and start up synchronisation. it is basically reinitialising the drive over and over and over The question is.. WHY?

The new one about joint errors/limits just showed up at random and went away. I think it was related to some stored values that got cleared on reboot, but not simply on linuxcnc restart. Like is was storing the wrong home or last encoder position etc. (i had shut down linuxcnc and rebooted the drives, then restarted linuxcnc). Probably an edge case that likely will never show up again.

The ffirst one is more important, cause every 10 times or so it starts it wigs out.
 

Marcos wrote:

@NWE


I know this thread is about EtherCAT motion control in general, so to avoid derailing it, maybe it makes sense to open a separate thread focused on this specific Omron / CiA402 / startup behavior case, where we can look at the actual component, configuration and state machine logic in detail

 

I have multiple threads on these things, with files posted
The point of commenting here was to say that ethercat in linuxcnc can be a little flakey here and there, but still the way forward.

@Marcos DC
I assume my best chance of diagnosing the behavior is to start with identical hardware and configuration.

I do not know enough details about ihavenofish's issues to point at any specific bit at the moment. I suspect some unexpected interaction between the Omron drives and the LinuxCNC CIA402 component but that is just conjecture at this point. I would like to take a closer look at CIA402 component behavior while running real hardware on my workbench.

ihavenofish wrote:

I have multiple threads on these things, with files posted
 

Thanks, I will search...

Marcos wrote:

Hi Rod,

 Once you start talking about pushing the host loop into the few-hundred-microsecond range, things like DC setup, cycle stability, NIC behavior (EEE, IRQ coalescing, etc.) and jitter stop being details and become the main engineering problem. That was the point I wanted to make.

When I said Mesa tends to be more “KISS”, I meant it in an architectural sense, not as a value judgment. EtherCAT is a full industrial fieldbus: multi-vendor, DC, flexible topologies, designed for distributed systems — that’s a big strength. The hm2-eth approach is intentionally simpler and focused on talking to the card, with the time-critical I/O timing living in the FPGA. Different tools, different trade-offs.
 

EEE, IRQ etc are really at the operating system level so they effect networking for both Ethercat and Mesa. But I think Ethercat is less affected.

In the RT community, the need to optimize/tune the kernel is well understood. Here at LinuxCNC we have only just been forced to come to grips with this since we adopted Bookworm. We skipped deployments on Bullseye but let me assure you the issues were there then.  I agree that users should never need to understand how to apply these settings, it should be done for them. Yesterday, I delivered a custom Linuxcnc installer that sets the system up for optimal RT performance in a networked environment and installs and configures ethercat. The customer just needs to install his linuxcnc config. Ultimately, I will build a more generic installer but I have to first recover from the brain-hurt this project inflicted on me!

Hi Rod,

Sorry for the late reply — I was traveling with my family and only catching up now.

Thanks for the work you’ve been doing on the installer and the RT tuning side. That’s really valuable and definitely helps lower the barrier for people getting started with EtherCAT on LinuxCNC.