Data Inconsistency detected for Base Kuka KRC4

Bumping this thread.

I'm working on an automated base teaching program using a Renishaw touch probe. We use EthernetKRL connected to Renishaw's probing software to capture point data and calculate the plane for our new base.

Once the robot receives this information, our probing program stops and deselects sps, writes off the updated base information, then restarts sps. I'm still getting the error message above in the original post.

My question is this: Is there somewhere else in the controller where this base data is stored that could be causing this "inconsistency"?

Robot: KR210-r2700 KR C4 on KSS 8.6.10

CWRITE($CMD,rSTAT,rMODE,"STOP 2") ;stop system Submit
WAIT FOR $PROG_INFO[2].P_STATE==#P_STOP

CWRITE($CMD,rSTAT,rMODE,"RESET 2") ;reset system Submit
WAIT FOR $PROG_INFO[2].P_STATE==#P_RESET

CWRITE($CMD,rSTAT,rMODE,"CANCEL 2") ;reset system Submit
WAIT FOR $PROG_INFO[2].P_STATE==#P_FREE


;name new base
BASE_NAME[rNewBaseID,]=rNewBaseName[]
;write new base
BASE_DATA[ rNewBaseID ] = rNewBaseFrame

WAIT SEC 0
CWRITE($CMD,rSTAT,rMODE,"RUN 2") ;restart system Submit

One other thing to note, this system uses MultiSubmit, so sps.sub's interpreter ID is '2'

no, there is nothing other than your code that is modifying base data.

what is the purpose of restarting submit?

why did you truncate the message? what is the COMPLETE message and value of that base?

are you making sure that received values are initialized and valid?

Quote

no, there is nothing other than your code that is modifying base data.

Perhaps my question was ambiguously worded. Is data for bases stored anywhere other than $config.dat?

Quote

what is the purpose of restarting submit?

When opening $config.dat on the controller, the system will automatically stop the submit. I assumed stopping submit in my program would prevent the "data inconsistency" message.

Quote

why did you truncate the message? what is the COMPLETE message and value of that base?

Frustratingly, there are multiple function calls within this program making it difficult to share the entire code in one snippet. The variables are declared as follows:

INT rNewBaseID
CHAR rNewBaseName[24]
FRAME rNewBaseFrame

I have verified the data received on the controller for rNewBaseFrame is a properly formatted frame:

{X 1596.34741,Y -471.842,Z 539.848816,A -90.9623795,B 0.0270521715,C 0.136301115}

In fact, the base data and name are even successfully written into $config, and I can verify this by checking Tool/Base Management.

The message "BTM 23, Data inconsistency detected for base" still appears, however. I could simply ignore it, but I'd like to understand why the robot is warning me in the first place.

Quote from snewk

Perhaps my question was ambiguously worded. Is data for bases stored anywhere other than $config.dat?

BASE_DATA array is stored in $CONFIG.DAT by default. The trick is, it could be moved by someone who knows how (it's just a user-space variable). It's also possible to create other user variables that contain data that can be fed to $BASE (which is the system variable that actually controls how the robot moves). BASE_DATA is just an array of FRAME variables provided by KUKA to assist the Inline Form programming on the teach pendant.

Quote from snewk

When opening $config.dat on the controller, the system will automatically stop the submit. I assumed stopping submit in my program would prevent the "data inconsistency" message.

No, BASE_DATA is a user-level variable. You can have your program rewrite it at any time -- feel free to try it in KRL.

Opening $CONFIG.DAT in the editor is a very different thing from assigning new values to a variable in $CONFIG.DAT

Quote from snewk

The message "BTM 23, Data inconsistency detected for base" still appears

That very much does not look like a KUKA internal error message. What is the source module? Possibly it's something specific to mxAutomation. I've never seen it before.

My first approach would be to take an Archive backup of the robot, and perform a text search (WinGrep, BareGrep, Agent Ransack) of all the files for "BTM" or "BTM 23", to see if anything pops.

My best guess (on minimal data) is that something at the program level is performing some kind of check of $BASE against another value, and throwing a message if they don't match. What type of message is it? Notify, Quit, Dialog, Status?

BASE_DATA is pretty forgiving -- you can leave entire members out of it, like

BASE_DATA[1]={X 101.23}

and be completely valid. Executing $BASE=BASE_DATA[1] will simply change the X value of $BASE, and leave the YZABC values untouched. So as long as $BASE had something valid in all 6 elements, the robot should have no issues.

Note: $BASE will be "empty" (Uninitialized) on reboot, or following a Program Cancel or Reset. Aside from that, it retains whatever values were last written to it.

why not show exact message expanded?

maybe "base tool management"? if so that would suggest KSS HMI plugin trying to parse new data. and if data is incomplete or invalid at any point, robot better complain about something..

why not show the code that you use to write the base?

sure string is formatted correctly at the remote side (LabView) but that does not tell what EKI receives, and how the parsing is done, using what exact error checking. because what you get is a string. this need to be read and cast into some temporary variable. then you need to check the value of the variable and if it is ok, THEN write the value to BASE_DATA[...].

pretty sure your code is just ASSUMING that data sent from LabView is received and converted correctly.

and you still did not answer all questions.... what is the NEED to restart submit? my guess is that your EKI code is running in Submit and getting stuck every now and then... so you are restarting submit as a last ditch effort to get going again. if so, it is a poor substitute for robust code. and maybe you are repeatedly writing to base... depending on how this is done, it could be a problem too. maybe the value is uninitialized during write (at least briefly)

Quote from snewk

My question is this: Is there somewhere else in the controller where this base data is stored that could be causing this "inconsistency"?

Hello, info about base and tool values are also stored in the file C:\KRC\USER\MEASUREMENTPOINTS.xml when you change values from tool/base management window it also saves the data from that window to that file, but as you are changing the value from program, I'm not sure if the it is also saves direclty in that file when changing from program.

I have somewhere in back of my head, I'm not sure, that in some cases for example if i used first 4 point method tool measurement or for base 3- point,or indirect method with measurement points, and later I altered the values for the same base data by hand in config.dat directly and later if i went back to the tool/base management window I would get a message about incosistency.

Maybe you should check if you program altered base_data are set to numeric method in the tool/base management window and not to some other method where also measurent points are stored for those methods and could make inconsistency.

interesting point but i don't think this file is modified unless when changes are done through HMI or WoV tool and base management . i just tried assigning value to one of bases, tried using it in program, then sent to see content of the XML file and it still does not contain change. so then i used WoV to transfer the latest project from KRC to my computer. still no change... so it appears that this is only contain data for frames that have been measured using HMI - as the name suggests. thus is not related to reported issue

Ok, so it seems this is related to C:\KRC\USER\MEASUREMENTPOINTS.xml as Danny suggested.

After I write to BASE_DATA, the base information is stored in $config.dat and it is valid for use in program, however this updated base data is not reflected in measurement points unless the user opens the Tool/Base Management HMI. This is also when the notification message pops up.

I suppose we could avoid the notification if we were to take the additional step of writing the base data to measurementpoints.xml, but it seems unnecessary now; I understand what is causing the notification, and it is simply a "notify" message.

Skyfire, this system does not have mXAutomation installed, and searching through the project archive for BTM was a bust. I'm now thinking BTM stands for BaseToolManagement, since this is the active HMI at the time of the message (KukaRoboter.SmartHMI.BaseToolManagement).

Panic, Apologies for not sharing more of the code. This code is highly modularized, and there are at least a dozen different functions controlling reading/writing/sending/receiving data over ethernetKRL which makes sharing it rather cumbersome. None of this is done in the submit loop, and the input buffer data is indeed validated before being written to any variables. I will also remove the sps reset since it's unnecessary

Thanks to all three of you for your help figuring this out!

Quote from snewk

After I write to BASE_DATA, the base information is stored in $config.dat and it is valid for use in program, however this updated base data is not reflected in measurement points unless the user opens the Tool/Base Management HMI. This is also when the notification message pops up.

You should have been said this in your first post,

id say that i've seen the same message also, but it has never reset a base to 0, 0, 0

This has happened when manually fiddling in config.dat while alterering bases. Try truncating the result to 7 digits total including decimals. The only difference i have found for me has been that the numerical values have been truncated but not significantly altered in other way. Atleast what i have seen.

After going through all of this, my assumption is that any change made to BASE_DATA, BASE_NAME, TOOL_DATA, TOOL_NAME, LOAD_DATA, LOAD_NAME, etc. outside of the BTM HMI will result in the Base Tool Management HMI displaying this notification the next time it is launched.

Quote from snewk

After going through all of this, my assumption is that any change made to BASE_DATA, BASE_NAME, TOOL_DATA, TOOL_NAME, LOAD_DATA, LOAD_NAME, etc. outside of the BTM HMI will result in the Base Tool Management HMI displaying this notification the next time it is launched.

And this is a correct behaviour. You get a message while opening the Management-Plugin, so you know that something/someone has tampered the data outside the Plugin. For me that makes sense. When you change f.e. base data outside, you cannot expect that the positions for measuring that base, stored in the plugin are valid. With that message you get a hint to be careful with datas in the plugin.