Modbus TCP

Modbus TCP wraps the original Modbus RTU register model in TCP/IP packets, keeping the same function codes (read coils, read holding registers, write single register, and so on). Almost anything with an Ethernet port can act as a Modbus client or server, which is why it shows up on everything from lab benchtops to plant PLCs.

In a robot cell it usually appears as a lightweight bridge: the robot controller exposes a small map of registers representing job requests, part counts, or fault codes, and the PLC or cell controller polls that map on a fixed interval. FANUC, KUKA, and Universal Robots controllers all support it either natively or through an option package.

Reach for Modbus TCP when the other device doesn't speak the robot vendor's preferred protocol: a third-party scale, a barcode reader, a small SCADA node, or a legacy PLC that predates EtherNet/IP support.

The protocol only defines the transport and function codes, not what any given register means. Every installation ends up with its own hand-written register map, and that map has to live in the cell documentation or nobody two years later can trace what address 40001 is actually for.

There is no built-in authentication or encryption. Keep Modbus TCP on a segmented plant network and don't expose it to a shared IT VLAN or, worse, the internet. Any device on the same broadcast domain can read and write it if the server side doesn't lock the register range.

Commissioning pitfalls: mismatched byte order (big-endian versus little-endian word swapping is the classic one), polling intervals that starve slow serial-to-TCP gateways, and hard-coded register numbers on both sides so a small map change breaks the interface silently.

Typical uses: reading barcode scans into a machine tending job, passing recipe numbers from an HMI to a Universal Robots UR10e cell, or exchanging count and status data between a robot and a small OEM machine that has no other network option.