Recurring path maintaining emergency stop

    Hi All,

    We run a KR 10 R1100 sixx C robot which processes various parts: pick and place, some machining in between, etc.
    I developed a new program for a new part, including a new gripper to hold this part.
    The program was tested and ran without issue, until after about 0.5 days, it stopped mid-cycle and threw a KSS00404 safety stop, with sub-message "path maintaining emergency stop".

    After acknowledging the message, the program couldn't be restarted as the robot lost its mastering of axis A5 and A6.
    I remastered these axis and was able to run again. I thought it was just some random glitch of the universe, that caused this issue.
    However, the problem re-occured again after a few days.
    I haven't seen this problem before on any other program.
    Any ideas that might trigger this problem?

    One thing that crossed my mind, is that the gripper that has been developed for this new program is somewhat longer and more heavy than what we have used before. Maybe the increase mass causes motion errors in axis 5 and 6?

    Any help and ideas are appreciated.

    Erik

    I have overloaded Kukas before in the past and i believe the error associated with that is closer to "overload detected A6" or " over current detected A5" sort of templates. They do cause a stop, but they can be acknowledged and have it move again right away.


    I suspect it's most likely something with your safety CCT / Safety PLC? Could you give some details about that?

    Quote from erikD

    it stopped mid-cycle and threw a KSS00404 safety stop, with sub-message "path maintaining emergency stop".

    What other messages occurred at that same time? These messages tend to come in clusters. 00404 is generally the final result of a previous error.

    The fact that you lost A5 and A6 Mastering suggests a possible electrical issue. Overloading is unlikely to cause a loss of Mastering without triggering other messages first, like the overload/overtorque messages. Still, you should definitely check your load data settings -- having the mass, CoG, and inertia set incorrectly could be a contributing factor to whatever is going on. Uncommanded axis motion can sometimes lead to Mastering loss, and having incorrect $LOAD can contribute to uncommanded motion under some circumstances.

    Thanks for the quick responses. I looked back the error log of the previous two faults.
    In the first instance, the warnings were (in chronological order)

    -Workspace monitoring functions deactivated (mastering error). KSS15054
    - Perform mastering A5
    -Perform mastering A6

    in the second event, it showed:

    - KSS03168 {Axis} is unmastered due to mechanical axis coupling.


    I will dive in to the forum and manual to find out possible causes and solutions for these issues, but what puzzles me is that I have remounted an old tool, and the robot has been running OK for several hours on an old program.

    One other possible cause might be that this new program, due to the longer tool, has much more motion in the A5 and A6 axis than it has previously seen. Could this increase wear or inaccuracy, or cause the toothed belt to run on a section that hasn't worn evenly? I thought that the A5 and A6 encoders are on the motors, not on the axis themselves? So even with worn or broken belts, the robot wouldn't notice, or am I mistaken?

    Quote from erikD

    -Workspace monitoring functions deactivated (mastering error). KSS15054
    - Perform mastering A5
    -Perform mastering A6

    That should not happen in isolation. There has to be some other error immediately before that cluster. Mastering doesn't simply get lost without either a motion or communicaiton error.

    Quote from erikD

    - KSS03168 {Axis} is unmastered due to mechanical axis coupling.

    Which {Axis} was it? I would expect it to be A6, since A5 and A6 are mechanically coupled such that unmastering A5 will usually unmaster A6 (and unmastering A4 will unmaster all three).

    Anyway, this suggests that the place to concentrate is A5, since the implication is that A6 lost mastering due to A5 losing mastering, rather than to anything A6-specific. I would pay special attention to the cabling between the RDW and the A5 motor.

    Quote from erikD

    So even with worn or broken belts, the robot wouldn't notice, or am I mistaken?

    Probably. What I would expect would be for the wrist axes to fail a Mastering test without actually producing any Mastering errors. Once an axis is Mastered, the KRC assumes that the mechanical linkage between the servo motor and the physical joint is reliable and unchanging. A mechanical failure downstream of the motor should not typically create a Mastering error.

    Quote from SkyeFire

    That should not happen in isolation. There has to be some other error immediately before that cluster. Mastering doesn't simply get lost without either a motion or communicaiton error.

    From the screenshot that my colleague made of the HMI, right after they found the robot stopped, this was indeed the list of warnings. There were a few other warnings from two days earlier (asking for regular maintenance, which is scheduled already), but nothing else as far as I can see. I'll have a deeper look in to the error log tomorrow when I'm at the robot again.

    Quote from SkyeFire

    Which {Axis} was it? I

    It doesn't say. The error message had the "{Axis}". After the message, A5 and A6 were lost again, so I agree it would be A5.

    Quote from SkyeFire

    I would pay special attention to the cabling between the RDW and the A5 motor.

    Thanks, I will check this as well. For my understanding, the RDW is the electrical board which sits at the base of the robotarm itself, right? So damaged cable would be between the robot bottom and the motor of A5.

    Thanks again for your great help.

    Quote from erikD

    the RDW is the electrical board which sits at the base of the robotarm itself, right? So damaged cable would be between the robot bottom and the motor of A5.

    Yes. The connectors on the motor end are vulnerable to taking internal damage if someone screws them on incorrectly. I would normally disconnect the cable and wriggle all the pins longitudinally to see if any of them are floating instead of fixed.

    Quote from erikD

    From the screenshot that my colleague made of the HMI, right after they found the robot stopped, this was indeed the list of warnings.

    That is very odd. What's the history of this robot?

    Quote from SkyeFire


    Yes. The connectors on the motor end are vulnerable to taking internal damage if someone screws them on incorrectly. I would normally disconnect the cable and wriggle all the pins longitudinally to see if any of them are floating instead of fixed.

    That is very odd. What's the history of this robot?

    Looked in to the logbook of the robot today, and found an "encoder error (position encoder) (A5)"
    strangely, this doesn't show up in the warnings initially displayed, but was only visible in the logbook under diagnostics. The time stamp did match the moment where the other warnings were shown, and when the robot stopped.

    I will check the cables and connectors to the encoder. But funny enough, the robot has been running fine today, so if anything is broken, it isn't really broken but only a little bit.
    Any possibilities for this error, other than broken hardware?

    what does it mean "mid cycle"? was the problem occuring at the moment robot was contacting something rigid (picking/placing parts)?

    normally this happens if there is a violent collision, or when there is a connection loss or external interference (EMI from plasma or weld or whatever equipment)...

    maybe the contact itself was not violent (or present) but it the effect could be magnified by other factors. is the load value entered correctly? is the robot moving through singularity? what is the controller type? did you check O-ring presence on data cable X21/X31? this could produce intermittent connection even on a robot mounted rigidly. ceiling robots are not always mounted on a very rigid structure, any chance of deflections or vibrations?

    what else was happening at the same time? collecting archive should be no problem even while robot is running but same may not hold for KRCDiag. was there anything that could lead to longer processing?

    was this the only time that it happened? are you able to reproduce it?

    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

    Hi Panic Mode,

    Quote from panic mode

    what does it mean "mid cycle"? was the problem occuring at the moment robot was contacting something rigid (picking/placing parts)?

    It was traversing between two points in a ptp motion, certainly no impact. It had run the exact same program a few times before the error occured, and has done the program again after re-mastering the drive, only to stop again at a not-singular position.

    Quote from panic mode

    maybe the contact itself was not violent (or present) but it the effect could be magnified by other factors. is the load value entered correctly? is the robot moving through singularity? what is the controller type? did you check O-ring presence on data cable X21/X31? this could produce intermittent connection even on a robot mounted rigidly. ceiling robots are not always mounted on a very rigid structure, any chance of deflections or vibrations?

    Load value isn't entirely correct and was roughly estimated. That is one of the things I will look at. I will look at all connectors and wire integrity, as also proposed by SkyeFire.
    By the way, our ceiling robot is converted in a floor robot which stands on a very stable pedestal.

    It's running fine on another program, and as long it doesn't break it will run this program for some time, so it will be a week or so before I can fiddle around again with the tool and program that caused the issue.
    I'll report back when the issue has been found.
    Thanks again for the kind help. :thumbs_up:

    Quote from erikD

    Load value isn't entirely correct and was roughly estimated.

    These smaller robots can be very vulnerable to loads that seem intuitively like they should be fine. CoG is especially tricky -- your robot could be overloaded by a 5kg payload, if the CoG of the payload is far enough from the origin of the A6 flange. You did mention that your new payload is "heavier and longer" than the old one.

    Quote from erikD

    By the way, our ceiling robot is converted in a floor robot which stands on a very stable pedestal

    Wait, this robot is hanging from the ceiling now? And it was originally a floor mount? Was the base transform corrected to account for this? The robot needs to know which way gravity is pulling on it in order to correct for it properly. Normally, if this was not done, I would expect to see faults on A2 or A3, but it's a possible contributing factor.

    About the fault: is there a particular motion where this fault occurs, or does it occur randomly anywhere? I'm looking for any common factors between the occurrences.

    Hi All,
    Bump to this thread: The robot has been running another program for a few weeks as we couldn't afford the robot downtime: no issue whatsoever, which in my opinion excludes fundamental problems of the robot itself.

    I restarted the problematic program with associated tooling and hit the same problem again: robot stops, throws the above mentioned errors and looses A5 and A6 mastering. I stopped at different positions throughout the program, sometimes continued for about an hour, running the same cycle over and over again without problems, and then stopped again.
    However, I then reduced the velocity of the automatic program from 100% to 75%, and it has been working for the last week without any issue, which I believe points to a dynamic/motion control issue.

    Quote from SkyeFire

    These smaller robots can be very vulnerable to loads that seem intuitively like they should be fine. CoG is especially tricky -- your robot could be overloaded by a 5kg payload, if the CoG of the payload is far enough from the origin of the A6 flange. You did mention that your new payload is "heavier and longer" than the old one.

    The robot used to work with ~100 gram loads mounted at ~20 mm from the flange. The new tool has a 300 grams tool, with a CoG about 150 mm away from the flange. So different from the previous situation, but far away from the 5 kg loads you mention.
    Point is: the robot runs very fast: usually 100% of the max speed in ptp motion, and the robot tended to stop in the somewhat more complicated and fast motions, with large speeds in the A5 and A6 axis.

    Quote from SkyeFire

    Wait, this robot is hanging from the ceiling now? And it was originally a floor mount? Was the base transform corrected to account for this? The robot needs to know which way gravity is pulling on it in order to correct for it properly.

    The opposite: it is a ceiling robot which is now floor mounted. Proper correction hasn't been done. I 'inherited' the robot in this configuration and the problem is that it used to run just fine until recently, and changing the configuration in the software would require reprogramming several complicated programs and quite a lot of downtime which couldn't be afforded. The only impact it had so far was that you had to remember to press Z- to move up, and vice-versa.

    So in conclusion, maybe, the problem is a combination of a slightly heavier tool, faster than usual motions, combined with incorrect load data for the tool and the robot itself.
    In a few months time we'll have another robot, a copy of the current one but then with the right floor/ceiling settings. I can then tell the old ceiling robot that it has actually been standing on the floor for the past few years, and see if this solves the above issue for good.


Advertising from our partners