Is the Timer()function inaccurate ?

[stephan]

Hello all

I have a problem with a software I wrote for a test-stand. I like to explain what I must do to make clear where the problem is:
The test stand is used to make Long-Time tests of electric motors. These tests can go for 500000 on/off cycles, which can be 20 weeks or so. I have to measure some values during this cycles on specific times, e.g. 5 seconds after start, 10 seconds after start �
The on/off switching is done inside an Async Timer function (separate thread). To calculate the correct measure times, I use the Timer() function from CVI. I store the actual value of the Timer() function at each start of an cycle and calculate the time, when I must take the next value. This works good for some time, but after some days of r
unning, I get the first wrong measurement: I want to measure a value at the end of an on-cycle, but I measure it to late so that the motor is already switched of. The longer the program runs, the more often this problem occurs.

And here is my question: Is the Timer() function the right way to do this kind of time calculation? Or should I use an other way to calculate times in my program?
For me, it looks like the Timer() function is inaccurate. Does anybody share this experience?

I am using CVI 5.5 on an NT 4.0 system.

Thanks
Stephan

[Reed_Blake]

The Timer() function will roll over every 49.71 days. For details, see NI
knowledgebase article 0MND339A, at
http://digital.ni.com/public.nsf/3efedde4322fef19862567740067f3cc/2f80bef68d
c8b1e2862563530068f0ca?OpenDocument

There are a couple of ways to resolve your problem. If the current Timer()
value is less than the previous value, add 4294967.296 to the current value.
Alternatively, use the ANSI C time() function instead of Timer(). The time()
function will return integer seconds, which may not be accurate enough for
your application.
(apologies if this gets posted twice)
--
Reed Blake
Beta Technology
Industrial and Scientific Computing

[Reed_Blake]

stephan wrote in message
<5065000000080000007AA70000-1042324653000@exchange.ni.com>...
Hello all

>To calculate the correct measure times, I use the Timer()
>function from CVI. I store the actual value of the Timer() function at
>each start of an cycle and calculate the time, when I must take the
>next value. This works good for some time, but after some days of
>running, I get the first wrong measurement: I want to measure a value
>at the end of an on-cycle, but I measure it to late so that the motor
>is already switched of. The longer the program runs, the more often
>this problem occurs.


The Timer() function will roll over every 49.71 days. For details, see NI
knowledgebase article 0MND339A, at
http://digital.ni.com/public.nsf/3efedde4322fef19862567
740067f3cc/2f80bef68d
c8b1e2862563530068f0ca?OpenDocument

There are a couple of ways to resolve your problem. If the current Timer()
value is less than the previous value, add 4294967.296 to the current value.
Alternatively, use the ANSI C time() function instead of Timer(). The time()
function will return integer seconds, which may not be accurate enough for
your application.

--
Reed Blake
Beta Technology
Industrial and Scientific Computing

[stephan]

Thank for your answer

The ANSI c time function is not a solution for me, because I need the time more accurate than one second.
So I must add extra code to handle the roll over.
What is with the general precision of the Timer() function? I feel, that it lost resolution, the longer my program runns, is this correct?

Stephan

[Stephan Gerhards]

Reed, another comment.:

The online documentation of the Timer() function reads:
--- snip-------------------------------------------

Returns the number of seconds elapsed since the first call to
Timer, Delay, or SyncWait, or the first operation on a timer control.

The value is never reset to zero except when you restart your
program.

The resolution is normally 1 millisecond. However, if you set the
useDefaultTimer configuration option to True, the resolution is 55
milliseconds:
--- snip end ----------------

I read in the knowledgebase article, that you do not plan to change the
behaviour.
In this case, you should change the dokumentation, because I chose this
function because of the statement "The value is never reset to zero..." and
this is not correct.

Stephan


"Reed Blake" schrieb im Newsbeitrag
news:3f8c1978@newsgroups....
>
> stephan wrote in message
> <5065000000080000007AA70000-1042324653000@exchange.ni.com>...
> Hello all
>
> >To calculate the correct measure times, I use the Timer()
> >function from CVI. I store the actual value of the Timer() function at
> >each start of an cycle and calculate the time, when I must take the
> >next value. This works good for some time, but after some days of
> >running, I get the first wrong measurement: I want to measure a value
> >at the end of an on-cycle, but I measure it to late so that the motor
> >is already switched of. The longer the program runs, the more often
> >this problem occurs.
>
>
> The Timer() function will roll over every 49.71 days. For details, see NI
> knowledgebase article 0MND339A, at
>
http://digital.ni.com/public.nsf/3efedde4322fef19862567740067f3cc/2f80bef68d
> c8b1e2862563530068f0ca?OpenDocument
>
> There are a couple of ways to resolve your problem. If the current Timer()
> value is less than the previous value, add 4294967.296 to the current
value.
> Alternatively, use the ANSI C time() function instead of Timer(). The
time()
> function will return integer seconds, which may not be accurate enough for
> your application.
>
> --
> Reed Blake
> Beta Technology
> Industrial and Scientific Computing
>
>
>
>
>

[cdk52]

Stephan, why not try this:

In your async timer callback (which triggers the test cycles), call NewAsyncTimer() either once or several times, depending on whether the measure times are equally spaced or not, and whether you perform the same operations each time. You can specify how many times the callback will occur before the timer is automatically discarded. Then the callback timing will always be accurate and relative to the beginning of the current on/off cycle.
Remember that the asynchronous callbacks should return as quickly as possible, so take your measurements, then handle any complex processing, disk i/o or user interface updates in a deferred callback using PostDeferredCall().

Regards,
Colin.