labview stops working over night

[Norbert_B]

---

@Lewis_G wrote:

Hey Guys,

See this KB.

The LabVIEW Development Environment does not support multithreading/multiprocessing at edit time. In LabVIEW, everything at edit time is single threaded and runs in the UI thread. This is chosen because you generally would not get much gain from the editor running in multiple threads, even on a multiprocessor machine. Therefore, only the execution of VIs and LabVIEW executables are able to take advantage of multithreading/multiprocessing.

Knowing this, we know that the EXE will run faster and the Dev Environment will run slower.  This could be why your having a problem.  The dev environment may not be able to keep up with something like emptying a queue whereas the EXE can because it can run faster.

Kind Regards

---

Lewis et al,

the linked KB is correct but you seem to misunderstand the underlaying message. The execution of VIs within the development environment (Dev Env) does use multithreading just as the EXE. (EDIT: You stated it correctly in your text, but i am not sure why you state it as an argument FOR possible issues like the OP describes. See comment below!).

---

@kb wrote:
[..] Therefore, only the execution of VIs and LabVIEW executables are able to take advantage of multithreading/multiprocessing.

---

So the UI thread thing refers only to the execution of the developer interface itself (editing of block diagram and front panel!).

You are, on the other hand, correct, that the runtime behavior is a little different between Dev Env (default settings) and EXE (default build settings). The one and (99%) only reason: Enable debugging.

If you disable debugging for your VIs, you get a very similar runtime behavior of your VIs in the Dev Env just as in the EXE. Other way round: Enabling debugging for your EXE (create debuggable EXE!) makes the EXE run very similar to your normal sources.

OK, there are still some differences (e.g. search directories), but for performance, there shouldn't really be much difference other than the stated one.

It is true, that runtime performance might be a key issue, leaving the system to switch to power safe for certain peripherals (like USB) with the Dev Env sources whereas the EXE does not create this. So maybe you want to try the VIs by disabling all debugging.... 🙂

hope this helps,

Norbert

[Lewis_G]

ah fail.  I totally misread that

Another thing you may want to try is to isolate the problem a little more and see if it is a particular part of your program that is letting you down.

 You can use Tools>>Profile>>Performance and Memory to monitor memory usage of VIs.  This can often lead you straight to a VI that has a memory leak.

Kind Regards

[Scherni]

I thougt that the EXE solved my problem because it worked one day over night, but during the weekend and from yesterday till today the same happenened again. My last idea now was to installl a programm that uses the mous and maximizes and minimizes the labview window. I hope this will help. But that can't be the final solution.

Are there any further Ideas. I'm happy about any clue.

Would you think that it makes sence to change the PC. Could this cause these problems?

Scherni

[PhillipBrooks]

Sounds similar to this post from 2009.

Are you using the Report Generation Toolkit to log your data?

http://forums.ni.com/t5/LabVIEW/My-application-freezes-but-when-the-mouse-is-moved-it-resumes/td-p/1...

[Scherni]

Somehow only,

I don't use any Report Generation Toolkit. I just write a set of comma seperated data in a line to create a csv file.

My files go to sices of about 20MB. My Cycle time is 5s at the moment. This is enough for the process

[PhillipBrooks]

Do you write your file locally, or to a network drive?

EDIT:  Never mind. You stated in the first post there is no network. Sorry...

[Scherni · Accepted solution]

Hi,

i finally solved the problem by minimizing/maximizing the program by a property node. (see picture)

It's not the best solution but at least it works.

Scherni

[Ray.R]

strange...

Thanks for sharing the solution.

[PhillipBrooks]

I looked at your top level VI and noticed that you have 6 charts with a length of 10,000 points, each with autoscaling on.

Since you are logging the data to disk, is it really necessary to show all the data? You might try reducing your history length or turn off the autoscaling.

[Scherni]

It's not absolutely necessary, but it is nice to have. Do you think that this could solve the problem as well by reducing these charts?

If it really help I can get rid of at least 4 of the charts and shortn the other 2.

They are just there to supervise the process while its running