How does the CVI Timer() function reset?

[joebae]

I am using the Timer() function in a "do while" timing loop.
Is there a way to reset the Timer() return varable to 0?
I have noticed that after the program has executed continiously for a few days it  losees track of time in the timing loop.
The module is launched from a TestStand 3.0 sequence.
Is the Timer() return variable getting to large and truncating?

[RobertoBozzolo]

As far as I know there is no way of resetting Timer () function. It counts up to 2^32 msec, that is 49 days and some: after tis time is resets to 0 and restarts counting.

What do you mean by "looses track of time"?

[joebae]

The Timer() reseting to zero in the middle of the timing loop seems to be the problem.
I ASSUMED that it would reset to 0 when the TestStand execution is restarted for the next UUT, but , the Timer() keeps track of the last execution and continues with the next increment of time (since the TestStand sequence was first loaded)

The program is used for ESS testing and runs for months.
Every few months the program would exit out of the timing loop at the wrong time, "losses track of time".
It seems that when the Timer() returns to zero it creates a negative number in the loop and exits.
When the executon is restarted it is okay for a few more months.
I will have to use a diffrent time stamp function to get the timing loop to work properly.

Any ideas on which time function to use?

Here is a sample of the code:

    double totalElapsedTimeInMinutes = 0.0;
    double cycleEntryTime;
    double cycleBFNTime;
    double rapidColdDwellTimeInMinutes = 1;   // set dwell time to 1 minute

    // Note cycle entry time
    cycleEntryTime = Timer();
    do
        {
            // Get elapsed time
            cycleBFNTime = Timer();
            totalElapsedTimeInMinutes = (cycleBFNTime - cycleEntryTime) / 60;
        } while (totalElapsedTimeInMinutes < rapidColdDwellTimeInMinutes);

[LuisG]

As long as you call the Timer() function at least once every 49 days, you should be able to run it indefinitely.

Resetting it to 0 wouldn't make sense, in my opinion, since that would falsify the results (each call is supposed to return the number of seconds since the first call in your program).

Are you saying that after some amount of time the Timer function returns 0? If so, this is definitely unexpected.

Luis

[RobertoBozzolo]

Luis, what I am observing is exactly that Timer () function restarts from zero after those 49 days, while eventData2 parameter in a timer callback (that returns the timer from the last execution of the callback) returns a negative number of the corresponding amount of seconds. I had to take appropriate countermeasures in the timer callback in which I am using *(double *)eventData2 for the case when this value is negative...

This occurs on CVI at least up to version 7.1. I handn't yet tried CVI8 in this respect.

[LuisG]

Roberto,

That's very surprising. There was such a problem a few years ago, but it should have been fixed back in CVI 5.5.

I tested the code again, by faking an overflow internally to see how the Timer() function handles the wrap. And it looks to me like it handles it correctly. So I can't explain how you're seeing the Timer function return a bad value. The only situation in which I'd expect a problem would be if you go more than 49 days between successive calls to Timer(). As for the timer callback's eventdata, it is implemented using the Timer function, so if one is broken the other would be too.

Do you happen to remember if the problem happened after 49 days since your computer was running, or 49 days since you first called Timer() in your program? These are the two overflow situations that need special handling, and narrowing the problem down to one of them might help me a bit.

Luis

[RobertoBozzolo]

Luis, I will call my customers trying to get some more informations on the exact succession of events, but I have no much hopes that I will succeed since I normally place my program in the startup folder so that it starts when the computer starts up. The only possibility to discriminate if the famous 49 days are from computer startup or program startup are that somebody has started the program significantly after the computer has turned on. Moreover, we must go back a lot of time, since I took appropriate countermeasures to contrast this phenomenon... My personal opinion is that the 49 days starts from the first execution of the timer callback, but I cannot grant for it on a instrumental basis.

But it's definitely NOT the case of calls to timer spaced by 49 days: my programs have a timer (multimedia timer in the majority of cases, standard timer in some others) that fires every 0.3, 0.5 or 1 sec depending on the application running. In all these cases the timer callback gets the time from previous call (eventData2) and accumulates it to update some counters for the running tests. It' this value that is rolling over so that on a particular moment it becomes negative by 2^32 minus some fraction of second. With the exception of this event all the application is running correctly, and after this event the timer continues to count consistently.

Last addition: I noticed this event back to CVI 5.5 times and observed it again on CVI6 applications. After this moment I learned how to patch this event so I have no informations on whether in 7 and 7.1 applications does it happen again or not.

Message Edited by Roberto Bozzolo on 11-20-2006 09:30 PM

[LuisG]

Roberto,

You don't have to bother your customers. It's not that important to be able to distinguish between the two rollovers, and if the program started running as soon as the machines starts up, then it will be almost impossible anyway.

The thing that is most likely to help is for me to be able to reproduce the problem. I couldn't reproduce it yesterday by faking the overflow internally, but I might have missed some important detail. So I've started my own test here, and I'll keep you guys posted on what happens in 48 days (barring some catastrophic failure in the test machine...)

By the way, in your last post you mentioned the multimedia timer. I assume you are talking about asynctmr.fp. What I've said so far about not expecting overflow problems only applies to UI timers and the Utility library's Timer() function. It does not apply to the asynctmr library. To be honest I'm not completely sure what will happen after 49 days with those timers (it might very well be OS-dependent). But just to confirm: you did see the problem with the UI timer and/or the Timer() function, correct?

Luis

[RobertoBozzolo]

Luis,

yes, I was referring to asyncronous timers when I spoke about multimedia timers, and I am using them in my applications when in executable (while when debugging on my machine I use UI timers but for shorter periods). For this reason I cannot be sure wether I saw this rollover also on standard UI timers and when: it's a long time since I begun using async timers... It's true that inside timer callback I have some little delays implemented as while loops on Timer () value, but the interval checked is so little (50 msecs) that it's not probable that we get the rollover in it, moreover they are only used as timeouts in communicating with external equipments: if the device is responding the loop terminates within 15 to 25 msecs, so...

Anyway, I am very curious of the result of your testing: I had not expected that async timers behave differently from UI timers in this respect. Thanks for keeping us up to date.

[LuisG]

Roberto,

Okay, we've passed the 49.7 day milestone, so I'm back to report that all is well. The Timer() function continued returning values greater than 4294968. So I'm pretty sure that the Timer function is behaving well with respect to this rollover.

Another rollover milestone would have been at 49.7 days since the machine was last rebooted, but of course that would have happened before the other milestone, so that should be okay also.

UI timer controls are implemented using the Timer function, so I'm quite confident that the callback data sent to their callback function is correct.

Asynchronous timers, on the other hand, use a completely different implementation, and as such they do not handle the rollover well. I suspect that this is the case that you ran into.

Luis