Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

System clock used to update

I am having troubles with my system clock.  I am using Labview to control the breathing rate in a breathing simulator and I need to update the motor drive at the end of each minute for 60 minutes to set the new speed.  I have a simple state machine that outputs a 0-10 V signal via SCXI-1124.  The problem is later in the run it sometimes is taking more than 30 seconds to update the motor drive.  I am using the Get Date/Time function to time my updates and believe the CPU system clock is off throwing off the timing of my updates. 

 

I am using Labview 5.1.1 and Windows ME and SCXI chasis is connected to CPU using PCI-6071E.  How can I correct for the poor timing in non-deterministic system or improve the accuracy of the clock?  Also, do you think this is what is throwing off the timing of my updates because this only really occurs maybe 1 out of 100 times as usually it will only take a few seconds after the start of a new minute to perform the update.

0 Kudos
Message 1 of 31
(4,238 Views)

I'm wondering how bad your system clock really is.  Do you see your system clock "off" very much? One thing to possibly check would be to see if your CMOS battery is low/dead, this could be the source of lag in your system clock. 

 

Let me know what you think, otherwise we'll need to find a work around.  Thanks!

aNIta B

Applications Engineer

National Instruments

0 Kudos
Message 2 of 31
(4,217 Views)
Where can I check the CMOS battery? 
0 Kudos
Message 3 of 31
(4,204 Views)

Your CMOS battery will be found on your motherboard.  Here's a link to some helpful information about finding and replacing it: http://www.computerhope.com/issues/ch000239.htm .  Good luck!

aNIta B

Applications Engineer

National Instruments

0 Kudos
Message 4 of 31
(4,185 Views)

Thanks but how do I know that is what's delaying my updates.  Wouldn't the timing of the updates get worse and worse over time if it was a clock issue.  In my case that poor update occurs in one run and then the next 50 or so runs are fine.  Maybe there is a memory leak?  The updates are done by AO Single Update.vi in their own loop.  There are 6 other loops are running in parallel in my main VI.  Maybe there is a thread allocation issue?  I mean usually it takes a few seconds to update but this anamoly takes a good 30 seconds to update!!

0 Kudos
Message 5 of 31
(4,166 Views)

You make a very good point.  The information about your code is helpful- I'm wondering if you would be willing to post it on the forum.  I think it could be very helpful to see what exactly you're doing in your programming. In the meantime, you may want to check out this link on memory leaks if you think that is the case.  Thanks!

aNItaB

Applications Engineer

National Instruments
Message Edited by aNIta B on 02-09-2009 06:06 PM
0 Kudos
Message 6 of 31
(4,136 Views)
My system clock gets worse over the 60 minute run where its off by a few seconds at the end.  Does Labview throw the system clock off but I that was hardware timed not being effected by threads and memory?
0 Kudos
Message 7 of 31
(4,114 Views)
The CMOS only affects the hardware clock which is not the problem.  It is the clock error that accumulates when the computer is on which depends on the software clock.  The software clock may be more skewed when Labview is running.  Is this correct and if so how can I make the software clock more accurate?  Remember I am running on Windows ME.
0 Kudos
Message 8 of 31
(4,093 Views)

I've had the same error in LV 5.1.1.  First look at every loop in your code and insure that all of them use a wait for next ms multiple!!! LV will hog every CPU resource it can to run a loop but Generally you do not need to loop as fast as the CPU can go- the wait for next ms multiple give the CPU Time to do other things (like servicing the system clock). 

 

If that does not provide a solution- you can download and install NISTtime-32.exe.  This is a shareware utility published by NIST that will reset your PC clock to +/-0.200 seconds via internet connection to a day-time server.  I'm also an amateur horologist- but don't tell my wife!

 

 

 


"Should be" isn't "Is" -Jay
0 Kudos
Message 9 of 31
(4,091 Views)
That's neat.  How did you fix your timing error and what exact timing issue were you having?  See, I even experience the clock error when Labview is not running nor anything.  So you are saying the thread processing does have an affect on the clock and thus screws up when everything is updated????  How about using a wait function and how long do you set your waits?  Finally, what about using something like a Chronos Atomic Clock Synchonizer and can I use that or the NIST application on Windows ME?
0 Kudos
Message 10 of 31
(4,088 Views)