Skyefire,
When you say "robot empty", does that mean putting files somewhere in the "program" folder or sub folders? So we should only keep the active program and any "called" sub routines in the active memory?
I meant, with none of your CNC programs on board.
Yeah 1 mb for milling is pretty small for me, I can easily see programs with 50-70k lines, which are about 5 mb. Maybe I should round off more digits, or does that even matter? I know the ABB RAPID had a way of real-time swapping modules into memory, does KRC have this? Even using spline interpolation...which we are just starting to explore here, a large path could be big.
You can sequence separate modules in KRL perfectly well -- I've never used programs that big, but my reflex response would be to break each larger program up into much smaller chunks and call them sequentially from a higher-level program.
Rounding digits might help a bit, but unless you're running each position out to 5+ decimal places, I doubt it would do a whole lot.
I don't know of any way to real-time swap entire modules. There is a tech package from KUKA called the Directory Loader that can let you upload new programs to the robot in an automated fashion, but it's not an on-the-fly process. Or, you could use the KRLXML package and a background process to load new positional data to your .dat file, maybe.
I suspect that the root problem here is that the KRC controller operates by loading *everything* into a RAM drive during boot, and then operates out of the RAMdrive -- the hard drive is almost completely out of play as far as the robot kernel is concerned. This setup was developed at a time when a 100kb program would have been considered ludicrously oversized in robot programming, and there's probably a limit to the individual module size it can handle well. I don't know how much, if any, KUKA Roboter may have done in handling Mb+ size modules.
When you say camrob exploits the robot's natural motion tendencies, can you elaborate? We do have a scripted filter that allows us to convert the motion to circ moves, which usually gives better accuracy with same size file(or smaller file with equal accuracy). CAM packages (mastercam, etc.) can usually only do this on the orthogonal planes when milling surfaces(or 3d curves), luckily the KRC code allows an arc on any plane, since you only need to call the 3 points. But we have not used this script for any surfacing yet, which we still do with mastercam/robotmaster.
CNC and CAM programming with robots isn't a subject I have much real experience with, so I can only speak in the most general terms. From what I've seen, CAM programs seem to tend to overpopulate their paths, especially curves, with lots and lots of points. OTOH, in general robot programming, we try to use as few points as possible on complex curves and use them as "attractors" to "pull" the path into the shape we want. That works for hands-on programming, but has obvious drawbacks when you are programming directly from a CAD/CAM model. My understanding is that KUKA's CAMROB package bridges the gap, converting CNC-type programs into something more optimized for robot use. I
assume that it takes the robot's natural arcs of motion into account and avoids things like programming umpteen dozen points per inch, but that's only a surmise on my part. I'm also assuming that CAMROB is designed to deal with large CNC-type programs and work around the module-size issue, but that's another guess.
One thing you could try: rather than import the programs using the KCP Navigator (which I assume you're using), try copying the programs directly to the correct subdir on the C:\ drive using Windows (remember the RAMdrive/Hard Drive split), then force a cold-boot of the robot (CONFIG>ON/OFF OPTIONS). When the robot reboots, any properly formatted KRL module that is inside the Program directory will be loaded and compiled. It's a bit of a workaround, but this
might get you past the module size issue. It's easy to do and worth a try, at any rate.
Author