Read fixed code reader results into a PLC over EtherNet/IP

You have a fixed code reader bolted over the line and a PLC that needs the scanned string, not a picture on someone's screen. EtherNet/IP carries that string in one cyclic connection: the reader exposes a fixed block of bytes, then status, length, and the code itself, and the PLC copies it into a string tag on the reader's data-valid bit. This guide maps the assembly, sizes the byte block, sets the RPI and walks the copy logic step by step. It assumes a reader with an Ethernet port running an EtherNet/IP adapter and a PLC in the scanner role; the last section covers the readers and PLC cards that cannot do that.

What does a code reader actually send over EtherNet/IP?

A fixed block of bytes called the input assembly, in this example 2 status bytes, a 2-byte length word and 64 bytes of ASCII code data, 68 bytes in all, refreshed at the RPI whether or not a new scan happened. The scanner finds that block through the assembly instance the reader's EDS file declares, and the same file declares the output assembly your PLC writes into. The camera-side version of that mapping, from EDS to instance numbers, is covered in Ethernet IP barcode reader to PLC: map the implicit I/O assembly; this page takes the reader side all the way down to the string copy.

Direction naming trips people: input means into the PLC, output means out of it. The output assembly carries your trigger bit, your acknowledge bit and a few command bytes; 4 bytes holds both bits with room to spare. Many readers present one input and one output assembly that bundle the reader object's attributes together, so you configure a single connection rather than one per field.

Which connection do you map: implicit, explicit or a TCP socket?

Map the string over implicit cyclic I/O, keep explicit messaging for configuration and counters, and drop to a TCP socket only when the reader has no adapter or your PLC card cannot run the scanner role. That sentence settles most cells; the table shows the mechanics behind it.

You cannot poll on a timer and guarantee you catch every read event, which is why the string always rides the implicit connection. The implicit-versus-explicit question in an HMI context is worked through in Vision sensor results to an HMI over EtherNet/IP: implicit or explicit. Explicit reads still earn their place at setup time, and the request-response pattern shown for reading a drive fault code over an EtherNet/IP adapter transfers directly to reader parameters.

How do you add the reader to the PLC project?

Register the EDS file, add the reader as an EtherNet/IP adapter module at its address, and enter the assembly sizes the EDS prints, for this example 68 bytes in and 4 bytes out. Six steps, ten minutes when the EDS matches the firmware:

1. Download the reader's EDS file from the manufacturer's support page and register it in your scanner tool.
2. Add the module as an EtherNet/IP adapter; enter the reader's IP address and the input, output and config instance numbers the EDS lists.
3. Set the RPI to 20 ms and leave the connection timeout at the tool's default multiple of it.
4. Point the input data at a byte-array tag, Reader_In[68], and the output at Reader_Out[4].
5. Download and go online; the module should show a running connection with the input bytes idle.
6. Present a known test code, TEST0001 works, and watch bytes 4 through 11 change in the tag monitor.

If the tool rejects the EDS, Vision camera EDS file and EtherNet/IP assembly mapping shows how to pull the instance numbers and sizes out of the file by hand.

How do the input bytes map to PLC tags?

Byte 0 and byte 1 carry a status word with the data-valid bit, bytes 2-3 carry the code length as an unsigned integer, and bytes 4 through 67 carry the ASCII characters, left-justified and zero-padded. Your reader's integration sheet fixes the exact bit and word positions; substitute its offsets and nothing else in the method changes.

Size the block from your longest code, not your average one. A GS1 element string carrying GTIN plus serial stays under 50 characters, and string tag types that hold 82 characters swallow a 64-byte block whole: 82 - 64 = 18 characters of headroom, no splitting, no second assembly.

How do you copy the bytes into a string once per scan?

On the rising edge of the data-valid bit: latch the event, copy the 64 data bytes into the string tag's character area, move the length word into the string's length field, then pulse your acknowledge bit in the output assembly. Copying on the bit's level instead of its edge is the classic failure, because the rung rewrites the same string every PLC scan and nothing downstream can tell a new read from an old one.

1. Detect the false-to-true transition of the data-valid bit with a one-shot, so one read event copies exactly once.
2. Copy 64 bytes, Reader_In[4] through Reader_In[67], into the string tag's data area.
3. Move the unsigned integer at Reader_In[2] into the string's length field, capped at 64.
4. Set the acknowledge bit in Reader_Out[0] so the reader clears its buffer and rearms for the next trigger.
5. Drop your latch when the valid bit falls, ready for the next edge.

The handshake around that copy is the subject of Copy barcode data to a string only on a new read handshake and PLC to HMI barcode data handshake: queue every scan without drops. When a short code follows a long one and the tail survives, the length and clear sequence in Storing ASCII barcode strings in PLC memory: bytes, words and clears is the fix.

What RPI do you need at your scan rate?

Set 20 ms and move on: at 20 ms the 68-byte assembly arrives 50 times per second, which carries a 30-reads-per-minute line with a 100x margin. Two arithmetic rules govern the number, and both fit on one hand.

Rule one: the RPI must be short enough that no read is overwritten before the PLC sees it, so keep at least four updates between reads. At 30 reads per minute the gap is 2 s, and 2 s / 20 ms = 100 updates per read. At 20 parts per second the gap is 50 ms, so set 10 ms and get five updates per part.

Rule two is bandwidth, which you will never approach. 68 input bytes plus 4 output bytes, 50 times per second, is 72 x 50 = 3,600 bytes per second, about 29 kbit/s, or 0.03% of a 100 Mbit/s link. Going faster than needed buys nothing, because the copy fires on the edge, not on every update.

What should you check before ordering the reader?

Three things on the product page decide this integration: an Ethernet port with an EtherNet/IP adapter option and a downloadable EDS file, an input assembly at least your longest code plus 4 bytes, and a trigger path you can drive from the PLC. Confirm all three before the purchase order, not after the first failed connection.

Pick the hardware with the interface filters first. In fixed code readers or the code reader finder, filter to Fast Ethernet or GigE and work from there. For the common line-side case the MV-ID3013PM-12M-WBN is the pick: a 1.3 MP compact reader with a 12 mm focal length on Fast Ethernet.

For wider labels or longer throws, the MV-ID5120RM-08M-RBN steps up to 12 MP over GigE with an M12 mount.

The MV-ID813M-05S-WBN-SR pairs 1.3 MP with a 4.9 mm focal length, white light and a static cable on GigE; the LS-CRD-0028 decodes 60 codes/s at 5 MP over Fast Ethernet with an 8 mm lens. Two more readers that carry this integration:

Not every station needs Ethernet. The LS-CRD-0047, a 1.2 MP USB 2.0 reader with a 60-120 mm reading distance, belongs at a manual bench with a PC in front of it; Fixed code reader setup over USB: first connection and readback checks covers that path. And read reliability is a lighting problem as often as a networking one: reader accessories such as the MV-SC3000-C-HP semi-polarizing lens cover exist for the shiny-label cases.

When is implicit EtherNet/IP the wrong answer?

Two cases: the reader has no EtherNet/IP adapter at all, or your PLC's Ethernet card cannot open scanner or socket connections; in both, a TCP ASCII stream from the reader, read as the client, is the fallback that keeps the line running. The assembly mapping disappears and you parse terminated ASCII strings instead of copying fixed bytes.

Check the card before you promise the connection: Your PLC Ethernet card may not support ASCII from a code reader names that trap. Then wire the direction that works, per Barcode reader as TCP server: wire your PLC as the client; the PLC-side string handling is the same as in Vision camera to PLC over Ethernet: ASCII strings, no serial port.

When one device must inspect and read on the same line, a smart camera reports like a sensor. The MV-SC6050C-08M-XBN is a 5 MP color model with an 8 mm focal length, a multi-color light source and GigE:

The smart cameras category holds the inspection-plus-reading combinations, and Trigger a smart camera over TCP with ASCII commands and read results covers the command side.

Your next step is arithmetic, then shopping: size the block from your longest label, set the RPI from your part pitch, and bring the wrinkles, whether two codes per part, a robot in the trigger chain or an HMI queue, to the contact page; free expert support comes with every order. If the read station is new from scratch, the system configurator walks the camera, lens and light side, and the code reading topic page collects the PLC-side articles for the rest of the chain.