FieldPoint Family

cancel
Showing results for 
Search instead for 
Did you mean: 

"RT Set date and time" does not set seconds in UTC mode

Solved!
Go to solution

Hallo,

I tried to set the time on my cRio 9012 with the function settimeUTC which is used by the "Set Date and Time" vi. But the seconds I enter are ADDED to the current time and not set as new value.

Even the vi shows this behaviour: I set up a vi in which the time is set in a loop (100ms delay) and read again. When I set local time the clock stops (as expected) but when I set the UTC time the seconds keep on running...

Can anybody help me with that problem???

Thanks

Florian

0 Kudos
Message 1 of 11
(7,823 Views)

Florian-

 

       Looks like you meant to post in the cRIO forum. No worries though.  So, I tried to verify what you were doing and recreate this behavior but was unable to.  I'm probably not doing the same thing you are,  sounds like a pretty simple issue to recreate.  Will you post the VI so that anyone reading this can easliy figure out what you're doing and offer advice. Thanks!

 

Regards,

 

John

0 Kudos
Message 2 of 11
(7,791 Views)

Hi John,

as this was my first post I trusted the wizard to place it right... I will try to put a link in the cRio Forum or move the post...

Well the problem ONLY occurs when I deploy the vi to my cRio 9012. When I run it in directly on my Windows in LabView it set the system time and date as expected. But when I deploy it to the controller on can clearly see thatthe seconds are not ste but added for testing I added the "correction secs"...The vi is only to show the effect. the problem first occured when I used the library function to set the time in my own c++ library.

 

Thanks for looking after the problem

Florian

 

0 Kudos
Message 3 of 11
(7,783 Views)

Hi Florian,

 

I modified your VI a little so it does not set the time in every loop cycle. It works on my cRIO-9012 like expected for setting local and UTC time and everything including seconds is set correctly.

You can also take a look at the following KB:

How Do I Set the Date and Time on My Real-Time Controller?

 

 Let me know if you have further questions.

Andreas Stark
Senior Transportation Systems Engineer
0 Kudos
Message 4 of 11
(7,775 Views)

Hi Andreas,

thanks for the reply! But I still have the same Problem with your VI: When I set the UTC time to 0:00:30 at e.g. 6:23:15 the result ist 0:00:45. So the 30 seconds are just added. The VI only behaves like that on the cRio9012. On Windows everything is fine.

I set the time intentionaly in the loop so one could clearly see that the time stops when I use the Set LocalTime and the seconds keeps on running when I set UTC time (with zero seconds).

Is there a way to find out which version of the settime.out is on my target? Or should I post the file here? Is it even allowed for copyright reasons? I think the problem lies in that file.

 

The funny thing is that I can set negative seconds without getting an error on the target but not on Windows.

 

Maybe you have another idea what the problem could be.

Thanks so far

Florian

 

0 Kudos
Message 5 of 11
(7,770 Views)
Hi Florian,

 

what version of LabVIEW RT are you using? Did you configure the time zone for your cRIO in MAX?

I set it to GMT+1 in MAX, so if the time is 6:23:15 and I set the UTC to 0:00:30 it shows 1:00:30, so I can't really reproduce your problem.

Message Edited by AndreasS on 02-11-2009 10:13 AM
Andreas Stark
Senior Transportation Systems Engineer
0 Kudos
Message 6 of 11
(7,754 Views)

Hi Andreas,

well it does not matter if I set a time zone in the MAX or not. In my example I was working on UTC + 0 but even when I set it to my local time (UTC + 1) I get the same behaviour modified by one hour.

My LabView Version is 8.5. In in the MAX under Software-> LabView-RealTime it says that I am using 8.5.0.

 

I suspect  that the settime.out which is installed on the cRio is probably the root of the problem as VxWorks itself does not offer a function (at least I did not find one) to convert from broken down system time to system time in seconds. There only exist one to convert from broken down local time to system time in seconds ( mktime() ). The reverse function is available for both cases: gmtime() and localtime(). I also did not find a way to find out the offset of the local time. So I have to use the library function settimeUTC() from settime.out.

As I offered I can send you the settime.out file from my cRio for reference or maybe you can tell me how to find out what the version of the file is. It seems not to be an ELF file as I looked inside it to find some timestamp or version info...

 

Thanks so far 

Florian

 

0 Kudos
Message 7 of 11
(7,737 Views)
Solution
Accepted by topic author FSC_DE

Hi Florian,

 

after you posted your version of LabVIEW I found an answer to your question:

The behaviour you see is a known bug that was fixed in LabVIEW 8.5.1. Workaround is to use set local time instead.

 

Let me know if you have any further questions.

Andreas Stark
Senior Transportation Systems Engineer
0 Kudos
Message 8 of 11
(7,734 Views)

Hi Andreas,

Thanks for the help! The new version did the trick! I dated my cRio up to 8.5.1 and it works. I previously did not use it as out FPGA code gets totally blown up when compiling with 8.5.1 but that is a different problem...

Another question is why didn't I find the bug report with the search function?  And where can I get such information like the release notes or bug lists. That would help quite a lot and I would not have to ask such "silly" questions in the forum.

 

By the way: The set local time does not help as we need the time stamp for measurement protocols and they have to be in UTC. We only need the local time for user interactions and for comparison of the age of files (as they get a local time stamp).

 

Best regards

Florian

Message Edited by FSC_DE on 02-12-2009 03:01 AM
0 Kudos
Message 9 of 11
(7,729 Views)

Florian,

 

bug reports are not accessible through the web. Only NI internal!

 

I think the workaround is to set the local time to UTC (timezone) and then use set local time.

 

Regards,

Andreas Stark
Senior Transportation Systems Engineer
0 Kudos
Message 10 of 11
(7,721 Views)