Minimise front panel of vi containing timed loop = problem

[Kevin_S]

Hi Troy K,

Are you building your own CAN message protocol interface?

As far as the performance, there are a few items to investigate.  How much RAM does your computer have?  Do you have a video card?  Do you have an integrated video card?  I saw the "hang" myself, and I also noted that CPU usage on my computer railed at 100% during the hang.

The reason I'm asking all these questions is because I'm not convinced that this is a LabVIEW bug.  I'm leaning toward investigating the hardware you have on your computer.  You're maximizing and minimizing your window rapidly, and you're doing very fast processing - at least trying, whether or not the OS is letting you.

Kevin S.

Applications Engineer

National Instruments

[TroyK]

Yes I am building my own CAN message protocol interface based on the Vector XL hardware.

I spent two weeks investigating and testing the NI CAN solution and found it to be insufficient for our needs.

My computer has 2GB of HP RAM. It's a HP xw4400 with an Intel Core2 Duo 6600 CPU (2.4GHz).

The graphics card is an Nvidia Quadro FX 1500 (256MB of DDR3 RAM).

(I don't think the problem is with my CPU, RAM or Video card.)

You are correct about the CPU usage during the hang. One of the CPU cores went up to 100% usage. The other core was near zero though.

It locked up for about 20 seconds in the attached image. In this test I only minimised it ONCE. The rapid minimising/restoring is just to reproduce the hang in the simple example when the processor isn't busy. Please do not think I sit there minimising/restoring windows just for thrills.

 

Message Edited by Troy K on 10-13-2008 09:36 AM

[LaRisa_M]

Hi Troy K,

I changed the dt of your Timed Loop and noticed that at 25 ms, the hang never occured (at least, never in about 5 minutes of clicking). The Windows clock resolution is indeed 1 ms, but 5 ms is cutting it pretty close. If you try a larger dt in your main application, is there a value at which it won't hang when minimized? You could try that to check if that 5 ms interval is really the source of the problem.

Another suggestion: I know you're using the Timed Loop to check if the Expected Time actually matches the Iteration Time to queue a message. Is there another way this can be programmed without a Timed Loop? That might be something worth looking into if this problem turns out to be unresolvable. I plan messing with the code and researching more, but that might be the only available route to us.

[TroyK]

I have already removed all timed loops from my application and found a way to accomplish a similar result using a standard while loop.

The timed loop bug still exists though. I thought NI might appreciate being notified of it's existence, and hopefully fix it.

Yes I am still convinced there is a bug in the timed loop code.

I tried your suggestion of changing the dt to 25ms. Attached is the screen shot of the processor load when LabVIEW froze after 3 minimise/restores (in not so quick succession). I did it twice, (as you can see in the image) it froze for about 20 seconds each time.

I've been able to very easily reproduce the freeze simply by having the task manager open to the performance tab.

 

I think there is a threading problem with the Timed Loop function. Perhaps it has something running in the user interface thread. When the front panel is minimised, the thread looses priority and hangs... I don't know, just a guess.

This is a bug, it isn't just Windows taking a few milliseconds off LabVIEW or some crazy user expecting too much of a non-RTOS.

PS.. I just got it to hang after a few minimise / restore cycles with the rate set to 100ms (and slightly increased stuff to do in the loop).

Message Edited by Troy K on 10-16-2008 11:13 AM

[TroyK]

Summary so far:

Thank you to all of you who have responded.

I have attached a revised vi demonstrating the problem at a much lower rate.

At the advise of 'Kevin S' I have been monitoring CPU activity during the vi operation (LabVIEW hangs much more consistently, thanks for the tip!) CPU activity in one core goes up to 100%.

At the advise of 'LaRisa S' I changed the rate to 25ms (allowing for Windoze, I also increased what had to be done in the loop - unfair test otherwise)

It still hangs!!! Admittedly it may take a few more minimise/restore clicks (of course it will, you've slowed the rate), but on both my development machines, and a colleague's, it freezes for 15 to 26 seconds.

Instructions:

1. Minimise all windows (Windows+D)

2. Open/Restore the 'minimise lockup.vi' front panel

3. Start task manager and view the performance tab

4. Run the vi

5. Click the vi's 'task bar button' to minimise / restore the vi front panel a bunch of times.

Randomly upon minimisation All LabVIEW code freezes for 15 - 20 seconds. Because it is random, it may take a few minimise restore cycles to get the freeze.

The attached demonstration vi only contains two separate loops to show that all LabVIEW code freezes, not just what is contained in the timed loop.

(I made it beep because otherwise you can't tell if it is still executing when it's minimised. You could just as easily be toggling a DAQ output or something.)

[LaRisa_M]

Hi Troy,

I think your theory about the user interface thread causing the hang is the most likely explanation. We can still do a couple of things to make the UI not have to expend so much CPU to update. I experimented with moving the String indicator outside the Timed Loop, and this improved the lag and hang time since the LabVIEW front panel isn't updating so often. Also, changing the mode for the Timed Loop causes differences in the lag and hang time. You'll notice that just minimizing and maximizing causes the program to lag, but also just moving the front panel around on the screen. While this program is running, the other windows lag some too, but not as badly as the LabVIEW UI. I tried this out on a single core computer as well, and the hang was even longer. Yes, there is a problem with the UI updating, and it seems to be affected by the amount of updating LabVIEW has to do and the other processes running on the computer. Another thing to note is that the loop running the beep function is by default at a lesser priority than the Timed Loop, so if LabVIEW is having any trouble getting the Timed Loop code executed and updated on the front panel, it looks like it decides to abandon the regular While Loop code which has less priority.

Currently, a lot of engineers in the department have been playing with your code, and a lot of ideas are floating around. I hope to update you soon on what the LabVIEW Experts and R&D think about this issue.

[LaRisa_M]

PS: Thanks for all your trouble-shooting work and for passing on the information to us! 

Message Edited by LaRisa_S on 10-17-2008 01:27 PM

[Kevin_S]

Hi Troy K,

After multiple application engineers and even R&D looking into the behavior being described, the information passed to me has been that of your code demonstrating expected behavior.

It's true that it's not desired behavior, but it is expected given the loop intervals, LabVIEW processing (synch, redrawing windows), and the Windows OS redrawing windows.  The code is being run on a non-deterministic machine.

If you present your underlying code need to the LabVIEW community, it is possible that we can all help you implement a better architecture.

Kevin S.
Applications Engineer
National Instruments

[TroyK]

Hi Kevin_S,

Even when I slow down the rate considerably a 20 second freeze of all LabVIEW code (even that in completely independant vis) is expected behaviour?!

Wow, I would never have expected that. (Pardon the pun)

Thank you for your generous offer to help me with my code.  My underlying code contains too many reliant, dependant and proprietary vis to post. (That's why I narrowed down the problem and wrote an example to demonstrate the bug.)

And as I mentioned in a previous post... "I have already removed all timed loops from my application and found a way to accomplish a similar result using a standard while loop."
And "The timed loop bug still exists though. I thought NI might appreciate being notified of it's existence, and hopefully fix it."

Just trying to show a spirit of altruism like others on this forum.