Sorry, I don't have experience with KRC4 systems, I can't tell without looking at it first(physically).
Posts by Spirit532
-
-
Looks like it's a permission issue. As hermann said, application signing may be enabled. Try booting Windows into safe mode(by plugging in a monitor, keyboard, and mouse - no way to do it from the pendant) and installing from there - you'd be elevated, perhaps it's one of the weaker certificate enforcement policies. If that doesn't work, it would require some definitely warranty-voiding OS tampering to install third-party software.
-
There's never enough pendants for robots
I wonder, where do they all vanish...I'm still trying to find one at a reasonable price, but the last seller tried to disappear with my money without shipping anything, so it's not going too well.
I suppose someone with a pendant and some electronics experience could help as well - sniffing the CAN bus on the physical layer shouldn't be too complicated. -
-
So since the KCP2 pendants are becoming an increasingly expensive spare/replacement, and because I'm an electrical engineer with a lab at my disposal, I've decided to do something a bit on the extreme side.
I'd like to reverse-engineer and (almost) completely emulate the KUKA KCP2 pendants, in their entirety. Internally, they're odd beasts - they have two logically separate(but physically one) connections to the digital ESC card, which is a CANBus network configured in an extremely odd ring topology. The pendant and ESC board communicate with a series of packets that describes the status of all the safety circuitry(integrity of the ring, dead man switches), as well as two additional layers - one, between the ESC and the MFC in terms of hierarchy, where the physical keys(drives, estop, +/- axis keys, space mouse) are, and the highest level, which is transferred through the MFC card up to VxWin(a proprietary KUKA version of VxWorks designed to run concurrently with Windows) and actuates the softkeys in the HMI.The display is connected using a proprietary protocol based on obsolete AMD TAXIchip technology, which is driven by an incredibly abused, but nonetheless standard CHIPS PCI graphics adapter(gotta give the German designers props, they managed to make it do what it was never supposed to). I have deemed this portion of the KCP system unnecessary to emulate, because replacing the expensive and very easy to kill KVGA card with a standard AGP, PCI, or even ISA graphics adapter gives automatic boot priority to the video output, meaning you could use any regular VGA display and retain 100% of the functionality, with none of the dangers, expenses, or mess - aside from, maybe, not being able to use an actual pendant due to the aforementioned proprietary protocol.
This project is to emulate only the pendant - not the entire safety system(though that, I suspect, would be just a few bytes away). The goal is not to compromise safety, but to let people with incomplete systems run them headless - to be able to turn drives on and have a third-party dead man switch without spending thousands of dollars. How the user implements it would dictate the overall safety, but I see no reason why one couldn't replicate the pendant functionally, just not aesthetically, to maintain complete safety(with estop, deadman, and drives control) at the cost of liability. In some situations, extreme safety measures aren't required - for example, when a small robot is physically unable to interact with and damage items, or reach and harm humans.
If you'd like to help, there's only one thing I need at this moment - a KCP2 std. ed05, with the part numbers of 00-130-547 or 00-131-239. I am almost certain that these particular pendants are easily converted into any other KCP2 variant, ed05 or otherwise. I'm unsure whether the more modern ed05 VKCP2 variants are convertable, but those could potentially work as well.
If anyone has a spare of either one of those part number pendants, please let me know.
-
Can you expand on this?The issue lies with the peripherals(MFC/KVA cards) and BIOS. If the distribution you're booting tries to communicate to them, which it may(for discovery or other purposes), you can have a number of funny outcomes since neither unit is expecting any data other than the kind it's designed for. I've had it hang cold once.
It's not a big risk, but it's something to avoid as good practice, because removing the hard drive is also going to speed the process up quite significantly(when you archive the image at runtime).
-
Booting Clonezilla on the controller is likely to cause malfunctions. You pretty much have no other choice.
The only way to do it safely is to take the hard drive out. It's usually held on with two snap clips, there's no need to disassemble the KUKA cage.
-
Never run Clonezilla on the controller itself, you may cause BIOS conflicts. Extract the hard drive, plug it into a native IDE port of another machine(no IDE->USB adapters, as that can be unstable).
The host PC should have no other drives connected to it. I boot Clonezilla from a flash drive, and dump the existing drive also onto a second(separate) USB flash drive. Restoration goes fine as well.Use the "dd" method when cloning, partclone is likely to fail. It takes longer, but is much cleaner. Also remember to leave the compression on default(gzip IIRC), otherwise you'll be stuck with a large file. Mine, after compression, ended up being about 1.2GB.
-
If no registry setting exists that mentions "DisplayFlags", something is very wrong with your controller, and you might require a clean re-install.
See if you can install the driver for KVGA again, perhaps that can fix it.Image your drive with CloneZilla(full "dd" clone, not partitions) before you do that if you decide to try, to have a complete backup.
-
(except, possibly, the KR3s, which were re-labelled Denso or CRS robots with kludgy modifications)My KRC3(e?) with a KR3(the CRS kind) has both the floppy drive and the CD drive.
So, no exceptions at all.
It also runs WinXPe with a security update on top of it. Both are present in the KUKA software box/folder that came with my controller. The MADA is still supplied on a floppy drive.@OP
What I would do is reinstall an IDE CD drive and try that, as it's more likely to work.
If you don't mind risking it, go into the BIOS, enable USB, shut down cold(important!), plug USB drive in, boot into BIOS again, and select it as the boot drive. Exit the BIOS(F10+save), see if it installs.
The installation disk for XPe is fairly standard, and you may need to apply the security update that comes with the robot.Note: Before doing all this, I highly recommend you image your hard drive with Clonezilla, using the "dd" method and full copy(not partitions). I managed to kill my controller twice now, and both times I was saved by restoring the cloned drive image.
-
Switch to Expert or Administrator mode, both should have "kuka" as the default password.
If that fails, try editing the registry manually.Winkey+R, run 'regedit', look for either this:
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Chips\Device0]
Or this:
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Video\{1D463511-CE9C-4ED6-BF8E-DA9D988357A0}\0000]
Set "DisplayFlags" to 3 (3 is KCP+Monitor). The image on your pendant can degrade in quality.
-
I thought that there is some sort of hardware or software setting that would let you switch the robot from T1 into auto without the pendant, but shorting the wires on the ESC board(X4 connector) responsible for the switch has no effect, so it must be disabled somewhere.
The video signal is a proprietary serial connection from the KVGA via a single differential pair, which is not possible to connect to using a regular VGA monitor.
The X11 contacts are indeed shorting them, but I guess they're still functional, since they do only start heating up when X11 is there.
And as far as I can tell, there's no software or hardware RDC equivalent. There are 4 boards inside the robot: The board at the bottom, near the Harting connector, serves as power and signal breakout(don't see much else besides a few LEDs). Then there's two servo drive boards, one in the waist(A1/A2 joint), one in the wrist(one side of A4). The last board is a power distribution and relay board that sits inside the waist(also A1//2).
Inside the controller the only custom board is the MFC2 ISA card with a DSE-IBS board on it, and that board connects directly to the robot via two RS-485 pairs, but they're also described as RS-422 in other places(electrically similar). The electrical repair manual says that they're actually an Interbus-S(no idea what the -S is) connection, but I am unsure yet. I'm currently working with someone that has a functioning original CRS F3(not re-labelled, but identical) to reverse-engineer the protocol.
As for the pendant... well, I'm basically out of options at the moment, as nobody will give me a reasonable price for an old, beat-up KCP2. Everywhere I contacted they say that they don't have KCP2s with broken displays and 6D mice(which I really don't care about). I'm open to offers on this, but I doubt I'll have much luck any time soon.
-
This KR3 is the older re-labelled Thermo CRS F3 version, the newer KR3 Sixx is a Denso.
I was under the impression that since this robot has a rack mount and was running in a factory, it was headless(and the seller said there was no controller with it, only one on the factory floor).
What worries me about X11 wiring is that when I plug the jumper in, both the diodes and optocouplers next to them get really rather warm(~80-85C), which is a very uncomfortable(but not fatal) temperature for silicon.
274 and 275 is... odd, since the controller definitely knows what robot it is, and all the data seems to be there, but I have the original floppy - would it be worth trying to copy the MADA over from that? I've never done it, so I'll have to read up more.
Pushing the "help" softkey in HMI mentions something about calibration, not mastering.53 is unknown to both me and the KUKA support people(not Augsburg though, got a local branch), but I'm going to assume it's something to do with the A4/5/6 drive, but with that said, the drive is fully functional and all error/warning fields are 0 in the DSE-RDW tool after mastering, so I think it may go away once the rest is solved.
Regarding 1, 23, 208, and 310 - can the ESC board fail so catastrophically without the pendant, with the Safetycircuit tool not being able to initialize at all?
-
More information:
After installing both batteries, backdriving all the robot axes into the mastering position and remastering the robot, I have managed to alleviate the "Dynamic braking active" message that popped up every 3-5 seconds, and I am only left with this list of blue "(!)" messages:
Code23 KCP Prototype 274 Check robot number 275 Set robot number - program robot name 53 Output state mismatch PM2 (my note - this is the A4/5/6 drive) 208 Safety circuit has detect an error. Use ESC-Diagnose for further information. 1 EMERGENCY STOP 20 External EMERGENCY STOP Pressed 310 Safety circuit for drives not ready 200 Drives Contactor off
Everything points to needing a teach pendant - is there any way to avoid having to buy one? Primarily because I can't afford to dump $2000 on a pendant.
-
More info:
With X14 plugged in, and X11 plugged in, the optoisolator section gets really, really warm(80C-ish):Without the plug, but still with X14, only two optoisolator + resistor pairs get hot(62C):
The 7805 in the top left corner is outputting a stable 5V, 1.6k between ground and output.
Any clues? -
Some progress: The power supplies at the top of the board, including the 78M05 linear regulator and 34063 switching converter are getting no voltage.
Using a thermal camera I found a single hot(52-53C) resistor(R116), next to A2/X10:There doesn't seem to be a very constant voltage across it.
Could the ESC be not switching on because there is a backup/UPS battery fault(it's missing)? -
Hello,
I'm slowly progressing in my repairs of the KUKA KR3 robot with a KRC3(ed05? Made in 2007) controller, but I have encountered an issue I am struggling to fix.
When I boot the robot up, there are a few errors I am seeing that I would like to fix, but the two that worry me most are these:When I run Monitor -> Diagnosis -> Safetycircuit, instead of the normal window I get this:
I have no idea where to begin looking at this issue, because there isn't anything in the manuals specifically related to the ESC board.
To further assist with the diagnosis, here is more information about the controller and robot in screenshots, text comments under images:
(KR C V5.2.15, GUI 1.2.32.0 B74, Kernal KS V6.74_39, DriveBus item #1 PM 2.24)
(KRC 3, #KR3 C3A FLR, No position accurate robot., 7123 hours, 6 axes, 0 external axes, all versions V6.6.0/KUKA5.2, DriveBus item #2 PM 2.24 )
(Windows version 5.1.2600, XPe V1.1.0 Build 10, BIOS version KUKA Roboter GmbH SY-7VBA133U/K V1.4.0/KUKA1030, DSE SW version 4-0, Processor Freq. 59MHz, Version C32)
(No options installed(?), MFC2 SW Version 4)Launching the DSE-RDW tool shows that there's no data on the ESC diagnostics status and state register, and only ESC1 has some data:
On the hardware side, the backup/UPS batteries are missing(on their way), that fault is signaled in the log.
The MFC board seems to be functional, as is the DSE board - I can open up the drive bus section in the DSE-RDW diagnostic menu, the drives show up there and provide realtime encoder and voltage stats from the robot when I release the brakes(by pushing the 3 buttons on the robot body).I have checked all the fuses in the entire controller, reseated most connectors(including the cards themselves), everything should be fine on that front.
All supplies except UPS(shows fault, no battery) and 76V(servo supply voltage, just turned off since drives aren't on) seem to be fine, but I don't know if there are any separate supplies on the ESC board I should be checking.
The ESC board is a "KUKA ESC CI2 V1.20 00-112-112".
On the ESC board itself, two LEDs are glowing - LED10 and LED11, close together. Nothing else is lit up.I've followed the manual(physical) and installed this jumper configuration:
(6-12, 2-8, 21-27, 3-9, 22-28, 7-1, 26-20, 5-11, 30-24, 10-4, 29-23)On the first boot when I got the robot, I also had some "defective brake" errors on A1 and A4, but those went away, and I could acknowledge them - they weren't persistent. That, and I don't care about A1 and A4 brakes, because they're not likely to move without them, and A1 brakes do work despite the error message.
Also, I should note that I do not have a KCP2 pendant, and I am unable to afford the exorbitant eBay and reseller prices, as that is close to what I paid for the entire robot. [size=4pt]If anyone has one of those for a sane price, let me know.[/size]
Where do I go from here? KUKA doesn't support this robot anymore(silence on their end), and I really want to get it running with the original controller.
[size=4pt](Side note: if anyone has the interface description for the Agile Systems servo drives, I would be very grateful)[/size] -
I have an old KR3 robot with a KRC3 controller that is about to arrive in my lab, but it's missing the teaching pendant.
If anyone has a spare KCP2 or VKCP2 pendant with a circular connector(not the square Harting one), let me know how much you'd be willing to part with it for. I don't care about the cosmetic or physical condition(broken shell, etc.) - as long as it functions and has a working display.
Just the bare PCB with a display and buttons will do if that's all you have
It's best if you email me - robot-forum@spirit.re, but PMs work too.