Click and hold windows bar freezes LV execution

[Navne]

Hi guys

I have a real time DAQ application that is usually runnning full screen, and as such I never experienced this problem before, but now we have moved to a scaleable layout and this is becoming an issue.. 

When you click and hold the windows title bar of a running VI, LabVIEW completely stalls the execution of the application for around a second.. To be more specific: if you just click it and moves the window around instantly this is not a problem, but if you click and hold the left button down on the windows title bar of the VI / .exe running, execution stops for around a second.

For a real time DAQ this is a rather long time to choke the read process.

I've tried this on two different brands of PC's and I can reproduce on both.

Does anyone know what causes this behaviour and possible how to work around it.. VI has been tested on XP and LV 8.6.1

attached png of a "highly complex" piece of code to illustrate the problem

Thanks in advance.

[Dennis_Knutson]

When I run it, execution does not stop but the update of the screen does pause. In other words, I click and hold the title bar and the iteration count display does pause but when it does update, it resumes at a higher count so the execution does seem to continue.

[Navne]

That is also what I experience - thank you for making my post more precisely..

However - if you run this program with a real time DAQ and the buffer is only say 200 ms large, you will experience a buffer overrun, so I'm wondering where and when the execution is performed... It could actually be that the loop chokes on having to do x amount of iterations in a very short time, and thus also x amounts of screen updates.. I will try and make a temp DAQ program that has not front panels at all... This does not solve the problem as I still need to have the DAQ running in the same program that does the math and displays the results (yes, they are not in the same while loop) , but it could maybe help to clarify the origin of this "issue" - I'll post my results on that later. 

[Navne]

update:

I've removed all elements from the front panel and the result is exactly the same - the loop stalls for close to a second, choking the DAQ.. Yes I know how to deal with this, larger buffers, error handling etc, but I'm just curious as to why this may happen, and if it is possible to avoid it..

As it is clearly illustrated by my choking queue in the actual program - the loop does not execute, how ever, as it is very well defined above, once the freeze stops, the iteration number indicates that the loop has actually been running.. Can anyone explain to me why the loop can freeze, and then execute the code very rapidly, when all there is in the code is a simple wait statement.. that does not seem very deterministic to me...

[Dennis_Knutson]

My tests with simulated DAQ do not show any problems at all. Can you post your code?

[Navne]

As I'm not using NI hardware the code makes very little sense as it will not run without the proper hardware. (dedicated .dll file and taylor made DAQ vi's) 

In essence the current test bench is a very simple DAQ in one loop (whille loop that ask for samples in the buffer, if any read the samples put them in a queue, then wait for x amount of ms to free cpu to other tasks, then ask again) and another loop reading elements from the queue and process them, since this is more time consuming than the actual read.. However, this coding structure is working very well and has been for a number of years, so it is not really of any relevance.. The only relevance is that the hardware I use has a maximum buffer of roughly 500 ms all the way thru the system - and when I press and hold the windows title bar the entire execution stalls for longer than that period of time, effectively overflowing my daq buffer... 

As you mentioned previously the loop actually performs the iterations since for instance the counter on the simple example VI will increase by a certain value, and with simulated daq I'm pretty sure this too will be the case that the loop will actually perform whatever task it is ordered to do, but it is done as a large burst once the freeze is "over", as clearly indicated by the fact that a real time DAQ is choked due to buffers not being read by the code - that is stalled do to the click on the windows bar.. Question still remains, what is it in the LV execution engine that stalls so badly?

cheers, Jacob

[JackDunaway · Accepted solution]

This question has been asked before, and Lynn provides the same advice I was about to suggest - create a separate user interface VI from the DAQ VI so they can run as "independent" (I use this word loosely) processes. The DAQ VI acts as a producer loop feeding the UI consumer VI, where the "buffer" that is allowed to fill up between the two is a Queue, not the very limited hardware buffer.

Sorry to break the news, but if you want to solve this problem, likely the only solution is to have multiple VI's for your two processes. (By the way, I'm able to confirm the 500-600msec delay when clicking on the Windows Title Bar in Windows 7 using a very recent version of LabVIEW)

http://forums.ni.com/t5/LabVIEW/mouse-down-in-title-bar-momentarily-freezes-vi/m-p/868903?requireLog...

[Navne]

Point taken... It is not a life support system we develop so if user manages to kill the buffer on the click, we catch the problem, and restart the hardware and flash a warning - I just got curious.. 

Off topic yet relevant:

moving the DAQ to a seperate .exe file would make sense in many ways. To the best of my knowledge the LV queue is only available in one execution space at a time, so if i make producer.exe and consumer.exe, both with a labeled queue called "samples", they will never see each other, as there will be a "samples" queue in the consumer.exe space, and another in the producer.exe space.. Am I right? IF, and I sure hope so, cause I just tested it to make sure I'm not making a jerk of my self, what would be the most clever way to ship 50K samples / sec around between two exe files? I all ready use the datasocket solution to transfer measurement results from the main program to a remote webviewing feature - however, this is 5 double values and a graph updated once / sec, and not 50K samples (DBL values) that need to come continuously - any wisdom to share on this topic? Can the datasocket handle such large amount of data in real time, or is there a more clever way to share this data between 2 exe files?

[JackDunaway]

No, I never intended for the producer and consumer to be split into two separate executables, just two front panels (two parallel processes) within one executable.

[Navne]

Hi Jack

Okay - they all ready are.. the DAQ doesn't really have a front panel as I run it as a subroutine but anyway, there is one loop handling only the read from the buffer, and push of elements to a queue, and then there is another loop running the DSP and UI updates - I think we've done that properly, but the main issue is that the entire execution stops of that exe file once the user clicks the title bar. so even though there are several threads running within the same program (given that it is a multicore machine) they all freeze when the user clicks and holds the titlebar.