LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

The real timer interval takes more time, than the configured interval. Why?

On one of my uirs there is a normal timer configured for 1sec interval. It means for me, that the timer callback should be called in each 1second. I experienced, that the timer interval is somehow bigger, than this 1 second (for a 30sec. periode the callback was called only 23 times). Then I tried to measure the ellapsed time between the calls to this callback with the Timer () function.

The measurement had a very interesting result: the measured time was exactly 1 second, but in the real life more than 1,5 second was ellapsed. How can it be?

I could belive and accept, that a timer will be called not exactly in the interval, how it was originally configured, but in that case the measured time should be also longer, same as the real time. Or how it is?

0 Kudos
Message 1 of 4
(4,016 Views)

I extensively use UIR timers in my applications and while I very often observed that the interval between calls is not constant, being influenced by activities in my application or in the system, I have never found such an incoherence between the time reported from the function and the real time elapsed. You probably don't know that the time elapsed from the previous call of the timer is reported by the function in eventData2 parameter, so I suggest you perform your checks again by using this parameter: you could for example print a line in the debug window each time the function is called by using

 

DebugPrintf ("%s: time from last call %.2f sec\n", TimeStr (), *(double *)eventData2);

 

One alternative to standard UIR timers is the use of Asyncronous timers (add AsyncTmr.fp to your project): they are based on multimedia timers and are executed in a separate thread, and they are structured so that the same callback of a UIR timer can be attached to an async one (with the only difference that the panel handle parameter is no longer valid in async timers). In my applications I distinguish between executing in the IDE and running as a standalone executable: in this case I discard the timer control and launch an asyncronous timer with the same callback as the UIR timer discarded. This way I can debug the function in the IDE by using the standard timer thus avoiding the problems that could arise if breakpointing in the funcion of the async timer, but can benefit from the threaded model while in the executable.

Message Edited by Roberto Bozzolo on 10-15-2008 07:03 PM


Proud to use LW/CVI from 3.1 on.

My contributions to the Developer Community
________________________________________
If I have helped you, why not giving me a kudos?
0 Kudos
Message 2 of 4
(4,006 Views)

It seems, that the problem is computer related. I have wrote a little program with 2 different types of timers (1 normal uir timer and 1 async. timer) to check the time interval between the callback calls. On my computer the time intervals were ok for the async. timer. The other normal timer was running slower. I have displayed the ellapsed time since the last call (eventData2 for normal timer), and it was exactly 1 second. In case of an async. timer the measured interval between 2 calls was ~0.62 seconds (measured with the function Timer ()). In the reality the measured 0.62 seconds is 1 second. On an another PC the same program runs correctly. Both calls are made in 1 sec. intervals and the 1 sec. is really 1 sec. Just for info I append my little code. I have tried to run this code with different runtime engines. On my PC it was always the same independently from the version. On an another PC is was correct with all available runtime engines. (The Op. system is always WinXP SP2)

I have not found any explanation to this issue. Maybe my PC is deffect?

0 Kudos
Message 3 of 4
(3,983 Views)

Even if I don't have a strong hypothesis about your problem, I should try the following:

*Measure the elapsed time with RDTSC and QueryPerformanceCounter

*Configure the BIOS of the 'faulty' PC to work in single Core/ not hyperthreaded / not overclocked ...

 

Best regards,

Nicolas

0 Kudos
Message 4 of 4
(3,972 Views)