Industrial protocol gateway not passing data — bridging Modbus / Profibus / EtherNet/IP / serial

When devices on different protocols must talk — e.g. a new EtherNet/IP PLC reading from a legacy Modbus RTU device — you use a protocol gateway (Anybus/HMS, Hilscher netTAP/netGATE, ProSoft, Moxa, Pepperl+Fuchs). The gateway translates between the two networks. The most common fault is not dead hardware but a wrong mapping config → “no data passing through.”

Common bridging scenarios

1. Modbus RTU/TCP ↔ EtherNet/IP — bring legacy Modbus devices into a Rockwell/Logix PLC.
2. Profibus ↔ PROFINET — keep legacy Profibus DP slaves when the controller has moved to PROFINET.
3. Serial ↔ Ethernet — put RS-232/485 devices on the network (device/terminal server).
4. Fieldbus ↔ OPC UA / MQTT — push field data up to SCADA/MES/IIoT.

How to diagnose a gateway not passing data

1. Split the two sides Identify side A (e.g. Modbus) and side B (e.g. EtherNet/IP); verify each side works on its own first.
2. Check the mapping table Compare source register/tag ↔ destination, length and data types match.
3. Byte/word order Wrong endianness (big/little, word swap) → garbage values. Try swapping to test.
4. Per-side network params Modbus: slave ID, baud, function code; EtherNet/IP: IP, RPI, assembly; Profibus/PROFINET: address, GSD/GSDML.
5. LEDs & diag tools Read the status LEDs + the gateway's web/diag tool (Anybus IPconfig, Hilscher SYCON.net…).
6. Back up the config Save the gateway config to a file before edits; many gateways lose config on power-down if not stored.

When to call an expert

Bridging old↔new protocols is a core DeepDebug strength. We help pick the right gateway, build the mapping table, fix byte-order/address issues and get legacy devices onto EtherNet/IP, PROFINET, OPC UA, MQTT — remotely.