KRC5 Micro with Agilus KR6

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.

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.

The EM8905 I/O module is only for the arm-mounted IOs. The XG12 IOs are controlled by the Interface Board, check my post from this thread. It is the same for these IOs, simply map it as all the other "normal" 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.

That is odd... Attached some screenshots how it looks in my project. I cannot see something wrong from your screenshot, but did you accidentally set a filter in the IO Mapping tab?

Quote from SkyeFire

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.

Did you try another version of WoV?

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.

Quote from SkyeFire

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. At the end i had to detach the gripper in order to jog out of this position

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.

Quote from SkyeFire

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.

Display More

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. 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. 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.

Quote from DannyDJ

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 ammo 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.