Posts by asa.leland

    Apologies for the delay.

    I was able to turn off absolute accuracy by setting the variable $ABS_ACCUR to FALSE in the $option.dat file. This can be found in the KRC\STEU\Mada folder. In order to overwrite the variable it was necessary to hook up a mouse to the robot controller in order to minimize the HMI and work on the windows side. From there it is a matter of searching for the $option.dat file, changing the variable to false, saving the change and rebooting the controller. This file is write protected so it was not possible to change the variable through the Kuka HMI controls.

    This screenshot shows the variables location in the file. This image was taken on my laptop, not the robot controller.

    Thank you Fubini and panic mode, I really appreciate the support and feedback. I turned off absolute accuracy and that solved my problem. Waiting on Kuka to send me the original PID file, but I am at least able to start test printing and moving on to the next hurdle.

    I could not have done it without the help here on this forum. Feeling grateful for the internet!

    I wanted to also share an example of the differences in the PID files saved on my controller. The one on the right, 916628, is the one currently loaded on the machine. I highlighted one area in the file to show what I am seeing. The manipulator type is the same in both files.

    What I dont have any clue about is how all of this is impacting my ability to run LIN moves!!

    Thank you again for the help.

    Thank you for the input.

    The robot is in fact labeled "Absolutvermessen" - and the serial number listed does not match the serial number in the PID file or the serial number listed in the Robot Data on the HMI (however these serial numbers are the same). I apologize as I should have noticed the discrepancy in the Robot data sooner.

    Does the PID file provide the serial number to the controller?

    I contacted Kuka, and their first suggestion was to swap out the batteries in the cabinet before trying to troubleshoot error messages, considering that this robot is 12 years old. I did follow Fubini's instruction to ask for an original PID file to match my robot, so hopefully that is something they can find and I can re-install.

    I compared the various PID files that are saved on my controller, and found that some data/variables are different, but seem to have been used with robots of the same type/Trafoname as mine (pictured above). Manipulating this data is definitely beyond my experience at this time, so it is difficult for me to understand what the differences in the data I am looking at actually entails.

    Kuka did explain the process to turn off $ABS_ACCUR through the windows interface on the controller, so I will test that.

    If you have any further suggestions, please let me know. I greatly appreciate the support and direction.

    Fubini - thank you so much for your help.

    Let me start by responding to your first message:

    Yes on KRC2 its active if $abs_accur is set to true. This variable is persistent so it stays true even after cold boot. So is it true on your machine? If so you could just for testing purposes set it to false and see if you no longer get the message.

    When I check the variable through the HMI, I can see that it is in fact set to True. However I was not able to overwrite this to False, either by changing the value on the pendant manually (variables<single) or by setting it to False as a line in my KRL. The controller responds with the message that the variable is write protected in both cases.

    Perhaps I am not setting the value to False in the correct manner?

    Apart from mounting the biggest source of bad absolute accuracy is lousy load data. Is your load data set correct?


    I do have the load data calculated - I used the Load Data Determination routine to calculate the mass, moment of inertia, etc.. The tool is stoutly bolted to the flange, and at 45kg is less than a quarter of the rated load. The tool has been taught properly and moves around its TCP as expected. So hopefully we can rule that out as a source of the issue.

    And also contact KUKA with robot serial number according to name plate and ask for the original pid file for your robot and install it. Maybe it was modified in the past. Some car manufacturers e.g. Daimler create their own pid files or change serial numbers freely and then use pid files from a originally different robot. These not really supported use cases exist out there even though KUKA is not very fond of them because you often loose a clear history for your robot and you never know what exactly you have in front of you. Unfortunatly such tweakings where much easier on krc2 generation robots than now with krc4 robots.

    Do you have pid or xpid as absolute accuracy? In late krc 5.x releases this was an option. In 8.x only the newer and better xpid is available.


    So, I have located the pid files in the archive that I pulled, and the serial numbers listed definitely do not match that on my robot arm. I do believe that this arm came out of a Daimler production line, so your assessment is likely correct. However, I do not see the $abs_accur variable declared in any of these files. Should I be expecting to see it declared as $ABS_ACCUR=TRUE or is this set through a different means?

    I've given Kuka a call and have a case started, so ill see what they may be able to help me with. Thank you again for your help today - if you have any other suggestions, they will be greatly appreciated.

    I appreciate your response above, and I should elaborate on my issue and perhaps you might be able to help me better understand the problem. My robot came from a car assembly line, and I am currently in the process of setting it up for large scale 3D printing. I am trying to do some initial path planning/testing, and have generated code using Kuka PRC. However, when I attempt to use LIN moves, I am receiving the error 'Precision Robot: Model deviation too large'. I have successfully run KRL that is comprised only of PTP moves, in T1 and Auto, but I am stumped with what to change to have it successfully run LIN moves. At this point I am not sure if I am missing something quite simple in the process or if it is beyond my experience. I have many years of running KRC4 robots, but this is my first KRC2, so I am still learning my way around the differences.

    I have a KR-200 3 comp robot, and a KRC2 ed05 cabinet, KSS 5.6.10

    The robot is floor mounted, and it is not a wall or ceiling mounted design. It is labeled 'Absolutevermessen'

    I am not sure that I understand how to change or adjust absolute accuracy - I did read through the thread: Absolute Accuracy Info KRC2 - KRC4 - but it seems that absolute accuracy has to be explicitly turned on for a KRC2 controller??

    Below is the error message:

    The code I am using is below. I am copying it out of my text editor as it has been generated from Kuka PRC:


    &REL 1

    &PARAM TEMPLATE = C:\KRC\Roboter\Template\vorgabe


    DEF test90 ( )





    BAS (#INITMOV,0 )



    ;FOLD STARTPOSITION - BASE IS 0, TOOL IS 0, SPEED IS 100%, POSITION IS A1 45,A2 -120,A3 110,A4 -80,A5 20,A6 80,E1 0,E2 0,E3 0,E4 0


    PDAT_ACT = {VEL 100,ACC 100,APO_DIST 50}




    BAS (#VEL_PTP,100)

    PTP {A1 45,A2 -120,A3 110,A4 -80,A5 20,A6 80,E1 0,E2 0,E3 0,E4 0}




    $ORI_TYPE = #VAR




    LIN {X 1118.565, Y -1041.747, Z 1627.273, A 0, B 90, C 0, E1 0, E2 0, E3 0, E4 0} C_DIS

    LIN {X 1118.565, Y -966.747, Z 1627.273, A 0, B 90, C 0, E1 0, E2 0, E3 0, E4 0} C_DIS

    LIN {X 1118.565, Y -891.747, Z 1627.273, A 0, B 90, C 0, E1 0, E2 0, E3 0, E4 0} C_DIS

    LIN {X 1118.565, Y -816.747, Z 1627.273, A 0, B 90, C 0, E1 0, E2 0, E3 0, E4 0} C_DIS

    LIN {X 1118.565, Y -741.747, Z 1627.273, A 0, B 90, C 0, E1 0, E2 0, E3 0, E4 0} C_DIS

    PTP {A1 45, A2 -120, A3 110, A4 -80, A5 20, A6 80, E1 0, E2 0, E3 0, E4 0} C_PTP


    Thank you all for your help!

Advertising from our partners