01-07-2013 10:13 AM
Does the "freezing" subVI contain a property node to a control? If so, that has to run in the UI Thread.
01-07-2013 10:17 AM
Hi crossrulz,
No, it is part of a fully automatic process which "starts" quite a few sub-VI levels above.
01-07-2013 12:00 PM
Have you consulted these notes before upgrading? LabVIEW Upgrade Notes. There's a paragraph devoted to '
Upgrading from LabVIEW 8.0 or Earlier." Usually that's a sign that it's a pretty rough upgrade path. Probably would've been better to upgrade from 7.1 to 8.x before attempting the big jump to 2011...
01-08-2013 04:28 AM
Hi Bill,
I admit that I haven't read this document entirely.
I don’t think that the conversion of the specific code is the key point here. In the end it is an application compiled under 2011 from a code that has now been used under 2011. I don’t think that, e.g., the changed behavior of some functions (like In Range and Coerce or Insert Menu Item) or some remaining compatibility VIs (I doubt that there are any left) could be the cause for this issue.
Besides, an error or any conflict should be handled.
What I didn't mention directly: The location in the code where the freezing happens had been passed thousands of times (literally) during hours of the program running before the freezing.
I only could identify the location in one of the freezing events. I'm not sure if it couldn't happen anywhere else in the program.
We are currently trying to reproduce the event. Whenever there are new facts I will post them.
01-08-2013 10:14 AM
@mirola wrote:
Hi Bill,
I admit that I haven't read this document entirely.
I don’t think that the conversion of the specific code is the key point here. In the end it is an application compiled under 2011 from a code that has now been used under 2011. I don’t think that, e.g., the changed behavior of some functions (like In Range and Coerce or Insert Menu Item) or some remaining compatibility VIs (I doubt that there are any left) could be the cause for this issue.
Besides, an error or any conflict should be handled.
What I didn't mention directly: The location in the code where the freezing happens had been passed thousands of times (literally) during hours of the program running before the freezing.
I only could identify the location in one of the freezing events. I'm not sure if it couldn't happen anywhere else in the program.
We are currently trying to reproduce the event. Whenever there are new facts I will post them.
I was under the impression that you started having issues only after the upgrade to LV 2011. This is not the case?
01-08-2013 10:28 AM
Yes, it is the case!
The issue happened on some systems that had been upgraded to the LV 2011 run-time engine and application or installed with these. It is possible that the issue is triggered by some parameters within the use of our program or by some condition of the PC. So that it did not appear right after the upgrade.
Today it happened again on an in-house system, runing the same process that produced the issue 5 days ago.
Maybe somethink that I wrote was misleading. If it was the second part of my last post: What I mean ist that when the program is started it executes an automatic process that can take 20 hours. The freezing part of the code is part of a loop that repeats thousands of times before the freezing happens, i.e. after several hours.
01-10-2013 10:58 AM
I would very much appreciate if someone from NI could think abaout this issue an give a statement.
The question is: How can it be that a part of a program freezes ocasionally at a certain point (where there is no loop and no ocasional change parameters and no GUI activity or programative interaction with the OS)?
What can make a thread stop and continue when I, e.g., minimize the program window?
This shouldn't be possible in any case, should it?
Any general idead, any hint could possibly help me to find what triggers such an event. I cannot test a lot of modifications, since it has only happened four times now in several days of operation.
As I already said, after analysing the issue, the only specific candidates that I can name are the Wait (ms) function and two diasble structures, one empty and one with only a numeric constant going out.
02-26-2013 03:23 AM
Hi,
what is the current status of your problem? Does it still persist?
I wonder if anything else changed while your were upgrading to LabVIEW 2011? The source of the sleep could be some mixture of Windows configuration (and its installed software) and LabVIEW 2011. Did you install/uninstall/reconfigure additional software? Did the hardware change?
I found an older case where a similar behavior occurred:
My Labview EXE (not computer) goes to sleep-mouse jiggle wakes up
Are there any parallels to your case? Maybe one of the solutions posted in that threat will help you finding the culprit.
Best regards
Raphael
02-26-2013 05:43 AM
Hi Raphael,
Many thanks for your reply and the link to the thread, which I had not found in all my searches (probably I missed the keyword "sleep").
The posts about using "mouse jigglers" as a workaround are funny, but also sad in a way.
I get two main messages out of the thread:
1.) Aparently, the issue existed over all the versions (7.1 - 2009). Actually, regarding my problem, I found indications for something else that might have triggered the issue, a modification in our program that was more or less coincidental with the switch to LV 2011.
2.) The last posts point into a direction (e.g. "uniprocessor mode in the Bios") in which I also investigated and posibly found a reason and solution (see below).
For me this thread was important:
http://forums.ni.com/t5/NI-TestStand/Wrong-Wait-step-execution-time/td-p/860397
It combines two terms: "Waite () miliseconds" and "(Intel) SpeedStep".
When I found it, I had already been suspecting about the Wait function as a posible point in my program where the freezing/sleeping happens. The thread only speaks about wrong wait times, but it was a hint to SpeedStep and all PC (BIOS/Windows) settings that deal with a control (throttling) of the CPU frequency.
Unfortunatelly, there is a certain caos of terms and parameters in differen BIOS and Windows (XP and 7). We had the issue on different combinations of PC types and XP/Win7.
** Currently, the issue seems to be under control. **
I tried both, avoiding the Wait function at the specific (frequently repeating) point in the program and switching off all kinds of IntelSpeedStep, CPU Power Management etc. (BIOS) and Power Option "All On" (XP), Min. Processor State 100% (Win7).
Note: Win7 does not set to 100% automatically when using a "High Performance" profile, one has to go into the extended settings. Yet, when SpeedStep (e.g.) can be disabled in the BIOS, the setting disapears.
For the moment it seems that it helps, especially the CPU thing, but possibly also the change in the program (which points to the Wait function).
I didn't post it yet, because the test duration on different systems was not yet long enough.
Best regards,
Miguel
PS: Your nickname reminds me of some work in my former life in atmospheric physics. Do you work with small droplets?
02-26-2013 06:22 AM
Great to hear that the link helped. If you need any further help let me know.
Concerning my nickname… In the near future I probably will be developing a LIDAR receiver module for an institute for atmospheric physics. So the answer is yes 😉