Posts by Koppel

    I have done that before.

    Basically the Search is inside a REPEAT ... UNTIL

    Code
    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...."

    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...

    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.

    ...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.

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

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

    I was absolutely sure that I was dealing with m/s2 ... 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.



    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?