Safety function in industrial robot

Abstract

The invention relates to a method (200) for controlling an industrial robot (100) comprising 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) comprises: receiving (211) a first release signal (U1) via a first secure input device (121); receiving (212), at the programming interface (120) via any input device (123), actuator selection data (V) indicative of one or more of the actuators (131); receiving (213) a second release signal (U2) via a second safety input device (122) at the programming interface (120) after the actuator selection data (V) has been received (212); 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 driveless motion mode.

Description

Technical Field

[0001] The present disclosure relates to the field of safety functions applicable to industrial robots and in particular to a method of activating a driver-less powered motion (MwoDP) mode. Background Art

[0002] The ISO 10218-1 standard (Robots and robotic equipment — Safety requirements for industrial robots — Part 1: Robots) specifies requirements and guidance for the inherently safe design, protective measures and information for use of industrial robots. It describes the basic hazards associated with robots and provides requirements to eliminate or adequately reduce the risks associated with these hazards. In particular, robots complying with the ISO 10218-1 standard should be designed to be able to move the axes without drive power in emergency or abnormal situations. This mobility without drive power may also be useful in maintenance or repair environments. Where practicable, moving the axes should be done by one person. Controls should be easily accessible but should be prevented from being accidentally operated. Relevant instructions should be included in the information for use, along with recommendations for training personnel to deal with emergency or abnormal situations.

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

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

[0005] 2. The teach button is pressed.

[0006] 3. The enabling switch is pressed.

[0007] 4. The warning button is pressed.

[0008] The product is configured so that, after this interaction sequence is completed, the brakes of a specific robot joint are released as soon as the selection button associated with this robot joint is pressed. The selection button belongs to the graphical user interface (GUI) displayed on the teach pendant. Since, from step 4 onwards, pressing the selection button is sufficient to release the brakes, it is best for a second operator to support the robot manipulator or be ready to grab it. This precaution is justified because a freely falling manipulator could severely impact persons and objects, or the manipulator itself could suffer structural damage.

[0009] The fact that the graphical user interface runs using hardware and software that are at least partially not safety certified also means that the risk of false signals triggering the brake release function cannot be ignored. False signals can be caused by operator errors during runtime, electromagnetic interference and other hardware defects or programming oversights. In addition, the buttons associated with the connectors are mechanical parts, which themselves constitute a significant error source. It is advisable to improve the product design to reduce the impact of this situation. Summary of the invention

[0010] It is an object of the present disclosure to provide a method of controlling an industrial robot so that it enters an MwoDP mode only in response to a safety generated signal. Another object is to make such a method more robust against unintentional activation by a human operator. A further object is to achieve the sought improvement without increasing the number of safety signals or the safety signal input devices in the robot system. A further object is to propose a method suitable for integration into existing installations (retrofits). A further object is to improve safety without sacrificing usability, application specificity or operator convenience. A further object is to provide a programming interface for an industrial robot adapted to safely activate the robot's MwoDP mode.

[0011] At least some of these objects are achieved by the invention defined in the independent claims. The dependent claims are directed to advantageous embodiments of the invention.

[0012] In a first aspect of the present 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 a teach pendant) separated 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 the first release signal and the second release signal are still received, causing the actuator indicated by the actuator selection data to enter the MwoDP mode.

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

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

[0015] In some embodiments, an additional timeout condition is applied, by which the second release signal is required to be received within a predefined timeout period. Thus, if the timeout period is exceeded, the result of the determination will be negative even if the first release signal and the second release signal are received simultaneously at a later point in time. These embodiments may be less sensitive to inadvertent activation due to operator negligence.

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

[0017] Some embodiments relate to the case where an optional input port is provided that is separate from the programming interface. This will be conveniently integrated with existing robotic systems. In these embodiments, the method also includes receiving static actuator selection data via pre-programming. Then, in order to determine that the first release signal is still received and the second release signal is received via the alternative input port, the actuator indicated by the static actuator selection data enters the MwoDP mode. Some embodiments of these embodiments can be combined with modified variations of the display of the above-mentioned visual indicators.

[0018] In a further embodiment freely combinable with all the above embodiments, a command is transmitted from the programming interface to the robot controller using a secure communication protocol to cause the instructed 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 comprises: 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 a processing circuit configured to perform a method according to the first aspect of the invention.

[0020] The programming interface generally shares the expected effects and advantages with the first aspect of the present invention, and may be embodied with a corresponding degree of technical variation.

[0021] The invention also relates to a computer program comprising instructions for causing a computer or in particular a programming interface to perform the above method. The computer program can be stored or distributed on a data carrier. As used herein, a "data carrier" can be a transient data carrier, such as a modulated electromagnetic or optical wave, 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 the magnetic, optical or solid-state type. Such memories still fall within the category of "data carriers" and can be fixedly mounted or portable.

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

[0023] In general, all terms used in the claims should be interpreted according to their ordinary meaning in the technical field, unless otherwise explicitly defined herein. Unless otherwise explicitly stated, all references to "elements, devices, components, means, steps, etc." should be openly interpreted as references to at least one instance of an element, device, component, means, step, etc. Unless explicitly stated otherwise. The steps of any method disclosed herein do not have to be performed in the exact order described. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Various aspects and embodiments will now be described, by way of example, with reference to the accompanying drawings, in which:

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

[0026] Figure 2 is a flow chart of a method for controlling an industrial robot according to an embodiment of the present invention;

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

[0028] Figure 4 is the front view of the example programming interface. DETAILED DESCRIPTION

[0029] Various aspects of the present disclosure will be described more fully below with reference to the accompanying drawings, in which certain embodiments of the present invention are shown. However, these aspects can be embodied in many different forms and should not be construed as limiting; rather, these embodiments are provided by way of example so that the present disclosure will be thorough and complete and the scope of all aspects of the present invention will be fully conveyed to those skilled in the art. Throughout the description, like numbers refer to like 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. The programming interface 120 may be considered a non-permanent component of the industrial robot 100 for reasons explained below.

[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 through a wired or wireless interface. The robot manipulator 130 can be configured to execute signals from at most one designated robot controller 110 at each point in time. Conversely, the robot manipulator 130 can be configured to share sensor signals only with a designated robot controller 110. In addition, the robot controller 110 can be configured to control a single robot manipulator 130 at a time, where the robot controller and the robot manipulator can be considered to be a one-to-one relationship. The robot controller 110 includes at least a processing circuit 111 and a memory 112. Figure 1 The robot controller 110 in the embodiment has an optional input port 140 to which an input device 141 can be connected. The optional input port 140 can be a general data port, and its recommended use will be described later. In some embodiments, the processing circuit 111, the memory 112 and the optional input port 140, some or all of which can be active during the execution of the method 200, can belong to a so-called safety controller within the robot controller 110.

[0032] Figure 1The robot manipulator 130 shown constitutes a fixed robotic device, although in other embodiments it may be a mobile robot. For example, the robot manipulator 130 may be a lightweight manipulator with a lifting capacity of at most 20 kg, such as at most 10 kg, such as at most 5 kg. In particular, the robot manipulator 130 may belong to a collaborative robot 100 adapted to work in conjunction with one or more operators. Figure 1 In the illustrated embodiment, the robotic manipulator 130 includes a base from which extend a plurality of components connected by rotational or linear joints and configured to carry a tool (or end actuator in another term) at its distal end. Actuators 131 for applying acceleration or deceleration torque and force are provided in the robotic manipulator 130. At least some of the actuators 131 include a drive device 131.1 and a brake device 131.2. The drive device 131.1 may be, for example, electric, hydraulic or pneumatic. The brake device 131.2 may include a moving component powered in the same manner, which is configured to generate a braking force by magnetic, friction or locking action. Except when the robot 100 is in a drive-free power motion (MwoDP) mode, the brake device 131.2 is configured to engage while the drive device 131.1 is in an inactive state. The brake device 131.2 is configured to have such behavior by installing a physical or mechanical device (e.g., a spring-loaded mechanism released by the motion of the drive device 131.1), a suitably programmed embedded controller, firmware or other suitable logic. It is understood that a corresponding behavior - the actuator 131 "freezes" during inactivity - can be easily realized by applying structural and functional solutions within the common general knowledge of the skilled person, even without the illustrated structure of the drive device 131.1 and the brake device 131.2 in the actuator 131. Such solutions are encountered 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 logo with a changeable appearance. The indicator light or logo can be arranged in a place where it is easily visible, such as near the end actuator. In other embodiments, the robotic manipulator 130 can be associated with the visual indicator 132 in other ways; for example, the visual indicator 132 can be mounted or hung near the robotic manipulator 130, where it can be seen by the operator and any bystanders. Further optionally, the visual indicator 132 can be marked with the name or other identifier of the robotic manipulator 130.

[0034] The programming interface 120 is provided with various input devices 121, 122, a screen 124 and a processing circuit 125. The input devices 121, 122 may include keys, keyboards, touch pads, scroll wheels, joysticks or switches (selectors) with two or more positions. It should be noted that the screen 124 and some of the input devices 121, 122 may be provided on opposite sides of the programming interface 120. Figure 1 In the embodiment of the present invention, the first 121 of the input devices is a button with a latch, which is arranged to remain activated (i.e., pressed) after the operator releases it; the button can be restored to its inactive position by a latch release operation, such as rotating the button about its axis. This type of button is often used as an industrial emergency stop (ESTOP) button. In addition, in Figure 1 In the embodiment of the present invention, the second of the input devices 122 is a three-position safety switch (also called a three-stage enabling switch) which includes a spring-loaded knob or lever that can be linearly moved by hand between two inactive end positions, defining an active position between the two inactive end positions. This three-position safety switch is considered to be very robust against unintentional manual activation because the knob will be pushed into (or returned to) the end positions unless the operator applies the correct force. The three-position safety switch 122 can be provided on the back of the handheld programming interface 120.

[0035] The screen 124 is adapted to display a graphical user interface 123. The graphical user interface 123 may receive input via the input devices 121, 122, or in embodiments where the screen 124 is touch-sensitive, directly through the 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 shown.

[0036] like Figure 1 As shown, the programming interface 120 is detachable from at least one component of the industrial robot 100, which means that the programming interface 120 is suitable for being manually and / or non-destructively separated from the robot controller 110 or the robot manipulator 130 or another component after use. During use, the programming interface 120 can be connected to a connection point on the robot controller 110, for example, to establish a wired or wireless connection. Figure 1 1, wherein the connection line 126 from the programming interface 120 is connected to the corresponding connection line from the robot controller 110 by a releasable plug and socket combination. The 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 configuration of the robot 100 is such that programming or training is not possible 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 a teaching phase, during which an operator can generate executable robot instructions. The 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 saved to the memory 112. The robot instructions in the memory 112 can be retrieved after the training phase is completed (e.g., during production) and executed by the robot controller 110 and the robot manipulator 130. The non-text input data can be provided through on-programming or manual jogging, during which the movements of the robot manipulator 130 are sensed and recorded. The programming interface 120 can be configured to accept commands indicating the beginning and end of the training phase, commands to start and end a recording session, commands for managing the recording (delete, save, crop, edit, etc.), and commands to supplement the robot manipulator 130 movements in various ways (e.g., activate / deactivate tools, assign speed and other attributes to the motion path). The programming interface 120 can be further configured to convey visual, acoustic, or tactile information related 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 type described above will now be presented. The method 200 is generally performed by the industrial robot 100. Specifically, it can be performed by processing the circuit 111 in the robot controller 110 alone, processing the circuit 125 in the programming interface 120 alone, or by a combination of these. In addition, the 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 conceived the method 200 as a safer way to put the industrial robot 100 into MwoDP mode than currently available technology allows. It should be understood that no other way 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 . In a first step 211, a first release signal U1 is received via a first safety input device. In an embodiment where the method 200 is implemented in the robot controller 110, the first release signal U1 is received 211 in the robot controller 110 even though the first safety input device may be located elsewhere, such as in the programming interface 120. The first release signal U1 may be represented as a change in an analog or digital channel value; or, the first release signal U1 may be represented as a code transmitted via a wired or wireless carrier or medium.

[0040] Recall that the intended meaning of a "safe" input means - whether implemented only in hardware, only in software or in a combination of these - has been explained in the previous section of this disclosure. In line with this definition, for example, a "safe" input means that it may be a safety-certified device, that is, one that is certified to the ISO 13849-1 standard (Safety of Machinery - Safety of Partially Controlled Systems - Part 1: General Principles for Design), the IEC 61508 standard (Functional safety of 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 means may have been found to comply with one of the safety integrity levels specified in these references. As another specific example, a "safe" input device may comply with 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 arranged on the programming interface 120 or separated from the programming interface 120. The first safety input mode can be one of the input modes on the programming interface 120 mentioned above. In particular, the first input device can be an emergency stop button 121 with a latch, which allows the first release signal U1 to be conveniently maintained during the subsequent steps of the method 200. A similar emergency stop button can also be provided near the robot manipulator 130.

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

[0043] It is recalled that any input means may be implemented as a "safe" input means or as a non-safe input means. Selecting a non-safe input means as the arbitrary input means may be a more economically attractive option. However, using a "safe" input means does not deprive the method 200 of any effect or benefit - rather, the degree of safety is slightly enhanced - but may be an unnecessarily expensive option. The arbitrary input means may include a graphical user interface displayed on the screen 124 of the programming interface 120. For example, an operator may be shown a visual representation of the actuators 131 located at their approximate positions relative to the robot manipulator hand 130, and be able to select and deselect them by touch commands or other forms of input.

[0044] The screen 124 may optionally be used to display a (graphical) user interface related to functions other than the MwoDP mode. These functions may, for example, include the functions described above related to the teaching phase, 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 movements of the robot manipulator 130 in various ways. The functions related to the teaching phase and the functions related to the MwoDP mode may be provided as two menus or submenus of a common graphical user interface. Under this option, since the screen 124 is used for the purpose of the MwoDP functionality, any errors affecting the screen 124 may be discovered in advance, so the risk of receiving incorrect actuator selection data through the screen 124 may become more acceptable.

[0045] In the third step 213 of the method 200, a second release signal U2 is received by a second safety input device. Similarly, the second safety input device can be arranged in a unit (e.g., programming interface 120) different from the unit (e.g., robot controller 110) receiving the second release signal U2. Just like the first release signal U1, the second release signal U2 can represent a change in value or by transmitting a pre-agreed code or symbol. The second safety input mode is "safe" in the above sense. The second safety input device is preferably non-locking, that is, once the operator releases the second safety input device, the second safety input device returns to the inactive position. In particular, 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 graphic element displayed on a safety touch screen previously used for another purpose (e.g., inputting actuator selection data V), it is preferred to display the element in a different position from other graphic elements previously used for the other purpose. This will require the operator to move a finger to activate the second safety input device, thereby reducing the risk of unintentional activation.

[0046] In a fourth step 214 of the 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 a fifth step 215 of the method 200, the actuator 131 indicated by the actuator selection data V enters the MwoDP mode. At the level of one actuator 131 including a drive device 131.1 and a brake device 131.2, wherein the brake device 131.2 is engaged by default in certain circumstances, entering the MwoDP mode may include releasing the brake device 131.2.

[0047] If the criterion evaluates to false (N branch of block 214), in a sixth step 216, it is ensured that the actuators 131 are not in MwoDP mode. To this end, more precisely, the state of the actuators 131 can be retrieved and, if the actuators 131 are in MwoDP mode, the actuators 131 are taken out of 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, i.e., 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 point in 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, for example 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 fifth step 215 to fourth step 214, such as Figure 2 The loop back to the fourth step 214 may optionally be configured to occur after a predetermined delay T>0. This achieves the indicated behavior of the actuator 131 remaining in the MwoDP mode for the time the operator generates the second release signal U2, with a granularity of T.

[0050] In some embodiments of the method 200, bystanders and operators are aware of the fact that the MwoDP mode is about to be entered. More specifically, when the graphical user interface is displayed on the screen 124 and / or the user accesses the graphical user interface, a visual indicator associated with the robotic manipulator hand 130 is displayed. Displaying the visual indicator may include lighting up Figure 1 Light 132 is shown.

[0051] As described above, the programming interface 120 may be detachable from a component of the industrial robot 100 to allow it to be moved and used to train other robots 100 at the same or different work sites. Effectively, especially in large deployments, the programming interface 120 may be present at a given robot 100 for a relatively small total time. If the ability to use the MwoDP mode more frequently is deemed important, then according to an embodiment to be described next, the method 200 may be extended with some additional steps to allow entry into the MwoDP mode even when the programming interface 120 is not available.

[0052] In order to implement the backup way of entering the MwoDP mode according to the present embodiment, the industrial robot 100 is preprogrammed with static actuator selection data V' (step 217), and it is further configured to evaluate the condition for triggering the MwoDP mode (step 218). The static actuator selection data V' is similar to the actuator selection data V, indicating that when the condition is found to be true, one or more actuators 131 will enter the MwoDP mode. The preprogrammed step 217 of receiving the static actuator selection data V' usually occurs before receiving the first release signal U1. The condition is whether the first release signal U1 is still received and whether the second release signal U2 is received through a backup input port separated from the programming interface 120. The backup input port can be the above-mentioned backup input port 140 on the robot controller 110, and the input device 141 can be connected to the backup input port. The backup input port 140 can be a general input port, which can be designated in the system configuration of the robot controller 110 for override purposes, that is, for the input port 140 to receive the second release signal U2. The input device 141 connected thereto is preferably a "safe" input device in the above sense, such as a safety-certified three-position safety switch, a safety-certified non-locking ESTOP button, etc. The input device 141 can be shared with another industrial robot (for example, it can be included in a detachable unit dedicated to MwoDP operation), or the input device 141 can be suitable for a single industrial robot 100. The alternative input port 140 can optionally be implemented as a safety input port. The first release signal U1 is preferably received by a first safety input device (for example, an ESTOP button) separated from the programming interface 120.

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

[0054] Optionally, to prevent unintentional entry into the MwoDP mode in an alternative manner, entry of the actuator 131 into the MwoDP mode is delayed for a predefined delay period; if at the end of the delay period both release signals U1, U2 are no longer received, the MwoDP mode is not entered. This embodiment may include the use of a visual indicator to alert the operator and any bystanders, similar to that described above. However, because the actuator selection data is static, the operator does not use any graphical user interface, the use of which could be used to trigger the visual indicator. Instead, a visual indicator 132 associated with the robotic manipulator 130 is displayed for the duration of the delay period during which entry of the actuator 131 into the MwoDP mode is delayed.

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

[0056] The 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 way in which the 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 fully protects the integrity of the data transmitted on the communication path between the programming interface 120 and the robot controller 110.

[0057] Figure 3 The sequence diagram in FIG. 1 shows an exemplary safety communication protocol, which relates to an embodiment of implementing the method 200 in the robot controller 110. The sequence diagram shows signals and data exchanged between the first safety input device 121, the second safety input device 122, the graphical user interface 123 on the screen 124 of the programming interface 120 (as an example of a non-safety input device), the programming interface 120 (e.g., the processing circuit 125 therein), the robot controller 110, and the actuator 131 indicated by the actuator selection data V. The signals and data are represented by arrows, Figure 3 The downward direction in represents the rise time.

[0058] like Figure 3As shown, after the robot controller 110 receives the first release signal U1, the operator continues to use the programming interface 120 to input the actuator selection data V. 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 so 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 a 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 a cyclic redundancy check (CRC). Many one-way functions for this purpose have been described in the literature, one example being CRC32, for which a software implementation can be retrieved from the website sourceforge.net / projects / crccalculator / files / CRC / . Return Figure 3 If the programming interface 120 is able to reproduce and thereby verify the checksum CRC(W) calculated by the robot controller 110, the programming interface 120 calculates the checksum of the checksum CRC(W) and transmits it to the robot controller 110. Optionally, Figure 3 As shown, the transmission of the checksum cyclic redundancy check (CRC(W)) can be conditional on the second release signal U2, which can be intercepted by the programming interface 120, although the second release signal U2 is actually destined for the robot controller 110 executing the method 200. In turn, the robot controller 110 attempts to verify the received checksum cyclic redundancy check (cyclic redundancy check (W)) by recalculating it based on the previously calculated checksum cyclic redundancy check (cyclic redundancy check (W)). If the robot controller 110 has received the second release signal U2 and the verification is successful ( Figure 2 1), the robot controller 110 sends a control signal M to the actuators 131 in the robot manipulator 130, commanding them to enter the MwoDP mode. Conversely, if the programming interface 120 cannot reproduce the checksum cyclic redundancy check (W), the protocol is terminated and the MwoDP mode will not be triggered due to the lack of actuator selection data v.

[0059] Aspects of the disclosure have been described above mainly with reference to a few embodiments. However, as readily appreciated by a person skilled in the art, other embodiments than the ones disclosed above are equally possible within the scope of the invention, as defined by the appended patent claims.

Claims

1. A method (200) for controlling an industrial robot (100), The industrial robot (100) comprises a robot controller (110), a programming interface (120) separate from the robot controller (110), and a robot manipulator (130) having a plurality of actuators (131), The method (200) comprises: Receiving (211) a first release signal (U1) via a first safety input device (121); receiving (212) at the programming interface (120) via any input device (123) actuator selection data (V) indicative of one or more of the actuators (131); receiving (213) a second release signal (U2) at the programming interface (120) via a second safety input device (122) after having received (212) the actuator selection data (V); as well as In response to determining (214) that the first release signal (U1) and the second release signal (U2) are still being received, causing (215) the actuator indicated by the actuator selection data (V) to enter a non-driven power movement mode.

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

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

4. The method (200) according to any one of the preceding claims, wherein the first safety input device is arranged at the programming interface (120).

5. The method (200) of any one of the preceding claims, wherein the first safety input device is an emergency stop button with a latch.

6. The method (200) of any one of the preceding claims, wherein the second safety input device (122) is a three-position safety switch.

7. The method (200) according to any one of the preceding claims, wherein the programming interface (120) is a teach pendant.

8. The method (200) according to any one of the preceding claims, wherein the programming interface (120) is detachable from at least one component of the industrial robot (100).

9. The method (200) according to any of the preceding claims, wherein the arbitrary input means is a graphical user interface displayed on a screen (124) of the programming interface (120).

10. The method (200) of 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 robotic manipulator (130) is presented (212.1).

11. The method (200) according to claim 9 or 10, wherein the screen (124) is further configured to display a user interface related to functions other than the non-driven powered motion mode.

12. The method (200) according to any one of the preceding claims, wherein: Each of the actuators (131) comprises a driving device (131.1) and a braking device (131.2); and When the drive device is not activated, in addition to being in the non-drive powered motion mode, the brake device (131.2) is configured to engage.

13. The method (200) according to any one of the preceding claims, further comprising: Receiving (217) static actuator selection data (V') via pre-programming; as well as In response to determining (218) 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), causing (215') the actuator indicated by the static actuator selection data (V') to enter the undriven powered motion mode.

14. The method (200) of claim 13, wherein the alternative 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 or 14, further comprising: Entering the actuator into the unpowered motion mode is delayed for a predefined delay period.

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

17. The method (200) according to any of the preceding claims, further comprising receiving (215.1) 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) comprising 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 coupled to a first safety input device (121) and a second safety input device (122) and an arbitrary input device (123); and The robotic controller (110) includes processing circuitry (125) configured to perform the method (200) of any one of the preceding claims.

19. A computer program comprising instructions for causing 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