Posts by Koppel

Hi,

When trying to deploy an older KSS version project I was able to see the new controller by manually changing the KSS version from 8.6.4 to 8.6.6. But this is where my progress stopped.

Trying to then deploy the project prompted a warning that the Controller name is different on the target and suggested to rename it. So I renamed my new controller to have the same name "kuka-noname"

Rebooted the controller and tried again.

Now it also has a problem with the CELL name of the project and the target.

And also Option "KUKA PROFINET S" cannot be downgraded.

I have attached an image of the conflicts.

I have never tried to deploy a project from a different robot. I have just taken a project from the controller, modified it and sent it back to the controller.

But if I had 10 copies of the same cell, it would make sense to do the work once and use the same project for all. Why do the cell and controller name have to match?

EDIT: I also tried to Export IO connections and import them on the new project... Resulted in "Error on import" !?

Something is messed up in the software. I take a the unaltered project from the new, fresh out of the box controller. Why would I be not able to see ANY addresses under PROFINET. Its impossible to map things together if one side is not showing anything.

EDIT2: Well... I uninstalled my WorkVisual 6.0.5 and installed Workvisual 6.0.14... Guess what. It works now!
But... I don't know if others have the same issue with it... I still have to open the software two times for it to actually open up. Was the same also with version 6.0.5.

EDIT3: Ok.. so even editing the IO mapping manually and deploying the project back to the controller fails. When changing the IO-s and deploying... the first step is Code generation... and this thing says "Starting code generation" and then immediately "The code generation was cancelled" ... why was it cancelled... I certainly didn't cancel it. What is going on with this software?
Wait...wait... KUKA.PROFINET S v 5.0.2 is not installed in WorkVisual... How do I install it? I think I had to import the corresponding GSD file. File ... Import GSD...

Ok... the one inside the installation folder doesn't cut it. I must find a newer one. I guess it was somewhere inside the controller itself.
So it was the *.KOP file that I had to fish out of the controller. "KUKA.PROFINET S.KOP" and install in WorkVisual by going Extras > Option Package Management and press the rightmost PLUS sign "Add a new option package from a file"
So finally I was able to complete the mapping.

I guess that using the Import/Export features for IO mapping and for files should be the best way to share content between robots. I didn't find TOOL and BASE in the Export options. How are these shared? Export Partitial Project ?

... resurrecting an ancient thread here.

I have a project form KSS version 8.6.4 ... and I want to put it on a new robot with KSS version 8.6.6
I have the software Workvisual 6.0.5_Build0492 (Build time 08 October 2019)

At first I just wanted to do the IO mapping for the new project but the Fieldbusses show no IO-s. Nothing under PROFINET, Nothing under EM8905-1001 I/O-Modul. I could just see the digital inputs and outputs of the KRC.

That seemed weird... and I think this might be that the WorkVisual software needs to be updated... does it?

And I then probably also cannot Deploy an older project to the newer controller also, right?

Because this was my second thought... if I cannot change the current one, can I just deploy the old one to the new robot.

Most up to date WorkVisual is "KUKA.WorkVisual_V6.0.14_Build0654.zip"
Modified: 12/04/2020 4:08PM

The software never tells me that something is too old or incompatible...

Quote from Florida

Correct!

But you can use TRIGGER WHEN DISTANCE together with PTP motions...

Hmm... for my ball throwing demo I should try it.

TRIGGER WHEN DISTANCE=0 DELAY=1234 DO $OUT[1]=TRUE

So after 1234 milliseconds the output is switched while the robot is still moving.

The thing to notice is that the variable tricks you into thinking that distance is actually distance... but its just either "0" or "1" meaning just the starting point or end point.

Plus... if the end point is approximated and I use no delay, the TRIGGER switches "in the middle of the approximate positioning arc"

TRIGGER WHEN DISTANCE=1 DELAY=0 DO $OUT[1]=TRUE

So is might be the optimum place when throwing things.

But to answer @Ayoub,

You can use the TRIGGER WHEN PATH inside splines but they have to be SCIRC or SLIN.

I ran into a similar problem once.

I wanted to create a ball throwing robot and wanted to release the gripper while the robot was still moving.

TRIGGER WHEN PATH=-100 DELAY=0 DO...

Only works with linear or circular motions. Calculating the length of a path that is a weird shape is something that KUKA cannot handle I guess.

Why on earth do you have different parts on different heights?

Why are you doing the fiducial calibration multiple times for different parts.

You can have one COGNEX program that turns on a specific pattern to search based on an input.

Just calibrate the COGNEX camera to give out values based on the robot coordinate system. Pixel coordinates to World coordinates.

The static COGNEX camera will find where the pattern is that you are looking for.... the X / Y and rotation.

And you just transfer the X, Y and rotation values to the KUKA.
The robot will go to this location without any conversation.

Now for the camera that is attached to the robot... the Keyence. Define a new tool for that. So that the tool center point is not the tip of the camera lens but the target location. Like a really long invisible tool...
When you command the robot to use this tool and go directly to the position that CONGEX sent you... you will look directly at the part. Even if you set some weird angles to the tool... it will still be focused on the part.

I find it really difficult to understand what you try to achieve.

Ok... I think I understand.

The Congex overhead just gets the location of the part.

The Keyence camera is mounted on the robot and only shows the correct part when the camera is directly overhead.

When you rotate the TCP the Keyence will no longer look directly at the part.

If the Keyence is always looking at say a 45° angle, you can apply a constant XY coordinate correction to make the part appear into frame again.

Its just Pythagorean theorem twice. Once for the X offset and once for the Y offset.

Just offset the tool in a way that the tool center point is is the target.

Then when you rotate the TCP the part is always centered in the KEYENCE camera.

And the COGNEX always sends the robot to the same coordinate.

I have used "Transfer done" bit.

Kuka says "Program 7 is completed" by turning on $OUT[7]

PLC looks for this signal and says "I got the message" bit.

Kuka looks for this signal from the PLC and turns $OUT[7] false again.

PLC looks for this signal to turn false and then turns off its "I got the message" bit.

And I have used PULSE output for a very long period... because if the communication goes bad, the outputs will not remain ON if you kill the program.

PULSE($OUT[7],TRUE,999999)

Whereas using just $OUT[7]=TRUE ... it will remain true even if you exit the program. And you may do that if the PLC is not switched on or the communication between them is not working.

Is there not a robot specifically designed for welding applications.

https://www.kuka.com/en-gb/industri…for-arc-welding

KR CYBERTECH ARC ... series maybe?

Quote from BOTTECH

...restrict the robots movement inside a guarded space ....

... if someone was to re teach a position or move the robot outside this area....

I understand that this will not fulfill safety restrictions... only SafeOperation package will, and BOTTECH also knows this.

I thought BOTTECH wanted a solution where someone in T1 mode would not crash into the safety fence or adjust positions in a way that could do this.

Hi,

Perhaps in the SPS.SUB you can create a signal that sends $POS_ACT to the PLC.

And on the PLC side you trigger a SAFETY STOP if the X or Y value is too much.

Something like this is discussed before: Monitor robot position through IO

Discussion and risks about doing this in the German Robot Forum... Chrome can translate: https://www.roboterforum.de/roboter-forum/…it-schmiert-ab/

Most of my confusion came from mixing up the units.... % and m/s² like panic mode pointed out.

Quote from panic mode

BAS(#ACC_CP, 100) ; unit is % - unlike $ACC.CP which is in m/s2

I was absolutely sure that I was dealing with m/s² ... and bumping up the numbers was such a small change that I perceived nothing.

I tried CIRC, SLIN, LIN ... everything seemed to not get faster than some limit.

Ok. I made a little speed test with timers. Code below.

Basically a linear race for 1600mm... Y -800 to Y 800... back-and-forth with three speeds.

1m/s = 2148 ms

2m/s = 1788 ms

3m/s = 1788 ms

We can clearly see that the speed limit in CONFIG.DAT (2 m/s) is kicking in - a limit that I was not aware of before and am happy to have learned about.

And even with 50% acceleration the results are almost the same:

1m/s = 2580 ms

2m/s = 2472 ms

3m/s = 2472 ms

And that was at a 1600mm track. Easy to make the conclusion that changing the speed numbers made no difference. And also changing the acceleration at very low values made no noticeable difference.

Once again... Thank you "panic mode" for pointing out my noob mistake.

DEF LIN_SpeedTest( )

  BAS (#INITMOV,0 )

SPTP xHOME
BAS (#VEL_PTP, 20)
BAS (#ACC_PTP, 10)
BAS (#VEL_CP,1)
BAS (#ACC_CP,100)
$ADVANCE = 0
$TIMER[1]=0
$TIMER[2]=0
$TIMER[3]=0

PTP {X 400, Y 800, Z 200, A 0, B 0, C -180}
BAS (#VEL_CP,1)
$TIMER_STOP[1]=FALSE
LIN {X 400, Y -800, Z 200, A 0, B 0, C -180}
$TIMER_STOP[1]=TRUE

BAS (#VEL_CP,2)
$TIMER_STOP[2]=FALSE
LIN {X 400, Y 800, Z 200, A 0, B 0, C -180}
$TIMER_STOP[2]=TRUE

BAS (#VEL_CP,3)
$TIMER_STOP[3]=FALSE
LIN {X 400, Y -800, Z 200, A 0, B 0, C -180}
$TIMER_STOP[3]=TRUE

SPTP xHOME
END

Hi...

In the $CONFIG.DAT file:

• DEF_VEL_CP=2.0 [m/sec]
• DEF_ACC_CP=2.3 [m/sec^2]

These must be the default values from the factory.

Can we conclude that this was my limiting factor and no matter what I set with BAS (#VEL_CP, ????? ) it will not go higher than the limit set in config.dat?

Thank you Fubini !

I don't think you guys are getting what I try to communicate.
I will make a better attempt.

BAS (#VEL_CP,0.1)

BAS (#ACC_CP,1)

RESULT: Robot is moving slowly

BAS (#VEL_CP,0.5)

BAS (#ACC_CP,1)

RESULT: Robot is moving faster than before

BAS (#VEL_CP,1)

BAS (#ACC_CP,1)

RESULT: Robot is moving faster than before

BAS (#VEL_CP,2)

BAS (#ACC_CP,2)

RESULT: Robot is not moving faster than before

BAS (#VEL_CP,20)

BAS (#ACC_CP,20)

RESULT: Robot is not moving faster than before

So changing the values work... but it seems to hit a limit. There seems to be a difference between BAS (#VEL_CP,1) and BAS (#VEL_CP,2) but I am not sure.

There definitely is no difference between BAS (#VEL_CP,2) and BAS (#VEL_CP,20) even If I increase the acceleration aswell...

The question is... What could possibly limit this that I am not aware of? It was not the acceleration. I started doubling both the speed and the acceleration with no apparent effects. I increased the length of the linear trajectory to give the robot more time to accelerate... still no difference.

I do not have SafeOperation.

The same limitation applied for SPLINES... (SLIN) faster than 1m/s seems impossible... I can increase the value but the speed does not increase.

I use an Agilus 2 KR10 R1100 robot with a KRC4 compact controller.

Is there perhaps a limit for the ability of the Controller / Encoders... that cannot assure a perfectly linear or circular motion if the speed is increased.
The robot has to move all of its 6-axes in degrees... and the sum of them all must assure the linearity of the tool center point. Not a simple task at all.

Hi,

What is the limiting factor if I cannot get the CIRC motion (probably LIN aswell) to be faster than seemingly T1 speeds.

At the beginning of my program I have.

BAS (#INITMOV, 0)

SPTP xHOME

BAS (#VEL_PTP, 20)

BAS (#ACC_PTP,10)

BAS (#VEL_CP,1)

VAS (#ACC_CP,1)

Playing with the VEL_CP and ACC_CP values makes a difference but it seems to hit a limit... It will not go faster... I can set VEL_CP to be 10m/s (36 kmh) and ACC_CP to 2 m/s^2...
The thing should go like a rocket... but its still super slow.
All the PTP motions react to VEL_PTP and ACC_PTP changes as expected.

What are the hidden limiting factors here?

Quote from MOM

Koppel

can you give an example of how and why updating your coordinates?

Do you want to do this only once in a while, or more frequently?

We are building a duplicate of a machine and need to go over the positions inside nests for the new machine.
Ideally this points adjustment would be required just once but in practice the the very best position is determined by running the machine for a while and doing small adjustmets here and there.

Quote from panic mode

....if the point is declared as one of AXIS types just say the new value is $AXIS_ACT

and if it is Cartesian, just say tat new value is $AXIS_POS.

You said $AXIS_POS ... and that was not available... I guess it was a typo on your behalf and you meant to say $POS_ACT

My variable was always available and I got the same results as on the images.

How do you not get the external axis coordinates when transfer $POS_ACT values to your POS_PT3.

Is it because your point was declared as POS and not E6POS.

I think I got the external axis values (E1 0.0, E2 0.0 ....) on both cases. I might remember incorrectly though.

The question about the digits was purely visual. I could just glance over my point coordinates and get an idea where they are. If things are displayed on multiple rows with six decimal places, it gets visually overloaded and difficult.

I think the method "panic mode" shared is fantastic and straight to the point. Exactly what I hoped for. Thank you!

Hi,

I wanted to test the Single Variable Monitor method.

• I wrote the name of my point to the "NAME:" area... pressed "update" and it showed the coordinate values.
• I wrote "$AXIS_POS" in the "NEW VALUE:" area... pressed "Set Value" but got the error "Object is not available"

I was wondering why $AXIS_POS is not available... but... it should be $POS_ACT ... and then it worked.

The method is much, much faster than doing it manually. Thank you panicmode!

Sidequestion...

Is there a way to limit the decimal places of "$POS_ACT" ... X 595.886108 seems a bit exessive... I used one decimal place for my manual coordinates and things looked a lot cleaner... X 595.9 is good enough for me. I don't need to know the last nanometer.

Hi,

I don't understand what is supposed to happen when I choose "Select target"

What I have done:

• Import my SRC file with points as "PTP {X 0, Y 500, Z 450, A 0, B 40, C -180}"
• I right click on one of the Move-es inside the program that was created in RoboDK and pick "Select target" and then a target is created with the same name as the move "T MoveJ 1"
• If I right click on many of the Move-es inside the program, right click and choose "Select targets" ... then many targets with the same name are created.

... I guess I understand what is supposed to happen... but I don't understand how this is useful?
Seems like just another way to import targets...

What I would like to have is a trick that would enable me to kind of use the points in a SRC file in the format of "PTP Point1"... "PTP Point2" ... etc.

Where the coordinates are in a DAT file.

I wondered if I already had a TARGET named "Point1" and I then import the SRC file... that it would somehow pick up the relationship but it didn't.

I tested another way.

• import all my points as Targets
• Open the SRC file that has the "bad" format "PTP Point1"... "PTP Point2"
• RoboDK tells me "Failed to retrieve target (line 7):PTP Point1" ... for all the lines and doesn't import anything.

I was expecting to exchange the failed points with my previously imported targets and then at least make the sequence of the movements work.

I guess I have to manually recreate my program in RoboDK by importing all the points in my DAT file and then create new program and adding "Set reference frame instruction" between the points when nessessary

Hi,

If I don't use inline forms in my SRC file and all my points are defined in a global DAT file, how can I conveniently update the coordinates?

MY SRC File:

...

PTP Point1

LIN Point2

PTP Point3

PTP Point4

...

So far I have just:

• Move the robot to the desired position, using the right tool and the right base coordinate system
• On the HMI look at "Display > Actual position"
• Manually write these positions to the Global DAT file

Is there a better way?