Program lost part of functions after 1.5 month?

[Harry.W]

Hello,

We developed a labview program that continuously reads current inputs (7) via a NI9203 card and also gives out current out via two NI9265 cards. This is a stand-alone executable installed on a PC that has no labview development tools.

The program runs great till about 1.5 month later and then it stops reading current inputs all the sudden.  When this happen, the program is still alive - clock is running, tabs are changeable, etc. The not working part is reading current inputs (it's like the USB cable been disconnected, or the card been pulled out). However, if we reboot the PC, everything comes back by itself.

We once monitored the memory usage of the program (using Windows Performance tool) for about 30 days, and did not see memory usage increase over the period of time, it stays at ~40MBs all the time.

As we are a group of researcher kind of people, we are now pretty much stuck here. What will cause this kind of problem? Heap fragmentation? Any thoughts or suggestions?

Thanks!

Harry

[johnsold]

Harry,

The Tick count will overflow in 49.7 days (2^32 milliseconds).  If you are using that, check to see if the overflow is being handled properly.

Lynn

[JÞB]

Nice thought Lynn-  That could be a cause if the vi is waiting durring rollover you can enter an infinite loop.  There is a vi here that is immune to that issue. 

Another Thought that pops to my mind is DAQmx.  Are you creating tasks more than 1 time.  repeatedly creating and destroying Tasks without the VI ever leaving scope and allowing clean-up can make DAQmx choke after a very large number of Task creations (In LabVIEW 7.0 days the 4096th task creation failed)  It still comes up now and then.

[johnsold]

Another thought.  If you are using the "i" value in a while loop and it executes more than 2^32 times, I think "i" stays at the maximum value.  I recall a discussion of this many years ago, but forget the details.

Lynn

[johnsold]

I tested it. "i" stops at 2147483647 = 2^31-1, which is the maximum value for an I32.  The loop took less than 85 seconds to run with a comparison and an indicator in the loop.

Lynn

[johnsold]

Verified that while loops continue to run after "i" reaches 2147483647.  I put x = x+1 in line with a shift register of I64 and ran it to well above 2147483647.

Lynn

[Harry.W]

Lynn,

Brilliant point! Yes we do use two Tick count functions in the main while loop to calculate the duration of sampling time (one minuses another). I just checked, the system lost (or paused) about 46 days 4 hours 42 mins, which is a little less then 49 days but close. So my next questions are the following:

1. It seems the Tick count function returns the time since the system last reboot, or after system restart this timer reset to 0. Do you see any way that I can speed up this timer or preset it to have a value close to 2^32 msec, so I can test what the symptom will be if it overflows? Because you know to find a PC been running continuously for 40 days is not easy

2. According to the help context, if tick counter overflows it will wrap back to 0. If this is the case, since we are doing subtraction btw two Tick counts, it sounds it should not stop the program?

3. Do you think the reason it stops at 46 days instead of 49 days could because of the inaccuracy of PC's system time? It's 7% difference and sounds a little too much to me.

Thanks so much!

Rgds,

Harry

[.aCe.]

Use this instead: http://zone.ni.com/reference/en-XX/help/371361H-01/glang/get_date_time_in_seconds/

This never rolls over. Convert the output to a double and substract as you do with the tick function.

[RavensFan]

---

@Harry.W wrote:

3. Do you think the reason it stops at 46 days instead of 49 days could because of the inaccuracy of PC's system time? It's 7% difference and sounds a little too much to me.

---

My guess is that the PC was last rebooted 3 days before you started your program.

[Harry.W]

Thanks for your input, but we have a DCS record shows exactly time when the single lost and when reboot happens. Any other possibilities?