A virtual axis-based non-standard robot control method, device and medium

Abstract

The application discloses a non-standard robot control method and device based on a virtual axis, and a medium, and relates to the technical field of industrial automation control. The method comprises the following steps: a virtual axis is established by using a PLC axis group function, and the virtual axis is used as an execution carrier of a Cartesian space track; a motion control instruction is issued to an axis group to which the virtual axis belongs, a Cartesian space continuous track is generated by an interpolation algorithm in the axis group according to the motion control instruction; a current Cartesian position of the virtual axis in a current scanning period is read in each scanning period, and the current Cartesian position is input into a kinematics module; the kinematics module is triggered to perform inverse kinematics calculation once, and the current Cartesian position is mapped into a target position array of each real axis in the current scanning period; each axis component in the target position array is issued in an abort mode to each real axis through a synchronous absolute positioning instruction, the motion of each real axis in a previous scanning period is forced to be aborted, and each real axis is driven to move by using a new target position mapped in the current scanning period.

Description

Technical Field

[0001] This application relates to the field of industrial automation control technology, and in particular to a non-standard robot control method, equipment and medium based on virtual axes. Background Technology

[0002] In the field of industrial automation, motion control of non-standard multi-axis mechanisms (i.e., non-standard six-axis articulated industrial robots) currently mainly employs two approaches. The first approach uses a dedicated robot kinematics library provided by the Programmable Logic Controller (PLC) manufacturer. This library integrates forward and inverse kinematics algorithms for specific configurations (such as SCARA) into the PLC's proprietary software modules. Users implement Cartesian space trajectory planning by calling encapsulated function blocks, which automatically perform inverse kinematics calculations and drive the movement of each physical axis. The second approach uses a dedicated robot controller independent of the PLC. This type of controller has a built-in kinematics engine and communicates with servo drives via a fieldbus. The PLC only sends trigger signals or target coordinates to the robot controller through digital I / O or a protocol gateway.

[0003] The above-mentioned existing technical solutions have the following limitations: (i) Poor algorithm portability. The kinematic algorithms of the dedicated robot library are deeply coupled with the compilation environment and underlying motion control kernel of a specific PLC brand. When the PLC platform needs to be changed due to technology upgrades or supply chain adjustments, the motion control program developed based on the library cannot be directly migrated to other brands of PLCs, and all kinematic related code needs to be rewritten and debugged.

[0004] (ii) Mismatch in control resource utilization. PLC models supporting dedicated robot libraries are typically mid-to-high-end products with CNC or advanced motion control functions, and their hardware performance and licensing costs are significantly higher than those of general-purpose PLCs. For application scenarios that only require control of simple non-standard mechanisms with 2 to 4 axes (such as box openers and simple loading and unloading robots), the cost-effectiveness of using high-end PLCs is severely unbalanced, resulting in over-configuration of control resources. Summary of the Invention

[0005] This application provides a non-standard robot control method, device, and medium based on virtual axes to solve the following technical problems: how to solve the problems of poor algorithm portability and mismatch in control resource utilization.

[0006] In a first aspect, embodiments of this application provide a non-standard robot control method based on a virtual axis, characterized by comprising: establishing a virtual axis using the axis group function of a PLC, and using the virtual axis as the execution carrier for a Cartesian space trajectory, wherein the virtual axis is not connected to the physical driver and has no encoder feedback; issuing motion control commands to the axis group to which the virtual axis belongs, and generating a continuous Cartesian space trajectory by the interpolation algorithm within the axis group according to the motion control commands; reading the current Cartesian position of the virtual axis in the current scan cycle on a cycle-by-cycle basis, and inputting the current Cartesian position into a kinematics module, wherein the kinematics module is a global singleton mode, and the kinematics module includes at least an inverse kinematics calculation unit; triggering the kinematics module to perform an inverse kinematics calculation, mapping the current Cartesian position to an array of target positions for each physical axis in the current scan cycle; and issuing each axis component in the target position array in parallel to each physical axis in a stop mode through a synchronous absolute positioning command, forcibly stopping the motion of each physical axis that was not completed in the previous scan cycle, and driving the motion of each physical axis with the new target position mapped in the current scan cycle.

[0007] Secondly, embodiments of this application also provide a non-standard robot control device based on a virtual axis, the device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to execute a non-standard robot control method based on a virtual axis as described in the first aspect above.

[0008] Thirdly, embodiments of this application also provide a computer storage medium storing computer-executable instructions, which, when executed, implement a non-standard robot control method based on a virtual axis as described in the first aspect above.

[0009] The non-standard robot control method, device, and medium based on virtual axes provided in this application have the following beneficial effects: Virtual axes can be established using the PLC axis group function, serving as the data carrier for Cartesian space trajectories. This ensures that trajectory planning and physical execution are logically and temporally independent. Secondly, motion control commands are issued to the axis group to which the virtual axis belongs. The interpolation algorithm within the axis group generates continuous trajectory points in real time during each scan cycle and automatically updates them to the virtual axis. Subsequently, the current Cartesian position of the virtual axis is read in each scan cycle and input into a global singleton kinematics module for inverse kinematics calculation. This maps the current Cartesian position to the target position array of each real axis, ensuring that the computational load of kinematics calculation does not increase linearly with the number of axes and that all axis commands originate from the same set of data at the same time, eliminating contour errors. Finally, synchronous positioning commands are used to send the axis components in the target position array in parallel to the drivers of each physical real axis in a stop-buffered mode. This forcibly stops the motion not completed in the previous cycle and drives each real axis with the new target position for the current cycle. This ensures that each real axis unconditionally refreshes its commands with the latest inverse kinematics result in each cycle. Thus, complete decoupling of continuous trajectory planning for the virtual axis and cycle-by-cycle synchronous tracking of the real axis is achieved. The above method relies solely on the general axis group functions and motion control instructions of the PLC, without binding to any brand-specific libraries. Therefore, it can be directly ported between different PLC platforms. At the same time, the decoupled architecture decouples the computational load from the number of axes and avoids dependence on high-end specialized libraries, enabling the above method to run stably on general-purpose PLCs. This improves the portability of the algorithm and allows the utilization of hardware resources to match the actual control requirements. Attached Figure Description

[0010] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 A flowchart illustrating a non-standard robot control method based on a virtual axis, provided for an embodiment of this application; Figure 2 A schematic diagram of a non-standard robot control system based on a virtual axis provided in an embodiment of this application; Figure 3 This is a schematic diagram of the internal structure of a non-standard robot control device based on a virtual axis, provided as an embodiment of this application. Detailed Implementation

[0011] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0012] The technical solutions proposed in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0013] Figure 1 This is a flowchart illustrating a non-standard robot control method based on a virtual axis, provided as an embodiment of this application. Figure 1 As shown in the figure, the non-standard robot control method based on a virtual axis provided in this application embodiment specifically includes the following steps: Step 101: Use the PLC axis group function to establish a virtual axis and use the virtual axis as the execution carrier of the Cartesian space trajectory.

[0014] The virtual axis is not connected to the physical driver and has no encoder feedback.

[0015] In practical applications, an axis group is a resource pool in the PLC motion control kernel responsible for geometric trajectory mathematical calculations, and it integrates algorithms such as linear interpolation and circular interpolation.

[0016] In this embodiment of the application, the PLC axis group function can be used to create a virtual axis without physical driver and encoder feedback. That is, the virtual axis is a pure software object, not bound to any hardware mapping address, and does not drive any physical motor. Its current position is calculated by the interpolation algorithm of the axis group, rather than obtained through encoder feedback. The virtual axis can be used as the execution carrier of Cartesian space trajectory.

[0017] Step 102: Send motion control commands to the axis group to which the virtual axis belongs, and the interpolation algorithm inside the axis group generates a continuous trajectory in Cartesian space according to the motion control commands.

[0018] In practical applications, when a user issues motion control commands to the axis group to which the virtual axis belongs, the interpolation algorithm within the axis group can calculate a Cartesian space coordinate point in real time during each scan cycle based on the motion control commands, and write the value of this coordinate point into the data structure of the virtual axis. The virtual axis serves as a temporary storage unit for this coordinate value, which can be read by subsequent kinematic solution steps. In this way, the virtual axis, as the standard data interface between the trajectory planning layer (interpolation calculation) and the physical execution layer (inverse kinematics distribution), allows the two layers to be completely decoupled in terms of timing. By establishing the virtual axis as a purely data-driven execution carrier, the adverse effects of physical axis response delay on trajectory planning accuracy can be avoided.

[0019] Step 103: Read the current Cartesian position of the virtual axis in the current scan cycle and input the current Cartesian position into the kinematics module.

[0020] The kinematics module is a global singleton and includes at least an inverse kinematics calculation unit.

[0021] In practical applications, within each PLC scan cycle, after the axis group completes the calculation of the trajectory points for this cycle and writes them into the virtual axis data structure, the current Cartesian position of the virtual axis in the current scan cycle can be read by directly accessing the virtual axis data structure (e.g., VirtualAxis.Position.X, VirtualAxis.Position.Y, VirtualAxis.Position.Z). This read operation is completed within microseconds and does not involve any bus communication or hardware I / O operations, thus avoiding communication delays or signal interference.

[0022] In practical applications, the kinematics module (kinematics function block) can be designed using a global singleton pattern, meaning that only one instance of this function block exists in the entire PLC program. This instance is stored in the global variable area, and other function blocks can access it. The inverse kinematics calculation unit is a software algorithm module that can map the input Cartesian space coordinates (X, Y, Z, R) to the target position (angle or displacement) of each physical real axis.

[0023] Step 104: Trigger the kinematics module to perform an inverse kinematics calculation, mapping the current Cartesian position to an array of target positions for each real axis in the current scan cycle.

[0024] In practical applications, regardless of the specific number of real axes, the kinematics module performs inverse kinematics calculations only once per scan cycle. This decouples the computational load of kinematics calculations from the number of physical axes, preventing it from increasing linearly with the number of axes. This keeps the computational power requirements of the control system constant, reducing the performance demands on the PLC processor. Furthermore, the target positions obtained by all real axes in the same scan cycle originate from the same current Cartesian position, avoiding inconsistencies in data timestamps caused by separate calculations for different real axes at different times.

[0025] In one possible implementation, the kinematics module further includes a forward kinematics calculation unit. The method further includes: In each scan cycle, the position of each real axis in the current scan cycle is read and the real axis is input to the kinematics module; The kinematics module is triggered to perform a forward kinematics calculation to obtain the actual position of the end effector in Cartesian space.

[0026] In practical applications, the forward kinematics calculation unit can utilize the real axis positions fed back by each physical real axis encoder to calculate the actual Cartesian coordinates of the end effector in the current physical space in real time through the mechanism's geometric model. This can represent the "physical reality" at the current moment and be used for real-time monitoring of tracking accuracy. In practical applications, the forward kinematics result can provide reference data for initializing the virtual axis position at startup, but it is not used as the basis for correction commands to ensure that the independence of the virtual axis trajectory planning is not affected by physical disturbances.

[0027] In one possible implementation, the kinematics module further includes a mechanism configuration selection interface, through which the corresponding forward kinematics algorithm and inverse kinematics algorithm are switched. The mechanism configuration includes at least one of the following: H-type XY motion platform, H-Bot XY configuration, selective compliant assembly robotic arm SCARA configuration, and parallel SCARA configuration.

[0028] In the above possible implementations, the kinematics module internally implements algorithm branch selection through CASE multi-branch statements: the CASE multi-branch statement uses the current value of the mechanism configuration selection interface as the selection condition. When the mechanism configuration selection interface takes the first value, it jumps to and executes the forward kinematics algorithm and inverse kinematics algorithm code segments corresponding to the first configuration, wherein the first configuration corresponds to the first value.

[0029] In practical applications, the aforementioned kinematics module can implement forward and inverse kinematics algorithms for various mechanism configurations through the mechanism configuration selection interface (KinType interface). Specifically, a KinType input interface can be preset within the kinematics module to receive externally specified mechanism configuration codes. Through the CASE multi-branch structure, based on the current value of KinType (e.g., 1=H-Bot XY, 2=SCARA, 3=ParallelSCARA, ...), the module jumps to the corresponding forward / inverse kinematics algorithm code segment for calculation. The KinType interface and the CASE structure together constitute a parameter-driven, branch-jump algorithm scheduling mechanism, enabling a single functional block to flexibly adapt to various non-standard mechanisms without modifying the program structure, thus improving configuration compatibility and algorithm maintainability.

[0030] In practical applications, H-Bot XY can be translated as H-type XY motion platform (also often called H-type roller motion mechanism). It is a lightweight motion structure that uses only a single synchronous belt to form an H-shaped transmission path and relies on dual motors to achieve full-stroke movement in the XY plane. It is mostly used in 3D printing and lightweight sorting scenarios.

[0031] Selective Compliance Assembly Robot Arm (SCARA), also known as a horizontal multi-joint robot, is a classic 4-axis industrial robot. It is flexible in the XY plane and maintains high rigidity in the Z direction, and is widely used in 3C precision assembly scenarios.

[0032] Parallel SCARA is a derivative structure of SCARA. It combines the advantages of high rigidity and high precision of parallel mechanisms, and has stronger load capacity and dynamic performance than traditional series SCARA, making it suitable for high-precision operation scenarios.

[0033] In practical applications, a global singleton kinematics function block can include interfaces as shown in Table 1.

[0034] Table 1. Interface examples of kinematic function blocks

[0035] Step 105: By using the synchronous absolute positioning command, each axis component in the target position array is sent to each of the real axes in parallel in a halt mode, forcibly halting the motion that was not completed in the previous scan cycle of each of the real axes, and driving the motion of each of the real axes with the new target position mapped by the current scan cycle.

[0036] In practical applications, the inverse kinematics result (each axis component in the target position array) can be sent to each real axis in parallel using the Synchronous Absolute command (SyncMoveAbsolute) in Aborting Buffer Mode. The Synchronous Absolute command is characterized by updating the position command strictly according to the clock tick of the PLC scan cycle, ensuring that the position data of multiple axes are synchronously latched and output within the same bus cycle. Each axis component refers to the target position array A_Cmd[0]~A_Cmd[n] calculated by the inverse kinematics, corresponding to the respective target values ​​of real axes 1 to n. The Aborting Buffer Mode immediately clears the remaining trajectory buffer in the axis driver that has not yet been executed, abandons the execution of the target position sent in the previous cycle, and instead accepts the new target position just calculated in the current cycle. This is because real axes have mass inertia, and the scan cycle is generally short (e.g., 2ms). The target position of the previous cycle may not have been achieved yet. Through the Aborting Buffer Mode, the driver's position command is directly overwritten, allowing each real axis to move with the new target position mapped in the current scan cycle.

[0037] In the embodiments of this application, the continuous trajectory planning of the virtual axis and the driving execution of each physical real axis are completely decoupled in time. Each physical real axis unconditionally overwrites the instruction of the previous cycle with the inverse solution result of the current cycle in each scanning cycle, which can realize a hierarchical decoupled control architecture for the continuous trajectory of the virtual axis to the synchronous tracking of the real axis cycle by cycle.

[0038] In one possible implementation, the method further includes: Create an instruction delivery function block instance corresponding to each of the real axes, wherein the instruction delivery function block instance is used to read the target position component corresponding to the real axis from the target position array by means of the axis number index preset for the real axis.

[0039] In practical applications, an independent AxisCtr function block instance can be created for each real axis (2-axis system = 2 instances, 3-axis = 3 instances, 4-axis = 4 instances). Each AxisCtr instance: Using the same Kinematics function block, extract only the component corresponding to this axis from the A_Cmd[] array; Call the standard PLC function block MC_SyncMoveAbsolute to issue the current position command; This process is executed once per PLC scan cycle, stopping any unfinished motion on the current axis and immediately sending out a new target position, thus achieving synchronous tracking cycle by cycle.

[0040] In practical applications, the target position arrays A_Cmd[0] to A_Cmd[n] store the target positions of each axis sequentially according to the physical axis numbering order. Each physical axis's corresponding instruction delivery function block instance accesses the corresponding element in the array through its preset axis number index (AxisIndex). For example, the i-th axis instance reads its own axis component from A_Cmd[i]. After each instance reads its own component, it calls the synchronous positioning instruction in parallel and sends it to the corresponding servo driver.

[0041] In one possible implementation, the method further includes, before reading the current Cartesian position of the imaginary axis cycle by scan cycle: Read the current actual position of each real axis; The kinematics module is triggered to perform forward kinematics calculations to obtain the current position coordinates of the end effector in Cartesian space; The current Cartesian position of the imaginary axis is set as the current position coordinate of the Cartesian space, so that the coordinate system of the imaginary axis is aligned with the actual spatial position of each physical real axis.

[0042] In practical applications, before enabling startup, the current Cartesian position of the virtual axis may not be consistent with the actual spatial position of each real axis. For example, the virtual axis may default to zero (X=0, Y=0) or remain at the position planned during the last power outage, while the real axes, due to gravity, being pushed during the power outage, or other factors, may not necessarily be in their actual position at the time of the last shutdown. Therefore, direct activation may result in a step deviation between the inverse kinematics output and the current position of the real axis, triggering a servo position error alarm. For example, the virtual axis defaults to (0, 0), and the inverse kinematics calculation shows that the motor needs to rotate 0°, but the encoder feedback shows it is at 10°. Upon system activation, the servo outputs a huge torque instantaneously, attempting to rotate the motor from 10° to 0° within milliseconds. This abrupt step change may directly trigger a position error alarm (excessive following error) on the driver, preventing the system from starting. Therefore, a virtual axis position pre-synchronization step can be introduced during the enabling phase: The first step is to read the current initial real axis position of all real axes (A_Act[]) and calculate the initial position coordinates of the end effector in Cartesian space (Act_Component[]) using the forward kinematics algorithm of the kinematics module mentioned above. For example, the end effector is calculated to be at X=100.5mm and Y=50.3mm.

[0043] The second step is to set the current Cartesian position of the imaginary axis as the initial position coordinates of the end effector in Cartesian space. This means that the physical coordinates (X=100.5, Y=50.3) calculated in the first step are directly written into the data structure of the imaginary axis, so that the coordinate system of the imaginary axis is aligned with the actual spatial position of each real axis. The third step, after alignment is complete, is that each instruction-issuing function block instance can initialize the target position of SyncMoveAbsolute to the current actual position of the corresponding real axis, clear any historical calculation differences that may have existed before, and then start the Phase synchronous tracking loop.

[0044] In this way, before activating synchronization control, the actual spatial coordinates of the end effector are obtained by reading the real axis encoder value through forward kinematics and forcibly written into the virtual axis, so that the virtual axis coordinate system is instantly aligned with the actual pose of the physical real axis. The above pre-synchronization mechanism will reduce the command step amount at the moment of startup to zero, which can avoid servo over-tolerance alarms and mechanical shocks caused by initial position mismatch, thereby achieving smooth activation of the control system without disturbance.

[0045] In one possible implementation, each instruction-issuing function block instance maintains a phase state machine internally, and executes the following control logic based on the values ​​of the state variables in the phase state machine: When the Phase state variable indicates an idle state, in response to receiving an enable signal, a virtual axis position pre-synchronization step is executed. When the virtual axis position pre-synchronization step is completed, the Phase state variable is switched to a synchronous tracking state, and a synchronous positioning command corresponding to the target real axis is issued in each scan cycle, wherein the target real axis is the real axis corresponding to the command issuance function block instance. When the Phase state variable indicates the synchronous tracking state, each scan cycle reads the target position component corresponding to the target real axis in the target position array and sends it to the physical real axis driver corresponding to the target real axis through a synchronous positioning command. When the Phase state variable indicates a synchronous tracking state, in response to receiving a deactivation signal, the real axis is controlled to stop moving, and when the target real axis stops moving, the Phase state variable is switched back to an idle state.

[0046] In practical applications, the AxisCtr function block can achieve smooth enable / disable control through a phase state machine: Phase 0 (Idle): Waiting for an enable signal (UpKinOn) or a disable signal (UpKinOff).

[0047] Phase 50 (Separation): Received a stop signal → Execute MC_SyncStop to stop axis movement → Return to Phase 0.

[0048] Phase 100 (Connection): Received enable signal (at this time, the virtual axis position has completed pre-synchronization initialization) → Initialize the SyncMoveAbsolute target position to the current axis position (to avoid position jump) → Enter the synchronization tracking loop.

[0049] The Phase state machine divides the operation of the real axis into three discrete and coherent phases, and the current phase is recorded by the state variable inside the AxisCtr function block. When the AxisCtr function block is called in each scan cycle, it reads the value of the state variable and determines which branch to execute in this cycle, thereby realizing the orderly migration of the axis between different life stages.

[0050] Thus, Phase 0 serves as an idle state, Phase 100 achieves zero-impact startup by forcibly initializing the target position to the current physical position, and Phase 50 achieves a controllable and safe shutdown by calling a standard deceleration and stop command. The Phase state machine divides the operational lifecycle of the physical axis into discrete yet coherent control phases, ensuring a smooth transition between startup and shutdown transients.

[0051] In one possible implementation, before sending each axis component in the target position array to each of the real axes in parallel in a halt mode via a synchronous absolute positioning command, the method further includes: Limit checks are performed on each axis component in the target position array, wherein, for the rotation axis in the real axis, the limit check includes performing modulo processing on the position component corresponding to the rotation axis.

[0052] In practical applications, before sending the angle calculated by inverse kinematics (e.g., J1 = 370°) to the motor, it can be compared with the preset soft limit in the PLC axis parameters. For example, the positive soft limit is that J1 can only rotate up to +360°. The negative soft limit is that J1 can only rotate up to -360°. A simple condition can be executed: IF A_Cmd[i]>positive limit OR A_Cmd[i]<negative limit THEN Error:=TRUE; (disable sending).

[0053] This prevents the inverse kinematics module from calculating an angle that theoretically exists but actually leads to a collision because the input coordinates exceed the robot's workspace. For example, if a virtual axis command requires the end effector to move to a point too far from the base, the joint angle calculated by the inverse kinematics module might exceed the mechanical limit. This step intercepts this dangerous value before issuing the command.

[0054] For a modular axis (such as the J1 axis of a SCARA, which can rotate infinitely in both directions), the angle value is periodic. For example, 370° and 10° are physically at the same location (both pointing in the direction of 10°), but the former causes the motor to rotate one more revolution. If 370° is directly sent to the motor, the motor may perform the action of "rotating one full revolution plus 10° in the forward direction", resulting in serious wasted motion and path distortion.

[0055] In practical applications, modular arithmetic refers to reducing arbitrarily large angle values ​​to a standard periodic range of 0° to 360° (or -180° to 180°). The formula is: Target Angle = Original Angle MOD 360. For example, if the original value is 370°, then 370 MOD 360 = 10° (the motor only needs to rotate from 0° to 10°, instead of idling for a full revolution). In practice, modular arithmetic often incorporates the "proximity principle." If the current J1 axis is actually at 350°, and the inverse calculation yields 10°, the target is not necessarily set to 10°, but rather to 370° (an extra 20° in the forward direction), which is much more efficient than rotating 340° in the reverse direction. This processing requires a difference comparison with the current actual position after the modular arithmetic calculation. Without modular processing, when the virtual axis continuously moves along a straight path, the J1 angle output from the inverse kinematics might jump from 359° to 361°. Although the physical position differs by only 2°, without modular processing, the unprocessed value might be interpreted as 361° (i.e., a 361° forward rotation from 0°), causing the motor to perform an almost complete extra rotation, resulting in severe contour errors and mechanical shock. Modular processing ensures that even if the virtual axis moves continuously, causing the inverse kinematics output value to accumulate, the final angle command always targets the "shortest physical path," keeping the cycle-by-cycle tracking of the real axis consistently efficient and compact.

[0056] In this way, the limit check ensures that the inverse kinematics result does not exceed the mechanical safety travel range; the modular processing reduces the absolute angle values ​​of the rotating shaft through multiple revolutions to a standard period range, and performs equivalent conversion according to the shortest path principle, eliminating invalid rotations and path distortions caused by the periodicity of angles. The above dual verification mechanism guarantees the physical feasibility, mechanical safety, and motion economy of issuing commands cycle by cycle.

[0057] In this embodiment, a virtual axis can be established using the PLC axis group function, and the virtual axis can be used as the data carrier for the Cartesian space trajectory, making trajectory planning and physical execution logically and temporally independent. Secondly, by issuing motion control commands to the axis group to which the virtual axis belongs, the interpolation algorithm within the axis group generates continuous trajectory points in real time during each scan cycle and automatically updates them to the virtual axis. Subsequently, in each scan cycle, the current Cartesian position of the virtual axis is read and input into a global singleton kinematics module for inverse kinematics calculation, mapping the current Cartesian position to each real axis. The target position array is used to ensure that the computational load of kinematic calculation does not increase linearly with the number of axes, and to ensure that the commands of each axis originate from the same set of data at the same time, eliminating contour errors. Finally, through synchronous positioning commands, the axis components in the target position array are sent in parallel to the drivers of each physical axis in a stop buffer mode, forcibly stopping the motion that was not completed in the previous cycle and driving each physical axis with the new target position in the current cycle. This ensures that each physical axis refreshes its commands unconditionally with the latest inverse kinematics result in each cycle, thus achieving complete decoupling between the continuous trajectory planning of the virtual axis and the cycle-by-cycle synchronous tracking of the physical axis. This method relies only on the general axis group functions and motion control commands of the PLC, without binding to any brand-specific libraries, and can therefore be directly ported between different PLC platforms. Furthermore, because the decoupled architecture decouples the computational load from the number of axes and avoids dependence on high-end specialized libraries, the method can run stably on general-purpose PLCs, thereby improving algorithm portability and matching hardware resource utilization with actual control requirements.

[0058] Figure 2 A schematic diagram of a non-standard robot control system based on a virtual axis provided in this application embodiment is shown below. Figure 2 As shown, the system adopts a three-layer progressive architecture of planning, calculation, and execution, achieving decoupling between trajectory planning and underlying hardware driving, as well as rapid adaptation to different mechanical configurations. The architecture of the above-mentioned non-standard robot control system based on virtual axes includes, from top to bottom: trajectory planning and crankshaft control layer, kinematics calculation layer, synchronization command issuance layer, and physical servo axis layer.

[0059] In practical applications, the trajectory planning and virtual axis control layer includes at least one virtual axis. This virtual axis is not directly bound to any physical hardware but serves as a carrier of Cartesian space to carry trajectory commands. In this embodiment, commands can be issued to the virtual axis using function blocks such as MC_MoveLinearAbsolute (absolute linear interpolation) or MC_MoveCircularAbsolute (absolute circular interpolation), for example, instructing the end effector to move linearly from coordinates (0,0) to (100,50). This layer shields the complexity of the underlying mechanical structure, allowing programmers to focus on the specific motor movements without needing to concern themselves with them.

[0060] The kinematics solution layer is used to execute forward and inverse kinematics algorithms. Since the system supports various heterogeneous mechanical mechanisms (such as H-Bots, SCARA five-bar linkages, etc.), this solution layer has pre-defined solution logic for different mechanism types (e.g., Figure 2 (As shown in CASE wstType Of). After the upper-layer virtual axis generates continuous trajectory points (containing parameters such as position, velocity, and acceleration), this layer uses a specific kinematic model to nonlinearly map the Cartesian space trajectory on the virtual axis to the joint space target positions required for each real axis. This mapping relationship is nonlinear, and one virtual axis trajectory point corresponds to a set of different real axis positions, thus overcoming the limitations of simple linear coupling or parameter forwarding in existing technologies.

[0061] The synchronous command delivery layer can convert the solved target commands into synchronous motion commands executable on the real axis. For example... Figure 2 As shown, the system sends the SyncMoveAbsolute command to the underlying layer by calling multiple axis control instances, such as AxisCr[0] to AxisCr[N]. The Execute pin triggers task execution, the Done pin reports the completion status, and the Phase[0..N-1] parameter is used to strictly synchronize the motion phases of multiple axes, ensuring trajectory accuracy during multi-axis linkage. This layer guarantees that all real axes receive coordinated strong brush commands within the same scan cycle.

[0062] The physical servo axis layer includes real axes that are mapped one-to-one with physical servo drivers. Each real axis corresponds to a physical servo motor and its transmission mechanism (motor, reducer, lead screw, etc.). After receiving synchronous absolute positioning commands from the upper layer, the real axis drives the physical mechanism to move, ultimately achieving accurate reproduction of the mechanical end effector trajectory.

[0063] The above architecture enables the technical effect of replacing physical machinery without changing the program. When it is necessary to change the underlying mechanical structure (for example, replacing H-Bot with a five-bar linkage), only the specific CASE branch formula in the kinematics calculation layer needs to be modified, while the upper-level trajectory planning program and the middle-level synchronization command issuance logic do not need to be changed at all, which greatly improves the development efficiency and production capacity of non-standard automated equipment.

[0064] The above are embodiments of the method proposed in this application. Based on the same inventive concept, embodiments of this application also provide a device, the structure of which is as follows: Figure 3 As shown.

[0065] Figure 3 This is a schematic diagram of the internal structure of a device provided in an embodiment of this application. Figure 3 As shown, the device includes: At least one processor 301; And a memory 302 that is communicatively connected to at least one processor; The memory 302 stores instructions that can be executed by at least one processor. The instructions are executed by at least one processor 301 so that at least one processor 301 can execute the above-described non-standard robot control method based on virtual axes.

[0066] In one possible implementation, the processor can perform the following: establish a virtual axis using the PLC axis group function, and use the virtual axis as the execution carrier for a Cartesian space trajectory, wherein the virtual axis is not connected to the physical driver and has no encoder feedback; issue motion control commands to the axis group to which the virtual axis belongs, and the interpolation algorithm within the axis group generates a continuous Cartesian space trajectory based on the motion control commands; read the current Cartesian position of the virtual axis in the current scan cycle on a cycle-by-cycle basis, and input the current Cartesian position into the kinematics module, wherein the kinematics module is a global singleton and includes at least an inverse kinematics calculation unit; trigger the kinematics module to perform an inverse kinematics calculation, mapping the current Cartesian position to an array of target positions for each real axis in the current scan cycle; and send each axis component in the target position array in parallel to each real axis in a halt mode through a synchronous absolute positioning command, forcibly halting the motion of each real axis that was not completed in the previous scan cycle, and driving the motion of each real axis with the new target position mapped in the current scan cycle.

[0067] Some embodiments of this application provide corresponding to Figure 1 A non-volatile computer storage medium stores computer-executable instructions, which are configured to execute the aforementioned non-standard robot control method based on virtual axes.

[0068] In one possible implementation, the aforementioned computer-executable instructions are configured to: establish virtual axes using PLC axis group functions and use the virtual axes as the execution carriers for Cartesian space trajectories, wherein the virtual axes are not connected to physical drivers and have no encoder feedback; issue motion control instructions to the axis group to which the virtual axes belong, and generate a continuous Cartesian space trajectory based on the motion control instructions using the interpolation algorithm within the axis group; read the current Cartesian position of the virtual axis in the current scan cycle on a cycle-by-cycle basis, and input the current Cartesian position into the kinematics module, wherein the kinematics module is a global singleton and includes at least an inverse kinematics calculation unit; trigger the kinematics module to perform an inverse kinematics calculation, mapping the current Cartesian position to an array of target positions for each real axis in the current scan cycle; and, through a synchronous absolute positioning instruction, send each axis component in the target position array in parallel to each real axis in an abort mode, forcibly aborting the motion of each real axis that was not completed in the previous scan cycle, and drive the motion of each real axis with the new target position mapped in the current scan cycle.

[0069] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments for IoT devices and media are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0070] The systems, media, and methods provided in this application are one-to-one correspondences. Therefore, the systems and media also have similar beneficial technical effects as their corresponding methods. Since the beneficial technical effects of the methods have been described in detail above, the beneficial technical effects of the systems and media will not be repeated here.

[0071] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0072] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0073] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0074] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0075] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0076] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0077] Computer-readable media include both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0078] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0079] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A non-standard robot control method based on a virtual axis, characterized in that, The method includes: A virtual axis is established using the PLC axis group function, and the virtual axis is used as the execution carrier of the Cartesian space trajectory. The virtual axis is not connected to the physical driver and has no encoder feedback. Motion control commands are sent to the axis group to which the virtual axis belongs, and the interpolation algorithm within the axis group generates a continuous trajectory in Cartesian space based on the motion control commands. The current Cartesian position of the imaginary axis in the current scan cycle is read cycle by cycle, and the current Cartesian position is input into the kinematics module. The kinematics module is a global singleton and includes at least an inverse kinematics calculation unit. The kinematics module is triggered to perform an inverse kinematics calculation, mapping the current Cartesian position to an array of target positions for each real axis in the current scan cycle; By synchronizing the absolute positioning command, each axis component in the target position array is sent to each real axis in parallel in a halt mode, forcibly halting the motion that was not completed in the previous scan cycle of each real axis, and driving the motion of each real axis with the new target position mapped by the current scan cycle.

2. The method according to claim 1, characterized in that, The kinematics module also includes a positive kinematics calculation unit; The method further includes: In each scan cycle, the position of each real axis in the current scan cycle is read and the real axis is input to the kinematics module; The kinematics module is triggered to perform a forward kinematics calculation to obtain the actual position of the end effector in Cartesian space.

3. The method according to claim 1, characterized in that, The kinematics module also includes a mechanism configuration selection interface, through which the corresponding forward kinematics algorithm and inverse kinematics algorithm are switched. The mechanism configuration includes at least one of the following: H-type XY motion platform, H-Bot XY configuration, selective compliant assembly robotic arm SCARA configuration, and parallel SCARA configuration.

4. The method according to claim 3, characterized in that, The kinematics module internally implements algorithm branch selection through CASE multi-branch statements: the CASE multi-branch statements use the current value of the mechanism configuration selection interface as the selection condition. When the mechanism configuration selection interface takes the first value, the statement jumps to and executes the forward kinematics algorithm and inverse kinematics algorithm code segments corresponding to the first configuration, wherein the first configuration corresponds to the first value.

5. The method according to claim 1, characterized in that, The method further includes: Create an instruction delivery function block instance corresponding to each of the real axes, wherein the instruction delivery function block instance is used to read the target position component corresponding to the real axis from the target position array by means of the axis number index preset for the real axis.

6. The method according to claim 5, characterized in that, Before reading the current Cartesian position of the imaginary axis cycle by scan, the method further includes: Read the current actual position of each real axis; The kinematics module is triggered to perform forward kinematics calculations to obtain the current position coordinates of the end effector in Cartesian space; The current Cartesian position of the imaginary axis is set as the current position coordinate of the Cartesian space, so that the coordinate system of the imaginary axis is aligned with the actual spatial position of each physical real axis.

7. The method according to claim 6, characterized in that, Each of the aforementioned instruction-issuing function block instances maintains a Phase state variable internally, and executes the following control logic based on the value of the Phase state variable: When the Phase state variable indicates an idle state, in response to receiving an enable signal, a virtual axis position pre-synchronization step is executed. When the virtual axis position pre-synchronization step is completed, the Phase state variable is switched to a synchronous tracking state, and a synchronous positioning command corresponding to the target real axis is issued in each scan cycle, wherein the target real axis is the real axis corresponding to the command issuance function block instance. When the Phase state variable indicates the synchronous tracking state, each scan cycle reads the target position component corresponding to the target real axis in the target position array and sends it to the physical real axis driver corresponding to the target real axis through a synchronous positioning command. When the Phase state variable indicates a synchronous tracking state, in response to receiving a deactivation signal, the real axis is controlled to stop moving, and when the target real axis stops moving, the Phase state variable is switched back to an idle state.

8. The method according to claim 1, characterized in that, Before sending each axis component in the target position array to each real axis in parallel in a halt mode via a synchronous absolute positioning command, the method further includes: Limit checks are performed on each axis component in the target position array, wherein, for the rotation axis in the real axis, the limit check includes performing modulo processing on the position component corresponding to the rotation axis.

9. A non-standard robot control device based on a virtual axis, characterized in that, The device includes: At least one processor; And, a memory communicatively connected to the at least one processor; The memory stores instructions that can be executed by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform a non-standard robot control method based on a virtual axis as described in any one of claims 1-8.

10. A computer storage medium storing computer-executable instructions, characterized in that, When the computer-executable instructions are executed, a non-standard robot control method based on a virtual axis as described in any one of claims 1-8 is implemented.

Images