Posts by RoboterEST

Will follow your guidelines for posting from now on.

Okay, I will try to react to the alive flag when connection is lost. Found a piece of code in the manual that achieves that using interrupt. With a few modifications this could work.

In response to hermann: So you're saying that even if I succeed in hiding the EKI error message from the display the program would still stop? I thought hiding the EKI messages would lead to behaviour similar to pressing the Confirm button, where the program continues executing (this is what currently happens when I press Confirm).

(For reference, usually I wouldn't need to open and close the server that frequently when dealing with KUKA to KUKA connection. However one of the older ABB robots seems to drop the connection from time to time)

Jürgen

Greetings

Robot controller: KRC5

KSS: 8.7.4

Ethernet KRL version: 3.2.7

My robot is configured to be a server that receives data from another robot (figure 1). The server program runs in submit interpreter in order to respond to requests swiftly (figure 2). Everything works fine for an hour or so until some error messages ("Initialisation already performed", "Create server failed", etc) pop-up on the top of display. When the error messages are cleared from the display, the connection is automatically restored and program proceeds to work correctly again.

I have not encountered an error message in testing that leads me to believe that something is systematically wrong with the robot program. Rather when reading the EthernetKRL manual it seems that encountering some of these errors is to be expected (figure 3). So I would like to deactivate the message output on display. I have tried the following options:

1) Disabled messages in EthernetKRL configuration file (figure 1 again, <MESSAGES> tag)
2) Added ON_ERROR_PROCEED line right before any EKI function call (removed from the program after testing as they didn't do what was intended)

So far both of these options have not worked as the EKI errors still appear on the display. Am I disabling the ethernet messages wrong? Are there any alternatives to automatically clear these EthernetKRL errors when they occur?

Regards
Jürgen

For future reference, the function SWRITE is described in KUKA CREAD/CWRITE documentation. There you can find examples on how to use it as well.

Hello

Thank you for your input. This way of doing things works. I hope that implementing a INTERRUPT-RESUME system and turning the INTERRUPT off right after method call works. Since most of the factory side staff is on holiday I cant be 100% sure but I do believe that the issues pointed out solved the problem.

Thanks hermann and Koppel.

hermann When moving downwards on the Z axis, the pressure cilinder will generate an interrupt when it encounters an object and presses on it. This INTERRUPT is enabled at the beginning of the main program and can be considered a stop criterion.

I will try to rework the code today so it will use RESUME and add some additional stop criterion coordinates wise.

UPDATE (Post #3): The operator seems to think that the change, where I turned the interrupt off immediately after function call, might have done the trick. Since the error was this rare of I am yet to be convinced, but will see.

hermann Disabling the interupt earlier is a good suggestion. Will make that change and update this post, if this fixes the issue.

To your second point, I am aware that the robot moves downwards after INTERRUPT 17 is triggered, but this "additional" movement after the interrupt causes no problemse. Currently RESUME variant can not be implemented easily and therefore changing this is not a priority (unless it could fix the issue at hand).

Greetings

First time poster. I've read the READ FIRST post and will try to give all the relevant information. If something is missing I can specify.

Problem description

I've been programming a KUKA KR 120 R3200 PA robot arm. In one of the sections of the program the robot arm starts descending and waits for a signal ($IN[6]) from a ultrasonic sensor to trigger an interrupt. The interrupt switches a boolean variable in the main program, which the program interprets as a signal to stop descending. This works 99% of the time, but there are some (seemingly random) instances where the robot just stops moving after the interrupt is triggered and doesnt continue executing the rest of the program. When I look at the main pointer it is still at LIN_REL {Z -10} portion of the program (aka still descending), but the robot itself is at a standstill. When the program is reset and run from the beginning, this stopping problem persists, but when I reboot the system (with "Reboot control PC" button) the problem disappears and the rest of the program is executed as intended.

Additional information: When the issue occurs there are no errors displayed on screen (see image below). All the drives seem to be active, because when I move the robot and then press the play/start button the robot moves to the previous position. I've also checked the $VEL and $APO variables which seem to have normal values, meaning that the speed, acceleration values are ok. Also when observing the $POS_ACT value there seems to be no change, so the robot is not moving even in the slightest.

According to one of the operators the issue occurs when the program is reset and ran after one of the safeguards is activated and the program stops the robot. The safeguard is a pressure cylinder on the robot which stops the robot when it presses too hard against something. It is possible that this safeguard isn't triggered on time and the KUKA internal safeguards stop the robot, but from what I've seen my safeguard catches the issue and the program reset works fine.

Thoughts: I have a gut feeling that it has something to do with the interrupt (as it happens right after interrupt is triggered), but can't figure out what I'm doing wrong. The robot is operational 5 times a week around 5 hours a day and this kind of problem occurs once almost every day. Any guidance on how to solve or debug this issue when it reoccurs is much appreciated.

Code and screenshots

Descending to pack (code)

   PalletOriginPos=$POS_ACT
   BAS(#VEL_CP, 2.0)
   ; MÕÕDAB KÕRGUSE (Z KOORDINAAT)
   StopZMoveOnInterrupt=TRUE
   INTERRUPT ON 17   ;JYRGEN: Ultraheliandur.
   WHILE StopZMoveOnInterrupt==TRUE
      LIN_REL {Z -10} C_DIS
   ENDWHILE
   INTERRUPT OFF 17   ;JYRGEN: Ultraheliandur. 
   PalletOriginPos.Z=HitPoint.Z-78

Stop descending interrupt declaration and code:

INTERRUPT WITH BRAKE DECL 17 WHEN $IN[7]==TRUE DO HeightMeasure()   ;DI7_Ultrasonic_SP1
...
GLOBAL DEF HeightMeasure()
   BRAKE
   HitPoint=$POS_INT
   HeightOK=TRUE
   
   IF StopXMoveOnInterrupt THEN
      PhotoPointXAxis.X=HitPoint.X
      StopXMoveOnInterrupt=FALSE
   ENDIF
   IF StopYMoveOnInterrupt THEN
      PhotoPointYAxis.Y=HitPoint.Y
      StopYMoveOnInterrupt=FALSE
   ENDIF
   IF StopZMoveOnInterrupt THEN
      PhotoPointZAxis.Z=HitPoint.Z
      StopZMoveOnInterrupt=FALSE
   ENDIF
   INTERRUPT OFF 18   ;JYRGEN: Ultraheliandur.
   INTERRUPT OFF 17   ;JYRGEN: Ultraheliandur.       
END

Image of program on SmartPad when robot is not moving but program is running:

robot-forum.com/attachment/31109/

Robot information

Robot "KUKA KR 120 R3200 PA"

Firmware version "8.6.6"

Software Architecture "KRC4"