In part one of this series, we explored the NI 2023 Technical Sessions “Creating a MeasurementLink Plugin” and “Using Python and TestStand to Boost Your Test Development.” In this part of the series, we will be taking an in depth look at “The DQMH framework” and “The LabVIEW UI of Your Dreams.”
There were several different technical sessions at NI Connect featuring DQMH (Delacor Queue Message Handler), as well as TestStand in general. DQMH is a framework in LabVIEW (available to install in VI Package Manager) based on a Queue Message Handling system. At a basic level, generated user events are queued up to be handled in a separate thread. There are ‘requests’ for the module to do something, and the module can also ‘broadcast’ out information to any code modules listening in. A common use-case for a DQMH module is interfacing with hardware resources. The advantages DQMH brings are the scripting tools it provides to make code generation easier. When using the scripting tools correctly, it also creates documentation for the code module as it is being created. It also provides users (and developers) a public testing API that can help troubleshoot code interfacing to the DQMH module.
One session went more in-depth and discussed using TestStand custom steps to further implement DQMH modules. For example, you could have a custom step type that would allow each event to have a custom timeout. Adding onto this, a custom step type could be made for each DQMH module that is created. Doing this would be one way to further implement a DQMH module in TestStand. There were also tips about making the DQMH modules more reusable in TestStand by creating a sequence file with a sequence for each command in the DQMH module. We have seen DQMH modules pre-compiled into a packed library, but not breaking each command out into a TestStand sequence. From a reuse perspective, having a precompiled packed library and then inserting it into a TestStand sequence file to act as a wrapper seems like a great method to use.
To learn more about DQMH, click here.
The LabVIEW UI of Your Dreams:
This technical session went through the philosophy and methodology of building user interfaces in LabVIEW. The session very lightly touched on the actual programming part, mainly on how to arrange UI elements on the screen and tips on how to make the front panel resizable. The session ranked UIs by the effort required to make them and by the dreaminess (or nightmarishness) of the design. The session also considered how each UI was distributed, i.e, downloaded from a git repo and run from source, distributed as an .exe through a package manager, etc. The session started with a discussion of the minimum viable product, which was presented as basic LabVIEW VI that is run from source, performs some kind of measurement, and displays the measurement result in an onscreen indicator. Next was the minimum likable product, which was still run from source but organized the UI in a useful and mostly intuitive way. Up from the minimum likable product, there was the platform which was a much more polished product that would be maintained and distributed through a continuous integration system.
One of the most important takeaways from the session was the idea of normalized pain. Normalized pain occurs when an awkward and clumsy process becomes the standard within a work area. Normalized pain can be summed up as, “we’ve always done it this way even though it really hurts and no one has thought to change it because everyone is used to the pain.” The presenter advised the audience to identify these points of normalized pain and build a better solution for the users. An example given in the session was a VI that would check if a given file path was valid or not; the logic in the VI was reversed so a good path would give a bad indication and a bad path would give a good indication. The users had become accustomed to the incorrect logic. It was even in the training manual for the UI.
Another takeaway was to occupy the user’s space; to get in the user’s shoes and see what work they do and how they do it. Talk to several operators, watch an operation and determine what defines a successful operation. Ask the operator, “if you could snap your fingers and change one thing, what would it be?”
The session encouraged developers to take a realistic view of the effort required to build a UI, the methodology behind how to make a UI useful to its users, and a few technical hints about the organization and structure of the UI.
NI Connect is on a smaller scale now than it used to be, but still a worthwhile experience to attend. It offers new perspectives and introduces us to new technologies. There were a lot of companies represented showcasing demos on the floor, as well as a wide range of technical sessions. Linux compatibility, LabVIEW coding techniques, python support, and new tools/technologies were some of the options available. The demos on the floor offered insight into new technologies and potential applications. One of the main attractions on the demo floor was a fully autonomous Indy car, loaded with multiple cameras and sensors. Another highlight coming in LV 2023 Q3 is a zoom feature. This announcement came to great applause during the first keynote. Overall, NI Connect offered quite a few insights into improving the way we use their products and also showed us some cool improvements to their existing products to look forward to in the near future.
This content was developed with support from the following additional members of our DISTek team of experts: Matt Johnson (Test Engineer) and Justin Nelson (Test Engineer).