Technology 📅 September 25, 2026 ⏱ 13 min read

Connecting a UHF RFID Reader to a PLC: Modbus TCP, PROFINET, EtherNet/IP and OPC UA, With the Register Maps

A fixed UHF RFID reader wired to an industrial control cabinet, with fieldbus and GPIO terminal connections visible

Search for how to connect a UHF RFID reader to a PLC and the page that still answers the question was published in September 2009. It tells you to hire whoever wrote your original PLC software. Seventeen years on, the cross-vendor layer is still spread across manuals: the register maps, the assembly-instance numbers, what the handshake costs in PLC cycles, and the electrical conventions on the trigger input. This guide gathers that layer in one place, from the manufacturers' own documents and the standards behind them, each one named and dated. Every number below is its publisher's, quoted as such, with the arithmetic shown.

What the category left to the vendor manuals

The canonical public answer to this question is an Ask the Experts reply published by RFID Journal on 15 September 2009. Its guidance: “The ladder logic programs running the PLCs may need to be altered to create interfaces with RFID readers, or with corporate databases or other software systems,” and you will “probably need to bring in the party that wrote the original PLC software to help write an interface.” It also names the real constraint on a moving line: on a fast conveyor there can be too little time to write a tag, confirm the serial number is unique, and act on the result before the item has passed.

That was sound advice in 2009, and it still ranks, for two reasons. The fuller treatment it points to, How to Link PLCs and RFID, is a premium-membership article. And the rest of the published material on the subject is vendor-specific by design: one manufacturer's manual for one product, written for someone who has already bought it. The cross-vendor layer — which protocol, which numbers, what it costs in cycles, how the trigger is wired — is what this article assembles, out of those manuals and the standards behind them.

Four decisions determine whether this integration takes a day or a quarter:

Which protocol the reader and the controller will actually share, and whether the reader needs a licence to speak it.
Which class of reader you are buying — because two readers with identical RF performance can differ completely here.
What the handshake costs in PLC cycles, which sets your real tag rate far more than the radio does.
How the trigger is wired, where two major manufacturers use opposite input conventions.

Scope: fixed UHF readers into Siemens, Rockwell, Beckhoff and Mitsubishi controllers. We build both the reader firmware and the software above it, so the integration questions below are the ones our own engineers work through on work-in-progress tracking projects.

EtherNet/IP: why every reader uses a vendor-specific assembly

Buyers reasonably expect a standard CIP device profile for an RFID reader, the way there is one for a drive or an encoder. ODVA's own publication settles where identification devices actually sit, and it is worth reading before you write the tender.

The Common Industrial Protocol (CIP) and the Family of CIP Networks, PUB00123R1, February 2016, section 2.6 lists the profiles defined in Volume 1. The list includes AC Drives (0x02), Motor Overload Device (0x03), Limit Switch (0x04), Inductive Proximity Switch (0x05), Photoelectric Sensor (0x06), General Purpose Discrete I/O (0x07), Communications Adapter (0x0C), Programmable Logic Controller (0x0E), Position Controller (0x10), Human Machine Interface (0x18), Encoder (0x22), Generic Device keyable (0x2B), Managed Ethernet Switch (0x2C) and roughly thirty more.

The profiles listed in Volume 1 cover drives, encoders, switches, sensors, discrete I/O, controllers and HMIs. Identification devices sit outside that set: search the publication for RFID, AutoID or barcode and it returns nothing. If a competing page tells you a CIP “Barcode Scanner Device” profile exists, check it against the publication.

Section 2.6 states the consequence directly: “Any device that does not fall into the scope of one of the specialized Device Profiles must use the Generic Device profile (0x2B) or a vendor-specific profile.” Section 3.3.16 is plainer still: “EtherNet/IP devices may utilize any of the device profiles described in the CIP Networks Library. As of the publication date of this book, no EtherNet/IP-specific device profiles have been defined.”

Section 2.1 fixes the numbering. Vendor-specific object class identifiers run 0x0064–0x00C7 and 0x0300–0x04FF; within the assembly object class, vendor-specific instance identifiers run the same 0x0064–0x00C7 and 0x0300–0x04FF. Check that against what real readers do — 0x0064–0x00C7 is decimal 100–199:

Device	Input assembly	Output assembly	Other instances
Zebra FX9600 (MN-003923-03EN Rev. A)	101 (standard, EPC to 12 bytes, 464 bits); 100 (extended, EPC to 64 bytes)	112 (inventory command, 8 bits)	Explicit messaging class 0x64 for reader capabilities
Turck TBEN-L…-4RFID-8DXP (V04.00, 2022/09)	103 (to 128 bytes); 120 (16 B per channel), 121 (56 B per channel), 122 (80 B per channel)	104 (to 128 bytes); 150 (16 B per channel), 151 (56 B per channel), 152 (80 B per channel)	Configuration assembly 106

Turck's table gives those 16, 56 and 80-byte figures per RFID channel, which is the manual's own convention; the total size of each assembly is larger once the status and control words are added, so size your PLC module from the assembly total and not from the per-channel figure. Every one of those instance numbers — 100, 101, 103, 104, 106, 112, 120, 121, 122, 150, 151, 152 — sits inside the vendor-specific range, which is exactly where ODVA's own text directs a device outside the specialised profiles.

So ask for the four things that actually let you build the module: the EDS or Add-On Profile file, the input and output instance numbers, the sizes in bits, and the data type for the connection. A supplier who owns the firmware can send all four from the source tree the same day. Make that the first thing you ask for.

Modbus TCP: what the specification standardises, what it leaves to the vendor, and the off-by-one

Modbus TCP is the cheapest path and the most commonly mis-specified, because the specification is explicit that the part buyers assume is standardised belongs to the vendor.

MODBUS Application Protocol Specification V1.1b3, dated 26 April 2012 on its page footers, section 4.4, “MODBUS Addressing model”, says: “The pre-mapping between the MODBUS data model and the device application is totally vendor device specific.” In the same passage it notes that in a Modbus PDU each datum is addressed 0 to 65535, while in the Modbus data model each element within a data block is numbered 1 to n. Those two sentences are the source of most commissioning delays in this category.

Section 6.1 spells the addressing rule out for coils: “In the PDU Coils are addressed starting at zero. Therefore coils numbered 1-16 are addressed as 0-15.” The same wording recurs for holding registers in section 6.3 — registers numbered 1–16 are addressed as 0–15. The specification then demonstrates the trap in its own Write Multiple Registers example: a request described as writing “two registers starting at 2” goes on the wire as Starting Address Hi 00, Starting Address Lo 01. Documented register 2, wire address 1.

So when a reader manual lists a block at holding register 40100, three numbers are in play: the documented 4xxxx label, the 1-based register number 100, and the wire address 99 (0x0063). Which one you type depends on your master's convention, and the specification leaves that to the master. Commissioning tactic: before mapping anything, issue one FC03 for a single register at the first block and confirm the error-status field reads back. If it returns the wrong field or an exception 02, you are off by one.

The hard budgets are standardised, and they constrain your design. Function code 03 (Read Holding Registers) reads 1 to 125 registers. Function code 16 (Write Multiple Registers) writes 1 to 123 registers, 0x0001 to 0x007B. Apply that:

Zebra's Multiple Standard Inventory Responses block at 40400 is 224 bytes, 112 words. 112 ≤ 125, so it fits in a single FC03 — one transaction per poll for up to six tags.
Turck exposes four RFID channels at bases 0x0000, 0x004C, 0x0098 and 0x00E4. The last base is register 228, and each channel spans 0x4C = 76 registers, so the mapped area runs to 304 registers. 304 ÷ 125 = 2.43, so reading all four channels takes three FC03 transactions (125 + 125 + 54), not one.

One more line belongs in your tender rather than in your assumptions: byte order and word order. Zebra states the FX9600 uses big-endian for all Modbus operations and supports a single Modbus master on port 502. The protocol guarantees neither, so put both in writing, and plan the architecture around one master from the start.

Two real register maps side by side, and the pattern behind both

Zebra FX9600, from Zebra RFID Modbus TCP User Guide, MN-004136-01EN Rev. A, March 2021. Preconditions first, because they are easy to miss: port 502, big-endian, a single Modbus master, reader firmware 3.8.7 or later, and an EtherNet/IP or PROFINET licence must already be installed on the reader before the Modbus application will run. That last one surprises people — the Modbus application is gated behind a licence named for a different protocol.

Block	Register	Length	Key fields (byte offsets within the block)
Inventory Command	40100	8 bytes / 4 words	Command @0 (1 = Start, 2 = Stop); Handshake @1 (any value 0–127); EnablePreFilter @2; EnablePostFilter @3; AntennaMask DInt @4 (bit 0 = antenna 1; 0 = all antennas)
Standard Inventory Response	40200	44 bytes / 22 words	ErrorStatus @0; EventMask @2; AntennaStatusMask @4; GPIOStatusMask @5; TagCount @6; SeqNo @7; SeenCount @8; TagPC @10; TagCRC @12; ChannelIndex @14; PhaseInfo @16; AccessStatus @18; TagEpc Byte[12] @20; timestamp @32; TagLength @40; AntennaId @41; RSSI @42; TagEvent @43
Long Inventory Response	40300	96 bytes / 48 words	Same layout, TagEpc Byte[64] @20, timestamp @84, RSSI @94
Multiple Standard Responses	40400	224 bytes / 112 words	8-byte status header, then six 36-byte tag slots at 8–43, 44–79, 80–115, 116–151, 152–187 and 188–223
Antenna Config	41500, 41520, 41540 … 41640	12 bytes / 6 words	One block per antenna 1–8 on a 20-register stride. PowerLevel @0 (1000–3000, default 3000); TagPopulation @2 (0–32767, default 100); TariValue @4; RFModeIndex @6 (0–39)
Trigger Config	43400	28 bytes / 14 words	Start and stop trigger definition
GPIO Config	43700	24 bytes / 12 words	Port direction and state
Event Report	47200	8 bytes / 4 words	EventType @0; GpiPortNumber @1; GpiValue @2; AntennaID @3

Note the offsets are byte offsets inside each block, so a field at offset 20 begins at the high byte of the eleventh register — register n covers byte offsets 2n−2 and 2n−1, and the FX9600 is big-endian, so the first byte of each register carries the high order bits. Count registers from the block base before you map anything, or every EPC lands half a word out.

Turck TBEN-L…-4RFID-8DXP uses a different shape for the same job. Per channel: response code at 0x0000 / 0x004C / 0x0098 / 0x00E4 for channels 1–4; loop counter at base+1; status word at base+2, with tag in detection range on bit 0, read/write head detuned on bit 4, head reports error on bit 6, and continuous mode active on bit 9; read and write fragment numbers at base+7; read data from base+0x000C; error code at base+4. Parameters live in a separate area at 0xB000, 0xB012, 0xB024 and 0xB036 — an 18-register stride per channel. Command codes are compact: Idle 0x0000, Inventory 0x0001, Read 0x0002, Write 0x0004, Continuous Mode 0x0010, Read buffer 0x0011, Stop Continuous 0x0012, Tag info 0x0050. Each channel moves up to 128 bytes of user data per read or write cycle; beyond that the data is fragmented, and the fragment size is selectable at 8, 16, 32, 64 or 128 bytes (128 is factory set for Modbus TCP).

Two vendors, two entirely different layouts — and the same six fields underneath. That abstraction is the part you can put in a specification and hold any supplier to:

Field	Purpose	Zebra	Turck
Command word	Tell the reader what to do	Command byte @40100+0	Command code, base register
Handshake / loop counter	Make a repeated command distinguishable from a stale one	Handshake byte @40100+1, 0–127	Loop counter at base+1
Response code	Confirm which command the data answers	ErrorStatus @40200+0	Response code at base+0
Length	Tell the PLC how much of the buffer is valid	TagCount @6, TagLength @40	Length field, fragment number
Data area	Carry EPC and user memory	TagEpc @20	Read data from base+0x000C
Parameter block	Separate configuration from operation	41500 onward	0xB000 onward

PROFINET already has a vendor-neutral RFID standard

PROFINET has a vendor-neutral profile for identification devices, and it is one of the best-kept secrets in this category, because the download sits behind a membership.

PROFIBUS & PROFINET International publishes Identification Systems, Proxy Ident Function Block, version 1.9, order number 3.142, dated 28 May 2010. It is a members-only download, and the function block is defined according to IEC 61131-3, the international standard for PLC programming languages. It covers RFID systems and barcode readers alike, handling configuration, reading and writing data, and status.

What the shipping implementations show is a job-based contract rather than a register poke. Reading it off Siemens' own Ident profile, Add-on instruction for Rockwell systems, C79000-G8976-C410-04, 07/2020: the interface is EXECUTE, which requires a positive edge before the instruction runs; HW_CONNECT, a variable of type IID_HW_CONNECT that addresses the channel or reader, synchronises the instructions, and must be passed to every one of them; and on the way out DONE (the job completed), BUSY (the job is running), PRESENCE (a transponder is present) and a status word. Commands are staged in an array of ten elements of type IID_CMD_STRUCT and selected with CMDSEL.

The same manual shows how the traffic is split, which is the part worth internalising: there is a cyclic status word sent from the communication module or reader to the controller and a cyclic control word sent from the controller to the module, alongside separate MSG_READ and MSG_WRITE message variables for communication between controller and module. Control and state ride in the cyclic words; the payload moves through messaging. That is a different division of labour from the Zebra PROFINET approach in the next section, where tag data lands in cyclic response modules, and it is why the two feel so different to program even though both are PROFINET.

The sequence you will write, in order, is where most first attempts stall:

Configure the module and establish the hardware connection variable.
Execute a parameter instruction for each Ident device — and re-execute it after every restart of the device.
Execute a reset command for each channel of the device.
Only then run application commands: set the command structure, raise EXECUTE on a positive edge, wait while BUSY is true, then read DONE or the error path.
Drop EXECUTE before the next command, because the block triggers on the edge and not on the level.

Steps 2 and 3 are the ones most often skipped by anyone porting from a REST or LLRP integration, where the handshake looks different.

Does it port across PLC brands? The table, and how to verify a claim

Yes — and the reason it does is the inversion nobody advertises. The PLC libraries come from the reader vendor. Siemens publishes the Rockwell add-on instructions, the Beckhoff library and the Mitsubishi project. Look for them in your controller vendor's catalogue and you will look in the wrong place — check the reader vendor's downloads instead.

Controller	Publication	What ships
Rockwell, over EtherNet/IP	Siemens Function Manual C79000-G8976-C410-04, 07/2020	Add-On Instructions including Inventory, Read_TID, Reader_Status and Tag_Status, with data types IID_CMD_STRUCT, IID_READSTAT_, IID_TAG_STATUS_ and IID_IN_I_80. Tested with Studio 5000 Logix Designer V21 to V28 and RSLogix 5000 V20.
Beckhoff TwinCAT 3	Siemens Article ID 109807653, V1.0, 04/2022 (separate PROFINET and EtherNet/IP documents)	The Beckhoff Simatic_Ident library, with FB_IdentProfile for PROFINET; parameters include CM_CHANNEL and AMS_NET_ID.
Mitsubishi GX Works3	Siemens Article ID 109781424, V1.1	A GX Works3 project for MELSEC iQ-R R16CPU over PROFINET, built around the supplied Ident profile blocks.
Siemens S7-1200 / S7-1500	Siemens Ident profile blocks in the TIA Portal catalogue	The native case, and the reference implementation the other three are ported from.

Two cautions before you take a library as proof of a clean integration. A profile can be partially implemented: the Proxy Ident profile defines more commands than any given library exposes, and the Rockwell package above ships a specific named subset. Verify by document, not by brochure. Ask a supplier three questions and put the answers in the purchase order:

Which profile — Proxy Ident Function Block, a vendor-specific CIP profile, or Generic Device 0x2B?
Which commands of that profile are implemented, listed one by one?
Which certificate number, if a certification is claimed, and issued by whom?

A supplier who owns the firmware can answer all three from the source tree. That is a fair test to apply to us as well as to anyone else you shortlist — see how we document what we build.

Throughput: the four-cycle handshake, and a module-count worksheet

Here is where specifications meet physics, and where a reader rated for hundreds of tags per second delivers a fraction of it. The limit sits in the handshake rather than in the radio.

Take the Zebra approach, from the Zebra RFID PROFINET User Guide, MN-004128-01EN Rev. A, March 2021, using GSDML-V2.35-Zebra-FX9600-20201215.xml. The Access Command/Response module can only be configured at slot 1. The Inventory Command module can only be configured at slot 2. Up to ten Standard EPC Response modules go in slots 3 to 12. Zebra's own statement: “Each Response module can fetch 1 EPC tag in each IO cycle,” and “With IO cycle time set to 4 msec, it is possible to fetch a maximum of 62 tags each second.” With ten modules, Zebra says more than 600 tags each second.

Do the division that the manual leaves to you. A 4 ms I/O cycle is 1000 ÷ 4 = 250 cycles per second. If one module yields 62 tags per second, then 250 ÷ 62 = 4.03 cycles per tag. Four cycles, not one. Turck says the same thing in plain words: “At least four PLC cycles are required in conventional command processing.” Turck also sells the way out — a loop-counter mode that “only requires two PLC cycles to execute a command repeatedly,” addressed by setting bit 13 of the command code: Inventory becomes 0x2001, Read 0x2002, Write 0x2004, Read buffer 0x2011, Tag info 0x2050, direct head command 0x2060.

So the design question is how many response modules to buy memory for. The worksheet:

modules = (items per minute × tags per item) ÷ 60 ÷ ((1000 ÷ cycle_ms) ÷ 4)

Assumptions, stated: four cycles per tag from the publishers above; one tag per module per cycle; no retry budget; the ceiling is ten response modules; and cycle_ms is the PROFINET I/O cycle you can actually sustain on that network segment, not the fastest the reader supports.

Worked example 1 — carton line, 4 ms cycle. 30 cartons per minute, 8 tags per carton.
Average load = (30 × 8) ÷ 60 = 4 tags/s. That average is misleading: the tags arrive in bursts of 8 as each carton passes, one carton every 2 s. Size for the burst. Per-module capacity = (1000 ÷ 4) ÷ 4 = 250 ÷ 4 = 62.5 tags/s, so a burst of 8 clears in 8 ÷ 62.5 = 0.13 s, well inside the 2 s pitch. One module suffices, two for headroom.

Worked example 2 — pallet portal, 4 ms cycle, demanding case. A pallet of 240 tags must be read as it passes, and the read window is 1 second.
Required = 240 tags/s. Per-module capacity = 62.5 tags/s. Modules = 240 ÷ 62.5 = 3.84, so 4 modules, in slots 3 to 6. Checked against Zebra's own published 62 tags/s per module rather than the derived 62.5: 4 × 62 = 248 tags/s, still above the 240 required. Memory, using Zebra's own method: output = Access Command 152 + Inventory Command 8 + (4 × 1 handshake byte) = 164 bytes; input = Access Response 155 + (4 × 33) = 287 bytes. Zebra's published two-module example computes 152 + 8 + 2 = 162 output bytes, which confirms the method is theirs and not ours.

Worked example 3 — the same pallet on a slower network, 16 ms cycle. Per-module capacity = (1000 ÷ 16) ÷ 4 = 62.5 ÷ 4 = 15.6 tags/s. Ten modules — the maximum — give 156 tags/s against the 240 required. The fix is on the other three levers: bring the I/O cycle time down, widen the read window, or split the load across two readers. This is the calculation that belongs before the purchase order.

Module	Device to PLC	PLC to device
Inventory Command	—	8 bytes
Standard EPC (12-byte EPC)	33 bytes	1 byte handshake
Extended Standard EPC	44 bytes	1 byte handshake
Long EPC (64-byte EPC)	85 bytes	1 byte handshake
Extended Long EPC	96 bytes	1 byte handshake
Access Command / Response	155 bytes	152 bytes

One failure mode to design against, in Zebra's words: selecting AB_FLIP for the antenna Target parameter configures the radio to read tags in both state A and state B, which “results in a very high tag read rate.” If the number of response modules is inadequate, a buffer overflow occurs on the reader, and “the oldest tag info is discarded.” Silently. A setting that improves the radio can therefore lose data at the PLC boundary — which is exactly why the module count is an RF and a controls decision.

OPC UA AutoID: the free, vendor-neutral model, and the one setting that completes it

There is one genuinely open, genuinely vendor-neutral information model for identification devices, and unlike the Proxy Ident specification you can read it without a membership. OPC 30010, OPC UA for AutoID Devices, version 1.01, published 2020-06-18 by the OPC Foundation, with the namespace http://opcfoundation.org/UA/AutoID/ at model version 1.01.

Its RfidReaderDeviceType defines the methods you would want: Scan, ScanStart and ScanStop to trigger read points, ReadTag, WriteTag and WriteTagID for memory access, and KillTag, LockTag and SetTagPassword for the security commands. Configuration and diagnostics are separated into functional groups — RuntimeParameters for device settings and Diagnostics with a LastAccess branch for what just happened — and two event types, RfidScanEventType and RfidAccessEventType, let the reader push rather than be polled.

One integration step sits in the middle of it, and it is a good illustration of why an open model is necessary and still needs a commissioning engineer. Siemens' OPC UA for SIMATIC Ident application manual (C79000-G8976-C661-01, 02/2022) documents the RuntimeParameters entry CodeTypesRWData, which defines the data type of the RWData diagnostics variable — the read or written data of the last command — with possible values 0: ByteString, 1: String, 2: ScanDataEpc. Siemens' own FAQ on moving a transponder UID to an S7-1500 over OPC UA (Entry ID 109997821, V1.1, 07/2026) gives the procedure. The RF1140R and RF1170R “make the data of the user memory available in the OPC UA node ‘RWData’” under the browse path Readpoint_11 › Diagnostics › LastAccess; RWData “is a variable node of the ByteString data type”, and for an S7-1500 client “it must be changed to the ‘String’ type” by writing the value 1 to CodeTypesRWData under Readpoint_11 › RuntimeParameters. Because that write has to reach the reader's own OPC UA server, Siemens points you at a separate OPC UA client application to make it.

The detail in that FAQ that saves a second site visit: “This value is not stored remanently in the device.” Siemens' advice is to put the variable in both a read list and a write list in the S7-1500's client interface, so it can be monitored and re-asserted when the reader restarts. Two compliant devices speaking a published standard, and the tag data still arrives once someone sets one enumeration and keeps it set.

Two smaller notes from the same Siemens manual, worth knowing before you write acceptance criteria against these fields. MinRssi is the lowest accepted RSSI value for an antenna, range 0 to 255, and Siemens states it is “a value without a unit and without direct reference to the power strength” — so it is a tuning knob, and the specification should describe the outcome you want rather than the integer. RfPower takes a range of 0 to 127 whose meaning differs by reader type, so the same integer means different things on different models.

Reading all of this is why our own software is shaped by the AutoID model rather than by an invented command set: the method names, the split between runtime parameters and diagnostics, and the event-driven access reports are a better contract than anything proprietary, and they are already written down. That thinking is what informs our edge device management and the reader-side logic it deploys.

Wiring, commissioning and which kind of reader you are actually buying

Before any fieldbus, most portals need one physical trigger — a photo-eye in, a stack light or diverter out. Two widely deployed readers publish full electrical detail for this, and they use opposite input conventions. Wiring one as though it were the other puts the input stage at risk.

	Impinj R700 (Installation and Operations Guide v7.6, Appendix B)	Zebra FX Series (FX Series Integration Guide, GPIO Interface Connection)
Count	2 opto-isolated inputs, 3 opto-isolated outputs, +5 V supply, 9-pin connector	FX7500: 2 in / 3 out. FX9600: 4 in / 4 out. Optically isolated terminal block with a +24 VDC pin
Input convention	Range 0–30 V. 0–0.8 V = logic 0; 3–30 V = logic 1. Impinj recommends external devices guarantee a minimum pulse width of at least 100 ms	Inputs are pulled up inside the reader to +5 VDC and are shorted to ground to pull them low. About 3 mA is sourced in the logic-low state. Compatible with NPN sensors, relays or dry contacts
Manufacturer caution	Maximum external user supply between V+ and V− is 30 V	“Do not connect the +24 VDC output directly to any of the general-purpose inputs.” They withstand above 5 V but are designed for 0 to +5 VDC
Output stage	Logic 0 shorts the output to V− through an isolated FET, sinking up to 1500 mA. Logic 1 pulls the output to V+ through only a 10 kΩ resistor. The +5 V pin is limited to 500 mA max	Open-drain NPN drivers pulled up to 5 V, withstanding up to +30 VDC. Each output sinks up to 1 A, but total draw from the internal 24 V supply is capped at 1 A. Output state is inverted — driving the processor pin high pulls the output low
Connector	Phoenix Contact MC 1,5/9-G-3,81, part number 1803345	Pluggable terminal block, isolated from chassis ground but common with the 24 VDC supply return

The design consequence, spelled out: a logic-1 output that is only a 10 kΩ pull-up to V+ is a high-impedance source, and a low-impedance 24 V PLC input needs a low-impedance one. Through 10 kΩ, the current available is on the order of 24 V ÷ 10 kΩ = 2.4 mA, while a typical sinking PLC input draws several milliamps and may sit below its guaranteed-on threshold — giving an input that reads correctly on a meter and intermittently in the field. Put an interposing relay or an optocoupler module between them. Three wiring patterns cover almost everything: NPN sensor to a pulled-up input (sensor sinks the input to ground); dry contact across input and ground; and 24 V PLC output into a reader input through a relay contact or an optocoupler sized for that reader's published input range.

Commissioning checklist, ordered by the symptom you would type into a search box. Each item below is from a manufacturer's own troubleshooting section:

Studio 5000 cannot keep up with the reader. The default Requested Packet Interval is 10 ms, which is the minimum the FX9600 EtherNet/IP module supports; raise it to suit the application.
Access commands do nothing while inventory runs. Inventory and access operations are performed one at a time — stop the inventory first.
Explicit messages fail after an IP change. Re-set the communication path in each MSG instruction.
Intermittent connection. Keep reader and PLC in the same subnet, with static addresses on both.
Data arrives byte-shifted. Check the Comm Format — the Zebra module is configured as Data – SINT, and the input assembly size is specified in bits (464 bits for the standard EPC assembly), not bytes.
The same tag reports endlessly, or new reads are missed. Use SeqNo, which increments with each new report, as the new-data flag rather than comparing tag data — the same tag read again is a new report.
Modbus reads are off by one. Re-read the addressing rule above and test a single register first.

Finally, the decision that precedes all of this: which of four kinds of reader you are buying. (1) A reader with a native multiprotocol runtime on board, where the fieldbus is part of the firmware. (2) An interface module or gateway that feeds passive read/write heads, as in the Turck block-I/O pattern — excellent for short-range channels, sized in bytes per cycle. (3) A reader where the fieldbus is a separately licensed application, as with the FX9600, where a Modbus deployment requires an EtherNet/IP or PROFINET licence to be present first. (4) A reader that speaks LLRP, REST or MQTT, which is the right choice when the consumer is software rather than a controller.

Where the reader speaks LLRP, REST or MQTT and the consumer is a PLC, two paths close the gap. A protocol-conversion gateway adds a box, an IP address, a configuration file and its own polling latency on top of the four-cycle handshake — one more device to keep alive and documented. Middleware on a host adds a server, an operating system to patch and a network hop, but it also gives you filtering, buffering and business logic, which sit more naturally in a host than in ladder logic. For a warehouse or dock-door deployment where the outcome is a database record, middleware usually wins. For an interlock that stops a conveyor, put the decision in the controller and keep the path short.

Specify the fieldbus at purchase time and most of what is above becomes a checklist rather than a project. That is the whole argument for naming it in the tender rather than discovering it at commissioning. Where the firmware and the software above it come from one team, the register map, the handshake and the trigger timing sit with one set of engineers rather than across three vendors' boundaries — which is the question to put to any shortlist, ours included.

Frequently asked questions

How do I connect a UHF RFID reader to a PLC?

Four steps, in order. Confirm which protocol the reader actually speaks and whether it needs a licence to speak it. Obtain the machine-readable description file (EDS or AOP for EtherNet/IP, GSDML for PROFINET) plus the register map or assembly instance numbers with sizes in bits and the data type. Import it, build the module, and establish the handshake. For a Proxy Ident implementation that means a parameter instruction, then a channel reset, then application commands on a positive EXECUTE edge. Finally wire the physical trigger, respecting that reader's input convention. Size the response modules before you order, using the worksheet above, because the handshake and not the radio sets your tag rate.

Do I need middleware between an RFID reader and a PLC?

A reader that carries the fieldbus itself needs none. With Modbus TCP, PROFINET or EtherNet/IP on board it writes tag data straight into the controller's I/O image or holding registers. Middleware earns its place when you need filtering, buffering, de-duplication across portals, or logic that sits better in a host, and when the destination is a database rather than an interlock. If the decision stops a conveyor, keep it in the controller. If the decision creates a record, a host is usually the better home.

Why are my Modbus register reads off by one?

Because the specification says so. MODBUS Application Protocol Specification V1.1b3 section 6.3, Read Holding Registers, states that in the PDU registers are addressed starting at zero, so registers numbered 1-16 are addressed as 0-15 - the same rule section 6.1 gives for coils. The specification demonstrates it in its own Write Multiple Registers example: a request described as writing two registers starting at 2 goes on the wire with Starting Address Hi 00 and Lo 01. A block documented at 40100 is register 100 and wire address 99, and which of the three your master expects depends entirely on that master. Test one register with a single FC03 and confirm the status field reads back before mapping anything else.

How many RFID tags per second can a PLC actually accept?

Far fewer than the radio can read, because a conventional command handshake costs about four PLC cycles per tag. Zebra publishes that each PROFINET response module fetches one EPC per I/O cycle and that a 4 ms cycle yields a maximum of 62 tags per second per module; 1000 divided by 4 is 250 cycles per second, and 250 divided by 62 is 4.03 cycles per tag. Turck states the same limit outright and offers a loop-counter mode needing only two cycles. So capacity per module is (1000 / cycle_ms) / 4 tags per second, and you add modules, lower the cycle time, or split across readers to reach your target.

Can I wire a 24 V PLC output straight into an RFID reader's input?

Check the specific manual, because the two conventions are opposite. Zebra's FX Series guide states the inputs are pulled up internally to +5 VDC and are designed for 0 to +5 VDC, and instructs you to keep the +24 VDC output away from them. The Impinj R700 accepts 0-30 V on its opto-isolated inputs, treating 0-0.8 V as logic 0 and 3-30 V as logic 1. Where the reader's range and the PLC's output differ, interpose a relay or an optocoupler rather than a resistor divider.

Is there a standard PROFINET profile for RFID readers?

Yes. PROFIBUS and PROFINET International publishes Identification Systems, Proxy Ident Function Block, version 1.9, order number 3.142, dated 28 May 2010, defined according to IEC 61131-3 and covering RFID systems and barcode readers. Siemens' shipping implementation shows how the traffic divides: a cyclic status word from the reader to the controller and a cyclic control word from the controller to the reader, with separate MSG_READ and MSG_WRITE message variables carrying the data. The specification download is members-only, which is a large part of why the profile is so little known. On EtherNet/IP the same job is done by vendor-specific assembly instances, so the numbers differ from one reader to the next.

Should I specify Modbus TCP, PROFINET or EtherNet/IP for an RFID reader?

Match the controller you already own, then weigh two things. Modbus TCP is the simplest and most widely available, but the specification states that the mapping between its data model and the device application is totally vendor specific, so you must get the register map in writing and settle byte and word order in the tender. PROFINET has the vendor-neutral Proxy Ident profile, which makes libraries portable across Siemens, Rockwell, Beckhoff and Mitsubishi. On EtherNet/IP, ODVA's PUB00123R1 directs any device outside its specialised profiles to the Generic Device profile 0x2B or a vendor-specific one, so every reader uses vendor-specific assembly instances - demand the EDS or AOP, the instance numbers, the bit sizes and the data type.