09-11-2012 06:32 AM
I checked now again and at the moment I only use 500MB of RAM and there absolutely no increase visible.
I will check again in a view hours but I can't imagine that this is the problem.
09-11-2012 06:38 AM - edited 09-11-2012 06:40 AM
When running perfmon, please focus on the following counters:
- CPU load
- private bytes
- page faults
- handles
- GDI objects
If you already have some suspicion WHERE the error occurs, you can use LabVIEW Desktop Execution Trace Toolkit to track down possible reasons. Either using custom trace events or if there is already some leak indicated, this could be a reason....
A last thing i can think of right now: Do you use some USB devices? I recall that USB has a dedicated setting for power save. I've seen applications crash because USB was powered down during execution when no user interaction took place.
Norbert
PS: If you use an USB hub, please try without it
09-11-2012 06:53 AM
Thanks,
I will check on your mentioned counters till tomorrow and let you know if any extraordinary occurs.
I don't have any more supects. I already disconnected all suspects during one night (one after each other) so that i could exclude them.
Almoust all components are connected via usb to the PC.
I'm using one NI-USB 6501, two NI USB TC01, two CO2 Sensors are connected directly.
Furthermore there are two RS232 interfaces in use.
There is a special host Software for the CO2 Sensors with which they work for one week without any user interaction.
there is one usb hub in use. But this one was added later where the problem already occured.
But i will try to run the program once without it.
09-11-2012 07:46 AM
Scherni wrote:The code is programmed with labview 2011.
At the moment it is running on an 30 day evaluation version of LV2012. When I'm done programming I will create an EXE or an installer.
Once upon a time (not sure if it is still true), the evalution versions would only let the user run a program for so long. I remember back in 7.1 that my programs would randomly quit after 10 minutes for this reason. Can somebody from NI confirm or correct this statement?
09-11-2012 09:31 AM
@crossrulz wrote:
Scherni wrote:The code is programmed with labview 2011.
At the moment it is running on an 30 day evaluation version of LV2012. When I'm done programming I will create an EXE or an installer.
Once upon a time (not sure if it is still true), the evaluation versions would only let the user run a program for so long. I remember back in 7.1 that my programs would randomly quit after 10 minutes for this reason. Can somebody from NI confirm or correct this statement?
I don't work for NI, but one of our interns is using an evaluation version of LV 2011. He can run VI's for ever and even build exe's that run without time limits. All of his panels are branded with the NI logo and "Evaluation Version".
09-12-2012 03:06 AM
Thanks!
After crussrulz your idea with the problem of the evaluation version i created an EXE and the programm worked over night.
The RAM usage remained at 500MB.
so probably the evaluation version was the problem.
it's still a little bit suspicious to me because it works for 10 hours during the day (movement of the mouse every few ours) and stops over night after 2 or 3.
09-12-2012 05:44 AM
I have had the same problem in a couple of applications. The application "pauses" randomly until the mouse is used somehow in the GUI. Then it runs just fine again.
The behaviour seems to disappear when i build the application and run from .exe. So far i got no idea why this happens, it havent happened in all my projects, just a few. The only thing i can think of is that the debug environment somehow causes it. To much memory use, some function that isnt working 100% in debug mode...
So if it goes away when you build an exe and use it, and if you dont plan to run the application in debug mode then it shouldnt be a problem as far as i have experienced. It would be interesting to know what might cause this behaviour though.
09-12-2012 11:22 AM
Nimgaard,
Have you tried building two executables from the same source code (no changes made); one with and the other without debug mode? Then running the two side-by-sside and see if one "pauses"? I would be curious of the outcome.
09-12-2012 11:54 AM
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
09-13-2012 01:39 AM
@ Ray.R: Unfotunately the system in question isnt available to me. The code is but the system runs off multiple hardware, some that i just cant simulate.
@ Lewis_G: That makes sense. The application i built is heavily dependant on queues.
Overall i didnt have much problems since the application paused pretty randomly in debug mode and so it didnt really stop me from running. Especially since it didnt pause if i worked with the application. And normally i always build it into an exe for the customer to use, i just wanted to let the OP know that he wasnt alone and that building an exe might help.