Kuka workspace error after transferring program

    Hi there,


    I’m a novice when it comes to robots, so forgive me if the solution is trivial.


    We have two kuka robots in our lab. One of them is not working, possibly due to a corrupted file. To continue working on my project I transferred my program from the broken robot to the working robot via USB. I can access the program on the pad, except when I try to run it I receive workspace errors and am unable to proceed beyond the home point. Other programs on that robot work fine.


    Thank you for any help.

    Thank you for your response.


    I’m confident all points are reachable by the robot as the program worked fine on the other robot. Part of the end effector (a gripper) is not attached to this robot for some reason and I don’t have access to the unique key to reattach it. Would that cause the error? I will upload some photos of the message in a few minutes.

    Having difficulty uploading the image, so I'll type out the message:


    Effect:
    Maximum Breaking
    Input of active commands (robot motions, program start) is blocked


    Possible Cause(s):


    Cause: Tool and/or base have been offset
    Solution: Correct tool and or base


    Cause: Tool and/or base have been modified since teaching
    Solution: Correct tool and/or base


    Cause: Incorrect calculation of positions
    Solution: Correct faulty calculation



    I presume from what you've said, and the messages, that the error has to do with half of the gripper not being attached. Seeing as I don't have the means to reattach the gripper, is there a way to circumvent the problem and allow me to run the program?

    [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]

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

    Edited once, last by panic mode ().

    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.

Advertising from our partners