Posts by Koppel

    What I wrote above was pretty much the interaction I had with KUKA.

    Quote
    If the maximum axis velocity configured for T1 in the safety controller is lower than the maximum possible axis velocity $RED_T1*max., the reduction factor is automatically reduced to prevent the velocity monitoring from being triggered.

    This explanation is hinting why sometimes the T1 speedlimits are very very slow.
    I sent them my files and they pointed out the relevant parameters and gave links to explanations of these parameters. (some xpert.kuka.com page that expires in 14 days)


    But when I manually calculated and compared the parameters (3696 °/sec vs 30°/sec) they seem way off.
    I didn't want to adjust anything just yet, rather to understand beforehand what all of that means. Because currently the maximum velocity 30°/sec is way way lower than the $RED_VEL_AXC * $VEL_AXIS_MA.

    There is a quote from Panic mode in this thread:
    BAS function speed limit is cummulative in T1 mode and much slower than 250mm/s

    Quote

    PTP is the fastest motion... and this is why in T1 mode PTP is throttled more aggressively than other types of motion.


    but in some cases there is a bug and safety controller reduces speed even further. in such case in T1 mode PTP becomes really really slow, specially when approximated with CP motions... by doing BCO you can skip that super slow part and get straight to CP motion such as LIN and robot will move normally. solution is to contact KUKA. they will tell you how to fix this (for example by changing limits in safety controller or whatever).


    I think I am also hit with this bug.


    PTP motions are limited by a reduction factor ($RED_T1*max. axis velocity).


    If the maximum axis velocity configured for T1 in the safety controller is lower than the maximum possible axis velocity $RED_T1*max., the reduction factor is automatically reduced to prevent the velocity monitoring from being triggered.


    In my STEU > MADA > MACHINE.DAT file there are.


    $RED_VEL_AXC[1]=11

    $RED_VEL_AXC[2]=8

    $RED_VEL_AXC[3]=8

    $RED_VEL_AXC[4]=10


    These values are percentages of the maximum related to these. (values are in RPM)


    $VEL_AXIS_MA[1]=5600.00

    $VEL_AXIS_MA[2]=6000.00

    $VEL_AXIS_MA[3]=5224.99707

    $VEL_AXIS_MA[4]=4975.84521


    So for example the limit for the first axis would be 11% x 5600rpm = 616 rpm.
    I can divide this by 60 seconds = 616/60 = 10,26 rounds per second.

    I can multiply this by 360° = 10,26*360 = 3696 °/sec

    In my limits in the safety configuration are:


    A1 = 30°/sec

    A2 = 30°/sec

    A3 = 250mm/sec

    A4 = 30°/sec

    Basically what I understand I need my $RED_VEL_AXC[1] * $VEL_AXIS_MA[1] to be under the 30°/sec value and if it is not then the system reduces the speeds to ridiculous levels.


    The numbers are close to a 100 times out, so I don't know if there is a massive 100:1 planetary gearbox in there somewhere or what?

    What do you mean by "Safety controller" Is this some physical part of the Kuka cabinet? Can this be accesssed by WorkVisual or by TeachPendent or by modifying parameters in $MACHINE.DAT ?


    How can I change the limits in the safety controller?

    I am sure I have hit the "bug" you are referring to because Kuka help responded with:

    Quote

    If the maximum axis velocity configured for T1 in the safety controller is lower than the maximum possible axis velocity $RED_T1*max., the reduction factor is automatically reduced to prevent the velocity monitoring from being triggered.

    I do not understand how a link to this thread gives an answer on how to solve this problem.

    This thread has another link to German version of Robot Forum.


    Fubini wrote there:

    Quote

    The quick translation is as follows:

    This is due to reductions like $red_t1. This is added to the override in T1. If you have programmed slow speeds in a PTP movement, it will be even slower. By the way, this is no longer the case with Spline. There is always limited to 250 mm/s no matter if LIN or PTP, because there are no more factors like $red_t1.

    Such general factors usually have historical reasons. In the past, PTP could not be limited to Cartesian 250 mm/s as a pure movement in the axis space. In the meantime this is possible via $speed_limit_teach_mode. But for compatibility you won't get rid of the old method as default. But you can change it somewhere ($custom.dat?). I don't remember the name of the variable, $Red_t1_ov or something like that.


    I am not able to find any parameter called $red_t1


    Can we solve this problem, as this can be safety hazard because nobody will test a program in T1 if it is not working correctly and happens on all new robots straight out of the box.
    It's not like I did something to the robot to act like that... it's how they come out of the box.

    Hi,


    The PTP speed in T1 mode on the KSS 8.7 is unbearably slow.

    How slow? Well let me tell you with the speed test example I run on two systems.

    From Y -300 to Y 400 so a 700 mm running distance and measured the time in T1 mode while at 100% speed on the Teach Pendent.


    System 1:
    KSS 8.6.4

    KR C4 Compact

    KR10 R1100 Agilus 2 robot (A six axis one)


    System 2:

    KSS 8.7.4

    KR C5 Micro

    KR6 R700 Z200 (A four axis scara robot)



    The results.


    System 1 (KSS 8.6.4)
    PTP time: 9,684 sec

    SPTP time: 3,852 sec

    LIN time: 5760 sec (Path was close to singularities so slower then necessary)


    System 2 (KSS 8.7.4)

    PTP time: 47,508 sec

    SPTP time: 3,744 sec

    LIN time: 5,964 sec


    This is nor normal and causes the programmer to test the programs in other modes which is not a safe way to avoid collisions.

    Its over ten times slower than SPTP. Why?
    Considering this was a 700mm Point to point distance... the speed was 14,7 mm/sec ...

    The speed in T1 should be limited to 250mm/s


    What is going on?

    If the CELL.SRC requires the robot to be HOME then I cannot use the CELL.SRC to run a program to safely take me to home.


    If I just change the variable CHECK_HOME = FALSE ... no evaluation is done and the robot will accelerate directly to home with 100% velocity.


    Is it advisable then to get rid of both the

    ;FOLD CHECK HOME

    ;FOLD PTP HOME


    So that the CELL.SRC will start running the CASE loops.
    Then I can use my PLC logic to check if the robot is not Home I can run the "BringMeHomeSafely()" program.

    KSS 8.7 on a KRC5 micro.

    The robot complains that this Syntax is a problem and does not even let me open the file. Not even outside the KRC:\R1 folder


    When I try to copy the file to R1 folder, it says

    "File format not correct (header syntax).... "
    Originator: ReadHeader()


    I delete the GLOBAL and everything is fine.

    Code
    GLOBAL DEF OpenGrip ( )
    PULSE (PleaseOpenGripper, TRUE, 3600)
    WAIT FOR GripperOpen
    PleaseOpenGripper = FALSE
    END


    So how do I create small programs that can be called from larger programs globally?

    "1. map some IO between PLC and KRC"

    DONE


    "2. configure on robot side AutoExternal interface (this is covered in KUKA programming 1)"

    DONE


    "3. create PLC logic to handle AutoExternal interface"

    I usually enable the REFLECT_PROG_NR and I compare what I want with the one that is reflected and if they match I send. PGNO_VALID... Is this what you mean?

    "4. create KRL code that will check if correct program is selected. if not correct - deselect it. if no program is selected, select one you want. this uses CWRITE commands and example is already inside CELL.SRC but it is before the loop. i like to do this inside the loop so it ALWAYS works, not only on boot."

    KRL code?

    "5. select EXT mode (this is still manual but controller will remember it...)"


    "6. there is no BCO mode in EXT mode (even if there is a message telling otherwise). this means when you tell robot to move in EXT it immediately moves at programmed speed. So if robot is not already at home you need to either abort and ask for human intervention OR you need to create own program that can safely bring robot to home position from anywhere. this can be tricky and it is meant for advanced programmers only. If you take KUKA training, this is covered in 3rd programming course."


    I cannot find "Programming 3" And we have attended Programming 1 and 2.

    Robot programmers | KUKA College

    Any feedback on this PTP vs SPTP speed difference in T1 mode?

    Hi,


    I have an enclosed production cell. A Siemens S7-1500 is the master controller with a Siemens HMI.

    Operator safety signal is wired through the safety door relays - so no safety risk

    KRC5 micro with a new KR Scara robot. KSS 8.7


    I want to be able to just turn on the production cell without the operator needing to go and press "Acknowledge general motion enable" , picking the right program, doing the BCO run and setting the robot to EXT mode. So the operator only operates the Siemens HMI and not the robot Teach Pendent.


    I know you can somehow automatically start a program with SPS.SUB

    I can run an interrupt program that can go from $POS_INT to a directly high safe Z positon and to XHOME.


    Can you guys point me to the right direction?

    ... and make sure the IO Device is activated if you're planning to use a Siemens PLC as PN Master and KRC5 as PN slave IO device.

    Connect the PLC to the KRC5 on KLI2 and then assign a PN name from accessible devices from the TIA portal.

    What do you mean "make sure the IO Device is activated" ?

    What do you mean "Connect the PLC to the KRC5 on KLI2"? I have just "KLI" tab under Start-up > Network Configuration


    I connected the PLC to the XF5 port on the robot controller, set a Fixed IP address to the controller. I can ping this address just fine with my laptop.

    I added PROFINET to the Bus structure in WorkVisual and deployed the project back to the controller

    I added the KRC5 GSDML file in TIA Portal.

    I set the IP address in TIA Portal to match the one in the controller.


    Still "Not reachable"


    EDIT:
    Ok... so under WorkVisual I had to right click on PROFINET under the Bus Structure, choose "Settings" and put a checkmark infront of "Activate PROFINET device stack" and have the Profinet device name also match with the one in TIA Portal.


    XF5 port seems fine for the communication. The device is now green in TIA Portal.


    First time using a KRC 5 micro aswell.


    Imported the project from controller in WorkVisual.

    There is no "PROFINET" under the Bus structure or under the "Fieldbusses" tab.


    How do I do the IO mapping to profinet?

    Profinet S v6.0.4 installed on the robot and the option package is also installed in WorkVisual v6.0.24 build 1632.

    I think I managed to delete half of my post before posting.

    A new Scara robot with KSS 8.7.4, straight out of the box.


    A blank SRC file with just:

    BAS(#INITMOV, 0)
    SPTP XHOME

    SPTP MYPOINT
    SPTP XHOME


    Is behaving like expected... ca 250 mm/s in T1 mode.


    Whereas the same thing with PTP movements is like 10 times slower.

    BAS(#INITMOV, 0)

    PTP XHOME

    PTP MYPOINT

    PTP XHOME


    No problems with speed in T2 on AUT modes.

    So what is the solution then? I also got a new robot and the PTP speeds in T1 mode are unbearably slow.

    SPTP movements have a reasonable speed.


    I cannot find what Fubini said.

    Quote

    But you can change it somewhere ($custom.dat?). I don't remember the name of the variable, $Red_t1_ov or something like that.


    Do I just change all the PTP movements to SPTP or is there a better solution?

    Yeah...you guys got me.

    At first I was... "order of points matter" ... how can that be, the software asks for the points in a specific order that I follow.


    BUT... I wanted the origin to be at the top left corner hence the flipping of the Z.

    As this cannot be I have to resort to the origin being at the bottom left corner.


    Thank you guys!

    Hi,


    KSS 8.5


    I am starting to work with different BASE systems and shifting frames for palletizing. So far I have managed to avoid using different BASES, I have just calculated new coordinates for the next part to pick and everything was in WORLD coordinates.

    Now I have a project where using BASES makes sense.

    However when I create a new base using "calibrate" with the 3-point method (touch up the origin, the X axis and the XY plane) the Z axis is pointed downwards. :S

    This annoys me because the approach positions for picking are meant to be above the surface... so the Z value should be higher when I go up.

    It is illogical to have the approach point at -100mm, this creates many opportunites for typos and crashes.


    At first I thought this is dependent on the tool I use to teach this base. If the tool has its Z the other way around, than so might be with the base. But this was not true. I tried both ways and still the C angle was 180 degrees, therefor flipped.


    I thought that if I dont mess with the angles myself and use a calibrated tool and a calibrated base using that tool, everything would be as standardized as possible.


    Am I doing something wrong?

    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?