Odd behavior from Timer() call

[mjl]

I have an application that uses the Timer() function to determine time outs.  I was running the application and noticed it would behave oddly or freeze at weird places.  I placed a break point when the communication timed out.  After running for less than 10 minutes my breakpoint stopped it for timeing out.  Here are the values returned from the timer.

This is a multi thread application Written in CVI 2012 SP1 12.0.1 (127).  This communication all happens in the same thread.

dStart = 329.408198000000030

dNow =  4295297.066703000100000

       double    dStart = 0.0, dNow = 0.0;
       

     dStart = Timer();
                do
                {
                    ProcessTCPEvents();
                    if (!(bDone = (kxdData.iTotalRec > iMinNumChars)))
                    { // Check Timeout
                        dNow = Timer();
                        if (dNow < dStart)
                            dStart = dNow;
                        bTimeout = ((dNow - dStart) > dTimeout);
                    } // Check Timeout
                } while ((!(bDone)) && (!(bTimeout)));

[PedroMunoz]

Hi;

Does the same problem occurrs using a different timer? Like the asynchronous timer?

http://zone.ni.com/reference/en-XX/help/370051V-01/toolslib/functionreference/cvinewasynctimer/

[ryk]

Your observation that the Timer() function returns 4Msecs after only 10 seconds of elapsed time suggests a bug.   Other than that, The loop you are in is pretty tight.  Have you considered throttling it back a little to keep from hitting ProcessTCPEvents() so fast and often.  Sleep() or Delay(), or a modified (non-blocking) Delay come to mind.

do
                {
                    delay_x(0.10); //includes call to ProcessTCPEvents() every 0.10 seconds, change as necessary for application
                    if (!(bDone = (kxdData.iTotalRec > iMinNumChars)))
                    { // Check Timeout
                        dNow = Timer();
                        if (dNow < dStart)
                            dStart = dNow;
                        bTimeout = ((dNow - dStart) > dTimeout);
                    } // Check Timeout

Where delay_x is defined: 

int delay_x (double delay)
{    
    static double time1;    
    static double time2;        
    
    time1 = Timer();    
    time2 = Timer();    
    
    while ((time2 - time1) < delay)    
    {        
        time2 = Timer();        
    }

    ProcessTCPEvents();//outside the loop

    //ProcessSystemEvents(); //uncomment if needed

    //ProcessDrawEvents(); //uncomment if needed
      
    
    return 0;
}

[mjl]

HI,

   It isn't 4msec what it is is 4,295,297 seconds vs 329.4 seconds.  The Timer() function returned the equivalent of 49.7 Days.  I should have specified that dTimeout =  5.0.  The point behind the loop is that I am waiting for a response over TCP from a device before I continue.  I am blocking the user input on purpose.

I have since replaced all my Timer() calls with (double) clock() / (double) CLOCKS_PER_SEC.  The program works properly now.  I don't understand what could cause the Timer() function to flake out like that.  I have been using that function for close to 2 decades.  I happened to find this glich and don't know if I was experiencing it previously.

Regards,

Mike

[ryk]

Hi Mike,

From the function panel help for Timer():

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 the program.

The resolution is normally 1 microsecond. However, if you set the useDefaultTimeruseDefaultTimer configuration option to True, the resolution is 55 milliseconds.

So, for 10 seconds duration in your application, then getting 4 million seconds (4Msec) from Timer() appears to be a bug.

Glad to see you have a work around.

Ryk