What do I need to know before disconnecting and moving a control cabinet?

  • I'm not at the machine itself at the moment, so you'll have to forgive the lack of kss details and so forth, but aside from having to remaster the arm itself, are there any special considerations I have to make before hooking the cabinet back up after moving it?

    The cabinet is currently in the same workspace as the arm itself, and all the polystyrene and toolbars milling dust have managed to kill the rear fan (which I'm replacing) - I thought it best to move it into a less dusty environment, but I'm just worried that it might lose some information or reference data in the move. I replaced the batteries recently, so hopefully that should forestall any major losses, but I figured it's best to ask before doing, you know?

  • Place your Ad here!
  • Lemster68

    Approved the thread.
  • Moving the KRC should be simple. Just on general principles, taking an Archive is a VERY good idea. And if you don't have a full hard drive image, that would also be a VERY good idea.


    No re-mastering of the arm should be needed, unless something screwy is going on. If it's a KRC2, then if the batteries are not up to snuff, powering down may cause the loss of mastering data. Aside from that, powering down, disconnecting, moving the KRC, and reconnecting the cables should be a low-risk action.

    Honestly, the biggest risk might be vibration damage to the KRC's internal electronics if you're not careful while moving it. It's not made of glass, but... just, be gentle about the bumps, yeah?


    Some of the KRC/KR connections can be a bit fragile, especially the round connectors for the RDC cable. So being gentle with them, and being sure the pins are aligned and inserted properly before you start screwing down the threads, is a good idea. It's too easy to crush or push the pins back into the connector housing if you get careless.


    Obviously, when powering down the controller, wait until the controlled powerdown is 100% complete before you start yanking any cables. That should only take 30-60sec, usually. You can tell by watching the pendant screen and/or the LEDs inside the KRC. When all of those go dark, you should be fully powered down and ready to disconnect.

  • mastering can be lost if robot transport was unreasonably rough or if robot was not in proper transport position. this may not be possible without removing tool but the idea is to place robot in pose where effects of joint torque due gravity are reduced.

    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

  • The cabinet has now been moved, thank you for all input on that.

    While the robot has spun up just fine again, the original issue that caused me to move the cabinet is still present. Axes 4 and 6 throw a thermal error part way through a milling process. I'm told there's a way to shut down the pc instead of hibernating it, and re-reading the definition files to clear extant error codes. Can any of you point me in the right direction for how to do this?

    Krc2 v5.4.14

    Kernel ks v5.4.93_hf02 rtacc

    The robot is a kr210-2 with a turntable. Is there any other data you need?

    Thanks in advance.

  • I've found the 'force cold start' function, but my next question is whether or not there is any potential hazard to running a cold start - do I need to find any specific filesets that it will want to read through, or can I just run the cold start and then it'll pick up as was?

  • I've found the 'force cold start' function, but my next question is whether or not there is any potential hazard to running a cold start - do I need to find any specific filesets that it will want to read through, or can I just run the cold start and then it'll pick up as was?

    Cold Start with default options should have no issues, aside from losing the program pointer, so you'll want to make sure the robot is at Home and not partway through a program when you do it.


    Obviously you want to keep your backups current, but that's less due to Cold Start than to the KRC2 being an old system and increasingly vulnerable to hardware issues and file corruption as time goes by. Always have a good full hard drive image, and pull Archive backups on a regular basis.

  • OK, I'll take an archive snapshot tomorrow morning.

    I'm mainly worried that the error won't clear, which means a servo pack needs replacing - on a machine this old, sourcing one and fitting it may well be a serious issue. Am I right in thinking that the servo packs aren't directly swappable? I remember hearing something about hardware IDs needing to be registered with the controller...

  • Am I right in thinking that the servo packs aren't directly swappable? I remember hearing something about hardware IDs needing to be registered with the controller...

    AFAIK, on KRC2s you can swap the servo modules without any issues, there's no individual IDs. The modules are "addressed" by their position on the daisy-chain bus (the white cables that go from the KPP to KSD1 to KSD2 to....). So if you were to, say, swap your A5 and A6 KSDs, it's a simple matter of unplugging the cables, physically swapping the modules, then plugging the cables back in -- the A5 cables will plug into the "new" A5 KSD, and so on. This was a regular troubleshooting trick back in the day, when you weren't sure if an axis issue was coming from the motor or the KSD.


    Each axis has its own KSD. In most KRC2s, the first three KSDs are larger, for A1-A3, and the last three KSDs are smaller, for A4-A5. The KSDs for big robots (like the KR500) are bigger overall than the ones for a small robot like the KR60. So, when swapping, you need to ensure that you're swapping two KSDs of the same size/amp rating, but that should be about the only thing to really worry about.

  • That's great news. I'm going to try applying fresh thermal paste to the heatsink contact points first, then continue to diagnose from thereon out. Worst case scenario, we may have to buy a second robot to scavenge parts from - I've not found any matching KRC2 cabinets within a sane price or radius, whereas I can get another KR210 for ~£9k. Not ideal, but better than nothing.


    Thanks again for all the info, it's been super helpful.

  • I'm going to try applying fresh thermal paste to the heatsink contact points first

    What contact points?


    The KSDs have finned backs that protrude into the "double back" of the KRC2, and the cooling fans blow air through those fins for heat dissipation.


    What's the actual text and code of the error you're getting (it should be in the Logbook)? It might be the temperature sensors in the motors, rather than the KSDs, throwing the error.

  • I meant the point on the plane of the heatsink where it meets the components that generate heat. I know that requires more disassembly than is considered the usual, but it's not the first cnc machine I've had apart, just the first kuka.


    The specific error code is 1070.

    • Helpful

    I meant the point on the plane of the heatsink where it meets the components that generate heat.

    I've never had a KSD apart, but IIRC the fins are part of the backplane of the module, and I would assume that backplane is the direct-contact heat sink for the components inside the KSD.


    I'm not certain how any debris could get between the components and backplane, but I suppose it's worth checking. The KSDs are basically all standard Lenze servo modules with KUKA-specific firmware, so if you can find a service manual for similar Lenze products, that might be helpful.


    My manual shows 1070 as "Brake Cooldown Time", and that's the acknowledgement message that follows after Status Message 25.

    I've never run into that one, so I'm not sure if the heat causing the error is in the motor, or the KSD. Though my gut feeling suspects the motors. The brakes only consume power and generate heat while the robot is in motion, so stopping for a few seconds will let them cool down. Does this error only happen when the robot has been moving non-stop for a long time?


    Each KR servo has its own temperature sensor, whose value is cyclically recorded into the $MOT_TEMP[] array, one entry for each axis. The zeroing of those sensors isn't great, but they're pretty accurate about changes in temperature. So if you checked them when the robot is cold, then again when this error happens, you might see just how much the motor temps are increasing over that time period. That might reveal something useful


  • Sorry for the delay in answering, I've been trying very hard to not take work problems home with me over weekends.

    Yeah, the Kuka service engineer I was talking to and I came to the same conclusion, having dug through the error logs. I've also gone through the program that I was running on it, and the A4 motor is being worked, but not ridiculously hard (it's not doing as much as some of the other axes, that's for sure). I'm fairly confident that it's not the program causing it, so that does rather point at the motor being faulty at this stage. It's an intermittent error that's come up historically, but it's never been this persistent.

  • So, further development. I've had a replacement motor and servo pack out of Kuka, and neither has resolved the problem. Having conferred with Kuka, it's looking like it's probably one of the internal control boards, so at this point I may well either have to scavenge parts out of another robot of the same model, or it's replacement robot time, which I'm fairly confident isn't going to be an answer that management will like much.

  • Just for the sake of completion, I'm adding a final update to this post, in case anyone runs into the same problem.

    It transpires that there was nothing wrong with the robot itself - the CAM software had over-constrained the motion to the point where the robot couldn't consistently maintain it. There was a combination of a toolpath that it didn't much like (rotary cutting a piece that had a lot of ins and outs, for lack of a better term, and the postprocessor had $APO.CDIS set to 0.5, which was drastically overworking A4.


    Thanks to everyone for their input and help with this, and extra thanks to Kuka and SprutCAM support for getting to the bottom of things.

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

Advertising from our partners