Master-slave PLC multi-axis cooperative control method, system and equipment

Abstract

The invention discloses a master-slave PLC multi-axis cooperative control method, system and equipment, and the method comprises the steps: obtaining a communication structure body which comprises an input instruction structure body and an output feedback structure body, mapping the communication structure body to a bottom layer communication transmission region, and building a corresponding relation between a variable name of a master PLC and a bottom layer hardware address of at least one slave PLC; the main PLC generates a motion control parameter and an action instruction for a target control axis based on a preset multi-axis process control logic, and automatically completes instruction conversion and issuing to a bottom hardware address by writing a variable name corresponding to an input instruction structural body; and periodically acquiring a real-time operation state and an underlying hardware sensing signal fed back from the PLC by reading a variable name corresponding to the output feedback structural body, and updating a multi-axis process control logic based on a feedback result. Therefore, multi-axis closed-loop cooperative control under multi-degree-of-freedom space cooperative motion and / or multi-station synchronous positioning is realized.

Description

Technical Field

[0001] This application relates to the field of industrial automation motion control technology, and in particular to a master-slave PLC multi-axis collaborative control method, system and equipment. Background Technology

[0002] In industrial automation production scenarios, multi-axis motion control is widely used in machine tool processing, robot linkage, material handling and assembly, and precision execution equipment. As equipment processes become increasingly complex, control systems not only need to achieve precise drive of each motion axis, but also need to balance the real-time performance of multi-axis collaborative control, the flexibility of system expansion, and the economic efficiency of engineering implementation. Therefore, achieving a balance between control performance, hardware cost, system maintenance, and future expansion has become a crucial issue in the design of multi-axis control systems.

[0003] Currently, multi-axis control is typically implemented in two ways: one is to use a single high-performance PLC with a dedicated motion control module to achieve centralized control; the other is to build a distributed control system with multiple PLCs through a fieldbus. While the former approach can meet certain multi-axis control requirements, it often suffers from high hardware investment and limited number of axes that can be directly supported in small and medium-sized equipment scenarios. The latter approach, although having some scalability, usually requires handling more complex communication configurations, device coordination, and program organization issues in practical applications, thus increasing the difficulty of system implementation, debugging, and maintenance.

[0004] Furthermore, in traditional dual-PLC or multi-PLC collaborative control schemes, the master and slave stations typically need to achieve data interaction through underlying communication address mapping, while retaining their respective control flows and logical judgments. This approach can lead to cumbersome communication variable configuration and poor readability, and can easily cause complex mapping adjustments when upgrading equipment or adding new control objects. On the other hand, the master and slave control units often need to perform multiple interactions to confirm the execution status of actions, resulting in fragmented control logic and complex program organization, which is detrimental to unified debugging, maintenance, and expansion by engineers. Summary of the Invention

[0005] This application provides a master-slave PLC multi-axis collaborative control method, system, device, storage medium, and program product to at least solve one of the above-mentioned technical problems.

[0006] In a first aspect, embodiments of this application provide a master-slave PLC multi-axis collaborative control method, comprising: acquiring a communication structure including an input instruction structure and an output feedback structure, and mapping the communication structure to a lower-level communication transmission area to establish a variable mapping relationship between variable names of the master PLC and the lower-level hardware addresses of at least one slave PLC; generating motion control parameters and action instructions for at least one target control axis based on preset multi-axis process control logic, and writing the motion control parameters and action instructions into the variable names corresponding to the input instruction structure, such that the writing operation for the variable names generates control instructions for the lower-level hardware addresses of the slave PLC according to the variable mapping relationship, and automatically sending them to the slave PLC via the lower-level communication transmission area; the multi-axis process control logic includes multi-degree-of-freedom spatial collaborative motion logic and / or multi-station synchronous positioning logic; periodically receiving real-time operating status and lower-level hardware sensor signals fed back by the slave PLC by reading the variable names corresponding to the output feedback structure, via the lower-level communication transmission area and the variable mapping relationship; and updating the operating status of the multi-axis process control logic based on the received real-time operating status and lower-level hardware sensor signals.

[0007] Secondly, embodiments of this application provide a master-slave PLC multi-axis collaborative control method, applied to a slave PLC. The method includes: acquiring a communication structure containing an input instruction structure and an output feedback structure, and mapping the communication structure to a lower-level communication transmission area to establish a variable mapping relationship between variable names of the master PLC and the lower-level hardware address of the slave PLC; receiving control instructions automatically issued by the master PLC through the lower-level hardware address, via the lower-level communication transmission area and the variable mapping relationship, and extracting the motion control parameters and action instructions corresponding to the control instructions; wherein, the control instructions are generated by the master PLC based on a preset multi-axis... The motion control parameters and action commands generated by the process control logic are automatically converted from the variable names corresponding to the input command structure. Based on the extracted motion control parameters and action commands, local drive is executed on the controlled axis from the PLC through the local pulse output port. The real-time operating status and underlying hardware sensor signals of the controlled axis are collected, and the real-time operating status and underlying hardware sensor signals are fed back to the main PLC through the underlying communication transmission area and the variable mapping relationship, so that the real-time operating status and underlying hardware sensor signals can be periodically received by the main PLC by reading the variable names corresponding to the output feedback structure.

[0008] Thirdly, embodiments of this application provide a master-slave PLC multi-axis collaborative control system, including a master PLC and at least one slave PLC; the master PLC is configured to perform the steps of the above method; the slave PLC is configured to perform the steps of the above method.

[0009] Fourthly, embodiments of this application provide a storage medium storing one or more programs including execution instructions, which can be read and executed by electronic devices (including but not limited to computers, servers, or network devices) to perform the steps of the master-slave PLC multi-axis collaborative control method described in this application.

[0010] Fifthly, a computer device is provided, 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 perform the steps of the master-slave PLC multi-axis collaborative control method described in this application.

[0011] Sixthly, embodiments of this application also provide a computer program product, the computer program product including a computer program stored on a storage medium, the computer program including program instructions, which, when executed by a computer, cause the computer to perform the steps of the method described above.

[0012] The beneficial effects of the embodiments of this application are as follows: By mapping the communication structure to the underlying communication transmission area, the master PLC can automatically associate with the slave PLC's underlying hardware address based on variable name reading and writing. This simplifies the communication configuration and program organization between the master and slave PLCs, reducing the complexity of adjustments during system implementation, maintenance, and expansion. Simultaneously, the master PLC generates and issues motion control parameters and action commands for each target control axis based on preset multi-axis process control logic. It also performs closed-loop updates of the multi-axis process control logic by combining the real-time operating status feedback from the slave PLC and the underlying hardware sensor signals. This improves the consistency of commands, the coordination of responses, and the stability of operation during multi-axis collaborative control. Attached Figure Description

[0013] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0014] Figure 1 A flowchart illustrating an example of a master-slave PLC multi-axis collaborative control method according to an embodiment of this application is shown. Figure 2This document shows an example of an operation flowchart illustrating the method for establishing a variable mapping relationship between a master PLC and a slave PLC through communication structure mapping according to an embodiment of this application. Figure 3 A flowchart illustrating an example of performing jog debugging control in a method according to an embodiment of this application is shown. Figure 4 A flowchart illustrating an example of a master-slave PLC multi-axis collaborative control method according to an embodiment of this application is shown. Figure 5 A flowchart illustrating an example of establishing a variable mapping relationship between the variable names of the master PLC and the underlying hardware addresses of the slave PLC according to an embodiment of this application is shown. Figure 6 A structural block diagram of an example master-slave PLC multi-axis collaborative control system according to an embodiment of this application is shown; Figure 7 A schematic diagram illustrating an example of the hardware communication architecture of a master-slave PLC multi-axis collaborative control system according to an embodiment of this application is shown. Figure 8 A schematic diagram illustrating an example of single-axis control variable structure data in a master-slave PLC multi-axis collaborative control system according to an embodiment of this application is shown. Figure 9 A schematic diagram illustrating an example of a master-slave PLC multi-axis collaborative control system in which multi-axis control structure variables are uniformly declared at the master station according to an embodiment of this application; Figure 10 The diagram shows a code logic illustration of an example of the association between the RZ axis slave station and the master station variables in the master-slave PLC multi-axis collaborative control method according to an embodiment of this application. Figure 11 This paper presents a schematic diagram of the code logic for an example of the association between the Y-axis slave station and the master station variables in the master-slave PLC multi-axis collaborative control method according to an embodiment of this application. Figure 12 A schematic diagram illustrating an example configuration of the intelligent device communication transmission area and corresponding variable address mapping in a master-slave PLC multi-axis collaborative control system according to an embodiment of this application is shown. Figure 13 A schematic diagram of an example interface for detailed address configuration of a single transmission area in a master-slave PLC multi-axis cooperative control system according to an embodiment of this application is shown. Figure 14 A schematic diagram illustrating an example of the slave PLC-side program logic and master-slave division of labor mechanism in a master-slave PLC multi-axis collaborative control system according to an embodiment of this application is shown. Figure 15 A schematic diagram is shown as an example of centralized six-axis control implemented through a human-machine interface in a master-slave PLC multi-axis collaborative control system according to an embodiment of this application; Figure 16 A schematic diagram of an example of a single-axis fine-tuning and monitoring interface in a master-slave PLC multi-axis collaborative control system according to an embodiment of this application is shown; Figure 17 This is a schematic diagram of the structure of an embodiment of the electronic device of this application. Detailed Implementation

[0015] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. It should be noted that, unless otherwise specified, the embodiments and features in the embodiments of this application can be combined with each other.

[0016] It should also be noted that, in this document, the terms "comprising" or "including" include not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0017] In current multi-axis control implementations, small and medium-sized automation equipment often faces the challenge of balancing underlying control resources with system economics. Some small PLCs can only directly provide a limited number of pulse control resources. As the number of controlled axes increases, expansion is often necessary by adding dedicated motion control modules or using higher-specification controllers. While this approach can improve axis control capabilities to some extent, it typically leads to increased hardware investment, limited model compatibility, and increased engineering configuration complexity, thus affecting the applicability of the solution in small and medium-sized equipment.

[0018] Furthermore, in scenarios involving dual or multiple PLCs in collaborative control, current master-slave communication technologies still largely rely on manual allocation and mapping of underlying registers or address areas. During configuration, engineers often need to meticulously map and maintain different control commands, status variables, and parameters item by item, in accordance with communication protocol rules. While this method enables basic data exchange, its strong dependence on address relationships results in relatively poor program readability and configuration intuitiveness. When the equipment subsequently requires the addition of control axes, expansion of I / O points, or adjustments to the process flow, the communication mapping relationships often need to be modified accordingly, increasing the workload of system adjustment and maintenance.

[0019] In some master-slave joint control modes, the master PLC and slave PLC often each undertake part of the process control, status judgment, and execution control tasks. Therefore, during multi-axis coordinated operation, the master and slave control units typically need to interact multiple times around the stages of action triggering, execution completion, and status confirmation. While this type of control organization can meet basic linkage requirements, it easily leads to program logic being distributed across different controllers, resulting in long process chains and numerous program dependencies, which is not conducive to unified debugging and centralized maintenance.

[0020] Meanwhile, in some solutions, the slave control unit, in addition to undertaking axis drive and I / O acquisition functions, also participates in certain process judgments and logical operations, resulting in an unclear division of responsibilities between master and slave. For equipment that requires continuous iteration, once the number of axes, workstations, or external signals change, it is usually necessary to adjust the relevant programs and communication configurations on both the master and slave sides simultaneously. This involves a large range of modifications, which in turn affects the efficiency of subsequent system expansion, upgrades, and maintenance.

[0021] It should be understood that the above description of the relevant technologies is intended only to help the public better understand the inventive spirit and motivation of this application, and is not intended to limit this application. Furthermore, the technical solutions described in the above-mentioned relevant technologies are not prior art, and may also be undisclosed technical solutions, such as those under research or in the laboratory stage.

[0022] Figure 1 A flowchart illustrating an example of a master-slave PLC multi-axis collaborative control method according to an embodiment of this application is shown.

[0023] Regarding the execution subject of the method in this application embodiment, it can be a programmable logic controller (PLC) in an industrial automation environment. In some extended examples, as long as it has real-time industrial communication capabilities and a low-level hardware control interface, the method in this application embodiment can also be integrated and configured in other types of industrial electronic devices or control terminals through software, hardware, or a combination of software and hardware. Furthermore, the type of industrial electronic device can be diverse, such as an industrial control computer (IPC), a programmable automation controller (PAC), an industrial control computer / desktop computer running a soft PLC system, or an edge computing gateway with real-time control capabilities, etc.

[0024] For example, the execution subject of the method in this application embodiment can be a controller in the main PLC integrated in the main control system of automated production equipment. By calling the master-slave PLC multi-axis collaborative control program pre-configured in the memory, it performs read and write operations on the communication structure mapped to the underlying communication transmission area, and combines the communication connection established with at least one slave PLC to complete the unified generation and issuance of motion control parameters and action instructions, as well as the periodic reception and processing of real-time running status and underlying hardware sensor signals, so as to realize multi-axis collaborative closed-loop control.

[0025] like Figure 1 As shown, in step S110, a communication structure containing an input instruction structure and an output feedback structure is obtained, and the communication structure is mapped to the underlying communication transmission area to establish a variable mapping relationship between the variable names of the main PLC and the underlying hardware addresses of at least one slave PLC.

[0026] In some implementations, the communication structure can be a data organization unit predefined in the PLC programming environment, such as a user-defined data type or a data object with a fixed field format. The communication structure includes at least an input instruction structure from the master PLC to the slave PLC, and an output feedback structure from the slave PLC to the master PLC, which transmits status information back to the master PLC.

[0027] Furthermore, in some preferred embodiments of this application, the input instruction structure includes at least Boolean instruction variables and numerical parameter variables, and the output feedback structure includes at least Boolean state variables and numerical parameter variables. Specifically, the Boolean instruction variables in the input instruction structure are used to indicate at least one of enable, reset, return to zero, start, stop, and jog actions, while the numerical parameter variables are used to set at least one of target position and target speed; correspondingly, the Boolean state variables in the output feedback structure are used to indicate at least one of servo ready, return to zero completed, positioning completed, and hardware limit (such as positive limit, negative limit, origin, etc.) trigger state, while the numerical parameter variables are used to indicate at least one of current actual position, current actual speed, and error code.

[0028] In some implementations, the control and parameter items in the input instruction structure, and the status and feedback items in the output feedback structure, can be organized and arranged according to a predetermined field order. By adopting a unified data structure definition method, it is beneficial for the master PLC and slave PLC to consistently parse the same fields during communication, and it is also convenient to access the corresponding control and feedback items through structure variable names in the program, thereby improving the clarity of the communication interface and the standardization of program organization.

[0029] By using a consistent communication structure on both the master and slave PLC sides, a unified data interaction format can be established between the master and slave stations around the target control axis. For example, in a six-axis collaborative control scenario for a blind spot radar focusing device, the device may include six degrees of freedom axes: X, Y, Z, RX, RY, and RZ. Some axes can be controlled locally by the master PLC, while others, such as the Y and RZ axes, can be driven by local axis control units connected to the slave PLC. In this case, input / output structures with the same field definitions can be declared for each axis, and these structures can be associated with the underlying communication transmission area between the master and slave PLCs. This allows operations in the master PLC program targeting variable names such as "RZ axis enable," "Y-axis target position," and "RZ axis current speed" to automatically correspond to the corresponding underlying hardware addresses on the slave PLC side, eliminating the need for engineers to maintain address offsets and signal tag numbers item by item. This approach helps separate the upper-level process logic from the lower-level communication address configuration process, facilitating unified management of the six-axis interface and enabling the subsequent replication of existing axis interfaces to expand to new control axes.

[0030] In step S120, motion control parameters and action commands for at least one target control axis are generated based on preset multi-axis process control logic. These parameters and commands are then written into the variable names corresponding to the input command structure. This allows the writing operation to the variable names to generate control commands for the underlying hardware address of the slave PLC based on the variable mapping relationship, and these commands are automatically sent to the slave PLC via the underlying communication transmission area. Here, the multi-axis process control logic includes multi-degree-of-freedom spatial cooperative motion logic and / or multi-station synchronous positioning logic.

[0031] In some implementations, the master PLC acts as the unified control entity for multi-axis collaborative control. It executes multi-axis process control logic based on the current process stage, equipment operating status, and the coordination relationships between the target control axes. This multi-axis process control logic can correspond to both multi-degree-of-freedom spatial collaborative motion scenarios and multi-station synchronous positioning scenarios. Within a predetermined control cycle, the master PLC generates motion control parameters and action instructions related to the current action for at least one target control axis and writes them into the corresponding variable names in the input instruction structure. Since the variable names are already mapped to the underlying hardware addresses of the slave PLCs, this write operation can be automatically converted into a control data transmission process for the corresponding slave PLC via the underlying communication transmission area, enabling the slave PLC to receive and execute the corresponding control content within its local control cycle.

[0032] For example, in a six-axis blind spot radar focusing device, the human-machine interface can provide operation entry points such as manual jogging, standby position, loading position, and unloading position. When the operator selects a positioning station on the interface, or selects JOG mode and sets the jogging speed, the main PLC can uniformly generate the target position, target speed, and start-type instructions corresponding to each target control axis in the six axes (X, Y, Z, RX, RY, RZ) according to the current formula parameters and process status. Among them, for the Y-axis and RZ-axis controlled by the slave PLC, the main PLC directly writes the corresponding parameters into the corresponding variable name of its input instruction structure, thereby automatically sending them to the axis control execution unit on the slave PLC side.

[0033] Furthermore, in scenarios where multiple axes need to simultaneously reach a set of target postures, the master PLC can generate the target positions and start commands for multiple target control axes at once within the same control logic. This avoids the logic dispersion problem caused by traditional master-slave PLCs writing separate processes and then gradually confirming actions through multiple interactive signals. Thus, the "master-slave" control mode can be applied to specific interface operations, parameter generation, and synchronous distribution processes in actual equipment scenarios.

[0034] In step S130, by reading the variable names corresponding to the output feedback structure, and through the underlying communication transmission area and variable mapping relationship, the real-time operating status and underlying hardware sensing signals fed back from the PLC are periodically received.

[0035] In some implementations, during the execution of local axis control tasks, the PLC collects the status data of the connected controlled axes and related underlying hardware units, and writes the collected results into the data fields of the output feedback structure. Real-time operating status may include servo ready status, enabled status, homing completion status, positioning completion status, current position, current speed, and error codes; underlying hardware sensor signals may include positive limit signals, negative limit signals, origin signals, and other local I / O inputs related to the field execution status.

[0036] Since the output feedback structure is also mapped to the underlying communication transmission area, after local feedback data is written from the PLC, it can be transmitted to the main PLC via the underlying communication transmission area. The main PLC only needs to read the variable name corresponding to the output feedback structure to obtain the latest status information returned from the PLC.

[0037] In the aforementioned six-axis equipment control scenario, the slave PLC can continuously collect servo status, current position, current speed, and related hardware protection signals such as origin, positive limit, and negative limit from its locally connected Y and RZ axes. This data is then fed back to the main PLC in real time via an `out` structure. Ultimately, this information can be used by the main PLC for logical judgments and simultaneously displayed on the human-machine interface (HMI), allowing operators to intuitively see the enable status, homing completion status, positioning completion status, error codes, and current position and speed information for each axis.

[0038] In examples employing standard PROFINET intelligent IO communication, status updates can be completed within millisecond-level communication cycles, meeting the status monitoring requirements of common multi-axis motion control and logic control scenarios. The periodic reading method based on structure variable names helps reduce the program processing burden caused by scattered feedback signals and provides a unified and continuous source of field data for subsequent closed-loop control.

[0039] In step S140, the operating status of the multi-axis process control logic is updated based on the received real-time operating status and underlying hardware sensing signals.

[0040] In practice, after receiving the real-time operating status feedback from the PLC and the underlying hardware sensor signals, the main PLC uses the feedback information as the status input for the current control cycle, and updates the operating status of the current multi-axis process control logic in combination with motion control parameters and action commands.

[0041] During this update process, it can be determined whether the target control axis has met the predetermined execution conditions, whether the coordination relationship between multiple control axes meets the current process requirements, and whether the system should enter the next process stage or maintain the current control state. When feedback information indicates that a target control axis has completed the predetermined action, the main PLC can advance the current process flow accordingly; when feedback information indicates that there is an incomplete state, an error state, or a hardware limitation state, the main PLC can maintain the current step, stop the relevant action, or output alarm processing logic accordingly, thereby realizing multi-axis collaborative closed-loop control for the target control axis.

[0042] For example, when performing focus attitude adjustment in six-axis linkage, the main PLC can simultaneously monitor the positioning status of six axes (X, Y, Z, RX, RY, and RZ) within the same process cycle. If the Y-axis or RZ-axis controlled by the slave PLC has not yet completed positioning, or if a positive limit, negative limit, origin abnormality, or servo alarm is triggered, the main PLC can pause the operation to the next station based on the corresponding feedback result and execute a shutdown or alarm handling. Only when multiple target control axes meet the preset positioning conditions will the main PLC update the process status and advance to the next control stage.

[0043] On the other hand, in manual debugging scenarios, if the JOG jog command issued by the HMI has been executed, and the real-time position and speed returned from the PLC indicate that the target axis is still in motion, the main PLC can maintain the current debugging state until a stop or arrival feedback is detected before updating the interface state and internal control state. By adopting a closed-loop organization method that coordinates command issuance, status feedback, and logic updates, the main PLC can perform collaborative scheduling of multiple distributed axis control units under a unified main control framework, thereby balancing the operational stability, control coordination, and engineering maintainability of multi-axis linkage.

[0044] Figure 2 This document illustrates an example of an operation flowchart illustrating the method for establishing a variable mapping relationship between a master PLC and a slave PLC through a communication structure mapping according to an embodiment of this application.

[0045] like Figure 2 As shown, in step S210, the master PLC is set as an IO controller and the slave PLC is set as a controlled intelligent IO device, so as to establish a low-level communication transmission area corresponding to the communication structure between the master PLC and the slave PLC.

[0046] In practical implementation, during the hardware configuration phase of the industrial Ethernet network, the master PLC can be configured as an I / O controller responsible for cyclic data exchange, and the slave PLC can be configured as an intelligent I / O device managed by the master PLC. The slave PLC can expose its local data area used for master-slave communication to the outside world according to a preset length, enabling the master PLC to access the corresponding data interface of the slave PLC as an intelligent I / O device. Furthermore, based on the number of fields and byte length of predefined input instruction structures and output feedback structures, corresponding underlying communication transmission areas can be established between the master PLC and the slave PLC to serve as the transmission carrier for the master PLC to send control data to the slave PLC and for the slave PLC to send status data back to the master PLC. For example, this communication method can be implemented based on standard PROFINET intelligent I / O communication to meet the needs of general motion control and logic control scenarios.

[0047] With the above configuration, the master PLC can treat the slave PLC as a controlled intelligent I / O node in the network and complete data transmission and reception with the slave PLC based on the periodic exchange mechanism of the underlying bus, without needing to write separate data transmission and reception logic based on application-layer communication instructions in the user program for each control and feedback process. This approach helps maintain a unified interface and fixed cycle for data exchange between the master and slave PLCs, and also reduces the organizational complexity added to the program around communication transmission and reception, thus providing a stable data channel for subsequent variable reading and writing based on the communication structure and multi-axis collaborative control. It should be understood that under standard PROFINET communication conditions, the communication cycle can be 1~4 ms, which can meet the engineering application requirements of this type of multi-axis control scheme.

[0048] In step S220, the input instruction structure is bound as a static overall variable to the corresponding allocated logical output start address in the underlying communication transmission area, and the output feedback structure is bound as a static overall variable to the corresponding allocated logical input start address in the underlying communication transmission area. This ensures that read and write operations on any sub-variable within the communication structure are automatically converted into direct access to the underlying hardware address via the underlying communication transmission area.

[0049] In practical implementation, global variables corresponding to the input instruction structure and output feedback structure can be instantiated separately in the PLC programming environment, and these global variables can be associated with the corresponding starting addresses in the underlying communication transmission area. Since the sub-variables in the communication structure are encapsulated according to a predefined field order, once the global variable is bound to the starting address, each sub-variable within the structure can be mapped to its corresponding address in the underlying communication transmission area according to its relative offset within the structure. This allows developers to directly access specific control or feedback items in the master or slave PLC program using the format "structure variable name.sub-variable name," without needing to maintain absolute addresses, bit offsets, or separate, fragmented variable mappings item by item.

[0050] In some example mapping methods, a logical output area on the master PLC side used to issue control content can be associated with a corresponding logical input area on the slave PLC side. After the master PLC writes sub-variables such as enable, return to zero, start, target position, and target speed, the relevant data can be transmitted to the corresponding address on the slave PLC side via the underlying communication transmission area. Conversely, after the slave PLC writes servo status, error code, current position, current speed, and feedback items such as positive limit, negative limit, and origin into the output feedback structure, it can also return to the corresponding logical input area on the master PLC side. A one-time association between the variable interface and the underlying address area is achieved through overall structure binding; for example, configuring the master PLC's Q500 area to correspond to the slave PLC's I500 area.

[0051] By adopting the above-described overall binding method, the main PLC program can focus primarily on controlling process variables without constantly worrying about the details of underlying communication address allocation. From an engineering implementation perspective, this approach helps reduce problems such as address misalignment, overlap, or difficulty in modification that may occur when manually configuring addresses item by item. It also facilitates expansion by copying existing structure variables and adjusting the corresponding address areas when adding new control axes.

[0052] In some cases, axes can be added by copying and pasting and modifying the number, which can improve programming efficiency, readability and ease of maintenance while maintaining consistency between the master and slave interfaces.

[0053] This application's embodiments employ an architecture based on IO controllers and intelligent IO devices, combined with an implementation method that binds the overall address of the communication structure. This improves the data interaction between master and slave PLCs from both the underlying communication organization and upper-level program writing perspectives. On one hand, by configuring the master PLC as an IO controller and the slave PLC as an intelligent IO device, a fixed transmission channel matching the communication structure can be established using the periodic exchange mechanism of the underlying bus. This provides a unified data exchange foundation for the transmission of control data and the feedback of status data between the master and slave PLCs. On the other hand, by binding the input instruction structure and the output feedback structure as overall variables to their corresponding starting addresses, developers can perform symbolic programming based on structure variables, eliminating the need for item-by-item addressing around scattered absolute addresses. This reduces the complexity of communication configuration, improves the clarity and maintainability of program organization, and provides a more convenient implementation method for subsequent expansion of multi-axis control objects.

[0054] In some preferred embodiments of this application, the target control axis includes a native controlled axis directly controlled by the master PLC through a local pulse output port, and an extended controlled axis directly controlled by the slave PLC through a local pulse output port.

[0055] In practical implementation, conventional small and medium-sized PLC mainframes are limited by their hardware architecture, typically having a limited number of locally available high-speed pulse output ports. Therefore, the number of servo or stepper axes they can directly drive is capped. When automated equipment involves coordinated motion with many degrees of freedom, the total number of target control axes may exceed the maximum number of controlled axes that a single main PLC can support through its local pulse output ports. For example, in a six-axis blind-spot radar focusing device, the device may include X, Y, Z, RX, RY, and RZ axes. The main PLC can directly control the natively controlled axes such as the X, Z, RX, and RY axes through its local pulse output ports, while axes beyond the local main axis control capabilities, such as the Y and RZ axes, are driven by slave PLCs through their local pulse output ports. This approach allows for the expansion of the target control axis number without introducing additional high-cost dedicated motion controllers or high-end multi-axis PLCs, thus balancing system cost and axis expansion requirements.

[0056] Regarding the implementation details of writing motion control parameters and action instructions into the variable names corresponding to the input instruction structure in step S120, in some examples of embodiments of this application, firstly, within the same scan cycle of the main PLC, the cooperative control parameters of the native controlled axis and the extended controlled axis are calculated based on the multi-axis process control logic to obtain the cooperative control parameters corresponding to the native controlled axis and the extended controlled axis respectively; the cooperative control parameters may include parameter information such as cooperative target position and cooperative target speed.

[0057] In other words, regardless of whether the relevant control axis is ultimately driven directly by the main PLC or controlled locally by the slave PLC, the control target corresponding to it within the current control cycle is uniformly generated by the main PLC within the same logic cycle. This helps to maintain a unified time base and consistent process reference when different target control axes generate parameters, reducing the problem of inconsistent action rhythm caused by batch generation of parameters or dispersed control entities.

[0058] Then, the collaborative control parameters and synchronous start instructions corresponding to the extended controlled axis are written into the variable names corresponding to the input instruction structure and synchronously sent to the slave PLC. Based on the collaborative control parameters and synchronous start instructions corresponding to the native controlled axis, the native controlled axis is directly driven locally, so that the native controlled axis and the extended controlled axis start synchronously.

[0059] Specifically, after completing the calculation of the collaborative control parameters, the master PLC can, on the one hand, execute local direct drive on the native controlled axis based on the collaborative target position, collaborative target speed, and corresponding action instructions corresponding to the native controlled axis; on the other hand, it can write the collaborative control parameters and synchronous start instructions corresponding to the extended controlled axis into the variable names corresponding to the input instruction structure, and send them to the slave PLC through the underlying communication transmission area established between the master PLC and the slave PLC. The slave PLC then drives the extended controlled axis through its local pulse output port according to the received control content. Thus, although the native controlled axis and the extended controlled axis are physically driven by the master PLC and the slave PLC respectively, they are both scheduled by the unified process control logic of the master PLC, enabling the native controlled axis and the extended controlled axis to start and operate collaboratively under the same process cycle.

[0060] Taking the aforementioned example of a six-axis blind-filling radar focusing device, when the device needs to drive multiple axes to move synchronously to a set of target focusing postures, the main PLC can simultaneously calculate the target position and target velocity corresponding to each of the X, Y, Z, RX, RY, and RZ axes within the current scanning cycle. Specifically, for the X, Z, RX, and RY axes controlled locally by the main PLC, corresponding drive controls can be directly output. For the Y and RZ axes controlled by the slave PLC, corresponding control parameters and start commands are issued through the input command structure. Since the control parameters of each axis originate from the same main PLC control cycle, and the control content of the extended controlled axes can be periodically transmitted to the slave PLC for execution via the underlying communication transmission area, in engineering applications, the local native axes and the remote extended axes can maintain a good consistent start-up relationship and cooperative operation relationship, thereby meeting the multi-axis linkage control requirements of multi-degree-of-freedom devices.

[0061] Through the embodiments of this application, a hybrid control implementation based on native controlled axes and extended controlled axes is achieved. By retaining some control axes as objects directly driven by the main PLC, and configuring the remaining control axes that exceed the local pulse output capability of the main PLC as extended controlled axes driven by the slave PLC, a low-cost expansion of the target number of control axes is realized under a unified main control architecture. Furthermore, by having the main PLC uniformly complete the collaborative control parameter calculation for both native and extended controlled axes within the same scan cycle, and separately perform local driving and remote distribution, controlled axes at different physical locations can be coordinated and scheduled under the same process logic. This improves the consistency of actions, control coordination, and system scalability during multi-axis linkage processes.

[0062] In some examples of embodiments of this application, after step S130, the underlying hardware sensing signals can be continuously monitored to identify the hardware limit trigger status or servo alarm error code physically acquired from the PLC.

[0063] In practical implementation, in multi-axis spatial collaborative control scenarios, such as in a six-axis blind-spot radar focusing device, there are usually strong spatial positional relationships between multiple target control axes. When any control axis experiences out-of-bounds movement or servo malfunction, it can easily affect the current linkage action. For extended controlled axes driven by the slave PLC, the positive limit signals, negative limit signals, origin signals, and servo alarm signals directly related to these extended controlled axes can be connected to the local input interface of the slave PLC, which can then collect and monitor them during the execution of local axis control. In some examples, axis-related hardware protection can still be set and executed by the slave PLC, while the relevant status is fed back to the master PLC in real time, with both the master and slave sides monitoring the axis status.

[0064] Furthermore, the PLC can write hardware limit status, servo status, and alarm information into the corresponding fields of the output feedback structure, and then feed this information back to the main PLC via the aforementioned structure mapping mechanism. In this way, the main PLC can continuously monitor the positive limit, negative limit, origin, error codes, and other status information of the extended controlled axis by reading the variable names corresponding to the output feedback structure within its control cycle, without needing to build separate, distributed anomaly acquisition interfaces around the remote extended controlled axis. This approach helps to shorten the data transmission link between anomaly status acquisition at the field and the main control logic's perception, improving the timeliness of the main PLC's detection of anomalies in the remote extended controlled axis.

[0065] Furthermore, when the hardware limit trigger state or the servo alarm error code is detected to be active, the global safety interlock protection logic is triggered, and the stop command is written into the variable name corresponding to the input command structure to synchronously send the stop command to all target control axes, thereby stopping the currently running multi-axis process control logic.

[0066] In some implementations, when a hardware limit trigger state or a servo alarm error code is detected to be active, the slave PLC can first perform local basic protection on the corresponding abnormal axis and feed back the abnormal state to the master PLC. After receiving the abnormal state, the master PLC triggers the execution of global safety interlock protection logic and writes the stop command into the variable name corresponding to the input command structure to synchronously issue the stop command to all target control axes, thereby suspending the currently running multi-axis process control logic.

[0067] In a specific implementation, when the master PLC detects that the limit status variable in the output feedback structure is set, or detects an abnormality indicated by the servo alarm error code variable, it can abort the currently executing conventional motion control process and transfer to the safety interlock processing logic. The master PLC undertakes all control programs, interlock protection, and fault handling functions. Therefore, after identifying the abnormal status of any extended controlled axis, the master PLC can not only stop and alarm the corresponding abnormal axis, but also uniformly implement stop control on all target control axes participating in the current process action based on the current multi-axis linkage relationship.

[0068] For example, when the six-axis blind spot compensation radar focusing device performs multi-axis synchronous positioning, if the positive limit, negative limit, or servo alarm is triggered by the Y-axis or RZ-axis controlled by the slave PLC, the slave PLC can first rely on the local hardware protection mechanism to implement basic protection for this axis, and upload the corresponding abnormal status to the master PLC via the output feedback structure; after detecting this abnormality, the master PLC can write the stop instruction for all target control axes into the corresponding variable name of the input instruction structure, so that both the native controlled axis and the extended controlled axis stop the current linkage action, and further perform alarm processing or keep the current process step from advancing. In addition, since the master and slave PLCs can exchange data through standard PROFINET communication with a communication cycle of 1 to 4 ms, this interlock processing method can meet the engineering requirements for the timeliness of abnormal response in this type of multi-axis control scenario.

[0069] Through the embodiments of the present application, an implementation method combining bottom-layer hardware signal monitoring and global safety interlock protection is adopted. By locally collecting and feedbacking the limit status, origin status, and servo alarm information by the slave PLC, and uniformly implementing stop and alarm processing by the master PLC based on the feedback information, the distributed multi-axis collaborative control architecture not only maintains the "master control and slave execution" division of labor mode, but also takes into account the timeliness of local hardware protection and the consistency of global linkage stop. Thus, it is beneficial to reduce the risk that other axes continue to move due to a single-axis abnormality during multi-axis linkage, and improve the system operation safety, interlock control coordination, and reliability in engineering applications.

[0070] Figure 3 The operation flowchart showing an example of performing jog debugging control in the method according to the embodiments of the present application is shown.

[0071] As Figure 3 shown, in step S 310, a jog debugging request is received, and the target jog axis and the corresponding jog debugging identifier corresponding to the jog debugging request are parsed. Here, the jog debugging identifier includes at least one of the following: jog debugging direction identifier, speed increase adjustment identifier, and speed decrease adjustment identifier.

[0072] In practical implementation, during the equipment assembly, sensor calibration, initial setup, or routine maintenance phases of a multi-axis collaborative control system, operators typically need to perform manual jogging adjustments on a single mechanical axis to observe its direction of motion, operational stability, current position changes, and the coordination status between mechanical components. For example, in a six-axis blind-spot radar focusing device, engineers can initiate JOG jogging operations on a specific axis via a human-machine interface, teaching terminal, or host computer debugging interface. The main PLC can periodically receive such jogging adjustment requests during operation and parse the target axis identifier carried in the request to identify the currently selected target jogging axis. The target jogging axis can be either a natively controlled axis directly controlled by the main PLC or an extended controlled axis driven locally by a slave PLC.

[0073] Furthermore, after locking onto the target jogging axis, the main PLC can parse the operational intent in the jogging debugging request to obtain the jogging debugging identifier corresponding to the debugging action. The jogging debugging identifier may include a direction identifier indicating the forward or reverse movement of the target jogging axis, or a speed adjustment identifier for adjusting the axis's running speed during jogging. Through this parsing process, the main PLC can convert the jogging command from the operating interface into a clear control intent for the specific target jogging axis, thus providing a basis for subsequently writing relevant debugging parameters into the input instruction structure.

[0074] In step S320, one or more sub-variables corresponding to the target jog axis are determined in the input instruction structure, and the jog debugging parameters matching the jog debugging identifier are written into the corresponding sub-variables.

[0075] In practical implementation, after parsing the target jogging axis and its corresponding jogging debugging identifier, the main PLC can further locate the control field corresponding to the target jogging axis in the input instruction structure and write the jogging debugging parameters matching the current debugging intention into the corresponding sub-variables. For example, when the jogging debugging identifier indicates forward or reverse jogging, the Boolean sub-variables related to direction control and jogging enable can be set to the corresponding states; when the jogging debugging identifier indicates speed increase or decrease adjustment, the target speed parameter can be adjusted within the preset jogging debugging speed range, and the adjusted speed value can be written into the corresponding numeric sub-variable. In this way, the operator's button actions on the debugging interface can be converted into structured, executable jogging debugging parameters.

[0076] Furthermore, since the input instruction structure has already established a mapping relationship with the aforementioned underlying communication transmission area, after the master PLC completes the writing of the sub-variables, the corresponding jog debugging parameters can be transmitted to the corresponding execution side through the existing communication interface. For native controlled axes, the master PLC can organize local axis control execution based on the written debugging parameters; for extended controlled axes, the relevant jog parameters can be sent to the slave PLC through the corresponding variables of the input instruction structure, and the slave PLC can execute jog control through the local pulse output port based on the jog parameters. Thus, regardless of whether the target jog axis is located on the master PLC side or the slave PLC side, the master PLC can complete the debugging control through a unified jog request parsing process and a unified structure parameter writing method. This helps reduce the program complexity caused by writing independent debugging logic for different axes and improves the consistency and convenience of on-site jog debugging operations.

[0077] The implementation method of jog debugging control based on input command structure adopted in this application parses the target jog axis and jog debugging identifier in the jog debugging request, and writes the corresponding jog debugging parameters into the sub-variables corresponding to the target jog axis in the input command structure. This enables the main PLC to simultaneously support jog debugging of both native and extended controlled axes within a unified control framework. Therefore, on the one hand, it helps meet the actual needs for single-axis fine-tuning and speed adjustment during equipment installation, calibration, and maintenance; on the other hand, it also helps maintain consistency between the upper-level debugging entry and the lower-level execution interface, thereby improving the operational flexibility, program clarity, and engineering applicability of the multi-axis control system in debugging scenarios.

[0078] Figure 4 A flowchart illustrating an example of a master-slave PLC multi-axis collaborative control method according to an embodiment of this application is shown.

[0079] Regarding the execution subject of the method in this application embodiment, it can be a programmable logic controller (PLC) in an industrial automation environment. In some extended examples, as long as it has real-time industrial communication capabilities and a low-level hardware control interface, the method in this application embodiment can also be integrated and configured in other types of industrial electronic devices or control terminals through software, hardware, or a combination of software and hardware. Furthermore, the type of industrial electronic device can be diverse, such as an industrial control computer (IPC), a programmable automation controller (PAC), an industrial control computer / desktop computer running a soft PLC system, or an edge computing gateway with real-time control capabilities, etc.

[0080] For example, the execution subject of the method in this application embodiment can be a controller in a slave PLC integrated in the main control system of automated production equipment. By executing a pre-configured slave control program, the controller parses the control instructions received through the underlying communication transmission area, and performs drive control on the local controlled axis according to the parsed motion control parameters and action instructions. At the same time, the controller collects the corresponding real-time operating status and underlying hardware sensor signals and feeds them back to the main PLC.

[0081] like Figure 4 As shown, in step S410, a communication structure containing an input instruction structure and an output feedback structure is obtained, and the communication structure is mapped to the underlying communication transmission area to establish a variable mapping relationship between the variable names of the master PLC and the underlying hardware addresses of the slave PLC.

[0082] In practical implementation, the slave PLC, acting as the lowest-level execution node in a distributed multi-axis control system, can establish a communication structure matching that of the master PLC during the initialization configuration or hardware configuration phase. This communication structure is then associated with the local low-level communication transmission area used for master-slave data exchange. The communication structure can maintain consistency with the master PLC in terms of field composition and byte length, and at least includes an input instruction structure for receiving control content from the master PLC, and an output feedback structure for sending status information back to the master PLC. For example, the master and slave PLCs can each define communication structures with the same structure, which may include axis control words, axis parameters, setpoints, feedback values, I / O status, and fault information. These structures are directly mapped to the communication transmission area via intelligent I / O communication to achieve automatic binding between variable names and communication addresses.

[0083] Through the above mapping method, the PLC side effectively provides a standardized, structured data interface to the outside world, enabling the content written to variable names by the master PLC to correspond to the corresponding address area on the slave PLC. Simultaneously, the status data collected by the slave PLC can be fed back to the master PLC in a structured format. In this way, the slave PLC does not need to handle complex process interaction logic; it only needs to perform tasks such as instruction reception, axis control execution, and status feedback based on the communication structure. This provides a unified data foundation for subsequent cyclic data exchange and local axis control execution. Using this master-slave division of labor, a control strategy is achieved where the master PLC provides centralized control, and the slave PLC only retains the axis control unit.

[0084] In step S420, the control commands automatically issued by the main PLC are received via the underlying hardware address, the underlying communication transmission area, and the variable mapping relationship. The motion control parameters and action commands corresponding to the control commands are then extracted. Here, the control commands are automatically converted from the motion control parameters and action commands generated by the main PLC based on preset multi-axis process control logic and written into the variable names corresponding to the input command structure.

[0085] In practical implementation, the slave PLC can read the data content corresponding to the input instruction structure from the underlying communication transmission area within its local operating cycle. Since a mapping relationship between the communication structure and address area has been established between the master and slave PLCs, when the master PLC writes parameters such as enable, reset, homing, start, positioning, target position, target speed, and manual adjustment speed corresponding to the target control axis into the structure variables in its control program, the relevant data can be transmitted to the corresponding address on the slave PLC side via the underlying communication transmission area. After reading the data from the slave PLC, it can identify the action instructions and motion control parameters corresponding to the locally controlled axis according to the predefined field positions, for subsequent axis control execution.

[0086] For example, the content sent from the master PLC to the slave PLC may include parameters such as enable, reset, homing, start, target position, target speed, and manual adjustment speed. The slave PLC then feeds back information such as servo status, positive and negative limits, error codes, real-time position, and current speed. The slave PLC does not need to participate in multi-axis process flow judgment, path coordination, or interlocking decisions; instead, it mainly undertakes the functions of receiving structured instructions and preparing for local execution. This allows complex process logic to be centrally retained on the master PLC side while keeping the slave PLC program relatively simple.

[0087] In step S430, based on the extracted motion control parameters and action commands, local drive is performed on the controlled axis from the PLC via the local pulse output port.

[0088] In practical implementation, after the PLC obtains the motion instructions and motion control parameters corresponding to the local controlled axis, it can call the local axis control program unit or pulse servo control module to process the parameters and output the corresponding control signals to the connected servo driver or stepper driver through the local pulse output port to drive the local controlled axis to perform actions such as start, stop, return to zero or positioning.

[0089] Here, the PLC program mainly includes IO mapping and pulse axis control. Under the new architecture, the slave PLC no longer undertakes the process logic, but only retains the basic control unit of the axis. The master PLC is responsible for telling it the target position and action requirements, and the slave PLC executes accordingly. This allows the structured control content issued by the master PLC to be implemented as the actual drive operation of the local controlled axis on the slave PLC side, thereby making full use of the local pulse output resources of the slave PLC itself.

[0090] For example, in a scenario using Siemens S7-1200 series PLCs as master-slave control units, there is an upper limit to the number of local pulse axes each PLC can control; for instance, each PLC can control a maximum of four pulse axes. Therefore, the system can be expanded to a maximum of eight pulse axes with this hardware configuration. In the current six-axis blind-spot radar focusing equipment scenario, the master PLC can be configured to control four axes, and the slave PLC can control two axes. By having the slave PLC undertake some of the local drive tasks for the axes, the number of target control axes can be expanded without changing the overall "master-slave" architecture, meeting the multi-axis control needs of small and medium-sized automated equipment.

[0091] In step S440, the real-time operating status of the controlled axis and the underlying hardware sensing signals are acquired, and the real-time operating status and underlying hardware sensing signals are fed back to the main PLC through the underlying communication transmission area and variable mapping relationship, so that the real-time operating status and underlying hardware sensing signals can be periodically received by the main PLC by reading the variable names corresponding to the output feedback structure.

[0092] In practical implementation, while executing local pulse drive, the PLC can also collect real-time operating status and underlying hardware sensor signals related to the locally controlled axis, and write them into the corresponding fields of the output feedback structure. Real-time operating status can include servo status, action completion status, error codes, current position, and current speed; underlying hardware sensor signals can include local I / O signals related to axis operating safety, such as positive limit, negative limit, and origin. Subsequently, this feedback information can be returned to the main PLC via the underlying communication transmission area, enabling the main PLC to periodically obtain status feedback from the PLC side by reading the variable names corresponding to the output feedback structure.

[0093] For example, the slave PLC feeds back the axis status and I / O status to the master PLC through a structure, and can display information such as enable, homing completion, positioning completion, error code, current position, speed, and positive and negative limits on the human-machine interface. Through this feedback step, a closed-loop data path can be formed between the physical execution end of the slave PLC and the upper-level control end of the master PLC. This allows the master PLC to continuously obtain the operating conditions and local I / O status of the distributed controlled axes while maintaining centralized control logic, providing a data foundation for subsequent multi-axis collaborative control, interlocking protection, and fault handling.

[0094] Figure 5 This document illustrates an example of an operation flowchart for establishing a variable mapping relationship between the variable names of the master PLC and the underlying hardware addresses of the slave PLC in a method according to an embodiment of this application.

[0095] like Figure 5As shown, in step S510, under the network architecture where the PLC is configured as a controlled intelligent IO device and connected to the main PLC, a lower-level communication transmission area corresponding to the communication structure is established.

[0096] In practical implementation, during the hardware configuration phase of the master and slave PLCs, the master PLC can be configured as an I / O controller in the network, and the slave PLC can be configured as an intelligent I / O device managed by the master PLC. A periodic data exchange link is established between the master and slave PLCs through the industrial network. Under this master-slave communication relationship, a data exchange area matching the length of the communication data is reserved for both parties as the underlying communication transmission area.

[0097] The communication structure includes at least an input instruction structure for the master PLC to send control content to the slave PLC, and an output feedback structure for the slave PLC to return status content to the master PLC. The input instruction structure and the output feedback structure can use the same data format composed of fields on both the master and slave sides to ensure that both sides have a consistent parsing method for control items and feedback items in the same data area.

[0098] Furthermore, the underlying communication transmission area can be used to carry the data content corresponding to the input instruction structure and the output feedback structure, enabling the control parameters written by the master PLC to be periodically transmitted to the slave PLC, while simultaneously allowing the local status data collected by the slave PLC to be returned to the master PLC. By configuring the slave PLC as an intelligent I / O device, the slave PLC can participate in master-slave data exchange in the network as a controlled node, thus enabling continuous data transmission and reception between the master PLC and the slave PLC based on the underlying communication mechanism. This facilitates providing a unified data channel for subsequent control instruction reception, local axis control execution, and feedback status uploading.

[0099] In step S520, the input instruction structure is bound as a static overall variable to the corresponding allocated logical input start address in the underlying communication transmission area, and the output feedback structure is bound as a static overall variable to the corresponding allocated logical output start address in the underlying communication transmission area. This ensures that data read and write operations targeting the underlying hardware address are automatically converted into data interaction between the underlying communication transmission area and the corresponding variable name of the main PLC.

[0100] In practical implementation, the PLC side can instantiate the overall variables corresponding to the input instruction structure and output feedback structure, and associate the overall variables with the corresponding starting addresses in the PLC's local underlying communication transmission area. Since the slave PLC is responsible for receiving control content from the master PLC and returning local status to the master PLC in this master-slave communication relationship, the input instruction structure on the slave PLC side can correspond to the data area received from the master PLC, and the output feedback structure can correspond to the data area sent to the master PLC. The sub-variables in the structure are arranged according to a predefined field order. Once the overall variable is bound to its corresponding starting address, each sub-variable can be mapped to its corresponding address in the underlying communication transmission area based on its relative offset within the structure.

[0101] When executing a PLC program, control items such as enable, reset, homing, start, target position, and target speed issued by the main PLC can be directly read using the format "structure variable name.subvariable name". Similarly, locally acquired feedback items such as servo status, positive limit, negative limit, origin status, error codes, current position, and current speed can be written into the corresponding subvariables of the output feedback structure, eliminating the need to maintain the underlying absolute addresses and offset relationships for each control item and feedback item separately. This method of address-binding the communication structure as a whole variable reduces the complexity of manually configuring and maintaining address correspondences, minimizes address misalignment, overlap, or difficulty in modification, and improves the clarity of program organization and the convenience of subsequent expansion.

[0102] Through the embodiments of this application, a low-level communication transmission area corresponding to the communication structure is established in a network architecture where the master PLC acts as the I / O controller and the slave PLC acts as the intelligent I / O device. On the slave PLC side, the input instruction structure and output feedback structure are bound as whole variables to their corresponding starting addresses, enabling data exchange between the master and slave PLCs to be performed using a structured variable interface. On one hand, the slave PLC can receive control content from the master PLC based on a unified data interface and execute local axis control operations; on the other hand, the slave PLC can also feed back the operating status of its controlled axis and low-level hardware signals to the master PLC according to a unified data format. This helps reduce the complexity of address configuration and communication organization in traditional distributed control methods, improves the convenience of program writing and maintenance, and provides a consistent data interface foundation for subsequent multi-axis collaborative control, status feedback, and system expansion.

[0103] Regarding the implementation details of step S430, in some examples of embodiments of this application, when the extracted motion instructions include a synchronous start instruction, in response to the synchronous start instruction, based on the cooperative target position and cooperative target speed in the extracted motion control parameters, a local drive is executed on the controlled axis from the local PLC through the local pulse output port, so that the controlled axis from the local PLC keeps synchronously started with the native controlled axis driven by the local PLC.

[0104] In practical implementation, after the PLC extracts the motion commands and motion control parameters corresponding to the local controlled axis from the data content corresponding to the input command structure, it can further determine whether the motion commands contain synchronous start commands. When the synchronous start command is valid, the PLC can call its local axis control program unit or pulse control unit, and according to the synchronously extracted target position and target speed, drive the local pulse output port to output corresponding control signals to the servo driver or stepper driver connected to the PLC, so that the local controlled axis performs the start, positioning, or motion process. Thus, what the PLC receives is not the high-frequency pulse itself, but the structured control parameters and start control content corresponding to the local controlled axis, while the actual pulse output execution is completed locally by the PLC.

[0105] Furthermore, since the synchronous start command, along with the corresponding cooperative target position and speed, are all generated by the master PLC under unified control logic and transmitted to the slave PLC via the underlying communication transmission area established between the master and slave PLCs, when the master PLC executes local drive on the native controlled axis, the slave PLC can also execute pulse output drive on its local controlled axis based on the received synchronous start command. Thus, although the native controlled axis and the slave PLC's local controlled axis are driven by different control units at the underlying level, both are uniformly scheduled by the same master PLC process control logic, allowing them to be triggered and started within the same control cycle or the same process cycle, maintaining a consistent start-up sequence.

[0106] For example, in a six-axis blind-spot radar focusing device, when the device needs to simultaneously drive multiple axes to a target focusing posture, the main PLC can uniformly calculate the cooperative target position and cooperative target velocity corresponding to each target control axis within the current control cycle, and simultaneously generate a synchronization start command. The main PLC can directly drive the four native controlled axes (X-axis, Z-axis, RX-axis, and RY-axis) based on the corresponding parameters. For the other two motion axes (such as the Y-axis and RZ-axis) controlled by the slave PLC, the corresponding cooperative target position, cooperative target velocity, and synchronization start command can be issued through the input command structure. The slave PLC, upon receiving the control content, executes the drive through its local pulse output port. In this way, the locally controlled axes of the slave PLC and the natively controlled axes driven locally by the main PLC can maintain coordinated startup in the same linkage action, thereby meeting the synchronization control requirements of multi-degree-of-freedom devices.

[0107] In this embodiment, the master PLC uniformly calculates and issues synchronous start commands, while the slave PLC executes pulse drives locally based on the received cooperative target position and cooperative target speed. This ensures that although the native controlled axes on the master PLC side and the locally controlled axes on the slave PLC side are distributed across different control nodes, they can still form a consistent start-up timing relationship under a unified process logic. Therefore, on the one hand, it avoids transmitting the underlying pulse execution process over the network, which helps reduce unnecessary real-time control burden in the communication link; on the other hand, it also allows for the expansion of the number of control axes using the local pulse output resources of the slave PLC without adding high-end multi-axis motion control hardware, and improves control coordination and engineering applicability in multi-axis linkage scenarios.

[0108] In some preferred embodiments of step S440, where information is fed back to the main PLC, the hardware limit trigger status or servo alarm error code of the controlled axis is identified locally by local physical acquisition.

[0109] In practical implementation, while executing the local controlled axis drive, the slave PLC can also collect and monitor the underlying hardware signals related to the local controlled axis through its local input interface or data interface connected to the driver. These underlying hardware signals can include positive limit status, negative limit status, origin status, and alarm status information from the servo driver. When the local controlled axis moves to the mechanical travel boundary and triggers the corresponding limit switch, the slave PLC can identify the corresponding hardware limit trigger status; when the servo driver malfunctions, the slave PLC can also identify the servo alarm error code corresponding to the malfunction. This local acquisition method allows the slave PLC to directly obtain status information related to the safe operation of the controlled axis at its local execution end, thereby improving the timeliness of identifying local abnormal states.

[0110] Furthermore, the PLC can write the identified hardware limit trigger status or servo alarm error code into the corresponding field of the output feedback structure, enabling this type of abnormal status to be fed back to the main PLC via the underlying communication transmission area. In this way, the main PLC can obtain the limit status, alarm status, and other operating status information of the locally controlled axis by reading the corresponding variables in the output feedback structure. This approach facilitates the integration of abnormal statuses from the local actuator into the centralized control framework of the main PLC using a unified data format, providing status-based information for subsequent interlocking judgments and fault handling.

[0111] Furthermore, when a hardware limit trigger state or servo alarm error code is detected to be active, local emergency stop protection is executed for the controlled axis from the PLC. Simultaneously, the hardware limit trigger state or servo alarm error code is updated to the corresponding underlying hardware address, so as to be fed back to the main PLC through the output feedback structure via the underlying communication transmission area, thereby triggering the main PLC to execute the global safety interlock protection logic.

[0112] In practical implementation, when the slave PLC detects that the hardware limit status corresponding to the local controlled axis has been triggered, or detects an abnormality in the servo alarm error code, it can prioritize executing local emergency stop protection for the local controlled axis to stop its continued operation. Simultaneously, the slave PLC can write the corresponding limit status or alarm information into the corresponding field of the output feedback structure and feed it back to the master PLC via the underlying communication transmission area. Upon receiving this abnormal status, the master PLC can suspend the currently executing conventional multi-axis process control logic and trigger the global safety interlock protection logic.

[0113] In multi-axis spatial collaborative control scenarios, when a controlled extended axis controlled by a slave PLC experiences a positive limit trigger, negative limit trigger, or servo alarm, the slave PLC can first execute local shutdown protection for that axis and feed back the corresponding abnormal status to the master PLC. After recognizing the abnormal status, the master PLC can further issue unified shutdown control to other target control axes currently involved in the linkage, thereby terminating the current multi-axis linkage action. By adopting a processing method of first stopping local anomalies, then reporting abnormal statuses, and unified interlocking by the master PLC, the system can maintain the centralized control architecture of the master PLC while taking into account both local anomaly response and global safety coordination.

[0114] Through the embodiments of this application, the hardware limit status and servo alarm status of the locally controlled axes are acquired and identified from the PLC side. When an anomaly is detected, a local emergency stop protection is first executed, and then the corresponding abnormal status is fed back to the main PLC through an output feedback structure, enabling the main PLC to further trigger the global safety interlock protection logic. This improves the timeliness of the slave PLC's response to abnormal statuses at the local execution end, and also allows the main PLC to coordinate the shutdown and fault handling of each target control axis globally. This reduces the risk of other control axes continuing to move due to local anomalies during multi-axis linkage, improving the operational safety and interlock control consistency of the distributed multi-axis collaborative control system.

[0115] Figure 6 A structural block diagram of an example master-slave PLC multi-axis collaborative control system according to an embodiment of this application is shown.

[0116] like Figure 6 As shown, the master-slave PLC multi-axis collaborative control system 600 includes a master PLC 610 and at least one slave PLC 620. The master PLC is configured to execute the steps of the master-slave PLC multi-axis collaborative control method applied to the master PLC as described above, and the slave PLC is configured to execute the steps of the master-slave PLC multi-axis collaborative control method applied to the slave PLC as described above.

[0117] Figure 7 A schematic diagram illustrating an example of the hardware communication architecture of a master-slave PLC multi-axis collaborative control system according to an embodiment of this application is shown.

[0118] like Figure 7 As shown, this system can use two Siemens S7-1200 PLCs, such as the CPU 1215C model illustrated, to form a master-slave control architecture. The two PLCs communicate via an industrial network, such as the PN / IE_1 network shown in the diagram. In some implementations, the master PLC can be configured as the I / O controller in the network, and the slave PLC can be configured as an intelligent I / O device managed by the master PLC, in order to establish a periodic data exchange link between the master and slave stations.

[0119] Furthermore, combined Figure 7 As shown in the example, the master PLC and slave PLC can each utilize their local pulse output resources to execute axis control tasks. For instance, the master PLC provides four-axis pulse output, and the slave PLC provides four-axis pulse output, thereby collaboratively completing multi-axis low-level drive under a unified master-slave communication architecture. This hardware communication architecture provides the network connection and hardware topology foundation for establishing a low-level communication transmission zone between master and slave stations and for subsequently achieving unified multi-axis collaborative control.

[0120] Figure 8A schematic diagram illustrating an example of single-axis control variable structure data in a master-slave PLC multi-axis collaborative control system according to an embodiment of this application is shown.

[0121] like Figure 8 As shown, a single-axis control variable structure of data type "AxisControl" can be defined. In some implementations, the master PLC and slave PLC can use this type of communication structure with consistent field composition and internal layout. This structure can be divided into an "IN" substructure as an input instruction structure and an "OUT" substructure as an output feedback structure. The "IN" substructure can contain axis control words, such as Boolean control items like enable, reset, start, stop, and jog, as well as axis parameters and setpoints, such as numerical parameters like target position, target speed, and jogspeed. The "OUT" substructure can contain axis IO status, fault information, and feedback values, such as Boolean statuses like servo ready, positioning complete, and positive / negative limits, error code words, and real-time numerical feedback such as current position and current speed.

[0122] Furthermore, since the variables within the structure are arranged consecutively in memory according to a predetermined order—for example, the "IN" area in the diagram starts from logical address 170.0, and the "OUT" area starts from 192.0—this structure can serve as a unified data organization unit for subsequent data mapping and interaction between master and slave PLCs. This method of reusing structure variables helps reduce the workload of manually calculating and configuring discrete control bits and data word address offsets item by item, and reduces the risk of address misalignment, thereby improving the consistency of data interaction in distributed axis control units and the engineering reproducibility of multi-axis programs.

[0123] Figure 9 A schematic diagram is shown as an example of a master-slave PLC multi-axis collaborative control system in which multi-axis control structure variables are uniformly declared at the master station according to an embodiment of this application.

[0124] like Figure 9 As shown, in practical implementation, communication structure variables of the same data type can be declared uniformly for multiple target control axes in the system in the variable table of the main PLC or the static variable area of ​​the global data block. Referring to the aforementioned example of a six-axis collaborative control device, the main PLC can instantiate control structure variables of the data type "AxisControl" not only for its natively controlled axes that it directly controls locally, such as the RX, RY, Z, and X axes in the figure, but also for extended controlled axes that are actually driven by the slave PLC, such as the RZ and Y axes in the figure.

[0125] Furthermore, from Figure 9The continuous offsets shown, such as the X-axis starting at 102.0, the RZ-axis starting at 136.0, and the Y-axis starting at 170.0, with a fixed offset interval between adjacent variables, demonstrate that the control structure variables for each axis are continuously arranged in the main PLC memory according to a unified rule. By uniformly declaring multi-axis control structure variables on the master station side, the upper-level multi-axis process control logic of the master PLC can access the local control axis and the slave station control axis using a consistent data interface, thereby simplifying the writing of cross-station control programs and improving the versatility and reusability of multi-axis collaborative control code.

[0126] Figure 10 The diagram shows a code logic diagram illustrating an example of the association between the RZ axis slave station and the master station variables in the master-slave PLC multi-axis collaborative control method according to an embodiment of this application.

[0127] like Figure 10 As shown, in practical implementation, the main PLC can establish the correspondence between upper-level operational variables and RZ axis control variables in its user program through structured assignment statements. Specifically, this code logic can be divided into two parts: For the "RZ output control" part, which issues control commands to the RZ axis, the main PLC can assign upper-level operational variables, such as "operation.RZ.IN.enable" and "operation.RZ.IN.target position", to the input command variables corresponding to the RZ axis control, such as "RZ enable" and "RZ target position"; For the "RZ input control" part, which receives RZ axis feedback status, the main PLC can assign RZ axis feedback variables, such as "RZ enable OK" and "RZ current position", to the internal application variables required by the upper-level logic, such as "operation.RZ.OUT.enable OK" and "operation.RZ.OUT.current position".

[0128] pass Figure 10 As shown in the variable association method, the main PLC can use structured variable assignment at the program level to control and interact with the remote extended controlled axes RZ. This allows for programming primarily focused on upper-level application variables with clear business meanings when writing multi-axis collaborative process flow or human-machine interface programs, eliminating the need to directly handle low-level communication addresses or write complex network transceiver logic in the user program. This improves the readability, maintainability, and ease of development when adding new control axes to the distributed multi-axis control program.

[0129] Figure 11 The diagram shows an example of the code logic for the association of Y-axis slave station and master station variables in a master-slave PLC multi-axis collaborative control method according to an embodiment of this application.

[0130] like Figure 11As shown, in specific implementation, following the aforementioned variable association logic for the RZ axis, the main PLC can use a consistent code framework and variable association logic to achieve control variable association for another remote extended controlled axis, the Y axis. Specifically, for the "Y output control" part, the main PLC can use standardized assignment statements to assign upper-level application variables, such as "operation.Y.IN.enable" and "operation.Y.IN.target position," to the input instruction variables corresponding to the Y axis control, such as "Y enable" and "Y target position." Correspondingly, for the "Y input control" part, the main PLC can assign Y axis feedback variables, such as "Y enable OK" and "Y current position," to the internal state variables required by the upper-level application, such as "operation.Y.OUT.enable OK" and "operation.Y.OUT.current position."

[0131] Combination Figure 10 and Figure 11 As can be seen, because this application adopts a standardized communication structure organization method, the variable association logic of the main PLC can remain consistent when facing different extended controlled axes. In actual engineering implementation, when the system needs to add a new control axis, the program configuration and communication interface of the new axis can be completed based on the existing variable association logic, following the same data structure and assignment rules. This helps to reduce the difficulty of secondary development of multi-axis linkage systems, the cost of code maintenance, and the potential risk of address configuration errors.

[0132] Figure 12 This document illustrates a configuration diagram of an example of the intelligent device communication transmission area and corresponding variable address mapping in a master-slave PLC multi-axis collaborative control system according to an embodiment of this application.

[0133] like Figure 12 As shown, this configuration interface illustrates the memory allocation method of the master-slave PLC's underlying communication transmission area and the mapping relationship between structure sub-variables and absolute addresses. For example, in Figure 12In the "Intelligent Device Communication - Transmission Area" configuration list shown in the lower half, the system can divide data interaction between master and slave stations into byte channels with defined lengths. Taking RZ axis communication as an example, a 22-byte correspondence can be established between the logic output area "Q500...521" of the IO controller (master PLC) and the logic input area "I500...521" of the intelligent device (slave PLC) for control data transmission; simultaneously, a 12-byte correspondence can be established between the logic output area "Q500...511" of the intelligent device and the logic input area "I500...511" of the IO controller for status data feedback. Similarly, for Y-axis communication, a transmission channel from "Q600...621" to "I600...621" and a corresponding feedback channel from "I600...611" to "Q600...611" can be configured. Through this bidirectional mapping method based on the underlying configuration, corresponding data paths can be established for cross-station transmission of upper-level structural variables.

[0134] Furthermore, Figure 12 The upper part of the "PLC_AA_Y Output" and "PLC_AA_Y Input" variable tables shows the correspondence between control variables called by the upper-level process logic and the underlying physical addresses. For example, in the Y-axis output channel, Boolean instruction variables such as "Y Enable" and "Y Reset" can be assigned to various bits of the starting byte, such as %Q600.0 and %Q600.1; subsequent numerical target position and target speed parameters can be assigned to double-word spaces, such as %QD614 and %QD618; and reverse input feedback states such as "Y Enable OK" and "Y Current Position" can be mapped to physical memory areas such as %I600.0 and %ID604. Through this underlying configuration method, scattered control bits and numerical parameters can be formed into continuous data blocks in the communication network, thereby facilitating data interaction between the master PLC and distributed slave stations.

[0135] Figure 13 A schematic diagram of an example interface for detailed address configuration of a single transmission area in a master-slave PLC multi-axis cooperative control system according to an embodiment of this application is shown.

[0136] like Figure 13As shown in the diagram, this figure further illustrates the detailed configuration information of a single transmission area in intelligent device communication, such as the "RZ Input" transmission area. In the "Transmission Area Details" configuration interface, the system can clearly define the communication roles and address allocation rules of both parties exchanging data. Specifically, using "PLC_AA" as the communication partner (i.e., the master PLC) and "PLC_Single Axis" as the local device (i.e., the slave PLC), a correspondence can be established between the logic output area (address type "Q") starting at address 500 on the master PLC side and the logic input area (address type "I") starting at address 500 on the slave PLC side, and the data length of this transmission channel can be set to 22 bytes.

[0137] pass Figure 13 The detailed configuration settings shown illustrate that data interaction between the master and slave PLCs can be implemented as a specific physical memory block mapping relationship. Once the above configuration parameters are downloaded to the PLC device, data in the output address block of the master PLC can be transmitted to the corresponding input address block of the slave PLC via the underlying communication transmission area. For program implementation, the correspondence between the output area of ​​the master PLC and the input area of ​​the slave PLC can be configured through a graphical address mapping method, thereby reducing the complexity of writing network transceiver logic separately in the user program and providing the underlying configuration foundation for control data transmission in multi-axis collaborative control systems.

[0138] Figure 14 A schematic diagram illustrating an example of the slave PLC-side program logic and master-slave division of labor mechanism in a master-slave PLC multi-axis collaborative control system according to an embodiment of this application is shown.

[0139] like Figure 14 As shown in the diagram, this illustrates the main program architecture from the PLC side. Specifically, program segment 1, "Axis Call," may include a call to the underlying pulse servo drive function block, such as "%FB12 Pulse Servo" in the diagram, used to execute the drive control of the locally controlled axis; program segment 2 may include data transfer instructions, such as the MOVE instruction in the diagram, used to write the sensor input data corresponding to the RZ and Y axes, such as "%IB0 Single Axis Input," to the output address corresponding to the underlying communication transmission area, such as "%QB700 Single Axis TOAA," so that the main PLC can centrally receive, monitor, and process it. Figure 14 As can be seen from the program logic shown, in this embodiment, the program on the PLC side mainly undertakes local axis drive control, low-level IO acquisition and related data forwarding functions, but does not undertake multi-axis process flow organization or global business judgment tasks.

[0140] Furthermore, in conjunction with the master-slave control architecture in the embodiments of this application, the master-slave division of labor mechanism can be described as follows: the slave PLC, as an edge-side execution unit, is mainly responsible for local controlled axis driving, physical I / O signal acquisition, and communication data uploading; the master PLC, as a centralized control unit, after receiving the operating status, limit signals, alarm information, and other feedback data uploaded by the slave PLC, uniformly executes the logical judgment, process scheduling, motion parameter generation, and global safety interlocking processing in multi-axis collaborative control. This division of labor allows the slave PLC-side program structure to remain relatively simple, while retaining centralized decision-making and complex logic processing in multi-axis collaborative control on the master PLC side. This helps reduce the development and debugging complexity of the slave PLC program and improves the scalability and maintenance convenience of the entire multi-axis collaborative control system.

[0141] Figure 15 A schematic diagram is shown as an example of centralized six-axis control implemented through a human-machine interface in a master-slave PLC multi-axis collaborative control system according to an embodiment of this application.

[0142] like Figure 15 As shown, the system provides operators with a unified debugging and control interface through human-machine interaction devices, such as touch screens. This interface allows for the centralized setting and display of operation items and status information for multiple target control axes. Examples include the jog control buttons, running speed settings, positioning start items, and current position display items for the X, Y, Z, RX, RY, and RZ axes, as shown in the figure. This enables multiple control axes to be centrally displayed and uniformly operated within the same interface.

[0143] Furthermore, combining the communication structure mapping mechanism and master-slave division of labor in the embodiments of this application, this interface can be used for both the operation and display of the axis controlled locally by the master PLC and the operation and display of the axis controlled by the slave PLC. When the operator is... Figure 15 When performing standby position setting, running speed input, start positioning, or jog debugging operations on each axis, such as X+, Y-, RZ+, etc., on the interface shown, the main PLC can generate corresponding control parameters based on the current operation command and implement local control or send them to the slave PLC via the communication structure, combining the affiliation of each target control axis. Simultaneously, feedback information such as the current position of each axis can also be centrally displayed on the human-machine interface.

[0144] Therefore, at the operational level, multiple target control axes can be uniformly debugged and centrally controlled through a single human-machine interface, facilitating operators to perform overall operation and status monitoring of multi-axis systems distributed across PLCs. For example, in a six-axis blind spot radar equipment scenario, the coordinated debugging and positioning control of the six control axes can be completed through this interface. This centralized interface control method helps improve the operational convenience, debugging efficiency, and system integration of multi-axis collaborative equipment.

[0145] Figure 16 A schematic diagram of an example of a fine-tuning and monitoring interface for a single axis (e.g., the RZ axis) in a master-slave PLC multi-axis collaborative control system according to an embodiment of this application is shown.

[0146] like Figure 16 As shown, in addition to the aforementioned centralized multi-axis control interface, the human-machine interface device can also provide separate operation and status display interfaces for each target control axis. Taking the RZ axis as an example, this interface can be divided into an operation area for issuing control commands, a status display area for displaying the running status, and a top status indicator area. Through this single-axis interface, operators can independently set parameters, issue actions, and monitor the status of a specific target control axis.

[0147] Furthermore, the various operation items and display items in this interface can be correlated with the input command structure and output feedback structure in the aforementioned single-axis control variable structure. Specifically, in the operation area, Boolean operation items such as enable, reset, restart, return to origin, JOG+, and JOG- can be set, as well as numerical parameter input items such as target position, target speed, and JOG speed; in the status display area and status indicator area, relevant status information corresponding to the target control axis can be displayed, such as servo ready, running, in position, fault, positive limit, negative limit, as well as error code, current position, and current speed. Thus, the operation items and feedback items on the single-axis interface can be organized and displayed according to a unified data structure.

[0148] pass Figure 16 The single-axis debugging and monitoring interface shown provides a unified operation entry and status display method for the target control axis on the human-machine interface on the main PLC side. This facilitates independent operation and detailed monitoring of a single control axis by operators during equipment assembly, debugging, and maintenance. Furthermore, it helps maintain consistent interface control logic between the native and extended controlled axes at the application layer, further demonstrating the system characteristics of "distributed deployment of controlled objects and centralized implementation of operation and monitoring" in this application.

[0149] This application presents a multi-axis control architecture based on dual PLC collaboration, which is innovative in two main aspects: communication organization and master-slave division of labor. Firstly, by employing a communication structure variable mapping mechanism to establish the correspondence between master PLC variables and slave PLC underlying addresses, the communication configuration is transformed from the traditional manual address allocation method to a unified configuration method oriented towards structure variables, thereby simplifying the communication debugging process and reducing the risk of address configuration errors. Secondly, by adopting a division of labor model of "centralized control by the master PLC and axis control execution by the slave PLC," the master PLC uniformly undertakes process flow, logic scheduling, motion planning, interlock protection, and fault handling, while the slave PLC mainly undertakes axis drive execution, IO acquisition, and status forwarding. This makes the multi-axis collaborative control architecture more centralized and clear, reducing the coupling and maintenance complexity caused by the dispersion of multiple PLC programs.

[0150] Based on this, the embodiments of this application achieve centralized convergence of axis control parameters, IO signals, and operating status from the PLC side to the main PLC through unified data interaction between the master and slave PLCs, and the main PLC implements unified scheduling and global control. Compared with traditional solutions that rely on high-performance PLCs or dedicated motion controllers, the embodiments of this application can meet the multi-axis control requirements of small and medium-sized automation equipment while balancing control performance and hardware cost; moreover, when adding control axes or expanding IO points, only the structure variable definitions and the acquisition and execution logic on the PLC side need to be adjusted, without making significant modifications to the core control flow of the main PLC, thus having better expansion flexibility, maintenance convenience, and engineering applicability.

[0151] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of combined actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Secondly, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application. In the above embodiments, the descriptions of each embodiment have their own emphasis; for parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0152] In some embodiments, this application also provides a computer program product, the computer program product including a computer program stored on a non-volatile computer-readable storage medium, the computer program including program instructions, which, when executed by a computer, cause the computer to perform any of the above-described master-slave PLC multi-axis cooperative control methods.

[0153] In some embodiments, this application also provides an electronic device, which includes: 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 perform a master-slave PLC multi-axis collaborative control method.

[0154] The apparatus described in the embodiments of this application can be used to execute the master-slave PLC multi-axis collaborative control method of this application, and accordingly achieve the technical effects achieved by the master-slave PLC multi-axis collaborative control method of the embodiments of this application, which will not be elaborated here. In the embodiments of this application, the relevant functional modules can be implemented by a hardware processor.

[0155] Figure 17 This is a schematic diagram of the hardware structure of an electronic device for executing a master-slave PLC multi-axis cooperative control method according to another embodiment of this application, as shown below. Figure 17 As shown, the device includes: One or more processors 1710 and memory 1720, Figure 17 Take the 1710 processor as an example.

[0156] The device that performs the master-slave PLC multi-axis collaborative control method may also include: input device 1730 and output device 1740.

[0157] The processor 1710, memory 1720, input device 1730, and output device 1740 can be connected via a bus or other means. Figure 17 Taking the example of a connection between China and Israel via a bus.

[0158] The memory 1720, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as the program instructions / modules corresponding to the master-slave PLC multi-axis cooperative control method in the embodiments of this application. The processor 1710 executes various functional applications and data processing of the server by running the non-volatile software programs, instructions, and modules stored in the memory 1720, thereby realizing the master-slave PLC multi-axis cooperative control method in the above-described method embodiments.

[0159] Memory 1720 may include a program storage area and a data storage area, wherein the program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the device, etc. Furthermore, memory 1720 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, memory 1720 may optionally include memory remotely located relative to processor 1710, and these remote memories may be connected to the device via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0160] Input device 1730 can receive input digital or character information and generate signals related to user settings and function control of the device. Output device 1740 may include display devices such as a display screen.

[0161] The one or more modules are stored in the memory 1720, and when executed by the one or more processors 1710, the master-slave PLC multi-axis collaborative control method in any of the above method embodiments is executed.

[0162] The above-described product can perform the methods provided in the embodiments of this application, and has the corresponding functional modules and beneficial effects for performing the methods. Technical details not described in detail in this embodiment can be found in the methods provided in the embodiments of this application.

[0163] The electronic devices described in this application are primarily aimed at the field of industrial automation control, and their forms include, but are not limited to: (1) Programmable Logic Controller (PLC): including master PLC and slave PLC devices with integrated real-time communication interface and local pulse output port.

[0164] (2) Industrial Control Computer (IPC) and Edge Computing Gateway: An industrial-grade computer terminal with real-time processing capabilities and industrial bus expansion interface, capable of running soft PLC systems or executing multi-axis collaborative control algorithms.

[0165] (3) Programmable Controller (PAC): A complex industrial control device that combines the computing power of a PC with the reliability of a traditional PLC.

[0166] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0167] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented using software plus a general-purpose hardware platform, or of course, using hardware. Based on this understanding, the above technical solutions, in essence or the parts that contribute to the related technology, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

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

Claims

1. A master-slave PLC multi-axis collaborative control method, applied to a master PLC, the method comprising: Obtain a communication structure containing an input instruction structure and an output feedback structure, and map the communication structure to the underlying communication transmission area to establish a variable mapping relationship between the variable names of the main PLC and the underlying hardware addresses of at least one slave PLC. Based on preset multi-axis process control logic, motion control parameters and action commands are generated for at least one target control axis. The motion control parameters and action commands are written into the variable name corresponding to the input command structure. The write operation for the variable name generates a control command for the underlying hardware address of the slave PLC according to the variable mapping relationship, and is automatically sent to the slave PLC via the underlying communication transmission area. The multi-axis process control logic includes multi-degree-of-freedom spatial cooperative motion logic and / or multi-station synchronous positioning logic. By reading the variable name corresponding to the output feedback structure, and through the underlying communication transmission area and the variable mapping relationship, the real-time operating status and underlying hardware sensing signals fed back from the PLC are periodically received. Based on the received real-time operating status and the underlying hardware sensing signals, the operating status of the multi-axis process control logic is updated.

2. The method according to claim 1, wherein, The step of mapping the communication structure to the underlying communication transmission area to establish a variable mapping relationship between the variable names of the master PLC and the underlying hardware addresses of at least one slave PLC includes: The master PLC is set as an IO controller, and the slave PLC is set as a controlled intelligent IO device, so as to establish a low-level communication transmission area corresponding to the communication structure between the master PLC and the slave PLC. The input instruction structure is bound as a static overall variable to the corresponding allocated logical output start address in the underlying communication transmission area, and the output feedback structure is bound as a static overall variable to the corresponding allocated logical input start address in the underlying communication transmission area. This ensures that read and write operations on any sub-variable within the communication structure are automatically converted into direct access to the underlying hardware address via the underlying communication transmission area.

3. The method according to claim 1, wherein, The input instruction structure contains at least Boolean instruction variables and numerical parameter variables, and the output feedback structure contains at least Boolean state variables and numerical parameter variables; The Boolean instruction variable is used to indicate at least one of the following actions: enable, reset, return to zero, start, stop, and jog; and the numerical parameter variable in the input instruction structure is used to set at least one of the following: target position and target speed. The Boolean state variable is used to indicate at least one of the following states: servo ready, homing completed, positioning completed, and hardware limit trigger. The numerical parameter variable in the output feedback structure is used to indicate at least one of the following states: current actual position, current actual speed, and error code.

4. The method according to claim 1, wherein, The target control axis includes a native controlled axis directly controlled by the main PLC through a local pulse output port, and an extended controlled axis directly controlled by the slave PLC through a local pulse output port; The process generates motion control parameters and action commands for at least one target control axis based on preset multi-axis process control logic, and writes the motion control parameters and action commands into the variable names corresponding to the input command structure, including: Within the same scan cycle of the main PLC, the multi-axis process control logic is used to calculate the collaborative control parameters of the native controlled axis and the extended controlled axis to obtain the collaborative control parameters corresponding to the native controlled axis and the extended controlled axis respectively; the collaborative control parameters include the collaborative target position and the collaborative target speed. The collaborative control parameters and synchronous start instructions corresponding to the extended controlled axis are written into the variable name corresponding to the input instruction structure and synchronously sent to the slave PLC. The slave PLC performs local direct drive on the native controlled axis according to the collaborative control parameters and synchronous start instructions corresponding to the native controlled axis, so that the native controlled axis starts synchronously with the extended controlled axis.

5. The method according to claim 1, wherein, After periodically receiving the real-time operating status and low-level hardware sensor signals collected and fed back from the low-level hardware address of the PLC by reading the variable names corresponding to the output feedback structure, via the low-level communication transmission area and the variable mapping relationship, the method further includes: Continuously monitor the underlying hardware sensor signals to identify the hardware limit trigger status or servo alarm error code acquired locally from the PLC. When the hardware limit trigger state or the servo alarm error code is detected to be active, the global safety interlock protection logic is triggered, and the stop command is written into the variable name corresponding to the input command structure to synchronously send the stop command to all the target control axes, thereby stopping the currently running multi-axis process control logic.

6. The method according to claim 1, wherein, The method also includes jog adjustment control, specifically including: Receive a jog adjustment request and parse out the target jog axis corresponding to the jog adjustment request and the corresponding jog adjustment identifier; the jog adjustment identifier includes at least one of the following: jog adjustment direction identifier, speed increase adjustment identifier, and speed decrease adjustment identifier; Determine one or more sub-variables in the input instruction structure that correspond to the target jog axis, and write the jog debugging parameters that match the jog debugging identifier into the corresponding sub-variables.

7. A master-slave PLC multi-axis collaborative control method, applied to a slave PLC, the method comprising: Obtain a communication structure containing an input instruction structure and an output feedback structure, and map the communication structure to the underlying communication transmission area to establish a variable mapping relationship between the variable names of the master PLC and the underlying hardware addresses of the slave PLC. Through the underlying hardware address, via the underlying communication transmission area and the variable mapping relationship, the control instructions automatically issued by the main PLC are received, and the motion control parameters and action instructions corresponding to the control instructions are extracted; wherein, the control instructions are automatically converted by the main PLC from the motion control parameters and action instructions generated based on the preset multi-axis process control logic and written into the variable name corresponding to the input instruction structure. Based on the extracted motion control parameters and action commands, local drive is executed on the controlled axis from the PLC via the local pulse output port; The real-time operating status and underlying hardware sensing signals of the controlled axis are collected, and the real-time operating status and underlying hardware sensing signals are fed back to the main PLC via the underlying communication transmission area and the variable mapping relationship, so that the real-time operating status and underlying hardware sensing signals can be periodically received by the main PLC by reading the variable name corresponding to the output feedback structure.

8. The method according to claim 7, wherein, The step of mapping the communication structure to the underlying communication transmission area to establish a variable mapping relationship between the variable names of the master PLC and the underlying hardware addresses of the slave PLC includes: In the network architecture where the intelligent IO device configured as a controlled device from the PLC is connected to the main PLC, a lower-level communication transmission area corresponding to the communication structure is established; The input instruction structure is bound as a static overall variable to the corresponding allocated logical input start address in the underlying communication transmission area, and the output feedback structure is bound as a static overall variable to the corresponding allocated logical output start address in the underlying communication transmission area. This ensures that data read and write operations targeting the underlying hardware address are automatically converted into data interaction between the underlying communication transmission area and the corresponding variable name of the main PLC.

9. A master-slave PLC multi-axis collaborative control system, comprising a master PLC and at least one slave PLC; The main PLC is configured to perform the steps of the method as described in any one of claims 1 to 6; The PLC is configured to perform the steps of the method as described in claim 7 or 8.

10. A computer device comprising a memory, a processor, and a computer program stored in the memory, wherein, The processor executes the computer program to implement the steps of the method according to any one of claims 1-8.

Images