English is currently available.
Modbus DISCUSSION
I moved from Modbus RTU to Modbus TCP and my client library still asks for a "unit" or "slave id" on every read. The device already has its own IP address, so I do not see what the number is for. One energy meter answers with any unit ID, while a serial gateway only answers when the ID matches the device behind it.
What is the unit ID really used for in Modbus TCP, and what else changes in the frame compared with RTU?
A Modbus TCP frame carries the same function code and data (the PDU) as RTU, wrapped differently. The slave address byte and the CRC are removed, and a 7-byte MBAP header is placed in front: transaction identifier (2 bytes), protocol identifier (2 bytes, always 0), length (2 bytes, the number of bytes that follow) and unit identifier (1 byte). There is no CRC because TCP and Ethernet already provide error checking, and no silent-interval framing because the length field tells the receiver where the message ends. The registered port is 502.
Example: reading 2 holding registers from address 0, unit 1, is 00 01 00 00 00 06 01 03 00 00 00 02.
The unit identifier exists for gateways. A Modbus TCP to RTU gateway has one IP address but may have 30 serial devices behind it, so it needs to know which slave address to put in the RTU frame. It copies the unit ID into the address byte, forwards the request on RS-485 and returns the reply over TCP. That is why your gateway insists on the right value.
A native TCP device is already identified by its IP address and does not need the field. The implementation guide specifies 255 (0xFF) for that case, but devices vary: some accept anything, some require 255, 0 or 1. If a native device does not respond, the unit ID is the first thing to try changing.
The transaction identifier is the other field worth understanding. The client picks a value for each request and the server echoes it in the reply, so the client can match replies to requests. That allows several requests to be outstanding on one connection, which RTU cannot do.
Behind a serial gateway the requests are still executed one at a time, so a slow or missing serial device delays everything queued after it. Set the TCP client timeout longer than the gateway's serial timeout; otherwise the client gives up and retries while the gateway is still waiting, and the queue only gets longer.
Size limits carry over from serial. The PDU is limited to 253 bytes, which is why one request can read at most 125 registers or 2000 coils and write at most 123 registers, the same as RTU. The whole TCP frame is therefore at most 260 bytes.
Connection handling is where TCP projects usually go wrong. Open one connection and keep it, rather than connecting and disconnecting for every poll, because small devices accept only a few simultaneous connections and may be slow to free closed ones. Handle reconnection explicitly: a pulled cable does not always produce an error until the next request times out.
One thing does not change from RTU: there is no authentication or encryption in the protocol. Anything that can reach port 502 on the device can read and write its registers, so Modbus TCP devices belong on an isolated plant network or VLAN, and the port should never be forwarded to the internet. For remote access, put a VPN in front of the network.
A secure variant of the protocol using TLS has been specified, but check whether your devices support it before relying on it.
