A dynamic fieldbus configuration system and its construction method

Abstract

This invention discloses a dynamic fieldbus configuration system and its construction method, relating to the field of industrial automation control. The dynamic fieldbus configuration system includes a device scanning and modeling module, a topology construction and verification module, a configuration generation and verification module, an incremental update monitoring module, an automatic code generation module, and a configuration persistence management module. The construction method of this invention sequentially implements device scanning and modeling, dynamic topology construction and verification, configuration generation and verification, incremental update monitoring, automatic code generation, and configuration persistence management. This invention improves configuration adaptability and efficiency through dynamic topology construction, fine-grained incremental updates, and multi-dimensional verification, and achieves configuration reuse and reliable maintenance through template-driven code generation and JSON format persistence, making it suitable for CAN bus-related industrial control scenarios.

Description

Technical Field

[0001] This invention relates to the field of industrial automation control technology, specifically to a dynamic fieldbus configuration system and its construction method. Background Technology

[0002] In the field of industrial automation, fieldbus technology is a key foundation for realizing distributed control systems. Among them, the CANopen protocol, as a high-level protocol based on the CAN bus, is widely used in industrial control, robotics, elevator control, and many other fields. However, traditional fieldbus configuration systems face numerous technical challenges, such as high configuration complexity, insufficient dynamic adjustment capabilities, and difficulties in device discovery and integration.

[0003] Therefore, there is an urgent need for a new type of dynamic fieldbus configuration system that can provide a visual configuration interface, support real-time monitoring, have dynamic adjustment capabilities, and achieve automatic device discovery. This system can effectively solve the aforementioned technical problems, thereby significantly improving the configuration efficiency and ease of operation and maintenance of industrial control systems. Summary of the Invention

[0004] In view of the above-mentioned shortcomings of the prior art, the present invention provides a dynamic fieldbus configuration system and its construction method, which can effectively solve the problems of the prior art.

[0005] To achieve the above objectives, the present invention is implemented through the following technical solutions;

[0006] This invention discloses a dynamic fieldbus configuration system, including a device scanning and modeling module, a topology construction and verification module, a configuration generation and verification module, an incremental update monitoring module, a code automatic generation module, and a configuration persistence management module.

[0007] The device scanning and modeling module is used to scan online devices through the CAN bus interface, obtain VendorId, ProductCode, and RevisionNumber identification information to establish a device identification library, and read and parse EDS files to build a device capability model library.

[0008] The topology construction and verification module is used to dynamically create a bus-master-slave hierarchical topology, assign unique node identifiers, and verify the legality of the topology.

[0009] The configuration generation and verification module is used to generate initial configuration parameters for nodes based on the device capability model and to perform real-time constraint checks on user-adjusted parameters.

[0010] The incremental update monitoring module is used to perform fine-grained incremental updates on the configured nodes and to adjust the permissions of the configuration interface by periodically polling the status of the monitored nodes.

[0011] The automatic code generation module is used to automatically generate program code files based on the bus topology and node configuration.

[0012] The configuration persistence management module is used to store configuration information in JSON format, enabling configuration version management, rollback, and cross-project reuse.

[0013] Furthermore, the device scanning and modeling module scans devices based on the JSONRpc protocol, reads emergency objects and identification objects to extract key information, and obtains detailed device parameters through the SDO protocol; the EDS file is parsed using the INI format, and the device identification library supports quick matching of configuration templates based on VendorId and ProductCode.

[0014] Furthermore, the topology construction verification module adopts a tree structure to manage the topology. The master station has a fixed ID of 127, and the slave stations are assigned sequentially and their uniqueness is verified. The topology's legality is verified through multi-layer checks, including node ID uniqueness, the number of slave stations being ≤10, and COB-ID conflict-free checks. In case of conflict, the topology is automatically reassigned.

[0015] Furthermore, the constraint checks of the configuration generation verification module include PDO total length ≤ 64 bits, no COB-ID conflict, and data type consistent with the device object dictionary definition. In case of illegal operation, an error is reported and blocked.

[0016] Furthermore, the incremental update monitoring module maintains the ΔConfig configuration difference table to perform incremental updates, and polls the node status every 2 seconds to adjust interface permissions.

[0017] Furthermore, the automatic code generation module adopts a template-driven mechanism, triggering incremental code generation when configuration changes occur.

[0018] Furthermore, the configuration persistence management module verifies the integrity of the configuration through MD5 checksum and automatically restores the backup when the configuration is corrupted.

[0019] This invention also claims a method for constructing a dynamic fieldbus configuration system as described above, comprising the following steps:

[0020] Step 1: The system automatically detects online devices through the bus scanning function, obtains identification information such as VendorId, ProductCode, and RevisionNumber for each device, and establishes a device identification library; at the same time, it reads the corresponding EDS description file of the device, parses the device object dictionary, PDO mapping, data type and other configuration information to build a device capability model library, providing basic data support for subsequent dynamic configuration;

[0021] Step 2: Based on the scanned device information and user configuration requirements, dynamically create a bus-master-slave hierarchical topology while the system is running; the system automatically assigns a unique identifier to each node, establishes communication mapping relationships between nodes, and verifies the legality and consistency of the topology in real time to ensure that no errors such as node ID conflicts or resource overruns occur during the configuration process.

[0022] Step 3: Based on the device model, the system automatically generates initial configuration parameters for each node, including PDO mapping, SDO parameters, communication parameters, etc. Users can adjust the configuration parameters. During the parameter modification process, the system performs constraint checks in real time to verify the legality of parameters, protocol compatibility and resource limitations, and promptly reports configuration errors and prevents illegal operations.

[0023] Step 4: Supports fine-grained parameter adjustment of configured nodes, using incremental updates to avoid full reconfiguration; the system monitors the connection and operation status of all nodes in real time through a periodic polling mechanism, and dynamically adjusts the available operation options in the configuration interface according to the actual status of the device to ensure that the configuration operation is synchronized with the actual capabilities of the device.

[0024] Step 5: Based on the current bus topology and node configuration parameters, the system automatically generates a program code file containing PDO mapping macros, variable declarations, communication parameter constants, etc. The generated code is completely synchronized with the current configuration, ensuring that the application can correctly access and control the configured bus devices, eliminating the risk of errors from manual coding.

[0025] Step 6: Save the complete topology, node configuration, parameter mapping and other information in a structured format to the configuration file, supporting persistent storage of configuration and version history management; the system records every configuration change operation, supports configuration rollback and iterative editing, ensures that the previous configuration state can be fully restored after the system restarts, and supports the reuse of configurations in different projects.

[0026] A further technical solution is as follows: The construction method of the Web visual configuration interface in step 2 is as follows: TypeScript is used as the development language, Vite is used as the build tool, and Webpack is used for module packaging; the interface layer adopts the React framework for component development, and the VS Code Webview API is used to realize communication with the extension main process; the state management library is integrated for unified management of configuration data, and CSS-in-JS technology is used to realize theme adaptation and responsive layout.

[0027] A further technical solution is as follows: The method for automatically detecting online devices via the bus in step 1 is as follows: The system reads the configuration system to obtain preset device scanning parameters and network topology information; it starts the bus scanning service, sends node guardian frames and heartbeat messages via the CANopen Network Management Protocol (NMT), and monitors the response status of each node; when a device response is detected, the system automatically reads the device's Emergency Object and Identity Object, extracting key identification information such as VendorId, ProductCode, RevisionNumber, and SerialNumber; simultaneously, it accesses the device's object dictionary index range of 0x1000-0x1FFF via the SDO (Service Data Object) protocol to obtain detailed parameters such as device type, manufacturer information, and firmware version; based on the obtained device identification information, the system automatically matches and loads the corresponding EDS description file, parsing key information such as the object dictionary mapping table, PDO (Process Data Object) configuration, data type definition, and communication parameters; after standardizing the parsed device capability information, it stores it in the device capability model library, establishing a mapping relationship between device ID and capability model, providing a complete data support foundation for subsequent dynamic configuration, parameter distribution, and real-time communication.

[0028] A further technical solution is as follows: The specific implementation method for dynamically creating the hierarchical topology in step 2 is as follows:

[0029] Based on the scan results, the system constructs a physical bus layer through a bus management component. Each bus object contains configuration parameters such as port identifier, baud rate, and bus type, supporting parallel management of multiple buses. Above the bus layer, a master station management layer is created. Each master station is assigned a unique network identifier and configured with protocol parameters such as node protection, synchronization control, and timestamp management. A device control layer is dynamically created through a slave station management component. The system automatically assigns a node identifier within a network address range to each slave station to avoid address conflicts.

[0030] The system adopts a tree topology to manage hierarchical relationships, and the parent-child node relationship ensures the consistency of the configuration hierarchy: each bus can carry multiple master controllers, and each master can manage a preset maximum number of slave devices; dynamic node addition, deletion, and attribute modification operations are realized through a unified hierarchical management interface;

[0031] The node identifier allocation adopts an intelligent scheduling algorithm: the master station uses the reserved high-order address segment, and the slave station is allocated the low-order address segment in sequence. The system maintains the address mapping table in real time to ensure uniqueness. When the topology changes, the system automatically triggers the view refresh mechanism and configuration persistence process.

[0032] The system monitors network connectivity in real time through a periodic status polling mechanism to verify the operational effectiveness of the topology. When an abnormal node communication is detected, the system automatically updates the device status identifier and pushes the changes to the user interface through a status synchronization mechanism to ensure the real-time performance and reliability of topology management.

[0033] A further technical solution is as follows: The specific implementation method for the automatic generation of node configuration parameters and constraint checking in step 3 is as follows:

[0034] Parameter configuration and constraint checks are implemented through multiple validation mechanisms: form components support hexadecimal format input and real-time format validation; the PDO length calculator ensures that the total mapping length does not exceed the 64-bit limit; the node identifier allocation algorithm automatically detects ID conflicts and provides alternatives; the COB-ID allocation manager maintains the uniqueness of communication object identifiers; the data type compatibility checker verifies the matching of parameters with the device object dictionary; when constraints are violated, the system immediately disables the relevant operations and displays an error message.

[0035] A further technical solution is as follows: The specific implementation scheme for real-time status monitoring in step 4 is as follows:

[0036] Real-time status monitoring adopts an event-driven architecture: a timer mechanism periodically calls the remote status query interface to obtain operational data such as device connection status, NMT status, and error count; status changes trigger dynamic updates of interface elements, including icon colors, button availability, and status indicators; remote device control operations are supported, including commands such as start, stop, and restart; abnormal states automatically trigger an alarm mechanism and provide fault diagnosis information; incremental configuration updates avoid full reconfiguration, reducing the impact on operating equipment.

[0037] A further technical solution is as follows: The specific implementation scheme for automatic code generation in step 5 is as follows:

[0038] The automatic code generation adopts a template-driven approach: based on the current topology and configuration parameters, it automatically generates C language header files and macro definitions; the code generator parses the configuration data structure and outputs code snippets such as variable declarations, constant definitions, and structure mappings; the template engine ensures the format and readability of the generated code; the code and configuration are kept synchronized in real time, and the corresponding code is automatically regenerated when the configuration changes; it supports custom code templates to meet the coding standard requirements of different projects.

[0039] A further technical solution is as follows: The specific solution for configuring persistence in step 6 is as follows:

[0040] Configuration persistence employs a layered storage strategy: configuration data is serialized in JSON format, containing complete hierarchical structure, parameter settings, state snapshots, and other information; the file system level supports importing and exporting configurations, enabling cross-project configuration reuse; a version management mechanism records every configuration change, supporting historical version viewing and configuration rollback; a configuration compatibility checker handles data migration during version upgrades; and an automatic backup mechanism ensures the security of configuration data, enabling rapid recovery to the most recent stable state in case of system anomalies.

[0041] Compared with the known prior art, the technical solution provided by this invention has the following beneficial effects:

[0042] (1) Significantly reduced configuration complexity: This invention transforms the complex fieldbus configuration process into an intuitive graphical operation through a visual interface and automated configuration tools. Compared with the traditional method of manually editing configuration files, the configuration efficiency is improved by more than 60%, and the human error rate is reduced by 80%.

[0043] (2) Real-time monitoring capability is comprehensively improved: The monitoring mechanism combining timed polling and event-driven is adopted to realize real-time monitoring of bus status and device operating status, which greatly reduces fault detection time and significantly improves system reliability;

[0044] (3) Breakthrough enhancement of dynamic configuration capability: Supports operations such as adding equipment, modifying parameters, and adjusting mappings while the system is running. Configuration changes can be completed without stopping the system, ensuring production continuity and reducing downtime for maintenance.

[0045] (4) Significantly improved equipment integration efficiency: Through automatic device discovery and EDS file parsing technology, the equipment integration process is simplified, and the device access time is shortened from hours to minutes, thus improving the efficiency of large-scale system integration;

[0046] (5) Enhanced user experience: The user interface built on modern Web technology provides an intuitive and user-friendly operating experience and rich interactive functions, reducing the learning cost for practitioners;

[0047] (6) Excellent cross-platform compatibility: Based on the VS Code extension architecture and Web technology, it supports mainstream operating systems such as Windows, Linux, and macOS, solving the limitations of traditional tool platforms and expanding the scope of application scenarios;

[0048] (7) The system security and stability are significantly enhanced: Through multiple confirmation mechanisms, configuration verification and error handling processes, misoperation and configuration errors are effectively prevented, the system stability is improved, and the fault recovery time is shortened to the minute level. Attached Figure Description

[0049] Figure 1Functional diagram for configuring a dynamic fieldbus system. Detailed Implementation

[0050] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0051] The present invention will be further described below with reference to embodiments.

[0052] A dynamic fieldbus configuration system includes: a device scanning and modeling module, a topology construction and verification module, a configuration generation and verification module, an incremental update and monitoring module, an automatic code generation module, and a configuration persistence management module.

[0053] The device scanning and modeling module is used to scan online devices through the CAN bus interface, obtain VendorId, ProductCode, and RevisionNumber identification information to establish a device identification library, and read and parse EDS files to build a device capability model library.

[0054] The topology construction and verification module is used to dynamically create a bus-master-slave hierarchical topology, assign unique node identifiers, and verify the legality of the topology.

[0055] The configuration generation and verification module is used to generate initial configuration parameters for nodes based on the device capability model and to perform real-time constraint checks on user-adjusted parameters.

[0056] The incremental update monitoring module is used to perform fine-grained incremental updates on the configured nodes and to adjust the permissions of the configuration interface by periodically polling the status of the monitored nodes.

[0057] The automatic code generation module is used to automatically generate program code files based on the bus topology and node configuration.

[0058] The configuration persistence management module is used to store configuration information in JSON format, enabling configuration version management, rollback, and cross-project reuse.

[0059] The construction method of the above-mentioned dynamic fieldbus configuration system includes the following steps:

[0060] Step 1: The system automatically detects online devices through the bus scanning function, obtains identification information such as VendorId, ProductCode, and RevisionNumber for each device, and establishes a device identification library; at the same time, it reads the corresponding EDS description file of the device, parses the device object dictionary, PDO mapping, data type and other configuration information to build a device capability model library, providing basic data support for subsequent dynamic configuration;

[0061] This step primarily involves performing a network scan via the CAN bus hardware interface, sending node guardian frames to obtain device responses. The system calls the remote API interface via the JSONRpc protocol to perform the following scanning operations: First, it sends a broadcast frame to the bus and listens for response messages from each node; when a device response is detected, the system reads the device's Emergency Object and Identity Object to extract key identification information. For example, in a CANopen network, the device's VendorId is 0x12345678, ProductCode is 0x87654321, and RevisionNumber is 0x00010002. Simultaneously, the system accesses the device's object dictionary index range (0x1000-0x1FFF) via the SDO (Service Data Object) protocol to obtain detailed parameters such as device type, manufacturer information, and firmware version.

[0062] EDS file parsing uses a standard INI format parser to extract key configuration sections: the [DeviceInfo] section contains basic device information, the [DummyUsage] section defines unused sub-indexes, the [Comments] section contains comment information, the [MandatoryObjects] section defines mandatory objects, and sections

[1000] to [9FFF] define specific object dictionary entries. The parsed device capability model is stored in the following format: a device index mapping table records the correspondence between object indices and data types; PDO configuration templates contain configurable input / output mappings; and communication parameter templates define supported baud rates, node protection methods, etc. An established device identifier library contains the mapping relationship between unique device identifiers and capability models, supporting quick lookup of corresponding configuration templates based on VendorId and ProductCode.

[0063] Step 2: Based on the scanned device information and user configuration requirements, dynamically create a bus-master-slave hierarchical topology while the system is running; the system automatically assigns a unique identifier to each node, establishes communication mapping relationships between nodes, and verifies the legality and consistency of the topology in real time to ensure that no errors such as node ID conflicts or resource overruns occur during the configuration process;

[0064] This step uses a tree-like data structure to manage the topology hierarchy. The BusManagerItem class constructs the bus layer, the CanMasterManagerItem class manages the master station layer, and the CanSlaveManagerItem class organizes the slave station layer. The node ID allocation algorithm is as follows: the master station uses a fixed node ID of 127, and slave stations are assigned IDs sequentially starting from 1, with uniqueness checked before allocation. The system maintains a node mapping table NodeMap[nodeId] = {deviceType, capabilities, status}, recording the device type, capability information, and online status of each node.

[0065] Topology verification employs a multi-layered checking mechanism: First, it verifies the uniqueness of node IDs, checking for duplicate allocations within the range of 1-126; second, it checks resource limitations, verifying that the number of slaves under each master does not exceed a preset limit (default is 10); finally, it checks communication parameter compatibility to ensure that COB-ID allocations do not conflict. The verification formula is as follows:

[0066]

[0067]

[0068] Here, IDUnique represents the node ID uniqueness check result, ResourceLimit represents the resource limit check result, and CommunicationValid represents the communication compatibility check result. When a conflict is detected, the system automatically triggers a reallocation algorithm to resolve the ID conflict through a negotiation mechanism. For example, if node ID=5 is found to be occupied, the system automatically allocates the next available ID=6 and updates the node mapping table.

[0069] Step 3: Based on the device model, the system automatically generates initial configuration parameters for each node, including PDO mapping, SDO parameters, communication parameters, etc. Users can adjust the configuration parameters. During the parameter modification process, the system performs constraint checks in real time to verify the legality of parameters, protocol compatibility and resource limitations, and promptly reports configuration errors and prevents illegal operations.

[0070] This step generates an initial configuration for each node based on the device capability model built in Step 1. The PDO configuration generation algorithm traverses the device object dictionary, filters objects with PDO mapping attributes, and automatically constructs RXPDO (receive PDO) and TXPDO (transmit PDO) mapping tables. SDO parameter configuration includes basic information such as object index, sub-index, data type, and access permissions. Communication parameter configuration covers protocol parameters such as COB-ID allocation, transmission type, event time, and suppression time.

[0071] The constraint checking engine employs a multi-factor validation mechanism to verify user input parameters in real time. The PDO length constraint check ensures that the total length of a single PDO mapping does not exceed the 64-bit limit, calculated as follows:

[0072]

[0073]

[0074] Where DataTypeLength_i represents the data length (in bits) of the i-th mapped object. When PDOLength > 64, the system disables the confirmation operation and displays an error message. COB-ID conflict detection checks whether newly assigned identifiers conflict with existing configurations by maintaining a global COB-ID allocation table. Data type compatibility verification ensures that the data type of the mapped object is consistent with the device object dictionary definition. For example, when a user attempts to map a BOOLEAN type object to a 32-bit length, the system immediately displays a "data length mismatch" error message and blocks the operation.

[0075] Step 4: Support fine-grained parameter adjustment for configured nodes, using incremental updates to avoid full reconfiguration; the system monitors the connection and running status of all nodes in real time through a periodic polling mechanism, and dynamically adjusts the available operation options in the configuration interface according to the actual status of the device to ensure that the configuration operation is synchronized with the actual capabilities of the device;

[0076] This step enables dynamic management and real-time monitoring of configurations. The incremental update mechanism only modifies changed configuration items, avoiding impact on other normally functioning nodes. The system maintains a configuration difference table ΔConfig = {addedItems, modifiedItems, deletedItems} to record configuration change details. Update operations are sorted according to dependencies, prioritizing updates to basic parameters before updating dependent parameters.

[0077] Status monitoring employs a timed polling mechanism, calling the getStatus API every 2 seconds to retrieve the node's running status. Monitoring parameters include: connection status (online / offline), NMT status (initialization / pre-operation / operation / stop), error count, heartbeat timestamp, etc. The status update algorithm is as follows:

[0078]

[0079]

[0080] The interface control logic dynamically adjusts operation options based on device status: when the device is offline, the parameter modification button is disabled and a gray icon is displayed; when the device is online but in a stopped state, configuration modification is allowed but data transmission is disabled; when the device is in operation, all control functions are enabled. For example, when slave node ID=3 is in a pre-operation state, the interface displays a yellow status indicator, parameter configuration is allowed but PDO communication is disabled.

[0081] Step 5: Based on the current bus topology and node configuration parameters, the system automatically generates a program code file containing PDO mapping macros, variable declarations, communication parameter constants, etc. The generated code is completely synchronized with the current configuration, ensuring that the application can correctly access and control the configured bus devices, eliminating the risk of errors in manual coding.

[0082] This step employs a template-driven code generation mechanism to parse the current complete configuration data and output standard C language header and implementation files. The code generator includes the following template components: macro definition templates are responsible for generating constant definitions such as node IDs and COB-IDs; data structure templates generate PDO mapping structures; and function templates generate device initialization and data access functions.

[0083] The code generation algorithm traverses the topology tree structure and generates a corresponding code segment for each node. The generated code format is as follows:

[0084] / / Node definition

[0085] #define SLAVE_NODE_1_ID 0x01

[0086] #define SLAVE_NODE_1_RXPDO_COBID 0x201

[0087] #define SLAVE_NODE_1_TXPDO_COBID 0x181

[0088] / / PDO mapping structure

[0089] typedef struct {

[0090] uint16_t statusWord; / / 0x6041:00

[0091] int32_t actualPosition; / / 0x6064:00

[0092] } SlaveNode1_TXPDO_t;

[0093] / / Variable declaration

[0094] extern SlaveNode1_TXPDO_t g_slaveNode1_txpdo;

[0095] The code synchronization update mechanism listens for configuration change events. When it detects the addition or deletion of nodes, modification of parameters, or changes in mappings, it automatically triggers incremental code generation. The update granularity is precise to the individual node level, avoiding a full regeneration. For example, when a user modifies the RXPDO mapping of node 1, the system only regenerates the structure definitions and access functions related to that node, keeping the code of other nodes unchanged.

[0096] Step 6: Save the complete topology, node configuration, parameter mapping and other information in a structured format to the configuration file, supporting persistent storage of configuration and version history management; the system records every configuration change operation, supports configuration rollback and iterative editing, ensures that the previous configuration state can be fully restored after the system restarts, and supports the reuse of configurations in different projects;

[0097] This step enables persistent management and version control of configuration data. The configuration file is stored in JSON format and contains complete hierarchical structure information. The file organization structure is as follows: the root node contains basic project information (name, version, creation time), the bus configuration node contains bus parameters (baud rate, bus type, rack number), and the node configuration node contains detailed configuration parameters for each device.

[0098] The configuration serialization algorithm traverses the configuration tree in memory, recursively extracting configuration information from nodes at each level. Serialization format example:

[0099] {

[0100] "projectInfo": {

[0101] "name": "CANopen_Project_1",

[0102] "version": "1.0.0",

[0103] "createTime": "2024-01-15T10:30:00Z"

[0104] },

[0105] "busConfig": [{

[0106] "busIndex": 0,

[0107] "baudrate": 500000,

[0108] "busType": "CANopen",

[0109] "masters": [{

[0110] "nodeId": 127,

[0111] "slaves": [

[0112] {

[0113] "nodeId": 1,

[0114] "vendorId": "0x12345678",

[0115] "productCode": "0x87654321",

[0116] "rxPDO": [...],

[0117] "txPDO": [...]

[0118] } ]

[0120] }]

[0121] }]

[0122] }

[0123] The version management mechanism generates a unique timestamp for each configuration change, recording the change type (addition / modification / deletion), affected scope, and the user who performed the change. The system maintains a version history table.

[0124]

[0125]

[0126] Supports configuration difference comparison and version rollback. Configuration integrity verification ensures data integrity by calculating the MD5 checksum of the configuration data. For example, if the configuration file is corrupted, the system automatically restores the most recent valid configuration version from the backup and prompts the user to confirm the restore operation.

[0127] This invention proposes a dynamic configuration, management, and monitoring technology for fieldbus networks based on the CANopen protocol. This system enables online configuration, real-time status monitoring, dynamic parameter adjustment, and intelligent management of inter-device communication for fieldbus devices. It is suitable for industrial control scenarios requiring fieldbus communication, such as programmable logic controllers (PLCs), distributed control systems (DCS), and industrial IoT.

[0128] This technology primarily addresses the problems of complex configuration, difficult debugging, and inability to dynamically adjust during operation in traditional fieldbus configuration systems. By providing a visual configuration interface, automated device discovery, real-time status feedback, and dynamic parameter adjustment functions, it significantly improves the configuration efficiency and ease of operation and maintenance of industrial control systems.

[0129] In traditional industrial settings, most systems only support limited bus parameter changes and cannot configure or update multi-master, multi-slave topologies and their mapping relationships without downtime (while running), leading to the risk of parameter mismatch after node replacement. This invention, through a hierarchical representation of device-bus-master-slave, supports adding, deleting, PDO mapping editing, and Modbus communication parameter modification of CAN masters and slaves without downtime. The slave scanning function obtains VendorId, ProductCode, and RevisionNumber. In CANOpen scenarios, the system supports regenerating header files containing PDO mapping macros and variable declarations as needed based on the current structure, significantly reducing manual synchronization and reconstruction workload. Configuration data is persistently saved in structured file format, supporting iterative editing. This solution, through a complete closed loop of "add / delete / edit → real-time verification → code generation → application," reduces the workload of repetitive configuration in multi-device projects, improves slave identification and status verification rates, and enhances the consistency and maintainability of field configurations.

[0130] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions will not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A dynamic fieldbus configuration system, characterized in that, It includes a device scanning and modeling module, a topology construction and verification module, a configuration generation and verification module, an incremental update and monitoring module, a code automatic generation module, and a configuration persistence management module; The device scanning and modeling module is used to scan online devices through the CAN bus interface, obtain VendorId, ProductCode, and RevisionNumber identification information to establish a device identification library, and read and parse EDS files to build a device capability model library. The topology construction and verification module is used to dynamically create a bus-master-slave hierarchical topology, assign unique node identifiers, and verify the legality of the topology. The configuration generation and verification module is used to generate initial configuration parameters for nodes based on the device capability model and to perform real-time constraint checks on user-adjusted parameters. The incremental update monitoring module is used to perform fine-grained incremental updates on the configured nodes and to adjust the permissions of the configuration interface by periodically polling the status of the monitored nodes. The automatic code generation module is used to automatically generate program code files based on the bus topology and node configuration. The configuration persistence management module is used to store configuration information in JSON format, enabling configuration version management, rollback, and cross-project reuse.

2. The dynamic fieldbus configuration system according to claim 1, characterized in that, The device scanning and modeling module scans devices based on the JSONRpc protocol, reads emergency objects and identification objects to extract key information, and obtains detailed device parameters through the SDO protocol; the EDS file is parsed using the INI format, and the device identification library supports quick matching of configuration templates based on VendorId and ProductCode.

3. The dynamic fieldbus configuration system according to claim 1, characterized in that, The topology construction and verification module adopts a tree structure to manage the topology. The master station has a fixed ID of 127, and the slave stations are assigned in sequence and their uniqueness is verified. The topology is verified through multi-level checks, including node ID uniqueness, the number of slave stations being ≤10, and COB-ID conflict-free. In case of conflict, the topology is automatically reassigned.

4. The dynamic fieldbus configuration system according to claim 1, characterized in that, The constraint checks of the configuration generation verification module include PDO total length ≤ 64 bits, no COB-ID conflict, and data type consistent with the device object dictionary definition. When an illegal operation occurs, an error is reported and the operation is blocked.

5. The dynamic fieldbus configuration system according to claim 1, characterized in that, The incremental update monitoring module maintains the ΔConfig configuration difference table and performs incremental updates, polling the node status every 2 seconds to adjust interface permissions.

6. The dynamic fieldbus configuration system according to claim 1, characterized in that, The automatic code generation module adopts a template-driven mechanism, which triggers incremental code generation when the configuration changes.

7. The dynamic fieldbus configuration system according to claim 1, characterized in that, The configuration persistence management module verifies the integrity of the configuration through MD5 checksum and automatically restores the backup when the configuration is damaged.

8. A method for constructing a dynamic fieldbus configuration system as described in any one of claims 1-7, characterized in that, Includes the following steps: Step 1: Equipment scanning and modeling. Scan online devices to establish an identification library, and parse EDS files to build a device capability model library; Step 2: Topology construction and verification. Dynamically create hierarchical topology and assign node IDs. Verify the validity through multiple layers of checks and reassign nodes in case of conflicts. Step 3: Configure and generate verification, generate initial configuration parameters, and perform constraint checks on user-adjusted parameters; Step 4: Incremental update monitoring, maintain configuration difference table to perform fine-grained incremental updates, periodically poll node status to dynamically adjust interface permissions; Step 5: Automatic code generation, generating program code based on topology and configuration; Step 6: Configure persistent management, serialize and store configuration information to achieve version management and backup and recovery.

9. The construction method according to claim 8, characterized in that, Step 1 parses the key configuration sections of the EDS file, including [DeviceInfo], [MandatoryObjects], and [1000]-[9FFF] sections; in Step 3, if the data types are incompatible, the system will prompt an error and block the operation.

10. The construction method according to claim 8, characterized in that, Step 4: Adjust interface permissions according to device status. Specifically: disable the parameter modification button when the device is offline; allow configuration modification but disable data transmission when the device is online but in a stopped state; enable all control functions when the device is in operation.

Images