Issue with updating time programatically

[cirrusio]

Hello all,

I currently have a sbRIO that I am running in a box that is not particularly accessible.  The space is tight, so we had to twiddle with the piece that holds the battery in contact with the board and it seems that now, when power is removed, the battery is not kicking in and our time/date settings are reset.  This is not so much a probelm (after all, the poor contact between the battery and the board appears to be creating this), but, when I attempt to reset the time to the current date and time via the Set Time.vi in the Real Time pallette and the tme has been set back to some distant past (1904?) then my communication with the device cuts out for about 30 to 60 s and when the device returns, it has the current time minus the time it took to get the controller to respond.  In this case, EVERYTHING cuts out - the network connection just bombs and I have no control over the device.  I believe that I have seen this to some extent when doing something similar on a PXI chassis, but this is pretty extreme.  Is this behavior expected?  Why might it do this?  This result is very consistent.

Any help is appreciated.  Thanks,

 Matt

[The_Right_Choice]

Hi Matt, 

What RIO drivers are you using and what sbRIO do you currently have?

How long have you noticed this behavior?

For clarity, you run the Set Time.vi and after running that, your device resets and has the correct time minus the time it took to restart?
And during the restart, you lose the Network connection with the sbRIO and cant interact with it correct?

[cirrusio]

Thanks for the response, Douglas.  I am running LV 2013 SP1 and using the most current drivers.  I noticed this behavior a while back but it wasn't as big of an issue then.  Several years ago it seems that there was a change made to the RT pallet.  If I recall correctly, there may or may not have been the nisyscfg VIs, but I was setting time using something like RT Set Time (this is a vague recollection).  Then came the nisyscfg VIs and I started to see some oddness in how the RT controller responded to the change in the time stamp.

Fast forward to now.  Using the sbRIO, I am not sure I have ever NOT seen this behavior.  It is not clear to me whether I am losing ALL hardware functionality or if I am just losing network connectivity.  But, I will illustrate the problem with the simple example below.  There is nothing much to this VI, but here iw what I am doing - simply sending a time stamp via a shared variable to the RT controller.  using this new time stamp, I reset the time using the Set Time.vi from the nisyscfg pallet.  Since I have no battery for the sbRIO, every time I pull power, the time resets to midnight on Jan 1, 1970 (don't ask me why that date, but that is the date).  Using this VI, I then reset the time to the current time and date (sometime in 2014).  If I observer ther response in the NI System Manager, I can see my network communication completely knocked out.  The network stays down for approximately 1.5 to 2 minutes.  In the larger app, this creates all kinds of problems as I wasn't accounting for this.  Could I be doing something wrong with the Set Time vi?

Thanks, Matt

[Joel-I]

Hi mtat76,

Thanks for uploading that VI snippet.  It could be that the controller is restarting during that time period espeecially given that the connection comes back without any additional work.  

Which sbRIO are you using? There should be a status light present that turns on when it is rebooting.  

Regards,

[cirrusio]

Haha, could be?  I have a 9636.  And right now, the sbRIO is buried in several boxes for deployment so I will not be able to see the light.

Matt

[cirrusio]

Thanks for uploading that VI snippet.  It could be that the controller is restarting during that time period espeecially given that the connection comes back without any additional work. 

---

The one problem with this idea is that it is not clear how I can keep debugging if the controller reboots.  Would this be possible?  I figured that all connectivity would be lost and you would get a warning saying that the connection to the target has been lost.

[Joel-I]

Can you clarify what you mean by debugging in this context?

[cirrusio]

I am running the code down on the controller from the development environment (i.e. I hit the run button on the VI on the target).  Generally, if the controller restarts, I lose the connection to the controller temporarily and this kills the development evnironment session that I am running.  The controller would then run with the active executable.  I am seeing none of this.

Another thing is that if the change in the time stamp is small (less than 5 minutes), I do not see this behavior.  It is only when I make larger jumps (> than several hours) that I see this behavior.

Cheers, Matt

[cirrusio]

Is this something that should be elevated to the AE level?  It is not clear to me what is going on, but right now I can't get to the battery to see if it has been dislodged or is dead and have to reset the time very time the device is unpowered and repowered.  This is unacceptable as it is creating some major headaches with my users.

[RyanPoPo]

So to make sure I completely understand this behavior, you reset the sbRIO which resets the clock to the default value (1904). After it boots, you update the clock with a new timestamp value, which subsequently causes it to lose connection since the time just vastly changed. When it reconnects the time is off by the time it took for it to reconnect, is this correct? But then after this, does the sbRIO permanently disconnect or can you still communicate with it?

The disconnect you experience when you first update the time is likely expected since the networking all depends on the time. However, I am unsure why the time does not stay updated while the network reconnects. You could possibly just purposely add 30 seconds to the time stamp before updating the time on the RIO to compensate for the network reconnect. Another option might be to sync with an SNTP server to get the latest time after you first update the time with the timestamp

Regards,

Ryan