EtherCAT slave not found on bus scan: fix the ESI and revision

The slave has its 24 V supply, the LEDs are lit, and the bus scan still returns nothing in its slot. Powered but absent usually means the master software refused to build the device — not that the wiring is dead. The fix order below separates devices that are not EtherCAT slaves at all, proves the frame completes the line, then clears the two master-side refusals: a missing ESI device description and a revision-number mismatch. It is written for whoever keeps vision cells and production machines running when the camera PC also runs the bus master: maintenance technicians, integrators and controls engineers.

Powered but absent means two different faults

A scan that skips a slave you can see and touch is one of two faults. The first is physical: the frame never comes back, because a cable sits in the wrong port or the line is broken after the previous device. The second lives on the master PC: the frame completes, the master reads the slave's identity, and then refuses to create the device because its description library holds nothing that matches.

LEDs cannot tell you which fault you have. The master's diagnostics can: lost-frame counters, the working counter and the identity line the scan prints for every device it finds. Read those three before you touch a cable or a file.

Not every terminal on the rail is a slave

Subtract the devices that will never appear. A 24 V power feed terminal and its ground terminal carry supply rails only; they contain no EtherCAT slave controller (ESC), so no master on any bus will list them. They are not faulty and they need no configuration. Some feed terminals even carry an indicator that looks like a status LED, which is how powered-but-invisible terminals end up looking like faults.

The machine documentation lists which slots hold bus devices. Against that list, count the devices that genuinely contain an ESC and compare the number with what the master shows. If the missing device is a feed terminal, the bus is telling the truth and the fault is somewhere else — or nowhere.

Walk the frame: in port, out port, working counter

Every slave carries two bus ports, marked in and out on the housing, and multi-port masters carry the same marks. The master's cable enters the in port of the first device, and each device's out port feeds the next device's in port. A cable pushed into an out port produces a line mismatch: the frame never travels the path the master expects, and the scan skips the device.

The proof is the working counter. Every slave that processes a frame raises it, the master prints the count each cycle, and a count below the expected value means the frame died in the chain — at or after the first slave that failed to serve it. A full count with the device still missing points the other way: the bus is fine and the description is not.

The ESI file the master is missing

An EtherCAT Slave Information file — the .esi file — is the slave's device description in XML: identity fields, object dictionary, process image. A scan reads the identity off the device, then looks in the master's library for a description whose vendor ID, product code and revision match. Nothing matches, nothing gets created, so the bus can be perfect and the device stay invisible. The scan log usually says so outright: a line reporting an unknown device with a vendor ID and product code is the bus seeing the slave and the library coming up empty.

Install the file from the device maker's download area or through the distributor — never a stray copy lifted from another project, which is how wrong versions get installed in the first place. Camera integration fights the same fault shape with GenTL CTI files that must validate before enumeration, and the camera that appears in Device Manager but not in your SDK is the same story one layer up: right file, loaded where the tool looks.

Revision mismatch: the quiet refusal

Masters identify a slave by name and revision, not by name alone. Vendors raise the revision number when hardware or firmware changes, so a machine builder's firmware update silently invalidates the description in your project: the scan reports revision 2, your library holds revision 1, and the master refuses to create the device. The identity matches field by field except the revision — exactly what the scan log shows.

Three fixes, in order. First, install the ESI revision that matches the device. Second, where the vendor states the two revisions are compatible, set the master's revision comparison to tolerant — the option that decides how strictly revision numbers must match usually sits with the bus scan or device-creation settings. Third, never on safety slaves (see the warning below).

A revision that no longer matches keeps doing damage after the scan: axis mapping on a drive depends on the ESI revision matching, so silencing the comparison across a real version change can leave an axis running on the wrong description.

Worked example: three slaves in a line, two counted

Take a vision cell whose EtherCAT line runs from the controller PC through three slaves — a drive, an I/O block and the sensor node that will not appear.

Inputs

• Line: 3 slaves in series from the master NIC (the station's electrical drawing).
• Expected device count: 3, feed and ground terminals excluded (same drawing).
• Master diagnostics each cycle: frames lost, working counter per process frame (the master's diagnostic page).
• Project library: one .esi file per device family, at the revisions commissioned (the project folder).
• Scan log after the counters look right: one identity line per found device — vendor ID, product code, revision (read off the slaves by the master).

Rule

A process frame that every slave serves returns with a working counter equal to the expected value; a frame that stops at a port returns short, with the shortfall at or after the device that failed. Once frames run complete, the master creates a device only when the identity it read matches a library description on all three fields: vendor ID, product code, revision.

Arithmetic

Expected working counter for the line: 3 slaves × 1 increment per slave for this frame type = 3. The master reports 2, so 3 − 2 = 1 short: the frame died at slave 2's out port, and no file can matter yet. Replace the jumper from slave 2's out port to slave 3's in port and rescan: the counter reads 3 = 3, frames complete. The scan now shows the sensor node as an unknown device with identity — example values: vendor ID 0x00A1, product code 0x0211, revision 2. The project's file for that family carries vendor ID 0x00A1, product code 0x0211, revision 1. Field by field: vendor ID matches, product code matches, revision 2 ≠ 1.

Decision

Counter short: fix the physical chain first. Counter full and the list short: the master is refusing the device, so fix the description. Revision the only differing field: install the revision-2 file and rescan; use the tolerant comparison only if the vendor states revisions 1 and 2 are compatible. Vendor ID or product code differing: wrong file family or wrong device — identify the device before changing anything else.

Fix order, fastest first

1. List the devices that genuinely contain an ESC; feed and ground terminals never count.
2. Read the master's diagnostics. A working counter short of the slave count is a wiring fault — wrong port or bad jumper — before any file work.
3. Check both cables at the missing device: master side into the in port, chain out of the out port.
4. Rescan and read the identity line for the device: vendor ID, product code, revision.
5. Install the matching ESI from the maker's download area, then close and reopen the scan view so the tool rebuilds its device library.
6. Rescan. Device present and reaching its operating state: commission as normal. Still absent: compare the identity against the file you installed — a mismatch means the wrong file version.

Keep the library honest afterwards

Keep one folder of .esi files beside the project, in version control, with the firmware version that commissioned each device. When a drive or sensor node takes a firmware update, expect the revision to move: rescan, read the new revision from the log, pull the matching file before the line goes back into production. Record the revision on the cabinet drawing or the machine file, so the next person starts from the same fact instead of the same hunt. That habit is the whole prevention.

The master PC: keep the bus port to itself

Sizing or rebuilding the PC that runs the master stack? The spec that matters here is LAN port count: one port dedicated to the bus line, one per camera network, one for the plant LAN. Sharing a NIC between the bus and camera traffic exposes both to each other's spikes. The MV-VC3301H-128G66 lists 5+ LAN ports, 3-4 USB 3 ports, 4 built-in channels and 8 GB of memory, and includes a VM6200Pro license. The MV-VC5525-256G70-NN lists 32 GB of memory, PoE camera ports, 8 built-in channels and 5+ LAN ports.

The vision controllers category filters by LAN port count and memory, so the bus port and each camera network get their own interface. The powered-but-not-enumerated twin on the camera side is the USB camera that fails enumeration after a reboot, and the systems topic page collects the rest of the integration fixes. If a scan still refuses a device after the file and the revision are right, send the scan log's identity line — vendor ID, product code, revision — through the contact page.