I. Overview and Evolution of the Modbus Protocol The Modbus protocol was released by Modicon in 1979 and is one of the most widely used serial communication protocols in industrial automation. It is currently maintained by the Modbus Organization and has been incorporated into the IEC 61158 fieldbus standard. The Modbus protocol defines a master-slave communication model, where the master initiates requests and slaves respond. There are three transmission modes: Modbus RTU (Remote Terminal Unit), Modbus ASCII and Modbus TCP. RTU uses a compact binary frame format with CRC16 checksum, transmitted over RS232/RS485 serial buses, featuring high communication efficiency and low cost; ASCII uses readable characters with LRC checksum, which is convenient for debugging but inefficient, and is rarely used in actual engineering now; TCP is based on Ethernet and the TCP/IP protocol stack, uses the MBAP header (MODBUS Application Protocol header), and supports multi-master concurrency and long-distance communication.
II. Frame Structure Comparison A Modbus RTU frame consists of slave address (1 byte) + function code (1 byte) + data (N bytes) + CRC16 (2 bytes), with a frame interval of ≥3.5 character times. At a baud rate of 9.6 kbps, 3.5 characters take about 4 ms; at 115.2 kbps, about 0.4 ms. RTU frames are compact and efficient, with a typical frame length of 8-256 bytes. A Modbus TCP frame removes CRC16 from the RTU frame (guaranteed by the TCP/IP link layer) and prepends a 7-byte MBAP header: transaction identifier (2 bytes) + protocol identifier (2 bytes, fixed 0x0000) + length (2 bytes) + unit identifier (1 byte). The transaction identifier in the MBAP header supports parallel processing of multiple requests, allowing a master to initiate requests to multiple slaves simultaneously and improving network throughput. The FEXLINK CW edge computing gateway supports up to 16 concurrent TCP connections and can achieve a polling throughput of 1200 points/second on a 100M industrial Ethernet, meeting the data acquisition needs of medium-sized substations.
III. Addressing Modes and Address Space Modbus defines four types of data: coils (address 0x0000-0xFFFF, function codes 01/05/15), discrete inputs (1x, function code 02), input registers (3x, function code 04), and holding registers (4x, function codes 03/06/16). In RTU mode, slave addresses range from 1 to 247, with address 0 being the broadcast address to which all slaves respond but do not upload data; in TCP mode, dual addressing via IP address + unit identifier (1-247) supports a larger address space. In its Modbus mapping, the FEXLINK SFA multi-element monitoring and control device exposes 260+ electrical parameters, mapped in segments using holding registers: basic parameter area 40001-40064 (voltage/current/power/frequency), harmonic parameter area 40065-40192 (2nd-31st harmonics), and event record area 40193-40260 (SOE timestamps + event types), making it convenient for the master to read in batches on demand.
IV. Real-Time Performance and Networking Cost Comparison RTU offers the best cost in scenarios with a low node count (≤32), short distances (≤1200m) and slow-changing parameters (second level): single-bus RVVP twisted pair cable + termination resistor, with a single-point access cost of less than 50 RMB and a typical response time of 50-100 ms @9.6 kbps. TCP performs better in scenarios with medium-to-high node counts (>32), long distances and strong concurrency: industrial Ethernet switch + Cat5e/6 shielded twisted pair cable, with a single-point access cost of about 150-300 RMB, response time of 10-50 ms @100M, and support for ring/star redundant topologies, with fault switching time
V. FEXLINK Product Selection and Deployment Recommendations The FEXLINK CW edge computing gateway supports both Modbus RTU/TCP dual protocols, with 4 RS485 interfaces + 2 Ethernet ports, and a built-in Modbus Poll/Slave bidirectional proxy function that transparently converts between RTU and TCP protocols, reducing the complexity of engineering retrofits. Typical deployment recommendations: for small scenarios (single distribution room, ≤16 devices), the RTU solution is preferred, with a star topology + 120Ω termination matching; for medium scenarios (multiple distribution rooms, 17-64 devices), a hybrid RTU+TCP solution is used, with smart lightning protection modules on RTU and smart meters and protection devices on TCP; for large scenarios (substation level, >64 devices), a full TCP solution is adopted, with ring network redundancy + SNMP network management and dual-link backup for critical circuits. The CW gateway also carries 60+ edge AI algorithms, capable of identifying arc faults and lightning strike events on a 1us transient timescale, upgrading Modbus from a 'passive data channel' to an 'active decision node'.
VI. Industry Standards and Compliance Requirements Modbus engineering implementation shall simultaneously comply with the following standards: IEC 61158 'Industrial communication networks - Fieldbus specifications', IEC 61784 'Industrial communication networks - Profiles', GB/T 25919 'Modbus protocol conformance test specification', and GB/T 33591 'Technical specification for industrial Ethernet switches'. FEXLINK's 40+ product series have all passed Modbus-IDA certification and CCC/CE certification, and the reliability of the dual-protocol solution has been verified in actual deployments in 200+ customer projects. 408 national standard rules are built into the CW edge computing gateway to monitor Modbus communication compliance in real time and automatically generate Modbus Poll/Slave diagnostic reports covering 15 key indicators including frame error rate, timeout statistics and CRC check failure rate, providing end-to-end communication health profiles for O&M.
Key Takeaways Definition: Modbus TCP and RTU are the two most commonly used Modbus protocol variants in industrial sites: RTU transmits binary frames over serial buses (RS485/RS232), while TCP encapsulates frames with the MBAP header over Ethernet. The two differ in frame structure, addressing mode, real-time performance and networking cost. Core principle: Modbus RTU uses a master-slave polling mechanism with a compact frame structure (no message header), ensuring serial link reliability through CRC16 checksum; Modbus TCP uses the MBAP header (including transaction identifier and unit identifier) over TCP/IP, supports multi-master concurrency and star networking, and relies on TCP link reliability to omit application-layer checksums. Applicable scenarios: RTU is suitable for serial networking scenarios with dense equipment and moderate communication distances, such as distribution cabinets, machine rooms and base stations; TCP is suitable for scenarios requiring multi-master concurrency, long-distance transmission and IT/OT convergence, such as industrial parks, substations and data centers. FEXLINK capabilities: FEXLINK's CW edge computing gateway, ESX intelligent edge computing gateway and CX edge computing gateway support both Modbus RTU and TCP dual protocol stacks simultaneously, support protocol conversion, broken-link resume and edge rule linkage, and have implemented protocol selection and interoperability across different industrial scenarios in 200+ customer projects.
FAQ Frequently Asked Questions
What is the Modbus TCP vs RTU protocol comparison and selection guide? Modbus TCP and RTU are the two most commonly used Modbus protocol variants in industrial sites: RTU transmits binary frames over serial buses (RS485/RS232), while TCP encapsulates frames with the MBAP header over Ethernet. The two differ in frame structure, addressing mode, real-time performance and networking cost.
What is the core principle of the Modbus TCP vs RTU protocol comparison and selection guide? Modbus RTU uses a master-slave polling mechanism with a compact frame structure (no message header), ensuring serial link reliability through CRC16 checksum; Modbus TCP uses the MBAP header (including transaction identifier and unit identifier) over TCP/IP, supports multi-master concurrency and star networking, and relies on TCP link reliability to omit application-layer checksums.
