Field Pocket Guide

Digital protocols on the loop

This page covers the digital protocols that share a plant loop with the analog ones: Modbus RTU and TCP, EtherNet/IP, PROFINET, PROFIBUS DP and PA, and OPC.

Digital protocols do not fail mysteriously. They fail at the physical layer, at the framing, or at an addressing convention two vendors wrote down differently. A CRC error is a cable, a terminator, or a bias resistor. An off-by-one register is a documentation convention. A device that will not connect is usually not answering at all, and the error code separates silence from refusal. Same principle as 4-20 mA: find the broken layer before you change anything.

How do I read a 32-bit float from two Modbus registers when the value comes out wrong?

Almost always word order. Modbus fixes the byte order inside a register and says nothing about which of the two registers holds the high word. Swap them and read it again.

A 32-bit IEEE 754 float sits in two consecutive 16-bit registers. A device can lay it out four ways: ABCD (big-endian), CDAB (word swapped), BADC (byte swapped), DCBA (fully reversed). Do not guess. Test against a value you already know. 100.0 is 0x42C80000, so in ABCD order the first register reads 0x42C8 and the second reads 0x0000.

  • Reads 0.0, or something around 2.4e-41 — the words are swapped. The zero-filled low word landed where the exponent belongs.
  • Reads -198,656 where the true value is 100.0 — the bytes are swapped inside each register.
  • For positive process values between 1 and 1000, the register holding the exponent reads 16256 to 17530 as an unsigned integer. If that register is the second of the pair, swap them. A negative value sets the sign bit, so the same range reads 49024 to 50298 instead.

Read both registers in one FC03 transaction so they come from the same device scan. In a ControlLogix, move them with COP. Never MOV, and never an integer-to-real conversion — COP moves the bit pattern, MOV converts the number. Logix is little-endian, so the first INT of the array lands in the low word of the REAL. A device that sends the high word first needs the swap done in the copy.

Is the first Modbus holding register 40001 or 0? My readings are off by one register.

Both are right. 40001 is a documentation convention for holding register 1. The number that goes on the wire is 0.

The Modbus data model numbers each block 1 to 65536. The PDU carries an address of 0 to 65535. That leading digit names the block; it is not part of the address.

  • 0xxxx coils, 1xxxx discrete inputs, 3xxxx input registers, 4xxxx holding registers.
  • "40001" is FC03 with starting address 0. "40100" is starting address 99.
  • A float at 40001-40002 is starting address 0, quantity 2.
  • Six-digit maps (400001) exist so a device can reach all 65536 registers. Same rule: subtract 400001.

An off-by-one is one of two mismatches, and they run in opposite directions. The vendor documents 4xxxx numbers while the client is set to protocol (base 0) addressing: every read lands one register low. Or the vendor documents the raw PDU address and calls the first one "register 1," and every read lands one register high. Prove which one you have by reading a register whose value you already know — a firmware revision, a serial number — not a live process value. Most clients put this in one setting, labeled PLC addresses (base 1) versus protocol addresses (base 0).

Why do I get intermittent CRC errors and timeouts on a long RS-485 Modbus RTU run?

On a long run this is nearly always the physical layer or the converter. The fastest test is to drop the baud rate: if 9600 is clean where 115200 was not, the fault is in the wiring or the converter, not the software.

Read that test honestly. Lower baud relaxes reflections and biasing margin, and it relaxes driver turnaround timing too. A clean 9600 narrows the fault to the cable, the termination, the biasing, or the converter. It does not separate them. Work the physical layer in this order. RS-485 supports about 1200 m (4000 ft) at 100 kbit/s or slower. The rate-times-length product is roughly 10^8 — a rule of thumb, not a figure out of TIA/EIA-485 — so 1 Mbit/s buys about 100 m.

  • Termination. At the two physical ends of the trunk and nowhere else. Power down and measure A-B: with 120 Ω terminators, about 60 Ω is correct, 120 Ω means one is missing, 40 Ω means there are three.
  • Fail-safe bias. With every driver idle the DC differential must sit above +200 mV, the RS-485 receiver threshold. Below that the receiver floats and noise becomes framing and CRC errors. One bias pair on the segment; the Modbus serial line specification puts those resistors between 450 Ω and 650 Ω.
  • Signal common. Run a third conductor with the pair. Receivers tolerate only -7 V to +12 V of common mode referenced to their own ground.
  • Topology. Daisy chain only, no stars and no tees. The Modbus serial line specification allows a derivation (stub) of up to 20 m, but that is a low-rate allowance — at high baud keep stubs to a few tenths of a metre.
  • Loading. 32 unit loads maximum, one unit load being 12 kΩ. Count unit loads, not devices; 1/8-UL transceivers allow up to 256.

If the physical layer checks out, look at turnaround timing. RTU frames are delimited by 3.5 character times of silence, fixed at 1.750 ms above 19200 baud. A converter whose driver-enable releases late is still driving the pair when the slave starts replying. That clips the head of the reply, and it looks exactly like this. So does a duplicate slave address, because two devices answer at once.

Do I need a 120 ohm termination resistor at both ends of an RS-485 Modbus line?

One terminator at each of the two physical ends of the trunk, nowhere else. 120 Ω is the usual value, though the Modbus serial line specification actually names 150 Ω, or 120 Ω with a 1 nF series capacitor.

The two ends are the two most distant devices on the daisy chain. Not the master, not the panel. A master sitting in the middle of the run does not get a terminator. Extra terminators do more damage than missing ones. Two 120 Ω in parallel present 60 Ω, which is already what an RS-485 driver is specified for (1.5 V minimum differential into 54 Ω), and a third drops the load to 40 Ω and pulls the swing down toward the ±200 mV receiver threshold.

On a bus terminated with 120 Ω at both ends, powered down, measured across the pair:

  • ~60 Ω — two terminators. Correct.
  • ~120 Ω — one. Find the missing end.
  • ~40 Ω — three. A device mid-run has its terminator switch on.
  • Several kΩ — none. You are reading the bias network.

Know which value your ends actually carry before you judge a reading. 120 Ω is the practical answer: it matches the characteristic impedance of the twisted pair used for these buses, and it is what TIA/EIA-485 practice assumes. The Modbus serial line specification itself calls for a 150 Ω, 0.5 W resistor, and says a 1 nF series capacitor with a 120 Ω, 0.25 W resistor is the better choice where the pair also has to be polarized. The capacitor blocks the DC path that would otherwise fight the bias network. Read the value off the parts. Do not assume 60 Ω.

Termination is not a substitute for fail-safe bias, and it makes biasing harder: with 60 Ω across the pair, bias resistors sized for an unterminated bus will not hold the idle differential above 200 mV. Short runs at 9600 baud often work with no termination at all. That proves the reflection settled before the sample point. It does not prove the installation is right.

Why does my PROFINET device show "no device name" and how do I assign one in TIA Portal?

A PROFINET IO device is identified by its device name, not its IP address. Unnamed, it cannot be given an IP or join the IO system. Assign one in TIA Portal under Online access, Update accessible devices, then Online & diagnostics, Functions, Assign PROFINET device name.

The controller resolves the name to a MAC address using DCP, then pushes the IP address down the same way. DCP is a Layer 2 protocol (Ethertype 0x8892) with no IP header at all. It does not cross a router, so the programming PC has to sit in the same broadcast domain as the device. Use the flash-LED function before you click Assign name, so you know which physical device you are naming. Menu wording shifts between TIA Portal versions. The path is always Online access to the adapter, then that device's Online & diagnostics.

The naming rules come from IEC 61158-6-10 and are stricter than they look.

  • 1 to 240 characters total, each dot-separated label at most 63.
  • Lowercase a-z, digits 0-9, hyphen and period only. No underscores, no uppercase, no spaces, no slashes.
  • No leading or trailing hyphen on a label.
  • The name must not have the form n.n.n.n (n = 0...999), so it cannot look like an IP address.
  • The first label must not have the form port-xyz or port-xyz-abcde (x, y, z, a, b, c, d, e = 0...9), because that form is reserved for port identifiers.
  • The name must match the project exactly. A tag copied off a P&ID usually fails here: uppercase letters, slashes, spaces. Read the name back off the device after assigning it. What ends up stored is not always what you typed.

Two other reasons a name goes blank. A reset to factory settings clears it. On devices that store the name on a memory card, a swapped card carries the wrong one.

Automatic naming on device replacement needs two things, not one: port neighbors configured in the Topology editor and device replacement without exchangeable medium enabled on the IO controller. If both are set and the device still comes up unnamed, the configured topology does not match how the panel is actually cabled.

What does a flashing BF (bus fault) LED mean on a Siemens PROFINET CPU or IO module?

On an S7-300 CPU with a PROFINET interface, steady BF means the interface itself cannot communicate at all, usually no link to the switch. Flashing BF means the link is up but the controller cannot set up communication with all of its configured IO devices — almost always a device name, IP, or configuration mismatch.

Siemens splits it cleanly in the LED table in the CPU 31xC and CPU 31x installation manual. BF lit: error on the PROFINET interface, communication no longer possible — for example, with a CPU as IO controller, when the connection to the switch is down. BF flashing: communication cannot be set up correctly to all devices on the PROFINET IO controller, for example station failure of one or several IO devices, while communication through a port of the interface is still possible. On a CPU running as an intelligent device, BF keeps flashing until at least one controller has correctly set up communication with it. BF off: no error at the PROFINET interface. Read it in that order and the problem is halved before you open a laptop.

  • Steady BF — Siemens lists a bus fault with no cable connection to a subnet or switch, the wrong transmission speed, and full duplex mode not set. Check the link LED and confirm the port is running 100 Mbit/s full duplex.
  • Flashing BF — Siemens lists failure of a connected IO device, an assigned IO device that cannot be addressed, and bad engineering configuration. Its own remedies are to verify that the configured device name matches the name actually assigned, and to check whether connected devices are carrying duplicate names or IP addresses.

Which LED is the PROFINET one depends on the CPU. Siemens heads the PROFINET fault tables "BF2 / BF3": on a two-interface S7-300 such as a CPU 315-2 PN/DP or 317-2 PN/DP, the first interface is MPI/DP and BF2 is the PROFINET LED; on a three-interface CPU 319-3 PN/DP, BF3 is PROFINET. Count the interfaces before you read the LED.

Plenty of Siemens hardware has no BF LED at all. Do not go hunting for one. S7-1500 CPUs use RUN/STOP, ERROR and MAINT. So does the CM 1542-5, the S7-1500 PROFIBUS communication module — its manual lists exactly three LEDs, RUN/STOP, ERROR and MAINT, and no BF. An ET 200SP IM 155-6 PN ST has RN, ER, MT and PWR on the interface module, and LK1/LK2 on the BusAdapter. A module configured but not yet exchanging data with the controller shows RN flashing green; RN goes steady on once the controller has it. LK1/LK2 off is the link problem.

The LED table in the manual for your exact model is the authority. Read the diagnostic buffer before replacing anything. It names the failed device and the fault, and guessing from an LED is slower.

Why can't RSLinx find my PLC on the EtherNet/IP driver?

The EtherNet/IP driver finds devices by broadcasting on the subnet of one selected network adapter, and no other way. A PLC on a different subnet, behind a router, across a VPN, or reached through the wrong adapter will never appear.

Work up from the bottom. Link light, then ping, then browse. If ping works and browse does not, the network is fine and the problem is the driver, the adapter, or the firewall.

  • Wrong adapter. RSLinx binds the driver to one NIC. A laptop with Wi-Fi, a dock, a VPN client, and virtual adapters offers it four wrong choices. Select the adapter by its actual IP.
  • Subnet mismatch. A PC at 10.10.10.5/24 will not browse a PLC at 192.168.1.10 even on the same switch. Add a second IP to the NIC rather than re-addressing the PLC.
  • Firewall. EtherNet/IP explicit messaging and session management are TCP 44818, discovery is UDP 44818, and implicit I/O is UDP 2222. Legacy CSP/PCCC to a PLC-5 or SLC-5/05 is a different thing on TCP 2222. A newly connected network defaults to the Public profile and blocks all of them.
  • Service stopped. RSLinx Classic runs as a service. Check it in the RSLinx Classic Launch Control Panel.

For a routed or VPN path, use the Ethernet Devices driver instead. It connects unicast to TCP 44818 and works where broadcast does not. One catch: that driver probes the legacy CSP port 2222 first, and has to see it refused several times before it falls back to 44818. A stateful firewall reads that burst of rejected connections as a port scan and blocks the lot. Append :EIP to the address in the host list (192.168.1.10:EIP) and RSLinx skips the 2222 probe, straight to TCP 44818. A device that browses with a yellow question mark was found and simply has no EDS file. Cosmetic.

What does error 16#0204 connection request timed out mean on a ControlLogix EtherNet/IP module?

The connection request went out and nothing came back. Either the target never received it, the route path never got it there, or its reply never got home.

16#0204 is a CIP Connection Manager extended status. Silence versus refusal is the distinction that matters. A target that heard you and said no returns a different code: 16#0100 connection in use, 16#0113 out of connections, 16#0311 port not available, 16#0312 link address not available, 16#0315 invalid segment in the path. Getting 0204 instead means stop debugging the target's parameters. Work on whether the request is arriving at all, which is the network and the route path both.

  • Ping the target IP. No answer means power, cable, IP, VLAN, or a router in the way.
  • Check the MSG path. A path of 1, 1, 2, 192.168.1.10, 1, 0 reads backplane, slot 1, Ethernet port, IP, backplane, slot 0. A wrong slot number produces 0204 on a perfectly healthy network, because the request reaches the chassis and then goes nowhere.
  • Check connection counts. A 1756-ENBT supports 128 CIP and 64 TCP connections. A module that is simply full normally answers with 16#0113, not 0204, but one saturated with traffic can fail to answer inside the timeout and give 0204 instead.
  • Look for a duplicate IP. Two devices at one address gives an intermittent 0204 with no pattern. Logix Ethernet modules run address conflict detection per RFC 5227: the second device onto the network drops its port into Conflict mode with a steady red network status indicator, so check the module status before you go hunting.

The same code shows up on an HMI transfer and on a MSG instruction, and it means the same thing in both. Fix reachability and the path first. Nothing about the target's configuration is worth checking until a ping returns.

What is the difference between Modbus RTU and Modbus TCP?

The function codes and the register map are identical. Framing and transport are what change: RTU wraps the request in a slave address and a CRC on a serial line, TCP wraps the same request in a 7-byte MBAP header sent to port 502.

Everything above the framing is the same. FC03 reading 10 holding registers from address 0 is byte-for-byte the same PDU in both.

  • RTU: RS-485 or RS-232, one master, slave addresses 1-247 with 0 as broadcast and 248-255 reserved, frames delimited by 3.5 character times of silence, integrity by CRC-16, ADU up to 256 bytes, half duplex, one transaction outstanding at a time.
  • TCP: port 502, no CRC because TCP handles integrity, a 7-byte MBAP header carrying transaction identifier, protocol identifier, length, and a unit identifier that replaces the slave address, ADU up to 260 bytes, many clients and many outstanding transactions at once.

The unit identifier is where people get caught. The Modbus messaging implementation guide says to use 0xFF (255) when addressing a server connected directly to a TCP/IP network. The reasoning: if that IP is ever reassigned to a gateway, a non-significant address gets discarded cleanly instead of being mis-routed onto a serial line. 0 is also accepted for a direct TCP device. Some devices insist on 1 and answer nothing else. Where the TCP endpoint is a gateway onto a serial line, it has to be the real serial slave address.

There is a third thing, Modbus RTU over TCP: a complete RTU frame, CRC and all, pushed through a socket, often on port 502 as well. It is not Modbus TCP. Select the wrong one in the client and it looks exactly like a dead device.

What is the difference between RS-232, RS-422 and RS-485?

RS-232 is single-ended and point to point, RS-422 is differential with one driver and up to 10 receivers, and RS-485 is differential and multipoint with up to 32 unit loads that take turns driving the same pair.

Two dividing lines. Is the signal referenced to ground or to itself, and is more than one device allowed to drive.

  • RS-232: referenced to a shared ground, driver ±5 V to ±15 V, receiver threshold ±3 V, load 3 kΩ to 7 kΩ, one driver and one receiver. The familiar 15 m (50 ft) figure is what the standard's 2500 pF load capacitance limit works out to on ordinary cable. The real limit is capacitance: low-capacitance cable goes further, ribbon cable does not. Any ground potential difference between the ends lands directly in the signal.
  • RS-422: differential, one driver that is always enabled, up to 10 receivers, 1200 m, four wires plus a common. Full duplex, no arbitration.
  • RS-485: differential with tri-state drivers, up to 32 unit loads at 12 kΩ each, 1200 m, driver output at least 1.5 V into 54 Ω, receiver threshold ±200 mV, common-mode range -7 V to +12 V. Two-wire half duplex or four-wire full duplex.

RS-422 and RS-485 are close enough electrically that a four-wire RS-422 device will usually talk to an RS-485 port. The real difference is whether the driver can let go of the line. That is why an RS-422 device can only ever be the one that talks first.

Do not trust the A and B labels. Do not trust anyone who tells you which one is correct, either. The Modbus serial line specification avoids the argument entirely by naming the two conductors D0 and D1, D0 the inverting line and D1 the non-inverting one, and it maps D1 to the terminal printed B and D0 to the terminal printed A — the opposite of how a large number of other devices label the same wires. Across vendors the labels carry no information. If a link is silent, swap the two data conductors before doing anything else. Nothing is damaged by trying it.

Do I need a managed switch for EtherNet/IP remote I/O or will an unmanaged switch work?

An unmanaged switch will carry EtherNet/IP, and small systems run on them every day. You want a managed switch with IGMP snooping as soon as the I/O connections use multicast, or the segment grows past a handful of devices.

CIP class 1 implicit I/O connections have traditionally used IP multicast for the device-to-controller direction. An unmanaged switch has no IGMP snooping, so it floods every multicast frame out every port. With two devices that is nothing. With 20 devices at a 10 ms RPI, every NIC on the segment is receiving and discarding everyone else's I/O. The first thing to fall over is usually a low-end HMI or a drive, and it shows up as connection timeouts with no obvious cause.

There is an escape hatch worth knowing before you spend money. Most current devices and Logix firmware let you set the I/O connection to unicast, on the module's Connection tab or in its Module Definition depending on the module. If every device on the segment supports it, the multicast problem disappears and an unmanaged switch is genuinely adequate. Check each device rather than assuming. Older FLEX I/O and some drives are multicast only, and one of them undoes the whole exercise. Unicast also rules out a second listen-only or redundant scanner consuming the same produced data, so confirm nothing else needs it.

If you do go managed, enable IGMP snooping and configure exactly one querier on the VLAN. Snooping with no querier is worse than no snooping: memberships age out and the I/O connections drop.

Beyond multicast control, a managed switch buys per-port error counters, port mirroring for a capture, locked speed and duplex, VLANs, and DLR ring support. DLR is not something a switch delivers on its own. Every node in a DLR ring needs two ports and embedded switch hardware, and the ring needs an active ring supervisor, with a backup supervisor as good practice; single-port devices join only through a three-port tap. Keep consumer switches with Energy Efficient Ethernet or green port power-down off a control segment. And if the segment touches a plant network, that is a design question — the group that owns that network belongs in the conversation, not a switch bought around them.

Can I use regular Cat5e patch cable for PROFINET instead of the green PROFINET cable?

Electrically, yes. A shielded Cat5e cable meeting 100BASE-TX will carry a 100 Mbit/s PROFINET link. What the green cable buys you is the mechanical, shielding, and connector specification, not better data.

Standard PROFINET copper cable is 2 pair (4 wire), AWG 22 solid, foil plus braid shield, green, standardized by PI so any member's cable and connector work together. Maximum copper segment is 100 m, the same as ordinary Ethernet. The trade runs the other way too. A 2-pair cable only supports 100BASE-TX and will never do 1000BASE-T, which needs all four pairs. PROFINET itself is not limited to 100 Mbit/s — PI also specifies a 4-pair (8-wire) cable for gigabit links — but the green 2-pair cable in most panels is not it.

  • Type A — fixed installation, no movement after it is laid in.
  • Type B — occasional flexing, such as a hinged door.
  • Type C — special applications: continuous flex or torsion, such as a drag chain or a robot arm.

Two practical reasons to use the specified cable in a plant. The solid AWG 22 conductor is what field-terminable push-in connectors are built for, and a stranded patch cord will not seat reliably in one. And the connector system gives a 360° shield bond, which is what keeps a drive out of your I/O.

PROFINET grounds the shield at both ends deliberately. High-frequency common-mode current needs a return path. That is the opposite of good analog practice, so grounding one end out of habit creates the interference problem you were avoiding. A pigtail instead of a 360° bond does the same damage. Before replacing any cable, read the per-port CRC and discarded-frame counters in the switch or in TIA Portal port diagnostics. Those counters name the bad link. Blind cable swaps usually do not.

What is the difference between PROFIBUS DP and PROFIBUS PA?

Same protocol, different physical layer. DP runs RS-485 at 9.6 kbit/s to 12 Mbit/s to separately powered devices. PA runs a Manchester bus-powered physical layer at a fixed 31.25 kbit/s that can be made intrinsically safe.

The protocol services above the physical layer are the same, which is why a single engineering tool configures both.

  • DP: RS-485, violet Type A cable, 9-pin D-sub with a switchable terminator, 32 devices per segment without a repeater, addresses 0-125, 1200 m at 93.75 kbit/s falling to 100 m at 12 Mbit/s. Devices carry their own 24 V.
  • PA: MBP per IEC 61158-2, fixed 31.25 kbit/s, blue cable, up to 1900 m per segment on non-IS Type A cable and about 1000 m on an EEx ia IIC intrinsically safe segment, power and signal on the same pair, signalling by ±9 mA current modulation, terminated at both ends. The power conditioner's current budget rather than the address space sets how many devices fit — add up the quiescent current from each device's datasheet.

One DP fault worth knowing before you chase anything else. The terminator inside a PROFIBUS D-sub connector is an active network, fed from the 5 V (VP) on pin 6 of the device it is plugged into and referenced to DGND on pin 5. Switch it on at the end of a segment, then de-energize that device, and the segment is unterminated with the switch still reading ON. A bus that only misbehaves when one panel is powered down is this.

DP and PA join through a coupler or a link, and the difference matters. A DP/PA coupler is transparent: no configuration, does not appear on the bus, and the DP master sees each PA device individually. The cost is that the DP segment it sits on must run at the coupler's fixed rate, commonly 45.45 kbit/s on Siemens couplers. A link has its own master and presents the whole PA segment as one DP slave, so the DP side keeps running at 1.5 Mbit/s or better. In the field: a 24 V remote I/O rack or a drive is DP; a bus-powered transmitter or valve positioner is PA.

What is the difference between OPC UA and OPC DA, and do I still have to deal with DCOM?

OPC UA is a protocol of its own over TCP (opc.tcp://, port 4840), certificate-based security, no COM anywhere. OPC DA is COM/DCOM and Windows-only. Run a DA server and you still deal with DCOM.

DCOM got harder, not easier. Microsoft's hardening for CVE-2021-26414 (KB5004442) rolled out in three stages: optional from 8 June 2021, on by default but disableable from 14 June 2022, mandatory from the 14 March 2023 updates, when the ability to turn it off was removed. DCOM servers now enforce packet-integrity authentication. Classic OPC connections that depended on loose DCOM authentication fail outright. DCOM also needs the RPC endpoint mapper on TCP 135 plus a dynamically assigned high port per connection, and DA callbacks have the server calling back to the client — matching identities on both machines, firewall rules in both directions.

If the DA server cannot be replaced, the practical route is a UA wrapper or a tunneler that fronts it and carries the data over a single TCP connection. That takes DCOM off the wire entirely, and it is nearly always less work than making DCOM behave across a firewall.

UA is not automatically more reliable. It has a signature failure of its own: a server and client that do not trust each other's application certificates, surfacing as BadSecurityChecksFailed or BadCertificateUntrusted. The fix is moving the certificate into the trusted store at both ends. Not setting the endpoint security to None. Check the clock on both machines while you are there — a certificate is validated against its not-before and not-after dates, and a PC with a wrong date fails with BadCertificateTimeInvalid even when the trust is set correctly.

The binary opc.tcp binding on port 4840 is what plants actually use. UA also defines an HTTPS binding, rarer in the field. If the point of the UA server is to expose plant data to a corporate network, that is a security architecture decision and both IT and OT belong in the room.

What is the best Modbus RTU to EtherNet/IP gateway for getting a power meter into a ControlLogix?

There is no single best one. Before buying a gateway at all, check whether the meter offers a native EtherNet/IP or Modbus TCP option card. Usually cheaper, and one less box to fail.

If the meter speaks Modbus TCP, or a serial device server can be used to make it speak Modbus TCP, you may need no gateway hardware at all. Rockwell publishes a free Modbus TCP client Add-On Instruction — search "Modbus TCP AOI" on rockwellautomation.com — that uses the controller's socket object. It needs a module with socket services and firmware to match: the 1756-EN2T/EN2TR/EN2F/EN3TR/EN4TR family and CompactLogix embedded ports. Not the older 1756-ENBT, which has none. Fine for one meter, poor for twenty, because you own the ladder and the socket handling.

  • ProSoft PLX31-EIP-MBS — DIN rail, EtherNet/IP to Modbus serial master or slave, appears in the Logix I/O tree with input and output assemblies.
  • ProSoft MVI56E-MCM — in-chassis 1756 module, two independently configurable serial ports. Costs more, but no extra IP address, no extra power supply, no extra panel space.
  • HMS Anybus Communicator, Moxa MGate 5105-MB-EIP, Real Time Automation 460ETCMRS — single-port, web or utility configured, all adequate for one meter.

These are close in capability. What separates them is the configuration tool, and whether an Add-On Profile delivers named tags instead of a raw INT array. Size it honestly: a power meter's useful block is typically 30 to 100 registers, so do not buy the 4000-register model for one device.

Set the poll slower than the meter's response time. Many meters need 100 to 300 ms to answer a large block read. A 50 ms poll does not make the data faster — it makes the gateway retry, and the effective update rate ends up worse than a 500 ms poll would have been. The gateway passes registers through raw, so the 32-bit word-order question above still applies on the Logix side. If the data is wanted for energy reporting rather than control, a power monitoring package or a historian reading the meter directly beats routing it through the PLC.

When this page runs out

This page is reference material, not a substitute for the device manual: the register map, the LED table, and the connection limits for your specific model are in the manufacturer's document, and where the two disagree, the manufacturer wins. If what is needed is an accredited calibration certificate, a repair under an OEM warranty, a network design for a segment that touches a corporate network, or an intrinsic safety calculation for a PA segment, then an accredited laboratory, the manufacturer, the plant network group, or whoever holds the area classification drawings is the right call, and Bridges Industrial will say so. What Bridges Industrial handles is the part in between: a value that reads wrong, a bus that drops out, and a device that will not talk to the controller in front of it.

Reference material, not a site-specific engineering recommendation. Verify against your own procedures, permits, and the manual for the device in hand.