RSI Axiscorr not keeping up with input

    Hello,


    Robot: KR60 HA

    KSS: 8.3.42

    RSI: 3.3.5.279


    I've recently discovered some strange behavior while attempting to correct axis 1 (it also happens on other axes, but I'm trying to narrow down the issue).


    The setup is that I'm taking a digital input value and connecting it to CorrA1 of an AXISCORR block. For monitoring, I've connected the same digital input, plus the output 'Stat' and 'A1' from the AXISCORR block into a monitor.


    When I run this, occasionally it'll work just fine for a few seconds before I hear an audible clunk and/or an over torque alarm and it shuts down.


    Upon investigation, I see that the AXISCORR A1 value is not continuing to apply changes that are sent into CoorA1. It seems to drop out for about 1/10th of a second, then abruptly resumes and trying to apply all of the accumulated correction value at once. I also noticed the output of the 'stat' value goes to zero (no correction) in this same time period, but I can't discern why that is.


    Please let me know if you need any additional info! And sorry in advance for the things I'm sure I forgot.

    The trace labelling appears off. The Blue trace is labelled as being AxisCorMonn1.A1, but no such object is in your RSI setup.


    You appear to be driving A1 in velocity, not position. Is that your intent?


    Assuming the Red and Green labels are correct, it looks like you're feeding the AxisCorr object a very slowly increasing value, while the AxisCorr output remains flat until the transient event at about 8.14sec. At that moment, both the Green and Blue traces jump. I'm assuming the Blue trace is STAT, but I can't see the actual value -- it would help to see the raw Monitor data. The first three bits of STAT show the status of A1.

    My apologies; I didn't upload the full RSI image because it's a mess. I attempted to simplify by removing elements, but RSIVisual kept crashing, so I recreated it and forgot to add the AXISCORRMON object. In the full version, the blue line is indeed A1 from the AXISCORRMON block. I was surprised to see it differed from A1 from the AXISCORR block.


    What tells you I'm driving velocity? I'm intending to drive based on position, so hearing what I'm doing wrong would be very helpful.


    I'll upload the raw monitor data tomorrow. The stat line isn't visible in the screenshot I attached, but it seems to be a single bit that goes high or low.

    Quote from lennort

    What tells you I'm driving velocity? I'm intending to drive based on position, so hearing what I'm doing wrong would be very helpful.

    Keeping in mind that I haven't done RSI in a decade (and it was all POSCORR stuff, not AxisCorr), my understanding is that the CORR objects take whatever input they're receiving, and adds that input to the axis every 12ms (4ms in IPO_FAST mode). So your constant input of 0.055 to AXISCORR.A1 should cause A1 to try to move 0.055deg every 12ms, or about 4.6deg/sec.


    All the RSI work I ever did had to include a PID loop that accepted a setpoint (usually from the KRL program), and "current state" (usually from a sensor), subtracted one from the other, scaled the resulting "error" through various filters and PID computation objects, and fed the output of the filtered PID into the CORR object. And the "setpoint minus state" was set such that the CORR object would receive an input of 0 when the the correct value was reached.


    For example, I did a lot of force control, with a load cell in the end effector to control how the robot pushed against a workpiece. The goal was to achieve a nice damped curve of force/time, tuning the PID contstants to get the fastest operation without overshoot or oscillation (or jerking the robot too hard, which is really easy in RSI).

    Quote from lennort

    I'll upload the raw monitor data tomorrow. The stat line isn't visible in the screenshot I attached, but it seems to be a single bit that goes high or low.

    The RSIMonitor output CSV data, fed into Excel or something like a Python data-processing script, is the most important tool for troubleshooting RSI. The pendant display is nice, but falls short.


    Quote from lennort

    In the full version, the blue line is indeed A1 from the AXISCORRMON block. I was surprised to see it differed from A1 from the AXISCORR block.

    So, like I said, it's been a while, but the output of the CORR block is simply "how much has the axis moved while this RSI container is running" -- it's always zero at the moment the RSI container starts executing. It's basically "where is the axis relative to the start position". The CORRMON block should report the actual absolute axis value.

    Thanks for all the info, SkyeFire! From your explanation, it sounds like you were using relative mode, while I'm using absolute mode (good question, roboformer). If my understanding is correct, rather than trying to increase by the amount we're sending each iteration, it should target that amount as the full correction value. The external PID loop is being run on the PLC with that intent- slowly ramp up the value to the full amount. And as long as RSI is "following along", it seems to work great. Right up until those strong jerking hiccups.


    I'm attaching the output csv from the Monitor. It's definitely easier to see than the graphs from the TP. We're running IPO_Fast and sending a new correction value every 4ms (though as you see, it's typically the same value twice in a row). I'm just starting to tune, but I can't reliably do that when it keeps doing what its doing :-).

    Quote from lennort

    it sounds like you were using relative mode

    Yes, that sounds familiar. Offhand, I don't think I ever used Absolute mode, so I rather forgot it was an option.


    Hm... okay, so you're sending a constantly-changing absolute-position command to RSI? I'm guessing you're having the PLC monitor the real position of A1 to generate the correction?


    The final part of the spreadsheet seems to show A1 catching up with the commanded position, which ends at 0.0548. Once A1 catches up, it stops moving, as shown by STAT changing from 1 to 0 at time 8060. So far, this all looks good.


    The bad event seems to happen at time 8144. Column C changes from 0.0548 to 0 -- is that the output of the AXISCORRMON, or the input to it? If it was the input to the CORR object, that would definitely cause a jerk and error, but... C looks like the CORR output, and D looks like the input. Correct? in that case, your commands appear to be nice and smooth. I do think that having each value repeated twice might be an issue for getting fast smooth motion, but I doubt it's causing what you're seeing here.


    I'm not seeing STAT change to 3 or 5, so you haven't hit the axis limit.


    It's really strange... it's almost as if the AXISCORRMON object is losing track of the A1 position for one sample. But by 8148, it's back to what it was before. Even more suspicious, there's no corresponding spike in any other data (except Column H, but I suspect that's just Column C minus Column D?). AXISACT.A1 certainly isn't jumping, which I would expect if there was a hiccup in the position data from the actual axis. The problem seems to be limited to the AXISCORR object. I would definitely write this up and file a ticket with KUKA tech support. The RSI object have to be fully reliable, or else there's no point.


    ATM, I can only offer some semi-random things to try just to see if they help:


    Try the same RSI program, but at 12ms instead of IPO_FAST.


    Maybe build an RSI test program that does the PID internally -- the PLC just sends over the desired destination for A1, and the RSI program does all the math itself. Just to see if it behaves differently.


    Test to see if this problem only occurs when you send the same command value for some time. In that spreadsheet, the error only occurred after A1 had been stationary (STAT=0) for about 80ms. I'm wondering if there's something about being stationary in Absolute mode for too long that's causing this. Another related thing: set up your RSI program with a termination signal, and try terminating the RSI after STAT=0, but before the error occurs.


    None of this probably helps with your production setup, but right now I think we're stuck trying to trial-and-error how pervasive this problem is.

    You're correct. There's a whole bunch of external junk that gives me what the actual position should be, but ultimately the PLC generates the difference and send it to RSI. That's where the PID breaks down the total difference into little tiny chunks to send an incrementing total to RSI.


    Most of the spreadsheet shows totally normal RSI operation in action. STAT is outputting 1, indicating that it's active. The issue appears at time 8060, where stat falls to zero. Each iteration you can see the scaled input incrementing, as expected (column D). However, the actual axis correction value (column E) isn't following along, as it was previously. This seems sort of expected if a stat of zero indicates RSI is off, but nothing explains why it's off.


    When you get down to time 8144, stat goes back to 1 and suddenly the axis correction value jumps up to match the scaled input. This jump from .0548 to .057 is what I'm assuming produces the loud clunk and overtorque alarm: The robot tries to suddenly apply a large delta in a single RSI iteration.


    I like the 14ms idea. I'll give that a shot and see what happens. I suspect there may be something wrong with the robot itself though. I've opened a ticket with Kuka support and I'll report back if I learn anything interesting.

    I got a response from Kuka. The core issue is that the program I was running had non-continuous motion, which stops the motion interpolater and means RSI isn't able to run. If you can ensure you've got continuous moves within RSI, you're good to go.


    We ended up sending the 'stat' byte back over to the PLC so we could pause the correction values while RSI wasn't running. When RSI does resume, it expects the input to be exactly where it was before it paused. Not zero. This took some guess and check work :-). We also noticed that if you specify a move with a tool change, that'll cause the joint position to go to zero for one cycle before it goes back, which causes an over torque. At this point that's a limitation I can live with and I'm not looking into it further.

    Quote from lennort

    We also noticed that if you specify a move with a tool change, that'll cause the joint position to go to zero for one cycle before it goes back, which causes an over torque.

    Ah. I had a similar issue with the startup of RSI containers. Basically, for the first scan, all inputs are 0, and the actual input signals are only processed into RSI input values on the second scan. This created a violent "step" between Scan 1 and Scan 2, which would often lead to motion errors as RSI tried to react to the sudden input change (especially Derivative elements of the PIDs). I generally got around it by throwing a low-pass filter onto the inputs, and/or a "max" limiter on the CORR object inputs.

Advertising from our partners