Soft board servo motion control and data interaction system based on OPCUA

Abstract

The invention provides a soft board card servo motion control and data interaction system based on an OPCUA. Comprising a server connection module used for selecting an OPCUA according to a server address, establishing a client session and outputting a session handle; the variable analysis module is used for generating an analysis rule from a logic variable name to an OPCUA node identifier and outputting variable metadata; the memory mapping module is used for creating subscriptions in batches under a session handle, binding data change callback and writing change of server variables into a local data storage area; the control module is used for providing a data read-write interface and a shaft control interface for an upper computer; and determining an instruction state based on the completion mark, the error code and the busy mark, and providing the instruction state and the shaft state quantity as readable variables to the data read-write interface. According to the application, the unification of variable analysis and OPCUA node addressing, subscription-driven local data mirroring and low-delay read-write, axis control parameterization execution closed loop and unified state judgment based on completion / error / busy can be realized.

Description

Technical Field

[0001] The present application relates to the field of industrial automation technology, and in particular to an OPC UA-based soft board servo motion control and data interaction system. Background Art

[0002] In industrial automation scenarios, host computers often use flexible boards to carry motion control logic and interact with controlled objects using industrial protocols such as OPCUA to implement axis parameter setting, command issuance, and status acquisition. As the scale of device interconnection expands, the system faces the challenges of coexisting multiple protocols such as OPCUA, Modbus, and ACP, heterogeneous variable namespaces, and decentralized node addressing, increasing access and maintenance costs.

[0003] Existing technologies often rely on general-purpose OPC UA clients or PLC vendor drivers, using point-based read / write or periodic polling to interact with data. These technologies lack parametric control abstractions for servo axes, unified mapping of variables to local memory, and batch subscription update mechanisms. The business side often independently determines the association between completion flags, error codes, and busy flags, resulting in fragmented instruction execution loops, insufficient state consistency, and inconsistent interfaces. Furthermore, device descriptor changes and node renaming can easily lead to variable mapping mismatches, while polling can cause bandwidth usage and latency fluctuations. The lack of session keepalive and subscription robustness makes it difficult to support multi-axis real-time control and cross-device scalability. Summary of the Invention

[0004] In view of this, an embodiment of the present application provides an OPCUA-based soft board servo motion control and data interaction system to solve the problems existing in the prior art of inconsistency in variable resolution and OPCUA node addressing, data interaction dependence on polling and lack of subscription-driven local mirroring, and lack of parameterized control and unified judgment of servo axis instructions.

[0005] An embodiment of the present application provides an OPCUA-based soft board servo motion control and data interaction system, including: a server connection module, used to select OPCUA according to a server address and establish a client session, and output a session handle; a variable parsing module, used to read configuration and device descriptors, generate parsing rules from logical variable names to OPCUA node identifiers, and output variable metadata; a memory mapping module, used to allocate a local data storage area according to the variable metadata, establish a mapping from logical variable names to local memory addresses and a mapping from OPCUA node identifiers to local memory addresses, and create subscriptions in batches under the session handle and bind data change callbacks to write changes to server variables to the local data storage area; a control module, used to provide a data read and write interface and an axis control interface to a host computer, wherein data reading takes values ​​from the local data storage area according to the logical variable name, and data writing constructs an OPCUA data variant according to the parsing rules and writes it to the corresponding node via the session handle; the axis control interface receives the axis number and trajectory parameters, writes the position, velocity, acceleration, and deceleration parameters to the corresponding node and sets the execution control bit, determines the instruction status based on the completion flag, error code, and busy flag, and provides the instruction status and axis status as readable variables to the data read and write interface.

[0006] At least one of the above technical solutions adopted in the embodiments of the present application can achieve the following beneficial effects: Through the server connection module, it is used to select OPCUA according to the server address and establish a client session, and output the session handle; the variable parsing module is used to read the configuration and device descriptors, generate the parsing rules from the logical variable name to the OPCUA node identifier and output the variable metadata; the memory mapping module is used to allocate the local data storage area according to the variable metadata, establish the mapping from the logical variable name to the local memory address and the mapping from the OPCUA node identifier to the local memory address, and create subscriptions in batches under the session handle and bind the data change callback to write the changes of the server variables to the local data storage area; the control module is used to provide the host computer with a data read and write interface and an axis control interface, wherein data reading takes values ​​from the local data storage area according to the logical variable name, and data writing constructs the OPCUA data variant according to the parsing rules and writes it to the corresponding node via the session handle; the axis control interface receives the axis number and trajectory parameters, writes the position, speed, acceleration and deceleration parameters to the corresponding node and sets the execution control bit, determines the instruction status based on the completion flag, error code and busy flag, and provides the instruction status and axis status as readable variables to the data read and write interface. This application can achieve the unification of variable resolution and OPCUA node addressing, subscription-driven local data mirroring and low-latency reading and writing, parameterized execution of axis control closed loop and unified status judgment based on completion / error / busy. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the embodiments or descriptions of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0008] Figure 1 This is a schematic diagram of the structural composition of the OPCUA-based soft board servo motion control and data interaction system provided in an embodiment of the present application. DETAILED DESCRIPTION

[0009] In the following description, specific details such as specific system structures and techniques are provided for purposes of illustration rather than limitation to facilitate a thorough understanding of the embodiments of the present application. However, it will be apparent to those skilled in the art that the present application may be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to avoid obscuring the description of the present application with unnecessary detail.

[0010] In existing technologies, host computers typically rely on flexible boards to host motion control logic, interacting with controlled objects via industrial protocols such as OPCUA. In engineering practice, multiple protocols, including OPCUA, Modbus, and ACP, often coexist, resulting in fragmented variable namespaces and node addressing. Universal clients often employ point-based read / write or polling updates, lacking parametric control abstractions and a unified state determination path for servo axes. Variable mapping mismatches are easily caused when device descriptors or node names are renamed, and persistent connection keepalives and subscriptions lack robustness, hindering multi-axis real-time control and scalable maintenance.

[0011] Therefore, the existing technology still has the following problems: how to achieve the unification of variable resolution and OPCUA node addressing; how to build a subscription-driven local data mirror to reduce polling and reduce read and write latency; how to provide a parameterized execution closed loop for servo axis instructions and make unified judgments based on completion / error / busy, while taking into account session preservation and subscription recovery, and improving system portability and maintainability.

[0012] In view of the problems existing in the prior art, the present application proposes a soft board servo motion control and data interaction system based on OPCUA, including a server connection module for establishing an OPCUA session based on the server address and outputting a session handle; a variable parsing module for reading configuration and device descriptors, generating parsing rules from logical variable names to OPCUA node identifiers and outputting variable metadata; a memory mapping module for allocating local data storage areas, establishing a first mapping of logical variable names → local memory addresses and a second mapping of OPCUA node identifiers → local memory addresses, and creating subscriptions and binding data change callbacks according to preset strategies under the session to write changes to local storage; a control module for providing data read and write interfaces and axis control interfaces, writing position, speed, acceleration, and deceleration parameters according to parsing rules and setting the execution control bit, making status judgments based on the completion flag, error code, and busy flag within a preset time window and resetting the execution control bit, while providing the instruction status and axis status quantities as readable variables to the outside.

[0013] The technical solution of this application can realize the unified management of variable resolution and OPCUA node addressing; build local data mirroring with subscription drive to reduce polling bandwidth and read and write latency; form a parameterized execution closed loop and a unified state determination path for servo axis instructions, with consistent interface semantics and easy integration of upper-level applications; and improve long-term operation stability and cross-device portability through session keep-alive and subscription recovery mechanisms.

[0014] The specific structure and functions of the OPCUA-based soft board servo motion control and data interaction system provided in the embodiment of the present application are described in detail below in conjunction with the accompanying drawings and specific embodiments. Figure 1 Schematic diagram of the structure of the OPCUA-based soft board servo motion control and data interaction system provided in the embodiment of the present application, such as Figure 1 As shown, the OPCUA-based soft board servo motion control and data interaction system can specifically include the following modules: The server connection module 101 is used to select OPCUA according to the server address and establish a client session, and output a session handle; The variable parsing module 102 is used to read the configuration and device descriptors, generate parsing rules from logical variable names to OPCUA node identifiers and output variable metadata; The memory mapping module 103 is used to allocate local data storage areas based on variable metadata, establish a mapping from logical variable names to local memory addresses and a mapping from OPCUA node identifiers to local memory addresses, create subscriptions in batches under the session handle, bind data change callbacks, and write changes to server variables to the local data storage area. The control module 104 is used to provide a data read and write interface and an axis control interface to the host computer. Data reading is to obtain values ​​from the local data storage area according to the logical variable name, and data writing is to construct an OPCUA data variant according to the parsing rules and write it to the corresponding node via the session handle. The axis control interface receives the axis number and trajectory parameters, writes the position, speed, acceleration, and deceleration parameters to the corresponding node and sets the execution control bit. It determines the instruction status based on the completion flag, error code, and busy flag, and provides the instruction status and axis status as readable variables to the data read and write interface.

[0015] In some embodiments, selecting OPC UA based on the server address and establishing a client session, and outputting a session handle, includes: Receive the server address and set the communication mode to OPCUA; When an existing client session is detected, the session is closed and resources are released, and an OPCUA client instance is created based on the preset client configuration. Resolve the target connection endpoint based on the server address and initiate a session establishment request to the server; When the session is successfully established, a session handle is generated and registered, and the session handle is provided to the variable parsing module, the memory mapping module and the control module for calling.

[0016] Specifically, in this embodiment, the server connection module is executed in the order of "communication mode setting → existing session cleanup → client instantiation → endpoint resolution → session establishment → handle registration and distribution". First, the server address is received and the communication mode is set to OPCUA to enter the connection state. Then it is detected whether there is an existing client session. If so, the session closing, subscription revocation notification and resource release are executed in sequence to ensure the idempotent switching of the connection. Thereafter, an OPCUA client instance is created according to the preset client configuration, which includes security policy, session timeout, retry policy and certificate parameters. The module performs endpoint resolution on the input server address, obtains the target connection endpoint that meets the policy and initiates a session establishment request. After the session is successfully established, a session handle is generated, the handle is uniquely registered and written into the session management table, and the available session reference is released to the variable resolution module, memory mapping module and control module.

[0017] The key technical terms and features involved in this embodiment are explained below. The specific contents are as follows: Session handle: Indicates the unique identifier of the current OPCUA session resource and its access context, used to pass session references across modules and standardize the attribution of subsequent read, write, and subscription operations.

[0018] Preset client configuration: A set of connection parameters preset for different deployment environments, including security and timeout boundaries, endpoint selection strategy, and certificate loading strategy, to ensure portability and consistency of the instantiation process.

[0019] Endpoint resolution strategy: Regularize and detect the input server address, select the matching endpoint item based on the policy priority, and output the target connection endpoint for connection establishment, avoiding direct coupling of the upper layer with the underlying endpoint enumeration and change.

[0020] Concurrency and idempotence control: Session switching is serialized using exclusive locks. The release of old sessions and the establishment of new sessions are atomic, preventing resource dangling and reference failures from spreading across modules.

[0021] For example, in some example scenarios, in a typical deployment, the host computer enters the server address "opc.tcp: / / 192.168.1.10:4840." The server connection module first sets the communication mode to OPC UA and enters the connection process. When it detects the existence of an old session, the module notifies the relevant subscription to enter a suspended state, then closes the old session and reclaims the associated resources.

[0022] The module creates an OPCUA client instance based on the site's pre-configured client configuration, loads security and timeout parameters, and completes certificate loading. It then performs endpoint resolution on the input address, selects the target connection endpoint that meets the policy, and initiates a session establishment request.

[0023] When the server returns a successful response, the module generates a session handle and registers it in the session management table. It provides the session handle to the variable parsing module to read the configuration and device descriptors, provides the session handle to the memory mapping module to subsequently create subscriptions according to the batch strategy and bind data change callbacks, and provides the session handle to the control module to support data writing and the execution of the axis control interface.

[0024] If any link in the establishment process returns an unrecoverable error, the module records the reason for the failure and keeps the old handle invalid, and does not distribute references to each module, thereby ensuring that each module can only perform subsequent operations when the session is valid.

[0025] In some embodiments, reading configuration and device descriptors, generating parsing rules from logical variable names to OPC UA node identifiers, and outputting variable metadata includes: Read the configuration file to obtain the logical variable name, data type and initial value related to the variable; Determine a device prefix based on the device descriptor, and standardize the logical variable name to form a logical variable name with the prefix; According to the preset naming and mapping rules, the logical variable name with the prefix is ​​parsed into the OPCUA node identifier, which includes the namespace identifier and the node name; Perform consistency check on the parsing results to confirm the correspondence between the logical variable name and the corresponding data type and OPCUA node identifier; Generate and register variable metadata, and provide the variable metadata to the memory mapping module and control module for calling.

[0026] Specifically, in this embodiment, the variable parsing module executes in the order of "configuration acquisition → device prefix determination → logical variable standardization → node identifier resolution → consistency check → metadata registration and distribution." First, the configuration file is read to obtain the logical variable name, data type, and initial value of each variable. The device prefix is ​​then determined based on the device descriptor to distinguish different soft card instances. The logical variable names are then standardized, including regularization of hierarchical delimiters, uniform case and array index formats, and necessary name space padding. The device prefix is ​​then added to the header to generate a prefixed logical variable name. Based on preset naming and mapping rules, the module parses the prefixed logical variable name into an OPC UA node identifier, which includes a namespace identifier and a node name. After parsing is complete, the results are checked for consistency, establishing a one-to-one correspondence between the logical variable name, data type, and OPC UA node identifier. The check includes data type matching, node reachability, and initial value writability. Finally, variable metadata is generated and registered, and provided to the memory mapping module and control module for invocation.

[0027] The key technical terms and features involved in this embodiment are explained below. The specific contents are as follows: Device prefix determination mechanism: Generates prefix identifiers based on device descriptors, decouples homogeneous variables between different soft board instances, and makes logical variable names portable across devices.

[0028] Standardized rule set: Unify hierarchical paths, array indexes, and naming conventions to maintain a stable mapping between upper-level configurations and underlying node naming, reducing addressing deviations caused by project naming differences.

[0029] Node ID resolution strategy: Output the namespace ID and node name simultaneously through mapping rules to ensure addressing integrity; when there are nodes with the same name, select the target based on the namespace priority and path integrity.

[0030] Consistency verification link: performs serial verification of data types, node reachability, and initial value writability to ensure that subsequent memory mapping and subscription establishment have a reliable reference basis.

[0031] For example, in some example scenarios, in a typical deployment, the configuration file records the logical variable name, data type, and initial value of the axis-related variables, such as the logical variable name of the position parameter, the type is double precision, and the initial value is zero.

[0032] The variable parsing module first determines the device prefix based on the device descriptor and concatenates the logical variable name with the device prefix to form a prefixed logical variable name. It then parses the variable name according to pre-set rules to obtain the corresponding OPCUA node identifier, where the namespace identifier and node name come from the server-side namespace configuration and the hierarchical node path, respectively.

[0033] The module performs a consistency check on the parsed results, confirming that the variable's data type is consistent with the server-side node's data type, that the node is reachable, and that the initial value has write permission. Once the check passes, variable metadata is generated, recording the logical variable name, data type, initial value, and OPCUA node identifier. This metadata is provided to the memory mapping module for establishing a primary mapping from logical variable names to local memory addresses and a secondary mapping from OPCUA node identifiers to local memory addresses. It is also provided to the control module for data reading and writing and for locating axis control parameter nodes.

[0034] This embodiment establishes a stable mapping and usable metadata output mechanism from logical variables to OPC UA nodes by determining device prefixes, standardizing variable names, and parsing and checking the dual elements of node identification. This improves the consistency and portability of variable addressing and provides a reliable reference basis for parameter node positioning in subsequent memory mapping, batch subscription, and axis control.

[0035] In some embodiments, allocating a local data storage area based on variable metadata, establishing a mapping from a logical variable name to a local memory address, and establishing a mapping from an OPCUA node identifier to a local memory address, includes: Parse variable metadata to obtain the logical variable name, data type, initial value, and OPCUA node identifier corresponding to each variable; Configure storage units according to data types, allocate local data storage areas and write initial values ​​into corresponding storage units; Determine and register a local memory address for each logical variable name, and establish a first mapping from the logical variable name to the local memory address divided by data type; Based on the correspondence between the OPC UA node identifier and the local memory address, a second mapping from the OPC UA node identifier to the local memory address is established.

[0036] Specifically, this embodiment is implemented in the order of "metadata parsing → typed storage allocation and initial value storage → first mapping registration → second mapping registration". The variable metadata output by the variable parsing module includes the logical variable name, data type, initial value and OPCUA node identifier. The memory mapping module first parses all variable metadata; then configures the corresponding storage unit according to the data type, allocates a continuous or equivalent addressable memory location for each variable in the local data storage area and writes the initial value; on this basis, two types of indexes are established: one is the first mapping of logical variable name divided by data type → local memory address, and the other is the second mapping of OPCUA node identifier → local memory address. Both types of mappings are registered in the index management structure for data reading and writing and subscription callback calls.

[0037] The key technical terms and features involved in this embodiment are explained below. The specific contents are as follows: Typed storage units: Separate storage areas are configured for bool, int16, uint16, int32, uint32, double, etc. to ensure type consistency and address alignment requirements of the read path.

[0038] First mapping: The read path addressed by the logical variable name to the host computer locates the target memory address and directly reads the value of the corresponding type.

[0039] Second mapping: Node addressing for subscription callbacks and write paths, quickly locates the target memory address based on the OPCUA node identifier, and implements in-place update of the changed value.

[0040] Initial value disk write strategy: After the allocation is completed, the initial value in the metadata is written to the corresponding storage unit, so that the reading result is deterministic before the first subscription update arrives.

[0041] For example, in some example scenarios, in a typical configuration, the variable metadata includes parameter items and status items related to single-axis absolute position motion, such as the logical variable name with device prefix "SoftCard.GVL.SingleAxis[i].stMoveAbsolute.Position", "...Velocity", "...Acc", "...Dec", and the status variable "SoftCard.GVL.SingleAxis[i].stMoveAbsolute.Done", "...ErrorID", "...Busy", whose data types correspond to double, double, double, double, bool, uint16, and bool, respectively, and the initial value is given in the configuration.

[0042] After reading the metadata, the memory mapping module allocates a storage unit matching the type of each item in the local data storage area and writes an initial value of 0 or false. It then generates a first mapping, establishing a key-value mapping between each prefixed logical variable name and its local memory address; and a second mapping, establishing a key-value mapping between each variable's corresponding OPCUA node identifier (including namespace identifier and node name) and the same memory address.

[0043] When a subsequent subscription callback receives a change notification for any parameter or state variable, the callback routine queries the second mapping using the OPCUA node identifier, directly locates the local memory address, and writes the latest value according to the variable type; when the host computer reads, it queries the first mapping using the logical variable name and retrieves the current value from the local data storage area without accessing the server.

[0044] This embodiment establishes a stable and consistent local data mirror addressing system through typed allocation and initial value storage, and bidirectional indexing of logical variable names and OPCUA node identifiers, allowing the upper layer to quickly read with logical variable names and the lower layer to efficiently update with node identifiers, reducing access coupling and supporting subsequent batch subscriptions and reliable calls to axis control parameter nodes.

[0045] In some embodiments, creating subscriptions in batches under a session handle and binding data change callbacks to write changes to server variables to a local data store includes: Determine the target variable set to be subscribed based on variable metadata; Group the target variable set according to the preset strategy, create a subscription request for each group under the session handle, bind the data change callback, and activate the subscription; Upon receiving a data change notification including the OPCUA node identifier and the changed value, calling the second mapping to locate the corresponding local memory address according to the OPCUA node identifier; The changed value is processed for type consistency according to the data type recorded in the variable metadata, and the changed value is written to the corresponding storage unit in the local data storage area.

[0046] Specifically, in this embodiment, the memory mapping module executes the sequential process of "target set determination → group binding → callback binding → notification processing writeback" under the session handle. First, the target variable set that needs to be tracked in real time is screened based on the variable metadata, with priority given to axis parameter nodes and status nodes, limit and origin sensor nodes, and fault-related nodes. Then, the target variable set is grouped according to the preset strategy, with no more than 100 items in each group, and is aggregated as much as possible by namespace and functional domain to reduce server-side push jitter and client-side processing peak. Create a subscription for each group under the session handle and bind a data change callback, and enter a continuous receiving state after activation. When a notification containing an OPCUA node identifier and a changed value is received, the callback routine calls the second mapping to locate the corresponding local memory address based on the OPCUA node identifier, performs type consistency processing according to the data type recorded in the variable metadata, and writes the changed value to the corresponding storage unit in the local data storage area.

[0047] The key technical terms and features involved in this embodiment are explained below. The specific contents are as follows: Group subscription strategy: The upper limit for a single subscription is no more than 100 items, and aggregation by namespace and functional domain is prioritized to facilitate efficient packaging on the server and low-cost unpacking on the client.

[0048] Second mapping: An addressing index with the OPCUA node identifier as the key and the local memory address as the value, ensuring that the callback process can directly locate the storage location without re-parsing the logical variable name.

[0049] Type consistency processing: Conversion and writing are performed strictly according to the data type declared in the variable metadata to avoid storage misalignment or reading ambiguity caused by different data types.

[0050] For example, in some example scenarios, in a typical deployment, the target variable collection includes parameters and status items related to single-axis absolute position motion, such as "SoftCard.GVL.SingleAxis[i].stMoveAbsolute.Position," "...Velocity," "...Acc," "...Dec," "...Done," "...ErrorID," and "...Busy," as well as "SoftCard.GVL.SingleAxis[i].stPower.Status," "isPosSensor," "isNegSensor," and "isHomeSensor," related to enable and limit motion. The module divides these variables into two groups based on a preset strategy: the first group contains motion parameters and motion status, and the second group contains enable and sensor status and fault-related variables. Each group contains no more than 100 items. The system creates subscriptions for each group under the session handle and binds data change callbacks. Once the subscriptions are activated, the server begins pushing incremental updates.

[0051] When the server sets "SoftCard.GVL.SingleAxis[1].stMoveAbsolute.Done" to true, the callback receives the notification and parses it to obtain the corresponding OPCUA node identifier. It then directly locates the address of the Boolean variable in the local data storage area through the second mapping and writes the true value according to the Boolean type. Subsequently, if "SoftCard.GVL.SingleAxis[1].stMoveAbsolute.ErrorID" changes to an unsigned integer value, the callback also queries the second mapping with the node identifier, locates the local unsigned integer storage unit and writes the new value. If "SoftCard.GVL.SingleAxis[1].isPosSensor" is triggered, the callback completes the consistent writing of the Boolean type using the same path. From beginning to end, there is no need for the host computer to poll the server. All the latest values ​​are implemented in the local data storage area. When the upper layer reads, it only takes the value immediately according to the logical variable name based on the first mapping.

[0052] This embodiment forms an in-place update path with the second mapping as the core under the session handle through the group binding and data change write-back mechanism, realizes the incremental push of server-side variables and the synchronous maintenance of the local data storage area, reduces the polling bandwidth and latency, improves the consistency and real-time performance when the host computer reads according to the logical variable name, and provides a stable data foundation for subsequent axis control and status query.

[0053] In some embodiments, the control module is configured to: Receive a read request containing a logical variable name, locate the corresponding local memory address according to the first mapping, read the value from the local data storage area according to the data type of the variable, and return it; Receive a write request containing a logical variable name and a target value, call the variable parsing module to obtain the OPCUA node identifier according to the parsing rules, construct an OPCUA data variant that matches the target value data type, and write it to the corresponding node through the session handle; Receives a control request containing the axis number and trajectory parameters, determines the parameter node according to the parsing rules and writes the position, velocity, acceleration and deceleration parameters, sets the execution control bit to start the instruction, makes a status judgment based on the completion flag, error code and busy flag within the preset time window, and resets the execution control bit after the judgment condition is met.

[0054] Specifically, the control module in this embodiment provides a unified calling entry in the order of "read interface→write interface→axis control interface".

[0055] Read interface: Receives a read request containing a logical variable name, locates the target memory address in the local data storage area based on the first mapping, reads the current value from the corresponding storage unit according to the data type recorded in the variable metadata, and returns it; if the variable has not received a subscription update, returns the initial value written during the initialization phase.

[0056] Write interface: Receives a write request containing a logical variable name and a target value, calls the variable parsing module to obtain the corresponding OPCUA node identifier according to the parsing rules, constructs a data variant consistent with the target value data type, and writes it to the target node through the session handle; after writing, the local image is updated by the subscription callback according to the server notification.

[0057] Axis control interface: Receives control requests containing axis number and trajectory parameters, determines parameter nodes based on parsing rules, and writes position, velocity, acceleration, and deceleration parameters in sequence, sets the execution control bit to start the instruction; reads the completion flag, error code, and busy flag according to the sampling period within the preset time window, and makes a status judgment based on the combination of the three; resets the execution control bit after the judgment condition is met, and registers the instruction status and related axis status values ​​obtained by the judgment as readable variables for access by the read interface.

[0058] The key technical terms and features involved in this embodiment are explained below. The specific contents are as follows: The first mapping: an index with the logical variable name as the key and the local memory address as the value, used for address positioning of the read interface.

[0059] Parsing rules and OPCUA node identification: The combination of the namespace identification and node name output by the variable parsing module is used for node addressing of the write interface and axis control interface.

[0060] Execution control bit and status triplet: The execution control bit is used to trigger the action; the completion flag, error code and busy flag constitute the status judgment triplet, which is used to distinguish the instruction status such as completion, error, timeout and unexecuted.

[0061] For example, in some example scenarios, the implementation of this embodiment includes the following process: Read interface example: The host computer requests to read the logical variable name "SoftCard.GVL.SingleAxis[1].stPower.Status". The control module locates the Boolean storage unit in the local data storage area through the first mapping and directly returns the current value; if the variable has not yet reached the first subscription update, it returns the false value written initially.

[0062] Write interface example: The host computer requests to write the logical variable name "SoftCard.GVL.SingleAxis[1].stPower.bRegulatorOn" to true, the control module calls the variable parsing module to obtain the corresponding OPCUA node identifier, constructs a Boolean data variant and writes it through the session handle; then the subscription callback receives the server notification and writes the true value to the corresponding address of the local data storage area.

[0063] Axis control interface example: The host computer initiates absolute position motion for axis 1. The request includes position 100.0, speed 5, acceleration 50, and deceleration 50. The control module determines the "SoftCard.GVL.SingleAxis[1].stMoveAbsolute.Position", "...Velocity", "...Acc", "...Dec" parameter nodes according to the parsing rules and writes them in sequence, and then sets "SoftCard.GVL.SingleAxis[1].stMoveAbsolute.Execute" to true to start the action; reads "SoftCard.GVL.SingleAxis[1].stMoveAbsolute.Done", "...ErrorID", "...Busy" every 10ms within the 1-second time window, and determines that it is completed when Done is true and Busy is false; when ErrorID is non-zero, it is determined as an error; when the time window expires and Busy is true, it is determined to be a timeout; when the time window expires and Done is false and Busy is false, it is determined to be not executed; after the completion judgment, Execute is reset to false, and the instruction status and the current axis status are registered as readable variables for access by the read interface.

[0064] This embodiment forms a unified data reading and writing and motion instruction execution channel through local reading driven by the first mapping, node writing driven by parsing rules, and an axis control closed loop with completion flag / error code / busy flag as the core, ensuring low latency of the read path, addressable write path, and consistent status judgment caliber, providing support for the host computer to complete stable data interaction and servo motion control without directly coupling OPC UA details.

[0065] In some embodiments, setting an execution control bit to start the instruction and performing a status determination based on a completion flag, an error code, and a busy flag within a predetermined time window include: Set the execution control bit to trigger the target instruction and start the timer to limit the preset time window; Determine the status node identifiers of the completion flag, error code, and busy flag associated with the target instruction according to the parsing rules, and read the corresponding status variables through the session handle; Repeatedly read the completion flag, error code and busy flag according to the preset sampling period within the preset time window; The execution status is determined based on the read result. The error status is determined when the error code is not zero; the completion status is determined when the completion flag is true and the busy flag is false; the timeout status is determined when the time window expires and the busy flag is true; the unexecuted status is determined when the time window expires and the completion flag is false and the busy flag is false.

[0066] Specifically, this embodiment follows the sequence of "execution control bit set → timing window activated → state node determination and reading → periodic sampling → four-category state determination." The control module first sets the execution control bit to trigger the target instruction and simultaneously starts the timing to define a preset time window. It then determines the state node identifiers associated with the instruction, including the completion flag, error code, and busy flag, based on parsing rules, and reads the corresponding state variables through the session handle. Within the preset time window, the three types of state variables are repeatedly read at a preset sampling period. When the sampled state meets any of the determination criteria, the determination result is immediately output.

[0067] The key technical terms and features involved in this embodiment are explained below. The specific contents are as follows: Execution control bit: A Boolean control value used to trigger a specific action. After being set, it enters the controlled execution stage.

[0068] Completion flag / error code / busy flag: a ternary state quantity that reflects instruction completion, fault code, and execution occupancy status respectively. The combination of the three is used to distinguish completion, error, timeout, and non-execution.

[0069] Preset time window and sampling period: Uniformly configured by the control strategy, used to limit the observation interval and sampling frequency of state judgment, ensuring that different instructions are judged under the same caliber.

[0070] For example, in some example scenarios, taking the absolute position movement of axis 1 as an example, after completing the parameter node writing, the control module sets "SoftCard.GVL.SingleAxis[1].stMoveAbsolute.Execute" to true and starts timing. The preset time window is 1 second and the sampling period is 10ms. According to the parsing rules, the status node identifier is determined and "SoftCard.GVL.SingleAxis[1].stMoveAbsolute.Done", "SoftCard.GVL.SingleAxis[1].stMoveAbsolute.ErrorID", and "SoftCard.GVL.SingleAxis[1].stMoveAbsolute.Busy" are read through the session handle. Repeat the reading in 10ms cycles within 1 second: If ErrorID is not 0 in any sampling period, it is immediately determined to be in error state; If Done is true and Busy is false in any sampling period, it is determined to be in the completed state; If the time window expires and Busy is true, it is determined to be in a timeout state; If the time window expires and Done is false and Busy is false, it is determined to be in the unexecuted state.

[0071] When any of these results occurs, the control module records the result and ends the current state determination process; the upper layer can use this result for subsequent processing. The above reading and determination process also applies to actions such as return to zero, relative position movement, and uniform speed movement. The state node is pointed to the Done / ErrorID / Busy variable of the corresponding function block by the parsing rules.

[0072] This embodiment forms a consistent judgment path for various types of instructions by combining the completion flag, error code and busy flag in a unified time window and sampling period, ensuring a unified state recognition caliber and clear boundary conditions, and can be directly called by the upper layer for standardized management of action processes.

[0073] In some embodiments, the control module further comprises: The axis status query interface is used to provide readable variables related to the axis, such as the enable status, positive limit sensor status, negative limit sensor status, origin sensor status, operation status enumeration, and function block error flag, based on the local data storage area.

[0074] Specifically, in this embodiment, the axis status query interface within the control module follows the sequence of "status item subscription driver → local mirror read → structured return." First, under the session handle, target variables related to the axis status are added to the subscription set based on variable metadata. These variables include the enable status, positive limit sensor status, negative limit sensor status, origin sensor status, operating status enumeration, function block error flags, and enumerations related to operating energy. After the subscription is activated, the data change callback writes the latest value pushed by the server to the corresponding address in the local data storage area via a second mapping.

[0075] When the host computer issues an axis status query request, the interface receives the axis number and a list of status items. It then determines the local memory address corresponding to each prefixed logical variable name using the first mapping. It then reads the current value from the local data storage according to the data type recorded in the variable metadata, assembles it into a status set, and returns it. To ensure consistent interpretation, operating status uses a preset enumeration code, function block errors use Boolean flags, and limit and origin sensing use Boolean flags.

[0076] The key technical terms and features involved in this embodiment are explained below. The specific contents are as follows: Operation status enumeration: used to identify the kinematic state of the axis, distinguishing Disabled, Errorstop, Stopping, StandStill, DiscreteMotion, ContinuousMotion, SynchronizedMotion, and Homing according to preset codes.

[0077] Running energy enumeration: used to identify the speed / energy change form, and distinguish Constant Velocity, Accelerating, and Decelerating according to preset codes.

[0078] Readable variable: refers to the state quantity that has established the first mapping in the local data storage area. The host computer reads it directly through the logical variable name without accessing the server.

[0079] Type consistency: Boolean values, unsigned integers, and doubles are interpreted according to the data type of the variable metadata when reading to prevent value ambiguity.

[0080] For example, in some example scenarios, taking axis 1 as an example, the variable metadata and subscription collection cover the following status items: enable status "SoftCard.GVL.SingleAxis[1].stPower.Status", positive limit sensor "isPosSensor", negative limit sensor "isNegSensor", origin sensor "isHomeSensor", operating status enumeration "SoftCard.GVL.SingleAxis[1].stAxisStatus.State", operating energy enumeration "SoftCard.GVL.SingleAxis[1].stAxisStatus.EnergyState", function block error flag "SoftCard.GVL.SingleAxis[1].stAxisStatus.FBErrorOccured", and safety-related Boolean quantities such as bErrorStop and bSoftlimit. After the subscription is activated, when any of the above variables on the server side changes, the data change callback uses its OPCUA node identifier to locate the local data storage area through the second mapping and writes the latest value in situ.

[0081] When the host computer calls the axis status query interface, the interface reads the current value of the address corresponding to the aforementioned logical variable name according to the first mapping. For example, when "stPower.Status" is true and "stAxisStatus.State" is the StandStill enumeration value, "isPosSensor" is false, "isNegSensor" is false, "isHomeSensor" is true, "FBErrorOccured" is false, and "bSoftlimit" is false, the interface returns these values ​​as a consistent status set. If any of these items has not yet received the first subscription update, the initial value registered during the initialization phase is returned and marked as the current state of the readable variable. This reading process does not rely on real-time interaction with the server, ensuring stable response even in high-frequency query scenarios.

[0082] This embodiment maintains the local state mirror with subscription drive, performs local direct reading with the first mapping, and adopts unified operation and energy enumeration and error flag encoding to achieve a unified query path for axis enable, limit, origin, operation state and function block errors, reduce the host computer's dependence on the underlying node details and protocol timing, and improve the consistency and timeliness of state acquisition.

[0083] In some embodiments, the system further comprises: The monitoring module is used to send keep-alive requests to the server according to the set period and monitor subscription activity and connection status. It triggers session reconstruction when an anomaly is detected and initiates subscription recovery and callback binding to the memory mapping module after the session is reestablished.

[0084] Specifically, the monitoring module in this embodiment is executed in the order of "keep-alive request → activity determination → exception trigger → session reconstruction → subscription recovery". First, a keep-alive request is sent to the server according to the set period Tka. The keep-alive request is completed by lightweight read operations such as reading the server heartbeat variable or reading the server time to verify that the session handle is in an available state. Then, the subscription activity and connection status are monitored in parallel: the last data change callback timestamp is maintained for each subscription group. When the no callback time exceeds the threshold Tsub or continuous read and write failures occur, the group or connection is marked as degraded. The monitoring module triggers session reconstruction when it detects that the abnormal conditions are met, calls the server connection module to close the old session and create a new session according to the preset client configuration, and generates a new session handle. After the reconstruction is completed, the monitoring module initiates a subscription recovery instruction to the memory mapping module, batch creates subscriptions under the new session based on the variable metadata and the existing grouping strategy and binds the data change callback, and resumes the incremental update and writes it to the local data storage area after the subscription is activated.

[0085] The key technical terms and features involved in this embodiment are explained below. The specific contents are as follows: Keep-alive request period Tka: used to limit the keep-alive frequency, typically 2 to 5 seconds, to ensure timeliness and control server load.

[0086] Subscription activity threshold Tsub: used to determine whether a subscription group is active. It is typically set to 2 to 3 times Tka, taking into account the group size and server push rhythm.

[0087] Abnormal judgment conditions include: continuous failure of session-level keep-alive, no data change callback in the subscription group Tsub, client status identification entering disconnected or unreachable, and key node reading and writing returning error codes.

[0088] Reconstruction idempotence and serialization: Session reconstruction is performed under mutual exclusion control to ensure the atomicity of releasing old session resources and establishing new sessions, avoiding handle competition and repeated callback binding.

[0089] Subscription recovery strategy: Restore by original group, first restore the parameters and status groups closely related to the axis action, then restore the limit and alarm groups, to ensure that the control closed loop is available first.

[0090] For example, in some example scenarios, in a typical deployment, Tka is set to 2 seconds and Tsub is set to 6 seconds. The system has established two types of subscription groups for axis 1: one is the motion parameter and action status group, including "SoftCard.GVL.SingleAxis[1].stMoveAbsolute.Position", "...Velocity", "...Acc", "...Dec", "...Done", "...ErrorID", "...Busy"; the other is the enable and sensor group, including "SoftCard.GVL.SingleAxis[1].stPower.Status", "isPosSensor", "isNegSensor", "isHomeSensor", etc.

[0091] The monitoring module reads the server heartbeat variables at a 2-second cycle and records the last callback timestamp of each group. When a short-term network jitter causes continuous heartbeat failures and the action status group has no callback within 6 seconds, the monitoring module determines that the connection has entered an abnormal state, immediately triggers session reconstruction, and calls the server connection module to establish a new session handle. After the session is successfully reestablished, the monitoring module issues a subscription recovery instruction to the memory mapping module. First, it restores the subscription and callback binding of the motion parameters and action status groups under the new session and activates them, and then restores the enable and sensor groups. After activation is complete, the server continues to push the latest values ​​of variables such as "Done", "ErrorID", and "Busy". The callback writes the changes to the local data storage area through the second mapping, and the reading link to the host computer remains unchanged. The host computer still obtains the current value from the local data storage area through the first mapping using the logical variable name, without the need to perceive the underlying session switch.

[0092] This embodiment forms a closed-loop guarantee mechanism for session availability and subscription continuity through joint monitoring of periodic keep-alive and subscription activity, session reconstruction triggered by abnormal conditions, and rapid subscription recovery based on variable metadata. This ensures that data incremental push can be quickly restored and continuous updates of the local data storage area can be maintained in scenarios of network jitter or connection interruption, reducing the upper computer's perception and adaptation burden on underlying connection fluctuations.

[0093] In some embodiments, the system further comprises: The servo motion control execution interface module is used to uniformly encapsulate the parameter node positioning, execution control bit management and status judgment results of the axis control instructions and provide a single calling entry; it determines the parameter nodes based on the parsing rules of the variable parsing module, completes parameter writing and status acquisition according to the second mapping and session handle, and registers the instruction status and axis status quantities as readable variables in the local data storage area, and provides them to the outside through the data read and write interface of the control module.

[0094] Specifically, in this embodiment, the servo motion control execution interface module is implemented in the following order: "single call entry → parameter node location → parameter writing → execution control bit management → status acquisition and determination → result registration and external provision." It first receives an execution request containing the axis number, action type, and trajectory parameters, and reads the preset time window and sampling period. The variable parsing module then calls the module to determine the OPCUA node identifiers of the parameter node, execution control bit node, and status node corresponding to the action type, based on the parsing rules. Under the session handle, the module sequentially writes trajectory parameters such as position, velocity, acceleration, and deceleration to the parameter node and sets the execution control bit to trigger the instruction. Within the preset time window and sampling period, the module obtains the current values ​​of the completion flag, error code, and busy flag. When any determination condition is met, the instruction status is output and the execution control bit is reset. The instruction status and axis-related status variables are registered as readable variables and written to the local data storage area. The local implementation of the parameters and status is updated in-place in the data change callback via a second mapping. The host computer directly reads the current values ​​using the logical variable name through the control module's data read / write interface.

[0095] The key technical terms and features involved in this embodiment are explained below. The specific contents are as follows: Single call entry: unified encapsulation of parameter node positioning, execution control bit management and status determination results, shielding OPCUA details.

[0096] Parameter node positioning: Determine the OPCUA node identifier from the prefixed logical variable name based on parsing rules, ensuring consistent addressing semantics across devices.

[0097] Execution control bit management: set trigger, reset after judgment is completed, to ensure clear boundaries of each instruction life cycle.

[0098] Status determination: Under a unified time window and sampling period, a standardized instruction status code is generated based on the combination of completion flag, error code and busy flag.

[0099] Local data mirroring: The second mapping is used to directly locate the address of the local data storage area using the OPCUA node identifier, enabling local writing of parameters and status changes.

[0100] For example, in some example scenarios, taking the absolute position movement of axis 1 as an example, the host computer submits an execution request, and the trajectory parameters are position 100.0, velocity 5, acceleration 50, and deceleration 50. The module first locates the OPCUA node identifiers of the parameter nodes "SoftCard.GVL.SingleAxis[1].stMoveAbsolute.Position" "...Velocity" "...Acc" "...Dec", the execution control bit node "SoftCard.GVL.SingleAxis[1].stMoveAbsolute.Execute" and the status node "SoftCard.GVL.SingleAxis[1].stMoveAbsolute.Done" "...ErrorID" "...Busy" according to the parsing rules.

[0101] Under the session handle, write the corresponding values ​​to the above parameter nodes in turn and set Execute to true. The module reads Done, ErrorID and Busy within a 1-second time window according to a 10ms sampling period: when ErrorID is not 0 at any sampling moment, it outputs the error status; when Done is true and Busy is false, it outputs the completion status; when the time window expires and Busy is true, it outputs the timeout status; when the time window expires and Done is false and Busy is false, it outputs the unexecuted status. After the judgment is made, reset Execute to false. During this period, the server's push of changes to the above parameters and status is handled by the data change callback. The callback is located in the local data storage area through the second mapping with the corresponding OPCUA node identifier and written in situ; therefore, the host computer can then obtain the latest parameters and status by reading the prefixed logical variable name through the read interface of the control module without directly accessing the server.

[0102] After the instruction status and axis-related status quantities are registered as readable variables, they are uniformly included in the local data storage area management; the data read and write interface of the control module locates and returns the current value with the logical variable name through the first mapping, and the write interface still relies on the parsing rules and session handle to complete the node writing. The two maintain a consistent reference basis in the two dimensions of address and node.

[0103] This embodiment unifies the parameter node positioning, execution control bit management and status determination results into a single call entry, and combines the local in-situ update driven by the second mapping with the data read and write interface of the control module to achieve a closed-loop connection from instruction triggering to readable results, thereby reducing the coupling of the upper computer to the underlying protocol and node details, and ensuring call consistency and portability in multiple action scenarios.

[0104] The above embodiments provide a detailed description of the structure and functions of the OPC UA-based soft board servo motion control and data interaction system of this application. In practical applications, this system can be developed into a suite of software to implement all of its functions. For example, a suite of "OPC UA-based soft board SDK software" can be developed based on the system structure and functions of the aforementioned embodiments. The following describes in detail the functions, application scenarios, and specific implementation processes of the "OPC UA-based soft board SDK software," using examples from specific scenarios.

[0105] The software revolves around the control and data interaction of soft boards, and uses the OPCUA protocol to build a communication bridge with the soft boards, providing users with a comprehensive and feature-rich interface designed to achieve precise operation and real-time monitoring of soft boards. It is suitable for a variety of industrial automation scenarios and is a key component of soft board management in industrial control systems.

[0106] 1. Features 1. Various server connection types The software is designed to support connections to various server types, with a current focus on OPCUA server connections. Through the ConnectOpcuaServer function, users can enter the server IP address to attempt a connection. This function implements logic for automatically identifying device descriptors, enhancing connection flexibility and compatibility. For example, in real-world applications, this feature automatically adapts to changing network environments or server configurations, reducing manual intervention.

[0107] The software defines the ServerType enumeration type, which clearly lists the supported server types, including OPCUA, ACP, MODEBUS, etc., providing a convenient framework for expanding connections to other types of servers in the future.

[0108] 2. Rich data type support The software boasts powerful data exchange capabilities, supporting read and write operations for a variety of data types, including bool, int16, uint16, int32, uint32, double, and other common data types. This allows users to easily transmit and interact with flexible boards for various data needs, meeting diverse data requirements in different industrial scenarios.

[0109] A series of concise and efficient data read and write interfaces, such as GetBool, GetInt16, and SetDouble, are provided. These interfaces utilize complex internal implementation mechanisms to enable data interaction with the OPCUA server. For example, the GetBool function retrieves the corresponding Boolean value from the server using the OPCUA protocol based on the variable name passed in, performs necessary parsing and conversion, and returns it to the user. Similarly, the SetBool function writes the Boolean value passed in by the user to the specified variable on the server using the OPCUA protocol.

[0110] 3. Data storage and subscription mechanism To achieve efficient data reading and writing, the software implements comprehensive data storage area initialization (InitDateArea), variable memory mapping (such as BindBoolVariable and BindInt16Variable), and OPCUA variable subscription capabilities. During data storage area initialization, the software automatically identifies device descriptors (via the GetDeviceName function). Then, based on predefined variable names and types, it maps variables from the OPCUA server to local memory, establishing a mapping between variable names and memory addresses (implemented through hash tables such as _Bool and _Int16). Furthermore, by subscribing to OPCUA variables, the software receives real-time notifications of server-side variable value changes and promptly updates data in local memory, ensuring real-time and consistency.

[0111] 4. Comprehensive axis control operation The software provides comprehensive control over the flexible card's axes, including power, halt, jog, home, absolute position movement (moveAbsolute), relative position movement (moveRelative), uniform velocity movement (moveVelocity), inch Jog, get axis status (getAxisStatus), reset the axis (reset), reset the drive (reinitDrive), stop, set soft limits (setSoftLimit), set position (setPosition), and controller home (homing). Each operation controls a specific motion or state of the flexible card's axis, meeting the diverse and complex requirements for axis motion in industrial automation.

[0112] 5. Detailed parameter setting and execution control During axis control operations, users can set detailed parameters for each operation, such as movement speed, acceleration, and deceleration. For example, in an absolute position move (moveAbsolute) operation, users need to specify parameters such as the target position (Position), movement speed (vel), acceleration (acc), and deceleration (dec). The software constructs accurate control instructions based on these parameters and sends them to the flexible card via the OPCUA protocol, ensuring that the axis moves along the intended trajectory and speed. Furthermore, each axis control operation returns status information after execution, including whether the operation was successful, whether an error occurred, and the error code, facilitating error handling and status monitoring. For example, during a drive reset (reinitDrive) operation, the software waits for the operation to complete and determines whether the reset was successful based on the returned status. If it fails, the error code can be used for further troubleshooting.

[0113] 6. Axis status monitoring and feedback A wealth of axis status monitoring features are provided, allowing users to obtain the current state of the axis at any time, such as whether it is enabled (bPower), whether it is returning to home (bHome), whether an error has occurred (bError), the axis's busy state (bbusy), and the specific error type (such as bErrorStop, an emergency stop error, or bSoftlimit, a soft limit error). This status information allows users to understand the axis's operating status in real time, identify potential problems promptly, and take appropriate measures. For example, in an automated production process, if an axis error occurs, users can quickly locate the root cause based on the error type and perform appropriate repairs to ensure continuous and stable production.

[0114] 7. Real-time data monitoring Leveraging OPCUA's subscription mechanism, the software enables real-time monitoring of flex board data. Functions such as isPosSensor, isNegSensor, and isHomeSensor allow users to obtain axis limit status, indicating whether the axis has encountered a positive limit, negative limit, or the origin. Furthermore, the getAxisStatus function retrieves detailed axis status information, including information on whether the axis is in Disabled, Errorstop, Stopping, StandStill, DiscreteMotion, ContinuousMotion, SynchronizedMotion, or Homing states, as well as motor energy changes (such as ConstantVelocity, Accelerating, Decelerating), and function block errors (FBErrorOccured). This real-time monitoring data provides users with a comprehensive understanding of the flex board's operating status, helping to promptly detect and respond to abnormalities.

[0115] 8. Timely feedback mechanism During axis control operations and data monitoring, the software provides timely feedback to the user on the operating status and error information of the flexible board. For example, in axis control operations, each operation function returns a status code indicating the result of the operation. If the operation is successful, 0 is returned; if an error occurs, the corresponding error code is returned, such as -99 for an uncleared axis error or -10 for an execution timeout. Based on this feedback, the user can quickly determine whether the operation was successful and take appropriate action. Regarding data monitoring, when the flexible board data changes, the software promptly notifies the user through a callback function (such as handler_DataChanged), ensuring that the user has real-time access to the latest status information, improving system responsiveness and reliability.

[0116] 2. Application Scenarios This software has a wide range of applications in industrial automation, particularly in environments requiring precise control and real-time monitoring of flexible circuit boards. For example, in automated production lines, it can be used to control the axis motion of various automated equipment, enabling precise positioning, processing, and assembly operations. In CNC machine tools, it can precisely control the machine's coordinate axes to ensure machining accuracy and efficiency. In robotic control, it serves as a key component for robot joint control, enabling flexible movement and precise operation. By providing a unified interface and rich functionality, the software facilitates developer integration into various industrial automation control systems, effectively improving the overall system performance and reliability, and providing strong support for industrial automation production.

[0117] 3. Software Features 1) Data initialization process 1. First, the program attempts to connect to the OPCUA server via the IP address and checks the heartbeat of the slave computer.

[0118] 2. After the connection is successful, the program reads the configuration file. The configuration file contains the parameter ID (nodeid), parameter type, initial value, and other settings required for interacting with the server.

[0119] 3. After reading the configuration file, the program registers the OPCUA subscription to the server in the form of one subscription request for every 100 variables.

[0120] 4. After creating a subscription request, the program binds a callback function. This callback function will be called when the data is updated to process the new data.

[0121] 5. After binding the callback function, the program activates the subscription. This step causes the server to start sending data updates to the client.

[0122] 6. After activating the subscription, the program enters a loop, waiting for data updates sent by the server. When the data is updated, the callback function is triggered.

[0123] 7. After the callback function is triggered, the program obtains the nodeid of the data. Nodeid is a data structure used to uniquely identify a node in OPCUA.

[0124] 8. After obtaining the nodeid, the program searches for the corresponding memory address through a map (a data structure used to store the mapping relationship between nodeid and memory address).

[0125] 9. After finding the corresponding memory address, the program writes the received data value to the memory. This completes the process of obtaining data from the server and storing it in local memory. Then, re-enter step 5 and call the activation subscription function.

[0126] 2) Software usage process The process mainly includes the following steps: start the software → connect the soft board → perform the operation → process the operation → obtain status and feedback → end. The specific operation process is as follows: 1. The program starts running and initializes global variables and related data structures.

[0127] 2. Call the ConnectServer function to attempt to connect to the soft card server (currently the OPCUA server) based on the IP address entered by the user. If the connection is successful, set the server communication mode to OPCUA and start the status monitoring thread; if the connection fails, return an error message.

[0128] 3. According to user needs, call corresponding function, such as axis control function (power, halt, moveAbsolute, etc.), data read and write function (GetBool, SetInt16, etc.) or other function (such as test function).

[0129] 4. Within the function, perform operations based on the function's purpose. For axis control functions, construct control instructions and send them to the flexible board via the OPCUA protocol. Then, wait for the operation to complete and obtain the execution result. For data read and write functions, interact with the server via the OPCUA protocol to read or write data. For test functions, execute a series of test logic, including obtaining variable values, modifying values, sending instructions, and verifying the results.

[0130] 5. During or after the operation, call the status acquisition function (such as getAxisStatus, GetBool, etc.) as needed to obtain the status information of the soft board or related variables, and feedback the status information to the user so that the user can understand the operation execution status and the current status of the soft board.

[0131] The software continues to run, waiting for the user to perform the next operation, until the program is closed.

[0132] 3) Connecting soft board function This function mainly includes the following process: user calls the connection function → checks the connection type → initializes the data storage area → creates a client connection. The specific operation process is as follows: 1. The user calls the ConnectOpcuaServer function in the program and passes in the IP address of the soft card server.

[0133] 2. Inside the function, first check whether the current server communication mode (_ServerType) is OPCUA. If it is not an OPCUA connection, execute the subsequent connection steps. If it is already an OPCUA connection, terminate the current connection (closing the connection, waiting for the thread to terminate, etc.), and then proceed to the subsequent connection steps.

[0134] 3. Call the ConnectServer function of the OpcuaClient class and pass in the IP address. Within this function, first call the InitDateArea function of the OpcuaData class to initialize the data storage area. This process includes identifying the device descriptor, establishing an OPCUA client connection, and creating a variable memory mapping. If data storage area initialization fails, an error message is returned to the user.

[0135] 4. After successfully initializing the data storage area, create an OPCUA client instance (UA_Client_new), set the default configuration (UA_ClientConfig_setDefault), and then attempt to connect to the server (UA_Client_connect). If the connection fails, delete the client instance (UA_Client_delete) and return an error message. If the connection is successful, set the device descriptor (_device), start the heartbeat thread (to prevent the server from automatically disconnecting the client), and return a connection success message.

[0136] 4) Axis enable operation function This function mainly includes the following process: user calls the enable function → checks the connection type → checks the axis error status → sends the enable instruction parameters → waits for the enable operation to be completed. The specific operation process is as follows: 1. The user calls the power function of the SMC class in the program and passes in the axis number (axis) and the enable status (power, 1 means enabled, 0 means disabled).

[0137] 2. The function first checks the current server connection status. If no connection is established, it outputs a "Connection not established" prompt message and returns -1.

[0138] 3. Next, use the GetBool function of the OpcuaData class to retrieve the error status of the specified axis ("SoftCard.GVL.SingleAxis["+ std::to_string(axis)+"].bError"). If an axis error exists, an error message is output and -99 is returned.

[0139] 4. If the axis is error-free, use the SetBool function of the OpcuaClient class to send the enable status value to the axis enable variable corresponding to the soft card ("SoftCard.GVL.SingleAxis["+std::to_string(axis)+"].stPower.bRegulatorOn"). If parameter sending fails, an error message is output and -1 is returned.

[0140] 5. After sending the parameters, the program enters a loop and waits for the enable operation to complete. Within the loop, it retrieves the axis enable status ("SoftCard.GVL.SingleAxis ["+ std::to_string (axis) +"].stPower.Status") and error code ("SoftCard.GVL.SingleAxis ["+ std::to_string (axis) +"].stPower.ErrorID"). If the error code is not 0, the operation failed and the error code is returned. If the enable status is inconsistent with the expected status and the wait time is less than 1 second, the program continues waiting. If the enable status is consistent, the program returns 0 to indicate a successful enable operation. If the wait time exceeds 1 second and the axis is still busy ("SoftCard.GVL.SingleAxis ["+ std::to_string (axis) +"].stPower.Busy" is true), the program returns -10 to indicate an execution timeout. If the wait time exceeds 1 second and the axis is not busy, the program returns -20 to indicate failure.

[0141] 5) Axis motion operation function (taking moveAbsolute as an example) This function mainly includes the following process: the user calls the absolute position motion function → checks the connection type → checks the axis status → sends the motion parameters → starts the action → waits for the motion operation to complete. The specific operation process is as follows: 1. The user calls the moveAbsolute function of the SMC class in the program and passes in the axis number (axis), target position (Position), velocity (vel, default is 5), acceleration (acc, default is 50) and deceleration (dec, default is 50).

[0142] 2. The function first checks the current server connection status. If no connection is established, it outputs a "Connection not established" prompt message and returns -1.

[0143] 3. Next, use the GetBool function of the OpcuaData class to obtain the error status ("SoftCard.GVL.SingleAxis["+ std::to_string (axis) +"].bError") and busy status ("SoftCard.GVL.SingleAxis["+ std::to_string (axis) +"].bbusy") of the specified axis. If an axis has an outstanding error, an error message is output and the return value is -99. If the axis is in motion, an error message is output and the return value is -98.

[0144] 4. If the axis has no errors and is not in motion, use the SetDouble function of the OpcuaClient class to send the target position, velocity, acceleration, and deceleration values ​​to the absolute position motion variables of the axis corresponding to the soft card ("SoftCard.GVL.SingleAxis["+ std::to_string (axis)+"].stMoveAbsolute.Position", "SoftCard.GVL.SingleAxis["+ std::to_string (axis)+"].stMoveAbsolute.Velocity", etc.).

[0145] 5. Then, use the SetBool function to send the execution instruction ("SoftCard.GVL.SingleAxis["+std::to_string (axis) +"].stMoveAbsolute.Execute" is set to true). If parameter sending fails or the instruction fails to start, the corresponding error message is output and -1 or -2 is returned, respectively.

[0146] 6. After sending the parameters, enter a loop and wait for the motion operation to complete. In the loop, obtain the completion status ("SoftCard.GVL.SingleAxis ["+ std::to_string (axis) +"].stMoveAbsolute.Done") and error code ("SoftCard.GVL.SingleAxis ["+ std::to_string (axis) +"].stMoveAbsolute.ErrorID") of the axis absolute position motion operation. If the error code is not 0, the operation failed and the error code is returned. If the motion operation is not complete and the wait time is less than 1 second, the wait is continued. If the motion operation is complete, 0 is returned to indicate success. If the wait time exceeds 1 second and the axis is still busy ("SoftCard.GVL.SingleAxis["+ std::to_string (axis) +"].stMoveAbsolute.Busy" is true), -10 is returned to indicate execution timeout. If the wait time exceeds 1 second and the axis is not busy, -20 is returned to indicate failure. After the operation is complete, the execution instruction is set to false ("SoftCard.GVL.SingleAxis["+ std::to_string (axis) +"].stMoveAbsolute.Execute" is set to false).

[0147] 6) Data reading function (taking GetBool as an example) This function mainly includes the following process: the user calls the data reading function → obtains data through the OPCUA client → searches for variables in OpcuaData. The specific operation process is as follows: 1. The user calls the GetBool function of the SMC class in the program and passes in the name of the Boolean variable to be read.

[0148] 2. Call the GetBool function of the OpcuaClient class to obtain data. In the GetBool function of the OpcuaClient class, the GetBool function of the OpcuaData class is first called.

[0149] 3. The GetBool function of the OpcuaData class searches for the corresponding variable in the internal hash table (_Bool) based on the variable name passed in. If the variable is not found (the key with that name does not exist in the hash table), it outputs the prompt "Unsubscribed Bool variable" and returns false. If the variable is found, it obtains the memory address corresponding to the variable, reads the value in memory, and returns it.

[0150] 7) Data writing function (taking SetBool as an example) This function mainly includes the following process: user calls the data write function → builds the OPCUA data variant → parses the variable name to obtain the node ID → writes the data to the OPCUA server. The specific operation process is as follows: 1. The user calls the SetBool function of the SMC class in the program and passes in the name of the Boolean variable to be written (name) and the value to be set (value).

[0151] 2. Create an OPCUA data variant (UA_Variant) within the function and use the UA_Variant_setScalar function to set the incoming Boolean value to the variant, while specifying the data type as Boolean (UA_TYPES_BOOLEAN).

[0152] 3. Pass the variable name (with the device descriptor prefix, i.e. _device+name) to the parseString function of the OpcuaClient class to parse out the namespace (ns) and node name (s), and then use UA_NODEID_STRING to create the OPCUA node ID.

[0153] 4. Use the UA_Client_writeValueAttribute function to write the data variant to the node specified by the OPCUA server. If the write is successful, the function returns true; if the write fails, the function outputs a "write failed" prompt message and returns false.

[0154] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the technical solutions of the present application are described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present application, and should all be included in the scope of protection of the present application.

Claims

1. A soft board servo motion control and data interaction system based on OPCUA, characterized in that: include: The server connection module is used to select OPCUA according to the server address and establish a client session, and output the session handle; The variable parsing module is used to read the configuration and device descriptors, generate parsing rules from logical variable names to OPCUA node identifiers, and output variable metadata; A memory mapping module is configured to allocate a local data storage area based on the variable metadata, establish a mapping from logical variable names to local memory addresses and a mapping from OPCUA node identifiers to local memory addresses, create subscriptions in batches under the session handle, bind data change callbacks, and write changes to server variables to the local data storage area; A control module is used to provide a data read and write interface and an axis control interface to a host computer, wherein data reading is to obtain values ​​from the local data storage area according to the logical variable name, and data writing is to construct an OPCUA data variant according to the parsing rule and write it to the corresponding node via the session handle; The axis control interface receives the axis number and trajectory parameters, writes the position, speed, acceleration and deceleration parameters into the corresponding node and sets the execution control bit, determines the instruction status based on the completion flag, error code and busy flag, and provides the instruction status and axis status as readable variables to the data read and write interface.

2. The system according to claim 1, wherein: The method of selecting OPCUA according to the server address and establishing a client session and outputting a session handle includes: Receive the server address and set the communication mode to OPCUA; When an existing client session is detected, the session is closed and resources are released, and an OPCUA client instance is created based on the preset client configuration. Resolve the target connection endpoint according to the server address and initiate a session establishment request to the server; When the session is successfully established, a session handle is generated and registered, and the session handle is provided to the variable parsing module, the memory mapping module and the control module for calling.

3. The system according to claim 1, wherein: The configuration and device descriptors are read, and parsing rules from logical variable names to OPCUA node identifiers are generated and variable metadata is output, including: Read the configuration file to obtain the logical variable name, data type and initial value related to the variable; Determine a device prefix based on the device descriptor, and perform standardization processing on the logical variable name to form a logical variable name with a prefix; According to preset naming and mapping rules, the logical variable name with the prefix is ​​parsed into an OPCUA node identifier, wherein the OPCUA node identifier includes a namespace identifier and a node name; Perform consistency check on the parsing results to confirm the correspondence between the logical variable name and the corresponding data type and OPCUA node identifier; Generate and register variable metadata, and provide the variable metadata to the memory mapping module and the control module for calling.

4. The system according to claim 1, wherein: The allocating a local data storage area according to the variable metadata, establishing a mapping from a logical variable name to a local memory address and a mapping from an OPCUA node identifier to a local memory address, includes: Parse the variable metadata to obtain the logical variable name, data type, initial value and OPCUA node identifier corresponding to each variable; Configuring a storage unit according to the data type, allocating a local data storage area and writing the initial value into the corresponding storage unit; Determine and register a local memory address for each logical variable name, and establish a first mapping from the logical variable name to the local memory address divided by data type; Based on the correspondence between the OPC UA node identifier and the local memory address, a second mapping from the OPC UA node identifier to the local memory address is established.

5. The system according to claim 4, characterized in that The step of creating subscriptions in batches under the session handle and binding data change callbacks, and writing changes to server variables into the local data storage area, includes: Determining a target variable set to be subscribed based on the variable metadata; The target variable set is grouped according to a preset strategy, and a subscription request is created for each group under the session handle, a data change callback is bound, and the subscription is activated; Upon receiving a data change notification including an OPC UA node identifier and a changed value, calling the second mapping to locate a corresponding local memory address according to the OPC UA node identifier; The changed value is processed for type consistency according to the data type of the variable metadata record, and the changed value is written into a corresponding storage unit in the local data storage area.

6. The system according to claim 4, characterized in that The control module is used for: receiving a read request including a logical variable name, locating a corresponding local memory address according to the first mapping, reading a value from the local data storage area according to the data type of the variable, and returning the value; Receive a write request containing a logical variable name and a target value, call a variable parsing module to obtain an OPCUA node identifier according to a parsing rule, construct an OPCUA data variant that matches the target value data type, and write the data to the corresponding node through the session handle; Receive a control request containing an axis number and trajectory parameters, determine the parameter node according to the parsing rule and write the position, speed, acceleration and deceleration parameters, set the execution control bit to start the instruction, perform status judgment based on the completion flag, error code and busy flag within a preset time window, and reset the execution control bit after the judgment condition is met.

7. The system according to claim 6, characterized in that The execution control bit is set to start the instruction, and the status is determined according to the completion flag, error code and busy flag within the preset time window, including: Set the execution control bit to trigger the target instruction and start the timer to limit the preset time window; Determine the status node identifiers of the completion flag, error code, and busy flag associated with the target instruction according to the parsing rule, and read the corresponding status variables through the session handle; Repeatedly reading the completion flag, error code, and busy flag according to a preset sampling period within the preset time window; The execution status is determined based on the read result. The error status is determined when the error code is not zero; the completion status is determined when the completion flag is true and the busy flag is false; the timeout status is determined when the time window expires and the busy flag is true; the unexecuted status is determined when the time window expires and the completion flag is false and the busy flag is false.

8. The system according to claim 1, wherein: The control module further includes: The axis status query interface is used to provide readable variables related to the axis, such as the enable status, positive limit sensor status, negative limit sensor status, origin sensor status, operation status enumeration, and function block error flag, based on the local data storage area.

9. The system according to claim 1, wherein: The system further comprises: The monitoring module is used to send keep-alive requests to the server according to a set period and monitor subscription activity and connection status, trigger session reconstruction when an anomaly is detected, and initiate subscription recovery and callback binding for the memory mapping module after the session is reestablished.

10. The system according to claim 1, wherein: The system further comprises: The servo motion control execution interface module is used to uniformly encapsulate the parameter node positioning, execution control bit management and status judgment results of the axis control instruction and provide a single calling entry; the parameter node is determined based on the parsing rules of the variable parsing module, and parameter writing and status acquisition are completed according to the second mapping and session handle, and the instruction status and axis status quantities are registered as readable variables and stored in the local data storage area, and are provided to the outside through the data read and write interface of the control module.

Images