Posts by Fubini

    Hi,


    to cover the angle jump I would do the following:


    FrameResult = INV_POS(FrameA):FrameB should give $NULLFRAME if the positions and orientations are the same. Hence you should check:


    REAL EPSPOS=1E-5 ; Or whathever precision you need
    REAL EPSORI=1E-5 ; Or whathever precision you need
    IF ABS(FrameResult.X) > EPSPOS OR ABS(FrameResult.Y) > EPSPOS OR ... THEN
    ...
    ENDIF
    IF ABS(FrameResult.A) > EPSORI OR ABS(FrameResult.B) > EPSORI OR ... THEN
    ...
    ENDIF



    Fubini

    Hi,


    this is the wrong $machine.dat. There are two files called $machine.dat on the controller.


    The first one located in C:\KRC\ROBOTER\KRC\R1\Mada describing in part the machine.


    The second one located in C:\KRC\ROBOTER\KRC\STEU\Mada describing mainly IO related stuff.


    You sent the second one but the first one would be needed.


    Still better you could create an archive of your controller and send it here.


    Fubini

    Probably external kinematics might not be used asynchronous if they are defined as a robroot kinematic inside $machine.dat ($EX_KIN is set to #ERSYS). Have you tried setting $EX_KIN to #EASYS or EBSYS or ... or EFSYS instead?

    Hi,


    The EK function is for activating geometric coupling on calibrated external base kinematics predefined in R1/$machine.dat. Hence the $BASE is attached to the flange of a external base kinematic and the robot moves together with the external kinematic (the robot is attached to the chosen external kinematic).


    Die EK-function has the following syntax:


    $BASE = EK (<Root>, <Kinematic identifier>, <Offset>)

    where:


    <Root> = Position of external kinematic root in $WORLD
    <Kinematic identifier> = #EASYS or #EBSYS or ... or #EFSYS
    <Offset> = (optional) additional offset frame from the external kinematic flange


    (for examples see bas.src on you controller, which does set the correct $BASE for measuerd in external bases).

    Geometric coupling is deactivated by assigning a different $BASE:


    $BASE = <Frame>


    For RoboTeam/Motion Cooperation there is a similar command called LK(...) allowing you to attach a robot to another robot.


    For attaching on a conveyor the EB(...) command is used.


    Fubini

    Quote

    So, does this mean that on the KRC4 there's no longer any copy of the serial number, hour meter, etc, stored on the robot hard drive?


    Thats right. Cal-File and Pid-File are other examples. By the way: If you read the EPROM content to generate an archive/KRCDiag the created RDC-Folder on HD is deleted if you restart the controller.

    In KRC4 the serial number is not stored on HD. It is set by KUKA on the EPROM attached to your robot and plugged into the RDC. Hence the serial number now is unique for the robot and by plugging the EPROM into a new RDC the serial number always stays with the robot. Moreover a defect RDC does not require "programming" a new serial number anymore but simply plugging the EPROM into the new one. The RDC folder is only created in case you are creating an archive or a KRCDiag. In this cases the EPROM is read and the files on the EPROM are written on HD to be included in the archive/KRCDiag.

    Quote

    Can you really not specify a tool def for example as [0,0,0,0,120,0]?


    Of course you can. But this orientation is equal to {X 0,Y 0,Z 0,A 180,B 60,C 180} as you can see by entering {X 0.0, y 0.0, z 0.0, a 0.0, b 120, c 0.0}:$NULLFRAME in e.g. VarCor. Its just like sinus or cosinus functions which have a standard interval of [0,2pi], but any other interval of length 2pi will lead to the same results. Internally the controller always converts the orientation to the standardized intervals given previously by SkyeFire. On this standardized intervals the values A,B,C are unique (apart of the Euler singularity at B exactly +-90°, where only the sum of A and C is unique).


    Fubini

    Just to clear it up. KRC4 still has an interpolation cycle time of 12ms. But there is a new interface called "Fast Sensor Interface" running at 4ms allowing the sensors to run and apply corrections at a faster interval. If this fast mode is already supported by RSI I do not know for sure.


    Fubini

    Ah the correct English version of the message text for no. 1133 is "Gear torque exceeded axis %1".


    So you are only driving axis 6 using the buttons on the right hand side of the KCP? Did you check if somebody tampered with your machine data? Is the robot newly calibrated?
    Taking a look at your currently programmed loads might be helpfull too.


    Fubini

    Quote

    After I run my code they are:
    CP = 0.001
    ORI1 = 50
    ORI2 = 50


    I meant $VEL_C during execution in EXT when you robot is to fast, not after your program has finished. $VEL_C tells the programmed velocities of the currently executed motion (the one you see the robot doing at this moment). Hence this Test would reveal if in EXT somebody messed up your programmed data $VEL.

    Hi,


    All messages except KSS15014, do not prevent driving the robot. Hence try plugging in and out of the KCP.


    I have a list:
    KSS15014: KCP Connection Error (Connection to KCP is defective. Possibly caused by wrong disconnection.)
    KSS13015: <%1> Ethercat Bus-Scan Error. Device: %2 [%3] (Bus-Scan Error. Configured and physical Devices are different)
    KSS10041: %1: Profibus-Slave Configuration Error (%2%3) (Error in PB-Slave Configuration)
    KSS10015: %1 Bus Error %2 AddInfo %3 (Bus error with error special error code is detected)


    Fubini

    Hi,


    what you are looking for is the concept called base inside your robots controller. The robot always tries to reach the desired TCP position in the current base system. In your use case I would drive the robot where I would like to zero out and then set $BASE = $POS_ACT (=current tcp position based on the current base frame) setting the base to the current position. Hence all future positions (as long as $BASE is not assigned a new value) would be based on the origin of the base frame.


    Fubini

    Hi,


    probably APO_FAC is only there due to compatibility reasons. Parsing my BAS.SRC (which should use it if it has a meaning) finds no reference to this value. As already mentioned it was used to set blending params inside $APO.


    Fubini