serzulu XD12 and XD12.1 are internally connected. The manual states you can input power on either XD12 or XD12.1. The additional connecter is provided to daisy chain the external supply via the subsequent plug terminal to additional KRCs.
The only thing the manual does not help to identify is the physical numeric identifiers on the plugs for terminals 1,2 or 3,4 and they are not labeled on the plugs. (At least my plugs have no visual indication of the terminal numbers)
Thanks for the quick response. I will contact kuka for the option. 
Software: KRC V8.3.33
Controller: KRC4 NA UL
Robot: KR22 R1610
Option Packages: Profinet ProfiSafe V3.2.2, SafeOperation V3.2.3, HMI Easy V?
Note: The HMI Easy option is pending purchase/licensing but irrelevant to this topic
I am recommissioning an old robot for integration with an injection molding machine (IMM).
I am using SafeOp to assign a protected workspace via light curtain input for operator insert loading onto a nesting plate.
I will be running the system in AUT mode using HMI easy for user control
A Siemens S1200 PLC is used as Profinet master to establish coms for control of a Turck TBEN IO block and SMC EX260 SPN3 Valve bank. (end of arm tooling function)
Question:
I cannot access the menu to configure multiple SPS programs using the teach pendant. Is this a limitation of the software version since I am recommissioning and older KRC?
I have created more .sub programs using WOV however I assume the only .sub running is SPS.sub since it is the default routine and I cannot configure the new ones to run?
When I press the submit interpreter softkey (green 'S' top center of KTP) I only get the options to Select/Start,Stop and Deselect the Sub routine. On newer models this softkey opens a configuration window allowing the user to assign up to 8 .sub routines which run parallel to the robot interpreter. I tried navigating the KTP to Configuration/ SUBMIT Interpreter and still only get the options to Select/Start, Stop and Deselect the Sub routine.
I have tried this on both Expert and Administrator user groups
I will need multiple SPS programs for IO control via HMI easy/program selection/etc. so that I do not bog down the SPS.sub program.
Let me know if any additional information is required.
Thanks in advance.
Final update: The issue seems to derive from a couple different areas.
OPC communication timeout
We encountered multiple OPC communication timeout errors which result in data loss during the timeout. Our C# programmer increased the timeout duration on the IPC to account for this.
Reading/Writing through OPC at the same instance
It seems that writing to variables through OPC at the same instance the variables are updated/read can result in data loss. It appeared to resolve the issue by isolating the conflicting variables into separate dat files and reorganizing the code so that there is no longer a read/write request at the same instance.
Take this information with a grain of salt as our specific KRC-IPC integration may not be %100 correct at this point. This is our first integration using OPC communication for Auto-External control.
I wish I could figure out how to post the picture of the logbook for reference. I made a mistake in my original post quoting the warning message as "2797". That number was the logged event instance where the system message number is "108".
It appears the most recent notification was 5 minutes prior to the dynamic breaking failure and 10 minutes after, once we began tending to the issue.
We realized that we have some variables which are being wrote and read from OPC at nearly the same instance, inside the same .dat file. We are currently testing the system with these variables isolated into separate dat files. We have been running for 4 hours now without fault.
Updates to follow as testing continues. Thanks for your input.
KR3 R540 / SEL
KRC4 UL Compact
KSS V8.6.5
Hello, thanks in advance for your interest in this topic.
We are running a KR3 from an IPC using OPC to enable Auto External, and pass coordinate data/commands to the KRC. The robot will run for about an hour or 2 autonomously without failure. Eventually the robot stops without any error on the message bar. The Drives are still enabled (green I at the top of the TP) however the program is stopped (red R at the top of the TP). I look into the logbook and find the warning message (#2797) Dynamic Breaking Active at the point of failure.
Note: The robot usually stops at the same point in the program and there is no other fault, warning or even notification within 3 minutes of the failure.
I can easily resume the program by pulsing the $EXT_START system variable.
Has anyone ever ran into this issue before, or have any insight as to why/how this warning may have arose?
I am guessing it has something to do with the OPC server timing out or possibly sending null to a system variable which stops the program? The issue seems too consistent but I do not know what else could cause this, unless it has something to do with the IPC software we are running.
Is there a system variable which stops the program but leaves the drives enabled if it changes state during production?
A cheese fix for this could be to monitor $PRO_ACT and pulse $EXT_START whenever we drop the run state however I would like to understand the root cause for this. If data is getting lost we run the risk to create larger problems.
I am having trouble uploading an image of the TP logbook for reference, otherwise I am happy to send any pictures that are required and provide any additional information.
This problem has been solved and I wanted to update the forum in case anyone else has a similar issue.
It turned out that the KRC5 dualcab AC has a transformer which can be tapped for different input voltages.
Two separate manufacture labels on the cabinet specified the supply voltage was ~3 480VAC which was supplied to the cabinet. However the transformer was tapped for ~3 600VAC input.
The transformer was rewired and the issue has been rectified. There is no sign of damage to the KRC5.
Thanks for everyone's input
Thanks for the Reply, it makes sense the RDC data should not disable the drives, however I cannot come to any alternative conclusion.
Since I made the change to the Controller name from Factory "0" to "PolyNovaKR20" and saved the data, I regained power to the drives.
I opened WorkVisual, browsed for the project and deployed with the new controller data. Since then, I am able to Shut down / restart the controller with no issue.
Hello, I am having a Drive power issue with a KR20 Robot and can't seem to rectify it on my own.
Posting here as it is the most directly relatable post I can find.
Robot: KR20 R1810-2
Controller: KR C5 S6 AC
Cabinet: KR C5 dualcab AC
Background:
We have been commissioning this robot for the last 3-4 weeks and it arrived new approx. 2 months ago. Originally, I forgot to plug in the backup battery 24V power supply for the UPS circuit. Since then it has been plugged in and functions now. Prior to this, the controller had been shutoff multiple times without the proper soft shutdown procedures. Luckily, we have not had any issues with this until today.
Note: The safety has not been wired so we are using startup mode to configure and test our programs.
Problem:
There are no errors when power is applied to the KRC5. When I put the robot in Start-Up mode and press the enable switch there is no power to the drives and after a 3 second delay I get the acknowledgement error
"Charging Failed Power Supply 1"
I am having trouble posting images of the pendant screen for reference however there is not much more than the error above.
Note:
I tested the 3~ 480 power supply and it seems to be fine.
Since adding the UPS battery the KRC5 shuts down properly.
The robot was running fine in startup mode for the last month without this error occurrence.
Solution:
As I went through some basic troubleshooting to ensure that this post was relevant and accurate I actually solved our problem.
It seems that the RDC data was most likely lost, corrupted or factory reset during the hard shutdowns without the UPS. Which is funny because the program data was still intact? I noticed that the startup wizard was no longer completed as it was during original power on date. I simply renamed the controller to its original name and saved the RDC data.
I now have power to my drives again. Hope this helps someone else with similar issues.
Updates:
Adding an alternate FDAT/Base data for the offset tools seemed to increase our pick accuracy. The base data x and y coordinates only changed by <1mm, mainly along the y axis.
Upon closer inspection it seems the PC is triggering the feeder bowl to bump the parts at the same time it takes a picture.. Obviously this is the cause for our variance in pick accuracy. Even with the pick area away from the bump action the vibration along the bowl surface causes motion in the smaller/lighter parts.
I think we are on the right track from here. Thanks for the support.
Thanks for the quick response and input panic mode.
Just to clarify,
We calibrated the tools using a sharpened point held at the TCP and mated it to a stationary point fastened to the base. Using the 4 point calibration method the error value was measured as <0.8mm once the calibration was complete. After the calibration we rotated the tool around the axis A,B,C although it was not perfect the rotations seemed to be 'good enough to proceed'.
As for the Base we used the same method of sharpened points held in the TCP and fastened to the base. We did the first calibration using the 3 point base method as close to the vision origin points as we could without compromising the integrity of the light source. We did this using pixel accuracy to locate the base point along the +X axis, then teaching a point along the +XY Plane for the Z reference. Using the pixel values we bypass the perspective correctional scale to a contour TCP value.
(I specify this because we tried the calibration both ways and the pixel values before correction prove to be the more accurate approach)
Once the Base is calibrated using the 3 point method. The origin point (X0,Y0) of vision does not correspond with the origin point of the KUKA base we just taught. To correct for this we have used the numerical input method to offset the (X and Y values only) new base until the KUKA coordinates equal the vision coordinates at the desired pick location.
We did our perspective correction using a rigid laser cut aluminum plate which sounds great but admittedly has a slight warpage. As the parts have multiple different geometries, we split the difference for pick height when calibrating vision perspective correction.
I suspect that there is an accumulative stack of error from all the slight variances in parts, vision, grippers etc. which is the cause of our problem.
My question is, does the theory for this calibration method sound correct? Have we overlooked something or is it most likely the result of oversimplifying a complex pick and place system?
For the time being,
I am attempting to create an alternative base which works for the offset tools and developing some logic to adjust the FDAT according to the equipped tool during the pick, hope this works.
I will update my findings as the project continues.
KRC4 UL Compact (no option packages)
KR6 4700-2
Baumer VCXG13M (Camera) with Vision Q400 software for data analysis
PC (EIP Master) with C# program to interpret vison data and send coordinates to KRC4
Our system requires 3 separate end of arm tooling using pneumatic automatic tool interchange to pick and place 21 different parts with unique geometries.
Note: The separate EOAT have 2 unique geometries. One straight gripper with just z offset and 2 similar grippers with an X,Y,Z offset. The offset grippers are copies of each other with only the jaw width as a deviation. For that reason I tried to simplify the programming by grouping the offset tools together as they have nearly identical TCP's.
I have calibrated the TCP of the tools using 4 point method and I do not have any error >0.8mm
I have calibrated the Base using the 3 point method as accurately as possible, drove to some pick coordinates, then offset the base x, and y coordinates using the numeric input method in hopes to align the KUKA and vision origin points.
Note: Vision provides a X,Y,A coordinates with 2 decimal point accuracy. The Z,B,C values are hard coded depending on the equipped tool.
I have developed a function to transform the rotation angle 'A' so that the EOAT stays within +/-180 degrees.
So far this method works for 1 (the straight gripper) of the 3 tools reliably. However, when we switch 'recipes' to a job requiring an offset tool, we begin to see inconsistencies between the 'calibrated' pick coordinates and the actual location of the part.
These variances can measure up to 2mm from the actual part location while other times the picks are spot on. This variance will not suffice.
Note: The variance seems to have somewhat of a consistency depending on the part location relative to the pick space. Could this be a result of a poor perspective correction from vision? Is a perspective correction even required if I used the raw pixel data to calibrate the Robot base?
I have repeated the calibration methods multiple times over and continue to get the same result. Have I overlooked something? Is there any way to increase the accuracy of my Tool and Base calibration methods?
If you require any snippet of code, pictures, additional information etc. I will send it for reference. Any information or documentation on the subject is much appreciated.
