Showing results for 
Search instead for 
Did you mean: 

Why does the RTC go nuts when shared/network variables are used in newer versions of LabVIEW?

I am using a  whole batch of Dell PC's as networked data collection monitor PC's on our lab (closed) network. When I have attempted to use any version of LabVIEW, inclusive of 2009 or after, the RTC goes bonkers. Something is messing with the system clock in such a way that the system can not hold the time at all. Because these systems interact with SQL Server using embedded queries that is the mechanism that always fails first since ADO.NET is quite sensitive to DateTime parameters and typically times out when the RTC fails in this way, Has anyone else seen this? The failure stops occurring when the network cable is unplugged but that makes no difference since as a distributed application nothing else works, either.


NI is claiming they can not replicate this failure in the lab and I am a bit skeptical since the failure I see occurs across different generations of hardware (Pentium 4 Netburst and now Core 2 integrated chipset machines - G33 Express). I may have to consider rebuilding the system in Visual Studio if this issue continues and if that happens we will discontinue LabVIEW support since we can no longer use this as a development environment. This issue breaks the whole system.


Has anyone seen this issue? Is there a definitive work-around for this? There is a support request that was opened a while back that is now closed due to this. I am afraid to try LV 2010 since I attempted to use the latest FieldPoint driver on my personal development system and I ended up rebuilding the system up from scratch (reformat and install Windows) which wasted two days I could have used to do actual work. This appears to be the only way to recover the use of the system. Re-installing drivers, Windows or LabVIEW has no effect at all on the problem and I have not found any way to recover the machine other than to rebuild it from scratch. The OS is Windows XP. Any verification of this issue might push NI to actually do something about this.

0 Kudos
Message 1 of 3

What exactly does 'bonkers' mean?

Do you have any sort of time server enabled on your PC's

0 Kudos
Message 2 of 3

The issue was assumed, at the time, to be related to network/shared variables. This no longer seems to be the case. The problem was that with each update of the software through shared variables to the system the "Real-Time-Clock" or on-board system time clock would be reset to a different random value. Through troubleshooting under LabVIEW 2010 I am slowly eliminating other components of the system. The issue seems to be related somehow to SQL Server interaction through the CLR used by ADO.NET 2.0. I have installed software built using isual Studio 2005 but not the compiler itself. It may be that the debug components add something incompatable with LabVIEW.


See: for additional information.

0 Kudos
Message 3 of 3