Posts by robotecnik

    If you've got a HA accuracy robot you should have smaller than 1 mm errors in all the working range. (Not a constant error but at max 1 mm).

    That will be possible if the bases and tcp's are correctly done.

    You can always do the mastering, some times transportation ends with small errors that a mastering solve.

    You could try to make the tcp by calculus. When your robot is precise sometimes is even better doing it that way.

    If everything fails, you can always call kuka tech support (if you have the robot under warranty) or try to contact metrology companies who could recalibrate the robot for you.

    Regarding this last point, the HA robot is calibrated to himself, therefore any external adjustment in the base, tcp, artificial vision, sensors... Can decrease this precision.

    With a HA robot you can be sure the precision will be under 1mm.

    If yoiu recalibrate it you can achieve 0.3 (which is the best I've ever seen with a robot).

    Hope this helps!

    Sent from my BlackBerry 9300 using Tapatalk

    What 0lda says is correct. ABB robots have a battery set in their base to remember the robot arm position during shut downs. Typically this battery can last around two normal usage years.

    What "kills" faster that battery is having the robot without electrical power (holidays and so).

    It's really easy to change, but you will need to remaster the robot.

    Good luck!

    Sent from my BlackBerry 9300 using Tapatalk

    I'm far away from the computer and I don't have any code now to check it... But I would use connect (I think it was the way to start an interruption) to check the state of one of those digital inputs. You should use that interrupt (which at the end is a function that gets executed as if it was multitask) to check the states of those inputs and activate the outputs accordingly...

    Sorry not to be able to give you a better answer but from the phone and without manuals or old code to check... :(

    Sent from my BlackBerry 9300 using Tapatalk

    I can think of two solutions:
    You can use the submit program ( to do that for you (which is not the best in terms of speed but it is the best in terms of flexibility).

    You could also put an extra software layer there by using a beckhoff controller and do that inside the PLC logics.

    Both options are very similars, but the first one is free.

    Good luck!

    Sent from my BlackBerry 9300 using Tapatalk

    In theory it is not possible to decrypt those files. At least this is what ABB explains and the only reason why somebody would spend money on that encryption software.

    Sent from my BlackBerry 9300 using Tapatalk

    The rumors you've heard are true: robots are repetitive, but not precise.

    In any Brand you can get more precise robots by paying a little bit more (high accuracy, absolute accuracy...) those “ultra-precise” robots can get typically precisions of 0.3mm (this is the best you can get and the bigger the robot is the worst precision you’ll get).

    Due to the specific construction shape of the robot which all the axis are rotary, the robot can't be more precise than that.

    There are external companies that calibrate robots. They are expensive and keep in mind that you won’t get better results than 0.3mm.

    When you teach the points, you are "solving" the precision issue automatically as the robot don't mind if the real position versus the software position are correct/equal.

    Anyway, I must tell you that with KUKA I've got very good results with normal robots. i.e. it's quite normal to program a robot in our factory and send it to our customer and need to retouch a lot of points to adjust the part program. With KUKA this has been minimized a lot.

    Don't think on a constant formula to solve the error issue, the amount of error is not constant in the space as it depends completely on the robot gearboxes and arm torsions, which change depending on their position.

    If you need a lot of precision teach is the best, in the other hand, you can always use a correction array in which you can allow the user to apply a correction in a specific array position and before making any movement add the user correction to the calculated point:

    calcpoint [x] = calpoint[x] + userarray[x]

    If userarray is 0 then no addition will be performed and so…

    Anyway, test it and take measurements, probably you won't need this amount of precision.

    Good luck!

    Try to edit the /KRC/ROBOTER/INIT/MEMCONFIG.INI file.

    Modify the variable "miniumal physical page".

    Initially that variable value is 10.

    I don't know why, but KUKA tech support once told me to update it in steps of 10 units.

    So the next step should be 20, the next 30...

    Try it and come back with the result ;)

    You can always use a CIRC_REL, just this afternoon I've been having problems with the very same thing until I've found this:


    check it, it is in the roboterforum (which is almost the same than this one but in german and only available for germans I think). That is why it is from google cache... because I've not been able to reach it...

    All In all this should help you to calculate easily the circle.

    Good luck!

    Thank you for your answer Skyefire, I've started again to check the program.

    Note: believe it or not in the KUKA tech support told me that each IF clause stops the flow and that therefore I needed to put a continue just after each one. :(

    Apart of that I've found some logic on the problem:

    The second function can be called in two different situations: with the robot in movement or with the robot stopped. This made me to design the logics in the following way:


    I've put a halt just after the TRIGGER/DISTANCE (to check if the program was going there or not).

    The external code (the one who calls the second function) is something like:

    PTP 1
    PTP 2
    PTP 3

    My surprise has been big when I've seen that some times the robot got stopped at the halt and that sometimes it was not getting stopped (therefore the normal PULSE was being called).

    That's really strange, I've finished solving the issue putting a simple CONTINUE before the normal PULSE, but that is (at last) strange.

    Pointing me to the manual has been great, I've noticed that asking for internal/system variables stops the movements, therefore I've also put the continue before the first IF clause (where the $PRO_MOVE var is being checked).

    At last everything will work as expected.

    Thank you all for your help and comments.

    I've found a way to make it work as expected:

    Writting CONTINUE before and after ANY program line inside the first and second functions... This is probably the ugliest thing I've seen for a long time...

    Do you know if I can activate some kind of global continue? I mean, I'd like to activate it before executing those functions and deactivate it again just after the functions have finished their job...

    It should be something like:


    Thank you in advance

    Hello all,

    I'm trying to get an output ON without stopping the robot.

    Of course I'm using


    to get it done, but there are some conditions before that must be observed, therefore, I have some IF clauses and a couple of function calls prior to activating the output itself...

    In pseudocode the logic flow is the following one:

    Of course, if in the main program I'm using the TRIGGER... call directly the robot is not stopping.

    I would like to be able to keep the different functions and so in my logics in order to separate the physical inputs and outputs from the logics.

    I've tried placing a continue just before any of the IF clauses present in the code with the same result...

    Any idea or hint?

    as always thank you in advance.

    Good morning Skyefire,

    It fails in both states, but in different ways:

    In that "super" fold I'm making an automatic touch up, which means that I'm getting the POS_ACT and assign it to some fields of that fold. I'm creating a fold that's similar to a LIN, PTP movement with speed, base, XYZABC and some other fields.

    If I'm opening the fold for first time I'm getting the POS_ACT and assigning it directly to the fold (like when you make a LIN in which all the XYZABC get updated automatically at the creation moment).

    If I'm modifying the fold, then a question appears asking if I want to touch up or not, which is wonderful as it helps the user to avoid touching up (one extra step).

    That fold is used to automate some robot path movements.

    Then, going back to the problem and behaviour:

    The inline form is not working as the robot is not aware of POS_ACT.
    In the notification area reads "invalid inline form".
    The PASTE operation fails.

    When the inline form is about to get pasted then the question appears and fails.
    The problem that I'm trying to avoid here is that when the fold is being pasted that question appears and therefore nothing is being pasted beyond that point.
    Of course this is a big issue as the customer gets fooled by the system and can make the robot to collide.

    Can you imagine some way to arrange this?

    Thank you very much in advance.