This is the final entry in a 3 part series for creating modular, scalable LabVIEW programs. Feel free to visit the first two entries, “Creating a Modular LabVIEW Application (Part 1 of 3): Creating an Expandable Data Format” and “Creating a Modular LabVIEW Application (Part 2 of 3): Eliminating VI Dependencies”.
This final part will focus on the need for a universal control and communication scheme between VI’s that control test devices and sample data and some master VI. Once more, you can think of the simple example of a test with a serial device reporting weather info (temperature, humidity, etc.) and a NI PXI chassis controlling digital IO and sampling analog data. Each device would have its own state machine VI created for it and there also would be a master VI that would coordinate the two and merge the final data.
One last thing to be sure of with your architecture is to develop a universal communication protocol for controlling the start, stop, and configuration of your tests. Obviously messages to start and stop sampling are very important, but don’t also overlook the ability to launch VI’s, shutdown instruments, and modify settings via a central master VI. It is quite possible that each instrument VI will need to have its own settings (com port settings, baud rates, channel configs, etc.) but will also need to receive shared universal settings (database connection strings, test duration, sampling rate, etc.) Creating a universal method to send and receive all of these messages that avoids making them particular to a certain instrument or group of instruments will greatly improve your ability to add to the system in the future.
The ideal scenario is to be able to make each device state machine follow a “template” where the universal communication pieces are all set in place and you are able to fill in device specific components. For example you would probably want all of the devices to respond to a “Prepare for Test” message where each VI would perform any initialization that is needed prior to sampling data. For example the serial device would initialize the serial connection and the PXI chassis might make perform a pre-test calibration for a baseline of existing sensor conditions. The same generic message would be broadcast out, presumably by the master VI, but each device VI would be able to perform its own specific procedures and then report back that it is complete. The key step is to identify all of the universal messages that your test will need.
In many circumstances it will also be helpful to keep track of the reply from each VI to know if the overall system can proceed. For example, at the end of a test, each VI might reply to a “End Testing” message indicating that they have finished sampling data and that their data is ready for merging into a complete “test data” file. You would want to make sure that every VI had reported that it was finished and its data was ready before the master VI attempted to culminate the data together.
The beauty of this is that, once the universal messaging is determined, it can be sent and received in whatever way works best for your system. You can even go as far as running different device control state machine VI’s on different PC’s and have them communicate via TCP!
In summary, there are many aspects to consider when creating a large scale architecture in LabVIEW. To keep your system modular and scalable, the 3 most important things to focus on are maintaining a universal data format, avoiding dependencies between different devices and their VI’s, and creating a set of universal messages to control all of the VI’s. By following these recommendations you should find that it is much easier to add and remove components throughout your system’s lifecycle.
See Also: