LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

One part (thread) of a run-time application freezes for hours until human interaction with PC

Does the "freezing" subVI contain a property node to a control?  If so, that has to run in the UI Thread.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 11 of 20
(877 Views)

Hi crossrulz,

 

No, it is part of a fully automatic process which "starts" quite a few sub-VI levels above.

------------------------
Labview 5.1 - 2020
0 Kudos
Message 12 of 20
(874 Views)

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...

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 13 of 20
(860 Views)

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.

------------------------
Labview 5.1 - 2020
0 Kudos
Message 14 of 20
(840 Views)

@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?

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 15 of 20
(821 Views)

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.

 

 

------------------------
Labview 5.1 - 2020
0 Kudos
Message 16 of 20
(815 Views)

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.

------------------------
Labview 5.1 - 2020
0 Kudos
Message 17 of 20
(786 Views)

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

http://forums.ni.com/t5/LabVIEW/My-Labview-EXE-not-computer-goes-to-sleep-mouse-jiggle-wakes-up/td-p...

 

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

0 Kudos
Message 18 of 20
(722 Views)

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?

 

------------------------
Labview 5.1 - 2020
0 Kudos
Message 19 of 20
(716 Views)

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 😉

0 Kudos
Message 20 of 20
(708 Views)