OPCUA-based soft board card servo motion control and data interaction system

Abstract

The application provides a soft board card servo motion control and data interaction system based on OPCUA. It includes: a server connection module for selecting OPCUA according to the server address and establishing a client session, and outputting a session handle; a variable analysis module for generating a resolution rule of logical variable name to OPCUA node identification and outputting variable metadata; a memory mapping module for creating a subscription under the session handle in batches and binding a data change callback, and writing the change of the server variable to a local data storage area; a control module for providing a data read-write interface and an axis control interface to the upper computer; determining the instruction state based on the completion flag, error code and busy flag, and providing the instruction state and axis state quantity as readable variables to the data read-write interface. The application can realize variable analysis and OPCUA node addressing, local data mirroring and low-latency read-write driven by subscription, parameterized execution of axis control closed loop, and unified state determination based on completion / error / busy.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of industrial automation, and particularly relates to a soft board card servo motion control and data interaction system based on OPCUA. BACKGROUND

[0002] In the industrial automation scene, the upper computer often carries motion control logic through a soft board card, and interacts with a control object through an industrial protocol such as OPCUA to realize parameter setting, instruction issuing and state acquisition of a shaft. With the expansion of device interconnection, there are problems such as coexistence of multiple protocols such as OPCUA, Modbus and ACP, heterogeneous variable naming space and dispersed node addressing, which increase the access and maintenance costs.

[0003] The prior art relies on a general OPCUA client or a PLC manufacturer driver to complete data interaction through point-by-point reading and writing or periodic polling, lacks parameterized control abstraction for servo shafts, unified mapping of variables to local memory and batch subscription update mechanism, and the association determination of completion flags, error codes and busy flags is often combined by the business side, which leads to dispersed instruction execution closed loop, insufficient state consistency and non-unified interface. At the same time, device descriptor changes and node renaming easily cause variable mapping mismatch, polling causes bandwidth occupation and time delay fluctuation, and there is a lack of session keep-alive and subscription robustness design, which makes it difficult to support multi-axis real-time control and cross-device expansion. SUMMARY

[0004] Therefore, the embodiments of the present application provide a soft board card servo motion control and data interaction system based on OPCUA to solve the problems of non-unified variable analysis and OPCUA node addressing, lack of local mirroring of subscription-driven data interaction, and lack of parameterized control and unified determination of servo shaft instructions in the prior art.

[0005] The embodiment of the application provides a kind of soft board card servo motion control and data interaction system based on OPCUA, comprising: server connection module, for selecting OPCUA according to server address and establishing client session, output session handle;Variable analysis module, for reading configuration and equipment descriptor, generate logical variable name to the analysis rule of OPCUA node identification and output variable metadata;Memory mapping module, for according to variable metadata allocation local data storage area, establish logical variable name to the mapping of local memory address and the mapping of OPCUA node identification to local memory address, and in session handle under batch creation subscription and bind data change callback, the change of server variable is written into local data storage area;Control module, for providing data read-write interface and shaft control interface to host computer, wherein data reading is according to logical variable name from local data storage area, data writing is according to analysis rule to build OPCUA data variant and write into corresponding node by session handle;Shaft control interface receives shaft number and trajectory parameter, writes position, speed, acceleration and deceleration parameter into corresponding node and sets execution control bit, determines instruction state based on completion flag, error code and busy flag, and provides instruction state and shaft state variable as readable variable to data read-write interface.

[0006] The above at least one technical scheme adopted by the embodiment of the application can achieve the following beneficial effects:

[0007] Through server connection module, for selecting OPCUA according to server address and establishing client session, output session handle;Variable analysis module, for reading configuration and equipment descriptor, generate logical variable name to the analysis rule of OPCUA node identification and output variable metadata;Memory mapping module, for according to variable metadata allocation local data storage area, establish logical variable name to the mapping of local memory address and the mapping of OPCUA node identification to local memory address, and in session handle under batch creation subscription and bind data change callback, the change of server variable is written into local data storage area;Control module, for providing data read-write interface and shaft control interface to host computer, wherein data reading is according to logical variable name from local data storage area, data writing is according to analysis rule to build OPCUA data variant and write into corresponding node by session handle;Shaft control interface receives shaft number and trajectory parameter, writes position, speed, acceleration and deceleration parameter into corresponding node and sets execution control bit, determines instruction state based on completion flag, error code and busy flag, and provides instruction state and shaft state variable as readable variable to data read-write interface. The application can realize variable analysis and OPCUA node addressing uniformity, subscription driven local data mirroring and low latency read-write, shaft control parameterized execution closed loop and unified state determination based on completion / error / busy. BRIEF DESCRIPTION OF DRAWINGS

[0008] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the embodiments or prior art description will be briefly introduced. Obviously, the drawings in the following description only some embodiments of the present application, and for those skilled in the art, other drawings can be obtained without creative labor on the basis of these drawings.

[0009] Figure 1 Figure 1 is a structural composition schematic diagram of the OPCUA-based soft board card servo motion control and data interaction system provided by the embodiments of the present application. DETAILED DESCRIPTION

[0010] In the following description, specific details are set forth in order to provide a thorough understanding of the embodiments of the present application. However, persons skilled in the art should understand that the present application can also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted so as not to obscure the description of the present application with unnecessary details.

[0011] In the prior art, the host computer usually carries motion control logic through a soft board card, and interacts with control objects through industrial protocols such as OPCUA. In engineering practice, multiple protocols such as OPCUA, Modbus, and ACP often coexist, and the variable namespace and node addressing are scattered. The general client usually adopts point-by-point reading and writing or polling update, and lacks parameterized control abstraction and unified state determination path for servo axes. When the device descriptor or node renaming is changed, the variable mapping is easily mismatched, the long connection keep-alive and subscription robustness are insufficient, and the real-time control and expansion maintenance of multiple axes are affected.

[0012] Therefore, the prior art still has the following problems: how to realize the unification of variable analysis and OPCUA node addressing; how to build a subscription-driven local data mirror to reduce polling and reduce reading and writing delay; how to provide parameterized execution of servo axis instructions and unified determination based on completion / error / busy, while taking into account session keep-alive and subscription recovery, and improve system portability and maintainability.

[0013] In view of the problems in the prior art, the application provides a soft board card servo motion control and data interaction system based on OPCUA, which comprises a server connection module, a variable analysis module, a memory mapping module and a control module.

[0014] The technical scheme of the application can realize unified management of variable analysis and OPCUA node addressing, construct a local data mirror based on subscription driving, reduce polling bandwidth and read-write time delay, form a parameterized execution closed loop and unified state determination path of servo shaft instructions, and provide consistent interface semantics and facilitate upper layer application integration.

[0015] The specific structure and functions of the soft board card servo motion control and data interaction system based on OPCUA provided by the embodiments of the application will be described in detail below in combination with the accompanying drawings and specific embodiments. Figure 1 The structure of the soft board card servo motion control and data interaction system based on OPCUA provided by the embodiments of the application is shown in FIG. 1. Figure 1 As shown in FIG. 1, the soft board card servo motion control and data interaction system based on OPCUA can specifically comprise the following modules:

[0016] The server connection module 101 is configured to select OPCUA according to a server address, establish a client session, and output a session handle.

[0017] The variable analysis module 102 is configured to read a configuration and a device descriptor, generate an analysis rule of a logical variable name to an OPCUA node identifier, and output variable metadata.

[0018] The memory mapping module 103 is configured to allocate a local data storage area according to the variable metadata, establish a mapping of the logical variable name to the local memory address and a mapping of the OPCUA node identifier to the local memory address, create a subscription and bind a data change callback in batches under the session handle, and write changes of server variables to the local data storage area.

[0019] The control module 104 is configured to provide a data read-write interface and an axis control interface to the host computer, wherein data reading is performed according to a logical variable name to obtain a value from a local data storage area, and data writing is performed according to a parsing rule to construct an OPCUA data variant and write the data variant into a corresponding node through a session handle;

[0020] The axis control interface receives an axis number and a trajectory parameter, writes position, speed, acceleration and deceleration parameters into corresponding nodes and sets an execution control bit, determines an instruction state based on a completion flag, an error code and a busy flag, and provides the instruction state and an axis state variable as readable variables to the data read-write interface.

[0021] In some embodiments, an OPCUA is selected according to a server address, and a client session is established, and a session handle is output, including:

[0022] The server address is received, and a communication mode is set to OPCUA;

[0023] When it is detected that there is an existing client session, session closing and resource releasing are performed, and an OPCUA client instance is created according to a preset client configuration;

[0024] A target connection endpoint is parsed according to the server address, and a session establishment request is initiated to the server;

[0025] When the session establishment is successful, a session handle is generated and registered, and the session handle is provided to a variable parsing module, a memory mapping module and a control module for calling.

[0026] Specifically, in the present embodiment, the server connection module performs the sequence of “communication mode setting → inventory session cleaning → client instantiation → endpoint parsing → session establishment → handle registration and distribution”. First, the server address is received, and the communication mode is set to OPCUA, and the connection state is entered. Then, it is detected whether there is an existing client session, and if there is, session closing, subscription notification revocation and resource releasing are sequentially performed to ensure connection idempotent switching. Then, an OPCUA client instance is created according to a preset client configuration, which includes security policy, session timeout, retry strategy and certificate parameters. The module parses the input server address to obtain a target connection endpoint that meets the policy and initiates a session establishment request. After the session establishment is successful, a session handle is generated, the handle is uniquely registered and written into a session management table, and the session reference is published to the variable parsing module, the memory mapping module and the control module.

[0027] The key technical terms and features involved in the present embodiment are explained as follows:

[0028] Session handle: a unique identifier indicating the current OPCUA session resource and its access context, used to pass the session reference across modules and specify the attribution of subsequent read-write and subscription operations.

[0029] Pre-set client configuration: A set of connection parameters pre-configured for different deployment environments, including security and timeout boundaries, endpoint selection strategies, and certificate loading strategies, to ensure portability and consistency of instantiation processes.

[0030] Endpoint resolution strategy: Normalize and probe the input server address, select the matching endpoint item according to the priority of the strategy, and output the target connection endpoint for connection establishment, avoiding direct coupling between the upper layer and the lower layer endpoint enumeration and change.

[0031] Concurrent and idempotent control: Session switching is serialized using exclusive locks, and the release of the old session and the establishment of the new session have step atomicity, preventing resource hanging and reference invalidation from spreading between modules.

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

[0033] The module creates an OPCUA client instance according to the pre-set client configuration of the current site, loads security and timeout parameters, and completes certificate loading. Then it performs endpoint resolution on the input address, selects the target connection endpoint that meets the strategy, and initiates a session establishment request.

[0034] When the server returns a successful response to the establishment, the module generates a session handle and registers it in the session management table, provides the session handle to the variable resolution module to read the configuration and device descriptor, provides the session handle to the memory mapping module to create subscriptions and bind data change callbacks in batches, and provides the session handle to the control module to support data writing and axis control interface execution.

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

[0036] In some embodiments, read the configuration and device descriptor, generate a resolution rule for logical variable names to OPCUA node identifiers, and output variable metadata, including:

[0037] Read the configuration file to obtain logical variable names, data types, and initial values related to variables;

[0038] Determine the device prefix based on the device descriptor, and standardize the logical variable name to form a prefixed logical variable name;

[0039] According to the preset naming and mapping rules, the prefixed logical variable name is parsed into an OPCUA node identifier, the OPCUA node identifier including a namespace identifier and a node name;

[0040] The consistency of the parsing result is checked to confirm the corresponding relationship between the logical variable name and the corresponding data type and the OPCUA node identifier;

[0041] Variable metadata is generated and registered, and the variable metadata is provided to the memory mapping module and the control module.

[0042] Specifically, in the embodiment, the variable parsing module executes in the order of "configuration acquisition → device prefix determination → logical variable standardization → node identifier parsing → 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. Then, the device prefix is determined according to the device descriptor, which is used to distinguish different soft board card instances. Then, the logical variable name is standardized, including level separator normalization, uniformity of case and array index format, necessary name space padding, and concatenation of the device prefix in the header to generate a prefixed logical variable name. The module parses the prefixed logical variable name into an OPCUA node identifier according to the preset naming and mapping rules, and the node identifier includes a namespace identifier and a node name. After the parsing is completed, the consistency of the result is checked to establish a one-to-one correspondence between the logical variable name, the data type and the OPCUA node identifier, and the checking content includes data type matching, node reachability and initial value writability. Finally, variable metadata is generated and registered, and the variable metadata is provided to the memory mapping module and the control module.

[0043] The key technical terms and features involved in the embodiment are explained and described as follows:

[0044] Device prefix determination mechanism: generate a prefix identifier based on the device descriptor to decouple isomorphic variables between different soft board card instances and realize the portability of logical variable names across devices.

[0045] Standardization rule set: unify the hierarchical path, array index and naming specification to maintain stable mapping between upper-layer configuration and lower-layer node naming and reduce addressing deviation caused by engineering naming differences.

[0046] Node identifier parsing strategy: simultaneously output the namespace identifier and the node name through the mapping rule to ensure the integrity of addressing; when there are nodes with the same name, the target is selected according to the namespace priority and the path integrity.

[0047] Consistency check link: serially check the data type, node reachability and initial value writability to ensure that the subsequent memory mapping and subscription establishment have a reliable reference basis.

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

[0049] The variable parsing module first determines the device prefix according to the device descriptor, splices the logical variable name and the device prefix to form a prefixed logical variable name. Then, the corresponding OPCUA node identifier is parsed according to the preset rule, wherein the namespace identifier and the node name are from the server-side namespace configuration and the hierarchical node path, respectively.

[0050] The module performs consistency checking on the parsing result, confirms that the data type of the variable is consistent with the data type of the server-side node, the node is in an accessible state, and the initial value has write permission. After the checking passes, the variable metadata is generated, recording the logical variable name, data type, initial value, and OPCUA node identifier, and the metadata is provided to the memory mapping module for establishing the first mapping of the logical variable name to the local memory address and the second mapping of the OPCUA node identifier to the local memory address, and to the control module for data reading and writing and axis control parameter node positioning.

[0051] The present embodiment determines the device prefix, normalizes the variable name, parses the node identifier in two elements, and performs consistency checking, thereby constructing a stable mapping from the logical variable to the OPCUA node and a usable metadata output mechanism, improving the consistency and portability of variable addressing, and providing a reliable reference basis for subsequent memory mapping, batch subscription, and axis control parameter node positioning.

[0052] In some embodiments, a local data storage area is allocated according to the variable metadata, and a mapping of the logical variable name to the local memory address and a mapping of the OPCUA node identifier to the local memory address are established, including:

[0053] Parsing the variable metadata to obtain the logical variable name, data type, initial value, and OPCUA node identifier corresponding to each variable;

[0054] Configuring storage units according to the data type, allocating the local data storage area, and writing the initial value into the corresponding storage unit;

[0055] Determining and registering the local memory address for each logical variable name, and establishing a first mapping of the logical variable name to the local memory address divided by data type;

[0056] Based on the correspondence between the OPCUA node identifier and the local memory address, a second mapping of the OPCUA node identifier to the local memory address is established.

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

[0058] The key technical terms and features involved in the embodiment are explained and described as follows:

[0059] Typed storage unit: For bool, int16, uint16, int32, uint32, double, etc., a storage area is configured respectively to ensure the type consistency and address alignment requirements of the reading path.

[0060] First mapping: The reading path facing the host computer with logical variable name addressing, positioning the target memory address and directly reading the corresponding type of value.

[0061] Second mapping: Node addressing for subscription callback and write path, quickly positioning the target memory address according to the OPC UA node identifier, and realizing in-place updating of changed values.

[0062] Initial value writing strategy: After allocation is completed, the initial value in the metadata is written to the corresponding storage unit, so that the reading result has determinacy before the first subscription update arrives.

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

[0064] The memory mapping module reads the above metadata, allocates a storage unit matching the type for each item in the local data storage area and writes an initial value of 0 or false. Then a first mapping is generated to establish a key-value correspondence between each prefixed logical variable name and its local memory address, and a second mapping is generated to establish a key-value correspondence between the OPCUA node identifier (including namespace identifier and node name) corresponding to each variable and the same memory address.

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

[0066] The embodiment establishes a stable and consistent local data mirror addressing system through type-based allocation and initial value writing, 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 subscription and reliable calling of shaft control parameter nodes.

[0067] In some embodiments, a subscription is created in batches under a session handle and a data change callback is bound, and changes in server variables are written to the local data storage area, including:

[0068] Determining a target variable set that needs to be subscribed based on variable metadata;

[0069] Grouping the target variable set according to a preset strategy, creating a subscription request for each group under the session handle and binding a data change callback, and activating the subscription;

[0070] Upon receiving a data change notification containing an OPCUA node identifier and a changed value, the second mapping is called to locate the corresponding local memory address according to the OPCUA node identifier;

[0071] Processing the changed value according to the data type recorded in the variable metadata, and writing the changed value to the corresponding storage unit in the local data storage area.

[0072] Specifically, in the present embodiment, the memory mapping module performs the sequential process of "target set determination → group subscription → callback binding → notification processing writeback" under the session handle. First, based on the variable metadata, the target variable set that needs to be tracked in real time is screened, including the axis parameter node and the state node, the limit and origin sensor node, and the fault-related node in priority. Then, the target variable set is grouped according to the preset strategy, each group does not exceed 100 items, and is aggregated by namespace and function domain as much as possible to reduce the server push jitter and client processing peak. Under the session handle, a subscription is created for each group and a data change callback is bound, and after activation, it enters a continuous receiving state. When receiving a notification containing the OPCUA node identifier and the changed value, the callback routine calls the second mapping to locate the corresponding local memory address according to the OPCUA node identifier, performs type-consistent 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.

[0073] The key technical terms and features involved in the present embodiment are explained and described as follows:

[0074] Group subscription strategy: The upper limit of a single subscription is not more than 100 items, and aggregation by namespace and function domain is prioritized to facilitate efficient packaging by the server and low-cost unpacking by the client.

[0075] Second mapping: Addressing index with OPCUA node identifier as key and local memory address as value, ensuring that the callback processing can directly locate the storage location without the need to parse the logical variable name again.

[0076] Type-consistent processing: Strictly according to the data type declared in the variable metadata to perform conversion and writing, avoiding storage misplacement or reading ambiguity caused by different data types.

[0077] For example, in some example scenarios, in a typical deployment, the target variable set includes parameters and state items related to single-axis absolute position motion, such as "SoftCard.GVL.SingleAxis[i].stMoveAbsolute.Position" "...Velocity" "...Acc" "...Dec" "...Done" "...ErrorID" "...Busy", and "SoftCard.GVL.SingleAxis[i].stPower.Status" "isPosSensor" "isNegSensor" "isHomeSensor" and the like related to enablement and limit. The module divides the above-mentioned variables into two groups according to the preset strategy: the first group is motion parameters and action states, and the second group is enablement and sensing states and fault-related quantities, each group does not exceed 100 items. The system creates a subscription for each group under the session handle and binds a data change callback, and after the subscription is activated, the server starts pushing incremental updates.

[0078] When the server side sets "SoftCard.GVL.SingleAxis[1].stMoveAbsolute.Done" to true, the callback receives the notification and parses the corresponding OPCUA node identifier, 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; then if "SoftCard.GVL.SingleAxis[1].stMoveAbsolute.ErrorID" changes to a certain 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" triggers, the callback completes consistent writing of the Boolean type through the same path. Throughout the process, the host computer does not need to poll the server, and all the latest values are landed in the local data storage area. When the upper layer reads, it only takes values according to the logical variable name in real time according to the first mapping.

[0079] The embodiment forms an in-place updating path with the second mapping as the core under the session handle through the grouping subscription and data change rewriting mechanism, realizes the incremental pushing of the server side variable and the synchronous maintenance of the local data storage area, reduces the polling bandwidth and time delay, improves the consistency and real-time performance of the host computer when reading according to the logical variable name, and provides a stable data basis for subsequent axis control and state query.

[0080] In some embodiments, the control module is configured to:

[0081] 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;

[0082] receive a write request containing a logical variable name and a target value, call the variable parsing module to obtain an OPCUA node identifier according to the parsing rule, construct an OPCUA data variant matching the data type of the target value, and write to the corresponding node through the session handle;

[0083] receive a control request containing an axis number and a trajectory parameter, 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, and determine the state according to the completion flag, error code and busy flag within a preset time window, and reset the execution control bit after reaching the determination condition.

[0084] Specifically, the control module in the embodiment provides a unified calling entrance around the sequence of "read interface -> write interface -> axis control interface".

[0085] Read interface: receives a read request containing a logical variable name, locates the target memory address in the local data storage 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, the initial value written in the initialization phase is returned.

[0086] 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 rule, constructs a data variant consistent with the data type of the target value, and writes the target node through the session handle; the local mirror after writing is updated by the subscription callback according to the server notification.

[0087] Axis control interface: receives a control request containing an axis number and trajectory parameters, determines the parameter nodes according to the parsing rule and writes the position, speed, acceleration and deceleration parameters in order, sets the execution control bit to start the instruction; reads the completion flag, error code and busy flag at the sampling period within the preset time window, and makes a state determination according to the combination of the three; after reaching the determination condition, the execution control bit is reset, and the instruction state obtained by the determination and the related axis state quantity are registered as readable variables for the read interface to access.

[0088] The key technical terms and features involved in the present embodiment are explained and described as follows:

[0089] First mapping: an index with logical variable name as key and local memory address as value, used for address positioning of the read interface.

[0090] Parsing rule and OPCUA node identifier: the combination of namespace identifier and node name output by the variable parsing module, used for node addressing of the write interface and axis control interface.

[0091] Execution control bit and state triple: the execution control bit is used to trigger action; the completion flag, error code and busy flag constitute the state determination triple, which is used to distinguish the instruction states of completion, error, timeout and non-execution.

[0092] For example, in some example scenarios, the implementation manner of the present embodiment includes the following flow:

[0093] 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 type storage unit in the local data storage through the first mapping, and directly returns the current value; if the variable has not reached the first subscription update, the false value written in the initialization is returned.

[0094] Write interface example: Host computer requests to write logical variable name "SoftCard.GVL.SingleAxis[1].stPower.bRegulatorOn" to true, control module calls variable resolution module to get corresponding OPCUA node identifier, constructs Boolean data variant and writes through session handle; then receives server notification by subscription callback and writes true value to corresponding address in local data storage area.

[0095] Axis control interface example: Host computer initiates absolute position movement for axis 1, requests to contain position 100.0, velocity 5, acceleration 50, deceleration 50. Control module determines "SoftCard.GVL.SingleAxis[1].stMoveAbsolute.Position" "…Velocity" "…Acc" "…Dec" parameter nodes according to resolution rules and writes in turn, then sets "SoftCard.GVL.SingleAxis[1].stMoveAbsolute.Execute" to true to start action; reads "SoftCard.GVL.SingleAxis[1].stMoveAbsolute.Done" "…ErrorID" "…Busy" every 10 ms within a 1-second time window, when Done is true and Busy is false, it is determined to be completed; when ErrorID is non-zero, it is determined to be 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 completion determination, Execute is reset to false, and the instruction state and the current axis state quantity are registered as readable variables for read interface access.

[0096] This embodiment forms a unified data read-write and motion instruction execution channel through local reading driven by the first mapping, node writing driven by the resolution rule, and axis control closed loop with completion flag / error code / busy flag as the core, ensures low latency in read path, addressable in write path, and consistent in state determination, and provides support for host computer to complete stable data interaction and servo motion control without directly coupling OPCUA details.

[0097] In some embodiments, the execution control bit is set to start the instruction, and the state is determined according to the completion flag, error code and busy flag within a preset time window, including:

[0098] The execution control bit is set to trigger the target instruction, and the timing is started to limit the preset time window;

[0099] The state nodes of the completion flag, error code and busy flag associated with the target instruction are determined according to the resolution rule, and the corresponding state variables are read through the session handle;

[0100] repeating reading the completion flag, the error code and the busy flag at a preset sampling period within a preset time window;

[0101] performing state determination based on the reading result, determining an error state when the error code is not zero, determining a completion state when the completion flag is true and the busy flag is false, determining a timeout state when the time window expires and the busy flag is true, and determining a non-execution state when the time window expires, the completion flag is false and the busy flag is false.

[0102] Specifically, the embodiment is implemented in the order of "execution control bit setting -> timing window starting -> state node determination and reading -> period sampling -> four-state determination". The control module first sets the execution control bit to trigger the target instruction, and starts timing to define a preset time window. Then, the state node identifiers of the completion flag, the error code and the busy flag associated with the instruction are determined according to the analysis rule, and the corresponding state variables are read through the session handle. The above three types of state variables are repeatedly read at a preset sampling period within a preset time window; when the sampled state satisfies any determination condition, the determination result is immediately output.

[0103] The key technical terms and features involved in the embodiment are explained and described as follows:

[0104] Execution control bit: a Boolean control variable for triggering a specific action, which is set to enter the controlled execution phase.

[0105] Completion flag / error code / busy flag: three-state variables reflecting the instruction completion, fault encoding and execution occupation state, respectively, which are combined to distinguish completion, error, timeout and non-execution.

[0106] Preset time window and sampling period: configured uniformly by the control strategy, used to define the observation interval and sampling frequency of state determination, and to ensure that different instructions are determined under a unified standard.

[0107] 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 10 ms. According to the analysis rule, the state node identifier is determined, and “SoftCard.GVL.SingleAxis[1].stMoveAbsolute.Done” “SoftCard.GVL.SingleAxis[1].stMoveAbsolute.ErrorID” “SoftCard.GVL.SingleAxis[1].stMoveAbsolute.Busy” are read through the session handle. The reading is repeated at a period of 10 ms within 1 second:

[0108] If ErrorID is not 0 in any sampling period, it is immediately determined as an error state;

[0109] If Done is true and Busy is false in any sampling period, it is determined as a completion state;

[0110] If the time window expires and Busy is true, it is determined as a timeout state;

[0111] If the time window expires and Done is false and Busy is false, it is determined as an unexecuted state.

[0112] When any of the above results occurs, the control module records the determination result and ends the state determination process this time; the upper layer can perform subsequent processing according to the result. The above reading and determination process is also applicable to the zero reset, relative position movement, uniform speed movement, etc. The state node is pointed to the Done / ErrorID / Busy variables of the corresponding function block by the analysis rule.

[0113] The embodiment combines the completion flag, error code and busy flag under the unified time window and sampling period to form a consistent determination path for various instructions, ensures the unified state recognition range and clear boundary conditions, and can be directly called by the upper layer for standardized management of the action flow.

[0114] In some embodiments, the control module further comprises:

[0115] The axis state query interface is configured to provide readable variables of the enabling state, the positive limit sensing state, the negative limit sensing state, the origin sensing state, the running state enumeration and the function block error flag related to the axis based on the local data storage area.

[0116] Specifically, in the present embodiment, the shaft status query interface within the control module performs around the order of "status item subscription driving -> local mirror reading -> structured return". First, under the session handle, the target variables related to shaft status are added to the subscription set according to the variable metadata, including the enable state, the positive limit sensor state, the negative limit sensor state, the origin sensor state, the running state enumeration, the function block error flag, and the enumeration quantity related to the running energy. After the subscription is activated, the latest value pushed by the server is written to the corresponding address of the local data storage area by the data change callback through the second mapping.

[0117] When the host computer issues a shaft status query request, the interface receives the shaft number and the status item list, determines the local memory address corresponding to each prefixed logical variable name according to the first mapping, reads the current value from the local data storage area according to the data type recorded in the variable metadata, and assembles it into a status set and returns it. To ensure consistent standards, the running state uses a preset enumeration code, the function block error uses a Boolean flag, and the limit and origin sensor uses a Boolean flag.

[0118] The key technical terms and features involved in the present embodiment are explained and described as follows:

[0119] Running state enumeration: used to identify the kinematic state of the shaft, and the Disabled, Errorstop, Stopping, StandStill, DiscreteMotion, ContinuousMotion, SynchronizedMotion, Homing are distinguished according to the preset encoding.

[0120] Running energy enumeration: used to identify the speed / energy change form, and the ConstantVelocity, Accelerating, Decelerating are distinguished according to the preset encoding.

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

[0122] Type consistent processing: Boolean, unsigned integer, and double precision are all interpreted according to the data type of the variable metadata when reading to prevent value ambiguity.

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

[0124] When the host computer calls the axis state query interface, the interface reads the current values of the addresses corresponding to the above-mentioned logical variable names 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 set of states; if any of them has not received the first subscription update, the initial value registered in the initialization phase is returned and marked as the instant state of the current readable variable. This reading process does not depend on instant interaction with the server, ensuring stable response in high-frequency query scenarios.

[0125] The embodiment realizes unified query paths for axis enablement, limit, home, running state, and function block error by maintaining a local state mirror with subscription driving, performing local direct reading with the first mapping, and adopting unified running and energy enumeration and error flag coding, reduces the dependence of the host computer on the details of the underlying node and the protocol timing, and improves the consistency and timeliness of state acquisition.

[0126] In some embodiments, the system further comprises:

[0127] The monitoring module is configured to send a keep-alive request to the server at a set period and monitor subscription activity and connection status, trigger session reconstruction when an abnormality is detected, and initiate subscription recovery and callback binding for the memory mapping module after session reconstruction.

[0128] Specifically, the monitoring module in the embodiment executes in the order of "keep-alive request → activity determination → abnormality triggering → session reconstruction → subscription recovery". First, a keep-alive request is sent to the server at a set period Tka, and the keep-alive request is completed by a light read operation such as reading a server heartbeat variable or reading a server time, to verify that the session handle is in an available state. Then, subscription activity and connection status are monitored in parallel: a last data change callback timestamp is maintained for each subscription group, and when there is no callback for more than a threshold Tsub or consecutive read / write failures occur, the group or connection is marked as degraded. The monitoring module triggers session reconstruction when an abnormal condition is detected, 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 completion of the reconstruction, the monitoring module initiates a subscription recovery instruction to the memory mapping module, creates subscriptions and binds data change callbacks in bulk under the new session based on variable metadata and existing group policies, and activates the subscriptions to resume incremental update writing to the local data storage area.

[0129] The key technical terms and features involved in the embodiment are explained as follows:

[0130] Keep-alive request period Tka: used to limit the keep-alive frequency, typically 2 to 5 seconds, to ensure timeliness and control server load.

[0131] Subscription activity threshold Tsub: used to determine whether a subscription group is active, typically 2 to 3 times Tka, set in combination with group size and server push rhythm.

[0132] Abnormality determination conditions: including consecutive failures of session-level keep-alive, no data change callback for a subscription group within Tsub, client state identifier entering disconnected or unreachable, and key node read / write returning error codes.

[0133] Reconstruction idempotency and serialization: session reconstruction is executed under mutual exclusion control to ensure atomicity of old session resource release and new session establishment, avoiding handle competition and repeated callback binding.

[0134] Subscription recovery strategy: restore according to the original group, first restore parameters and state groups closely related to axis actions, then restore limit and alarm groups, to ensure that the control closed loop is available first.

[0135] 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 a motion parameter and action state group, including "SoftCard.GVL.SingleAxis[1].stMoveAbsolute.Position" "...Velocity" "...Acc" "...Dec" "...Done" "...ErrorID" "...Busy"; the other is an enablement and sensor group, including "SoftCard.GVL.SingleAxis[1].stPower.Status" "isPosSensor" "isNegSensor" "isHomeSensor", etc.

[0136] The monitoring module reads the server heartbeat variable at a 2-second cycle and records the last callback timestamp of each group. When the network appears to be short and jittery, causing the heartbeat to fail continuously and the action state group to have no callback within 6 seconds, the monitoring module determines that the connection enters an abnormal state, immediately triggers session reconstruction, and calls the server connection module to establish a new session handle. After the session reconstruction is successful, the monitoring module issues a subscription recovery instruction to the memory mapping module, first restores the subscription and callback binding of the motion parameter and action state group under the new session and activates it, and then restores the enablement and sensor group; after activation is complete, the server continues to push the latest values of the "Done" "ErrorID" "Busy" variables, and the callback writes the changes to the local data storage area through the second mapping. The reading link of the upper computer remains unchanged, and the upper computer still obtains the current value from the local data storage area through the first mapping with the logical variable name, without the need to perceive the underlying session switching.

[0137] The embodiment forms a closed-loop protection mechanism for session availability and subscription continuity through periodic keep-alive and subscription activity joint monitoring, session reconstruction triggered by abnormal conditions, and rapid subscription recovery based on variable metadata, ensuring that data incremental push can still be quickly recovered and the local data storage area can be continuously updated in network jitter or connection interruption scenarios, reducing the perception and adaptation burden of the underlying connection fluctuations on the upper computer side.

[0138] In some embodiments, the system further comprises:

[0139] The servo motion control execution interface module is used for positioning the parameter nodes of the axis control instruction, managing the execution control bits, and uniformly packaging and providing a single calling entry for the state determination result; the parameter nodes are determined based on the analysis rules of the variable analysis module, the parameter writing and state acquisition are completed based on the second mapping and the session handle, and the instruction state and axis state quantity are registered as readable variables and stored in the local data storage area, and are provided to the outside through the data reading and writing interface of the control module.

[0140] Specifically, in the embodiment, the servo motion control execution interface module implements the sequence of "single call entry→parameter node positioning→parameter writing→execution control bit management→state acquisition and judgment→result registration and external provision". First, the execution request containing the axis number, action type and trajectory parameters is received, and the preset time window and sampling period are read. Then the variable analysis module is called to determine the OPCUA node identifier of the parameter node, execution control bit node and the state node of the completion flag, error code and busy flag corresponding to the action type according to the analysis rule. The module writes the trajectory parameters such as position, speed, acceleration and deceleration to the parameter node in order under the session handle, and sets the execution control bit to trigger the instruction. The current values of the completion flag, error code and busy flag are obtained at the sampling period within the preset time window; when any judgment condition is met, the instruction state is output and the execution control bit is reset. The instruction state and the state quantity related to the axis are registered as readable variables and written to the local data storage area, wherein the local landing of parameters and states is updated in place in the data change callback through the second mapping; the host computer directly reads the current value through the data read-write interface of the control module with the logical variable name.

[0141] The key technical terms and features involved in the embodiment are explained and described as follows:

[0142] Single call entry: unified encapsulation of parameter node positioning, execution control bit management and state judgment result, shielding OPCUA details.

[0143] Parameter node positioning: based on the analysis rule, the OPCUA node identifier is determined by the logical variable name with prefix, ensuring consistent addressing semantics across devices.

[0144] Execution control bit management: set to trigger, reset after completion of judgment, ensuring clear boundaries of each instruction life cycle.

[0145] State judgment: based on the combination of completion flag, error code and busy flag, a standardized instruction state code is generated under the unified time window and sampling period.

[0146] Local data mirroring: the second mapping is used to directly locate the local data storage area address with the OPCUA node identifier, realizing in-place writing of parameter and state changes.

[0147] For example, in some example scenarios, taking the absolute position movement of axis 1 as an example, the host computer submits an execution request with the trajectory parameters being position 100.0, velocity 5, acceleration 50, and deceleration 50. The module first locates 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 state nodes “SoftCard.GVL.SingleAxis[1].stMoveAbsolute.Done” “…ErrorID” “…Busy” according to the parsing rules, and the OPCUA node identifiers.

[0148] The corresponding values are sequentially written to the above-mentioned parameter nodes under the session handle, and the Execute is set to true. The module reads the Done, ErrorID, and Busy in a 1-second time window with a 10ms sampling period: when ErrorID is not 0 at any sampling time, the error state is output; when Done is true and Busy is false, the completion state is output; when the time window expires and Busy is true, the timeout state is output; when the time window expires and Done is false and Busy is false, the non-execution state is output. After the determination is generated, the Execute is reset to false. The changes of the above-mentioned parameters and states by the server are pushed by the data change callback processing, and the callback is located to the local data storage area according to the corresponding OPCUA node identifier through the second mapping and is written in place; therefore, the host computer can obtain the latest parameters and states by reading the logical variable name with a prefix through the read interface of the control module, without directly accessing the server.

[0149] The instruction state and the state quantity related to the axis are uniformly included in the local data storage area management after being registered as readable variables; the data read-write interface of the control module is located and returns the current value through the first mapping with the logical variable name, and the write interface still relies on the parsing rules and the session handle to complete the node writing, and the two are consistent in the address and node two dimensions.

[0150] The embodiment realizes the closed-loop connection from instruction triggering to result reading by uniformly encapsulating the parameter node positioning, execution control bit management, and state determination result as a single call entry, and combining the local in-place update driven by the second mapping and the data read-write interface of the control module, reduces the coupling degree of the host computer to the underlying protocol and node details, and guarantees the call consistency and portability in the multi-action scenario.

[0151] The above embodiments detail the structure and function of the OPCUA-based soft board card servo motion control and data interaction system of the present application. The system can be developed into a software to realize all functions in practical applications. For example, a "OPCUA-based soft board card SDK software" can be developed based on the system structure and function of the foregoing embodiments. The function, application scenario, and specific implementation process of each function of the "OPCUA-based soft board card SDK software" will be described in detail below in conjunction with examples in specific scenarios.

[0152] The software is centered around the control and data interaction of the soft board card, and builds a communication bridge with the soft board card with the help of the OPCUA protocol, providing a comprehensive and function-rich interface for users, aiming to realize precise operation and real-time monitoring of the soft board card, and is suitable for various industrial automation scenarios, and is a key component of soft board card management in industrial control systems.

[0153] I. Functional characteristics

[0154] 1. Multiple server connection types

[0155] The software design supports connection to multiple server types, and currently implements the OPCUA server connection function. Through the ConnectOpcuaServer function, users can input the server IP address to attempt to establish a connection. This function internally implements automatic device descriptor recognition logic, enhancing the flexibility and compatibility of the connection. For example, in practical applications, when the soft board card is connected to different network environments or the server configuration changes, this function can automatically adapt, reducing manual intervention.

[0156] The software defines the ServerType enumeration type, which clearly lists the supported server types, including OPCUA, ACP, MODEBUS, etc., providing a convenient framework for future extension of other server connection types.

[0157] 2. Rich data type support

[0158] The software has strong data interaction capabilities, supporting read and write operations for multiple data types, including bool, int16, uint16, int32, uint32, double, and other common data types. This allows users to easily transmit and interact with various data from the soft board card, meeting the diverse data needs of different industrial scenarios.

[0159] A series of concise and efficient data read-write interfaces are provided, such as GetBool, GetInt16, SetDouble, etc. These interfaces realize data interaction with OPC UA server through internal complex implementation mechanisms. Taking the GetBool function as an example, it will get the corresponding boolean value from the server through the OPC UA protocol according to the input variable name, and return it to the user after necessary parsing and conversion. Similarly, the SetBool function will write the boolean value input by the user into the specified variable of the server through the OPC UA protocol.

[0160] 3. Data storage and subscription mechanism

[0161] In order to realize efficient data reading and writing, the software internally implements perfect data storage area initialization (InitDateArea), variable memory mapping (such as BindBoolVariable, BindInt16Variable, etc.), and subscription of OPC UA variables. During the data storage area initialization process, the software will automatically identify the device descriptor (through the GetDeviceName function), and then map the variables in the OPC UA server to the local memory space according to the predefined variable name and type, establishing the mapping relationship between the variable name and the memory address (implemented through the _Bool, _Int16 hash table). At the same time, by subscribing to OPC UA variables, the software can receive real-time notifications of changes in server-side variable values and update the data in the local memory in a timely manner, ensuring the real-time and consistency of the data.

[0162] 4. Comprehensive axis control operation

[0163] The software provides comprehensive control functions for the soft board card axis, including power, halt, jog, home, moveAbsolute, moveRelative, moveVelocity, inchJog, getAxisStatus, reset, reinitDrive, stop, setSoftLimit, setPosition, homing, etc. Each operation controls the specific movement or state of the soft board card axis, meeting the various complex needs of axis movement in industrial automation.

[0164] 5. Fine parameter setting and execution control

[0165] In the axis control operation, users can set detailed parameters for each operation, such as movement speed, acceleration, deceleration, etc. For example, in the absolute position movement (moveAbsolute) operation, users need to specify parameters such as target position (Position), movement speed (vel), acceleration (acc), and deceleration (dec). The software will construct accurate control instructions according to these parameters and send them to the soft board card through the OPC UA protocol, ensuring that the axis moves according to the expected trajectory and speed. At the same time, each axis control operation will return corresponding status information after execution, such as whether the operation is successfully completed, whether an error is reported, and the error code, etc., to facilitate users to handle errors and monitor the status. For example, in the drive reset (reinitDrive) operation, the software will wait for the operation to complete and determine whether it is successfully reset according to the returned status. If it fails, it can further troubleshoot the problem according to the error code.

[0166] 6、Axis state monitoring and feedback

[0167] Rich axis state monitoring functions are provided, and users can obtain the current state of the axis at any time, such as whether it is in the enabled state (bPower), whether it is homing (bHome), whether an error has occurred (bError), the busy state of the axis (bbusy), and the specific error type (such as emergency stop error bErrorStop, soft limit error bSoftlimit, etc.). Through these status information, users can understand the running situation of the axis in real time, discover potential problems in time and take corresponding measures. For example, in the automatic production process, if an error occurs in the axis, users can quickly locate the problem source according to the error type and perform corresponding repair operations to ensure the continuity and stability of production.

[0168] 7、Real-time data monitoring

[0169] With the subscription mechanism of OPC UA, the software realizes real-time monitoring of the relevant data of the soft board card. Users can obtain the limit state of the shaft through functions such as isPosSensor, isNegSensor, and isHomeSensor, i.e., whether the shaft has encountered a positive limit, a negative limit, or a home position. In addition, through the getAxisStatus function, detailed status information of the shaft can be obtained, including whether the shaft is in the Disabled, Errorstop, Stopping, StandStill, DiscreteMotion, ContinuousMotion, SynchronizedMotion, Homing, etc. state, as well as the energy change of the motor (such as ConstantVelocity, Accelerating, Decelerating) and function block error (FBErrorOccured) etc. These real-time monitoring data provide users with a comprehensive perspective of the running state of the soft board card, helping to discover abnormal situations in time and respond.

[0170] 8. Timely feedback mechanism

[0171] During the shaft control operation and data monitoring process, the software can timely feedback the running state and error information of the soft board card to the user. For example, during the shaft control operation, each operation function will return a status code indicating the execution 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 indicating that there is an uncorrected error in the shaft, -10 indicating that the execution has timed out, etc. Users can quickly determine whether the operation is successful based on these feedback information and take appropriate handling measures. In terms of data monitoring, when the data of the soft board card changes, the software will timely notify the user through the callback function (such as handler_DataChanged) to ensure that the user can obtain the latest status information in real time, improving the response speed and reliability of the system.

[0172] II. Application scenarios

[0173] The software has a wide range of application scenarios in the field of industrial automation, especially in environments that require precise control and real-time monitoring of the soft board card. For example, in an automated production line, it can be used to control the shaft movement of various automated equipment to achieve precise positioning, processing, and assembly operations; in a numerical control machine tool, it can precisely control the coordinate axes of the machine tool to ensure processing precision and efficiency; in the field of robot control, it can be used as a key component for robot joint control to achieve flexible movement and precise operation of the robot. By providing a unified interface and rich functions, the software facilitates developers to integrate it into various industrial automation control systems, effectively improving the overall performance and reliability of the system, and providing strong support for industrial automation production.

[0174] III. Software Function

[0175] 1) Data initialization process

[0176] 1. First, the program attempts to connect to the OPCUA server through the IP address and checks the lower machine heartbeat.

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

[0178] 3. After reading the configuration file, the program registers an OPCUA subscription with the server according to the form of one subscription request per 100 variables.

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

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

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

[0182] 7. After the callback function is triggered, the program gets the nodeid of the data. nodeid is a data structure used to uniquely identify nodes in OPCUA.

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

[0184] 9. After finding the corresponding memory address, the program writes the received data value to the memory. In this way, the program has completed the process of obtaining data from the server and storing it to the local memory. Then re-enter step 5, call the activate subscription function.

[0185] 2) Software usage process

[0186] This process mainly includes the following processes: starting the software → connecting the soft board card → executing the operation → operation processing → obtaining the state and feedback → ending. The specific operation process is as follows:

[0187] 1. The program starts running, initializes global variables and related data structures.

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

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

[0190] 4. Inside the function function, perform the corresponding operation according to the function function. For axis control functions, construct control instructions and send them to the soft board card through the OPCUA protocol, then wait for the operation to complete and get the execution result; for data read-write functions, interact with the server through the OPCUA protocol to achieve data reading or writing; for test functions, execute a series of test logic, including obtaining variable values, modifying values, sending instructions, and verifying results.

[0191] 5. During the operation execution process or after the operation is completed, call the state acquisition function (such as getAxisStatus, GetBool, etc.) as needed to obtain the state information of the soft board card or related variables, and feed back the state information to the user, so that the user can understand the operation execution situation and the current state of the soft board card.

[0192] The software continues to run and waits for the user to perform the next operation until the program is closed.

[0193] 3) Connect soft board card function

[0194] This function mainly includes the following processes: 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:

[0195] 1. The user calls the ConnectOpcuaServer function in the program and passes in the IP address of the soft board card server.

[0196] 2. The function first checks whether the current server communication mode (_ServerType) is OPCUA. If it is not an OPCUA connection, perform the subsequent connection steps; if it is already an OPCUA connection, stop the current connection (close the connection, wait for the thread to end, etc.) first, then continue with the subsequent connection steps.

[0197] 3. Call the ConnectServer function of the OpcuaClient class, passing in the IP address. Inside the function, first call the InitDateArea function of the OpcuaData class to initialize the data storage area. This process includes operations such as identifying the device descriptor, creating an OPCUA client connection, establishing a variable memory mapping, etc. If the data storage area initialization fails, return an error message to the user.

[0198] 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 interrupting the client connection), and return a connection success message.

[0199] 4) Axis enable operation function

[0200] This function mainly includes the following processes: user calls the enable function → checks the connection type → checks the axis error state → sends the enable instruction parameter → waits for the enable operation to complete. The specific operation process is as follows:

[0201] 1. The user calls the power function of the SMC class in the program and passes in the axis number (axis) and the enable state (power, 1 for enable, 0 for disable).

[0202] 2. First, check the current server connection state inside the function. If the connection is not established, output the "connection not established" prompt message and return -1.

[0203] 3. Then, get the error state of the specified axis ("SoftCard.GVL.SingleAxis ["+ std::to_string (axis) +"].bError") through the GetBool function of the OpcuaData class. If there is an error that has not been cleared, output the error prompt message and return -99.

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

[0205] 5. After sending the parameters, enter a loop to wait for the completion of the enable operation. In the loop, get the axis enable state ("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, it indicates that the operation has an error, and the error code is returned; if the enable state is inconsistent with the expected state and the waiting time does not exceed 1 second, continue waiting; if the enable state is consistent, return 0 to indicate that the enable operation is successful; if the waiting time exceeds 1 second and the axis is still busy ("SoftCard.GVL.SingleAxis ["+ std::to_string (axis) +"].stPower.Busy" is true), return -10 to indicate that the execution has timed out; if the waiting time exceeds 1 second and the axis is not busy, return -20 to indicate that the execution has not been performed.

[0206] 5) Axis action operation function (take moveAbsolute as an example)

[0207] This function mainly includes the following processes: user calls the absolute position motion function → checks the connection type → checks the axis state → sends the motion parameters → starts the action → waits for the completion of the motion operation. The specific operation process is as follows:

[0208] 1. The user calls the moveAbsolute function of the SMC class in the program and passes in the axis number (axis), target position (Position), speed (vel, default 5), acceleration (acc, default 50), and deceleration (dec, default 50).

[0209] 2. The function first checks the current server connection state. If the connection is not established, output the "connection not established" prompt message and return -1.

[0210] 3. Next, get the error status and busy status of the specified axis ("SoftCard.GVL.SingleAxis ["+ std::to_string (axis) +"].bError") and ("SoftCard.GVL.SingleAxis ["+ std::to_string (axis) +"].bbusy") by the GetBool function of the OpcuaData class. If there is an un-cleared error for the axis, output an error prompt and return -99; if the axis is in motion, output a prompt and return -98.

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

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

[0213] 6. After sending the parameters, enter a loop to wait for the completion of the motion operation. In the loop, get the completion status of the absolute position motion operation of the axis ("SoftCard.GVL.SingleAxis ["+ std::to_string (axis) +"].stMoveAbsolute.Done") and the error code ("SoftCard.GVL.SingleAxis ["+ std::to_string(axis) +"].stMoveAbsolute.ErrorID"). If the error code is not 0, it indicates that the operation has an error, and the error code is returned; if the motion operation is not completed and the waiting time does not exceed 1 second, continue waiting; if the motion operation is completed, return 0 to indicate that the motion operation is successful; if the waiting time exceeds 1 second and the axis is still busy ("SoftCard.GVL.SingleAxis["+ std::to_string (axis) +"].stMoveAbsolute.Busy" is true), return -10 to indicate that the execution has timed out; if the waiting time exceeds 1 second and the axis is not busy, return -20 to indicate that the execution has not been performed. After the operation is completed, the execution instruction is set to false ("SoftCard.GVL.SingleAxis ["+ std::to_string (axis) +"].stMoveAbsolute.Execute" is set to false).

[0214] 6) Data reading function (taking GetBool as an example)

[0215] This function mainly includes the following processes: the user calls the data reading function → obtains data through the OPCUA client → finds the variable in OpcuaData. The specific operation process is as follows:

[0216] 1. The user calls the GetBool function of the SMC class in the program and inputs the Boolean variable name (name) to be read.

[0217] 2. The GetBool function of the OpcuaClient class is called inside the function to obtain data. In the GetBool function of the OpcuaClient class, the GetBool function of the OpcuaData class is first called.

[0218] 3. The GetBool function of the OpcuaData class looks up the corresponding variable in the internal hash table (_Bool) according to the variable name passed in. If the variable is not found (there is no key with the name in the hash table), the "Unsubscribed Bool variable" prompt information is output, and false is returned; if the variable is found, the memory address corresponding to the variable is obtained, the value in the memory is read, and the value is returned.

[0219] 7) Data writing function (taking SetBool as an example)

[0220] The function mainly includes the following processes: the user calls the data writing function, builds an OPCUA data variant, parses the variable name to obtain the node ID, and writes data to the OPCUA server. The specific operation process is as follows:

[0221] 1. The user calls the SetBool function of the SMC class in the program, and passes in the Boolean variable name (name) to be written and the value (value) to be set.

[0222] 2. The function internally creates an OPCUA data variant (UA_Variant), and uses the UA_Variant_setScalar function to set the passed-in Boolean value to the variant, and specifies the data type as Boolean (UA_TYPES_BOOLEAN).

[0223] 3. The variable name (with the device descriptor prefix, i.e. _device+name) is passed into the parseString function of the OpcuaClient class to parse the namespace (ns) and node name (s), and then UA_NODEID_STRING is used to create an OPCUA node ID.

[0224] 4. The data variant is written to the OPCUA server specified node through the UA_Client_writeValueAttribute function. If the writing is successful, true is returned; if the writing fails, the "writing failed" prompt information is output, and false is returned.

[0225] The above embodiments are only used to illustrate the technical solutions of the present application, but not to limit them; although the technical solutions of the present application are described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacement for part of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should be included in the protection scope of the present application.

Claims

1. An OPCUA-based soft board card servo motion control and data interaction system, characterized in that, The application comprises: a server connection module for selecting OPCUA according to a server address and establishing a client session, outputting a session handle; a variable analysis module for reading configuration and device descriptors, generating an analysis rule of logical variable names to OPCUA node identifiers and outputting variable metadata; a memory mapping module for allocating a local data storage area according to the variable metadata, establishing a mapping of logical variable names to local memory addresses and a mapping of OPCUA node identifiers to local memory addresses, creating a subscription in batches under the session handle and binding a data change callback, and writing changes of server variables to the local data storage area; a control module for providing a data read-write interface and an axis control interface to an upper computer, wherein data reading is based on logical variable names to obtain values from the local data storage area, and data writing is based on the analysis rule to construct an OPCUA data variant and write it to a corresponding node through the session handle; the axis control interface receives an axis number and trajectory parameters, writes position, speed, acceleration and deceleration parameters to corresponding nodes and sets an execution control bit, determines an instruction state based on a completion flag, an error code and a busy flag, and provides the instruction state and axis state quantities as readable variables to the data read-write interface; wherein the reading configuration and device descriptors, generating an analysis rule of logical variable names to OPCUA node identifiers and outputting variable metadata comprises: reading a configuration file to obtain logical variable names, data types and initial values related to variables; determining a device prefix based on a device descriptor, and standardizing the logical variable names to form prefixed logical variable names; analyzing the prefixed logical variable names to OPCUA node identifiers according to a preset naming and mapping rule, the OPCUA node identifiers including a namespace identifier and a node name; checking the analysis result for consistency to confirm the corresponding relationship between the logical variable names and the corresponding data types and OPCUA node identifiers; generating and registering variable metadata, and providing the variable metadata for the memory mapping module and the control module to call.

2. The system of claim 1, wherein, The OPCUA is selected according to the server address and a client session is established, and a session handle is outputted, which comprises: receiving a server address and setting a communication mode to OPCUA; performing session closing and resource releasing when detecting that there is an existing client session, and creating an OPCUA client instance according to a preset client configuration; analyzing a target connection endpoint according to the server address and initiating a session establishment request to a server; generating and registering a session handle when the session establishment is successful, and providing the session handle for the variable analysis module, the memory mapping module and the control module to call.

3. The system of claim 1, wherein, The local data storage area is allocated according to the variable metadata, a mapping of logical variable names to local memory addresses and a mapping of OPCUA node identifiers to local memory addresses, which comprises: analyzing the variable metadata to obtain the logical variable names, data types, initial values and OPCUA node identifiers corresponding to each variable; According to the data type configuration storage unit, allocate local data storage area and write the initial value to the corresponding storage unit; Determine and register the local memory address for each logical variable name, and establish the first mapping of logical variable name to local memory address according to the data type division; Based on the correspondence between the OPCUA node identifier and the local memory address, a second mapping of OPCUA node identifier to local memory address is established.

4. The system of claim 3, wherein, The method for creating subscription and binding data change callback under the session handle in batches, and writing the change of server variable to the local data storage area, comprises: Based on the variable metadata, determine the target variable set that needs to be subscribed; According to the preset strategy, group the target variable set, and create a subscription request and bind a data change callback for each group under the session handle to activate the subscription; When receiving a data change notification containing an OPCUA node identifier and a change value, the second mapping is called to locate the corresponding local memory address according to the OPCUA node identifier; According to the data type recorded in the variable metadata, the change value is processed in a type-consistent manner, and the change value is written to the corresponding storage unit of the local data storage area.

5. The system of claim 3, wherein, The control module is used for: Receiving a read request containing a logical variable name, locating the corresponding local memory address according to the first mapping, reading the value according to the data type of the variable from the local data storage area, and returning; Receiving a write request containing a logical variable name and a target value, calling a variable parsing module to obtain an OPCUA node identifier according to a parsing rule, constructing an OPCUA data variant matching the data type of the target value, and writing to the corresponding node through the session handle; Receiving a control request containing an axis number and a trajectory parameter, determining the parameter node according to the parsing rule and writing the position, speed, acceleration and deceleration parameters, setting the execution control bit to start the instruction, and judging the state according to the completion flag, error code and busy flag within a preset time window, and resetting the execution control bit after reaching the judgment condition.

6. The system of claim 5, wherein, The setting of the execution control bit to start the instruction, and the state judgment according to the completion flag, error code and busy flag within a preset time window, comprises: Set the execution control bit to trigger the target instruction, and start the timer to limit the preset time window; Determine the state node identifier of the completion flag, error code and busy flag associated with the target instruction according to the parsing rule, and read the corresponding state variable through the session handle; Repeatedly read the completion flag, error code and busy flag at a preset sampling period within the preset time window; Based on the reading result, perform state judgment, when the error code is not zero, determine the error state; When the completion flag is true and the busy flag is false, determine the completion state; When the time window expires and the busy flag is true, determine the timeout state; When the time window expires and the completion flag is false and the busy flag is false, determine the non-execution state.

7. The system of claim 1, wherein, The control module further comprises: An axis status query interface for providing readable variables of enabling state, positive limit sensor state, negative limit sensor state, origin sensor state, running state enumeration and function block error flag related to the axis based on the local data storage.

8. The system of claim 1, wherein, The system further comprises: A monitoring module for sending a keep-alive request to the server at a set period and monitoring the subscription activity and connection state, triggering session reconstruction when an exception is detected, and initiating subscription recovery and callback binding for the memory mapping module after session reconstruction.

9. The system of claim 1, wherein, The system further comprises: A servo motion control execution interface module for unified packaging and providing a single calling entry of parameter node positioning of the axis control instruction, execution control bit management and state determination result, determining the parameter node based on the analysis rule of the variable analysis module, completing parameter writing and state collection according to the second mapping and the session handle, and registering the instruction state and the axis state variable as readable variables into the local data storage, and providing externally through the data read-write interface of the control module.

Images