Strange behavior of LabVIEW in multidisplay monitoring

[rolfk]

Did you read the PM I sent you?

The reason is clearly in the architecture of your application. It uses many different Call Library Nodes to access the different IO hardware and most if not all are set to run in the UI Thread.

To make matters worse there is one big fu**ing loop (BFL) that handles the ENTIRE application in a sequentiual stream from data input, over processing, to data output and also the UI handling happens to be in that same loop. So everytime LabVIEW comes in this BFL across one of these Call Library Nodes and VI Server calls to handle your dynamic UI, it has to wait for the UI Thread to be available. And when you drag your window around on the title bar or similar, that UI thread is sort of blocked by a tight tracking loop that closely interacts with Windows.

Basically, that the application even seems to work reliable when no Windows window handling comes in the way is already almost a miracle, that it doesn't once the Windows window handling comes into play is absolutely logical!

You have two options:

1) Leave it as is and learn to live with it. In my 25 years of LabVIEW programming I have seen several lab applications with notes on it to not touch a certain device while a test is running and even one or two where you were explicitedly warned to even touch anything on the front panel of the application during a run (and yes that was because the application was so brittle that it could break from a to sharp stare at the front panel )

2) Rewrite the application! The underlaying architecture isn't even terrible, although I think they did abuse the old style (pre LabVIEW 8.0) LabVIEW GOOP to some extend. The object hierarchy doesn't immediately look like it was well thought out despite that there is clearly a principle behind it. But most of that part could be probably just reused except that all the IO drivers should be reviewed if the Call Library Nodes in there can't be set to reentrant execution. But don't just go and set them all to reentrant. If the underlaying DLL is not programmed to work reentrant you are going to get potential problems with that unless you can guarantee that your application never ever happens to call two different functions in the DLL in parallel. And if you keep the serial execution of the IO in place like it is now done to the extreme, you could guarantee that.

But the different parts like IO, processing and UI handling all belong each in their own indpendent LabVIEW loop. One possible pitfall here might be the implementation of the GOOP objects  They do locking of the object before updating its internal data but on my quick look I saw two objects methods already, which did retrieve the data, modify it, then lock the object, update it, and after that unlock it. This is a potentially harmful sequence if that same object can be modified from other methods too. The lock over an object should be held over the entire read, modify, write back seqence and not only over the write back part if there is any chance that other data in that object can be changed by other methods. Otherwise your object is not safe for use from parallel threads, such as when you place the different tasks into their own indpendent LabVIEW loops.