Serial & Ethernet Industrial Client / server

Modbus

The register-based protocol most PLCs, energy meters, and building-automation gear already speak — your code polls it for values, the same way a SCADA system would.

Variants

RTU (RS-485), TCP

Model

Client polls, server responds

Data unit

16-bit registers

What Modbus actually is

Modbus dates to 1979 (Modicon, now Schneider Electric) and is still one of the most common protocols in industrial equipment precisely because it's simple enough that almost anything can implement it. It's strictly client/server: a client sends a request, a server responds — devices never speak unless spoken to. There's no discovery, no metadata about what a register means; you get that from the equipment's own documentation, and the protocol just moves numbers.

Two variants matter in practice. Modbus RTU runs over serial, almost always RS-485, and is what you'll find wired into older or cost-sensitive equipment. Modbus TCP is the same data model wrapped in a TCP/IP frame instead of a serial frame — no RS-485 wiring, just a request over a normal network socket.

Type	Access	Typical use
Coil	Read/write, 1 bit	A single relay or on/off output
Discrete input	Read-only, 1 bit	A single digital sensor, like a limit switch
Holding register	Read/write, 16 bit	A setpoint, a configuration value
Input register	Read-only, 16 bit	A measured value, like a temperature reading

How this fits into a General Infinity fleet

Same pattern as every other interface here: General Infinity deploys and supervises your code, and your code is the Modbus client. A typical loop polls a handful of registers on a schedule and does something with the values — log them, forward them, react to a threshold being crossed:

from pymodbus.client import ModbusTcpClient
client = ModbusTcpClient('192.168.1.50')
result = client.read_holding_registers(0, count=4)

If the equipment is RTU over RS-485 rather than TCP, the code looks almost identical — same register model, a serial port instead of a socket. Either way, General Infinity's role stops at keeping that process alive and deployed; it has no opinion about what your registers mean.

Things that bite people

Every RTU device needs a unique unit ID. Multiple Modbus servers share the same RS-485 pair; the client picks which one to talk to by an address in the request, not by wiring.
RS-485 is still a bus, not a star. Same daisy-chain-and-terminate rules as CAN apply — a star topology or missing termination causes exactly the kind of flaky, load-dependent errors that are hard to trace back to wiring.
Register maps aren't standardized across vendors. "Holding register 40001" means whatever that specific device's datasheet says it means. There's no protocol-level way to ask a device what its registers mean — that context only lives in the manual.

Watch for off-by-one addressing. Some vendor documentation numbers registers starting at 1 or with a 4xxxx prefix (a holdover from the original spec), while the wire protocol itself is zero-indexed. Reading the wrong register because of this mismatch is one of the most common Modbus integration bugs.