Problem with long term run

[wassi]

Hello,
i have a problem after running my program >1000 hrs. The failure occures every time after this runtime. The user interface is not operateable any more. This means, the mouse can be moved, but a mouse click is not accepted, controls can not be changed any more, UI is not uppdated from the program; its "frozen". The rest of the program works well. (Collecting data and put it to the file, make control, communicate over RS232, ... I can not see any problem with memory. I use the rte of CVI7. Do you have any idea for localizing the problem?

Thanks

[RobertoBozzolo]

You may be experiencing some problem related to time issues. There was a warning some years ago that windows (and CVI) could hang if run continuously for 49 days and some (2^32 msec). Now this problem has been fixed, but some functions (among them Timer() and eventData2 in a timer callback) will wrap around in the same period of time returning a very high negative value: if you are repetitively using such functions, you may have get and incorporated this negative value in calculations that do expect only positive values!
(2^32 msec ==> 1193 hours!)

[cosmo]

Hey Robert,
Can this be beat with casting to unsigned?

Orlan

[cosmo]

OK,
That came off strangely worded on my part. The timer callback eventData2 is INT, so it would actually wrap at 596.5 hours (~25 days). The casting--if it worked properly--would get you to the 1193 hours that was mentioned. Will that work? (Funny, because I've had some programs that misbehaved after several weeks and I never knew why?)
But the timer() function return a double, so why would it rollover anytime soon? At some point you will run into truncation where you might lose more and more resolution, but shouldn't it go way farther than 1193 hours?

Orlan

Message Edited by cosmo on 06-21-2005 01:33 PM

[RobertoBozzolo]

Dear Orlan,
eventData parameters are not to be used directly; according to timer control help:

eventData1 is a pointer to a double that represents the current time in seconds. The time base is the same as that used by the Timer function in the Utility Library. eventData2 is a pointer to a double that represents the time that has elapsed since the last call to the timer callback. LabWindows/CVI sets the elapsed time to zero if the callback has not been called previously.

You can cast these pointers to the corresponding double values by using
tn = *(double *)eventData2;
obtaining values in seconds: eventData1 is directly comparable with the Timer () function, while eventData2 gives the same result than using inside the timer callback

{
static double told = 0.0;
double tnew;

tnew = *(double *)eventData2;
tn = tnew - told;
told = tnew;
}

Now, from my experience, eventData2 wraps at 1193 hours and some (the same as Timer() function), while eventData1 doesn't; this is quite in line with this KB entry. Seems that both eventData2 and Timer() function rely on a 32bit-wide counter so wrapping at this particular value, while eventData1 is based on a larger counter (how large? I don't know: I never have let a computer on for such a long time! 😉 )

Message Edited by Roberto Bozzolo on 06-22-2005 08:56 AM

[cosmo]

Ooh,
I wasn't paying attention to those eventDataX being returned as pointers. Most are, but some are directly useable. Should have checked more closely. Please disregard my temporary lunacy.

Orlan

[wassi]

Hello,

I made a simulation and tested my program what happens in case of this overflow. But my program seems to work well in this case.
Is it possible that this problem causes an internal failure in the UI, which blocks panels and menus?
For more testing: is there a way to make a simulation with directly changing the time base of the system?

Regards

[RobertoBozzolo]

Till now I have found no UI block due to this timer overflow: what has happened to me is that my application was confined in a loop made endless due to the negative value found in the overflow, but the rest of the program was working (I had a timer that managed data acquisition and process control and it was still working).

Manipulating timer value cannot be done at high level software: maybe you will need to deep into some internal windows variable or counter but I never attempted it and I cannot give you informations in this respect.