Minimise front panel of vi containing timed loop = problem

[TroyK]

Is this expected behaviour...

Run the attached VI.

All it is supposed to do is beep every 10 cycles.

When you minimise it and try to restore the front panel though... it locks up for a random amount of time.

I don't think it is supposed to do that. (I'm running it on XP Pro.)

 

Originally I was chasing this problem in a data acquisition loop. The buffer would overflow and exit the app with an error when it was minimised.

It took all day to track it down to this.

Hmmm... I just tried to save it back to a version 8.0 vi and it doesn't seem to have the same error!

Message Edited by Troy K on 10-03-2008 05:26 PM

Message Edited by Troy K on 10-03-2008 05:31 PM

[TroyK]

Ooops, forgot to mention (before edit time expired) minimise ALL OTHER WINDOWS.

I just tried the 8.0 version again and after minimise/restore a couple of times it locked up too.

Sorry about the red herring.

Message Edited by Troy K on 10-03-2008 05:40 PM

[Kevin_S]

Hi Troy,

Did you ever run this VI on a Real-Time target?

Kevin S.

Applications Engineer

National Instruments

[TroyK]

Nope, only windows.

Have you been able to reproduce the error?

As far as I knew, timed loops should still work under a non-RTOS. You just get millisecond resolution instead of microseconds.

I've also found another bug (after eliminating all timed loops). If I run the 'profile performance and memory' tool and then stop it while my vi is running, it causes a similar buffer overflow in my application. I haven't been able to narrow down where exactly its happening yet though.

I think it has something to do with vi execution priorities and call library function nodes set to run in 'any thread'. I'm a bit too busy at the moment to spend a lot of time on an error I hope I will never see once it is compiled.

[Kevin_S]

Hi Troy K,

I have opened your VI and run it with LabVIEW 8.6, 8.5, and 8.0.  I have not been able to see the program crash, disappear, or indicate that anything was wrong.

I ran the program with everything else minimized.  I then minimized and maximized the running VI multiple times.  I also ran the Profile Performance and Memory tool multiple times when the VI was and wasn't running.

If anyone else is able to replicate this issue, please post your findings.

Kevin S.

Applications Engineer

National Instruments

[TroyK]

I'm using LabVIEW 8.5.1 on two PCs and it does it on both of them.

I just emailed the vi to a colleague and after a few minimise/maximises it locked up on him too.

I've just found that if I remove the left and right data nodes inside the timed loop the bug seems to go away.

Steps to repeat bug:

1. Minimise all windows (Windows+m)

2. Restore vi front panel and run it. (It should start beeping twice a second)

3. Minimise / Restore it rapidly by repeatedly clicking on the vi's Front Panel 'task bar button' (down the bottom).

After a while the beeping will stop when the front panel is minimised and it wont restore. Then after a while (with or without clicking on the task bar button) the front panel will restore and the missed periods will execute very quickly (as the timed loop does what it is configured to do).

I think because of the simplicity of the example vi the bug doesn't show up as often. When I ran it in the real application (too many vi's to post) it crashed every time. In the real application there isn't much going on in the timed loop, it is just used to queue items into a separate consumer loop. The problem is that when the bug occurs, ALL LABVIEW CODE stops executing, not just the code inside the timed loop. So another vi running in parallel (in a daemon) that retrieves messages from a device queue stops and the device buffer overflows.

Attached is a modified vi to demonstrate that code outside the timed loop stops executing too. The bug occurs here on three different PCs, the only common thing I can think of is LabVIEW 8.5.1.

[Russ_Evans]

Hi Troy,

I went ahead and gave it shot and it did, at least temporarily, freeze up for me as well. I ran it with LabVIEW 8.5.1 and Win XP Pro SP3. It did eventually come back to life but would freeze again and again, each time however it would eventually come back to life.

cheers,

--Russ

[TroyK]

Yay... thanks Russ.

I'm not just going mental. Yes, it does come back to life. But if other LabVIEW code executing at the same time can't handle being frozen for a while, you have a problem.

[Kevin_S]

Hi Troy,

I believe I misunderstood initially.  I was looking for a crash.  I do see a slight delay in maximizing your VI when done very quickly. 

The delay no longer exists when the loop times are increased though. 

Is there a reason why you want your code to run at 5ms intervals?  (I ask because you're getting closer to the clock resolution of the Windows Operating System.)

Also, is there a reason why you use a Timed Loop and a While Loop both at the same time?  (I ask because one has a variable priority setting while the other doesn't.)

When you want your code to run on a Windows Operating System, your code is at the mercy of Windows (virus scan running in the background, Window's updates, other OS threads).  Your code is the low man on the totem pole.  The OS taking priority over your code is more pronounced the faster you try to run your code.  My initial analysis of the delay is that a lot of Windows overhead is created when maximizing and minimizing the VI rapidly in succession. 

In general, if you want higher precision with control of the OS threads as well as your code, you would need to run your code on a Real-Time Operating System.

Kevin S.

Applications Engineer

National Instruments

[TroyK]

The 5ms time interval is for a CAN message scheduler. All it is supposed to do is check the expected iteration time and queue a message when the time matches.

I used two while loops in the example to show that all LabVIEW code freezes, not just the code in the timed loop.

I do realise I am at the mercy of the operating system for software timing.

When the code freezes (here on my PCs), it stays locked up for 10 - 15 seconds, it isn't a slight delay. A slight delay I can handle/expect.