Error recalculating position

    Good morning gents.

    Edit: Sorry forgot to add, this is a krc2 V5.6.12

    Im working in a really fun project, at least for me after 10 years in car factories with basically grippers and welding guns.

    I have my first palletizing robot, and its really pushing me (happily) out of my confort zone.

    So the robot has 3 bays for standard europalets in front.

    Palet 1 I programmed and works a charm.

    I calculate a grid and then multiply by row or column and is working really good.

    However, my second palet is sitting across my axis 1 (I can already feel you guys grinning).

    So when the positions are recalculated, the point becomes unreachable due to axis 1 limit.

    I can see the problem in my dat file, the S and T values are changing. (T43 changes to T42).

    I do know with Lin movements I can ignore this, however I would like to know if there is a better approach, its not the first time in my career I have suffered with these orientations.

    Any help much appreciated.

    Edit: misspellings

    A few moves here. My favorite solutions first:

    1. If you aren't particular about your S&Ts of your edited position, then change your edited position variable from an E6POS to a FRAME (X, Y, Z, A, B, C), then, it will make the same S&T assumptions that a regular LIN move would make, except it will still make a nice PTP motion.
    2. Do a logic check to see if you Y component is positive or negative before you do the move. Depending on your $BASE and $TOOL, this can be a clean indicator of whether the Status BIT0 will be positive or negative. From there, you can make bitwise changes to Status. ( IF myPos.Y >= 0 THEN... )
    3. AXIS and E6AXIS position structures also ignore S&T.

    Option 1 in the previous post is the way I would usually do it. The others are viable, but can cause issues if someone comes along later and adds new points w/o understanding the math.

    Another way would be to use LIN moves instead of PTPs, which might be slower, but LIN moves ignore S&T values in favor of maintaining their linear path. If you have concerns about your dress pack getting wrapped around the wrist, putting an E6AXIS position in your program to force the wrist axes to "unwind" at the start/end of every cycle can help with that.

    Thank you both so much.

    I believe next week I will have time to try out these different solutions.

    I had put a single ptp at the start of my drop program and a single ptp at the exit.

    And then all calculated positions are Lineal.

    Its just a topic I would like to understand and improve on.

    Im worried exiting my drop from a given position could cause the robot to do some irregular movement due to rotation of axis 4-6.

    Hence why I would feel better using ptp movements.

    Also I made a master palet and just copy pasted the 3 programs.

    3 bases and voila...

    Except the damn palet across my Axis 1...

    At the moment I recalculate my pick/drop position acording to my master position and then displace this position.

    Example: (havent got my laptop here forgive any syntax error)

    Code
    xdrop_pos=xmasterdrop_pos
xdrop_pos.x=xdrop_pos.x+(partwitdh*rowpos)
xdrop_pos.y=xdrop_pos.y+(partlength*columnpos)

    In the previous post i simplified the calculations using "rowpos" to avoid confusing anyone with the rest of the maths.

    So the example above is E6pos based.

    And honestly I have never worked with A6pos.

    But im guessing it saves in the dat file the axis positions rarther than the actual coordinate.

    Also im not familiar with FRAME, have been searching, but its 2 am... so monday I will have a more detailed search.

    Quote from micahstuh

    Do a logic check to see if you Y component is positive or negative before you do the move. Depending on your $BASE and $TOOL, this can be a clean indicator of whether the Status BIT0 will be positive or negative. From there, you can make bitwise changes to Status. ( IF myPos.Y >= 0 THEN... )

    first checking myPos.y for being positive or negative has nothing to do with Status BIT0!

    Status BIT0 = 0, when axis2 is pointing towards your target position (Y can be positive or negative)

    Status BIT0 = 1, when axis 2 is pointing in the opposite direction (called overhead)

    As Micahstuh suggested and Skyfire agreed using LIN and Frame ist the best option.

    Quote from Joe_vlc84

    However, my second palet is sitting across my axis 1 (I can already feel you guys grinning).

    What do you mean be sitting across?

    I think your calculation is wrong and is causing the problem

    Can you provide more information?

    MOM,

    Great catch. I meant Turn Bit 0, which according to my System Integrator manual declares bit 0-5 refer to each joint in sequence (A1:bit 0 | A2:bit 1 | A3:bit 2 | etc) where a 0 indicates a positive or zero joint angle and a 1 indicates a negative joint angle.

    Thus, if a mathematically changed E6POS results in a negative -> positive A1 position or vise versa, WITHOUT updating the Turn bit 0, the KSS will yell at you and halt the program. This is my understanding of how the robot works, at least.

    I've ran into what Joe is experiencing a few times where a mathematically indexed position crosses through that 0 degree mark on Axis 1. Luckily, only the first position in a program needs to be explicitly declared with E6POS or E6AXIS. After that, you COULD start using FRAMEs since the KSS can interpret the next status & turn bits from the previous ON PATH position.

    Its great to revert to FRAMEs when the code is using math to modify coordinates.

    Quote from Joe_vlc84

    I had put a single ptp at the start of my drop program and a single ptp at the exit.

    Good.

    Quote from Joe_vlc84

    And then all calculated positions are Lineal.

    Also good.

    Quote from Joe_vlc84

    Im worried exiting my drop from a given position could cause the robot to do some irregular movement due to rotation of axis 4-6.

    Hence why I would feel better using ptp movements.

    It's a real risk, but your approach should manage it. The key is that PTP motions "obey" the S&T variables, and LINs do not (or rather, LINs prioritize their linear path over the S&T if the two ever conflict). As long as all your "dangerous" moves are LINs, you should be okay.

    One of the worst cases of this I ever saw not only had the palletizing pattern crossing the $WORLD X axis, but also had the robot sitting above the pallet such that a certain subset of positions forced the robot to pass through the A5 singularity, because part of the program involved moving parts between different positions on the pallet, not just picking/placing (it was a werid setup). The solution involved detecting this in advance by checking $POS_ACT_MES.Y against the Y of the next calculated point, and if the move involved a transition between $WORLD.Y + and -, the program divided the "dangerous" motion into a series of short moves, filled them into an array of FRAMEs, and then ran through them using PTP motions.

    Quote from MOM

    What do you mean be sitting across?

    He means (I assume) that the pallet spans the $WORLD X axis. This would guarantee that A4, and possibly A6, would have to be in different quadrants for different parts of the pallet.

    this is why KUKA College suggest to use array to store all calculated positions. using loop(s) one can compute all locations and of needed adapt S&T for ones that need correction. then let program just call already calculated points. test it once in T1 and off you go.

    this may not work for cases where reference position can change dynamically but for usual palletizing applications this is very simple and works nicely.

    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

    Quote from Joe_vlc84

    Also im not familiar with FRAME, have been searching, but its 2 am... so monday I will have a more detailed search

    FRAME is easy to understand:

    In robot programming we are dealing with coordinate systems and not points (point is just a vector with x,y and z as parameters)

    A coordinate system has a vector describing the origin of the coordinate system and an orientation describing the rotation going from source to target coordinate system

    A FRAME consists of X,Y and Z for the translation moving the source origin of the coordinate system to the origin of the target coordinate system

    A, B and C of the orientation change from source to target coordinate system.

    KUKA and others using the Tait-Bryan angles: rot.z(A)*rot.y(B)*rot.x(C)

    (some guys (even on this forum) call this (extended) Euler angles (Euler angles would do a rotation rot.z(?)*rot.y(?)*rot.z(?))

    There is a document on the internet which describes all possibilities of rotations

    Putting translation and rotation together ends with the FRAME {X, Y, Z, A, B, C}

    If you have more question on that do not hesitate to ask for

    Quote from Joe_vlc84

    So the robot has 3 bays for standard europalets in front.

    Palet 1 I programmed and works a charm.

    I calculate a grid and then multiply by row or column and is working really good.

    Now let us talk about my stupid(?) idea:

    You have three palets and on every palet you want to do the same thing - correct?

    Why not saying:

    Palet 1: BASE_DATA[1]

    Palet 2: BASE_DATA[2]

    Palet 3: BASE_DATA[3]

    Advantage:

    Program on all palets is the same (only difference $BASE)

    Have a safe positions on top of the palets using PTP AXIS with the required axes positions and afterwards LIN to go to the positions on your palets (because the target position will be the shortest distance to the previous position)

    we got two as well, the black one is very very clever. the one in my avatar is a total dummy, always eyes wide open and ready to do something silly or stupid. this look was "i am about to do something and not sure you re going to like it"

    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

    That is actually why I am asking for

    During my Home Office I always was supported by my cats (Sissi 12 years, Merlin 11 years) as cats and my dog Labrador mix Emma (13 years))

    Sometimes they were boring but most of the time they helped me to relax and calm down. I never want to miss them (but this is not my choice)

    Quote from MOM

    What do you mean be sitting across?

    I think your calculation is wrong and is causing the problem

    Can you provide more information?

    As SkyeFyre points out in the next posts.

    Quote from SkyeFire

    He means (I assume) that the pallet spans the $WORLD X axis. This would guarantee that A4, and possibly A6, would have to be in different quadrants for different parts of the pallet.


    SkyeFire Tks :smiling_face:

    Quote from SkyeFire

    It's a real risk, but your approach should manage it. The key is that PTP motions "obey" the S&T variables, and LINs do not (or rather, LINs prioritize their linear path over the S&T if the two ever conflict). As long as all your "dangerous" moves are LINs, you should be okay.

    One of the worst cases of this I ever saw not only had the palletizing pattern crossing the $WORLD X axis, but also had the robot sitting above the pallet such that a certain subset of positions forced the robot to pass through the A5 singularity, because part of the program involved moving parts between different positions on the pallet, not just picking/placing (it was a werid setup). The solution involved detecting this in advance by checking $POS_ACT_MES.Y against the Y of the next calculated point, and if the move involved a transition between $WORLD.Y + and -, the program divided the "dangerous" motion into a series of short moves, filled them into an array of FRAMEs, and then ran through them using PTP motions.

    I am worried since the parts they palletize can vary in many shapes, even some larger than the palets themselves.

    But I did try a dozen parts and I think with the ptp movement, and the vacuum tool being very small (400x130) even if it did do a peter pan on the way out, it would never crash.

    Maybe strech a few cables :smiling_face:

    My client is over his budget in hours, so sadly im not going to dedicate much more time to providing a better solution.

    Edited once, last by Joe_vlc84 (February 8, 2021 at 2:09 PM).

    Quote from panic mode

    this is why KUKA College suggest to use array to store all calculated positions. using loop(s) one can compute all locations and of needed adapt S&T for ones that need correction. then let program just call already calculated points. test it once in T1 and off you go.

    this may not work for cases where reference position can change dynamically but for usual palletizing applications this is very simple and works nicely.

    I have never programmed an array (spank me, I deserve it)

    However I understand an array would be like a dictionary with all the positions saved.

    And that doesnt work for my application.

    The robot calculates the orientation and how many parts fit on the palet win the inputs of lenth/width/height and then just multiplies the "master position" by the column/row calculated with the current parts in pallet.

    The robot will be "FED" parts with many many size variations (thousands of variations). (only 1 size per palet)

    Tks MOM So yeah I do understand FRAME, just never used the TERM.

    I do have a base_data for each palet.

    I took a "MASTER" palet and painted the tool on the palet (In my MASTER POSITION).

    So when they add a new palet, I just calculate the base orientation (not all are facing the same way/angle) and touchup the master position.

    And the program is ready.

    Its really a charm to look at it work.

Advertising from our partners