Labview and windows that can run for months non stop

[rk_t]

Hi,

I have a simple application(turning on and off labview compatible usb based device with some simple fuctions such as recipe creator) that requires the labview code to run at least for 3-4 months 24*7.

I have heard that after a few days if your windows based computer is ON without restart, it starts giving problems. Is this true?

If yes, what are the options that I have.

Thanks in advance

[pincpanter]

Nobody can grant you that your application will run for such a long time on Windows.

However, in my opinion, there is a good chance that it may work: some of our monitoring applications (serial and Ethernet communication) run for months without downtimes, within dedicated networks.

To enhance the probability, it would be better to not use the computer for other tasks and disable a number of useless services like automatic updates and so on (best of all would be to keep the computer disconnected from any network).

[crossrulz]

---

@rk_t wrote:

I have heard that after a few days if your windows based computer is ON without restart, it starts giving problems. Is this true?

---

This was especially true in the Windows 98 days.  Not so much since Windows XP.

But for your application, you will need to watch your memory allocations closely.  Even a small memory leak becomes a major issue over the coarse of a week or more.

Agree with the other advice already given: Do not use a corporate issued computer as they typically have all kinds of extra stuff that you do not want.  Do not put this computer on any network.  Disable as many services as you can.

[Ben]

Ditto on the "watch your memory!" comments above.

I keep the task manager running all of the time when I am developing. It much easier to fix a memory leak if you track what has changed and resulted in the leak. Generally speaking I want to see the memory climb a little at startup and then settle in on a constant value.

Spoiler

G-Story Time!

I had been asked look into a DSC application that was starting to slow down a bit. After checking and digging around in system logs etc. I discovered the last time the machine had been rebooted was more than 1.5 years ago.

Bottom line, PC can run for quite a while if the application is developed correctly.

Ben

[proland1121]

2 points for consideration.

1) Windows device manager by default, allows Windows to disable power to a USB port (i've seen this happen quite often for USB-DAQ and USB-GPIB devices).  Go into the device manager and disable this power management option for the USBs; must be logged in as administrator.  Long running programs sometimes result in a complete loss of communication via USB if you don't do this. 

2) A common memory issue for long running programs occurs in regards to the Build Array function or auto-indexed output terminals for large data sets.  I ran into this with a solar array monitoring program we were setting up to collect atmospheric data 24 hr/day as we wanted the front panel to display a week long history.  LabVIEW requires the memory allocated for an array to be continuous (at least, last time I checked).  Windows,however, can create disconnected memory allocations if you are trying to increase the size of your arrays during run-time.  To avoid this problem, start by creating an array of known size (for whatever your application is) of NaNs, zeros, or empty strings.  Use the in-place structure to replace array elements when placing data in the array.  This will ensure continuous space of memory allocated for the array.

[altenbach]

For a computer to run for an extended time:

• the OS needs to be stable (as others have said, no autoupdates, no hibernation, etc.)
• Your LabVIEW program needs to be stable (no evergrowing data structures)
• Your power needs to be stable (no power failures that exceed the battery backup capacity).

What you should do instead is actively plan for possible interruptions. Have your LabVIEW program autostart with windows and write the current state to disk whenever it changes. This way it can continue where it left off even if a power failure or crash occurs. Most computer can be configured to restart automatically after unexpected shut downs. Even add some redundancy to ensure data safety in case of HD failure (RAID, etc.)

Basically, instead of trying to do a high-wire act without safety net, assume the worst cases and ensure that all possible scenarios are handled with minimal impact.

[RTSLVU]

Why wouldn't your LabVIEW program be able to run non stop? I have written several long term tests that ran 24/7 for YEARS, only being rebooted once a year when the instruments were due for calibration.

So far I have had no issues running LabVIEW programs these operating systems non stop for months to years at a time.

Windows 95, 98, 2000, XP, and 7. Just make sure you turn off auto updates on anything running XP or newer.

Also don't forget to use a decent UPS on your computer and instruments.

[JÞB]

And no one said anything about a Real Time OS Target?  Actually, that 24/7/365 app you need should be the "Start-up" application of the real-time target.  

That is not to say that an application could not run indefinitely on another target! but, some "Maintenance" activities will cost a reboot now and then or other interruptions, Power outages, Windows Updates, IT security patches, I32 clock rollovers, etc....

Unless you plan for those interruptions they will interrupt the application.  Once, I even had to argue that the error log file was the trouble.   That error log file grew to 2G over 9 years! and 65k$US  of raw materials needed to be scrapped because the file writing failed and the materials no longer had a "Path to product" when the file could no longer be written too. (Ouch!)

There are many reasons to interrupt test completion.  Time should not be one of those reasons.  

[wiebe@CARYA]

Nobody mention rt, since the title mentions "LabVIEW and Windows". It still a good idea, obviously.

Windows 10 doesn't really allow to turn off updates. You can try, but it won't work.

But nowadays there is Windows 10 IoT. That is build to make kiosk like applications. It's the only way to regulate when and what Windows updates (besides unplugging internet). Updates would be the nr. 1 reason Windows will reboot.

[crossrulz]

---

@JÞB wrote:

And no one said anything about a Real Time OS Target? 

---

The reason I didn't was because of the USB device.  If it is just a simple DAQ, then we could replace that with a cRIO and then use the FPGA for most of the logic (no need to worry about an OS there).  But that is quite a cost in hardware and development to switch from DAQmx to FPGA (I'm talking $2-5k in hardware and probably 2 weeks of development if you knew what you were doing).  Even with the cRIO, you will want a UPS on the system.