KUKA loop and move in Z

Hi,

could you paste program code here?

Hi,
You can solve it by adding an "BASE_DATA[17].Z=BASE_DATA[17].Z + 1" Before ENDLOOP. Off course if direction of build is parallel to Base Z+ direction.

After each execution the program, you can move the base of 1mm in Z direction.

For example:
BASE_DATA[17].Z= BASE_DATA[17].Z + 1

Second way is changing point value of z coordinate.

That being said, remember you'll need a way to revert Base 17 back to its original value before starting the next loop. So you'll probably want to make another variable, perhaps a CONST, or perhaps another Base that's not used, assign that the permanent un-shifted value of Base 17, and always set Base 17 back to that value at the beginning of the program, before the start of the loop.

BASE_DATA[17].Z= BASE_DATA[17].Z + 1 works only if the euler angles are zero, so I would recommend to use the geometric operator.

BASE_DATA[17] = BASE_DATA[17]:{X 0, Y 0, Z 1, A 0, B 0, C 0}

Well, for sake of being pedantic, the Z+1 method will work as long as the Z axis of Base 17 is parallel to the Z axis of $WORLD. But Spl is right, the geometric operator is the better option.

how about entire message? what line of code?

"constant expected" means you are not using constant where constant is expected. for example you are trying to use variable instead of constant.

for example, if you are using aggregate, you MUST use constants:

DECL FRAME OFS
DECL REAL Layer_height


;.....


Layer_height = 1.00 ; mm




;......
; create offset


; this does NOT work, must use constant instead of variable (Layer_height)
OFS={X 0, Y 0, Z Layer_height, A 0, B 0, C 0} 


; this works 
OFS={X 0, Y 0, Z 0, A 0, B 0, C 0} 
OFS.Z=Layer_height


;finally make offset
BASE_DATA[17] = BASE_DATA[17]:OFS


; ....

Hi everybody

Well my problem is similar, but i would like to do a loop with the TCP, add or substract the distance mesure for a sensor.

Anyone knows, how i can do this?

Thanks
Itzel

TOOL_DATA can be manipulated exactly the same as BASE_DATA. Both are FRAME type variables, both interact with the Geometric Operator in the same way.

One caveat: when using the Geometric Operator, all six values MUST be filled in, even if you only use a 0.

BASE_DATA[17] = BASE_DATA[17] : {Z 10} ; invalid
BASE_DATA[17] = BASE_DATA[17] : {X 0,Y 0,Z 10,A 0,B 0,C 0} ; valid

I forgot to explain that I use to RSI for get the information of force sensor. My force sensor mesure the distance in Z, this distance is send by RSI and i would like to the distance modified the TCP (my TCP initial is 230 mm in Z. If the distance mesure by sensor is the 2 mm, the distance in Z for the TCP change to 228 mm).

I read the forum is possible to modify the base_data[], but I didn't understand if it is possible with the RSI the datasheet is not too clear.

Thanks

Okay, that's a completely different thing.

You can't change $TOOL or $BASE dynamically on the fly between motions -- changes to $BASE or $TOOL only take effect at the start of a motion command. As such, making changes to $BASE or $TOOL in KRL cannot effect "realtime" changes to motion, only on a motion-by-motion basis.

RSI cannot change Base or Tool. RSI only controls motion. It can alter motion along either the Base or Tool axes. However, RSI can carry out "realtime" motion adjustments, unlike KRL (which is why RSI exists).

Hello ,

First post here, I hope I don't mess it up.

Been in the shadows reading lots of posts and checking for info.

I found this post interesting because I'm trying to kind of do the same but It seems like some setting is not right for me.

We have a Kuka KR 150 L120/2 E with a KR C2 control 5.2.14 soft version + linear rail + 2 turntables all KUKA branded.

At the moment the goal is to weld several seams in a cylinder which is attached to one turntable while it is constantly turning and the TCP stands still in the same point, after a 360º turn it is supposed to shift itself "x" mm to keep doing the next seam and so on for the amount of seams needed.

For this the turntable has been mastered so that it can be coupled and synchronized, also it has been set to endless type of movement (Axis_type=5 as I recall), also I am taking into account that even in the endless type of movement the turntable will rotate in the direction of the shortest path.

For programming the circle I am using the turntable as base and I calculate the points so the TCP doesn't move while the base rotates (X, Y and C change as E3 Changes). This I got right, I can make one seam without any problem and the turntable will rotate and the TCP will stand still. Even if I loop this (with for loop for example) I can repeat the circle and check that the turntable set to endless keeps rotating always in the same direction.

My problem comes when I try to shift the seam ( In the base of the turntable it is Z direction but in the world base it is X direction) . To achieve this I have tried what was suggested earlier in this post :

OFS={X 0, Y 0, Z 0, A 0, B 0, C 0}

OFS.Z=Layer_height

BASE_DATA[17] = BASE_DATA[17]:OFS

When I do this, the tool starts moving though it should not. I have tried changing both X or Z and in both cases I got the same result.

I am attaching my code here in case you can check it ( by the way, I am using .dat+.src so I declare variables in .dat)

And here my .dat

Oh, And I have also tried modifying the points with the same result via XP1.Z=XP1+5

offsetting base using frame and geometric operator works and it is used all the time.

incrementing point Z value works and it is also used all the time. but you need to make sure to not mix apples and oranges. you are adding:

XP1 is E6POS

XP1.Z is REAL

5 in an INT

you can add and assign values of REAL and INT to each other.

you can do the same with individual elements of E6POS but you cannot use entire E6POS structure as a single REAL or INT.

another thing to watch for is how exactly points and bases are restored. your code is screaming bad practice or collision waiting to happen:

1. you copy base 18 to base 4

2. you manipulate base 18

3. then restore base 18 from base 4

if user resets or aborts half-executed program , last part will not happen and that means base 4 value is not use to restore base 18. next time program is started, base 4 itself will get WRONG value from base 18 and now you also have no good backup of that base any more.

same applies to point manipulation. FYI, i would NEVER let program manipulate reference data (base or point). those can and should only be handled manually (touchup or commissioning). but i would COPY reference data to another variable and THEN manipulate and use that copy.

then it does not matter what user does, when you start program you always starts with GOOD reference value.

Quote from panic mode

offsetting base using frame and geometric operator works and it is used all the time.

incrementing point Z value works and it is also used all the time. but you need to make sure to not mix apples and oranges. you are adding:

XP1 is E6POS

XP1.Z is REAL

5 in an INT

you can add and assign values of REAL and INT to each other.

you can do the same with individual elements of E6POS but you cannot use entire E6POS structure as a single REAL or INT.

another thing to watch for is how exactly points and bases are restored. your code is screaming bad practice or collision waiting to happen:

1. you copy base 18 to base 4

2. you manipulate base 18

3. then restore base 18 from base 4

if user resets or aborts half-executed program , last part will not happen and that means base 4 value is not use to restore base 18. next time program is started, base 4 itself will get WRONG value from base 18 and now you also have no good backup of that base any more.

same applies to point manipulation. FYI, i would NEVER let program manipulate reference data (base or point). those can and should only be handled manually (touchup or commissioning). but i would COPY reference data to another variable and THEN manipulate and use that copy.

then it does not matter what user does, when you start program you always starts with GOOD reference value.

Display More

Hello Panic Mode, Thank you very much for your reply.

I will modify it so I don't mix apples and oranges.

I was aware already about the base 18 restoring thing. I was doing it this way because when I get into the .dat I don't really know how to modify the base of the points, like in FDAT of each point I have BASE_DATA 18. How to change it to a base that I declare earlier? like BASE_DATA MYBASE (in case I declare DECL FRAME MYBASE)