LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

RT Set Time and Shared variable engine

I'm working on a ni cRIO 9075. When it is rebooted the timestamp goes to 1970. So I developed a simple vi on PC Host which periodically updates RT Time when the difference between RT Time and Pc Host Time is higher than a certain number.

 

The problem is that when the time is updated, the network shared variable engine seems to stop. In particular I have two network shared variable deployed on RT target, one containing sensor data and one containing the RT Time. They stop working when I update RT Time.

 

The strange thing is that this happens whit executable applications (RT application and Host Application), while in Project all work fine.

 

Any help? I know that I can work with FGV but I would understand why of this behavior.

 

0 Kudos
Message 1 of 8
(3,418 Views)

Don't know much about cRIO hardware, but this sounds like a "battery-backed BIOS clock" (or the equivalent in the cRIO).  The cRIO has to have its own Date/Time clock -- has it ever been set correctly?  Could the battery be dead?  [I've had batteries die in PXI controllers after about 10 years, and the symptoms are that the time resets to 1904 ...].

 

Bob Schor

0 Kudos
Message 2 of 8
(3,396 Views)

OK, this is from the cRIO-9075 manual:

 

At startup, the system clock resets to January 1, 1970, 12:00 a.m. (midnight). For information about synchronizing the system clock with an SNTP time server on the network at startup, go to ni.com/info and enter the Info Code criosntp.

 

Hopefully, the information there will fix your problem.

 

Bob Schor

0 Kudos
Message 3 of 8
(3,391 Views)
Hi Bob, yes I know the crio has not a battery so the time is not stored. In fact I give the time from the pc host.
The problem is that when the time is updated, the network shared variables deployed on crio application stop working. It seems to me that pc host does not find variables anymore after time update.
0 Kudos
Message 4 of 8
(3,363 Views)

Do you see this problem after the first time you set the time or is it only after you've set the time more than once?

0 Kudos
Message 5 of 8
(3,343 Views)
Also after the first time.
Reading the wp in info code, it seems that the problem arises from the difference between 1970 and current time, if it is the same as sntp synchronisation. Anyway I cannot use sntp because I have no Internet connection.
0 Kudos
Message 6 of 8
(3,336 Views)

"When Life Hands You Lemons, Make Lemonade".

 

Given that every time you start your cRIO it will reset its clock to 1970, and if you change the clock, you'll lose your Shared Variables, don't change the clock!  Instead, continue to send your progam the "correct" time from your PC, and compute the "Time Offset" as (PC Time) - (cRIO Time when PC Time is received).  Now whereever you get a Time Stamp from the cRIO, simply add the "Time Offset" to it and you will convert it into a Time Stamp based on your PC's System Clock, not your cRIO's (which we know is off by about 35 years ...).

 

Bob Schor

0 Kudos
Message 7 of 8
(3,324 Views)

Yes, I've come to the same conclusion yesterday evening. But this a bug if I'm not wrong. 

 

Thank you for the citation about lemons Bob :)) 

0 Kudos
Message 8 of 8
(3,307 Views)