Nullframe base rotation

    Hi All, i m very new to kuka and to the forum, but i have spent over 15 hours on it in the last 2 days.

    I m working on a KRC4 for pallettizing, and trying to re-use a program made by someone else with v8.3 (i have v8.6).

    The robot doesnt use any base or any tool and, for now, i want to keep it this way.

    My issue is that, compared to the previous machine, the XY axis are "rotated" of 270 degrees, (for example, a LIN command on X axis only moves the robot transversally to the line, while it s clear than in the previous machine the same command was moving it longitudinally).

    Now i dont want to go thru all the programs and swap X with Y, cause there are lot of other conditions in the middle..

    I guess i could change base, but everywhere in the program ALL bases and tools are NULLFRAME.

    So i wonder: how can i rotate or swap XY axes without changing the base?

    thanks.

    Ps, please dont tell me to go to "READ THIS FIRST", cause i have been there 50 times! :winking_face_with_tongue:

    Edited once, last by Mr Marcus (May 19, 2022 at 12:32 PM).

    ....programming a palletizing setup without setting up a Base or Tool is programattical suicide. Or possibly masochism. Is the original robot seriously running Base 0 and Tool 0 universally? That only works if the pallet is perfectly square to $WORLD, or if the program is doing extra trigonometry on every shift.

    How is the original program doing the Pallet pattern math? That's really what's going to define how much you can salvage from it.

    Well, i dont want to be the bringer of bad news, but the reason that there are different bases you can use is because you can not (or better should not) change your nullframe or world.

    Programming everything in Nullframe is what i would call a rookie mistake, that most people only make once.

    Now for an other idea, I presume the programs are made with inline forms? you can still open those programs with a text editor and use Find and replace to change base. (in have never worked with inline forms on a KRC4, but i think that should work.)

    Every problem has a solution, that isn't the problem. The problem is the solution.

    Yes, the pallet is perfectly square, the math is made in the plc.

    Ok, i will add a base, i was just curious how could that be change outside the program folder, cause i have looked in every program and they all use nullframe.

    I found something in System, but modify it didnt have any effect, and also the same lines are not in the previous project (8.3) :-/

    Quote from Mr Marcus

    i have looked in every program and they all use nullframe.

    How? Raw KRL, Inline Forms?

    Quote from Mr Marcus

    I found something in System, but modify it didnt have any effect,

    ...what? What did you modify? How?

    What base is being used in the program? Base 0 is unalterable, while any other Base (usually part of the BASE_DATA array in $CONFIG.DAT) can be altered in any way you desire.

    If the programs are written to use Base 0, and you make edits of Base 1, of course it won't have any effect.

    Yes, i had a look at BASE_DATA into CONFIG.DAT and was all zeros, empty names, and NONE types.

    Anyway i have created a base so i'm ok.

    As you say: "base 0 is unalterable", so I was just curious and wanted to know how the hell did anybody changed that?

    For most robot brands, Base 0 (UFrame 0 for Fanucs, Work Object 0 for ABBs, and so on) is a reference to the robot's World frame ($WORLD in KUKA). This coordinate system is permanently attached to the robot's base and cannot be altered -- it is literally part of how the robot is built[1]. "Base 0" is just an easy way to use World in programs, without having to create an extra data type. Tool 0 behaves similarly, but "mounted" to the robot wrist, rather than the robot base.

    Generally, any Base is an offset from World. World is considered the "master" reference frame from which all other Base frames are measured. And any point programmed for a move command (PTP, LIN, etc) are referenced to a Base.

    Without seeing the code of your robot, I can only guess, but if they programmed everything in Base 0, there are two ways they could have made it work.

    1. Point offsets. Basically, teach the "master" Pick Position once, then as the program runs, do something like TempPickPosition={X 100, Y200, Z 150,A 0,B 0,C 0}:MasterPickPosition , with the offsets changing to reference a particular item location on the pallet

    2. Base offsets. While Base 0 is unalterable, $BASE is the "live" Base that the robot is actually executing motions in, and $BASE can be set to anything. So the program might start with $BASE=$NULLFRAME (since there's no BASE_DATA array element for Base 0), but then, while running, $BASE={X 100,Y 200, Z 150... etc similarly to how the point offsets would work.

    3. I know, I said two. That's because Tool offsets could theoretically be done to make this work, but this method would be substantially more work for no gain.

    [1] there are special cases, like when the robot is mounted on top of a 7th axis positioner, where World is moved from the robot base to the base of the positioner. But World does not change unless the physical kinematics of the robot are altered. Once the robot is configured, World can be considered to be "grounded" to whatever structure (generally immobile) the robot is mounted to.

Advertising from our partners