Posts by SkyeFire

    Obvously, make a backup first before making any changes. After that, it depends. You can probably delete most of the Renault program files, but you should avoid tampering with anything in the MADA directories to start with. You will probably need to "clean" the SPS.SUB file -- generally it should be safe to delete anything inside the USER PLC and USER INIT folders.


    The best approach would be identify what's causing the errors -- the pendant should indicate which line of a program is causing the error, and you could simply comment out that line and see if that works. You can also open up the Archive on a computer and use search tools like BareGrep to find all the occurrences of variables, subroutine calls, etc -- it'll be some work, but you can build a map and flowchart of all the various programs (and the variables they depend on) this way. Then it'll be time to figure out what you need to prune, and what to keep.

    If a plant electrician moved the resolver cable (the one that runs from the KRC to the robot base), check the pins on both ends. Those cables are particularly vulnerable to having their male pins pushed down into the housings whenever someone is careless about screwing the connectors together. Ditto for the resolver cables on the individual motors. Once they've been damaged, it's not hard for these pins to look fine, but actually be loose enough that they won't make contact with the female side. If you grab each pin with needle-nose pliers and (gently!) push/pull on them, they should have less than 1mm of axial play -- if they "sink" into the connector housing when you push on them, that's your issue. Sometimes you can fix this simply by pulling on the pins until they seat in the socket again, but they will still be fragile, and require extra care when being connected -- you will need to be very sure the connectors are aligned properly before you begin screwing them together.

    That by itself will not be enough to satisfy most jurisdictions' safety regulations (though it is a good start). Given enough time, air will leak into the tool and it will eventually lose its grip.


    The key term is "stored energy", which includes "gravity" -- OSHA has entire checklists for evaluating risk in these situations.

    Okay, no LPDN card means that the robot must be using the DN port built into the MFC card. Which is fine, but dictates which files you need to change in order to add the nodes. So it's good to have that known.


    Now, when adding lengthy cabling to a DN bus, one issue will be termination -- on any DN bus, there must be exactly two termination resistors, and they must be placed at the ends of the longest cable distance (electrically). So, since you will be adding a few meters of DN cable, you will almost certainly need to relocate at least one of your termination resistors.

    Are you cold-booting this robot for a reason? You could consider setting the robot to Warm Boot (Hibernate) instead -- that should have the robot reboot in exactly the condition ($TOOL, $BASE, program line, etc) as when it powered down.


    Hm... when the robot has been freshly Cold Booted, and shows T?, is $POS_ACT_MES showing invalid data? If so, the SPS solution might still work, but you would need to use the FORWARD function to generate the position of the Flange from $AXIS_ACT_MEAS, then pose-multiply that by the TOOL_DATA value of your Tool.


    Another option... do you have SafeOp? I generally prefer not to use SafeOp for anything other than human safety, but SafeOp is always aware of the location of the Safety Tool relative to any Safety Space, regardless of the robot's running condition.

    On newer KRCs, there is a special KUKA USB drive (the KSR) that will backup/restore the entire robot hard drive, without needing any extra tools. But it doesn't work on KRC1s. That may be what the "expert" was referring to.


    On normal KRCs, the installer for KSS is saved in the robot's D: drive. I can't say for certain if a Renault KRC follows that rule, or if the installer might have been modified to be Renault-specific.


    The larger problem is Windows 95. Without the KUKA install CD (the KRC1 uses a customized W95 build, so a "normal" W95 install CD won't work), if the C: drive were ever to become corrupted, the robot would be inoperable unless/until you obtained a W95 install CD from KUKA. So, as Panic says, whenever getting an old KRC for the first time, making a 100% image of the hard drive (Acronis, CloneZilla, whatever) is vital. That will be your last-ditch disaster-recovery option.

    "After restart"? Do you mean a Cold Boot?


    I'm honestly not certain there's a way to do this -- on a Cold Boot, only the SPS will be running, and the SPS cannot change $TOOL.


    I can see three simple options:

    1. Create a subroutine in the SPS that takes $POS_ACT_MES, pose-multiplies it by the inverse of $TOOL, then pose-multiplies that result by TOOL_DATA[1], then checks the result against the boundaries of the Cartesian Workspace. This would depend on the SPS starting.

    2. Create a second Cartesian Workspace that is a duplicate of the first, but using Tool 0 instead of Tool 1, and logically OR their outputs at whatever external system is receiving these signals.

    3. Use an Axis workspace instead of a Cartesian.

    Well, I have a new assignment that involves (among other things) applying labels to plastic totes (roughly like these) on all four sides. The robot would have to take the labels from the printer and apply them to the plastic totes.


    This isn't something I feel like reinventing the wheel for, especially since there appear to be several products on the market that already handle this:




    https://www.kaufmanengsys.com/…cts/robotic-load-labeling (I especially like this one)


    So, has anyone done this kind of application in the past? Any nuggets of wisdom to pass along?;) Any particularly standout vendors to recommend? (North American preferred). We're probably going to want something that uses Fanucs, b/c that's what the rest of the packaging line will be running.


    I'm also open to non-robotic solutions -- I'm aware that, as a roboticist, I have a tendency to look at the world through robot-colored goggles. 8o

    No..Did not do anything.

    Production ended normally yesterday. Today we could not load the program as mentioned in the attached picture in the original thread.

    "Ended" how? Was the robot halted, powered down, other? Cold boot or Hibernate?


    "Could not load the program" -- again, details -- was this simply a reboot? Or were you trying to load new files?


    If you haven't made any program changes since your last Archive, you could probably just do a Restore of that Archive.


    Other option: make a fresh Archive, and use a program like WinMerge or KDiff3 to do a full comparison between the new Archive and one made from when the robot was still operating properly. This will highlight any files that have differences, and will allow you to examine the differences in detail. There will be differences that are irrelevant (mostly changes to variable values), you will want to look for serious formatting changes. Given how many of your files appear to be showing Linking errors, most likely the file corruption happened to a "core" file -- $CONFIG.DAT, BAS.SRC, or some other file in either the SYSTEM directory or possibly in the TP directory tree.

    Really depends on what you want to do. I've only used RDK's free version, and that only slightly, but it seems decent for doing basic layouts and reach studies. For creating off-line programs that can be exported directly to a robot, I'm pretty sure you need the paid version.


    If nothing else, the free version seems like a good, cheap way to get a handle on the benefits and limitations of simulation.

    My personal preference would be to use DN everywhere, but that's mainly because I'm comfortable with DN on KRCs, and I like to minimize the wire distance of discrete signals.


    Buying additional DN nodes may be more expensive than simply running some multi-conductor cables. And using DN at the ATI will require you to mount a DN node (with sufficient discrete I/O points) out on the robot wrist, which could present volumetric issues (plus that DN node would probably need an IP rating, unlike those "sliced" Beckhoff units you've been using -- those are not intended for being mounted "in the open").


    So, at the end of the day, it really comes down to your personal cost/benefit comparison.

    Same questions: "stock", or "special" (aka VW, GM, etc)?


    Again, the installer for KSS should be located on the robot's D drive. That should leave you only needing the Windows 95 installer, which would have to be obtained from KUKA. Of course, before anything else, you should make a complete backup of the robot's entire hard drive (CloneZilla, Acronis, Norton Ghost, etc) as a disaster-recovery safety net.

    No, I meant attach a dial indicator where it can touch the moving part of the axis, and measure the axis motion. Because you're probably stuck touching the castings, at non-ideal locations relative to the axis of rotation, these will only be approximate, but they might be indicative.


    Can't judge by eyeball, sorry.


    The "jump" at first motor-on suggests the brakes are worn, letting the arm "sag" some when the power is off -- not enough to generate a system fault, but enough to create a "jump" when the robot switches between brake holding and servo holding.


    .3-.4mm of lost Cartesian motion seems a bit high, but not really excessive -- it depends a lot on payload, robot model, robot pose, and other factors.


    I'm not seeing an obvious "smoking gun" here -- it's entirely possible that the motion issues you're seeing are the accumulation of lots of very small wear issues in the robot, from A1 to A6.


    One other thing I would suggest: create a program to do these tests, and execute it, instead of using jog mode. There are some (usually insignificant) differences in how the robot moves between Playback and Jog. I'd be especially interested to see if the O-Scope following error trace can be reduced by using lower acceleration values.

    TouchSense uses the Fast Measure inputs, correct? So, is it the software or the hardware that KUKA Bulgaria says is not supported? I could maybe see the hardware package being discontinued, but the software? No.


    What are you trying to do with TouchSense? If it's just base offsets, it might be possible to create your own. You could also try asking KUKA about MeasureTech -- that's basically TouchSense without any of the arc-welding seam-following tech.

    The JR signal should just be connected to the MasRef sensor -- you wire the MasRef sensor to a safe input pair on the safety PLC, and have your safe-PLC program pass that signal directly to the robot on the JR signal. I don't recognize this "EJB" signal they're talking about, either.


    There's no way to fake this in any of the robot programs, b/c the safety controller in the KRC4 is essentially a separate "brain" of its own that is inaccessible from the "main" controller. The MasRef program works by setting an internal signal that tells the safety controller to check the MasRef input and the robot's current position (vs the MasRef position set in the Safety Config). And if the safety controller doesn't see what it wants to see, it fails the MasRef test.


    Likewise, if the MasRef input (hardware or JR) stays on too long, or not long enough, it's a failure. So the JR signal has to come True, and then go False, at the right location, within the right time frame.