LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

What do I need to worry about when running a VI for an extended amount of time?

Solved!
Go to solution

Hi, I'm fairly new to LabVIEW as a program, but not new to programming as a whole.

 

I'm attempting to build a VI which will, hopefully, be run continuously and take data for weeks-months at a time.

 

I've never built a VI, let alone a program, which will be run continuously for so long, and so I'm unsure as to what I should be concerned about. I'm looking right now at optimizing, as best I can, memory allocation, algorithms, etc. but I suppose my main question is: What should I really be worrying about when programming a VI which will be run continuously for an extended period of time?

0 Kudos
Message 1 of 4
(2,639 Views)
Solution
Accepted by topic author wger

What platform and operating system are you going to use? Windoze XP sometimes has its own issues with running continuously for weeks without rebooting. If you are going to be saving data to a hard drive or remote location, you will want to put in some error handling in case the drive gets full or network is down. Other than that, and the things you mentioned, I've had no trouble running LabVIEW (for XP and PDA) for weeks on end.

 

Robot wink

Message 2 of 4
(2,634 Views)

I think XP will likely end up being the OS used, though perhaps that can be changed.

 

Anyway, thanks for the prompt reply and information!

0 Kudos
Message 3 of 4
(2,622 Views)

In the structure of your VI's, be certain that you are not repetively creating things such as references to queues, or file references, or DAQ tasks, or anything without closing them.  I was working on one application where a DAQ task was getting created every loop iteration and not being closed.  It crashed the PC hard with a blue screen of death after about 20 minutes of operation, through debugging and before I found the cause, I saw I had about 80,000 to 100,000 iterations of a loop fairly consistently before the crash.

 

If this loop had run at a slower rate, it might have taken days or weeks before the PC would have crashed.  It would have seemed infrequent and would have taken longer to debug because I would never have seent the pattern.  If it takes a few failures before you discover the problem, it is a lot quicker to find the explanation after a few failures at 20 minutes per failure as opposed to 20 days per failure.  The problem was eventually found in a subVI several layers down and fixed.

 

So if you pay attention to these things early enough, then hopefully they won't pop up and bite you weeks or months into a critical run of the program.

0 Kudos
Message 4 of 4
(2,591 Views)