External Linear Axis Compensation

KUKA does not offer support for such a feature directly. You would need to do the adaptions and corrections yourself using e.g. RSI if realtime correction on the path would be necessary.

So where exactly would you need to apply corrections. Only at programmed positions or arbitrarily in between taught in positions?

Fubini

Two ways the previous engineer might have done this:

1. Added some kind of correction to the SprutCAM postprocessor, using something that adjusted the Z value of the output position based on the E1 position.

2. Created some kind of "live" offset in the robot. You can check this by looking at the extant robot programs. If they look like:

LIN P1 C_DIS

then the offset is probably not being generated in the robot. OTOH, if you see something like:

PTEMP=P1

IF PTEMP.E1>5000 AND PTEMP.E1<6000 THEN

PTEMP.E1 = PTEMP.E1 + 1

ENDIF

LIN PTEMP C_DIS

Then that would be a smoking gun indicating that the robot is offsetting Z relative to E1, while the SprutCAM output is assuming an "ideal" linear axis.

I suppose one other possibility exists. If SprutCAM supports creating the virtual linear axis in a non-linear fashion, that might put the "correction" into the kinematic model, upstream of the postprocessor.

why not install rail properly? make it level and even. then no compensation is needed.

Quote from loctran96

I've heard that the previous engineer used "mapping" to compensate for the uneven of the track, but I have no idea where that information is stored. The system was set up by the previous engineer who left no document and I have no way to contact him.

take the archive and look for clues. optionally post it here.

btw if the system was setup by a previous engineer, and it was working - what changed? did someone remove and lay down the linear rail again? was the system relocated?

Sounds like a robot roller coaster

got to love it when instead of doing proper hardware setup they pass the lopsided problem your way and want you to "fix it in software". so what if things are not level or robot goes through singularity or has no reach or no room to turn around...

have no experience with SprutCam and without knowing what the robot program looks like or if the compensation is done on the robot, one can only guess.

All KUKA guides on linear rail installation that i encountered insisted on making the rail level. then theoretical model in CAD/CAM and reality are easier to match. but it is also conceivable that someone did measure the rail and number of points, fed them into a table and have script that interpolates E1 position and corrects the Z value (or also X and Y or rotations too).

it is also possible that someone simply stated that compensation does exist but it is not really there. maybe it is not even necessary for the particular process tolerances. have you tried taking any measurements to quantify the differences? without knowing what data you are looking for, it will be much harder to find it.

it also depends if this CNC a single 25m long machine (making giant shafts, or naval cannons for capital ships etc) that robot need to correctly track along the entire length.. OR the robot is used for loading bunch of CNCs that are lined up along the linear track. most CNCs are reasonably small with door opening that is maybe 1m wide or so. so for most scenarios robot E1 would need to come to a specific place and then robot would tend that machine, in this case, it would be sufficient to make single frame (base) to offset points at that one machine. one would need to do the same for others.

so far there is no clear idea what the process is, what the deviations look like, what the CNC setup looks like etc. all we know is that SprutCam is used to generate code. that code may already contain compensation. or maybe compensation is done on a robot. since there is nothing for us to look at, this is all in your hands.

and just to bring this up as well - maybe the compensation is real but it was done after export from SprutCam but before delivering programs to the robot. previous engineer could have simply created own program or script that does the corrections. and he may have decided to remove that program when he was leaving.

you are welcome

Quote from loctran96

I just wanna narrow down where to look, whether the "mapping" would be in KUKA system or from SprutCAM.

If you could post a snippet from one of the existing robot programs (2-3 moves), that would help.

There is another option for "mapping". New River Kinematics (the makers of Spatial Analyzer) offer a product called SARCA that is available for many brands of robot. The SARCA module can be "taught" the robot accuracy error through its entire envelope using a laser tracker. To use the SARCA, you make a special function call instead of a standard LIN or PTP motion. The SARCA function call takes the desired motion, massages it using the error model, and passes back an adjusted E6POS value that corrects for the robot error. I've seen it used, and it improves the accuracy of a typical robot quite a bit.

It's possible that the previous engineer used that, or a competing product, instead of "hand-mapping" everything in SprutCAM or in a robot-side error-correction file. Alternatively, you could price one out (don't forget the setup and laser-tracker rental time), and use it to scare the bosses into just fixing the rail properly.