$DATE does not match the system time

the base system reads the actual time during powerup.

As time goes by you will see a difference between windows time and vxworks time ($DATE) on your office lite and there is no way to synchronize while powered up.

The user interface shows the windows time (next to the message displayed)

In putty you will see the vxworks time (similiar to $DATE)

I think that $DATE is write protected and this gives you an error. The error message you've got is probably caused by assigning a value to $DATE instead of assigning a value to $DATE.SEC

Hey folks, wanted to piggy back on this thread as I have a related issue. Can also make my own post though.

System is KRC4 with KSS 8.3.620

I have the controller set to use our time server for the system time. This is set up and working correctly—however—I have to manually re-sync it (minimize HMI, navigate to control panel, open the time settings, go to internet time, and refresh/update the time) every time after a reboot.

This of course means that my $DATE time is never actually correct, because as MOM mentioned, "the base system reads the actual time during powerup".

Would anyone know why the internet time is lost during a reboot? Is this normal?

how does the system starts up (hibernate, cold start)?

Cold Start. Via, main menu>shutdown>reboot control PC (with cold start selected)

When you reboot the robot, how far off is the clock? How long is the robot off? Are there any robot error messages (especially battery-related ones) when the robot reboots?

Quote from SkyeFire

Are there any robot error messages (especially battery-related ones) when the robot reboots?

Have you also checked application error (event log)?

MOM, I have not checked these log files before. I assume this thread ( Viewing event logs ) will sort me out. I will report back after I have viewed the logs.

SkyFire, after reboot the clock goes back to Jan 1 2012 or 2013 (this year changes depending on the restart strangely). The robot is off for only a minute or so. No error messages of any kind during startup on the smartPAD .

Quote from dave tripp

after reboot the clock goes back to Jan 1 2012 or 2013 (this year changes depending on the restart strangely). The robot is off for only a minute or so. No error messages of any kind during startup on the smartPAD .

Weird. I would normally suspect the motherboard CMOS battery is failing, leading to the motherboard clock resetting to "zero" (which varies depending on the BIOS manufacturer) when main power is lost. But if that were the case, the year should be a constant. Not to mention, losing the CMOS memory would usually cause other problems.

Still, replacing the CMOS battery wouldn't be a terrible idea, just to see what happens.

Well, to update everyone:

One day I did see message 13103 "Battery or battery fuse defective, backup not possible". The message didn't always appear on powerup, but I decided to replace the batteries anyways. So I replaced the batteries and let them charge for about 40 hours, however the issue is still there. I'm wondering if I should have let the batteries charge for even longer.

SkyeFire, I also realized that the date is always going back to Jan 1 2013, however for whatever reason I do sometimes see a message dated 2012 in the message window on power up (but the system date is still Jan 1 2013).

I tried both a cold boot, and hibernate, and checking/unchecking "use internet time" (to sync with our time server), but I didn't see any differences.

I may just put a little script on the controller to force an update with our time server.

You can see in the images attached, the event message from 2012, but the system time is 2013, and then the time going back to correct after syncing with the time server, and... strangest of all, at one point I turned off the connected welding machine, and when I restarted the controller, the ethernet connection warning messages were from...18 days ago?

Although this post is from last year, the out of sync issue with $DATE remains. From KSS 8.6 there's a new variable named $DATE_HOST which overcomes the issue and can be used the same way as $DATE. It's a shame they didn't do this years ago.

Quote from Razzzhead

Although this post is from last year, the out of sync issue with $DATE remains. From KSS 8.6 there's a new variable named $DATE_HOST which overcomes the issue and can be used the same way as $DATE. It's a shame they didn't do this years ago.

Interesting. Any idea as to what the issue with $DATE was, that they needed to create $DATE_HOST? I happened to have a KSS 8.7 robot handy to try this on, and both variables matched exactly.

the answer is and was post #2

It seems, that kuka finally woke up and allows you to get the actual time with $DATE_HOST!

This would really have helped in march and october.

But, why do it the easy way if there is a more complicated way to do it?

sorry because this thread is from 2022. but i have a question like this

the variable $Date and $Date_host is the same ? because when i check the data of 2 variable. they are the same.

hi zin,

let the system run 3 weeks and then compare them again

Date_Host is the Time from Windows which can also connected to a NTP server

Date is the Vxworks time and they can differ like mentioned before

it is sad the times are not equal. and also so sad the u only get the real time with KSS 8.6 over $DATE_HOST