Abstract: This paper introduces monitoring configuration software and LonWorks network control technology, and proposes a configuration control method based on LonWorks network technology, giving its design ideas and implementation methods. Keywords: Configuration software; Fieldbus; LonWorks; Neuron chip; Network variables; Explicit messages 1 Introduction 1.1 Configuration Control Software Configuration control software is a configurable program that can implement various control functions. A predetermined control scheme can be achieved through configuration. Users can generate application systems suitable for their needs without writing code. These application system software are configuration software, which is developed by developers. This paper proposes a development method for configuration software based on LonWorks network control, and presents a configuration method based on LonWorks network technology, giving its design ideas and implementation methods. 1.2 LonWorks Network Control Method – Nodes Each control node on the LON network is called a LON node or LONWORKS intelligent device, which includes a Neuron chip, sensors and control devices, transceivers, and power supplies. The Neuron chip is the core component of the node, encompassing a complete communication protocol, the LonTalk protocol, ensuring reliable interoperability between nodes using a reliable communication standard. Because the Neuron chip can directly connect to the sensors and control devices it monitors, a single Neuron chip can transmit sensor or control device status, execute control algorithms, and exchange data with other Neuron chips. Using Neuron chips, developers can focus on designing and developing better applications without spending excessive time designing communication protocols, software, and hardware, thus reducing development workload and saving significant development time. LonWorks node programming is implemented using Neuron C; programs must be compiled and burned before being loaded into the node for execution; alternatively, some nodes can be compiled and directly downloaded for execution. Here, we introduce the concept of configuration into the configuration control software, providing rich control function modules pre-built for the control network. By changing the logical relationships between network nodes, the network control functions can be altered. 1.3 Advantages and Features of Introducing Configuration into LonWorks Control Networks ● Users do not need to program in Neuron C language; they only need to configure the network according to their actual needs. ● It can implement a wide range of functions, making it convenient for users to implement various control functions. ● LonWorks itself has a communication protocol, making networking convenient and flexible. 2. Configuration Control Based on LonWorks 2.1 Configuration Software Generation: Some configuration software refers to control function modules as "soft PLC" or "soft logic." The configuration control software programming tool uses a graphical programming language. A reusable control scheme can be created simply by "clicking and dragging" with the mouse, greatly reducing engineering time and manpower. An application can contain many control modules. Developers use Neuron C language to write general control programs. General control programs consist of many basic function modules, each of which can implement different control functions. Basic function modules have several inputs and outputs. Each input and output pin has a unique name, and the meaning and value range of each pin differ for different types of function blocks. The basic functional blocks of the control module include: a mathematical operation module (implementing basic operations such as addition, subtraction, multiplication, division, exponentiation, and root extraction); a logic operation module (implementing logical operations such as AND, OR, NOT, delay, and selection switching); a variable module (providing operands for operations and storing the final results); and commonly used control algorithm modules (such as PID control). When the configuration control software saves the program, it automatically compiles it, checks for syntax errors, and generates message packets of a specific format to be transmitted to the Neuron chip. These specific format data packets include: a comprehensive description of the control module (e.g., the total number of control modules, total number of parameters, total number of intermediate variables), a description of each module (e.g., the number of modules, number of parameters, intermediate variables), a parameter table for each module, a code table for each module, and a list of the storage order of intermediate variables for each module. The configured Neuron node communicates with the PC via explicit messages and receives module message packets. This node stores the execution module code corresponding to the basic functional modules. Mathematical modules, logic modules, variable modules, and control algorithm modules are written as separate functions, which can be called according to message packets generated by the configuration software. The execution results can be transmitted to the PC or other Neuron nodes. If the parameters of a functional block in the configuration change, the program is recompiled, and the latest generated module message packet is sent to the Neuron chip, ensuring that the latest functional block is always executed, achieving online compilation and control of the configuration. When receiving messages, the configuration Neuron node assigns the message data to different data structures defined by the node based on the message tag. A functional block can only be executed after all relevant messages generated by the configuration software have been received. Neuron nodes communicate with each other through network variables. A certain number of network variables are predefined in the configuration Neuron node, including both input and output types. The total number of these network variables does not exceed the total number of network variables allowed to be defined in the Neuron C language. The use of network variables greatly simplifies the development and installation of distributed systems. Each node can be independently defined, and then easily connected together or disconnected from certain connections to form new LONWORKS applications, significantly increasing the system's flexibility and openness. Network variables greatly improve the interoperability of node products by providing clear network interfaces between nodes. The benefits of interoperability are that nodes can be easily installed in different types of networks while maintaining the independence of the network configuration of node applications. Nodes can be installed in a network, and as long as the network variable data types match, they can logically establish connections with other nodes on the network. A network variable (NV) is an object of a node, which can be defined as either an input or output network variable. When a network variable is assigned a value in a node's application, the LonTalk protocol implicitly transmits the modified output network variable's new value as an implicit message to other nodes or PCs that can share data with it. Here, the network variable is actually an implicit message. Because the data length of each network variable is fixed and cannot be changed, and is at most 31 bytes, its scope of use is limited. Therefore, the explicit message data type provided by Neuron C can be used simultaneously. The length of an explicit message is variable, with a maximum of 228 bytes. Explicit messages must be constructed using a predefined object, and then processed using explicit functions and predefined events. Messages are received using the predefined event `msg_arrives`. In this design, the message-code determines which data structure the received message data `msg_in.data` should be stored in. The message-code includes header, stragehead, code, parameter, index, and run. Here, `head` is the control module header, `stragehead` is the control module description header, `code` is the receive code table, `parameter` is the receive parameter table, `index` is the receive index table, and `run` is the command to start the program execution. These messages correspond to the message packet format generated by the configuration software. The module is only executed after the configured Neuron node receives all module messages and the execution command `run`. 2.2 Example For implementing an addition operation (adder), its configuration function diagram is shown in the figure: Module 1 is the constant module in the variable module (input/output module); modules 2 and 3 are both network variable input modules in the variable module (input/output module); module 4 is the addition module in the mathematical operation module; and module 5 is the output module in the variable module (input/output module). To implement such an addition function, first draw the function configuration diagram shown in Figure 2 in the configuration tool, and then compile it to generate the required module code. If the module header file is: `Varsize 12 0 0 0 0 // Temporary storage units required for intermediate variables` `Stragenum 1 // Number of control modules` `Parasize 2 // Storage units required for parameters` `Codesize 20 // Storage units required for code` `Indexsize 24 // Storage units required for indexes` `Globalsize 0 // Storage units required for global variables` When the module is executed: 1) Execute module 1, retrieve parameter values ​​from the parameter table and place them into the intermediate variable table; 2) Execute module 2, place the corresponding input network variables into the intermediate variable table; 3) Execute module 3, place the corresponding input network variables into the intermediate variable table; 4) When executing module 4, retrieve the enable parameter, input 1 parameter, and input 2 parameter from the intermediate variable table, add the two operands, and place the result back into the intermediate variable table; 5) Execute module 5, assign the values ​​from the intermediate variable table to the corresponding output network variables. 2.3 Data Structure Ø Code Structure: Consists of 4 bytes, represented in hexadecimal. Ø Meaning of Code Structure: The first byte represents the category, i.e., one of the four modules (mathematical module, logic module, variable module, and control module); the second byte represents the kind, i.e., the specific function within a module; the third and fourth bytes represent the index. Ø Index Table Structure: Consists of two bytes; represented in hexadecimal in the program. Ø Meaning of the Index Table: I. Occupies two bytes. II. Consists of four parts from each functional block: A. The first part indicates that a functional block integrates several inputs and outputs, corresponding to pointer values ​​in the intermediate variable table. B. The second part represents the input network variables. In this design, input data is sent by message variables from message nodes, received by receiving nodes, transmitted through the network to another receiving node, converted into network variables, and then sent to the PTAG table for calculation. C. The third part represents the output network variables. The calculation result is placed in the PTAG intermediate variable table. During output, the result is retrieved from the intermediate variable table and sent to the output network variable on the receiving node (this node), i.e., the NEUM node. After being transmitted over the network, the data can be read from another node (i.e., the message node) via the connected input network variable. D. The fourth part represents constants. Their values ​​are retrieved from the parameter table, and the data in the parameter table is sent via messages. III. The order of each functional block and the order of the four parts within each functional block are determined by the configuration order. The format of the first part: The format of the second part (input network variable): The format of the third part (output network variable): The format of the fourth part (constant): Ø Structure of the intermediate variable table: The byte length is determined by the data type. The intermediate variable table's structure is determined by initialization. At this time, the intermediate network variable has only an empty structure and no data. Its data awaits input, which is accomplished by the variable module, the data retrieval function GET(), and the data setting function SET(). The variable module has three types: constants, network variable inputs, and network variable outputs. All three types of data are ultimately placed into the intermediate variable table. During input, if the data is constant, it is retrieved from the parameter table and placed into the intermediate variable table. The data in the parameter table is pre-sent by the message node and is read into the parameter table during the reading process. This is done by the READP() program. If the data is not constant, it is received via network variable input. The data is still sent by the message node, read using the GET() function, and then placed into the PTAG intermediate variable table by the SET() function for later use in calculations. During output, the data is retrieved from the intermediate variable table and placed into the output network variable for output. The node then transmits the data to the message node via the network, and the calculation result can be observed through the input network variable on the message node. It is particularly important to note that the byte length of the intermediate variable table is determined by the type of the constant data (only integer and floating-point types) and the data type of the network variable. Therefore, the length of the intermediate variable table differs for different modules, which is also reflected in the content of the index table. Ø Format of the intermediate variable (Ptag) table: (one module) Ø Format of the parameter table: (constants) To implement this addition function, first draw the configuration function diagram as shown above in the configuration tool, and then compile it to generate the required control module code. For example, the design code is: {0, 0, 0, 0, 0, 1, 0, 2, 0, 1, 0, 4, 1, 0, 0, 6, 0, 2, 0, 10}. The index table is designed as: {16, 0, 16, 0, 16, 0, 16, 3, 16, 1, 16, 6, 16, 0, 16, 3, 16, 6, 16, 9, 16, 9, 16, 0}. //16 is entirely related to the programming method of the data type generated in the program. 3 Conclusion There is broad development space for implementing configuration control based on LonWorks technology. Relying on the powerful Neuron chip and LonTalk protocol, configuration control can be compiled online and run in real time. The configuration control module is transmitted to the Neuron chip in the form of message packets, which reduces the workload of Neuron programming and compilation, and increases the flexibility and openness of the system. It provides a broader market for the development of configuration software. References: [1] Echelon Corporation. Neuron C Programmer's Guide, Revision 4 [2] Echelon Corporation. Neuron C Reference Guide, Revision 2 [3] Echelon Corporation. Neuron C User's Guide, Revision 3 [4] Yang Yuhong "Lon Network Control Technology and Application" Xi'an: Xi'an University of Electronic Science and Technology Press, 1999 [5] Yang Yuhong "Lon Network Programming" Xi'an: Xi'an University of Electronic Science and Technology Press, 2001 [6] Ma Guohua "Monitoring Configuration Software and Its Application" Tsinghua University Press, 2001