Posts by Koppel

Quote from micahstuh

PTP moves do not refer to the $VEL variable for speed. They refer to $VEL_AXIS which has a component for A1-A6 expressing the percent speed limit from 0 to 100.

But what is BAS(#VEL_PTP, 20) referring to? Its 20% of something.

I know

$VEL.AXIS

Velocity of the robot axes in the advance run

The variable contains the programmed axis velocity as a percentage of the

maximum axis velocity $VEL_AXIS_MA defined in the machine data (variable in the file …R1\Mada\$machine.dat

And in this File I have

$VEL_AXIS_MA[1]=6000.0

$VEL_AXIS_MA[2]=6000.0

$VEL_AXIS_MA[3]=7999.2

$VEL_AXIS_MA[4]=6000.0

$VEL_AXIS_MA[5]=5796.52148

$VEL_AXIS_MA[6]=7288.8335

What units are used in this file? 6000 degrees per second?

I knew about it like a year ago... and now I cannot find what is limiting my speeds. I remember there are some limits in the BAS function, and when exceeded a default value is used.
So this time I want to document all the different ways the speed of a robot can be limited.

Is there a good way to visualize the actual speed values during a running program. The oscilloscope feature maybe?

Ok.
So there is no way to change the address in the "Address" column, only the name.

Like you have for "Q140.0 Move Enable" but the address showing 2.0.

No way to make this "Address column" show 140.0 aswell?

When using the IO Mapping editor in WorkVisual, the Profinet addresses have a weird format.
The first input has in the Name column "02:01:0001 Input" ... and in the Address column "18.0"

The next ...0002 and 18.1

And the next 0003 and 18.2 ...

Where does this start address "18.0" come from?

From the PLC side I assign a starting address for KUKA inputs and outputs so my 0001 input becomes to the PLC maybe Q140.0 ... the next one Q140.1 etc.

Can I change the 18.0 so that it will match my actual PLC addresses?
Figuring out what address my Profinet 0072 Input has on the PLC side is annoying.

Greetings from a fellow estonian.

Are you sure you cannot do the "by the book" solution with essentially three programs.

- Main()

- search()

- found()

The concept is that you declare the interrupt in the main program.

Call a search() from your main program

The interrupt is turned ON in the search program

This search program is tasked to go to the bottom of your stack... PTP SeachEnd. (You are just looping Z -10mm)

You have a "WAIT FOR TRUE" at the end to prevent the advance run pointer to process anything more.

"When the RESUME statement is activated, the advance run pointer must not
be at the level where the current interrupt was declared. To prevent this, an
advance run stop is triggered here via WAIT FOR TRUE."

DEF PROG()
INI
...
INTERRUPT DECL 21 WHEN $IN[15] DO FOUND()
PTP HOME
...
SEARCH()
...
END

DEF SEARCH()
INTERRUPT ON 21
SPLINE 
SPL START_SEARCH 
SPL IN_BETWEEN 
SPL END_SEARCH
ENDSPLINE
WAIT FOR TRUE
...
END

You have a third program Found() that turns the Interrupt OFF, brakes and reverses back to the point where the interrupt was called because braking takes some time and distance.

DEF FOUND()
INTERRUPT OFF 21
BRAKE
LIN $POS_INT
... ;The robot grips the found part.
RESUME
END

RESUME causes the main program to be resumed after the part has been
gripped. Without the RESUME statement, the subprogram SEARCH() would
be resumed after END.

I have done that before.

Basically the Search is inside a REPEAT ... UNTIL

REPEAT
SearchSomething()

    IF $IN[10]==FALSE THEN        ;sensor telling that grabbing was not successful
    PTP SearchStart                ;Go back to the beginning
        $OUT[19]=TRUE             ;tell PLC there was a problem       
        WAIT FOR $IN[17]            ;Wait signal from PLC to try again    
         $OUT[19]=FALSE             ;stop telling there was a problem
    ENDIF
UNTIL $IN[10] == TRUE

I think what "bersihe" is wondering about is "optimized access DB-s" that no longer have a defined location in memory... therefor no specific "address"

They are called out by variable name.

But you cannot link a DB value in Siemens to a Kuka robot directly.

You may have a DB entry "MyValue" that is equal to "123" of the type "integer" that is 16 bits long.

Then you have an OUTPUT to the KUKA robot... a Tag in the Tag table, named "MyOutputToKuka" with an address like "%QW12"

That is essentially 16 bits starting from byte nr 12. So 12.0 ... 12.1 ... to 13.7

Then you use a MOVE block where:
INPUT is the "MyValue"

and OUTPUT is "MyOutputToKuka"

And you have to have your mapping done with WorkVisual so that the signals from Siemens PLC output will end up in the correct place for KUKA inputs.

NB! ... 32 bit Integers are better. By default Kuka then handles negative numbers correctly.

NB! ... You still have to worry about Big/Little endian.

My adventures in sending a signal to KUKA: How to access/use the Signal editor in WV

I don't see an actual question in your post.

More information about what?

You need a robot - you picked one out.

You need a turn table if the robot cannot reach all sides of your part - you planned on using one.

You need a milling attachment/tool/spindle

Maybe a KUKA.CNC software package:
https://www.kuka.com/en-de/pro…ication-software/kuka_cnc

Your sales representative can take care of you and provide the necessary equipment required together with pricing.

May I add that the System ingegrators manual may be better than the "Expert programming manual"
You can download it from this thread... post nr 10.

Kuka Downloads (software, cad...)

Example on page 359.

"The robot is to search for a part on a path. The part is detected by means of a

sensor at input 15. Once the part has been found, the robot is not to continue
to the end point of the path, but to return to the interrupt position and pick up
the part...."

Quote from dddomodossola

When you run the application, it converts the robot code into python

Quote from dddomodossola

I created it to run kuka robot code in case of no simulator available.

Do I understand correctly that I can write code in KRL and this thing converts it into Python... and I can run the Python code to simulate the robot in RoboDK?

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/ind…ka-robots-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/ro…6-sps-submit-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