Four layers have to agree, and only one of them is the fieldbus

An EtherCAT joint module is a servo drive, a reducer, an encoder and a brake in one housing. When integration goes wrong, the failure is rarely "EtherCAT does not work" — it is one of four layers disagreeing, and knowing which layer you are in saves most of the debugging time:

1. Electrical — cabling, shielding, connector strain in a moving harness, and the ground path through a rotating joint.

2. Identity — the three numbers that tell the master which device description applies. This is where ESI files live.

3. Behaviour — cycle time, sync mode, and whether every axis samples at the same instant.

4. Meaning — units, sign conventions, and the layout of the process data. The bus can be perfectly healthy while the numbers it carries mean something different than you assumed.

Most of this article is about layers two, three and four, because those are the ones a buyer can specify in advance. Layer one is a mechanical and cable-dressing discipline, and it mostly punishes you later.

The ESI file is the contract between drive and master

The ESI — EtherCAT Slave Information — file is an XML document that describes the drive to the master: its identity, the relevant part of its object dictionary, its default process-data layout, and whether it supports distributed clocks. The master reads it before it can bring the drive into operational state. There is no useful sense in which an EtherCAT joint module "just works" without the right ESI — the file is the difference between a drive and a well-machined paperweight.

Inside it, the part that decides everything is the identity: Vendor ID, Product Code and Revision Number, held in object 0x1018 on the drive and mirrored in the file. Every EtherCAT vendor registers a Vendor ID with the EtherCAT Technology Group — that registration is what prevents two manufacturers' devices from being confused for one another. Product Code identifies the model; Revision Number identifies the firmware line.

Revision is the number that catches people

Vendor ID and Product Code tend to be stable. Revision Number is not: it moves when the firmware does, and the ESI that describes the behaviour moves with it. So the sequence that ruins a commissioning week looks like this — you integrate in the spring, the drive arrives in the autumn with a newer firmware revision, and your master refuses the device or, worse, accepts it and maps process data at different offsets.

Two practical habits make this cheap. First, read the identity off the device rather than trusting the paperwork: scan the network, read 0x1018, and compare all three values against the file you loaded. Second — and this matters more than it sounds — verify that the Vendor ID is a real registered one. Vendor IDs are published in the EtherCAT Technology Group's vendor list; if the number on a datasheet belongs to a different company, or to nobody, the ESI has been copied from somewhere rather than written for that device. That is a reason to stop and ask questions, not a detail.

Sync modes, and why DC-Sync is the common denominator

EtherCAT drives support a ladder of synchronisation modes, and the difference only shows up when several axes move together.

In DC-Sync, the master and every drive agree on a common clock; each drive samples its position and current and applies its new setpoint on the same tick, independent of when its particular frame arrived. In FreeRun and SM-Sync, each axis does its work on its own schedule, so the axes are coherent in the trajectory generator and slightly incoherent on the hardware.

On a single joint, that difference is invisible. On a six-axis arm doing coordinated motion it shows up as small current spikes, uneven torque sharing across a pair of shoulder joints, and a trajectory that is measurably softer than the model — the kind of thing that is easy to blame on the gearbox and hard to prove.

Where mixed-brand builds actually go wrong

Mixing EtherCAT joint modules from more than one manufacturer is normal, and usually deliberate: no single line covers every frame size, torque band and price point a build needs. It works. What it costs is integration airtime, and the cost lands in four specific places.

The honest version: mixed builds are not a compatibility problem, they are a normalisation problem. Teams that struggle with them usually do so because they left normalisation until after assembly, when the arm is standing up and every change is expensive.

The object dictionary you will actually touch

EtherCAT joint drives implement CoE — CANopen over EtherCAT — with the CiA402 drive profile, so the object indices you work with are standardised even across brands. This is the short list worth knowing before you open a vendor manual.

Two of these deserve a warning. The brake is often not in the standard object dictionary. Many compact drives expose brake control through a vendor-specific object or a manufacturer-specific bit, and the polarity is not universal — so ask which object releases the brake, which engages it, and what happens when power is removed. Getting that wrong is how an arm drops on the bench.

And torque scaling is not self-describing. The torque objects carry integers in whatever unit and resolution the drive uses; the sign convention tells you whether positive torque accelerates the joint in the direction you expect. Verify with a known load before you trust a single number that comes off the bus.

The modes of operation you need

For an arm, the useful subset is small: Cyclic Synchronous Position for coordinated motion, where the master sends a new position every cycle and the drive reports back inside the same cycle; and Cyclic Synchronous Torque for force work, impedance control, or anything where the joint has to yield. Profile modes are useful on the bench and for homing, but a coordinated arm runs on the cyclic modes — and both should be verified at your chosen cycle time, not at whatever the manual calls "typical".

A bring-up order that finds faults early

This sequence is deliberately ordered so that each step is cheap to fail: bring each EtherCAT joint module up alone, no load, no coordination, until every assumption has been tested exactly once. The principle: one drive, no load, no coordination, until every assumption has been tested exactly once.

1. Archive the ESI before you touch the hardware. One folder per model and revision, in the same revision control as the CAD. Note the three identity numbers you expect.

2. Scan with a single drive connected and read 0x1018. Compare all three values with the file you loaded. Do not proceed on a revision mismatch — solve it now, while nothing is assembled.

3. Enable with no load and no trajectory. Walk the CiA402 state machine deliberately, watch the statusword, and confirm the drive reaches operation enabled and stays there.

4. Run one slow move and verify direction and scaling. A small commanded position in the positive direction should produce motion in the direction your model assumes. If it does not, fix the sign convention here rather than in a controller later.

5. Verify the torque reading against a known load, and the brake against gravity. Confirm the sign, the scale, and that the brake engages when you expect it to — including on a power cut.

6. Only then go to three axes, with DC-Sync on, and log for thirty minutes. Watch the working counter and the cycle jitter. A configuration that survives thirty minutes of continuous coordinated motion is a configuration you can put on an arm.

Cabling, and the errors that look like software

Once the logic is right, the residual faults on a moving robot are usually physical. Stranded cable in a rotating harness fatigues; a connector at the joint gets loaded in a way it was not designed for; the shield and ground path changes as the arm rotates. The symptom is often not an alarm but a working counter that quietly drops — frames that arrive but do not reach every device in the chain exactly once.

So treat the working counter as a first-class health signal, log it alongside torque and position, and try to move the arm through its full range of motion while watching it. If it degrades with motion and recovers when stationary, you are chasing a cable, not a configuration — and the fastest test is a continuity and shield check on the harness, not a firmware update.

What to ask before you order

These are the questions worth sending in writing before you commit to an EtherCAT joint module, because the answers decide how much integration time the build will consume. They are also questions a supplier can answer quickly if the information exists — which is useful, because the inability to answer is itself the answer.

1. The ESI file for the exact firmware revision that will ship, plus the policy for firmware updates afterwards.

2. The three identity values — Vendor ID, Product Code, Revision Number — so you can check the vendor registration independently.

3. Whether the build supports DC-Synchronous mode, the minimum cycle time, and the recommended shift time.

4. The default PDO mapping, and whether the torque and status bits you need are in it by default.

5. Which object controls the brake, its polarity, and the behaviour on power loss.

6. Torque sensor or current-based torque: resolution, units, sign convention, and how it is scaled into the object dictionary.

7. The error code list for the drive, so your health logging can translate codes instead of printing hex.

8. Whether the mechanical interface is shared with other bus variants of the same frame — and if so, that the electronic documentation is variant-specific.

Point eight is worth expanding, because it causes more confusion than it should. Mechanical drawings are often shared across bus variants of the same frame: the housing, flange and hollow shaft are identical across the CAN and EtherCAT builds, and only the drive electronics, connector and firmware differ. That is normal and efficient — but it means a drawing carrying CAN markings may still be the correct drawing for the EtherCAT unit you ordered. Confirm it in writing for your item code, and keep the electronic documentation — ESI, object list, firmware note — strictly per variant.

If you are still choosing frame sizes rather than integrating drives, settle the arithmetic first — gravity term, inertia term, duty cycle, safety factor — and let those numbers decide the frame before you worry about the bus. This article starts where that work ends: the drives are chosen, the order is placed, and now they have to run together.

Questions we get asked

What is an ESI file and do I need one for an EtherCAT joint module?

The ESI (EtherCAT Slave Information) file is the XML description your master reads to recognise and configure the drive: its identity, object dictionary excerpt, default PDO layout, and whether it supports distributed clocks. Without it the master has no device description to work from, so it cannot bring the drive into operational state. Ask for the ESI for the exact firmware revision you are buying.

Why does my EtherCAT master not recognise a joint drive?

Almost always the identity triple: Vendor ID, Product Code and Revision Number. The revision is the one that catches people, because a firmware update can ship a new revision that the master will not accept under an older ESI. Read the three values from object 0x1018 on the drive, compare them with the ESI you loaded, and treat any revision difference as an integration task rather than a nuisance.

What is DC-Sync and do I need it on a robot arm?

Distributed clocks synchronise the drives' internal time bases so every axis samples position and current at the same instant rather than whenever its frame happens to arrive. On a single joint you will not notice. On a six-axis arm moving under coordinated control you will: unsynchronised axes produce torque ripple, uneven current draw and a slightly mushy trajectory. Assume DC-Sync for any multi-axis build.

Can I mix EtherCAT joint modules from different manufacturers?

Yes, and mixed builds are normal — each drive carries its own ESI and its own Vendor ID, and one master can run all of them. What has to be common is the integration layer: sync mode and cycle time, unit and sign conventions, and an error-mapping scheme. The cost of mixing is integration time, not incompatibility.

Which modes of operation do I need for a robot arm joint?

Cyclic Synchronous Position for coordinated motion, and Cyclic Synchronous Torque for force work or compliant control. Point-to-point and profile velocity modes are useful for bench testing and homing, but a coordinated arm runs on the cyclic modes, where the master sends a new setpoint every cycle and the drive reports back within the same cycle.

What causes intermittent EtherCAT dropouts on a robot?

Most intermittent faults on a moving robot are physical before they are logical: shielded cable damaged in a moving harness, connectors stressed at the joint, or a ground and shield arrangement that changes as the arm rotates. Watch the working counter — if it drops without an alarm, suspect the cable and the shield path before you touch the firmware.