Error recalculating position

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.

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.

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)

panic mode

I think you should change your picture (at least looking a bit different).

I have two cats and whenever they are looking like this there are two possibilities:

hungry or angry

Actually I like this picture looks like Merlin as teenager to me

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"

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)

@Joe_vlc84

I am very happy that your problem is solved! Maybe you could tell us the actual solution.

Can you explain what you have done differnetly to when the problem is solved now?