This is the second part of a 3 part series on creating modular, scalable LabVIEW applications. If you haven’t, feel free to read the first section, “Creating a Modular LabVIEW Application (Part 1 of 3): Creating an Expandable Data Format”.
This part of the series will focus on avoiding data dependency between different devices and VI’s. Obviously there are going to be some cases where it is unavoidable, but for the most part, you want to strive to make any 1 piece of your application able to function as a standalone program. To explore this, we will again focus on the simple example of a test system with 1 serial weather instrument (for temperature, humidity, etc.) and 1 NI PXI Chassis for digital IO and analog sensing. As discussed in part 1, our basic architecture will start with creating 1 VI for controlling and sampling from the serial device, 1 VI for controlling and sampling from the chassis, and 1 master VI for overall control and data merging.
The last thing that you want is to try to tie together too many different devices in the same VI, where you can easily run into the problem of different data rates or different initialization procedures. Trying to coordinate all of these in 1 place will only lead to unnecessarily complicated structures, and enabling or disabling different devices will only make it more complicated. If, on the other hand, you divide up each device to have its own VI state machine, you will be free to adapt to the specific device and enabling or disabling the device in your test will be as simple as running or not running the VI.
Ultimately, you will want to develop an architecture that, as much as possible, allows you to avoid dependency between VI’s. To best facilitate flexibility, VI’s for each device should be as self contained as possible, with the ability to run on their own. This means they should have their own time base, be able to manage their own data, and not depend on settings from any other VI. This will allow you to add or remove devices and VI’s at will and will also greatly improve your ability to segment the system into manageable pieces for test, commissioning, and debugging.
For maximum flexibility you will also want to make sure that you avoid the situation where 1 VI relies on another for data or control. The best analogy is to create your architecture like a tree instead of like a web. This enables you to turn a “branch” on or off without having any impact on any other branch, whereas if your system turns into a web of VI’s, you won’t be able to modify, add, or remove any piece without at least creating contingency procedures with the pieces surrounding it.
For example, you would want to provide your serial device with its own sampling time-base. This could somehow be aligned later to the hardware time of the chassis, but you wouldn’t want to tie it directly unless absolutely necessary, so that you can run the serial device without the chassis and vice versa. Also, if there are any universal items that are needed, it is best to have them coordinated through the master VI if possible so that no 2 device VI’s are dependent on each other.
By making every effort to avoid direct, dependent connections between devices and their VI’s, you will create a system where you can change the configuration quickly and easily. If no piece of your test relies on any other part, you can turn on or off devices as they are needed and won’t need to make any changes to the rest of the system. You will even be able to create brand new state machine VI’s to add on new devices, and they will be able to integrate with the system without overhauling the architecture to fit them in.
See Also:
Learn more about DMC's LabVIEW PLC programming services.