Posts by sloopkogel

  • minimum distance between points for a given speed

    hermann , the only reason is to simplify the case for this example. This is not a real life problem I'm trying to solve, because I have edited my program to have the points spaced out far enough so that the velocity does not drop, this topic is only intended to get a better understanding of why this is necessary.


    Fubini , I do not understand, why would acceleration / deceleration be an issue? The robot does not stop / delecerate / accelerate in between the points

  • minimum distance between points for a given speed

    I have a question regarding moving the robot through a lot of points, for example when using the robot for milling / plasma cutting and the robot has to follow a path created by some sort of post processor. When the points are too close to eachother (the points are too 'dense') the tool will move slower than the commanded velocity.

    For instance, this code will be executed 'normally', with the commanded velocity:


    Using this code however, the robot will move much slower:


    I have 2 questions about this behavior:

    1: Am I correct in assuming that the reason for this, is that the advance pointer cannot look ahead far enough within the cycle time of the internal clock, which I beleive is 12ms?

    2: How does one determine the minimum distance between two points before the velocity drops below the commanded velocity? If statement 1 is correct then I beleive it could be as simple as Commanded velocity / (1000 / 12) ? Or is it more complex, and is trial and error the only way to find out the minimum distance between 2 points

    I am aware that putting the motion commands in a spline block can fix this problem, but this is not possible in my case, because in my application I sometimes need the robot to start at a given point instead of the first line (this is possible in my case because I use an array of E6Pos that I loop through instead of the code provided in the example)

  • Send live axis position with ethercat to PLC < 12ms

    Thanks for the replies guys.

    panic mode,

    The reason I want it to update so fast (ideally every millisecond) is that I control the servodrive directly with the PLC. The PLC has a built in motion controller that runs on 1 millisecond. The servo position is coupled to the external axis position that is sent by Kuka. I don't just send the target pos to the PLC but the actual position, and couple the servomotor to that position. If the update only happens every 12ms the motion is 'stuttering' (for lack of a better word..), I have solved this now by applying a 12ms filter. This works with the only drawback that the motion lags 12ms behind what it should be.

    hermann,

    In hindsight, this might have been a better solution.

    Just to clarify, there is no real necessity to update the position this fast for this specific application, but I would like to know my options if I ever encounter a similar application where I do need the fast update.

  • Send live axis position with ethercat to PLC < 12ms

    Hello all,

    I have an external axis setup that is controlled by a PLC. The reason for this is that this axis has to be controlled by either the PLC or by the robot. In the robot I have configured the external axis as a 'simulated axis', and in a submit interpreter I send the axis position to the PLC (t = $axis_act.e1), the PLC then controls the servodrive. This works fine for this application, but the update frequency is quite slow, in the future if I want to use this approach again I would like the position to update faster. The submit interpreter will always run at 12ms minimum so with my current solution the update will never be faster then this.

    Controller: KRC5

    From what I understand my options are:

    Option 1: Send the axis position through ethercat, using a submit (my current solution)

    - Minimum cycle time: 12ms

    - Cost: Free (assuming I already have Ethercat setup for PLC communication)

    Option 2: Using Kuka Ethernet KRL ? (or is this a bad idea?)

    - Minimum cycle time: ? unknown, although from what I've heard, probably not verry fast, so not a good idea

    - Cost: Paid, reasonable price

    Option 3: Kuka RSI

    - Minimum cycle time: ? From what I've heard minimum 4ms?

    - Cost: Paid, reasonable price

    Option 4: Kuka FSD

    - Minimum cycle time: 1ms

    - Cost: Paid, verry expensive (too expensive for this application)

    Option 5: ???

    Any other ways to send data (preferably using ethercat) faster then the submit interpreter cycle time that don't cost an arm and a leg? Does anyone know the update time for the system variable $axis_act.e1? Is this < 12ms?

  • Interrupt changes advance run behaviour?

    Quote from panic mode

    sounds you run into a bug. blending P6/P7 should not be affected.

    the only thing i would do is make sure to turn off interrupt after search... you only turn it off IF the interrupt is triggered. but that can be disastrous as possibly robot or program may crash if interrupt trigger did not occur during expected search but some time later.
    there should be line in side SEARCH() directly after SEARCHMOVE() to do just that.

    Thanks for the input. I have included INTERRUPT OFF 5 in the SearchMove() program (line 10), doesn't this not accomlish what you are suggesting? If the interrupt triggers then INTERRUPT OFF 5 will be called in the interrupt subroutine, if it doesn't get triggered then INTERRUPT OFF 5 will be called at the end of SearchMove()

  • Interrupt changes advance run behaviour?

    I have written a program and wanted to try it out in KukaSim. The program is working fine but after I trigger an interrupt, non of the motions will blend anymore. I have created a simplified version of the program to replicate the problem

    Main:


    Search:

    Code
    DEF  Search ( )
   INTERRUPT DECL 5 WHEN $IN[1] DO SearchInterrupt()
   SearchMove()
END

    SearchMove:

    SearchInterrupt:

    Code
    DEF SearchInterrupt ( )
   INTERRUPT OFF 5
   BRAKE
   RESUME
END

    If I comment out 'Search()' in the main program then the blending of the motions after the 'Search()' call work fine, if I call Search() (and therefore the interrupt) then every motion afterwards will not blend anymore. I also get the following message in the output of KukaSim at the point where the blending is supposed to start:

    KR 10 R1440-2: RRS OP 118 (GetNextStep) message: Approximation not possible

    I have checked $ADVANCE, and it is always 1, I also tried forcing $ADVANCE = 1 after calling Search(), didn't change anything

    - Am I doing something wrong?

    - Is this behaviour to be expected after triggering an interrupt?

    - Or is this probably a KukaSim shortcoming / bug?

    KRC5 KSS 8.7.5 (simulated in Kuka.Sim 4.3)

  • Kuka.Sim 4.3 $ACT_POS_MES not working

    My previous posts might have been a bit confusing. I wanted to use the same program (Pick() and Place()) for both automatic and manual mode. That's why I needed the motion to be able to blend. I have since split up the program in automatic and manual sequence so there is no need for blending with $POS_ACT_MES anymore

  • Kuka.Sim 4.3 $ACT_POS_MES not working

    Quote from Fubini

    One possible solution is to let the controller do it for you:

    Code
    lin_rel {z 100} #tool

    moves up 100 mm in tool z direction.

    Fubini

    But I need to move to an absolute position, not a relative position

    For instance, pallet 1 has a height of 300mm, pallet 2 has a height of 700mm, I want the robot to move to 700mm + 200mm (safety margin) = 900mm from any random position

  • Kuka.Sim 4.3 $ACT_POS_MES not working

    Quote from chris.rhoades

    sloopkogel Just out of curiosity, what is the purpose for moving up to a determined height? I have done similar things in the past without the use of $POS_ACT_MES, it would depend on the application however.

    The application is a depalletizing robot. It is picking layers from one pallet and placing it on another pallet. I calculate a 'safe height' by multiplying the amount of layers on the heighest pallet with the product height. I have a program 'Pick()' and a program 'Place()'. The beginning of both these programs is to always move Z up to the safe height (this is also the approach height) with the program 'MoveUp()', just to prevent colision if someone selects the program by hand and robot is not in the correct position (normally programs are called from a main program and then this isn't relevant because the flow of programs will make sure robot is in correct position before Pick() or Place() is called). I have fixed it another way now by deleting 'MoveUp()' from 'Pick()' and 'Place()' and created 2 other programs called 'PickManual()' and 'PlaceManual' that in turn call 'MoveUp()' and 'Pick()' or 'Place()'. If someone wants to manually pick or place a single layer then they can use those programs.

    I'm curious about your solution though. How do you move the tool up along the Z axis from a random position, without using $POS_ACT or $POS_ACT_MES?

  • Kuka.Sim 4.3 $ACT_POS_MES not working

    Can anyone confirm that $ACT_POS_MES is not working in Kuka.Sim 4.3? (or any other Kuka.Sim version)

    $ACT_POS is working fine but $ACT_POS_MES is always returning zero (X 0, Y 0, Z 0, A 0 etc...)

    Is this a known problem in Kuka.Sim? Are there any other system variables that do not work as we might expect?

    Background info: I want to move my robot straight up along the Z axis to a calculated height, I did it like this:

    UpPos = $ACT_POS

    UpPos.Z = GetTopHeight()

    LIN UpPos C_DIS

    This works, but it interrupts the advance pointer and thus prevents motion blending, that's why I wanted to use $ACT_POS_MES

  • Kuka ArcTech commands reset $BASE and $TOOL

    I read your answer too late Fubini so I didn't try monitoring $BASE_C, I will try this next time when I visit this customer. I did however try setting advance to 0 and the result was still the same ($BASE seems to get reset as soon as the welding starts)

    I also tried the following along with $ADVANCE = 0:

    This does not work (gives actual position relative to nullframe instead of base 17)

    Code
    ;FOLD ARCON <WDAT1> SLIN CIRCLE0DEG Vel=0.2 m/s CPDAT1 Tool[1]:lastoorts Base[17]:Base17

TestPos = $ACT_POS

    This DOES work

    Code
    ;FOLD ARCON <WDAT1> SLIN CIRCLE0DEG Vel=0.2 m/s CPDAT1 Tool[1]:lastoorts Base[17]:Base17

BAS(#TOOL,1) ;set tool and base to get the correct position
BAS(#BASE,17)

TestPos = $ACT_POS

    I would expect the same result for both versions, however, only the second versions gives me the actual position relative to base 17, the first version gives me the actual position relative to the nullframe

    Again, the program is working fine so there's no urgency here, but I'm curious to find out what is causing this....

  • Kuka ArcTech commands reset $BASE and $TOOL

    I have a Kuka that's working fine, and wanted to make some changes, and then spotted something strange. It seems that the ArcTech commands (ArcOn, ArcOff etc) reset the $BASE and $TOOL. The robot works fine, and the only reason I stumbled upon this, was that I wanted to record the position right after the welding is complete with $POS_ACT, which gave me unexpected results. After some digging I found out that $BASE and $TOOL seem to be 'reset' during the welding.

    If I monitor $BASE with the teach pendant before the welding I can see {FRAME:X0, Y0, Z0, A0, B0, C0}, if I monitor $BASE during the welding I see {FRAME}, when the welding is complete I see {FRAME:X0, Y0, Z0, A0, B0, C0} again.


    This doesn't cause any issues other then the $POS_ACT not behaving as expected

    $ACT_BASE remains the same, only $BASE

    Example code of an ArcTech command that seems to reset $BASE:

  • BAS(#TOOL,1) vs $ACT_TOOL=1

    One more question: I have a robot with an external axis (E1), and there at a certain point I want to move only that axis. I have done this with the following code:

    Code
    StartPos = $pos_act
StartPos.E1 = 30.0

;FOLD SPTP StartPos Vel=10 % PDAT1 Tool[1] Base[17] ;%{PE}
;FOLD Parameters ;%{h}
;Params IlfProvider=kukaroboter.basistech.inlineforms.movement.spline; Kuka.PointName=StartPos; Kuka.BlendingEnabled=False; Kuka.MoveDataPtpName=PDAT1; Kuka.VelocityPtp=100; Kuka.VelocityFieldEnabled=True; Kuka.MovementParameterFieldEnabled=True; IlfCommand=SPTP
;ENDFOLD
SPTP XStartPos WITH $VEL_AXIS[1] = SVEL_JOINT(100.0), $TOOL = STOOL2(FStartPos), $BASE = SBASE(FStartPos.BASE_NO), $IPO_MODE = SIPO_MODE(FStartPos.IPO_FRAME), $LOAD = SLOAD(FStartPos.TOOL_NO), $ACC_AXIS[1] = SACC_JOINT(PPDAT1), $APO = SAPO_PTP(PPDAT1), $GEAR_JERK[1] = SGEAR_JERK(PPDAT1), $COLLMON_TOL_PRO[1] = USE_CM_PRO_VALUES(0)
;ENDFOLD

    This works fine

    This also works, but E1 is rotating extremely slow:

    Code
    StartPos = $pos_act
StartPos.E1 = 30.0

BAS(#VEL_PTP,30)
BAS(#ACC_PTP,30)
BAS(#TOOL,1)
BAS(#BASE,17)

PTP StartPos

    Is there something else I need to do to initialize speed for axis E1? Something that is happening in the inline form that I'm skipping?

  • BAS(#TOOL,1) vs $ACT_TOOL=1

    Thanks for your reply. I took a peek in BAS.src and it seems that using BAS(#TOOL,1) also sets $LOAD variables according to the tool number

    Am I correct in thinking that using example 2 in my previous post would be more suitable for most cases? (eg. moving robot to a given point without using ILF)

Advertising from our partners