Posts by Fubini

    Hi,


    Quote

    Do you have any detailed description about those functions, or is it the basic error response?


    See the attachment. This is the only description I could find in Englisch and seems to be quite old. I have a newer version too, unfortunatly only in german.


    Fubini

    Hi,


    -2: the second parameter of your FORWARD() call has not yet a value assigned, e.g. the VARSTATE would be DEFINED but not yet INITIALIZED. So if your forward call reads
    FORWARD($AXIS_ACT, ERR_STATUS)
    assign a value to ERR_STATUS before calling FORWARD. This value could be 1 if you want a software limit switch check or 0 otherwise.


    Fubini

    Hi,


    you are probably inside the axis 5 singularity. This is a issue specific for 6dof-robots (axis 4 and axis 6 are colinear). You can use the forum search with keyword "singularity" to get a lot of additional info.


    Fubini

    Hi,


    Quote

    Guys is only a stupid question, but is possible to bypass the stupid kuka user group to be always connected as expert? or is possible to set timeout time > than 5 minutes?


    just use the forum search function with keyword "Authentication.config"


    Fubini

    Hi,


    Quote

    @Skyfire I have start point, end point and the centre of the circle. I need to automatize the motion of bot and remove the manual feeding of point.


    So you have three points in a plane allowing you to calculate the circle normal by the plane normal and parametrising your circle using the circle parametric equation. This allows you to calculate any two positions of the circle that can be entered into the circ command.


    If you don't know how "plane normals" and circle represantations by a "circle parametric equation" are calculated you can use google leading to numerous results.


    Fubini

    Hi,


    ":" is the geometric operator equaling the multiplication of homogenous coordinate transformations (or frames).


    For applications just use the forum search function with "geometric operator" and you'll find many.


    Fubini

    Hi,


    the KRC runs dual operating systems (Windows for visualization and VxWorks for Realtime robot control). These two "brains" have to communicate with each other. In your case most probably the VxWorks side did not boot correct. Hence the Windows side still waits for the connection. For a more specified diagnose why VxWorks does not start you could use


    C:\Windows\System32\PuTTYtel.exe -vio -noflush


    inside a windows cmd-shell openeing a putty-Shell of the VxWorks-side and post the content. Otherwise you could look at C:\KRC\ROBOTER\LOG\System\<LogFileName_Timestamp.csv> containing a somewhat reduced version of what is shown in the putty. If all of the above requires to much expert knowledge you could generate a KRCDiag using the "green Start KRC" button in the taskbar and send the KRCDiag to KUKA for analysis.


    Fubini

    Hi,


    as mentioned by Skyefire remove global inside the interrupt declaration.


    Moreover $BWDSTART is only for backward motion (<Start -> button on KCP) using SCAN method. It marks the FOLD beginning for the controllers interpreter. Backward motion is a feature probably not yet available in your version. So just remove it.


    Fubini

    Hi,


    Quote

    How do I check the value of $SINGUL_DIST[]?


    In the menu use Display -> Variable -> Single and type $SINGUL_DIST[].


    Quote

    $SINGUL_POS[3]=1 to try and prevent A4 from rotating ~180°


    The axis 4 turning 180° is not only caused by the singularity but often also the wrist axis status requires turning a4 and a6 about 180°. This can be prevented (even though ist is not recommended by KUKA) by setting $POS_SWB[3] = 1 allowing a status change when driving through the axis 5 singularity.


    The reason it is not recommended is that if you drive close to the singularity the status changes takes places velocity based. Hence in T1 the change might not occur but in AUT. This basically can lead to unpredictable programm behavoiur.


    Fubini

    Hi,


    Quote

    (BAS_COMMAND :IN,REAL :IN )


    Calling a subroutine where the first parameter is a "call by value"-parameter of type BAS_COMMAND) and the second also a "call by value"-parameter of type real.


    I suggest in booking a KUKA robotics course for beginners.


    Fubini

    Hi,


    $SINGUL_POS[3] is for the third singularity a standard 6 axis robot can have (Index 1: axis one singularity, Index 2: a2-a3 singularity, Index 3 axis 5 singularity). Basically for the axis 5 singularity distance corresponds to a scaled axis 5 angle. Therefore the robot is "inside" the singularity whenever the value of $singul_dist[3] < 1.0 (about +-0.0181° a5 angle) . Did you check the value of $singul_dist[]? Otherwise the robot might still think "no singularity" and does nothing. The controller has different singularity strategies (as SkyeFire already posted), which one is chosen depends on a few system variables:


    [list type=decimal]

    • $CP_VEL_TYPE: reduce the axes velocities if axes get to fast: Hence check if $CP_VEL_TYPE=#VAR_ALL or #VAR_ALL_MODEL (in default case this feature is only in T1 active: $CP_VEL_TYPE=#VAR_T1)

    • $ORI_TYPE = #JOINT: This is the preferred solution if orientation control is not important, because your hand axes a4-a6 are planned ptp. Hence the axis 5 singularity does not exist any more. So by cheating orientation a5- singularity is avoided

    • $SINGUL_STRATEGY = 1. Try avoiding the singularity by changing orientation during interpolation (different approach than $ORI_TYPE=#joint, which already is used during planning!!!): This method is not recommended by KUKA, because the orientation change depends on the velocity (hence in T1 the orientation error might be small and in AUT/EXT much bigger)
    • $SINGUL_POS[]: If $singul_dist[] < 1.0 the first not unique defined axis angle is set to zero.

    [/list]


    So basically $SINGUL_POS[3] leeds inside the singularity area to a unique defined axis 4 = 0° and a axis 6 set corrspondingly. But this solves only the first problem that arises inside singularities (mathematically spoken there is a infinite number of valid axis position leading to the same cartesian position). The second problem inside singularities is the velocity problem which can be "solved" using $ORI_TYPE = #JOINT, $CP_VEL_TYPE or $SINGUL_STRATEGY .


    Fubini

    Hi,


    probably you had the following


    LIN SomePoint C_DIS
    PTP SomeOtherPoint
    CONTINUE
    $OUT[55] = true


    In this case the advance pointer is implicitly reduced to 1 (see $advance_c). This needs to be done because you need the axis positions close to (or at best at) the beginning of the approximation motion. These axis positions are not known beforehand because the system only calculates them during execution of the LIN-movement. Hence the LIN movements needs to be executed reasonably far for the system being able to plan the approximated motion connecting the LIN and PTP motion.


    Fubini

    How about this (not tested):


    DEFFCT REAL POW (X: IN, Y: IN)
    REAL X
    REAL ERG
    INT Y
    INT IDX


    ERG = X
    FOR IDX = 2 TO Y
    ERG = ERG*X
    ENDFOR


    RETURN ERG
    ENDFCT

    Quote

    Now I just need to be able to modify that Safety configuration to make it match the Machine.dat


    Sadly you can not modify the safe configuration, because it is generated automatically from your $machine.dat. Your only chance is modifing your $machine.dat to a configuration which generates a correct safety config. Hence still my advice: Try making E2 to E1 and external kinematic ET2 to ET1.


    Fubini

    You are lucky I'am native german: Take a look at your third attached picture. Here you see "External kinematic type" has value "EASYS" (meaning external base kinematic). This value should be "ERSYS" for your external robroot kinematic. This basically brings me back to my first post:


    Quote

    Did you try to switch external kinematics ET1 and ET2 ? As far as i remember there was/is a restriction for the KL (=ERSYS) always being the first external kinematic.


    Did you change your E2-axis to E1 and did you change your ET2 kinematic to kinematic ET1?


    Fubini

    Hi,


    I'll try again:
    For me your problem still sounds that the safety controller is not considerung your E2 axis which is contained in the external kinematic ET2. Furthermore your external kinematic is of robroot-type (ERSYS), that is in your case the robot is mounted on E2. Is this what you intended?
    Message KSS12032 "Robot Controller <-> safety controller, Cart. position deviation" is set if the standard controller has a different cartesian position (only x,y,z no orientation considered) than the safety controller. This check is doen because the standard controller and safety controller use different forward kinematics functions. Hence a consistency check is done. The maximal allowed deviation between standard and safety controller is as far as I know 20 mm (which fits perfectly to your +-19,99 mm deviation). By remastering your external axis you reset its axis value to zero and the forward kinematics equation of ET1 only gives $NULLFRAME as result, so basically you get the same result as if there is no external kinematic.


    To check this theory please check under Configuration->Safety Configuration->Machine Data (View) -> check machine date. If you get a message "the machine data of the safety configuration are up to date" please take a look at the listed machine data. If the safety controller integrated your external kinematic correctly the value "Axis Number for ROBROOT kinematic 1" should read "8", meaning the 8-th system axis (6 robot axes + 2 external axis) is used inside the safe controllers forward external kinemtics equation.


    Fubini