Industrial robot teaching control system, control method and storage medium

Abstract

The application discloses an industrial robot teaching control system, a control method and a storage medium, and relates to the technical field of industrial robots. The teaching control system comprises a man-machine interaction module, which is arranged on a teaching terminal and is used for collecting terminal operation instructions; an API conversion module, which is connected with the man-machine interaction module and is configured with a device capability abstraction layer, the device capability abstraction layer being used for uniformly and standardly converting operation instructions of different types of teaching terminals; and a remote calling module, which is connected with the API conversion module and a business logic module arranged on a robot controller, respectively, and is used for issuing the standardly converted instructions to the business logic module, and for receiving result data after the business logic module executes the instructions and transmitting the result data to the man-machine interaction module. The scheme improves the versatility and compatible adaptation capability between different types of teaching terminals and the robot controller, and improves the convenience of robot teaching debugging and the equipment multiplexing rate.

Description

Technical Field

[0001] This invention belongs to the field of industrial robot technology, specifically relating to an industrial robot teaching control system, control method, and storage medium. Background Technology

[0002] In industrial robot control, conventional teaching pendants and robot controllers are configured with a one-to-one dedicated binding. Data interaction between the two relies on proprietary communication protocols and IDT interface mapping, resulting in deep coupling between the underlying hardware and software. Existing solutions lack a standardized intermediate architecture for instruction conversion and device abstraction. The operation instruction formats and communication protocols of different brands and types of teaching terminals (dedicated handheld teaching pendants, industrial tablets, mobile devices, etc.) are inconsistent. Controllers need to customize their parsing logic for each interactive device, which not only limits a single controller to a fixed teaching device, making it difficult to flexibly replace or expand the human-machine interface hardware, but also makes the communication method relying on direct IDT screen transmission prone to link instability and display screen distortion under long-distance and harsh working conditions. The high degree of device customization and the difficulty in compatibility and expansion lead to a series of derivative drawbacks, such as limited device selection and high hardware and software maintenance costs.

[0003] The above content is only used to help understand the technical solution of the present invention and does not represent an admission that the above content is prior art. Summary of the Invention

[0004] The purpose of this invention is to provide an industrial robot teaching control system, control method, and storage medium to solve the problem of deep hardware and software coupling between robot teaching devices and controllers in related solutions, which makes it impossible to achieve universal access for multiple types of interactive terminals. This invention aims to improve the universality and compatibility between different models of teaching terminals and robot controllers, thereby increasing the convenience of robot teaching and debugging and the reusability of equipment.

[0005] This invention provides an industrial robot teaching control system, comprising: a human-machine interaction module deployed on a teaching terminal for collecting terminal operation commands; an API conversion module connected to the human-machine interaction module and configured with a device capability abstraction layer, wherein the device capability abstraction layer is used to uniformly standardize the operation commands of different types of teaching terminals; and a remote invocation module connected to the API conversion module and a business logic module located on the robot controller, for sending the standardized converted commands to the business logic module and for receiving the result data after the business logic module executes the commands and transmitting it to the human-machine interaction module.

[0006] In some implementations, the device capability abstraction layer includes at least two device adaptation subunits, each corresponding to a type of teaching terminal; the device adaptation subunit is used to translate the private instructions of the corresponding type of teaching terminal into a unified instruction format.

[0007] In some implementations, the remote call module is configured with an RPC communication link, which is equipped with an asynchronous processing mechanism and a disconnection reconnection mechanism.

[0008] In some implementations, the API conversion module includes an instruction receiver, an instruction parser, and a standardizer; the instruction receiver is used to receive the original operation instruction; the instruction parser is used to split the original instruction; and the standardizer is used to generate a standard API according to a preset specification based on the information after splitting the original instruction and store it in the API pool.

[0009] In some implementations, the normalizer is configured with a serialization unit and a deserialization unit; the serialization unit is used to convert object data corresponding to a standard API into byte data that can be transmitted over the network, and the deserialization unit is used to restore the received byte data back to program object data.

[0010] In some implementations, the industrial robot teaching control system further includes an event feedback module, which is connected to the business logic module and the remote call module respectively, and uses a publish-subscribe architecture to transmit the running data from the robot controller to the teaching terminal. The event feedback module includes an event queue module and an event arbitration module. The event queue module is used to cache the running data according to the receiving order, and the event arbitration module is used to filter the data to be pushed to the teaching terminal from the cached running data according to a preset priority rule.

[0011] Another aspect of the present invention provides a control method for an industrial robot teaching control system, comprising: collecting operation instructions output by different types of teaching terminals; performing unified and standardized conversion of the operation instructions of different types of teaching terminals through an API conversion module; sending the standardized converted instructions to a business logic module located in the robot controller, receiving the result data after the business logic module executes the instructions, and transmitting the result data to the teaching terminal.

[0012] In some implementations, the control method further includes: acquiring operational data from the robot controller side, and transmitting the operational data to the teaching terminal based on a publish-subscribe architecture after event arbitration filtering; wherein, the event arbitration filtering includes: polling the operational data cached in the event queue, filtering the data to be pushed according to a user-defined arbitration mechanism or a preset default priority rule, and after the filtered events are converted to a standardized format, pushing them to the human-computer interaction interface corresponding to the teaching terminal based on the subscription relationship.

[0013] In some implementations, the control method further includes: transmitting instruction and result data via an RPC communication link in conjunction with an asynchronous processing mechanism and a disconnection reconnection mechanism; and translating the private instructions of the corresponding type of teaching terminal into a unified instruction format.

[0014] In conjunction with the above method, the present invention further provides a storage medium comprising a stored program, wherein, when the program is executed, the device containing the storage medium is controlled to perform the control method of the industrial robot teaching control system described above.

[0015] The solution of this invention involves a human-computer interaction module that collects operation commands from various teaching terminals, an API conversion module that standardizes differentiated commands using an internal device capability abstraction layer, and a remote invocation module that remotely sends standardized commands to the business logic module while simultaneously sending the execution result data generated by the business logic module back to the human-computer interaction module. This improves the compatibility and adaptability of multi-specification teaching terminals, increases equipment reuse rate and robot on-site debugging efficiency, and, through closed-loop transmission of command issuance and result feedback, facilitates real-time monitoring of equipment operating status by operators, reducing equipment modification and program development costs.

[0016] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention.

[0017] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0018] Figure 1 This is a schematic diagram of the industrial robot teaching control system of the present invention;

[0019] Figure 2 This is a schematic diagram of the API conversion module;

[0020] Figure 3 This diagram illustrates the relationship between the remote invocation module, the human-computer interaction module, and the business logic module.

[0021] Figure 4 A diagram illustrating the publish-subscribe architecture;

[0022] Figure 5 This is a flowchart illustrating the event arbitration module.

[0023] Figure 6 This is a flowchart illustrating the control method of the industrial robot teaching control system of the present invention. Detailed Implementation

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

[0025] According to embodiments of the present invention, an industrial robot teaching control system is provided, such as... Figure 1 As shown, the industrial robot teaching control system includes: a human-machine interaction module, an API conversion module, and a remote call module.

[0026] The human-machine interface (HMI) module, deployed within the teaching pendant, is used to collect terminal operation commands. The teaching pendant is a human-machine interface device used by operators to manually debug, program actions, and set parameters for industrial robots. This device can receive manual input commands via buttons, touchscreen, or joystick, serving as the hardware carrier for interaction between humans and the robot control system. The HMI module, deployed within the teaching pendant, can capture various operational inputs generated by the operator on the teaching pendant in real time and convert the physical inputs into digital operation commands that the system can recognize.

[0027] The API conversion module, connected to the human-computer interaction module, is equipped with a device capability abstraction layer. This layer is used to standardize and convert operation commands from different types of teaching terminals. The API conversion module enables interoperability between different command formats, accepting differentiated command content output from various teaching terminals and standardizing the command formats using the device capability abstraction layer. The device capability abstraction layer is an intermediate adaptation layer built within the API conversion module. This layer shields the differences in proprietary communication protocols and command encoding rules between different teaching terminal models, enabling the conversion of multi-source commands to a unified format.

[0028] The remote invocation module connects the API conversion module and the business logic module located in the robot controller. It sends standardized converted instructions to the business logic module and receives the result data from the business logic module after executing the instructions, transmitting it to the human-machine interaction module. The remote invocation module acts as a relay component for cross-device data interaction, establishing a data transmission channel between the teaching terminal and the robot controller, enabling bidirectional data flow between instruction issuance and execution result feedback. The robot controller is the core control device managing the motion logic and action execution logic of the industrial robot. It receives external control instructions and drives the mechanical structure to complete corresponding actions. The business logic module, deployed inside the robot controller, parses external control instructions and drives the robot to complete corresponding actions according to the instructions, while also summarizing the result data generated after instruction execution.

[0029] like Figure 1 As shown, in the industrial robot teaching control system, the human-machine interaction module, API conversion module, and remote call module are integrated inside the teaching terminal, while the business logic module is located inside the robot controller. The operator generates action commands through the human-machine interaction module and transmits them to the API conversion module. The API conversion module, relying on its internally configured device capability abstraction layer, performs unified and standardized conversion processing on operation commands from different sources and in different formats, and then sends them to the remote call module. The remote call module transmits the standardized action commands across hardware to the business logic module inside the robot controller. After executing the corresponding control task, the business logic module generates results and status feedback data, which is then transmitted back to the remote call module. Finally, the remote call module pushes the feedback data to the human-machine interaction module to complete information reception and display, thus fully realizing a closed-loop two-way data interaction process of command issuance, device execution, and status feedback.

[0030] In existing industrial robot applications, different brands and models of teaching terminals are equipped with their own proprietary instruction specifications. A single model of teaching terminal can only be matched with the corresponding model of robot controller. The hardware and software of the devices are deeply bound together, and changing the teaching terminal requires simultaneous modification of the controller program, resulting in poor device versatility. This solution adds a device capability abstraction layer as an intermediate adaptation carrier. By using the abstraction layer, the problem of instruction differences between different teaching terminals is smoothed out, breaking the technical limitation of one-to-one binding between terminal and controller.

[0031] In some implementations, the device capability abstraction layer includes at least two device adaptation subunits, each corresponding to a type of teaching terminal; the device adaptation subunit is used to translate the private instructions of the corresponding type of teaching terminal into a unified instruction format.

[0032] The device adaptation subunit is a command translation function unit for a single type of teaching pendant. Each independent device adaptation subunit corresponds to the proprietary command specification of a specific teaching pendant. Proprietary commands are exclusive command encoding formats and communication rules defined by each brand and model of teaching pendant manufacturer. Teaching pendants developed by different manufacturers will use mutually exclusive command encoding logic.

[0033] When a teaching terminal outputs a raw operation command with its own proprietary encoding rules, the corresponding device adaptation subunit for that terminal model receives this proprietary command. The device adaptation subunit translates each of the differentiated proprietary commands into a unified command format common to the system, according to preset mapping rules. The standardized commands, after translation, continue to circulate within the device capability abstraction layer and then enter the subsequent command standardization processing flow. When multiple teaching terminals of different types are connected to the system simultaneously, the proprietary commands issued by different terminals are distributed to their respective device adaptation subunits for format conversion.

[0034] By setting up multiple sets of device adaptation sub-units that correspond one-to-one with terminal categories in the device capability abstraction layer, the system realizes the directional conversion of private instructions of different models of teaching terminals to a unified instruction format, which greatly reduces the cost of equipment modification and program development in scenarios where multiple types of teaching terminals are used together. When expanding the access of new teaching terminals in the future, only the corresponding adaptation units need to be added, and the main system architecture does not need to be changed, effectively improving the terminal expandability and equipment versatility of the entire control system.

[0035] In some implementations, the remote call module is configured with an RPC communication link, which is equipped with an asynchronous processing mechanism and a disconnection reconnection mechanism.

[0036] RPC communication links enable cross-device remote procedure calls, relying on established communication protocols to facilitate program function and data interaction between different hardware carriers. The asynchronous processing mechanism is a task scheduling and execution mode during data transmission. After the sending end completes its data transmission operation, it does not need to continuously block and wait for the receiving end to return immediate response data. The sending end can simultaneously perform other business processing tasks, and the receiving end actively sends back the corresponding feedback information after completing data processing. The disconnection reconnection mechanism is a fault-tolerant control logic used to ensure communication continuity. When the communication link is interrupted due to line fluctuations or network failures, the communication link can autonomously detect the disconnection state and repeatedly attempt to re-establish the communication connection according to preset rules.

[0037] In conventional synchronous short-connection communication mode, the data sending device needs to wait for the robot controller to return a response after sending a command. During this waiting period, the device cannot process new teaching commands, causing command queuing and congestion. Simultaneously, industrial environments present challenges such as electromagnetic interference, loose network cables, and fluctuating wireless network signals, which can easily lead to momentary communication interruptions. Once the link is broken, control commands are lost, and the robot's operating status cannot be transmitted. This solution incorporates an RPC communication link within the remote invocation module and integrates asynchronous processing and reconnection mechanisms within the link. It addresses industry shortcomings such as communication congestion and command packet loss from two dimensions: transmission scheduling and fault self-healing.

[0038] Specifically, after the standardized control commands are sent to the remote call module, the module initiates remote data interaction via the RPC communication link. The asynchronous processing mechanism controls the sending process. After the remote call module issues a command, it immediately resumes standby mode and continuously receives newly generated standardized commands from the API conversion module. It will not pause the sending and receiving of new commands while waiting for feedback from the controller. After the business logic module on the robot controller side receives the command and completes the action execution, it asynchronously sends back the result data through the same RPC communication link. If the link is disconnected during command issuance or data transmission, the disconnection and reconnection mechanism will monitor the link connectivity status in real time and automatically start the reconnection and retry process. After the link is restored, the previously delayed commands or feedback data will be resent.

[0039] In some implementations, the API conversion module includes an instruction receiver, an instruction parser, and a standardizer. The instruction receiver receives the original operation instruction; the instruction parser breaks down the original instruction; and the standardizer generates a standard API according to a preset specification based on the information obtained from the breakdown of the original instruction and stores it in the API pool. A standard API is program call interface data encapsulated according to a unified system data specification. This type of data has a fixed field structure and can be uniformly identified and parsed by the remote transmission link and the controller's business logic. The API pool is a centralized data storage space for storing the generated standard API data, and this storage space can temporarily cache various standardized API data to be issued.

[0040] The unified format instructions output by the device capability abstraction layer are first sent to the instruction receiver. The instruction receiver receives all the original instruction data completely and transmits it down to the instruction parser. The instruction parser breaks down the information carried by the original instruction according to the data composition logic, separating independent information such as action coordinates, running speed, and device number. The various types of information after being separated are sent to the standardizer. The standardizer, referring to the preset specifications of the system, assembles and encapsulates the fragmented information according to a fixed structure to generate a compliant standard API. The generated standard API is temporarily stored in the API pool, waiting for remote calling modules to retrieve and send it as needed.

[0041] like Figure 2 As shown, the original instructions after queuing are first sent to the instruction receiver. The instruction receiver then transmits the received original instructions to the instruction parser. The instruction parser uses a pre-stored instruction protocol table to compare and split the various parameter information inside the instruction. The parsed data is then sent to the standardizer. The standardizer queries the interface specifications in the API pool and uses the API interface to construct and generate a standard API. Finally, the standardizer outputs the standardized instructions that have been formatted.

[0042] Even after being transformed by the device capability abstraction layer, the unified instructions are still fragmented structured data. This fragmented data cannot directly adapt to the data encapsulation requirements of remote cross-device calls, and the inconsistent data arrangement formats of different instructions can easily cause transmission and parsing errors. By splitting the processing flow into three stages—receiving, parsing, and standardizing generation—the fragmented instruction data is systematically organized step by step, and the fragmented instructions are uniformly encapsulated into a standard API with a fixed structure. This ensures data consistency in subsequent remote calls and controller parsing processes.

[0043] In some implementations, the normalizer is configured with a serialization unit and a deserialization unit; the serialization unit is used to convert object data corresponding to a standard API into byte data that can be transmitted over the network, and the deserialization unit is used to restore the received byte data back to program object data.

[0044] After the standardizer generates object data corresponding to the standard API, the serialization unit reads this object data and, according to predetermined encoding rules, decomposes the fully encapsulated object data into continuous, transmittable byte data. The converted byte data is sent to the robot controller via the RPC communication link. Upon receiving the byte data, the corresponding deserialization unit receives the byte data from the network and restores it to the original object data according to the rules matching the serialization. The restored object data can be directly read, parsed, and used by the business logic module to execute the corresponding control logic. When the controller generates result data that needs to be sent back, the result object data is serialized again into byte data and sent back. The teaching terminal receives the data and completes the data restoration through deserialization.

[0045] By relying on the bidirectional format conversion function of serialization and deserialization, flexible conversion between local program object data and network transmission byte data is realized, solving the problem that complex structured data cannot be transmitted remotely across devices, ensuring the integrity and readability of standard APIs and feedback data during remote link transmission, effectively reducing the probability of cross-device data parsing anomalies, and further improving the reliability of remote data interaction of the entire control system.

[0046] In some implementations, the industrial robot teaching control system further includes an event feedback module, which is connected to the business logic module and the remote call module respectively, and uses a publish-subscribe architecture to transmit the running data from the robot controller to the teaching terminal. The event feedback module includes an event queue module and an event arbitration module. The event queue module is used to cache the running data according to the receiving order, and the event arbitration module is used to filter the data to be pushed to the teaching terminal from the cached running data according to a preset priority rule.

[0047] The business logic module inside the robot controller continuously generates various types of operational data during robot operation, and the generated operational data is sent to the event feedback module; the event queue module caches all the accessed operational data one by one according to the generation time of each data item; the event arbitration module periodically reads the data content cached in the event queue module, and filters and classifies all cached data according to preset priority rules, and determines the valid data that needs to be pushed out; the filtered data is transmitted to the corresponding teaching terminal according to the data type pre-subscribed by the teaching terminal based on the publish-subscribe architecture.

[0048] By adding an event feedback module and supporting it with queue caching, priority arbitration, and publish-subscribe distribution mechanisms, the orderly caching and hierarchical push of robot operation data can be achieved. This avoids massive amounts of useless data occupying communication resources and delays in critical status information. It saves link transmission bandwidth and ensures that high-priority data such as faults and alarms are delivered to operators first, thereby improving the efficiency of on-site fault handling and the rationality of data transmission in the entire control system.

[0049] like Figure 3 As shown, the API conversion module inside the teaching terminal generates standardized APIs and transmits them to the remote call module. Data is sent via the RPC client to the RPC server on the controller side in the form of action commands through the call channel. The RPC server forwards the received data to the remote call module inside the controller, and then sends it to the controller's API conversion module via the corresponding API declaration to drive the business execution unit to complete the robot control operation. Data feedback generated after the robot performs its operation is sent from the controller, transmitted back to the RPC client via the publish-subscribe channel, and finally flows back to the teaching terminal. The entire system relies on the RPC call channel and publish-subscribe dual channels to achieve bidirectional data interaction, enabling downlink control command transmission and uplink operation data feedback.

[0050] like Figure 4In the published-subscribe architecture shown, after the operator completes the custom settings of the arbitration mechanism through the human-machine interaction module, the relevant configuration instructions are transmitted to the robot controller via the remote call modules on both sides through the change mechanism API. After receiving the instructions, the controller completes the change of the arbitration mechanism in the event arbitration module. During the operation of the robot, the operation process data generated is first stored in the event queue module. The event arbitration module filters the data according to the configured arbitration rules and hands it over to the event push module. The filtered operation data is transmitted across devices through the remote call module on the controller side to the remote call module of the teaching terminal. Then, after the data format is standardized by the API standard data conversion module, it is sent to the data update notification module. Finally, the data update notification module pushes information to the human-machine interaction module to realize the interface notification display for the operator.

[0051] like Figure 5 The arbitration process of the event arbitration module shown first involves polling and retrieving various cached event data from the event queue, and then sending the retrieved events to the preprocessing module for pre-processing. Next, it determines whether a user-defined arbitration mechanism is configured. In the absence of a user-defined arbitration mechanism, the system uses the default arbitrator, dividing the event pool into three priority levels: P1 alarm events, P2 running events, and P3 other events. In the presence of a user-defined arbitration mechanism, the system uses the user-defined arbitrator, dividing the event pool into four priority levels: P1 alarm events, P2 running events, P3 external device data events, and P4 other events. After both arbitration paths complete the event priority classification, the system uniformly pushes the filtered events to the event push module according to the priority ranking rule from high to low. The event push module uses the API standardization module to convert the event data into a network-transmittable byte stream and sends it outwards. Finally, the teaching terminal device receives the corresponding byte stream data, and the data update notification module, based on pre-registered subscription relationships, displays the event content to the corresponding subscription interface.

[0052] The technical solution adopted in this embodiment involves a human-computer interaction module that collects operation commands, an API conversion module that uses a device capability abstraction layer to standardize commands of different formats, and a remote invocation module that sends standardized commands remotely to the business logic module and transmits the result data after command execution back to the human-computer interaction module. This improves the compatibility of multi-category teaching terminals, increases equipment utilization and on-site debugging efficiency, and, relying on a two-way data closed loop, allows staff to view operational information in real time, saving on equipment modification and software development costs.

[0053] According to embodiments of the present invention, a control method for an industrial robot teaching control system is also provided. See also... Figure 6 As shown, the control method may include steps S110 to S130.

[0054] In step S110, the operation commands output by different types of teaching terminals are collected.

[0055] In step S120, the operation instructions of different types of teaching terminals are standardized and uniformly converted through the API conversion module.

[0056] In step S130, the standardized and converted instructions are sent to the business logic module located in the robot controller, and the result data after the business logic module executes the instructions is received and the result data is transmitted to the teaching terminal.

[0057] Specifically, after the operator completes the operation input on different types of teaching terminals, the system first completes the collection of various operation instructions. The collected differentiated operation instructions are sent to the API conversion module. The API conversion module relies on the internal device capability abstraction layer to perform unified standardization conversion on all original instructions, transforming the messy private instructions into unified and standardized instructions. The standardized instructions are then remotely transmitted to the business logic module inside the robot controller via the remote call module. The business logic module parses the received standardized instructions and drives the industrial robot to perform the corresponding actions, while generating result data after the instructions are executed. The generated result data is then transmitted back via the remote call module and finally sent back to the teaching terminal to complete data reception.

[0058] In some implementations, the control method further includes: acquiring operational data from the robot controller side, and transmitting the operational data to the teaching terminal based on a publish-subscribe architecture after event arbitration filtering; wherein, the event arbitration filtering includes: polling the operational data cached in the event queue, filtering the data to be pushed according to a user-defined arbitration mechanism or a preset default priority rule, and after the filtered events are converted to a standardized format, pushing them to the human-computer interaction interface corresponding to the teaching terminal based on the subscription relationship.

[0059] Specifically, the robot controller continuously generates various operational data during operation and continuously acquires operational data summarized by the controller side. After the system polls and reads all operational data cached in the event queue, it first confirms whether the user-defined arbitration mechanism has been configured on-site. If the custom configuration has been completed, the system filters the data to be pushed according to the priority rules set by the user. If no custom configuration has been made, the system uses the built-in default priority rules to complete the data filtering. The filtered event data is processed through standardized format conversion and then, based on the pre-established subscription relationship, is pushed to the corresponding human-computer interaction interface of the teaching terminal for display according to the publish-subscribe architecture.

[0060] In some implementations, the control method further includes: transmitting instruction and result data via an RPC communication link in conjunction with an asynchronous processing mechanism and a disconnection reconnection mechanism; and translating the private instructions of the corresponding type of teaching terminal into a unified instruction format.

[0061] Private operation commands output by various teaching terminals are captured by corresponding device adapter subunits. The device adapter subunits translate the differentiated private commands into a unified command format common to the system according to preset mapping rules. After the format conversion is completed, the commands undergo subsequent standardization processing and are transmitted across devices via RPC communication links. An asynchronous processing mechanism controls the data transmission and reception logic. After the sending end issues a command, it can continue to receive new commands to be transmitted without pausing work due to waiting for remote feedback. If the communication link is accidentally disconnected during transmission, the disconnection and reconnection mechanism detects the fault in real time and automatically initiates a reconnection operation. After the link is restored, the delayed commands and feedback data are resent. The result feedback data returned by the robot controller is also sent back to the teaching terminal via the same RPC communication link.

[0062] The technical solution of this invention first collects operation commands issued by various teaching terminals, then standardizes these commands through an API conversion module, and finally remotely sends the standardized commands to the business logic module inside the controller. Finally, it receives the execution result data generated by the business logic module and sends it back to the teaching terminal. This breaks the limitation of different teaching terminals being exclusively bound to the controller, improves the compatibility and adaptability of multiple teaching device models, increases on-site debugging efficiency, and reduces equipment modification and program development costs through closed-loop data feedback.

[0063] According to an embodiment of the present invention, a storage medium corresponding to a control method for an industrial robot teaching control system is also provided. The storage medium includes a stored program, wherein the program, when running, controls the device where the storage medium is located to execute the control method for the industrial robot teaching control system described above.

[0064] Since the processing and functions implemented by the storage medium in this embodiment are basically the same as the embodiments, principles and examples of the aforementioned methods, any details not covered in this embodiment can be found in the relevant descriptions in the aforementioned embodiments, and will not be repeated here.

[0065] By employing the technical solution of this invention, the instructions generated by operators through various teaching terminals are uniformly collected, standardized in format by the API conversion module, and then remotely delivered to the controller's business logic module for execution. The resulting data is then fed back to the teaching terminal. This solves the problem of incompatibility between existing terminal instructions, improves the versatility of the control system, increases the utilization rate of various teaching devices, facilitates real-time viewing of operating results by maintenance personnel, and shortens the debugging period.

[0066] In summary, it is readily understood by those skilled in the art that, without conflict, the aforementioned advantageous methods can be freely combined and superimposed.

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

Claims

1. An industrial robot teaching control system, characterized in that, include: The human-computer interaction module, deployed on the teaching terminal, is used to collect terminal operation commands; The API conversion module is connected to the human-computer interaction module and is configured with a device capability abstraction layer. The device capability abstraction layer is used to uniformly and standardizedly convert the operation instructions of different types of teaching terminals. The remote invocation module is connected to the API conversion module and the business logic module located on the robot controller. It is used to send standardized converted instructions to the business logic module and to receive the result data after the business logic module executes the instructions and transmit it to the human-computer interaction module.

2. The industrial robot teaching control system according to claim 1, characterized in that, The device capability abstraction layer includes at least two device adaptation sub-units, each corresponding to a type of teaching terminal; the device adaptation sub-unit is used to translate the private instructions of the corresponding type of teaching terminal into a unified instruction format.

3. The industrial robot teaching control system according to claim 1, characterized in that, The remote call module is configured with an RPC communication link, which is equipped with an asynchronous processing mechanism and a disconnection reconnection mechanism.

4. The industrial robot teaching control system according to claim 1, characterized in that, The API conversion module includes an instruction receiver, an instruction parser, and a standardizer; the instruction receiver is used to receive the original operation instruction; the instruction parser is used to split the original instruction; and the standardizer is used to generate a standard API according to a preset specification based on the information after splitting the original instruction and store it in the API pool.

5. The industrial robot teaching control system according to claim 4, characterized in that, The standardizer is equipped with a serialization unit and a deserialization unit; the serialization unit is used to convert object data corresponding to the standard API into byte data that can be transmitted over the network, and the deserialization unit is used to restore the received byte data into program object data.

6. The industrial robot teaching control system according to any one of claims 1 to 5, characterized in that, The industrial robot teaching control system also includes an event feedback module, which is connected to the business logic module and the remote call module respectively, and uses a publish-subscribe architecture to transmit the running data from the robot controller to the teaching terminal. The event feedback module includes an event queue module and an event arbitration module. The event queue module is used to cache the running data according to the receiving order, and the event arbitration module is used to filter the data to be pushed to the teaching terminal from the cached running data according to a preset priority rule.

7. A control method for an industrial robot teaching control system, characterized in that, The control method, applied to the industrial robot teaching control system as described in any one of claims 1-6, comprises: Collect operation commands output from different types of teaching terminals; The API conversion module standardizes and converts the operation commands of different types of teaching terminals. The standardized and converted instructions are sent to the business logic module located in the robot controller, and the result data after the business logic module executes the instructions is received and transmitted to the teaching terminal.

8. The control method for the industrial robot teaching control system according to claim 7, characterized in that, The control method further includes: The system acquires operational data from the robot controller, filters it through event arbitration, and then transmits the operational data to the teaching terminal based on a publish-subscribe architecture. The event arbitration filtering includes: polling the running data cached in the event queue, filtering the data to be pushed according to the user-defined arbitration mechanism or the preset default priority rules, and after the filtered events are converted into a standardized format, they are pushed to the human-computer interaction interface corresponding to the teaching terminal based on the subscription relationship.

9. The control method for the industrial robot teaching control system according to claim 7, characterized in that, The control method further includes: The system transmits instructions and results data via an RPC communication link in conjunction with an asynchronous processing mechanism and a disconnection and reconnection mechanism; and translates the private instructions of the corresponding type of teaching terminal into a unified instruction format.

10. A storage medium, characterized in that, The storage medium includes a stored program, wherein, when the program is executed, the device containing the storage medium is controlled to perform the control method of any one of claims 7 to 9 for the industrial robot teaching control system.

Images