Kuka workspace error after transferring program

Are tools and bases correct?
Are all points reachable by robot?

[size=1em]please check topic READ FIRST[/size]

[size=1em]also robot is unaware if tool is mounted or not so this is not the issue.[/size]

[size=1em]problem is that robot thinks that it needs to move to a point that is unreachable. that could be because points are referring to a different (shifted) base or tool.... to see what is going on check values of variables $TOOL and $BASE when program fails. also check $POS_FWD. try jogging robot manually towards that point and you will see where that point is according to robot.[/size]

Identical programs are not necessarily executed identically by different robots.

First: Are the two robots the same model? Same arm length, linkages, etc?

Second: Are the two robots configured identically?
If your program uses Cartesian coordinates (XYZABC values) as opposed to axis angles (A1,A2,A3, etc), then the robot requires more information than just the coordinates the program wants to move to -- it has to have the settings for the active $TOOL and $BASE values. $TOOL defines the mathematical relationship between the tool mounted to the robot wrist, and the flange its mounted to. $BASE defines the relationship between $ROBROOT (a coordinate system whose origin is located in the physical base of the robot) and the reference frame that the program points will be offset from. These values are not included by default in KRL programs, though they can be, but are normally stored in one of the robot's configuration files ($CONFIG.DAT for most KUKAbots).

Third: You haven't told us anything about these robots in detail. KRC1? KRC2? KRC4? iiWA? External axes or not?

Fourth: How is your program made? Are you writing KRL yourself, or are you jogging&saving points on the pendant, using the menu-defined structure?
If the latter, $TOOL and $BASE are being controlled by the Tool and Base numbers you assign to each motion command. These numbers draw their actual XYZABC values from the TOOL_DATA and BASE_DATA arrays in $CONFIG.DAT -- setting a motion command to use Tool 1 will cause $TOOL to be set to match TOOL_DATA[1] on the fly, as that motion command executes.

Work Envelope errors normally occur when the motion planner predicts that the commanded motion will reach beyond the robot's physical ability to stretch (this is distinct from an axis-limit error, which can be caused by limits the programmer places on each axis of the robot). This can be caused by incorrect $BASE or $TOOL settings. It can also be caused by the robot being mounted atop an external axis, and the XYZ values being incompatible with the E1/E2/etc values.

Your physical tool has nothing to do with this error. Only $TOOL matters, because that is the tool the robot thinks it has. If $TOOL is not accurate to the physical tool, collisions can be the result, but workspace calculations are controlled by the "virtual" tool defined in $TOOL.

$TOOL matters because it defines the point (relative to the wrist axis mounting flange) that the robot "cares" about -- for example, the tip of a pen, that the robot is supposed to draw a line with. If you program a LIN motion to move the pen in a straight line, but have the pen rotating or tilting during the drawing of that line, you need the robot to be set up to control the tip of the pen, not some other part. If your TCP is set to the middle of the pen, and you set up a LIN motion that changes orientation over the course of the motion, the middle of the pen will execute a quite straight line in space... but the tip may well move in odd, unpredictable ways (leaving the paper, gouging it, drawing a curve, etc).

$BASE matters because it is the reference frame against which every program point is executed. When $BASE is all 0s, it matches $ROBROOT by default. And this works for many simple applications. But imagine a palletizing pattern, where the robot is supposed to mathematically arrange objects in a 3-dimensional pattern on a pallet/table/platform/etc. It's entirely possible to do all this mathematically, relative to $ROBROOT, regardless of where the pallet is placed/rotated relative to $ROBROOT. But setting $BASE to match one corner of the pallet, with (for example) X and Y aligned along two of the pallet's edges, makes programming all of this much easier (the math is still getting done, but the robot is doing all the heavy lifting in the background). So for most palletizing programs, the programmer only creates one dropoff position, at the "zero corner" of the pallet. And then uses counters to "shift" $BASE in a raster pattern -- if your objects are 100mm cubes, and you want a 10x10x10 pallet stack, the robot could lay a "line" of cubes along the "zero Y" line of the pallet, counting each part and shifting $BASE.X by 100mm for every increment of the counter. Then it would increment the Y counter by 1, shift $BASE.Y by (Y Counter * 100mm), reset X counter to 0, and lay down a line of cubes on the "Y 1" line. Once it had reached X=10,Y=10, it would reset X and Y to 0, increment Z to 1, and... you get the idea. Neatly arranging one thousand parts on a pallet, using one programmed position, three nested FOR loops, and a well-designed Base value.