Posts by Leon

Things keep getting stranger for me, i rewrote the program using CIRC instead of CIRC_REL and something interesting is happening.

So the code as it is now:

PTP{x 984.5,y 1485.5,z 1400,a -90,b 80,c -90}
$ORI_TYPE  = #VAR
$CIRC_TYPE = #PATH
CIRC{x 1124.5,y 1341.5,a -180,b 80,c -180},{x 984.5,y 1203.5,a 90,b 80,c 90}, CA 180

This does exactly what i want it to do for the first half circle but i can't do more then half a circle apparently.
I uploaded a video in which you can see the movement of the first half of the circle as it should until is passes the halfway point.
(spindle is still away for repairs, but this gives me the time to test these kind of things)

Kuka robot milling

When i change the CA to 360, i doesn't even do the first half. It goes wrong from the start as it does in the video at the midway point. The tipping point is 180, if i enter 181 it doesn't work but if i enter 180 it does. Well fine by me, so i added a second line of code for the second half of the circle.

PTP{x 984.5,y 1485.5,z 1400,a -90,b 80,c -90}
$ORI_TYPE  = #VAR
$CIRC_TYPE = #PATH
CIRC{x 1124.5,y 1341.5,a -180,b 80,c -180},{x 984.5,y 1203.5,a 90,b 80,c 90}, CA 180
CIRC{x 842.5 ,y 1341.5,a 0,b 80,c 0},{x 984.5,y 1485.5,a -90,b 80,c -90}, CA 180

based on what i have seen this should work, only it doesn't. First half of the circle goes oke, second half it goes wrong.
The strangest thing to me is that the tool path itself is oke, it is only the rotation around tool z that goes wrong.

Well i tried making some pictures today, only strangely i can't seem to replicate the results i had last time with the variables set to var and path.
Now i know for sure i am doing something wrong. When i have some time to spare today i am going to rewrite the program to use CIRC instead of CIRC_REL and see if that helps.
I attached one picture of the robot at the start point of the circle, unfortunately the spindle is away for repairs so you will have to imagine one

Hello guy's, I have been running into a small problem when orientating the tcp in a circ_rel movement. But first of machine information.

control VKRC2, which has been updated to the the standaard KRC2 software Ks 4.9.
Robot: KR150

I am trying to mill a tapered hole of about 10 degrees.
so my plan of attack was move to circle start point and angle the mill PTP{x 1300,y 800,z 900,a 90,b 80,c 90} b is rotated 10 degrees to get the right taper in the hole.
The next step is CIRC_REL{x +100,y -100,a +90,b 0, c +90},{x 0,y -200,a -180,b 0,c -180}

So the actual points in the circle are:

start point {x 1300,y 800,z 900,a 90,b 80,c 90}
auxiliary point {x 1400,y 700,z 900,a 180,b 80,c 90}
end point {x 1300,y 700,z 900,a -90,b 80,c -90}

I have checked each of these positions individually, and the mills is exactly in the place i want it to be.
The problem arises when i tried the circular motion. The tcp follows the circle exactly only the orientation doesn't stay the way i want it.

I have got a few options:
1. $ORI_TYPE = CONSTANT mill stays in the same angle al around the circle, which means that i don't have a taper but a angled hole.
2. $ORI_TYPE = VAR and $CIRC_TYPE = BASE mill wants to make a complete rotation around the TCP path trough my product, not sure what is going on here
3. $ORI_TYPE = VAR and $CIRC_TYPE = PATH mill does exactly what i want i to do, with only on problem. It keeps the mill Perpendicular to the path and tries to rotate the mill through the robot arm at about 50% of the cirkel.

I know that option 1 and 3 are exactly as described in the programming manual. so that leaves option 2 which should be the correct one but i don't understand why it doesn't work.
I guess someone has tried to do this, and probably i am at this al wrong. any advice is welcome.

We are using a PDS spindel (DLC 90 Dyna - LOC) 5.5 kw and up to 24000 rpm. It is mounted on a KR150 robot and is mostly used for milling al kinds of plastics. At the moment we only use HSK-F40 tool holders with a ER25 lock.

Since we mounted the motor we had a few crashes and so far surprisingly the motor hasn't even gotten a scratch. No problems with excess heath either. Even after a full day of work the motor feels just a bit above room temperature.

We are located in the Netherlands, so i contacted kuka belgium, wich is located about 100 km from us. But if you use the standard contact email on the kuka website you will be put in contact with the closest kuka location.

Hello byakki,

we payed around 600 euro's for the conversion. This is not the price for the actual software but the total price of getting a kuka engineer to our plant, replace harddrive, make back-ups and justage of the robot.

A few months ago we also bought a used vkrc2, and have run in similar problems you have. In the end we contacted kuka and the replaced the volkswagen software with the standard kuka software. that made my life so much easier. But back to your problem, do you have any error messages, are you running in T1 or T2? a screenshot would be nice.

Well, i don't use anything for programming other then the editor on the controller. Most of the products we make are not that hard to program by hand. The above video is one of the simplest but the hardest i finished last week and the amount of the time i spent programming was one day max. When you get used to it KRL isn't a bad program language .

I have encountered similar problems in our milling applications. i am working with a kr150 witch has spend 10 years welding cars, so i consider it a very used robot. When a robot is this used you can expect problems like this. Luckily for me i found out that the fault is constant with a certain angle. so i run the program once and then adjust where it is needed. If in your case the fault is the same every time you can easily adjust this in your program.

The problem you describe can be fixed by just rebooting the controller. when you ad a new program to the robot folder it won't be loaded in until the robot is rebooted. Someone from kuka explained to me that the kuka software only works from the RAM memory not the hard drive, so during start up everything is loaded in to the RAM memory. This problem always occurs when you make changes outside of the Kuka software.

Never heard of the saying: "Whenever you make something idiot proof, along comes another idiot."

I had a similar problem not to long ago. you can try to use the $vel.ori1 or the $vel.ori2 commands instead. vel.ori1 is swivel velocity and vel.ori2 is rotational velocity. I don't know if it matters if you are using a external tool, but you could try it.

A simpler way to measure if you only change the length of a tool, could be done with a button. We are using our robot for milling so only the X value in the tool data ever changes. I calculate and measure the tools myself and then fill the tool data in by hand. You could also do this by moving the robot with tool to the button and stop it when it hits the button. Then use the robot coordinates to determine the tool length. This only works when you change 1 variable, if you change more you need to have a system more like wat skyfire suggest.

Hello to all,

For the last few days a had a bit of time to work with our robot and i noticed a few things that i cant explain. These things don't give any problem in using the robot but i would like to know what is going on.
The first thing is when i make a linear movement over a,b or c like for example LIN_REL{a -90} i cant control the speed at which it does this movement. I suspect it has something to do with the TCP not moving. Speed is set for the TCP in m/s so when the TCP does not move how does the robot caculate the speed for the axis?

The second thing also involves making a linear movement over a,b or c. 1 of the milling programs i use to mill the top of boxes rotates the mill over C multiple times by using LIN_REL{c -90} clockwise. It does this 3 times and kind of get all the wires tangled. So the when i am finished milling the last command is LIN_REL{c +270} which by logic should mean that the robot should move 270 degrees counterclockwise to move back to the start angle. Well surprisingly for me it does not do that, it moves another 90 degrees clockwise. The endpoint is the same so does this mean that when using a command like this that the robot will always use the shortest route and not the + or - direction used in the command.

I hope someone here can enlighten me, i am curios how this all works

If you can i should avoid buying a VKrc2 an look for a normal krc2. you can work with a vkrc but there are some things to consider before buying one.

1. Hardware is different from normal krc, for example plugs on the bottom are not wired the same
2. No I/O, Vkrc are standard without any form of in and outputs. you can ad I/O by adding a devicenet module or something like that.
3. No automatic operation, only automatic external. this means that you either have to buy a plc with it to get it working ore wire a devicenet module with buttons and get it to work that way.
4. Software, the software is different from the standard krl. it may be a little bit harder to programm

The devicenet module i keep mensioning could also be profibus, interbus or something else. depends on what cards are installed.

I am back again with yet another question, and it seems to me that there is always someone here who knows the answer.
What i am trying to is writing a function for changing the tool on the robot but i am running in to some problems (This is the first time that i use a function).

I start with making a new program and selecting function as template, and after that entering the code that i think i need. this function shall be called from the main program in another src file

GLOBAL DEFFCT INT toolchange(tool_1,tool_2) ;two variables are needed, 1 to select where to place the current tool and the second to select the next tool.


INT tool_1,tool_2


IF (tool_1 == 1) THEN ;repeat this for the necessary number of tools( in my case this will be 5)
 ;move to position 1 and drop the tool there
ENDIF


IF(tool_2 == 1)THEN ;
  ;move to position 1 and pick up the tool there
ENDIF


RETURN(); nothing is returned
ENDFCT

Now for the problems:

1. When i enter the first line to define the function it disappears when i hit enter
2. When the line does not disappear i will get an error from the compiler stating that it is double declared.
3. The compiler also gives an error on ENDFCT stating that this command is not allowed, but when i remove it i get an error that the function is not properly closed.

i have used subprograms before without any problems by just calling the name of the program "subprogram()" an the subprogam could be in the same src file or in another and it would work. On the other hand when i try to call a function like this "function(1,2)" i get an error that the function is not defined. so i added EXTFCT before the call but then the compiler gives the error declaration in the wrong place.

I am working with a KRC2 with Ks 4.9. I have no idea what i am doing at the moment so any help is appreciated.

Thanks for the tip, I tested my code yesterday and it al seems to be working fine. I understand there can be some time differences but in this application i don't think it matters much. I will remember your idea though, may be useful somewhere else down the line.

The code as it works now.

IF $IN[12] THEN
  HIGH_SINGNAL = HIGH_SIGNAL + 1
  LOW_SIGNAL = 0
ELSE
  HIGH_SIGNAL = 0
  LOW_SIGNAL = LOWSIGNAL + 1
ENDIF


IF (HIGH_SIGNAL > 100) OR (LOW_SIGNAL > 100) THEN
  $OUT[17] = TRUE
ELSE
  $OUT[17] = FALSE
ENDIF

I used different variable names just to understand what i was doing when i read this in about a year . and more importanly i used 1 if/else structure in stead of 2 if structure. what seemed to happen was that in some cases both instances where true and the output would be blinking. When i changed it to a if/else structure this problem stopped.

about the pulse command, i could type it in by hand and i would get an error from the compiler. Or i used the function blocks to try an add it in and i would get an error that this function is not allowed in this file. maybe it only works when it is not directly in the sps.

To byto, Manuals can be found here http://www.robot-forum.com/rob…d-tools-for-kuka-robots/.

So i tried using the pulse command, but apperently i can't use that in the sps. Probably for the same reason that you can't use wait instructions. Thanks for the suggestion skyefire but i am going to look for another solution. What i think should work is something like this:

IF $IN[12] THEN ;Sensor input
B = B+1
C = 0
ENDIF

IF NOT $IN[12] THEN
B = 0
C = C+1
END IF

IF B > 100 THEN ; 100x0,012 sec = 1,2 sec
;Motor stopped with the signal high

IF C > 100 THEN
;Motor stopped with the signal low

in this way when the signal has not changed in 1,2 seconds it detects that the motor has stopped and it doesn't matter if the motor stops on a high or a low signal.

thanks for the idea, this could work very nicely. i probably wont have any problems with the high rpm's because i will have to wait on a signal from the motor driver that he is not sending any more power to the motor. after that it is simply a check if the motor actually has stopped. if i don't do that and activate tool change with even a slightly turning spindle.., well lets just say it would make some interesting noises.

hmmm, is was kind of going to use a wait instruction. To specify during a toolchange the spindle has to be completely stil. so on the spindle is a sensor is a signal which is giving 2 pulses every rotation. I had planned to use code like this to check if spindle was running:

A = Input[1]
wait 500 //milliseconds
B = Input[1]

If A == B
spindle has stopped
else
spindle is still running

I think i have to come up with something more clever then this then .