Vision sensor results to an HMI over EtherNet/IP: implicit or explicit

The inspection runs on the vision sensor, the pass/fail bit has to appear on the HMI next to the machine status, and there is no PLC in the path — or you would rather not spend PLC tags on it. EtherNet/IP closes that link two ways, and the choice decides everything downstream: a cyclic implicit I/O connection that pushes the sensor's result register to the panel at the interval you set, or an explicit CIP read the panel fires when it wants a value. This guide shows where the result lives in the sensor's object model, why the EDS file does not create your tags, both configuration paths step by step, the timing and bandwidth arithmetic, and the faults that kill most of these links.

Can an HMI read vision sensor results over EtherNet/IP with no PLC in the path?

Yes: over EtherNet/IP the vision sensor is a server, so the HMI connects to it directly, either as a cyclic implicit I/O connection into its input assembly or as an explicit CIP client reading result attributes on TCP port 44818, and no PLC is needed in between.

The sensor listens and answers; the panel acts as the client — a scanner for implicit I/O, an explicit-message originator for reads. Both connections share one cable and one switch on a 100 Mbit/s industrial Ethernet line, and the ports are fixed by the standard: UDP 2222 carries implicit I/O packets, TCP 44818 carries explicit messages. Most panel drivers fill both in once you pick an EtherNet/IP (ODVA) device type.

At the panel end you need configuration software with that driver, which is the HMI and industrial panel PCs class of hardware rather than a plain office display.

One boundary matters before you build anything: this link carries results, not images. If the operator also needs the live camera picture on the panel, that is a separate channel with its own refresh limits — see Smart camera image in a PLC HMI: what actually displays live.

Where does a "tool OK" result live inside the sensor?

The result sits in a register the sensor publishes through CIP: for implicit messaging a bit per tool inside an Assembly object (class 0x04) that the panel receives with every packet, and for explicit messaging the same results as attributes addressed by class, instance and attribute ID.

EtherNet/IP devices expose their data as CIP objects. The Identity object (class 0x01) answers who the device is, the Assembly object (class 0x04) carries the blocks of I/O data, and vendor objects hold everything else. The one that matters here is the input assembly: the block the sensor rewrites after every inspection and the panel receives at every RPI.

A typical layout, close enough to most sensors' register tables to plan against:

Under that table sit the three numbers you configure against: the assembly's instance, its size in bytes, and the bit each verdict drives. The sensor's communication manual names them, and the same values hide inside the EDS file as plain text. Before you promise the link on a project, open the manual's EtherNet/IP chapter and check those three numbers are there; a sensor that speaks only its vendor protocol or GigE Vision has no input assembly to read, and the alternatives at the end of this guide take over.

The sensor side of the link is any vision sensor or smart camera with an industrial Ethernet interface running your inspection tools; typical picks:

The MV-SC3050XC-16M-ATN-H, for instance, is a 5 MP color vision sensor with a Fast Ethernet interface and a global shutter on a 1/1.45" sensor, and the SC5000X model beside it runs the same idea over GigE at 6 MP. Reading hardware fits the identical pattern, with decode and no-read bits in place of tool verdicts; this compact model carries a 12 mm lens and a Fast Ethernet interface:

Where the reading side of the line matters as much as the inspecting side, the fixed code readers category filters by interface and resolution.

Why doesn't the EDS file give you ready-made HMI tags?

An EDS file only describes a device — its identity, its CIP classes and instances, its assemblies and parameters — in a standard text format; most panel tools use it as a reference to show what the device offers, not as an automatic source of tag addresses.

An EDS (Electronic Data Sheet) is written by the sensor vendor and lists identity, the connection combinations the device supports, assembly instances and sizes, and parameters with their addresses. Controller software usually imports it into a device profile; panel software often skips it entirely and asks you for an IP address plus hand-typed tags. Neither behavior is a fault — the file was never a tag database — but it changes where you get the numbers from.

So read the file instead of importing it.

Between the EDS text and the manual's register table you can build the complete tag list offline, before the panel is even powered. If the two disagree, take the numbers from the manual that matches the sensor's firmware version.

Implicit or explicit messaging: which one fits your result?

Use implicit messaging when the verdict must be current every scan — an RPI of 50-100 ms pushes the result bits to the panel continuously — and use explicit messaging when you poll on demand or the panel's driver supports explicit reads only.

Decide from the cycle, not from preference. A line running one part per second or faster, with a verdict the operator must see for every part, is implicit territory: the display is never more than one RPI behind, and the connection costs the same whether verdicts change or not. A panel that needs a result code only when someone opens the results screen, or a driver that turns out to be explicit-only, is explicit territory: nothing moves while idle and commissioning is a single message type. The two also run at once on separate connections — push the verdict bits implicitly, poll the counter explicitly once per second.

Set the RPI from the cycle: at or below one fifth of the inspection time, with 100 ms the usual starting point. The connection times out after a multiple of the RPI passes unserviced, commonly four times, so an RPI faster than the panel can sustain produces a link that connects, drops and reconnects all shift.

How do you set up the implicit I/O path, step by step?

You configure the panel's EtherNet/IP driver as a scanner, open an implicit connection to the sensor's input assembly, set the RPI, and map tags onto that assembly's bits, because the connection then delivers a fresh copy of the result register at every interval.

1. Publish the results on the sensor side: in its software, confirm which verdicts land in the input assembly, and note the assembly instance, its size in bytes and each verdict's bit position from the manual's EtherNet/IP chapter.
2. Give the sensor a static IP on the machine subnet, same range as the panel, and ping it from the panel's network before configuring anything.
3. Add an EtherNet/IP device of the generic ODVA type in the panel's configuration tool and enter the sensor's IP address.
4. Create the connection: input assembly instance and size from step 1, the configuration assembly the manual specifies, and an RPI of 100 ms. Leave the transport as point-to-point unicast unless several consumers need the same data.
5. Map the tags: boolean tags at byte.bit offsets for verdicts, integer tags at word offsets for result codes and counters.
6. Trigger an inspection and watch the tag list. A connected status with motionless bits means wrong offsets or an unpublished result — fix the map, not the cable.

How do you set up the explicit CIP read, step by step?

You create an explicit message request on the panel with the sensor's IP address and TCP port 44818, the service Get_Attribute_Single (0x0E), and the class, instance and attribute of the result; each call returns the bytes you then map to tags.

1. From the manual or the EDS text, note the class, instance and attribute ID of the result attribute, plus its size in bytes.
2. Build the request in the panel: target IP, service 0x0E, the class-instance-attribute path, and a receive buffer of the attribute's size. The port defaults to 44818; leave it unless the manual says otherwise.
3. Schedule the request: every 250 ms from a periodic task, or on the screen event that opens the results view. At 250 ms the worst-case wait is a quarter second and the traffic is four requests per second.
4. Parse the buffer exactly like the implicit map: bit 0 of byte 0 for the first verdict, 16-bit words for codes and counters.
5. Test the error path: a general status instead of data means the path is wrong — a service-not-supported status points at the service byte, an attribute-not-supported status at the attribute ID. Correct the path and re-run.
6. Mind aggregate load when several screens or several sensors poll at once: one panel reading one sensor at 4 requests per second is a few kilobits per second, a dozen panels polling several sensors each needs a poll rate you write down.

How fast does the HMI see a new result, and what does the link cost?

At a 100 ms RPI the panel shows a changed verdict within one interval, so on a line running 60 parts per minute the result is on screen within 100 ms of the 1,000 ms each part occupies, while a 32-byte input assembly costs about 2.6 kbit/s of traffic.

The arithmetic behind those numbers, for a line at 60 parts per minute and a 32-byte input assembly:

The explicit alternative at a 250 ms poll lands within 250 ms plus a few milliseconds of response, at four requests per second — same order of traffic, but only while a screen asks for it. Either way the network load is a rounding error next to a 100 Mbit/s line; the reason to keep the RPI honest is the panel's own ability to service the connection, not bandwidth.

Prove the link before sign-off:

• Force the failure: a known-bad part under the sensor, its viewer flagging the tool, the panel bit flipping within one RPI.
• Watch connection status on both ends across a shift; a link that reconnects points at RPI or timeout settings, not wiring.
• Count results on both sides across ten parts; a mismatch means a wrong offset or a trigger firing between reads.
• Run it across a job change. If the new job publishes a different assembly layout, the map shifts underneath the panel.

Which faults cause most vision-to-HMI EtherNet/IP links to fail?

Most failed links die on four things: the panel talking to the wrong transport, a bit or byte offset one position off, an RPI the sensor or panel cannot sustain, and a result register read mid-update — and each has a two-minute test.

When is EtherNet/IP the wrong road for this job?

Choose OPC UA when you also want result values, strings and history, raw TCP when the sensor offers a plain socket and the panel can run a client script, or Modbus when both ends speak it and the map is small — and keep EtherNet/IP for cyclic, bit-level results.

OPC UA carries typed values and text, not just bits, and survives a route to a higher-level system: Read smart camera results over OPC UA into your control system walks that path. Raw TCP is the lowest common denominator when the sensor publishes a socket: TCP client or listener: match your network barcode reader to your host sorts out the two roles, and Barcode reader to PLC over raw TCP sockets without EtherNet/IP spells the frames out line by line. On older panels with a serial port, Read a barcode reader into a PLC over Modbus RTU covers the short, slow, perfectly serviceable road.

When a PLC turns out to exist after all, put the cyclic connection there and let the panel read the controller instead: Ethernet IP barcode reader to PLC: map the implicit I/O assembly maps the same assembly objects from the PLC side, and Barcode reader PLC communication: plan a reliable link walks the whole design before a wire is cut.

If you are specifying the sensor end now, filter the camera finder by interface and resolution, start the station in the camera configurator, or reach the application team through the contact page.