"Precision Robot: Model Deviation Too Large" Error or KRC2

Post your code and point value. Is your robot HA or ABS?

I have been contending with the same issue, were you able to resolve this?

This is an absolute accuracy issue. Deviation between non absolute accuracy transformation and absolute accuracy is too high. This is an intentional check to discover meddling with absolute accuracy files. This can happen e.g. if a absolute accuracy robot is mounted on ceiling or wall. Since absolute accuracy model is depending on gravity direction when its created you can not flip/tilt absolute accuracy robots.

To check you could deactivate absolute accuracy for testing purposes and see if problem disappears. How you can deactivate absolute accuracy is dependant on KSS release. Information you did not give. But its explained in this forum just need to use search function to find it.

Fubini

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:

&ACCESS RVP

&REL 1

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

&PARAM EDITMASK = *

DEF test90 ( )

;FOLD INI

;FOLD BASISTECH INI

GLOBAL INTERRUPT DECL 3 WHEN $STOPMESS==TRUE DO IR_STOPM ( )

INTERRUPT ON 3

BAS (#INITMOV,0 )

;ENDFOLD (BASISTECH INI)

;ENDFOLD (INI)

;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

$BWDSTART = FALSE

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

BAS(#PTP_DAT)

FDAT_ACT = {TOOL_NO 0,BASE_NO 0,IPO_FRAME #BASE}

BAS (#FRAMES)

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}

;ENDFOLD

;FOLD LIN SPEED IS 0.1 m/sec, INTERPOLATION SETTINGS IN FOLD

$VEL.CP=0.1

$ORI_TYPE = #VAR

$APO.CDIS=1

$ADVANCE=3

;ENDFOLD

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

END

Thank you all for your help!

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.

Btw its not surprising you see it only in lin moves. For a ptp only once a absolute accuracy trafo needs to be calculated to transform cartesian target position into an axis position. For lin its different and you need an absolute accuracy backward transformation every 10 ms along the path to calculate the necessary axis position along the line. So according to probability laws chances are higher in lin.

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

Fubini

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.

Fubini

Fubini - thank you so much for your help.

Let me start by responding to your first message:

Quote from Fubini

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?

Quote from Fubini

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

Fubini

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.

Quote from Fubini

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.

Fubini

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.

take a picture of the robot label. also if it is absolute robot (HA or ABS) it is likely to have another smaller label "Absolut vermessen". Sometimes robots are measured in field and that extra label may not be there. if the robot serial number and PID file do not match something is wrong...

don't recall details but if my memory is still good there is a function to deactivate absolute model by removing PID file from RDC (along with CHECKPIDONRDC and PIDTOHD). don't have things at hand but would say ask KUKA or check Xpert.

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.

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.

you mention that you say the PID file in the archive... did YOU personally collect that archive on THIS robot? did you check serial number in the AM.INI of that archive? because it seems like you may be looking at file that does not belong to this robot. why not take a fresh archive ad check again?

the content of PID that you are comparing is only small part of the PID file

even slight changes in values have an effect. this is why when robot is mounted in different orientation (tilted, or on wall or ceiling) corrections applied by PID will be large enough to exceed some limits and robot will not be able to move. as a workaround one can turn of absolute accuracy and robot will work again - as a standard accuracy robot. to make it absolutely accurate again, it will need to be measured again and get new PID file. again, this file will be good only for current mounting position, any tilt to the surface that robot is mounted on will cause the same issue again. since your robot was factory measured, you should be able to get copy of original PID file from KUKA.

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!

so how exactly did you turn it off?

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.