Strange behaviour of a timer

[RobertoBozzolo]

Hi all. I have developed an application that uses a standard timer to perform periodic controls over an equipment connected to the computer via RS232. The timer fires every 500 msecs and total timer execution is below 200 msecs every time, so that this task does not interfere with interaction on the user interface, which is very reduced on the system: this application controls endurance tests that lasts several days with less or no operator actions during tests.

Now, this application works well in several installations, but a customer of mine is claiming that after less than a day working the interaction with the user interface is reduced to the point that you see the pointer moving several seconds after a mouse move!

In my application I have a monitoring panel that shows some details on program and timer execution, namely seconds from program start, time from last timer execution and timer callback lenght, taken from eventData1 and eventData2 in the timer callback this way:

int CVICALLBACK timCbk (int panel, int control, int event,
  void *callbackData, int eventData1, int eventData2)

// Controllo impianto
{

 int  i;

 double tini;

 if (event != EVENT_TIMER_TICK) return 0;

 if (monH) {   // The monitoring panel is loaded
  tini = Timer ();   // Time when the callback started
  SetCtrlVal (monH, mon_life, *(double *)eventData1);    // Time from program start
  SetCtrlVal (monH, mon_scan, *(double *)eventData2 * 1000.0);  // Time from last execution of the timer
 }

 // Controlling the attached device

 // ...

 if (monH) {
  SetCtrlVal (monH, mon_timer, (Timer() - tini) * 1000.0);     // Time the callback lasted
  CVIDynamicMemoryInfo ("Memoria dinamica", NULL, &i,   // Dynamic memory size
          DYNAMIC_MEMORY_SHOW_ALLOCATED_MEMORY_SUMMARY);
  SetCtrlVal (monH, mon_mem, i);
 }

 return 0;
}

Now, when this customer displays the monitoring panel, it shows that the callback is firing every 210 msecs instead of 500! This explains the reduced reaction to user interface operations, but why it has happened?

Moreover, sometimes strange values are shown for timer pacing and for program life: I personally saw values of 4 millions appearing some times in "time from last timer" field, replaced with normal 500 msecs at the next timer execution, my castomes told me that program life showed 15 billions while it should show normal 86000 secs for a day work...

In my opinion this behaviour is machine-dependent, based on the fact the I never saw this behaviour on all other computers on which the application is running.

Has any of you noticed somethins similar to this, or has some information regarding timer behaviour?

Before moving all the application to async timer I'll try to change the machine on which it is running, but I would like to understand what's happening...

The application is developed in CVI6, executing under WinXP on a PIII machine.

Message Edited by Roberto Bozzolo on 12-08-2005 08:35 PM

[robskii]

It seems like the timer is used to implement a polling mechanism to execute code to control RS232 communication.  This is an excellent problem solved by using threads.  Of course I always preach threads while I find that others avoid this topic.   If you packaged this code into a while(1) which is a packaged into a function, then the same task could be done better using threads.

This is easy if this is the only code accessing the RS232.  If other code also accesses this device then think about adding thread safety along with a well thought out design of your thread model.

The problem with the default timers are that the happen in the main line of execution.  Events are also handled this way so unless you thread something, they tend to interfere with each other resulting in GUI hang ups.

Timers are useful for events that tend to be less frequent.

If you use threads, all the GUI reactions will be much better.

Hope this helps.

robskii

[RobertoBozzolo]

robskii, you're right that this application could be developed in multithreading, infact more recent versions of it use an asyncronous timer which as you know is executed in its own thread.

Unfortunately, this actual version, intially developed in cvi 5 / win98 and upgraded to 6 when the customer changed the machine to WinXP, has some special customization so that I cannot simply move the customer to the new program...

But two facts still need to be explained:

1. Timer timing ended up confused after a night working: noone is supposed to work on the computer during the night and the system had not even a screensaver to disturb the environment, so which other events are interfering with the timer? A little detail more: I observed that strange timer values (time from last timer execution) in the first minutes of program life but didn't give much importance to them since in the first hours working nothing strange happened

2. Why on other machines this exact program has been worhing for several days long without problems

BTW, can you detail a little much this sentence: "Timers are useful for events that tend to be less frequent."?

[robskii]

I read the CVI help about Timers being threads and I guess I believe this, but the callbacks that one references within a Timer Control are not!!   Code execution within a callback that is not threaded must complete before the next event can be handled unless one calls ProcessSystemEvents(Bad Idea) within the call back.   With a timer being called every 500ms, the event queue may eventually overflow (GUI Locks Up).  The time it takes to overflow depends on the power of the PC.  All Timer events will be stored in the event queue (One execution of callback per event).  This is the same queue that store events from other GUI controls.  Depending on the power of the PC one notices that GUI reaction become slower with time.  So I would find another way besides a Timer to execute code every 500 ms.  

robskii

[kabarr]

You did not say if the computer that your application does not run properly on is the same OS as you developed the application under.  I'm not sure about timer objects, the some of the timer functions are affected by a registry key "useDefaultTimer". You may want to check into that.