KRC5 Micro with Agilus KR6

  • Morning, all. I'm about to parachute into a new customer site and have my first experience with a KRC5, fresh out of the crate (KSS, not Sunrise). I've grabbed what I've been able to find of the relevant manuals (the X11 is very different!), but I'm looking to pick everyone's brains for any "tribal knowledge" that isn't in the documents.


    I've done a lot of KRC4 (full size), and one Agilus on a KRC4 Compact. One issue I recall from the KRC4C was that the internal valves and I/O of the Agilus would not operate until the X55 power connector was wired up. It looks like XD12 serves the same role on the KRC5Micro? Except the manual labelling looks like XD12 is only for external power -- is there no "loopback" option to power the non-safe I/O from internal power?


    It's little things like that, that are easy to know once you've worked on one, but aren't easy to find in the manuals coming at it from zero, that I'm hoping to pick up here. I'm going to need to wire up this unit, configure it, and get it fully programmed, in under a week. It should be simple, but I'd rather ask stupid questions in advance than lose time on some silly little easy issue. :waffen100:

  • As far as I know there is no "loopback" option for using internal power for XG12. If you want to use the XG12 non-safe IOs you have to wire external power to the XD12 connector.


    However, the internal valves and IOs of the Agilus will also work without wiring XD12. Configuration via WOV is enough to make them usable.

  • However, the internal valves and IOs of the Agilus will also work without wiring XD12. Configuration via WOV is enough to make them usable.

    Thank you! This is exactly the kind of "tribal knowledge" I was looking for. I was starting to look into maybe wiring the 27V circuit from XG33 into XG12.


    Does the KRC5 Micro come out of the box with that enabled, or do I need to take special steps in WoV? Or just map them like normal I/O?

  • By default it is inactive/not mapped. Open the IO mapping in WOV and under fieldbusses you should find an EM8905-1001 I/O module. This is the one for the internal valves and IOs. You can map these just like all the other IOs.

  • about agilus robot arms:


    IO in the agilus wrist are powered locally (through X21-X31 cable) and do not need X55 power.

    exception is KR3R540 which does not have in-wrist IO. it only has energy supply so used IO are external or from controller.




    about agilus controllers:


    XD12 in KRC5 is equivalent of X12 in KRC4. it is controller interface using IO module in the controller

    XG11.1 + XG58 is equivalent of X11. The thing here is that there is no input for button to acknowledge user safety.


    in case of KRC4 compact, X12 came in different variants.


    version with Beckhoff IO would need external power. normally that power would come from X55 when using local power.


    version with KUKA IOB seem to have 24V power internally routed to X12 interface so it should be possible to use it without touching X55.


    in case of KRC5 there is 24V power readily available on terminals. this is more convenient than X55 since changes to X55 required crimper and maybe pin extractor.

    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

  • Well, I'm on-site, and things are... odd.


    I've connected to the KRC5Micro through WoV, and located the EM8905 module, but when I try to map it, no "mappable" signals show up in WoV. Same for the IFB-STD board.

  • Hm... some more issues. I uploaded the active Project from the KRC5, made a change to the Cell name, and tried deploying, and got this:


    I'm not sure what the MADA issue could be -- the robot is jogging correctly, and there are no obvious errors in the $MACHINE.DAT file. The customer did have to change the $TRAFONAME to achieve that, from KR6R700_2 C4SR 230 to KR6R700_2 C4SR in order to achieve that. The new $TRAFONAME matches the robot label, except that the label doesn't make it clear if there needs to be an underscore between 700 and 2.


    I suspect the Bus error is related to why I can't get access to the I/O to start mapping.


    ADDENDUM: Found another thread where it was suggested that these errors come from using WoV 6.0.5 (which is what I had). Downloading 6.0.24 now to see if that helps.

  • Did you try another version of WoV?

  • Okay, stupid question: I managed to jog my Agilus into a collision that I can't get clear of. Spending 10 minutes just jogging in the opposite direction produced no motion -- the torque fault trips before I can even get 0.01mm of motion to relieve the pressure.


    I've never had this problem with the Big Iron -- they would always jog clear... eventually. But this little bot is completely stuck. Any special tricks for resolving this on a Agilus?

  • Did you try to deactivate the collision detection? There is a checkbox under the collision detection tab named "Override collision detection" which allows you to deactivate the collision detection for jogging.

  • Okay, stupid question: I managed to jog my Agilus into a collision that I can't get clear of. Spending 10 minutes just jogging in the opposite direction produced no motion -- the torque fault trips before I can even get 0.01mm of motion to relieve the pressure.


    I've never had this problem with the Big Iron -- they would always jog clear... eventually. But this little bot is completely stuck. Any special tricks for resolving this on a Agilus?

    Hi, I had the same problem once with Agilus robot, somehow due to tight and small space in the cell i managed to jog the sharp corner of my gripper into robot's arm. :wallbash: At the end i had to detach the gripper :uglyhammer2: in order to jog out of this position :wallbash:

  • Yeah, I ended up loosening the robot's mounting bolts to its base and letting it "rock" to relieve the pressure (and re-tightened afterwards, of course). After which I had to re-teach my Bases and tweak several points. :grinning-smiley:


    But at least I remembered to teach Bases before I got deep into programming positions, so it wasn't a total loss.

  • So, I had the collision problem again. This time, during an automatic run, because the part the robot was trying to pick had a damaged upper surface and the robot "hit" it maybe 2-3mm above the programmed position. And again, jogging the robot clear was impossible, and we had to loosen the mounting bolts, then re-teach everything. There has got to be a better alternative to this. The Agilus seems really hypersensitive to this kind of situation, compare to most KUKAbots I've worked with over the years.


    A few observations on the KRC5Micro and KSS 8.7.3:


    1. Going into EXT mode, the drives came on automatically, without $DRIVES_ON being pulsed. The only thing that seemed to break this behavior was if the robot suffered a safety fault (E-Stop or Operator Safety) while in EXT -- after that, I had to pulse $DRIVES_ON to get the motors on again, or go back to T1, get the motors on using the deadman, then switch back to EXT, after which the drives would be on automatically. AUT seemed to behave the same way, from what limited experimentation I had time to do.


    2. Tool and Base data don't seem to be the sole province of $CONFIG.DAT anymore. I had a problem where my WoV Project got corrupted, and was hand-loading files from a backup into the robot (couldn't use Restore for various reasons), and ran into an issue when I loaded $CONFIG.DAT -- the robot threw a fault that I failed to write down ("consistency error"?), and the values shown in the Tool/Base configuration menu did not match what was in the restored $CONFIG.DAT. I had a serious time crunch, so instead of digging into the issue, I just hand-typed the values from the good $CONFIG.DAT into the Base/Tool menu, and that fixed things. But I'm wondering what's changed in the way "custody" of TOOL_DATA, BASE_DATA, and LOAD_DATA are handled.


    I will say, though, the new Tool/Base config menu is nice, and offers several bells&whistles that I've been wishing for (and ABB and Fanuc have), like moving to the recorded points that set up the Base originally.


    3. The default SLIN/SPTP motions in the ILFs are a bit... odd. Most of the time, they worked perfectly well, but I ran into some strange hiccups once or twice, especially with CONT motions. One particular example, I had a SLIN leaving a Pick position, followed by an SPTP to move clear of the station. And if I set the SLIN to CONT, the robot would "bobble" at the corner -- basically, move to the end of the SLIN, sort of "jiggle" a bit (as if the CONT path was being calculated as a small ~10mm "knot" at the transition), then continue into the SPTP. A few other CONT motions would act like non-CONT motions (no ARP-breaking logic in between the motions), or would have strange "pauses" mid-path. I didn't have any time to dig into it, so I just made the motions that were behaving oddly into non-CONT and kept going (no cycle time concerns on this robot).


    I also had some programs that mixed ILF S-motions with hand-coded S-motions, and it seemed like I got some odd blending behaviors sometimes using C_PTP or C_DIS to blend into an ILF S-motion. Probably something I was doing wrong, as I really don't have much hands-on experience with the S-motions, but as I said, I didn't have time to really dig into it.

  • i was finding some odd things too. unfortunately things tend to present themselves when one does not have enough time to investigate.


    an example was a small block of KRL code mixing LIN and PTP and approximation using C_DIS only. during testing it was found that it would occasionally complain that approximation value for PTP was not programmed. well duh... i know it wasn't... but i never used C_PTP in this program and both LIN and PTP should be fine with C_DIS. but there is no arguing with the robot so i had to add value to $APO.CPTP as well so it would shut up.


    but one of the most annoying things i run into is robot movements when jogging. for some reason TCP would wobble around, sometimes good 2mm before moving in commanded direction. at first i thought it has to do with load and brake release but that was not the case. the wobble occurred after jog key is pressed even when brakes are already released. stopping jog would freeze robot in whatever point was reached during wobble. so using low jog speed and briefly pressing the same jog key would have robot TCP bounce around in any direction. not happy with that at all...


    all right, so maybe it does so initially but when key is pressed long enough it would eventually continue moving in the correct direction...?


    well, not always...


    couple times it continued traveling in wrong direction while the jog key was pressed. letting go and then pressing the same jog key again made it move correctly...


    and it is not wrong jog key or the 6D mouse either (confirmed). so i thought perhaps smartPad had defective jog key membrane or loose contact. have not seen the same issue on other two robots in time i was there but this did happen on same unit couple of times. to check keys i put a little scan routine into SPS (with IS_KEY_PRESSED) but all of the smartPad buttons appear to work perfectly even as i activated them in a different order, different smartPad orientation or tried applying different pressure.. after swapping smartPads issue remained with controller so my gut feeling is that this still could be a software issue - just not easily observed.


    whatever the reason i was really not happy with that. i was not going to risk a collision so remaining few points were manipulated numerically.

    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

  • In my case we have centering pins in the grippers and in the base of the robots, so no reteaching of points was needed afterwards.

    As i can remember, even watching the increments and position values on the axes on actual display didn't show any robot movement, while trying to jog out of this position. :wallbash: But i agree with you, there should be some nicer way to fix this problem, rather then dismounting grippers and robots(maybe opening the motor brakes manually), just can't imagine dismounting and mouting the bigger and heavier robot. :hammer1: but there at least at the end you can use release device on motors on bigger robots, but even that i think it is not possible on a new robot like IONTEC.

  • In my case we have centering pins in the grippers and in the base of the robots, so no reteaching of points was needed afterwards.

    that's the way to do it


    bigger robots have most of the motors accessible so brake release could be done in different ways, even on a single motor. there is a brake release for Agilus too but in this case one cannot release brake to single motor. brakes are internally parallels into two groups - Axis 1..3 and Axis 4..6.


    the real brake release from KUKA has batteries and it can be used even if no AC outlet is nearby. But that means one must maintain battery and to me that is a drag specially when one considers how rarely such device would be used. Imho it would be better to add necessary connectors to an old laptop power supply, and add enabling switch. in rare event this is used, it is not a big deal to bring extension cord... it is not like robots are installed in the middle of the desert.


    I was thinking more along something as shown below. small box with selector switch, two LED indicators and all cables connected to it. cables should be sufficiently long (1.5 - 2m) so that one can be in safe and comfortable position. Selector switch would be used to select brake circuit to release. Of course one would need to be very careful with thing like this and have robot properly supported.

    this too could be battery powered but i would rather use one for cordless drill. 20V is enough to release brake. the box here could be tiny, something like this and it would easily fit into any toolbox or even laptop bag. the one from KUKA looked huge (more like amo box).



    and there should also be a diode to clamp the spike when button is released. brakes are inductive load and store a lot of energy that need to be dissipated.

    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

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