Showing results for 
Search instead for 
Did you mean: 

Strange behaviour of LabVIEW in multidisplay monitoring

@billko wrote:

Computers are very good at doing what you TELL it to do, but not necessarily what you WANT it to do.  Hopefully, the more developing experience you get, the closer TELL and WANT become.  Smiley Wink

As someone explained it: Computers are very sofisticated morons.


G# - Award winning reference based OOP for LV, for free! ADDQ VIPM Now on GitHub
"Only dead fish swim downstream" - "My life for Kudos!" - "Dumb people repeat old mistakes - smart ones create new ones."
Message 11 of 21

What version of Labview? You said windows XP, perhaps this is related to a very old version of labview?

0 Kudos
Message 12 of 21



During debugging of code I found that whenever I click on title bar there is gradually reduction in CPU usage (34% to 18% and again it comes to 34% within 1-2 seconds). Hence due to this my data acquisition loop becomes slow.

But I have question that if it become slow it may update value slowly but here it is reading and writing adverse value (like if my control is true, it writes false). Don't know why ?


Normal CPU usage - 34% approx.

OS - WindowsXP

LabVIEW version - 2011


0 Kudos
Message 13 of 21

As always with such problems: Show us your code! And I do not mean a screenshot but the real actual code!

With this type of problem we can keep guessing all day what might be the cause and it will give you a few dozen possible guesses and maybe none of them to the point.

My fairly informed guess based on over 25 years of LabVIEW programming experience is that your program makes assumptions about the order of events that occur in your code and when Windows event handling gets in the way such as when you move a window to a different screen or you click in the non-client area of a window, that assumption falls on its ass!

Rolf Kalbermatter
Averna BV
LabVIEW ArchitectLabVIEW ChampionLabVIEW Instructor
Message 14 of 21

One more thing , when I right click on task bar and select MOVE option and after that if I move screen then it is working perfect !!!!!!!

0 Kudos
Message 15 of 21

I also observed that this jump in CPU usage creates delay in my data acquisition loop and hence due to this problem occurs. 

0 Kudos
Message 16 of 21

How many CPU cores do you have?


You said you have an XP machine, and it sounds rather old.


I have no idea how this would cause the digital I/O lines to get new data written to them, but I did have an application, one of my first on an ancient 1 core PC, and this PC was hold at the time I wrote the app in 2005, that if I did something UI related like drag the window around, it would cause the application to essentially freeze at what it was doing (continuous data acquisition and display) until I stopped moving the window around.  The single core mean that when the UI thread took control, the other threads LV was using was put on hold.


What are the specs on your PC?  Is it single core?  If it is, throw it away and buy a new one!  Windows XP is long past end of life anyway.

0 Kudos
Message 17 of 21


I have attached image for CPU core. It is multicore. 

System specs:



# of logical processors :8

# of packages :1

# of cores per package :4

# of logical processors per core:2

0 Kudos
Message 18 of 21

In message 1, you said you had only 2 GB of RAM!  ??


There is still a chance my theory could apply if your code happens to be such that the various VI's are set to run in the UI thread.  Others on the forum are more of an expert in this topic.



0 Kudos
Message 19 of 21

We have two system both have same configuration except RAM. One has 2GB RAM and other has 4 GB RAM. But both system have same issue.

0 Kudos
Message 20 of 21