KRC2 External Axis strange behaviour

    Hi all,

    Wonder if someone might be able to help or has experienced something similar before with some strange behaviour of one of our Kuka external axes.

    Firstly a few details on the setup. We have a KR240-L180-2 robot cell (refurbished unit) installed by a 3rd party robot integrator. It is the KRC2 ED05 controller and we have KR C V5.4.14 (2008 release) software. There is an additional box with a few buttons to run the system in Auto mode. This was setup with 2 external axes (synchronous motion, i.e. all 8 axes are positionally important to each other) which were originally both the same drive and motor (KSD1-32 with ME_228_180_30_S0 motor 1FK7101). These will be attached to other systems we have designed, but at present they are just wired up, but not actually mounted on anything.

    However we wanted to change one of the external motors (Axis 8 / E2) to a smaller unit as it goes on the robot head (tool) and needed to be much lighter and we didn't need much torque / power. So we got a smaller MG_16_60_42_S0 / 1FK7034 motor (from the same place the robot came from) as well as a KSD1-08 drive. I got some instructions from the integrator on how to change the drive and what settings to change. We swapped the KSD1-32 for the KSD1-08 and connected the cables as before in the cabinet.

    We were then advised to change:

    • $SERVOFILE[8] to "KSD_08_ME_S7"
    • $CURR_MAX[8] to 8.0
    • $RAT_MOT_AX[8] to our 15:1 ratio based on gearbox and belt that this motor drives

    We then tried to jog the robot and no matter which axis we tried to jog (A1-6 independent or E1 or E2) the only axis that moved was E2 by a few degrees before an error message appears and power to the drives was cut. I have checked routing for power and signal cables for the two external axes and they appear to be correct.

    Since that we've done some more research and dug out various manuals and realised there are a lot more settings that need changing and that in fact a slightly different Servofile is recommended for this motor. We have now set all of the settings for this motor contained in the "Kuka Motor Data V4" Issued 16/02/2010 manual. This is $SERVOFILE KSD_08_ME0_S7 as well as the various currents, factors, brake settings etc. For the 6off load specific data (G_VEL_PTP etc) we have currently used settings from the Axis 6 motor of a KR16 or the default values as a starting point. Later we plan to dial those in with the oscilloscope function.

    However at present we still have exactly the same issue, whatever axis we jog, Axis 8 / E2 is the only one that moves and we get the error / cut out.

    We have now disabled E2 by reducing $EX_AXIS to 1 and removing the details for $ET2_AX and the rest of the system works. Robot moves and is joggable, E1 axis all good too, but we do need the additional E2 axis for the system.

    I have included some images to show control box and errors.

    If anyone could help point out what we have missed that would be great? Or have we potentially damaged the E2 motor by trying to jog with some of the previous settings from the KSD1-32?

    view?usp=sharingview?usp=sharingview?usp=sharingview?usp=sharingview?usp=sharing

  • Fubini December 3, 2024 at 3:06 PM

    Approved the thread.
    Quote from mr_roboter

    And error / setup photos. Apologies some got chopped off.

    You can scroll up in the message window to show the "chopped off" errors.

    This might work better using the Axis Configurator tool (which should be available in the config menu) rather than modifying the MADA files directly. The tool should be available in KSS 5.4, I think. I know it was under 5.6.

    The "velocity monitoring" error suggests that the motor is failing to move as intended. It might be a good idea to run an Trace on the commanded and actual to see how they compare. My first thought is that the E2 motor is trying to accelerate at an impossible rate.

    Hi SkyeFire, thanks for the quick reply.

    After manually setting all the settings in $machine.dat we then did find the Axis Configurator and also tried setting everything through that, but unfortunately it was the same behaviour.

    The thing that seems most odd is that E2 moves even though we're not asking it to move.

    Thanks for the pointers, I will have a play with the oscilloscope and see what that reveals.

    Thanks Andy

    Quick update.

    Last night I re-added the E2 axis through the axis configurator and discovered that one of the proportional gains $G_VEL_PTP looked too high, I think it was set to 90. I changed it to 25.

    Now I can jog all the other robot and E1 axis without E2 jumping in and tripping things out. I still can't yet jog E2 without getting an error, but this feels like progress, so I suspect it is these load-specific settings.

    Current $machine.dat attached

    Solved (for now at least).

    It was the proportional gain settings $G_VEL_…

    Brought both of those down to 10 and it all behaves and can jog all the axes.

    Clearly will need to tune these with them attached to their loads.
    Thanks for the pointers and hope this helps anyone else who has this issue.

    Quote from mr_roboter

    The thing that seems most odd is that E2 moves even though we're not asking it to move.

    All 6 axes of the KR energize together, even if you're only moving one. And since your E1 and E2 are configured as part of the KR brake group, that means that any time any axis is going to move, all 8 axes switch from brake holding to servo holding. That doesn't explain why E2 tries to move, but:

    Quote from mr_roboter

    Solved (for now at least).

    It was the proportional gain settings $G_VEL_…

    Brought both of those down to 10 and it all behaves and can jog all the axes.

    This does explain it. The P gain was set for a physical condition (larger motor, heavier payload) than the new setup, so the servo control was trying "too hard" to hold E2 in position. Even when the motor appears to be stationary, it's actually undergoing constant tiny corrections to its position (that's the hum the motors generate). With the high P gain setting, the control was making those corrections with too much force, leading to the axis oscillating, probably with increasing amplitude, and quickly exceeding the error limit.

    The Trace function probably would have shown this. And it'll be critical when you go to re-tune the P and I gains after you attach the actual working payload. Standard practice is to inch up the P gain until you start to see the oscillation, then tweak up the I gain until the oscillation damps out, and repeat that until you either hit your target performance or can't damp out the oscillation any more (in which case, you back the P gain down to the highest level that worked).

Advertising from our partners