summary:
This paper first analyzes the CANopen device model and CANopen application system based on the CANopen high-level protocol, and describes a CANopen system based on HMI. Finally, it demonstrates the human-machine interface (HMI) access of CANopen devices through the CAN driver configuration software. Focusing on the HMI, the paper describes the data acquisition model of fieldbus devices in the HMI system, analyzes the CANopen protocol content relevant to the HMI system, elaborates on the application of devices conforming to the CANopen communication protocol on the fieldbus, and provides specific application models.
1. System Overview
Configuration software is built upon various standards in the field of industrial automation. For a detailed architecture, please see Figure 1.1 .
HMI (Human Machine Interface) systems have become a core application in industrial settings. They integrate hardware and software and conform to industry standards.
Through the configuration software driver interface, the configuration software collects data from fieldbus devices, transfers the field data to the configuration software real-time database, displays the data information through standard controls, completes historical storage through the standard disk interface, and performs other functions such as alarms, logic, and user management. Finally, through the real-time database and configuration driver interface, it can also realize the control of PLCs, smart meters, and other bus devices in the bus system.
In the system, fieldbus devices are the source of information, connecting and acquiring sensor signals, and participating in the control execution unit. For example, through the input section, analog input (AI) and digital input (DI) signals such as temperature, humidity, and altitude are acquired; through the calculation and control section, calculations and logic control such as data conversion and alarm judgment are realized; finally, through the output section, the control results are executed through analog output (AO) and digital output (DO) of voltage and current.
Figure 1.2 vividly illustrates the internal structure of a fieldbus device. The internal structure of equipment in the field of industrial automation follows predictable patterns and can be standardized, providing factual evidence and assurance for the standardization of fieldbus higher-level protocol device models.
2. CANopen devices
2.1 . CANopen Protocol
Figure 2.1 [1] Relationship diagram of CAN and CANopen standards in the OSI network model
The CANopen protocol is one of the standards defined by the CiA (CAN-in-Automation) organization. The CANopen protocol has gained widespread acceptance and has become the dominant standard for CAN bus in the field of industrial automation.
Based on the OSI communication model, the CAN bus protocol only defines the physical layer and data link layer standards, while the CANopen protocol is an application layer protocol based on the CAN2.0A protocol.
Figure 2.1 clearly shows the relationship between the CANopen protocol and the CAN protocol. In other words, the CAN protocol is embedded in the CAN controller chip; for example, if we choose the Philips SJA1000 CAN controller, the CAN standard protocol is already instantiated or embedded in the controller. The CANopen protocol, on the other hand, is an application layer protocol, meaning it needs to be implemented in software programming.
Therefore, the CANopen protocol also reflects the mapping relationship or device profile description of bus devices in application software.
2.2 . CANopen Device Model
The role of a fieldbus is to transmit information from near-execution-level bus devices to the management-level master system of the bus system. The CAN protocol enables the CAN bus to support multi-master communication, allowing upper-level systems to obtain information from bus devices in more ways. Based on the CAN2.0A protocol, the CANopen protocol defines the bus device model in industrial automation, clarifies the management of the bus network, defines various information objects within the bus devices, and specifies the concrete methods for device configuration.
According to the requirements of the automated field, CANopen devices are connected to signal I/O at the bottom to collect field data, and connected to the CAN bus at the top to transmit device information to higher levels. The CANopen protocol defines the application software, object dictionary, and CAN-bus communication for bus devices, as illustrated in Figure 2.2 .
Figure 2.2 [1] Relationship diagram of application software, object dictionary and communication part in CANopen device model
Communication Interface:
It provides services for sending and receiving data messages on the CAN bus. Four types of CANopen data messages are defined: Administrative messages (including LMT, NMT, and DBT service messages), SDOs (Service Data Objects: device configuration related, low-priority messages), PDOs (Process Data Objects: 8-byte data fast transmission messages), and special messages (Predefined messages or Special Function Objects: including SYNC, TimeStamp, etc.). Communication between devices is accomplished by exchanging communication objects.
CANopenObjectDirectory (object dictionary):
The object dictionary describes various parameters and network performance of the device, and describes the message objects (Process Data Objects, PDOs, or Configuration Service Data Objects, SDOs) contained in the bus device in a specific way, thus realizing the functional description of the device. These objects are accessed through a 16-bit index and an additional 8-bit sub-index. The object dictionary is located between the communication part and the application part of the CAN bus device, providing an interface to the application program. The application program can realize CANopen communication by manipulating the object dictionary.
Application:
The application program, written or configured by the user, includes both functional and communication components. The communication component implements CANopen communication by manipulating an object dictionary, while the functional components are implemented by the user according to application requirements. For example, in a CAN controller, the application program consists of process control or data processing logic, which needs to be written by the user.
All CANopen devices provided by various manufacturers must comply with the protocol standard. When we search for the information or technical manuals provided by the device manufacturers, we can find descriptions of bus devices similar to those from Beckhoff (see Figure 2.3 ).
Figure 2.3 [1] Description of Beckhoff's CANopen device
2.3 . CANopen System Applications
The CANopen protocol application can be divided into the following two levels:
At the operational application level: On-site operators and equipment inspectors should pay attention to controllability, ease of operation, and operational efficiency.
Objective: Monitoring and control of production operations. Features: Focus on CANopen protocol related content.
At the system setup level: This focuses on system integration technicians, equipment maintenance and modification personnel, etc., to implement the application system through the best solution.
Objective: Engineering implementation and system integration. Key feature: Focus on the CANopen protocol as a whole.
From an operational application perspective, technical operators primarily utilize the established production line and the CANopen system to complete predetermined production tasks. This involves viewing and analyzing the collected signals, focusing on the production operations performed by the equipment. In other words, operators concentrate on successfully completing production tasks through correct operating methods. This level of user is the end-user of the human-machine interface system. The design of industrial human-machine interface systems must consider the needs of this application level.
As shown in Figure 2.4 , in a fieldbus system, the human-machine interface (HMI) is often the part that represents the operation and application level.
From a system setup perspective, technicians are responsible for assembling, configuring, and even programming field equipment. They can perform this assembly and configuration based on the equipment's documentation and the specific needs of the field project. Generally, each type of equipment has testing or configuration software, especially logic control equipment, which typically includes programming software, such as PLCs and CANopen devices. Firstly, these software programs are already very mature. Secondly, programming and communication often involve many closed technologies, so we must rely on the software provided by the equipment manufacturer. The work of technicians at this level typically involves configuring equipment and integrating systems based on specific I/O components and clear process requirements, focusing on the system integration aspect—that is, integrating systems according to the specific needs of the operational application layer.
As shown in Figure 2.4 , in a fieldbus system, encoding and debugging equipment and software are often reflected at the system settings level.
For the configuration of the human-machine interface (HMI), we mainly consider the needs of the operational application layer, namely, focusing on I/O status, control-related parameter settings, and recording of operating results. These provide the basis for the implementation of the protocol communication mode of the HMI-based fieldbus control platform.
The data objects that HMI configuration focuses on are mainly process data objects (PDOs) used to transfer process data between CANopen nodes , such as reading and setting the I/O status of I/O modules, analog signal acquisition and analog signal output, etc.
Node --> HMI Platform (TxPDO: Transmission Process Data Object)
Node <-- HMI Platform (RxPDO: Receive Process Data Object)
The data objects that the system configuration focuses on are mainly Service Data Objects (SDOs). The service is used to read and write the node's object dictionary, which is used to transfer large, low-priority data between devices, and to perform operations such as downloading/uploading, requesting/responding, segmenting/accelerating transmission, etc. It is also used to configure devices on the CANopen network.
Other data objects, such as management messages, predefined messages, and special messages, are generally used during system configuration. However, depending on the control process, these data objects are used less frequently at the operational application level.
2.4 . CANopen Identifiers and Data Objects
To reduce the configuration workload of simple networks, CANopen defines a mandatory default identifier (CAN-ID) allocation table. These identifiers are available in the pre-operational state and can be modified through dynamic allocation. CANopen devices must provide the appropriate identifiers to the communication objects they support.
The default ID allocation table is based on the 11-bit CAN-ID, which includes a 4-bit function code part and a 7-bit node ID part, as shown in Figure 4.
Figure 2.5 [1] Predefined format of 11-bit ID for PDO data objects
Node-ID: Corresponds to CANopen devices and is defined by the system integrator, for example, by setting it via a DIP switch on the device. The Node-ID range is 1~127 (0 is not allowed).
FunctionCode: Determines the type of CAN frame. For example, PDO and SDO correspond to registers in CANopen devices. In CANopen devices, the commonly used PDO is 0x180 + Node-ID. Here, 0x180 refers to the FunctionCode. SDO is a service data object used to transmit large, low-priority data between devices; its typical function is to configure devices on a CANopen network.
For example, PDOs are used to transmit 8 bytes or less of data, without any other protocol pre-defined (meaning the data content is predefined). For instance, a tilt sensor uploads 7 characters, therefore it needs to transmit 8 PDO data entries to the fieldbus. The identifier format is TPDO=0x180+NODE_ID, so the transmitted PDOs can be represented as described in Table 3.1 .
Table 3.1 PDO of CANopen devices
3. Configuration software communication
3.1 . PC-based CAN bus access
The CAN bus system, consisting of configuration software and hardware devices, is shown in Figure 3.1 for detailed composition.
Figure 3.1 CAN bus system
3.2 . Description of the CANopen system based on HMI
1) Simple system: HMI + CANopen module.
HMI products can be directly connected to CAN slave modules, as shown in Figure 3.2 . CAN slave modules are primarily I/O modules, capable of acquiring analog I/O data or controlling digital I/O, and can be expanded via a bus. For example, the HMI device HMITECHTPC-CAN with a CAN interface can directly connect to the Finnish Axiomatic single-axis and dual-axis tilt sensors.
HMI products can also be directly connected to a CAN master module, as shown in Figure 3.3 . The CAN master module can be a programmable controller with fieldbus communication, which can be expanded with direct I/O modules or connected to a control bus expansion module. For example, HMITECHTPC-CAN connects to the EPEC2020 control module.
2) Complex system: HMI system + CANopen station module + diagnostic and configuration node.
The HMI primarily performs monitoring, storage, and analysis functions for the CANopen system. The advantage of a human-machine interface (HMI) is its user-friendly interaction. Therefore, the HMI's focus in a CAN system is on aspects related to HMI interaction, such as CAN system information display, bus data storage, and preliminary data analysis.
The CAN master controller prioritizes real-time performance, while the HMI system emphasizes user-friendly display and data storage. Although some of the logic from the CAN master controller can be transferred to the HMI system, we still recommend that customers carefully consider and configure the system appropriately based on the requirements of their control process.
4. CAN driver configuration software
4.1 . CAN driver specific configuration software
Figure 4.1 CAN driver configuration software
The CAN driver program of the configuration software, as shown in Figure 4.1 , serves as the interface between the human-machine interface and the configuration software. Its functions and features are as follows:
The interface for transmitting CAN bus data to the configuration software:
The driver needs to use the system's device driver interface to read CAN bus data and transmit it to the configuration software's real-time database in a standard format.
Successful data transmission and reception can be ensured in several ways:
1) Internally, the driver checks for errors sent by the CAN controller;
2) Write to the device register, and then read to determine whether the register write was successful.
Focus on the application level of the CANopen protocol operation:
The driver does not need to integrate the entire CANopen protocol stack; supporting the CAN2.0 protocol is sufficient. The CANopen protocol portion is then handled through configuration logic.
Data integrity and real-time performance can be ensured in several ways:
Real-time performance means that the latest transmitted bus data can enter the real-time database of the configuration software within a specified delay. Integrity means that all data packets can be captured by the configuration software and fully processed and stored. Depending on the control process requirements, we can set the frequency of bus data transmission, reduce non-target data by configuring the CAN controller embedded in the HMI, and also adjust the data transmission and reception performance of the CAN controller and drive buffer through the configuration software.
