Modbus vs CAN bus

Modbus vs CAN bus

What is CAN, and what are its advantages? What is Modbus, and what are its advantages? What are the disparities between the CAN and Modbus communication protocols?

Typically, novice practitioners who have recently embarked upon their exploration of CAN and Modbus often find themselves perplexed by the intricacies of these distinct communication protocols, thereby giving rise to the aforementioned inquiries. The informative articles found online tend to either delve too deeply into the subject matter or present oversimplified explanations. Is there perchance an article suitable for neophytes, one that fosters their comprehension? After all, the majority of individuals do not necessitate an acquaintance with the profound intricacies of low-level development; rather, they simply seek an understanding of the fundamental operational principles and primary disparities in data communication among these protocols.

This article aims to acquaint you with the CAN and Modbus communication protocols and elucidate, in a lucid and accessible manner, the dissimilarities between them.

1.CAN (Controller Area Network)

CAN, an abbreviation for Controller Area Network, is a serial communication protocol standardized by ISO. It serves as a widely employed real-time communication protocol for control systems. Originally developed by Germany's Robert Bosch GmbH in 1986 for automotive applications, the primary objective of this protocol was to simplify communication between controllers within a vehicle. Given this context, one can infer the distinctive characteristics of CAN communication: robust real-time capability, reliable data transmission, and strong resistance to interference.

An automobile system encompasses numerous control tasks that necessitate real-time responsiveness, such as engine management, braking systems, and steering systems. Moreover, the automotive environment is rife with electromagnetic interference sources, including the engine, ignition systems, and electrical devices. Just imagine the potential horrors if the internal data transmission within a vehicle were to suffer from interference, resulting in erroneous data transmission or signal delays. The implications are grave when considering the scenario where the car fails to respond promptly and efficiently to crucial actions like braking or steering, jeopardizing our personal safety. Hence, the adoption of CAN as the internal network for automobiles helps mitigate such safety risks.

Due to its high performance and reliability, CAN has also found extensive applications in industrial automation, marine vessels, medical equipment, and industrial machinery.

1.1Principles of CAN Communication

CAN operates on a broadcast model, where each device has the opportunity to transmit messages on the bus. These messages are not directed but received by all devices connected to the network. Each message carries a unique identifier that determines its priority in the network (lower identifiers implying higher priority). CAN enables real-time control by prioritizing the transmission of messages with higher priority.

To illustrate, imagine yourself in a large family, where each family member possesses a walkie-talkie for communication. In this scenario, the walkie-talkies represent the CAN bus, while the family members are the devices connected to the bus, such as sensors, actuators, and controllers.

Now, when a family member wishes to communicate with others, they press the button on their walkie-talkie and speak their message. This message is transmitted through the walkie-talkie's speaker, much like a broadcast, and other members can listen in.

In CAN communication, each device can also transmit messages, similar to pressing the button on the walkie-talkie and speaking a message. These messages are sent through the CAN bus, and every device can receive them, executing them if they are relevant or ignoring them if they are not.

However, we need to avoid conflicts when multiple devices attempt to transmit messages simultaneously, just like how multiple people talking at once in a family can lead to confusion. To address this issue, CAN introduces a conflict detection mechanism.

When multiple devices try to send messages simultaneously, conflicts occur on the CAN bus, much like everyone speaking at the same time in a family. However, the CAN bus can detect these conflicts and employs an algorithm to make the devices wait for a random duration before attempting to transmit again. This way, each device gets an opportunity to send its own message without causing data loss or confusion.

This is the fundamental principle of CAN communication: utilizing a shared bus for communication, where devices can transmit and receive messages, while the conflict detection mechanism ensures reliable message transmission. This simple yet effective approach has made CAN a widely adopted communication protocol in fields such as automotive and industrial control.

1.2 CAN Data

The CAN communication protocol offers a reliable and real-time means of data transmission, enabling the transfer of various data types through the message identifier and data field. Standard frames and extended frames are commonly employed data formats, encompassing the processes of competitive transmission, arbitration, data transfer, and error detection. Familiarizing oneself with the definition, format, data transmission process, and types of data within the CAN protocol facilitates a better understanding and application of CAN communication, meeting diverse data transmission requirements in different domains.

I.Data Definition:

Within the CAN protocol, data is transmitted through messages. Each message consists of an identifier and a data field. The identifier serves to indicate the priority and content of the message, while the data field encapsulates the actual data information. The identifier is typically represented by a set of bits, used to identify different types of messages. The data field can be tailored to the requirements of the application, accommodating various data types such as Boolean, integer, and floating-point.

II. Data Formats:

Standard Frame: The standard frame serves as a conduit for conventional data transmission, encompassing both data and remote requests.

• Identifier: Spanning 11 bits in length, it serves to uniquely identify the message.
• Remote Transmission Request (RTR) bit: It distinguishes between data frames and remote request frames, with the latter employed to solicit data transmission from other nodes.
• Data Length Code (DLC): This code indicates the number of data bytes contained within the data field, typically ranging from 0 to 8 bytes.
• Data Field: It encapsulates the actual transmitted data information.
• Extended Frame: The extended frame facilitates the transmission of larger volumes of data or endows higher-level functionalities.
• Identifier: Extending to 29 bits in length, it provides a larger identifier space.
• Remote Transmission Request (RTR) bit: Similar to the standard frame, it serves to differentiate between data frames and remote request frames.
• Data Length Code (DLC): Identical to the standard frame, it indicates the number of data bytes within the data field.
• Data Field: As with the standard frame, it carries the actual transmitted data information.

III.Data Transmission Process:

In CAN communication, multiple nodes can share a common bus for data transmission. The transmission of data follows the following process:

• Competitive Transmission: When the bus is idle, multiple nodes can contend to transmit messages. The transmitting node first checks if the bus is available and then proceeds to send the message.
• Arbitration: If multiple nodes attempt to transmit messages simultaneously, the arbitration mechanism within the CAN protocol determines which node can continue transmitting based on the priority of the identifier.
• Data Transfer: The victorious node continues to transmit its message, while the other nodes cease transmission and shift to the receiving mode.
• Error Detection: The CAN protocol possesses robust error detection mechanisms that identify errors occurring during the transmission process, such as bit errors and frame errors. When a node detects an error, it transmits an error notification to other nodes, ensuring the entire system remains vigilant to potential issues.

IV.Data Types:

The CAN protocol embraces a myriad of data types for transmission, encompassing, but not limited to, the following:

• Boolean: Employed for conveying logical values, enabling the representation of truth (1) or falsehood (0).
• Integer: Utilized for transmitting integer values, encompassing positive numbers, negative numbers, or zero.
• Floating-Point: Deployed for transmitting real (floating-point) values, supporting both single-precision and double-precision floating-point representations.
• String: Employed for transmitting sequences of characters, such as textual information.
• Custom Types: Tailored to the specific demands of applications, it allows for the definition and utilization of other specialized data types.

By judiciously selecting and combining diverse data types, the CAN protocol can cater to the data transmission requirements of various application scenarios. From humble switch signals to intricate sensor data, the CAN protocol enables the steadfast transmission of information.

1.3 Advantages and Limitations of CAN:

The CAN protocol boasts its virtues of reliability and real-time capability. It operates effectively in noisy and redundant environments, such as automotive or industrial settings, ensuring the timely delivery of messages. This signifies that CAN offers a stable and dependable means of communication, suitable for applications with stringent demands for data transmission latency and reliability.

However, the primary limitations of CAN lie in the trade-off between transmission rate and distance. The maximum transmission rate allowed by CAN is 1 Mbps, but this rate is applicable only for shorter communication distances (less than 40 meters). If the communication distance exceeds this range, the transmission rate needs to be lowered to ensure reliable data transfer. Consequently, in long-distance communication, the transmission rate of CAN may correspondingly decrease.

Hence, while CAN possesses advantages such as reliability and real-time capability, it requires a balance between transmission rate and distance in long-distance communication. In practical applications, it is essential to select an appropriate CAN configuration that aligns with specific requirements and the limitations of the communication environment, striking a harmonious balance between the speed and distance demands of data transmission.

2.Modbus

Modbus is a serial communication protocol originally developed in 1979 by Modicon for its programmable logic controllers (PLCs). Over the years, Modbus has emerged as one of the most prevalent communication protocols in industrial control systems.

2.1Working Principle of Modbus

Modbus operates as a master-slave protocol, where there is a designated device acting as the master and other devices functioning as slaves. The master device can both read and write data to the slave devices. The slave devices only transmit data upon receiving requests from the master.

This can be likened to a dialogue between two parties: the master (the initiating device) and the servant (the responding device).

The master assumes the role of the communicator, sending inquiries and making requests to the servant. These requests may involve reading or writing data, or performing specific operations. The servant, on the other hand, serves as the respondent, receiving the master's requests and providing appropriate responses accordingly.

This dialogue follows a set of rules. The master identifies itself to the servant by assigning an address, so the servant knows which master is addressing it. Subsequently, the master employs a special command to express its intentions, such as requesting data reading or writing. Upon receiving the command, the servant carries out the specified operations and returns the results to the master.

There are additional intricacies within this dialogue. For instance, specific data formats are employed for information transmission between the master and servant, much like the rules of a language. Moreover, an error detection mechanism is in place, resembling a comprehension check during the conversation, ensuring the accuracy and integrity of information. In the event of an error, the servant notifies the master, and they collaborate to resolve the issue.

In summary, the principle of Modbus communication revolves around a dialogue between a master and its servant, enabling the exchange of data. The master sends requests, the servant receives and executes these requests, and then replies with the results. They adhere to a set of rules encompassing identity confirmation, command exchange, and error handling to ensure smooth communication.

2.2 Modbus Data

Modbus is a widely employed communication protocol used for data transmission and communication among devices in the industrial domain. It encompasses straightforward and comprehensible data definitions, formats, and transmission procedures, suitable for facilitating data exchange across various devices.

I.Data Definitions:

Within the realm of Modbus, data can be defined as different types, including the following commonly encountered types:

• Bits (Coil): Utilized to convey individual boolean values, representing switch states, which can be either on or off.
• Discrete Inputs: Employed to transmit discrete input signals, such as sensor statuses.
• Holding Registers: Used for transmitting 16-bit integer values, often employed for configuring and controlling parameters.
• Input Registers: Utilized to transmit read-only 16-bit integer values, typically employed for obtaining device statuses and data.

II.Data Formats:

Modbus data formats typically fall into two categories: ASCII format and RTU format.

• ASCII Format: Data is transmitted in the form of ASCII characters, with each byte represented by two characters.
• RTU Format: Data is transmitted in binary form, with each byte composed of eight bits.

III.Transmission Process:

The transmission process of Modbus communication encompasses several pivotal steps:

• Request Transmission: The master device dispatches a request to the slave device, comprising instructions and relevant parameters for data read or write.
• Request Reception: The slave device receives the request from the master device and proceeds with processing.
• Request Execution: The slave device performs the requested operation from the master device, involving data read or write.
• Response Dispatch: The slave device sends the execution results back to the master device, encompassing the read data or execution status.
• Response Handling: The master device receives the response from the slave device and carries out the appropriate processing and parsing.

IV.Data Typs:

Modbus supports multiple data types for transmission, including but not limited to the following:

• Coils: Signify the status of a switch, which can be either "ON" or "OFF."
• 16-bit Integers: Employed for transmitting signed or unsigned integer values.
• 32-bit Floating-Point Numbers: Utilized for transmitting real numbers (floating-point values), supporting single and double-precision representations.
• Strings: Utilized for transmitting character sequences, such as textual information.

Understanding the data definition, format, transmission process, and types of the Modbus protocol aids us in comprehending and applying this communication protocol more effectively. By appropriately selecting data types and configuring the transmission format, we can establish a stable and efficient communication system that fulfills the requirements of various industrial fields.

2.3 Advantages and Limitations of Modbus

The primary virtues of Modbus lie in its simplicity and extensive support. It is a communication protocol that is easy to comprehend and implement, finding widespread application and endorsement in the industrial domain. Modbus enables communication through serial lines such as RS232 or RS485, as well as Ethernet, making it suitable for diverse communication environments and devices.

However, Modbus's principal constraints are its relatively lower efficiency and lack of real-time capabilities. As a master-slave protocol, when numerous devices require communication, the master device may become burdened, resulting in increased communication delays. This implies that under high load conditions, communication may slow down and fail to meet the demands of real-time applications.

Therefore, despite Modbus's simplicity and extensive support, alternative communication protocols may need to be considered for applications requiring high efficiency and real-time responsiveness. For systems necessitating high-speed communication and real-time responses, other protocols such as CAN or Industrial Ethernet protocols like Ethernet/IP or Profinet may be more suitable. Choosing an appropriate communication protocol requires evaluation and decision-making based on specific application requirements and system demands.

3.CAN vs Modbus

CAN and Modbus are two commonly used communication protocols employed in industrial control and automation fields. They differ in various aspects, and the following are key distinctions that can aid readers in better understanding their characteristics and applicable scenarios.

Table 1. CAN vs. Modbus

3.1 Communication Modes

• CAN operates based on a broadcast model where all devices can transmit messages on the bus, which are received by all other devices. This makes it highly suitable for real-time control and high-priority message transmission.
• Modbus employs a master-slave model, where only the master device can initiate communication, which may introduce delays in large-scale networks.

3.2 Rate and Distance

CAN has a maximum rate of 1 Mbps, but this applies only to short-distance communication (less than 40 meters). For longer distances, the rate must be reduced. On the other hand, Modbus typically operates at a lower rate than CAN, but it can work over longer distances, especially when using the RS485 interface.

3.3 Data Transmission Methods

• The CAN protocol utilizes a bus communication method where multiple devices share the same bus, enabling real-time data transfer and multi-master control.
• The Modbus protocol supports serial lines (such as RS232 or RS485) and Ethernet, facilitating data exchange through the master-slave communication approach.

3.4 Data Types and Formats

• CAN supports various data types for transmission, including bits, integers, floating-point numbers, and strings. Data is transmitted in frames, which include identifier, data, and checksum fields.
• Modbus defines different data types such as coils, discrete inputs, holding registers, and input registers. Data is read and written using discrete register or coil addresses.

3.5 Network Topology

• The CAN protocol is suitable for complex network topologies, supporting parallel connections of multiple devices on the bus, enabling distributed control and data sharing.
• Modbus typically adopts a master-slave structure where one master device connects to multiple slave devices, making it suitable for smaller-scale control systems.

3.6 Real-time Performance and Reliability

CAN protocol exhibits high real-time performance and reliability, making it suitable for applications requiring real-time responsiveness and resistance to interference, such as automotive and industrial control. Modbus, on the other hand, has relatively lower real-time capabilities and is more suitable for simpler data acquisition and control tasks.

3.7 Application Areas

CAN was initially developed for automotive applications but is now widely used in other embedded control systems, including industrial automation, medical devices, aerospace, and more. It is particularly well-suited for complex real-time control systems and large-scale data communication. Modbus, on the other hand, is predominantly used in industrial control systems such as PLCs and industrial automation devices, catering to simpler data acquisition and device control needs.

4.Conclusion

CAN and Modbus, as common communication protocols, possess their respective advantages and characteristics in different application scenarios. The CAN protocol is well-suited for control systems that demand high real-time performance, reliability, and complex network topologies, such as automotive electronics and industrial control. It features multi-master control, high-speed communication, and robust resistance to interference, enabling it to function effectively in noisy and redundant environments.

On the other hand, the Modbus protocol is more suitable for simple data acquisition, monitoring, and device control tasks, finding applications in fields like building automation, energy monitoring, and environmental sensing. It boasts simplicity and widespread support, allowing communication via serial lines or Ethernet, making it convenient for various environments.

In summary, the choice between CAN and Modbus depends on specific application requirements. If high real-time performance, complex control, and large-scale data communication are needed, the CAN protocol presents a favorable option. For simple data acquisition, device control tasks, and a more straightforward communication approach, the Modbus protocol is better suited. According to project requirements and system specifications, it is important to consider various factors and choose the appropriate communication protocol to achieve optimal system performance and functionality.