Posts by Fubini

    Only thing I can think of is $red_t1. Does this have any influence? Afaik 15 % is max. It implicity factors down the override so with a value of 7 in it for example 100 % override is stripped down to 7 %. Can be found in r1/$machine.dat.

    Whats $speed_limit_teach_mode? It also affects maximal t1 velocities?

    This thread also shows some facts on T1 velocities:


    First of all consider reading READ FIRST... - KUKA Robot Forum - Robotforum - Support and discussion community for industrial robots and cobots (

    What did you do to add the axis? Where did you make changes to add the axis? What does the machine data look like before and after? What tools did you use to make the changes (editing machine data directly, axis configurator, ...)? ...

    Please be a lot more specific my crystal balls service contract ran out last week.


    Never heard of a message with this Text. Can you provide exact Text and message number and message prefix, or share a screenshot. Does the message come from KSS or a Techpackage or is user defined or ...

    Which robot of KUKA type? Whats the robots position when this happens. Is it happening always on the same spot inside your program? What is the robot doing? Is it using any techpackages? ...

    Nothing abnormal happened? That's your interpretation. How do you know this? What did you checkout to verify nothing abnormal happened? Whats shown in logs for example? ...

    I think we need a lot more details to be able to help. Let me put it into perspective: what you provided so far is meaningless. It's the same quality calling your car repair shop with only info the car stopped. Did you pull hand brake, ran out of gas, crashed, ... Limitless possibilities.


    Simplest solution is as most of the times to restore your harddisk image backup. You should save the current project and deploy it again after the restore.



    Something like this

    3-Achs-Portal FP
    Das 3-Achs-Portal FP deckt grosse Arbeitsbereiche mit hoher Genauigkeit ab und bewegt auch schwere Lasten sehr genau.

    Was always called portal by us. There a different variants of it but basically 2 or 3 linear axes that are moving in xy and z.

    Look in a $machine.dat of your choice


    Might be a German inspired wording. Looking it up the correct English wording would be Gantry I think.


    That has been discussed many many times in this forum. Just use forum search. In KRL one can not use variables directly inside the target position. It needs to be a declared Variable so something along the lines of

    DECL FRAME myPos
    myPos.X = 0.0
    myPos.Y = 0.0
    myPos.Z = offset_prelievo
    myPos.A = 0.0
    myPos.B = 0.0
    myPos.C = 0.0
    LIN_REL  myPos


    Sorry SkyeFire can you elaborate on your remark. As I understood the question a xy or xyz stage aka portal should be run as robot kinematic with a KRC1. Did I miss something here?

    You can run portals with as standard KRC as well. It is only a matter of having the correct machine data. E.g. $MAIN_AXIS=#SS in R1/$machine.dat is portal if I remember correctly and $WRIST_AXIS=#NOH means "No Hand". There is a documentation that explains how to configure different kinematic types in $machine.dat. This documentation is no official KUKA manual but can be requested through KUKA customer support. Maybe it is already available inside KUKA xPert. I think this document has been shared with customers in the past and is not KUKA secret.


    What joint acceleration values does the robot realistically use? In the KUKA docs I haven't found any information at all so far and I don't know if the range is something like 250-500 °/s² or more like 5000-10000 °/s² or anything in between. I only need a rough estimate to know the range I am working with.

    There is no explicit bound for this. Since we are talking PTP moves here the limitations come from the robots dynamic model. The dynamic model restricts gear and motor torques. In this case $ACC_AXIS[] does not limit axis acceleration directly but the torque available to accelerate/decelerate each joint (the maximal values for torques are stored in robcor.dat inside the dyn_dat[] array. But the documentation of the dyn_dat values are a company secret of KUKA and not publicly available). How much torque there is available depends on the robots state (position, velocities, accelerations, loads, ...). Lets assume a motor can generate a torque of 40 Nm. Holding the robot and its current position (assuming for simplification positions, accelerations are zero) requires a motor torque of 27 Nm than a value of 100 in $ACC_AXIS[] means the robot will try to use 13 Nm for acceleration. Basically everything that can be used up to the maximal torque value. But since the robot is a coupled system this might not be the resulting acceleration you will see in the end. Since the calculated trajectories of the robot are time and phase synchronized over all axes it might be that another axis is the actual limiter for the overall torques. In this case all other axes are "slowed" to fit the limiting axes in such a way that all axes start moving and finish moving at the same time (this is an important feature that no matter what the user programs for VEL_AXIS and ACC_AXIS the resulting movement of the TCP in Cartesian space is always the same).

    To use accelerations on joint level in rad/s^2 you would need to deactivate the dynamic model. But this is not recommended because it is than a lot easier to destroy your robot and in your use case you would also see even more unwanted oscillations.

    If you want full control over how the robot accelerates and decelerates yourself the only option I can think of is using the RSI package.

    Another possibility to get closer to commanding direct rad/s^2 values would be to use spline motions in combination with adding additional restrictions by means of $SPL_VEL_RESTR. If I remember correctly you can add joint specific restrictions for axis acceleration in there. In that case $ACC_AXIS is applied as percentage value to both (torque limit and joint acc limits). Joint limit acc then is defined by the $RAISE_TIME[] the time it takes to acc from stand still to maximal velocity for each axis. In KRC2 $RAISE_TIME was directly inside R1/$machine.dat but for KRC4 this changed and the info was moved with tag RampUpTimeUnderLoad into the motor configuration xml-File of the specific axis.

    Maximum axis acceleration - General Discussion of Industrial Robots Only - Robotforum - Support and discussion community for industrial robots and cobots (

    Of course for getting a better performance with less or minimal oscillations the would be other options using available features of the robot controller but as I take that is not what would be a feasible solution justifying a masters thesis.

    Last but not least what you also could do is just "measure" the resulting accelertions by using the built-in oscilloscope function (aka trace) inside the KRC. You can record the resulting axis acc by configuring the correct channel you want to record and than plot the result using either WorkVisual or the Tracetool found in any KRC installation in the C:\KRC\UTIL folder. So use $ACC_AXIS just to "scale" the input but what the resulting axis acc you get is only defined after recording the values and looking at the trace plots.

    The data sheet for the KR150 2700 extra we use states the maximum speed at 150kg is:

    A1: 123 °/s, A2: 115 °/s, A3: 120 °/s, A4: 179 °/s, A5: 172 °/s, A6: 219 °/s
    Am I correct in assuming that I can safely set $VEL_AXIS[] to any value that is equal or smaller to these?

    The value entered for $VEL_AXIS[] is a percentage of the maximal value. So 100 means maximal velocity. The actual maximal value is given by $VEL_AXIS_MA in motor revolutions per minute inside R1/$machine.dat. If you want to calculate maximal axis velocities you need to also consider gear ratios RAT_MOT_AX[] and axis couplings $AXIS_COUP[,] inside the same file.

    External Axis (on Rotary Table) - Rotation Speed Control - KUKA Robot Forum - Robotforum - Support and discussion community for industrial robots and cobots (

    (its basically the same for robot axes).

    Is this arctech version for kss 8.2? Whats written inside the logfile? Each TechPackage installation creates a logfile inside C.\KRC\LOG (not totally sure about this folder. Might also been C:\KRC\ROBOTER\LOG or something similar. I currently have no access to a robot to look it up precisely).


    To which robot brand is this related? Unfortuntly you posted in the general section. This is probably different for each manufacturer.