Not to mention the possibility of race conditions. (I was going to write a bit more, but I got interrupted)
It sounds like there's the possibility of the user entering a new value and that value may get overwritten by the read action in the Timeout event. Then the new value would not get written to the hardware.
Maybe I'm not quite understanding what you are doing either. Maybe the reads in the Timeout are not writing to the same controls that the user is changing?
Thanks for all the responses, much appreciated!
Ok, let me try and clarify myself. For simplicity, i have analog inputs and digital outputs. So when i for example click on a "valve" component on my gui. I send a command to the hardware to open the valve, however, there are 2 inputs associated with a valve. The "openStatus" value will return true and the "closedStatus" value will return false. This is to ensure that the physical valve has opened. For this the event structure seems fine!
Then comes what i and from what you guys have said, is the problematic section. I need to constantly update the analogue display values. These are display only, cannot be written to! So the user interface will not be able to change it. I think the reason why i put the "aquisition" of the data in the timeout case is to sort of isolate the various steps. So i do the aquisition here (Since we cannot have an event case associated with the hardware itself, and the timeout section seems to be the ideal place, since it will always be executed, so we have a constant data aquisition!) and the range checking and alarming goes in the value-changed event case for each gui analog display component!
I hope this clears things up!
Constantly writing to Property nodes is not the best way to do things. Every time a property node is used, LabVIEW must switch the execution system to the User Interface thread (which takes time) and then switch back (more time). Not to mention it causes a copy of the data to be created.
Take a look at the attached VI. Open and run it. All it's doing is generating a random number and writing that value to the indicator through a property node in a For loop that runs 10,000 iterations. On my machine, it takes about 450ms to do this through the property node. Now delete the node and move the indicator into the For loop and wire it directly to the random number function and run it again. My time with this setup is about 5ms.
So depending on how fast your Timeout is executing, this may or may not be a problem. But it's something to keep in mind.
A better setup may to have your DAQ read in a separate While loop. In this loop, read all your data using a single read (or a single read for each device if needed) and parse the data and write directly to the indicators.
Wow, thats amazing, I cant believe that the property node keeps the system so busy!
I guess i should rethink my use of the property nodes. I just found it quite convenient, when for instance you get a value in for example the true section of a case structure, and you also want to use it in the false or in some other section, then this seems like a convenient "pointer" type of thing! Furthermore, it meant that i did not need to have a hundred lines all over the show to link a control to various sections that require its value.. It made things so much cleaner and well as i notice it comes at a huge price!
What would be the best way to reference a value of some indicator or control from various sections which cannot see that pointer.