I. Overview Our company offers a comprehensive range of devices supporting both Modbus and CAN protocols. However, selecting the right communication protocol for industrial sites or other applications can be challenging for users. This document aims to clarify the differences between CAN and Modbus to help customers choose products tailored to their specific needs. First, let’s briefly introduce these two protocols: 1.1 CAN Bus is a bus-type communication protocol developed by Bosch in the 1980s. It is defined at the physical and data link layers but lacks an inherent application layer, which can be extended via upper-layer protocols such as CANopen, DeviceNet, or J1939. Originally designed for real-time embedded systems like automotive electronics. 1.2 Modbus Protocol is an application-layer protocol developed by Modicon. It operates over various physical layers, including serial communication (Modbus RTU/ASCII) and Ethernet (Modbus TCP). Modbus is widely used for communication between PLCs, frequency converters, meters, and SCADA systems due to its simplicity, openness, and versatility. 1.3 Summary: CAN is a low-level communication protocol, while Modbus is a high-level application protocol. II. Physical Layer and Topology 2.1 Transmission Medium and Wiring CAN: Uses twisted-pair cables (CAN_H/CAN_L) with 120 Ω termination resistors required at both ends of the bus. Modbus RTU: Typically uses twisted-pair cables (RS485), covering up to ~1200 m at lower baud rates, also requiring termination resistors. Modbus TCP: Runs over standard Ethernet (Cat5/Cat6) and can reuse existing network infrastructure. 2.2 Node Count and Network Topology CAN: Supports up to ~110 nodes (depending on transceiver load), with all nodes connected in a “peer-to-peer” architecture. Modbus RTU: RS-485 buses support a maximum of 32 devices per bus (load-dependent), using a master-slave architecture. Modbus TCP: Node count is limited only by Ethernet switch ports and network scale. III. Data Link Layer and Access Mechanisms 3.1 Bus Access Control CAN: Implements CSMA/CR (Carrier Sense Multiple Access with Collision Resolution) at the bit level. Arbitration is based on message identifiers (IDs), where lower IDs have higher priority, ensuring deterministic access. Modbus: All communication is initiated by the master station, which polls slaves sequentially. Communication latency depends on polling intervals and the number of devices. 3.2 Error Detection and Handling CAN: Hardware-level CRC checks, bit-stuffing validation, acknowledgment slots, and automatic retransmission ensure frame integrity and reliability. Modbus: RTU mode uses CRC-16, while ASCII mode uses LRC. Error timeout and retry logic must be implemented by application software/firmware. IV. Frame Structure and Payload 4.1 CAN Frame Identifier and Priority: Standard frames use 11-bit IDs, extended frames use 29-bit IDs, with arbitration based on ascending ID values. Payload: Classical CAN supports up to 8 bytes; CAN FD supports up to 64 bytes. 4.2 Modbus Frame Address and Function Code: 1-byte device address + 1-byte function code + data + 2-byte CRC (RTU mode). Payload Length: Up to 252 bytes in RTU mode; Modbus TCP payload is “unlimited” in practice (constrained by Ethernet packet size). V. Trade-off Between Speed and Distance CAN: Maximum speed of 1 Mbps (≤40 m); speed decreases with distance (e.g., 125 kbps at 500 m). Modbus RTU: Typical baud rates range from 9600–115200 bps; up to ~1200 m at ≤100 kbps. Modbus TCP: Supports 100 Mbps or 1 Gbps, limited by Ethernet hardware. VI. Typical Applications CAN: Automotive internal networks, multi-axis robots, medical devices, and other scenarios requiring deterministic control. Modbus: PLC-I/O communication, SCADA telemetry, energy management, and building automation. Our company offers a complete lineup of Modbus and CAN devices: CAN Series: ECAN series (e.g., ECAN-E01, ECAN-W01, ECAN-S01). Modbus Series: Remote I/O modules, distributed I/O modules, MA01 serial I/O modules, and ME31 temperature acquisition modules.