Posts by ScruffyGerry

    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.

    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.

    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.

    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.

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

    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'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?

    The Kuka I run is used exclusively for milling, which generates some ridiculously large files. It's a KRC2 controller running KSS5.4.14 - can I just select a header file that's on the USB stick, and run it from there? I'm having to split programs up a lot at the moment - the milling routine that it's running right now is split into six sets of files, because the available onboard space is so small - it won't let me upload more than 15 linked files - this current job breaks down into 48 files total.

    I'm reluctant to just try it out, because I simply don't know if it's going to cause any readahead problems (or whatever the Kuka equivalent is) due to the slow USB bus speed - can anyone here verify if it would work?

    Well, XPe won't be an issue -- XPe only runs the user interface. The robot actually runs on VxWorks, a Linux-derived RTOS.

    That is actually really reassuring, and has also answered the question as to how in the hell they managed to get a decent RT kernel in there.

    I've already learned shedloads in the couple of months I've been playing with this thing, and I can tell there's still tons more to go. Thanks for being as helpful as you guys are - I've been in so many forums historically where people are just snide sods that don't even bother.

    Thanks for that - it's definitely pointed me in the right direction.


    I won't lie, it is predominantly paranoia on my part - I have very little trust in XP embedded on account of having to service instances of it for years. I've seen instances of them specifically spazzing out due to high integer values (only around 90% of the max limit, but it was enough, apparently) on a counter system, and given that we've got a lot of work coming in for this robot soon, I don't want to get tied up with a similar issue if I can forestall it.


    Having already had to deal with the gearing on the turntable being set up incorrectly, I've got a bit of a twitch on about making sure it's all just so.


    Thanks for indulging my paranoia and giving me something to work with, it is most appreciated.

    Hi all. I've got a third-party turntable on my KR210-2 (running KRC2, KSS5.4.14 I believe). It's set up to do milling work, and generally does a fine job of it too.


    Whenever I run the 'home' program after completion of a job (which explicitly states E1 0.0) it only returns the table to the nearest multiple of 360, instead of winding it all the way back to zero.

    As stupid as this may sound, is there an elegant way to force it to go back to the zero point as defined by the axis position reading? I don't really want to sit there with my thumb on the E1 - button in jog mode for what feels like an eternity, and I don't currently have a handy minion to fob such a tedious task off to.


    I know it seems like a non-issue, but based on several years' experience in IT support, I know full well that XPe can get very weird about large integers long before they reach the overflow limit. I just want to do everything I can disincentivise Murphy's law from taking an interest in me.

Advertising from our partners