millisecond timer

[Jonas Van Otterdijk]

Hi,

I�ve got a timing problem with my fieldpoint rt (fp2000) module, the millisecond timer is to slow (71 milliseconds after 100 seconds and 35 after 50 seconds, so its no delay problem).
It is been measured with 2 NI daq cards. I did no test on other fp2000 modules, but I guess other modules gives other timing results.

Has someone suggestions about how to solve this correctly (maybe a calibration routine). At this moment I�m using the millisecond timer with a correction value.

Kind regards,

Jonas Van Otterdijk

[Ben]

Could you please post a copy of your code that demonstrates this behaviour?

I suspect you have some other code that is running in parallel with the timer that is taking more time to complete as time progresses.

Are building any arrays?

Ben

[Jonas Van Otterdijk]

Hi Ben,

I think you can exclude background processes, because the vi is the only one running with time critical priority and running in an other threat (�other 1�).

I�m not building arrays, I know it�s dangerous.
I�m sorry, I can�t post the code.

Hope this will give you an idea�

Kind reagards,

Jonas

[Ben]

Well the only advise I can offer is to start simplifying your code until you end up with one of two possibilities.

1) You can demonstrate a repeatable bug. Pass this to NI.
2) You find what part of your code is causing the problem.

You aren't rying to use the timer along side of an timed I/O are you?

Out of ideas for now,

Ben

How about a picture of the code?

[Jonas Van Otterdijk]

It�s not a bug,
I guess it�s quite normal that the clock of a pc or fp module is not as accurate as a daq card clock.

But thanks anyway for you time, and ideas.

[Jonas Van Otterdijk]

This is what I was trying to say and it is also true for the fieldpoint clock.

But I have a daq card to measure the difference.

(from Info-LabVIEW Mailing List)
-----Original Message-----
From: Christophe Salzmann [mailto:christophe.salzmann@epfl.ch]
Sent: woensdag 16 april 2003 13:17
To: Info-LabVIEW Mailing List
Cc: Rolf Kalbermatter
Subject: Re: Tick Count ms drift



Rolf and others who reply to my private mail

Thanks for your information. My concern is that I'd like to trigger events on two different computers and I'd like to have the pace of these events locally synchronized. I'm using the Tick Count ms to trigger these events on both machines, but since millisecond on computer A is slightly different than millisecond on computer B, I'll have to find another solution. I have no hardware (DAQ) to rely on to and I can't either rely on SMB, NTP or other protocols, only plain LV with lots of restrictions on the IP ports I use. Sound like I'll have to estimate the ms drift and take it into account when triggering my events. I'm slightly coming to the conclusion that LV might not be the right to for this part of the job, but I need a plain LV solution for cross-platform constrains.
Anyway LV is such a great tool that I won't give it up!

Chris


> From: Rolf Kalbermatter
> Reply-To: rolf.kalbermatter@citengineering.com
> Date: Tue, 15 Apr 2003 20:21:46 +0200
> To: Christophe Salzmann
> Cc: Info LabVIEW
> Subject: RE: Tick Count ms drift
>
> Hi Christophe,
>
>> I notice a time drift when using "Tick Count ms" against "Get
>> Date/Time in seconds". I got about 1 second every 30 min on my Mac
>> and about 1 second every 3 min. under my PC with Win 2000!!!! This is
>> odd, and I wonder if this considered as acceptable and if someone can
>> confirm these values.
>
> Hmm, I definitely can't talk for the Mac but the Windows clock is
> actually loosely based on the timer tick. And by the way the Mac
> accuracy seems rather good. You seem to get around 50 ppm here! The PC
> system time is initialized at startup from the battery real time clock
> and then usually should run freely for longer periods of times with
> the timer tick with a synchronization every now and then. If you see a
> difference I wonder if you have a time service installed. That would
> update the system time regularly from a remote time server and might
> explain the two times getting out of sync as it won't influence the
> timer tick.
>
> Under Windows you have the "net time" service which is based on the
> SMB protocol and can synchronize to another SMB server (or SAMBA).
> Then there are a whole range of NTP clients which synchronize to a
> public internet time server and last but not least there is the Logos
> time synchronization service from NI Lookout or LabVIEW DSC.
>
> It is certainly not a good idea to use more than one of them and they
> have different approaches to adjust the local time, some rather jumpy,
> others adaptive.
>
>> As a related question I'm trying to synchronize two computers at the
>> millisecond level. It is not too important if there is a difference
>> that I can roughly estimated, but the time drift is an issue since I
>> need periodical actions to be taken at both end with the same pace.
>> To say it differently is need to be sure that wait 100 ms on one
>> computer takes the same 100 ms on the other one.
>
> Hmm, how exact does it have to be? With time synchronization of the
> computers you could probably use the system time, as it is even under
> Windows 10ms accurate. The timer tick between computers should
> probably be accurate to at least 1ms or more likely 1 promille to each
> other.
>
> If this is all not exact enough, well then it gets though. You would
> probably have to look for local quartz based time sources most
> probably with controlled heating as otherwise you won't get much
> better than around 100 ppm.
>
> Rolf Kalbermatter
> CIT Engineering Nederland BV tel: +31 (070) 415 9190
> Treubstraat 7H fax: +31 (070) 415 9191
> 2288 EG Rijswijk http://www.citengineering.com
> Netherlands mailto:rolf.kalbermatter@citeng.com
>