Any suggestion how to resolve KSS01205 Ackn.: Interpolation cycle timeout monitoring LRS_HP issue

  • Hello,


    For the last few weeks, the smartPad controller displays the following errors:

    • Emergency Stop inoperative
    • KSS12041 Ackn.: Position comparison robot controller <-> safety controller not possible.
    • KSS15085 Ackn.: Controller in failsafe state.
    • KSS01205 Ackn.: Interpolation cycle timeout monitoring LRS_HP

    As for now, I am informed that KSS01205 causes the other errors. The error sometimes occurs in motion commands, sometimes after a physical “RESET” or “Reset program” button click, and sometimes just randomly. In 2 weeks, there were only 2 days when the error did not occur at all. The robot code remains almost unchanged every day, the main difference is the motion programs. The interesting part is that sometimes the relaunch of the same motion program does not provoke the error.


    The robot's information:

    KR 20 R3100, Serial No. 1422984

    KSS 8.6.11 (before the KSS update, the version was 8.6.9).

    KRC4 controller.


    Additional software:

    • EthernetKRL v3.1.3
    • DirectoryLoader v3.0.4

    Please see a little bit of information about the robot code below:

    1. In this cell I am using 8 submits. The responsibilities of the submits:
      1. sps.sub is responsible for a handshake between inputs and outputs of the Auto External mode.
      2. Submit for communication between the robot and SCADA.
      3. Submit to control indication lights – some lights must blink, that’s the main reason why I use an independent submit.
      4. Submit to control all interrupts. To prevent some errors, I declared all the interrupts in one submit. In this submit I use the CWRITE function for the RUN, STOP and CANCEL commands.
      5. Submit for rail control (11 meters long rail with 3 positions). By controlling several outputs, the robot tells PLC where to position the robot. In this submit I use a state machine.
      6. Submit for chamber/camera control. The chamber consists of two tables and by controlling a few outputs, the robot rotates the chamber (it switches the table 1 with the table 2 and vice versa). In this submit I use a state machine.
      7. Second submit for chamber (2) control. Everything is the same as in f.
      8. Third submit for chamber (3) control. Everything is the same as in f.
    2. At the beginning, all state machines are at an Init state. When the submit for communication receives a message from SCADA, it will change a corresponding state of the state machine to perform some kind of work. After successful work, that state machine goes back to the Init state. So, basically, SCADA is controlling the robot cell with the help of the communication submit.

    view


    Process of the system when the error occurs in the movement:

    1. I am selecting a cell.src program, switching to the EXT mode, pressing the RESET button. The cell.src program starts running in the EXT mode.

    2. The cell.src program waits until communication between the robot (server) and SCADA (client) is established.

    3. When the communication is established, cell.src is running in loop (init state of the state machine). Right now, extra submit which is responsible for communication waits for messages from SCADA.

    4. In SCADA, an operator selects programs for the robot. SCADA uploads the files to the shared folder of the robot (D:\Directoryloader) and then sends a message to the robot to initialize a directory loader.

    5. The communication submit reads the message from SCADA and checks if the initialization of the directory loader is safe. If safety check passed, in the main program the robot starts to execute the sequence of the directory loader.

    6. The robot uploads the programs from the D:\Directoryloader folder. The main program (cell.src) starts to wait for communication again.

    7. After the upload of the files, SCADA reconnects to the robot.

    8. The operator prepares an object and press the READY button. That triggers an interrupt which sends the “Table of the Operator 1 is Ready” message from the robot to SCADA.

    9. SCADA sends the “Rotate the chamber 1” message to the robot. The state machine of the chamber 1 performs the rotation process. The robot informs SCADA that the rotation is finished.

    10. SCADA tells the robot to go to a specific position on rails. The submit of rails control performs the task and informs SCADA about it.

    11. SCADA tells the robot to perform a specific work program (one of the files which was uploaded with the directory loader in the sixth step).

    12. The robot starts to perform the motions to the first point and here the issue occurs in the motion.


    I am adding the snippet of the code function where the error occurred most often in the movement of the robot:

    At this point, we have already tested these parts:

    1. The usage of the CWRITE function for the RUN, STOP and CANCEL commands. At first, we suspected that they were called from different submits with an overlap, but after the code check, the support did not find anything wrong with the KRL code.
    2. I tried to replace a pendant from another robot because my colleagues suspected that something was wrong with the pendant itself. But the same issue occurred again.
    3. I tried to reduce the override speed of the robot program (up to 30%). At first, it seemed to be working but after 6 times of relaunching the same program, the same issue of the program execution occurred again. Since the error happens at the same code line (concerning the movement), I added "WAIT SEC 0" hoping it will stop the advance pointer and issue will be resolved, but it did not help.
    4. As the support suggested, I tried to set the value $sr_workspace_red=false.
    5. I turned off the workspaces (except 2 of them).
    6. I turned off the workspaces (except 2 of them), commented all the user code in sps.sub and cancelled all the extra submits (so, basically, I left running Cell.src + sps.sub).
    7. As the support suggested, I updated KSS (from 8.6.9 to 8.6.11) but it did not help.
    8. After the KSS update, I turned off the workspaces again (except 2 of them), set $sr_workspace_red=false, commented all the user code in sps.sub and cancelled all the extra submits.
    9. After that, the support suggested to update the KRCConfig.xml file. But it did not help either.
  • Fubini

    Approved the thread.
  • Take a KRCDiag when the error is shown and send it to KUKA HQ support. R&D can find out by studying the task switch monitoring log files inside the diag files which operation is taking up too much time so lrs_hp is not executed according to it's cycle. Nothing much else you can do.



    Fubini

  • Hello, Fubini.

    I have already been talking to support for a few weeks, but none of the suggestions helped so far. :S

    I naively hoped that there was something I could do to fast forward this issue elimination because right now this is the only issue blocking me from finishing the project.

  • Hi,


    There are some updates.


    It seems that the problem is caused by too big spline blocks in the program.


    The robot can execute the spline block, but the error occurs when I press the "Reset program" button:

    1) When the robot has not finished to execute the spline.

    2) After the robot has finished the spline execution and performed some other movements.


    Does anyone know the maximum "correct" size of a spline block? Or will it be my destiny to perform many tests to figure it out? :D

    Or maybe there is some kind of system variable which could warn me that the robot is performing some kind of important task right now?

  • No there is neither. Spline is bounded only by memory size. Your conclusion at first glance looks unplausible to me. Planning and sampling priority is less than lrs_hp where hp stands for high priority. So that if lrs_hp is not resumed fast enough would require some sort of priority inversion. Something I would not expect to happen, but who knows ...


    Fubini

  • I have similar problem with messages:


    • Emergency Stop inoperative
    • KSS12041 Ackn.: Position comparison robot controller <-> safety controller not possible.
    • KSS15085 Ackn.: Controller in failsafe state.
    • KSS01205 Ackn.: Zyk_PosIPO cycle time.


    I take KRCDiag and examine of logs and I found some logs:




    ERROR iHnf1 22:21:22.969 : Cycle 17843. Wrong cycle timing. Delayed for 32015 us (Min: 6000 us, Max: 18000 us). Source: PLC cycle watchdog

    ERROR iHnf1 22:21:22.969 : Cycle 17843: cycle time violated (source: 703).

    ERROR iHnf1 22:21:22.969 : InterfaceSetTimingViolationFailureState(): Timing-violation SOS_FAILURE_STATE_IS_ACTIVE

    WARN iHnf2 22:21:22.969 : switching timer source to TS_TSC

    ERROR iHnf1 22:21:22.969 : Cycle 17843. Wrong cycle timing. Delayed for 32017 us (Min: 6000 us, Max: 18000 us). Source: Generic high precision time

    ERROR iHnf2 22:21:22.969 : Cycle 17843. Wrong cycle timing. Delayed for 32097 us (Min: 6000 us, Max: 18000 us). Source: PLC cycle watchdog

    ERROR iHnf2 22:21:22.969 : Cycle 17843: cycle time violated (source: 703).

    ERROR iHnf2 22:21:22.969 : InterfaceSetTimingViolationFailureState(): Timing-violation SOS_FAILURE_STATE_IS_ACTIVE

    ERROR iHnf2 22:21:22.969 : Cycle 17843. Wrong cycle timing. Delayed for 32121 us (Min: 6000 us, Max: 18000 us). Source: Generic high precision time

    ERROR iHnf1 22:21:22.970 : hnfDoSafeOSCyclic: Cycle time violated in cycle 17843

    ERROR iHnf2 22:21:22.970 : hnfDoSafeOSCyclic: Cycle time violated in cycle 17843

    INFO dKRC 22:21:22.977 : Meldung Nr. M_15058 abgesetzt

    INFO tMELD 22:21:22.977 : M_15058: "Die Steuerung ist im fehlersicheren ..."

    WARN tNextGen 22:21:22.980 : CNextGenPowerBrakeControl: Wrong hardware state in "ReadyToMove". (A4)

    WARN tNextGen 22:21:22.980 : CNextGenPowerBrakeControl: Wrong hardware state in "ReadyToMove". (A5)

    WARN tNextGen 22:21:22.980 : CNextGenPowerBrakeControl: Wrong hardware state in "ReadyToMove". (A6)

    BASIC tNetP052 22:21:22.983 : <SYS-X48>: KCP-Connected State-Change: Old='KCP_Plugged' -> Act='KCP_Unplugged'

    WARN tNextGen 22:21:22.984 : CNextGenPowerBrakeControl: Wrong hardware state in "ReadyToMove". (A1)

    WARN tNextGen 22:21:22.984 : CNextGenPowerBrakeControl: Wrong hardware state in "ReadyToMove". (A2)

    WARN tNextGen 22:21:22.984 : CNextGenPowerBrakeControl: Wrong hardware state in "ReadyToMove". (A3)

    WARN tLRS_HP 22:21:22.984 : laghpStateRegular: Spontanantriebsstopp

    INFO tLRS_HP 22:21:22.984 : Meldung Nr. M_108 abgesetzt

    ERROR tCabCtrlFa 22:21:22.984 : virtual void CCabCtrlOpProcessSafetySignals::DevelopIO(): No communication with Safety! Interface versions: CabCtrl(13), Safety(0).

    INFO tMELD 22:21:22.984 : M_108: "Drehzahl-Stopp aktiv"

    INFO tZYK_preIP 22:21:22.992 : Meldung Nr. M_310 abgesetzt

    INFO tZYK_preIP 22:21:22.992 : Meldung Nr. M_3186 abgesetzt

    INFO tMELD 22:21:22.992 : M_310: "Antriebe durch Safety deaktiviert."

    INFO tMELD 22:21:22.992 : M_3186: "Antriebe wurden entladen (Grund: SAFETY)"






    It seems motherboard problem in PCH chip because HPET timer in PCH chip in my case. It seems similar.


    My thesis some threads in VxWin taking too long time and safety system going to fail safe state reason of thread monitoring. All safety communication lost included the SmartPad and you can see Emergency Stop Inoperative and red banner on top. I tried replace PLC and other related components but no success. I will try new motherboard in few days.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account
Sign up for a new account in our community. It's easy!
Register a new account
Sign in
Already have an account? Sign in here.
Sign in Now