Interrupt not working when program is stopped

    Quote from panic mode

    Program looks ok to me. I think the issue is with testing conditions. Do not stop program... Keep it running... do not pause to trigger the interrupt. And make sure input is off before each test.

    Well, ok. But is should have worked, even if the program was paused. At least it used to in earlier versions (e.g. v8.3). I found the proof that it used to be the way I want in an old manual that you shared in another thread in this forum.

    The document is :

    "SOFTWARE

    KR C1 / KR C2 / KR C3
    Reference Guide
    Release 4.1"

    And in section 2.2.27.3 on page 84 it says:

    "Each declared and activated interrupt can be detected once during an operator stop. After

    restarting the system, the interrupts that have occurred are executed in order of their priority
    (if they are enabled). The program is subsequently continued."


    This is exactly the behavior I want have have observed in older versions, but don't see anymore in v8.5. So KUKA must have changed something related to that. This was why I was asking about change-logs.

    I have a former colleague that now works at KUKA, so I think I'll give him a call to find out if the change in v8.5 is intended or not.

    "Do not stop program... Keep it running... do not pause to trigger the interrupt."

    This is unfortunately not realistic for use case we have. The user will be using the robot in T1 mode a lot of the time during setup and run in, and might release the stop button at any point.

    The robot receives coordinates from a software that runs on the PC. At any point the user might decide to change the program flow on the PC and start over. When this happens, the PC sends a stop signal that tells the robot to stop the current movement and skip any other movements that have been queued up. This is handled by the SPS. The PC software will then ask the robot where it currently is, and take it from there. Unfortunately, the interrupt that is triggered by the SPS only works properly if the robot is moving when the stop signal comes. If the robot program was temporarily paused, then the interrupt handler will only be run AFTER the current movement.

    the operating systems changed several times and so did resource management. just the Windows grew from Win95 to Win10 and that was not a single step. KSS went through many more releases (KSS 3.x 4.x 5.x 8.2.x 8.3.x 8.5.x etc ) and each of those major versions had many versions (about 50 or so in KSS8.3.x alone).

    of course many things will be compatible but - there will be some changes as things evolve. using reference document for KRC1 to form expectations for KRC4 or KRC5 is a bit of a stretch. modern KSS versions have very different allocation of resources. for example now there is a multisubmit and CPU quotas, a clear sign of things done differently.

    but regardless of KSS version, the way like to think of programs is simple:

    any instruction in a program is ONLY exectuded when that program is processed by an interpreter. and interpreter can ONLY process instructions while it is enabled. for robot program interpreter that means (among other things) that RUN button is held pressed while in T1 mode.

    anything else is a fringe factor and therefore may not be guaranteed. therefore i would not like to do it the way you want even if was working on KRC1. if you expect controller to react to some events when robot interpreter is not running, do not put that code into robot program - put it in a program that runs continously (Submit). Then you can be sure that events are captured no matter what. Then your robot program can process them as needed, whenever robot program gets to run.

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

    I know that a manual from the KRC1/KRC2 times is hardly up to date, but since the behavior described in the manual aligns with what I observed up until software version 8.3, I thought that it was fair to assume that the behavior would still be the same in 8.5. That it is no longer mentioned in the manual I find less important, since KUKA sometimes seems to omit some things in some manuals.

    I have emailed my contact at KUKA asking whether they have change-logs, so let's see what that brings.

    But anyways, I managed to solve my problem using an interrupt that is triggered by a cyclical flag that is defined like this:

    $cycflag[4] = ($PRO_STATE1 == #P_ACTIVE) AND (STOP_REQUESTED == TRUE)

    The STOP_REQUESTED variable is then set from the SPS.

    Because we use $PRO_STATE1 (program state) in the cyclical flag, the rising edge that triggers the interrupt will never come while the program is stopped, only when it is started again. I have now implemented it and tested it multiple times, and it works!

    I am pretty satisfied with that solution, unfortunately I didn't come up with it myself, one of my colleagues suggested it.

    Quote from Fubini

    After the resume of interrupt_handler.

    Fubini

    Some kind of glitch in Fubinis main memory :icon_mrgreen:

    Code after resume is not executed. AFAIK. So this:

    Quote from RoboticsMan

    Oook? But I don't have any movements in the interrupt, so I am not sure how that will change anything. Especially since my problem is that the interrupt is triggered later than I want. But sure, I'll try it out.

    Update: I tried it, didn't change anything.

    was expectable.

Advertising from our partners