Safety functions in industrial robots

Abstract

The present invention relates to a method (200) for controlling an industrial robot (100), the industrial robot (100) including a robot controller (no), a programming interface (120) separate from the robot controller (no), and a robot manipulator (130) having a plurality of actuators (131). The method (200) includes: receiving (211) a first release signal (U1) via a first safety input device (121); receiving (212) actuator selection data (V) indicating one or more actuators (131) at a programming interface (120) via an arbitrary input device (123); after receiving (212) the actuator selection data (V), receiving (213) a second release signal (U2) at the programming interface (120) via a second safety input device (122); and in response to determining (214) that the first release signal (U1) and the second release signal (U2) are still received, causing (215) the actuator indicated by the actuator selection data (V) to enter a non-drive power movement mode.

Description

Technical Field

[0001] This disclosure relates to the field of safety functions applicable to industrial robots, and specifically to a method for activating a non-driven dynamic motion (MwoDP) mode. Background Technology

[0002] ISO 10218-1 (Robots and robotic equipment—Safety requirements for industrial robots—Part 1: Robots) specifies the requirements and guidelines for the inherent safety design, protective measures, and usage information of industrial robots. It describes the basic hazards associated with robots and provides requirements for eliminating or adequately reducing the risks associated with these hazards. In particular, robots conforming to ISO 10218-1 should be designed to move their axes without driving power in emergency or abnormal situations. This mobility without driving power may also be useful in maintenance or repair environments. Where feasible, the movement of the axis should be performed by one person. Controls should be easily accessible but should prevent accidental operation. Relevant instructions should be included in the usage information, along with recommendations for training personnel to handle emergency or abnormal situations.

[0003] If the operator interacts with the connected teach pendant in the following manner, the brake release function of existing products on the market will be activated:

[0004] 1. The mode switch is set to manual mode.

[0005] 2. The teaching button was pressed.

[0006] 3. The enable switch is pressed.

[0007] 4. The warning button was pressed.

[0008] The product is configured such that, upon completion of the interaction sequence, the brake of a particular robot joint is released whenever the selection button associated with that joint is pressed. The selection button is part of the graphical user interface (GUI) displayed on the teach pendant. Because pressing the selection button is sufficient to release the brake starting from step 4, it is advisable for a second operator to support the robot manipulator or be prepared to grasp it. This precaution is reasonable, as a free-falling manipulator could severely impact people and objects, or the manipulator itself could suffer structural damage.

[0009] The fact that the graphical user interface operates using at least some uncertified hardware and software means that the risk of erroneous signals triggering the brake release function cannot be ignored. Erroneous signals could be caused by operator error, electromagnetic interference, and other hardware defects or programming negligence. Furthermore, the buttons associated with the connector are mechanical components, which themselves constitute a significant source of error. It is advisable to improve the product design to reduce the impact of this situation. Summary of the Invention

[0010] One objective of this disclosure is to provide a method for controlling an industrial robot such that it enters MwoDP mode only in response to a safety-generated signal. Another objective is to make this method more robust to unintentional activation by a human operator. A further objective is to achieve the sought improvements without increasing the number of safety signals or safety signal input devices in the robot system. A further objective is to propose a method suitable for integration into existing installations (retrofits). A further objective is to improve safety without sacrificing usability, specialization, or operator convenience. A further objective is to provide a programming interface for the industrial robot that adapts to the MwoDP mode for safe robot activation.

[0011] The invention, as defined by the independent claims, achieves at least some of these objectives. The dependent claims refer to advantageous embodiments of the invention.

[0012] In a first aspect of the invention, a method for controlling an industrial robot is provided. It is understood that the industrial robot includes at least a robot controller, a programming interface (or teach pendant) separate from the robot controller, and a robot manipulator having multiple actuators. The method includes: receiving a first release signal via a first safety input device; receiving actuator selection data indicating one or more actuators via any input device on the programming interface; after receiving the actuator selection data, receiving a second release signal via a second safety input device on the programming interface; and, in response to determining that both the first and second release signals are still received, causing the actuator indicated by the actuator selection data to enter an MwoDP mode.

[0013] In the method according to the first aspect of the invention, MwoDP mode is entered in response to receiving a signal via a safety input device. This method differs from the interaction sequence in the prior art described above, which has a state in which the brake release function can be automatically activated by the unsafe selector button. The method according to the first aspect also uses any input device (particularly cost-effectively as a non-safe input device), but in a different order, and therefore is safer than prior art in this respect.

[0014] It is important to note that this invention achieves improved security without increasing the number of signals requiring "safety" (see below). Specifically, actuator selection data is received via any input method, without requiring specific safety classifications, such as an interactive graphical user interface displayed on a screen. In this way, the operator can benefit from a complex and easily updated interface to input actuator selection data, which typically contains information relatively more complex than the release signal. In contrast, release signals can represent Boolean variables (although they may be transmitted in longer code form for technical reasons). The risk of receiving erroneous actuator selection data via the sieve becomes acceptable because the execution of the actuator selection data will not be performed without a second release signal. In some embodiments, this risk is further mitigated by configuring the screen to display a user interface related to functions outside of the MwoDP mode, so that any errors can be detected early and outside of the safety-critical context.

[0015] In some embodiments, an additional timeout condition is applied, requiring the second release signal to be received within a predefined timeout period. Therefore, if the timeout period is exceeded, the determination will be negative even if the first and second release signals are received simultaneously at a later time. These embodiments may be less sensitive to unintentional activation due to operator negligence.

[0016] In some embodiments, when the graphical user interface is displayed on the screen, or when a user accesses the graphical user interface, or in both states, a visual indicator associated with the robotic manipulator (e.g., illuminating a lighting element on the robotic manipulator) is displayed. The visual indicator alerts nearby people that the robot may soon enter MwoDP mode, which could pose the dangers mentioned above.

[0017] Some embodiments involve providing an optional input port separate from the programming interface. This facilitates integration with existing robotic systems. In these embodiments, the method further includes receiving static actuator selection data via pre-programming. Then, to determine that a first release signal is still received, and a second release signal is received via an alternative input port, the actuator indicated by the static actuator selection data is brought into MwoDP mode. Some embodiments of these embodiments can be combined with modified variations of the display of the aforementioned visual indicator.

[0018] In a further embodiment, which can be freely combined with all the above embodiments, a secure communication protocol is used to transmit commands from the programming interface to the robot controller, causing the indicated actuator to enter MwoDP mode.

[0019] In a second aspect of the invention, a programming interface for an industrial robot, a robot controller at least separate from the programming interface, and a robot manipulator having a plurality of actuators are provided. The programming interface includes: a first safety input device and a second safety input device, an arbitrary input device, a control interface adapted to communicate with the robot controller, and processing circuitry configured to execute the method according to the first aspect of the invention.

[0020] The programming interface generally shares the intended effects and advantages with the first aspect of the invention, and can be reflected through corresponding degree of technical changes.

[0021] This invention also relates to a computer program containing instructions for causing a computer, or particularly a programming interface, to perform the methods described above. The computer program can be stored or distributed on a data carrier. As used herein, "data carrier" can be a transient data carrier, such as modulated electromagnetic waves or light waves, or a non-transient data carrier. Non-transient data carriers include volatile and non-volatile memories, such as permanent and non-permanent storage media of magnetic, optical, or solid-state types. Such memories still fall within the scope of "data carriers" and can be permanently mounted or portable.

[0022] In the terminology of this disclosure, a "secure" input device is an input device designed according to trusted security protocols and / or through dedicated security verification procedures. "Insecure input methods" include not only input methods known to fail to meet these requirements, but also input methods with currently unknown security-related properties. In fact, according to widely accepted risk assessment methodologies, devices with unknown security-related properties should be considered unsecured devices.

[0023] Generally, all terms used in the claims should be interpreted according to their ordinary meaning in the technical field, unless otherwise expressly defined herein. Unless otherwise expressly stated, all references to "element, device, component, apparatus, step, etc." should be interpreted as referring to at least one instance of an element, device, component, apparatus, step, etc. Unless expressly stated otherwise, the steps of any method disclosed herein need not be performed in the exact order described. Attached Figure Description

[0024] Now, by way of example, aspects and embodiments are described with reference to the accompanying drawings, in which:

[0025] Figure 1 An industrial robot with a connected programming interface is shown.

[0026] Figure 2 This is a flowchart of a method for controlling an industrial robot according to embodiments of this document;

[0027] Figure 3It is a timing diagram of a secure communication protocol; and

[0028] Figure 4 This is the front view of the example programming interface. Detailed Implementation

[0029] Various aspects of this disclosure will now be described more fully with reference to the accompanying drawings, which illustrate certain embodiments of the invention. However, these aspects may be embodied in many different forms and should not be construed as limiting; rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and will fully convey the scope of all aspects of the invention to those skilled in the art. Throughout the description, similar numerals refer to similar elements.

[0030] Figure 1 An industrial robot 100 is shown, comprising the following components: a robot controller 110, a programming interface (or teach pendant) 120, and a robot manipulator (or robot arm) 130. For reasons explained below, the programming interface 120 can be considered a non-permanent component of the industrial robot 100.

[0031] The robot controller 110 is configured to provide control signals to the actuators 131 in the robot manipulator 130 and monitor sensor signals from sensors (not shown) in the robot manipulator 130. These control signals and sensor signals can be exchanged via a wired or wireless interface. The robot manipulator 130 can be configured to execute signals from at most one designated robot controller 110 at any given time. Alternatively, the robot manipulator 130 can be configured to share sensor signals only with a designated robot controller 110. Furthermore, the robot controller 110 can be configured to control a single robot manipulator 130 at a time, where the robot controller and robot manipulator can be considered to have a one-to-one relationship. The robot controller 110 includes at least processing circuitry 111 and memory 112. Figure 1 The robot controller 110 has an optional input port 140 for connecting to an input device 141. The spare input port 140 may be a general-purpose data port, the proposed use of which will be described later. In some embodiments, the processing circuitry 111, memory 112, and spare input port 140, some or all of which may be active during the execution of method 200, may belong to a so-called safety controller within the robot controller 110.

[0032] Figure 1The illustrated robot manipulator 130 constitutes a fixed robotic device, although in other embodiments it can be a mobile robot. For example, the robot manipulator 130 can be a lightweight manipulator with a lifting capacity of up to 20 kg, such as up to 10 kg, such as up to 5 kg. Specifically, the robot manipulator 130 can belong to a collaborative robot 100 suitable for working in conjunction with one or more operators. Figure 1 In the illustrated embodiment, the robot manipulator 130 includes a base from which multiple components connected by rotational or linear joints extend, and is configured to carry a tool (or, in other words, an end effector) at its distal end. Actuators 131 for applying acceleration or deceleration torque and force are disposed in the robot manipulator 130. At least some of the actuators 131 include a drive unit 131.1 and a braking unit 131.2. The drive unit 131.1 may be, for example, electric, hydraulic, or pneumatic. The braking unit 131.2 may include a moving component powered in the same manner, configured to generate braking force by magnetic, frictional, or mold-locking action. The braking unit 131.2 is configured to engage, while the drive unit 131.1 is inactive, except when the robot 100 is in a non-driven motion (MwoDP) mode. The braking unit 131.2 is configured to have this behavior by incorporating physical or mechanical devices (e.g., a spring-loaded mechanism released by the movement of the drive unit 131.1), a suitably programmed embedded controller, firmware, or other suitable logic. Understandably, the corresponding behavior—actuator 131 "freezing" during inactivation—can be readily achieved by applying structural and functional solutions within the common sense of those skilled in the art, even without the structure of the illustrated drive unit 131.1 and brake unit 131.2 in actuator 131. Such solutions are found in many industrial robots on the market.

[0033] like Figure 1 The illustrated robotic manipulator 130 is also equipped with a visual indicator 132, such as an indicator light or a sign with a variable appearance. The indicator light or sign can be positioned in an easily visible location, such as near the end effector. In other embodiments, the robotic manipulator 130 may be associated with the visual indicator 132 in other ways; for example, the visual indicator 132 may be mounted or suspended near the robotic manipulator 130, where it is visible to the operator and any bystander. Further optionally, the visual indicator 132 may be labeled with the name or other identifier of the robotic manipulator 130.

[0034] The programming interface 120 includes various input devices 121 and 122, a screen 124, and processing circuitry 125. Input devices 121 and 122 may include keys, keyboards, touchpads, scroll wheels, joysticks, or switches (selectors) with two or more positions. It should be noted that the screen 124 and some input devices 121 and 122 may be positioned on opposite sides of the programming interface 120. Figure 1 In this design, the first input device, 121, is a latching button configured to remain active (i.e., pressed) after the operator releases it; the button can be returned to its inactive position by a latch release operation, such as rotating the button around its axis. This type of button is commonly used as an industrial emergency stop (ESTOP) button. Furthermore, in... Figure 1 In this input device, the second 122 is a three-position safety switch (also known as a three-level enable switch) comprising a spring-loaded knob or lever that can be linearly moved by hand between two inactive positions, defining an active position between the two inactive positions. This three-position safety switch is considered very robust against unintentional manual activation because the knob will be pushed into (or returned to) the end position unless the operator applies the correct force. The three-position safety switch 122 may be located on the back of the handheld programming interface 120.

[0035] Screen 124 is adapted to display a graphical user interface 123. The graphical user interface 123 can accept input via input devices 121, 122, or, in embodiments where screen 124 is touch-sensitive, directly via screen 124. The output of the graphical user interface 123 may include images, text characters, symbols, and other graphical elements. An example of a handheld programming interface 120 manufactured by the applicant is shown below. Figure 4 As shown.

[0036] like Figure 1 As shown, the programming interface 120 is detachable from at least one component of the industrial robot 100, meaning that the programming interface 120 is suitable for manual and / or non-destructive separation from the robot controller 110, robot manipulator 130, or another component after use. During use, the programming interface 120 can be connected, for example, to a connection point on the robot controller 110 to establish a wired or wireless connection. Figure 1 As shown, the connection cable 126 from the programming interface 120 is connected to a corresponding connection cable from the robot controller 110 via a releasable plug and socket combination. This detachability allows one programming interface 120 to be used to train a large number of industrial robots 100. In other words, there is no one-to-one relationship between the robot manipulator 130 and the programming interface 120. In some embodiments, the robot 100 is configured such that programming or training is impossible unless the programming interface 120 is connected to the robot 100.

[0037] Typically, the programming interface 120 is configured to be used as a tool during the training phase, during which the operator can generate executable robot instructions. Robot instructions can be generated by the programming interface 120 or the robot controller 110 based on input data received from the operator in non-text form and stored in memory 112. The robot instructions in memory 112 can be retrieved after the training phase ends (e.g., during production) and executed by the robot controller 110 and the robot manipulator 130. Non-text input data can be provided via pass-through programming or manual jogging, during which the robot manipulator's 130 movements are sensed and recorded. The programming interface 120 can be configured to accept commands indicating the start and end of a training phase, commands to start and end a recording session, commands for managing records (delete, save, trim, edit, etc.), and commands to supplement the movements of the robot manipulator 130 in various ways (e.g., activating / deactivating tools, assigning speed and other attributes to movement paths). The programming interface 120 can be further configured to deliver visual, acoustic, or tactile information relating to programming feedback, general diagnostics, and various non-visual internal states of the robot 100.

[0038] Now refer to Figure 2 A method 200 for controlling an industrial robot 100 of the aforementioned type will now be proposed. Method 200 is generally executed by the industrial robot 100. Specifically, it can be executed by individually processing circuit 111 in the robot controller 110, individually processing circuit 125 in the programming interface 120, or by a combination of these. Furthermore, method 200 can be implemented as instructions forming a computer program, which can be executed by a general-purpose computer with the required signal input and signal output capabilities, or by the robot controller 110 or the programming interface 120. The inventors envision method 200 as a safer method for entering MwoDP mode for the industrial robot 100 than currently available technology allows. It should be understood that no other means of entering MwoDP mode should be provided for the operator of the industrial robot 100.

[0039] The execution of method 200 starts from Figure 2 The process begins at point 210. In the first step 211, a first release signal U1 is received via a first security input device. In an embodiment where method 200 is implemented in robot controller 110, the first release signal U1 is received in robot controller 110 even if the first security input device may be located elsewhere, such as in programming interface 120. The first release signal U1 may represent a change in an analog or digital channel value; alternatively, the first release signal U1 may represent a code transmitted via a wired or wireless carrier or medium.

[0040] To recap, the intended meaning of a “safe” input method—whether implemented solely in hardware, solely in software, or a combination of both—has been explained in the previous section of this disclosure. To conform to this definition, a “safe” input, for example, might mean a safety-certified device, that is, a certified ISO 13849-1 standard (Safety of machinery—Safety of partial control systems—Part 1: General principles of design), an IEC 61508 standard (Functionally safe electrical / electronic / programmable electronic safety-related systems), or an application-specific standard such as ISO 26262, IEC 61511, IEC 62061, IEC 62279, etc. In particular, a “safe” input method may have been found to conform to one of the safety integrity levels specified in these references. Another specific example is that a “safe” input device might conform to performance level (PL)d of category 3 in ISO 13849-1.

[0041] The first safety input device used in the first step 211 can be located on or separate from the programming interface 120. The first safety input method can be one of the input methods on the programming interface 120. In particular, the first input device can be an emergency stop button 121 with latching, which allows the first release signal U1 to be conveniently maintained during subsequent steps of method 200. A similar emergency stop button can also be provided near the robot manipulator 130.

[0042] In the second step 212 of method 200, actuator selection data V is received via any input device on programming interface 120. Actuator selection data V represents one or more of actuators 131, i.e., actuators that will later cause them to enter MwoDP mode. Actuator selection data V may be formatted as a bit string, where each position corresponds to one of the selectable actuators 131.

[0043] Recall that any input device can be implemented as a "safe" input device or as a non-safe input device. Choosing a non-safe input method as an arbitrary input method is more economically attractive. However, using a "safe" input device does not deprive method 200 of any effect or benefit—on the contrary, the level of safety is slightly enhanced—but may be an unnecessarily expensive choice. An arbitrary input method may include a graphical user interface displayed on the screen 124 of the programming interface 120. For example, a visual representation of the actuators 131 located approximately in their position relative to the robot manipulator 130 can be displayed to the operator, and they can be selected and deselected via touch commands or other forms of input.

[0044] Screen 124 may optionally be used to display a (graphical) user interface related to functions other than the MwoDP mode. For example, these functions may include those related to the teaching phase described above, including commands indicating the start and end of the training phase, commands to start and end a recording session, commands for managing recordings, and commands to supplement the robot manipulator 130 movements in various ways. The functions related to the teaching phase and those related to the MwoDP mode may be provided as two menus or submenus within a general graphical user interface. Under this option, since screen 124 is used for MwoDP functions, any errors affecting screen 124 may be detected earlier, thus making the risk of receiving incorrect actuator selection data via screen 124 more acceptable.

[0045] In the third step 213 of method 200, the second release signal U2 is received via a second safety input device. Similarly, the second safety input device can be located in a different unit (e.g., programming interface 120) than the unit receiving the second release signal U2 (e.g., robot controller 110). Like the first release signal U1, the second release signal U2 can represent a change in value or be transmitted via a pre-agreed code or symbol. This second safety input method is "safe" in the aforementioned sense. The second safety input device is preferably unlocked, meaning that it returns to an inactive position once the operator releases it. Specifically, the three-position safety switch 122 on the programming interface 120 can be the second safety input device. If the second safety input device is a graphical element displayed on a safety touchscreen previously used for another purpose (e.g., inputting actuator selection data V), it is preferable to display the element in a different location than other graphical elements previously used for said other purpose. This will require the operator to move their finger to activate the second safety input device, thereby reducing the risk of unintentional activation.

[0046] In step 214 of method 200, it is evaluated whether the first release signal U1 and the second release signal U2 are being received. If this is found to be true ( Figure 2 In the fifth step 215 of method 200 (the Y branch of the middle frame 214), the actuator 131 indicated by actuator selection data V enters the MwoDP mode. At the level of an actuator 131 including a drive device 131.1 and a braking device 131.2, wherein the braking device 131.2 is engaged by default in certain circumstances, entering the MwoDP mode may include releasing the braking device 131.2.

[0047] If the standard evaluation is false (N branch of box 214), then in step 6 216, it is ensured that actuator 131 is not in MwoDP mode. To do this, more precisely, the state of actuator 131 can be retrieved, and if actuator 131 is in MwoDP mode, actuator 131 is made to leave MwoDP mode; if they are not in MwoDP, no action is taken.

[0048] In some embodiments, the fourth step 214 includes an additional timeout condition, namely, the second release signal must be received within a predetermined timeout period T0. If the timeout period T0 is exceeded, the result of step 214 will be negative, even if the first release signal U1 and the second release signal U2 are received simultaneously at a later time. The predefined timeout period can be, for example, on the order of tens of seconds, such as 30 seconds. If the second release signal U2 arrives later than this time, it may be due to unintentional activation, such as when the programming interface 120 is carried in the operator's pocket.

[0049] In some embodiments, the execution flow of method 200 loops back from the fifth step 215 to the fourth step 214, such as... Figure 2 As shown. The loop returning to step 4 214 can optionally be configured to occur after a predetermined delay T > 0. This achieves the behavior of the indicated actuator 131 remaining in MwoDP mode for the time during which the operator generates the second release signal U2, with a granularity of T.

[0050] In some embodiments of method 200, the observer and operator are aware that MwoDP mode is about to be entered. More specifically, when the graphical user interface is displayed on screen 124 and / or the user accesses the graphical user interface, a visual indicator associated with the robot manipulator 130 is displayed. Displaying the visual indicator may include illuminating... Figure 1 The lamp shown is 132.

[0051] As described above, the programming interface 120 can be detached from the components of the industrial robot 100 to allow it to be moved and used to train other robots 100 at the same or different work locations. Effectively, especially in large deployments, the programming interface 120 can be present at a given robot 100 for a relatively short total time. If the ability to use the MwoDP mode more frequently is deemed important, then according to the embodiments described below, method 200 can be extended with some additional steps to allow entry into MwoDP mode even when the programming interface 120 is unavailable.

[0052] To implement the alternative method for entering the MwoDP mode according to this embodiment, the industrial robot 100 and static actuator selection data V' (step 217) are pre-programmed and further configured to evaluate the conditions for triggering the MwoDP mode (step 218). The static actuator selection data V' is similar to the actuator selection data V, indicating that one or more actuators 131 will enter the MwoDP mode when the conditions are found to be true. The pre-programming step 217 of receiving the static actuator selection data V' typically occurs before receiving the first release signal U1. The conditions are whether the first release signal U1 is still received and whether the second release signal U2 is received through a backup input port separate from the programming interface 120. The backup input port can be the aforementioned backup input port 140 on the robot controller 110, to which the input device 141 can be connected. The backup input port 140 can be a general-purpose input port that can be designated in the system configuration of the robot controller 110 for over-control purposes, i.e., for receiving the second release signal U2 at input port 140. The input device 141 connected thereto is preferably a "safe" input device in the aforementioned sense, such as a safety-certified three-position safety switch, a safety-certified non-locking ESTOP button, etc. Input device 141 can be shared with another industrial robot (e.g., it can be contained in a detachable unit dedicated to MwoDP operation), or input device 141 can be adapted to a single industrial robot 100. A spare input port 140 can optionally be implemented as a safety input port. The first release signal U1 is preferably received via a first safety input device (e.g., an ESTOP button) separate from the programming interface 120.

[0053] If the condition evaluates to true (Y branch of block 218), then actuator 131, indicated by static actuator selection data V', enters MwoDP mode (step 215'). Functionally, in this embodiment, static actuator selection data V' replaces actuator selection data V. Otherwise, if the condition evaluates to false ("No" branch of block 218), then it is verified that actuator 131 is not in MwoDP mode (step 216'). Steps 215' and 216' can be implemented in various ways as described above for steps 215 and 216, including cyclic behavior.

[0054] Optionally, to prevent unintentional entry into MwoDP mode in an alternative manner, the actuator 131's entry into MwoDP mode is delayed for a predefined delay period; if neither of the two release signals U1, U2 is received at the end of the delay period, the actuator will not enter MwoDP mode. This embodiment may include using a visual indicator to warn the operator and any bystanders, similar to the above. However, since the actuator selection data is static, the operator will not use any graphical user interface, which could be used to trigger the visual indicator. Instead, the visual indicator 132 associated with the robot manipulator 130 is displayed for the duration of the delay period during which the actuator 131's entry into MwoDP mode is delayed.

[0055] In a further variation of this embodiment with static actuator selection data V', the conditions evaluated in step 218 constitute the only way to enter the MwoDP mode. That is, method 200 includes steps 211 (where the first safety input device is not provided in programming interface 120), steps 217, steps 218, and conditional steps 215' and 216'. According to this embodiment, method 200 can be executed by an industrial robot 100 that is not currently connected to programming interface 120. In particular, method 200 can be implemented in the robot controller 110 of industrial robot 100.

[0056] Method 200 according to any of the above embodiments can improve the reliability of the communication link between the programming interface 120 and the robot controller 110. Note the manner in which actuator selection data V (or static actuator selection data V') is transmitted to the robot controller 110. More precisely, the actuator selection data V is transmitted from the programming interface 120 to the robot controller 110 using a secure communication protocol. The secure communication protocol can be understood as a protocol that sufficiently protects the integrity of the data transmitted along the communication path between the programming interface 120 and the robot controller 110.

[0057] Figure 3 The sequence diagram illustrates an exemplary secure communication protocol relating to an embodiment of method 200 implemented in robot controller 110. The sequence diagram illustrates the signals and data exchanged between a first secure input device 121, a second secure input device 122, a graphical user interface 123 on screen 124 of programming interface 120 (as an example of a non-secure input device), programming interface 120 (e.g., processing circuitry 125 therein), robot controller 110, and actuator 131 indicated by actuator selection data V. Signals and data are indicated by arrows. Figure 3 The downward direction in the text indicates the rise time.

[0058] like Figure 3As shown, after the robot controller 110 receives the first release signal U1, the operator continues to input actuator selection data V using the programming interface 120. After the programming interface 120 has captured the actuator selection data V, it transmits a code (e.g., a binary number) W to the robot controller 110, from which the actuator selection data V can be decoded. Preferably, the code W is long enough that the mixing of other artifact waveforms that interfere with and affect the communication path from the programming interface 120 to the robot controller 110 has a controlled and very low probability. In response, the robot controller 110 sends the checksum or check value CRC(W) of the code W. The robot controller 110 can be configured to calculate the checksum using a one-way function suitable for Cyclic Redundancy Check (CRC). Many one-way functions for this purpose have been described in the literature; one example is CRC32, for which software implementations can be retrieved from the website sourceforge.net / projects / crccalculator / files / CRC / . Figure 3 If the programming interface 120 can reproduce and thereby verify the checksum CRC(W) calculated by the robot controller 110, then the programming interface 120 calculates the checksum of the checksum CRC(W) and transmits it to the robot controller 110. Optionally, as Figure 3 As shown, the transmission of the checksum of the cyclic redundancy check (CRC(W)) can be conditional upon a second release signal U2, which can be eavesdropped on by the programming interface 120, although the second release signal U2 is actually designated to the robot controller 110 executing method 200. In turn, the robot controller 110 attempts to verify the received checksum cyclic redundancy check (CRC(W)) by recalculating it based on the previously calculated checksum cyclic redundancy check (CRC(W)). If the robot controller 110 has received the second release signal U2 and the verification is successful ( Figure 2 In sub-step 215.1), the robot controller 110 sends a control signal M to the actuators 131 in the robot manipulator 130, commanding them to enter MwoDP mode. Conversely, if the programming interface 120 cannot reproduce the check and cyclic redundancy check (W), the protocol terminates, and MwoDP mode will not be triggered due to the lack of actuator selection data v.

[0059] Various aspects of this disclosure have been described above primarily with reference to several embodiments. However, as will be readily understood by those skilled in the art, other embodiments besides those disclosed above are also possible within the scope of the invention as defined by the appended claims.

Claims

1. A method (200) for controlling an industrial robot (100), The industrial robot (100) includes a robot controller (110), a programming interface (120) separate from the robot controller (110), and a robot manipulator (130) with multiple actuators (131). The method (200) includes: Receive the first release signal (U1) via the first security input device (121); At the programming interface (120), actuator selection data (V) indicating one or more of the actuators (131) is received via any input device; After receiving the actuator selection data (V), a second release signal (U2) is received at the programming interface (120) via the second safety input device (122); as well as In response to determining that the first release signal (U1) and the second release signal (U2) are still being received, the actuator, as indicated by the actuator selection data (V), enters a non-driven motion mode.

2. The method (200) according to claim 1, further comprising: In response to determining that the first release signal (U1) and / or the second release signal (U2) are no longer being received, the indicated actuator is disengaged from the unpowered motion mode.

3. The method (200) according to claim 1 or 2, wherein the determination of the first release signal (U1) and the second release signal (U2) includes verifying a timeout condition by which the second release signal (U2) needs to be received within a predefined timeout period.

4. The method (200) according to claim 1 or 2, wherein the first security input device is arranged at the programming interface (120).

5. The method (200) according to claim 1 or 2, wherein the first safety input device is an emergency stop button with latching.

6. The method (200) according to claim 1 or 2, wherein the second safety input device (122) is a three-position safety switch.

7. The method (200) according to claim 1 or 2, wherein the programming interface (120) is a teach pendant.

8. The method (200) according to claim 1 or 2, wherein the programming interface (120) is detachable from at least one component of the industrial robot (100).

9. The method (200) according to claim 1 or 2, wherein the arbitrary input device is a graphical user interface displayed on a screen (124) of the programming interface (120).

10. The method (200) according to claim 9, further comprising: When the graphical user interface is displayed on the screen (124) and / or when the graphical user interface is accessed by a user, a visual indicator (132) associated with the robot manipulator (130) is displayed.

11. The method (200) of claim 9, wherein the screen (124) is further configured to display a user interface relating to functions other than the unpowered motion mode.

12. The method (200) according to claim 1 or 2, wherein: Each actuator (131) includes a drive unit (131.1) and a braking unit (131.2); and When the drive unit is not activated, the braking device (131.2) is configured to engage except in the non-drive-powered motion mode.

13. The method (200) according to claim 1 or 2, further comprising: Static actuator selection data (V') is received through pre-programming; as well as In response to determining that the first release signal (U1) is still received and the second release signal (U2) is received via a spare input port (140) separate from the programming interface (120), the actuator indicated by the static actuator selection data (V') is caused to enter the non-driven motion mode.

14. The method (200) according to claim 13, wherein the spare input port (140) is connected to an input device (141) that is not shared with any other industrial robot.

15. The method (200) according to claim 13, further comprising: The actuator is delayed for a predefined time period before entering the non-drive-powered motion mode.

16. The method (200) according to claim 15, further comprising: During the delay period, a visual indicator (132) associated with the robot manipulator (130) is displayed.

17. The method (200) according to claim 1 or 2, further comprising receiving the actuator selection data (V) from the programming interface (120) at the robot controller (110) using a secure communication protocol.

18. A robot controller (110) for use in an industrial robot (100), the industrial robot (100) including a programming interface (120) separate from the robot controller (110) and a robot manipulator (130) having a plurality of actuators (131), wherein: The robot controller (110) is communicatively connected to a first secure input device (121), a second secure input device (122), and any input device; and The robot controller (110) includes a processing circuitry system configured to perform the method (200) of any one of the preceding claims.

19. A computer program comprising instructions that cause a robot controller (110) according to claim 18 to perform the steps of the method according to any one of claims 1 to 17.

Images