LabVIEW
Control Front panel items from subVI (Best practice)
Hi community,
I am working on an measurement software with medium complexity. What I have realized (and what I have realized in numerous projects of mine in the past) that my subVIs need to read/write the front panel items. For example: I have a stop button on the front panel and I'd like to continously check its state in my measurement VI, so I can stop the measurement right when the user presses the stop button. For this I create a control reference of the Stop button and wire it to the subVI from my main app.
This is a simple a neat solution... BUT...
This solution is getting more and more convoluted when your subVI needs to read/write several front panel items. In this case I can create a reference for each one of them but then my block diagram will be packed with references (not to mention that it decreases the number of available connectors on the subVI). To get even worse I often need to write subVIs reading/writing the same UI element which means I need to create lots of references for the same control or indicator.
To get even worse what if I need to use that control reference in the subVI of a subVI of a subVI. I guess if you understood the issue above you also understand why this is very uncomfortable.
So... what I normally do is creating a typdef of a cluster of control references. Then I create a single process shared variable with this type and at the beginning of my application as it is shown below:
So from this point I can call this variable in any of my subVIs and get the reference of my UI elements. This has lots of benefits but also has disadvantages:
- Breaks the dataflow model
- Decreases the number of inputs of the subVI. Which could be a great thing, but now many of my subVIs have only an error in and an error out, so its hard to guess whats going on in the VI just by look, as it has no inputs
- it is incovenient to use because I have to put down the variable, then an cluster unbundle by name, and then a property node to read/write the control
I am wondering what is the best practice here if any. How do you guys approach the problem in you applications?
thanks!
Hi 1984,
I dislike linking my interface with my 'workers'.
I always tend to approach an MVC architecture. And to do so I mainly use User events to communicate between all my threads.
This way you can create some 'standard' events that your 'worker' (VI doing acquisitions) can send but this kind of VI can also listen to 'UI generic' events. Events are the links between my threads, and on a specific event I can choose to update a control / or stop a loop for example.
The really big issue with using control references is that is it HORRIBLY SLOW. Everytime you read/write a property node with a control reference, you are forcing a thread swap to the UI thread. The thread swap itself is a performance hit. But by running the UI thread, you are also forcing a redraw of the front panel. Plus you have way too much coupling between your different modules.
The idea with decoupling modules is that your DAQ loop doesn't care one bit who else is running. I like using Queues to allow somebody out there to send commands to that loop. You can timeout on the queue if you want something to happen every so often. So in your stop button case, you just use a queue to send a command to the DAQ loop to stop when the stop button was pressed. What this does is it makes things a lot more reusable and easier to troubleshoot. You can run something with just the DAQ loop and debug it without having to also have the rest of the system running. Passing data around with Queues, Notifiers, and User Events are the key to making the decoupling work well.
No typedef modification each time a new control has to be updated. No direct link (your ref in your case) between your 'workers' and your HMIs.
