Computer running LabView loses time

[GP]

Running LabView VI on HP Brio pc
Computer clock loses time non-linearly
e.g. after 24 hours lost 5 mins, after 36
lost 20mins. Time stamped log file is therefore wrong.
Happens with both Win95 or Win98 OS but worse on Win95.
The VI is reading data from instruments on serial port
and also a GPIB interface. Very slow
logging though (1 reading/min over many days).
Does this look like a hardware or software issue? Has anyone ever experienced this?
Help appreciated

[Dennis_Knutson]

You might want to look at the discussion at http://exchange.ni.com/servlet/ProcessRequest?RHIVEID=101&RPAGEID=135&HOID=5065000000080000001C0F0000&UCATEGORY_0=_49_%24_6_&UCATEGORY_S=0. What we do is have the network server synchronize to a web site that provides time signals from NIST (atomic clock standard) and then broadcasts the correct time using Network Time Protocol (Win NT network). Each of the pc's on the network are running a client program called K9 that periodically corrects the local system clock. If your pc'2 have Internet access, you could also have them connect directly. I don't remember any of the sites that provide the NIST time but you should be able to do a web search to find them. Good Luck.

[GP]

Thanks for that. This is certainly one way round it. I'm puzzled though. I have run the same VI on a borrowed Dell pc (same OS) and it doesn't seem to happen. This makes me think its a hardware issue (?). On the HP Brio the time loss is bad (hours over several days) and it appears to be worse with Win95 rather than 98. When the time loss has become significant, Windows is also rather sluggish.
Any idea what I could check while it is in that state (processes running etc?). Computers are not my forte.

Many Thanks

GP
790

[Mark A. Hanning-Lee]

GP wrote:
>
> Running LabView VI on HP Brio pc
> Computer clock loses time non-linearly
> e.g. after 24 hours lost 5 mins, after 36
> lost 20mins. Time stamped log file is therefore wrong.
> Happens with both Win95 or Win98 OS but worse on Win95.
> The VI is reading data from instruments on serial port
> and also a GPIB interface. Very slow
> logging though (1 reading/min over many days).
> Does this look like a hardware or software issue? Has anyone ever
> experienced this?

A general points:

Win98 tends to be worse at this than other OS; not just a LabVIEW issue.
My Win98 PC used to lose minutes per day; my Win2000 PC loses only a few
ms per day.

Make SURE that every loop in your code has a Wait or Wait until next ms
Multiple. That frees the CPU.


If a problem gets worse with time, see whether your memory usage is
growing with time.
If so, look for Build Array that is running in a loop, causing a large
array to grow without limits.

Also make sure there is a Close function for every Open.
Make sure that you aren't opening & closing inside a loop; correct
behavior is to Open before a loop, Read and/or Write inside the loop, &
Close at the end.
That's true for serial i/o, for VISA, and for GPIB.

Lastly, if you are now using classic GPIB & serial functions, consider
switching to VISA. Or vice versa!

In general, you can keep the clock sync'd by running the free Dimension
4 software from www.thinkman.com . That sets the PC clock at regular
intervals so it stays more or less on time.
(But I'd be reluctant to do that when the program is running; might mess
up loop timing.)

Mark

[D D]

You can also download public domain software from NIST at
http://www.boulder.nist.gov/timefreq/service/its.htm

> In general, you can keep the clock sync'd by running the free Dimension
> 4 software from www.thinkman.com . That sets the PC clock at regular
> intervals so it stays more or less on time.
> (But I'd be reluctant to do that when the program is running; might mess
> up loop timing.)
>
> Mark

[doobs]

Thanks. This is very useful information.

On Fri, 17 Aug 2001 20:43:48 GMT, "D D"

wrote:

>You can also download public domain software from NIST at
>http://www.boulder.nist.gov/timefreq/service/its.htm
>
>> In general, you can keep the clock sync'd by running the free Dimension
>> 4 software from www.thinkman.com . That sets the PC clock at regular
>> intervals so it stays more or less on time.
>> (But I'd be reluctant to do that when the program is running; might mess
>> up loop timing.)
>>
>> Mark
>

===========================================================================
Christopher Dubea Phone: (985) 847-2280
Vice President of Engineering Fax: (985) 847-2282
Moving Parts L.L.C. email: cdubea@movingpart.com
P. O. Box 6117
URL: http://www.movingpart.com
Slidell, LA 70469-6117

[Mike]

Mine does too - and I can loose an hour in a day! I posted it on
a microsoft newsgroup and they explained that it was my problem,
my application was too cpu bound to service the time interupt
requests. There is no need to reset the time, just reboot. Windows
it seems only reads the time from the BIOS once at startup.

Call it a feature...?
I call it a bug!



"Mark Hanning-Lee" wrote in message news:3B7D5DBB.7224@prodigy.net...
> GP wrote:
> >
> > Running LabView VI on HP Brio pc
> > Computer clock loses time non-linearly
> > e.g. after 24 hours lost 5 mins, after 36
> > lost 20mins. Time stamped log file is therefore wrong.
> > Happens with both Win95 or Win98 OS but worse on Win95.
> > The VI is reading data from instruments on serial port
> > and also a GPIB interface. Very slow
> > logging though (1 reading/min over many days).
> > Does this look like a hardware or software issue? Has anyone ever
> > experienced this?
>
> A general points:
>
> Win98 tends to be worse at this than other OS; not just a LabVIEW issue.
> My Win98 PC used to lose minutes per day; my Win2000 PC loses only a few
> ms per day.
>
> Make SURE that every loop in your code has a Wait or Wait until next ms
> Multiple. That frees the CPU.
>
> If a problem gets worse with time, see whether your memory usage is
> growing with time.
> If so, look for Build Array that is running in a loop, causing a large
> array to grow without limits.
>
> Also make sure there is a Close function for every Open.
> Make sure that you aren't opening & closing inside a loop; correct
> behavior is to Open before a loop, Read and/or Write inside the loop, &
> Close at the end.
> That's true for serial i/o, for VISA, and for GPIB.
>
> Lastly, if you are now using classic GPIB & serial functions, consider
> switching to VISA. Or vice versa!
>
> In general, you can keep the clock sync'd by running the free Dimension
> 4 software from www.thinkman.com . That sets the PC clock at regular
> intervals so it stays more or less on time.
> (But I'd be reluctant to do that when the program is running; might mess
> up loop timing.)
>
> Mark

[Laurent 437]

My LabVIEW data acquisition application running under Win 98 also slows down my computer time dramatically. But I cannot envisage to restart the computer because it is a standalone application. Isn't it a way to force Windows time to BIOS time, with a process written or not in LabVIEW ? Thanks for your ideas.

[GP]

I have found a sort of fix to this in that I now read the time from a stable device (another pc with no time drift) through LabView (via a GPIB command). I can either timestamp this to file at each measurement or convert it to an elapsed time from start of program. This can be done by converting time to elapsed time from a referenece date (see labview) at program start and at each measurement. Then subtract the start time to get elapsed time.

This circumvents the clock lag on the pc running Labview (for the time being). I can't use the internet to
update correct time so this works for the moment.

GP

[GP]

I have found a sort of fix to this in that I now read the time from a stable device (another pc with no time drift) through LabView (via a GPIB command). I can either timestamp this to file at each measurement or convert it to an elapsed time from start of program. This can be done by converting time to elapsed time from a referenece date (see labview) at program start and at each measurement. Then subtract the start time to get elapsed time.

This circumvents the clock lag on the pc running Labview (for the time being). I can't use the internet to
update correct time so this works for the moment.

GP