Abstract : With the development of industrial automation, the design and development of PLC drivers has become a frequently encountered problem. Channel utilization and data acquisition efficiency directly affect the performance of the entire monitoring system. This paper discusses the methods for designing and developing PLC drivers; details the design and implementation of PLC low-level driver functions; and explores several key issues for improving channel utilization. Experiments show that this can reduce development costs and significantly improve the efficiency of data communication and channel utilization between the computer monitoring system and the PLC. 1 Introduction With the rapid development of new technologies in computer science and technology, industrial control, etc., the use of computer monitoring systems to exchange data with field PLC devices has become widely applied. This type of data exchange often has the following characteristics: large data volume, scattered acquisition points, and narrow bandwidth. Because the communication mechanisms of PLC field devices provided by different manufacturers are not the same, the number of device communication drivers that need to be developed for computer monitoring system software is increasing. The development of such complex device drivers has the following characteristics: First, data exchange between the upper-level monitoring system and PLC devices is widely used. Second, this data communication process lacks a universal framework design, has a long development cycle, is difficult, and is hard to generalize. Furthermore, large-volume data transmission under limited bandwidth conditions generally suffers from low channel utilization, poor system efficiency, and instability, urgently requiring algorithms to significantly improve channel utilization. Moreover, existing data exchange standards lack mature designs for channel utilization under limited bandwidth conditions. As mentioned above, developing a universal data communication interface for PLC devices has broad application prospects and practical value. This paper mainly analyzes the data communication between the upper-level monitoring system and the PLC device, introduces the method of PLC device driver development, and provides an example of PLC communication. 2. Use of PLC Drivers This paper uses a PLC using serial communication as an example for analysis and explanation. The monitoring system is MCGS monitoring software produced by Beijing Kunlun Tongtai Company. The development tool is VC++ 6.0. In MCGS, the PLC has integrated functions such as baud rate setting for serial communication into the serial port parent device. Therefore, the PLC device driver is provided as a sub-device in the MCGS monitoring software device management window. It can use the communication functions of the parent device, that is, it can share the communication functions of the parent device with other devices. Since many PLC devices use serial ports, we will use a PLC using serial communication as an example to illustrate the development of a general PLC driver architecture. This PLC driver architecture is also applicable if a custom programming cable or Ethernet connection is used. There are several communication methods between a PLC using serial communication and the host computer, including RS232, RS485, and RS422. If the device uses RS232 communication, only one device can be connected to a single serial port. If RS485 or RS422 communication is used, multiple devices can form a network. In this network, each device is assigned a unique identifier, generally called a device address. Devices on this bus are divided into master devices and slave devices. During operation, slave devices continuously listen to and analyze data on the communication line. When they receive a request, they send a corresponding response frame. When the master device is working, it sends request frames to the slave device as needed, requesting data or sending a command. After sending the request frame, the master device must wait for a response from the slave device. This waiting process has a timeout limit. If no response is received after a certain time, it considers the communication to have failed and then determines whether to resend the request or give up according to certain logic. The communication protocols used are divided into two categories: ASCII communication and hexadecimal communication. Most PLC communication protocols use hexadecimal communication. Moreover, in serial communication, in order to ensure the correctness and integrity of the communication, checksums are usually added to the end of the communication frame. Common checksums include AND checksum, XOR checksum, CRC checksum, etc. During the communication process, the MCGS monitoring software of the host computer calls the PLC driver, sends register read and write commands to the PLC device according to the specific protocol, and receives response data. 3 Main Process 3.1 Acquisition Process For ease of explanation, this section takes the simplest case where only a single acquisition is required within one acquisition cycle as an example. The algorithm for multiple acquisitions within one cycle is described in the dense acquisition mode in section 5.1. The acquisition process is described as follows: First, initialization is performed, followed by channel creation. Entering the data acquisition cycle, a read command is generated first, then the sent data frame is verified. Reading and writing to the serial port completes one communication cycle. If communication is successful, the received data is decoded and output to the channel after verification, returning a success flag. If communication fails or verification fails, a failure flag is returned. 3.2 Parsing Function Flowchart The above diagram shows the flowchart for parsing data frames. Different devices have different protocol content. Using a predefined template parsing function, developers only need to divide the frame into valid data parts according to the device protocol and add them to the FrameField union. This union can divide the protocol data into bits for operation. As shown in the diagram, the first byte is the frame header, the last byte is the frame tail, the second byte is the status indicator, the third to sixth bytes are analog quantities, the seventh byte is the unit, and the eighth byte is divided into four input channels and four output channels. 4 Interface Design Generally speaking, PLC products from the same manufacturer in the same series usually have the same communication protocol. The difference lies only in the size of some registers. Therefore, we consider allowing devices in this series to use the same driver. To improve versatility, and considering that users generally don't need to use all registers, the channels of this device component are designed so that users can define them during configuration. All channels and their corresponding parameters (i.e., register addresses) are defined by the user. The driver communicates based on the user-defined information. Furthermore, some parameters in the PLC may not be frequently used by the user; if these were combined into channels, communication would be required for every acquisition cycle, resulting in low efficiency. To address this, we provide external interfaces for the monitoring system to call, allowing commands to be sent and supporting all register channels. Analysis of PLC devices from different manufacturers also reveals that the communication process and protocol can be abstracted, extracting their commonalities and variations, encapsulating and hiding the details of the data exchange process to achieve universality. By encapsulating formats, standardizing code, and unifying interfaces, driver development efficiency is improved, and the difficulty of driver development is reduced. Code reusability is improved, driver stability is enhanced, and design errors are reduced. This allows developers to focus their main efforts on familiarizing themselves with the device and analyzing the protocol, rather than getting bogged down in the minutiae of programming implementation. The encapsulated data and operations include: hiding the underlying communication process in a single data acquisition (some devices require more than one transmit and receive process to complete one acquisition, such as Siemens S7200); encapsulating dynamic acquisition algorithms for scattered acquisition points; encapsulating commonly used command operations; providing a unified interface for interaction with the monitoring system; the PLC driver encapsulates the underlying communication process, exposing only the interface methods, allowing developers to call these methods in a unified way, thus ensuring the software's transparency to customers, freeing developers from low-level development, and reducing development difficulty. For driver developers, the interfaces they need to focus on are only the following: defining the device's own attributes; such as address, real-time acquisition time requirements, etc.; defining the device's read and write operation attributes; such as the number of channels, etc.; the general design only provides packet assembly and unpacking interfaces related to the device protocol, and the implementation process will be completed by the developers. 5 Key Issues Analysis To improve channel utilization and system efficiency, several key issues were considered in the PLC communication framework design. 5.1 Three Acquisition Modes Based on the analysis of existing data exchange, the general needs of users can be summarized into three acquisition modes: intensive acquisition, on-demand acquisition, and scheduled acquisition. Intensive Acquisition Mode: In this mode, users want to utilize physical bandwidth as much as possible to ensure the fastest acquisition speed and updates. Ideally, the device should always be in acquisition mode. Acquisition should focus on the channel with the shortest time remaining before the required acquisition cycle among all currently active channels. This ensures that all channels have acquisition opportunities, but compared to other modes, CPU utilization will be higher. On-Demand Acquisition Mode: When communication links need to be controlled, such as when users use GPRS for acquisition and are billed by traffic, extensive communication cannot be performed. In this case, the acquisition mode is set to on-demand acquisition, and a single acquisition is initiated by calling the interface function when needed. Otherwise, no data acquisition is performed. Scheduled Acquisition Mode: This mode is a compromise between CPU utilization and acquisition speed. It ensures that channel acquisition occurs within the user-defined channel refresh cycle, and then continues until the next channel refresh cycle arrives before the next acquisition occurs. In module design, the acquisition mode is an attribute of the device class, and developers select the appropriate acquisition mode based on specific circumstances. The acquisition algorithms for different acquisition modes are implemented as follows: **Intensive Acquisition Execution Flow:** Set an acquisition cycle, such as 1000ms. At the start of each new acquisition cycle, recalculate the priority of the acquisition channels. Iterate through all channels, find the channel with the highest priority, and acquire it. Divide the channels into blocks (each block contains the channel most in need of updating). Enter the communication loop (some devices require at least two communications for one acquisition, hence the need for a communication loop). Send a data request and wait for a response; parse the results based on the returned information and process them accordingly; determine if another acquisition is needed; if not, exit the loop; update the channel and acquisition flag; continue sending thread messages to start the next acquisition until one communication loop ends; until all channels requiring acquisition have been traversed. **On-Demand Acquisition Execution Flow:** Loop through each channel, save successfully acquired values, and perform subsequent processing. **Timed Acquisition Execution Flow:** Triggered by a timer, the acquisition process is the same as intensive acquisition, but channels that do not meet the acquisition requirements are not acquired. 5.2 Dynamic Acquisition Algorithm for Dispersed Acquisition Points In the existing data exchange process, the data that users care about often only accounts for a small part of the total information, and these acquisition points are scattered in massive amounts of data. If data is read sequentially without judgment, the ratio of effective information to acquired information is very low, and the real-time performance is poor. If only effective information is acquired, the allocated acquisition granularity is too small, which will cause the system efficiency to be low and the channel utilization rate to be poor. To address this problem, the following solutions are adopted: (1) Only acquire the data that users care about. For example, when there are multiple channels, only transmit the data of the channel that the current user cares about, and do not care about other channels. Ensure that as few channels as possible are acquired, and provide a faster acquisition cycle for each channel that needs to be acquired. This reduces the amount of communication. (2) Assign different priorities to the data to be acquired, and prioritize the acquisition of data with high real-time requirements. The priority can be changed according to the data refresh time set by the user. (3) Implement a dynamic block-segmentation algorithm to transmit the collected information in blocks at a reasonable granularity, taking into account both channel utilization and the real-time acquisition of effective information; the implemented block-segmentation algorithm is briefly described as follows: During acquisition, if the active channels of the currently acquired register class can form a data request packet, then process it to increase the number of channels acquired at one time. According to the channel priority defined by the developers, find the channels with consecutive (or close) addresses near the highest priority channel address, and these channels form a channel block. Repeat the same process to continue to divide the remaining channels into blocks until the number of blocks formed is greater than a certain specified value, such as 20, or all channels of this register are allocated. (4) According to the characteristics of the communication protocol, try to include more requests when packaging data requests, thereby reducing the total number of requests. 6 Conclusion Based on the PLC general data interface in this paper, the developers have developed PLC drivers for multiple manufacturers, which have been applied in different projects. Developing PLC drivers based on this PLC general data interface shortens the development time and difficulty. The system in operation has stable communication, fast acquisition speed, good versatility, and high reliability. It ensures the smooth implementation of the project. The author's innovation lies in the design of a universal monitoring system and PLC communication interface, which can greatly shorten development time and difficulty, and improve communication stability and real-time performance, thus possessing high practical and economic value.