Abstract: This paper first analyzes the CANopen device model and CANopen application system based on the CANopen high-level protocol, and describes the CANopen system based on HMI. Finally, it realizes the human-machine interface access of CANopen devices through the CAN driver configuration software. The paper focuses on the human-machine interface, describes the fieldbus device data acquisition model of the HMI system, analyzes the CANopen protocol content that the HMI system focuses on, elaborates on the application of devices conforming to the CANopen communication protocol on the fieldbus, and provides a specific application model. Keywords: HMI (Human Machine Interface); HMIBuilder; Configuration software; CANopen. 1. System Overview Configuration software is built upon various standards in the field of industrial automation. The detailed architecture is shown in Figure 1.1. HMI (Human Machine Interface) systems have become a core application in industrial fields. They are hardware and software integrated and conform to industrial standards. Through the configuration software driver interface, the configuration software collects data from fieldbus devices, transfers the field data to the configuration software's real-time database, displays the data information through standard controls, completes historical storage through a 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 control PLCs, smart meters, and other bus devices in the bus system. In the system, fieldbus devices are the source of information, connecting to and collecting sensor signals, and participating in control execution units. For example, through the input section, they collect analog input (AI) and digital input (DI) signals such as temperature, humidity, and altitude; through the calculation and control section, they realize data conversion, alarm judgment, and other calculations and logic control; finally, through the output section, they execute the control results through analog output (AO) and digital output (DO) of voltage and current. Figure 1.2 vividly illustrates the internal structure of fieldbus devices. The internal structure of equipment in the field of industrial automation follows certain rules and can be standardized, providing factual basis and guarantee for the standardization of fieldbus high-level protocol device models. 2. CANopen device 2.1. CANopen protocol Figure 2.1 [1] Relationship diagram of CAN and CANopen standards in OSI network model CANopen protocol is one of the standards defined by CiA (CAN-in-Automation) organization. CANopen protocol has been widely recognized and has become the dominant standard of 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. Through Figure 2.1, we can clearly see the relationship between CANopen protocol and CAN protocol. It can also be said that the CAN protocol is solidified in the CAN controller chip. For example, if we choose Philips SJA1000CAN controller, the CAN standard protocol has been instantiated or solidified in the controller; the CANopen protocol is an application layer protocol, which means that we need to implement it 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 the fieldbus is to send the information of the bus device close to the execution layer to the master station system of the bus system management layer. The CAN protocol determines that the CAN bus supports multi-master communication, enabling 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 the field of industrial automation, clarifies the management of the bus network, defines various information objects within the bus devices, and specifies the specific methods for device setup. According to the requirements of the automation field, CANopen devices connect to signal I/O to collect field data and connect to the CAN bus 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: 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), SDO (Service Data Object: device configuration related, low priority message), PDO (Process Data Object: 8-byte data fast transmission message) and special messages (Predefined messages or Special Function Objects: including SYNC, Time Stamp and other messages). Communication between devices is accomplished by exchanging communication objects. " CANopen Object Directory: The object dictionary describes the various parameters of the device and its network performance, and describes the message objects (process data objects PDO or configuration service data objects SDO) contained in the bus device in a specific way, thereby 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 operating on the object dictionary. Application: The application part is written or configured by the user, including the functional part and the communication part. The communication part implements CANopen communication by operating on the object dictionary, while the functional part is implemented by the user according to the application requirements. For example, in a CAN controller, the application part is the process control or data processing logic, which needs to be written by the user. CANopen devices provided by various manufacturers must comply with the protocol standard. When we look for the materials 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 Beckhoff CANopen device description 2.3. CANopen System Application The application of the CANopen protocol can be divided into the following two levels: Operational Application Level: This level focuses on field operators, field equipment inspectors, etc., and emphasizes controllability, ease of operation, and operational efficiency. Objective: Monitoring and control, production operation. Characteristics: Focus on the relevant content of the CANopen protocol. "System Setup Level: This level focuses on system integration technicians, equipment maintenance and modification personnel, aiming to achieve the best application system solution. Objectives: Project implementation and system integration. Characteristics: Focus on the overall CA Nopen protocol. From an operational application level perspective, technical operators primarily rely on 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 focus on successfully completing production tasks through correct operating methods. Users at this level are the end users of the HMI system. The design of industrial HMI systems must consider the needs of this application level. As shown in Figure 2.4, in a fieldbus system, the HMI portion often represents the operational application level." From a system setup perspective, technicians are responsible for assembling, configuring, and even programming field devices. 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 devices, which typically have programming software, such as PLCs and CANopen devices. Firstly, these software programs are already very mature. Secondly, programming communication often involves many closed technologies, so we must rely on the software provided by the equipment manufacturer. Technicians at this level typically focus on specific I/O components, configuring equipment and integrating systems according to clear process requirements, paying particular attention to system integration—that is, integrating systems based on the specific needs of the operational application layer. As shown in Figure 2.4, in a fieldbus system, coding and debugging equipment and software often represent the system setup level. For HMI configuration, we mainly consider the needs of the operational application layer, 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. HMI configuration focuses primarily on process data objects (PDOs) used for transmitting 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. Node → HMI Platform (TxPDO: Sending Process Data Object) Node < HMI Platform (RxPDO: Receiving Process Data Object) System configuration focuses primarily on service data objects (SDOs). Services are used to read and write the node's object dictionary to transmit large, low-priority data between devices, enabling operations such as downloading/uploading, requesting/responding, segmenting/accelerating transmission, and configuring 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. 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-operation state and can be modified through dynamic allocation. CANopen devices must provide the corresponding identifiers to the communication objects they support. The default ID allocation table is based on an 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 via a DIP switch on the device. The Node-ID range is 1 to 127 (0 is not allowed). Function Code: Determines the type of CAN frame, such as: PDO and SDO: Corresponds to the registers of the CANopen device. In CANopen devices, the commonly used PDO is 0x180 + Node-ID. Where 0x180 refers to the Function Code. SDO is a service data object used to transmit large, low-priority data between devices, and its typical function is to configure devices on the CANopen network. For example, PDO is used to transmit 8 bytes or less of data, without any other protocol pre-sets (meaning the data content is predefined). For example, a tilt sensor uploads 7 characters, so it has 8 PDO data to transmit to the fieldbus. The identifier format is TPDO=0X180+NODE_ID, so the transmitted PDO 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 composed of configuration software and hardware devices is shown in Figure 3.1 for details. Figure 3.1 CAN bus system 3.2. Description of 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 mainly I/O modules, which can collect analog I/O data or control digital I/O, and expand through the bus. For example, HMITECH HMI devices with CAN interfaces. TPC-CAN directly connects to Finnish Axiomatic single-axis and dual-axis tilt sensors. HMI products can also directly connect to the CAN master module, as shown in Figure 3.3. The CAN master module can be a programmable controller with fieldbus communication, expandable with direct I/O modules, or connected to a control bus expansion module. For example, HMITECH TPC-CAN connects to the EPEC 20 20 control module. 2) Complex systems: HMI system + CANopen station module + diagnostic and configuration nodes. The HMI mainly performs CANopen system monitoring, storage, and analysis functions. The advantage of the HMI is its user-friendly interaction. Therefore, CAN system information display, bus data storage, and preliminary data analysis related to human-machine interaction are the focus of the HMI in the CAN system. The CAN master controller emphasizes real-time performance, while the HMI system emphasizes user-friendly display and data storage. Although the logic of the CAN master controller can be partially transferred to the HMI system, we still recommend that customers carefully consider and reasonably configure the system according to the requirements of the control process. 4. Configuration software CAN driver 4.1. Configuration software CAN driver specific Figure 4.1 The CAN driver for the configuration software, as shown in Figure 4.1, serves as the interface between the human-machine interface (HMI) and the configuration software. Its functions and characteristics include: • CAN bus data transmission interface to the configuration software: The driver uses the system's device driver interface to read CAN bus data and transmits it to the configuration software's real-time database in the standard format. • Successful data transmission and reception can be ensured through various means: 1) Internally, the driver checks for CAN controller transmission errors; 2) By writing to the device register and then checking if the register write was successful. • Focus on the CANopen protocol operation application layer: The driver does not need to integrate the entire CANopen protocol stack; supporting the CAN 2.0 protocol is sufficient. The CANopen protocol portion is handled through configuration logic. • Data integrity and real-time performance can be guaranteed through various means. 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 processed and stored completely. According to the requirements of the control process, we can set the frequency of bus data transmission, reduce non-target data by setting the shielding of the CAN controller embedded in the HMI, and also improve the data transmission and reception performance of the CAN controller and drive buffer through the configuration software. 4.2. HMIBuilder Software CAN Driver Mapping Relationship 4.2.1. HMIBuilder Configuration Software HMIBuilder configuration software is a distributed configuration software launched by Beijing Kunlun Zongheng Technology Development Co., Ltd. Fieldbus is one of the key focuses of HMIBuilder software. 4.2.2. HMIBuilder Device Station Parameters Corresponding to a Port of PCI1680U For Advantech PCI-1680U boards, in the device station parameter settings, the port and device number can be selected (see Figure 4.2), and the baud rate can be set. For example, Port1, device number 0, baud rate: 250K. These correspond to Advantech Device... The HardwareSetting in Magnager (see Figure 4.3) corresponds to the further settings for the CAN card in the CanMEx.exe test program (see Figure 4.4). CanMEx.exe is located in the directory after installing the Advantech Demo, such as C:\Program Files\Advantech\CAN\CAN Examples\Examples\VC\CanMEx. Figure 4.2 Station Parameter Selection; Figure 4.3 HardwareSetting; Figure 4.4 CanMEx 4.2.3. The data field of the HMIBuilder analog CANopen frame is shown in Figure 4.5, where the Message content is decoded in ASCII code form. The method for setting the point parameters corresponding to PCI1680U in HMIBuilder is shown in Figure 4.5. Here, ID can be the PDO of the CANopen device. To read the first byte of data in the PDO data field, the setting is as follows: 416:0:U8:R. That is, 416 represents the device ID, 0 represents the offset, and U8- represents an 8-bit unsigned integer. In other words, the starting offset is the offset of the data field by byte, with a value from 0 to 7. If using F32 data type, the starting offset is 0 or 1. Figure 4.5 Point Parameter Settings Note: The decoding methods of this driver include 8-bit unsigned data, 8-bit signed integer, 16-bit unsigned integer, signed integer, 16-bit BCD integer, 32-bit unsigned integer, 32-bit signed integer, 32-bit BCD integer, and 32-bit floating-point number. 5. Application Example Below, we will demonstrate the HMI (Human Machine Interface) integration of the CANopen module for the Axiomatic MVINC-CO-x-range tilt sensor from Finland. 1. Physical Connection Preparation: First, correctly connect the wiring to the Advantech PCI-1680U board; then test using Advantech's included testing software. If communication is successfully tested, proceed to the next step: connect the next-level device with CAN communication. Here, we test the Axiomatic MVINC-CO-x-range tilt sensor. 2. Tilt Sensor Analysis: By reading the sensor's technical documentation, our goal is to control the tilt sensor's start and stop using configuration software, while simultaneously acquiring the sensor's tilt information. Module start and stop can be achieved using NMT commands. The module's tilt information is periodically uploaded via TPDO1 data objects. We also know that object dictionaries can be configured via SDO, and module Node-ID and baud rate can be set via Layer Setting Service (LSS), but these are not the focus of this article; that is, these are not the operational application level's concern, but rather the system settings level. 3. HMIBuilder station parameter configuration settings for a station, select driver. As follows: Figure 5.1 Station parameter settings configuration protocol, parameter settings are as follows: Use the first port of the PCI-1680U board to receive data, so select Port1 in the device, select the first device in the device number, select 250k baud rate (the same as the sensor baud rate), and the mask code is 255. Figure 5.2 Communication settings 4. NMT object configuration of tilt sensor Table 5.1 [3] Network Management Object (NMT) data message format CAN-ID If it is 0X00, it means that all nodes on the bus execute the relevant command operation. The command classification is as follows: Table 5.2 [3] CAN module command In HMIBuilder data configuration, we set the two analog parameters to start the CAN module as shown in the figure. The ID is required to be 0, the offset address is continuous, and they are 0 and 1 respectively. Figure 5.3 Analog parameter settings Note: Address is 0, offset is 0 Figure 5.4 Address has no offset Address is 0, offset is 1. Figure 5.5 Address offset by one bit 5. By examining the relevant technical documents of the tilt sensor, we can view the data object dictionary defined by the device and determine the content of the data field of the data message. For example, for the MVINC-CO-2-180 module, the CAN data message sends 7 bytes of data, and the data is defined as follows: Sub1 is the latitude angle, 16 bits; Sub2 is the longitude angle, 16 bits; Sub3 is the temperature, 8 bits; Sub4 is the auxiliary input, 16 bits; Table 5.3 [3] Data dictionary content of the TPDO1 object of the MVINC-CO-2-180 module The format of the data uploaded by the tilt sensor: Table 5.4 Data message of the TPDO1 object If we read the 7 analog parameters of the CAN module, we need to make the following settings in the configuration software: Figure 5.6 Analog parameter setting Address setting is as follows: Figure 5.7 Data collected Figure 5.7 Address setting offset 0. Corresponding D0: 416:0:U8:R Figure 5.8 Address setting offset 1 corresponds to D1: 416:1:U8:R Note: The data read is 7 bits, and the ID remains unchanged. Set the offset to 0…6 6. HMIBuilder configuration complete configuration startup screen Figure 5.9 Startup screen running status: Figure 5.10 Running result 6. Conclusion Through the CAN bus communication settings of the HMIBuilder configuration software, the acquisition of tilt sensor data was realized. Furthermore, we can see that in the HMI system, we mainly focus on the PDO part of the CANopen protocol data object. At the same time, other data objects can also be implemented in the configuration software according to the requirements of the field process. 7. References [1] CANopenn: high-level protocol for CAN-bus, H.Boterenbrood, NIKHEF, Amsterdam, March 20, 2000 [2] "HMIBuilder Function Manual" Beijing Kunlun Zongheng Technology Development Technology Co., Ltd. [3] MVINC-CO-X_user_manual_2_08,Author:JKA,Modified:25.07.2007 14:28