dqmh

Blog

LabVIEW Messaging with the DQMH Framework for Code Reusability

On May 22, 2020

Software system design has not always been common practice, especially in automated test system development. However, in recent times, it has become more widely used to improve software engineering productivity and software system reliability. One of the keys to success in software system design is the implementation and reuse of a software architecture consistent with the problems at hand and the tools being used to solve them. Whether you are a junior or senior engineer, you will be faced with issues and bottlenecks caused by your software architecture and software development process which can and will disrupt the synergy of your design team. To be successful, it’s important to have access to tools and pre-built frameworks to “code” around and thru those issues. Choosing the correct set of frameworks - software components or sets of modules that support a basic programming model by encapsulating common functionality that can be reused within an architecture - will help your team create a flexible, maintainable application. In the Test Systems arena, both the NI Queued Message Handler and the Delacor Queued Message Handler frameworks can be used to build a robust and reusable architecture for LabVIEW applications. The NI QMHTM framework has limitations. However, moving to the DQMHTM framework provides a solution to those QMHTM limitations.

Each of the above frameworks comes with its own set of complexities, largely due to the tremendous number of features within the frameworks and the depth and breadth of experience within the community of developers attained over the years. These complexities sometimes come with limitations in performance. A specific caveat of the Queued Message Handler or (QMHTM framework) is that a queue can create a serialization (delayed execution of a message request due to un-processed message stack-up in the queue) issue by scheduling multiple processes/states that must complete execution before another message is processed or consumed. Specifically,

  • Serialization causes functions that require significant execution time to delay the processing of any other message driven related functions, and
  • Serialization can also cause high-level messaging and/or priority messages to wait on any currently running messages being processed or consumed by the message handler.

These limitations will be perceived as poor performance by the user and often will impose the need for additional event management logic in your software architecture. The additional logic may be required to minimize this “intermodular communication latency” that is built into your LabVIEW application due to the nature and operation of the QMHTM Framework. This situation can also lead to undesired overhead on system computing resources or more critically, additional nonrecurring engineering cost and time (NRE).

The DQMHTM framework has addressed the above serialization issues with the implementation of an “event-based message handling” mechanism rather than a “queues-based message handling” approach. DQMHTM, a modified version of QMHTM, gives the developer the ability to run multiple modules of code in parallel and communicate via “events” generated in real time. Each module can broadcast an event and every module can register for an event, depending on the needs within the architecture. The built-in DQMHTM Framework scripting helps to build synergy between developers by starting every project, or module, with a similar code base. The result: more code/style commonality and reusability.

The figure below depicts an architecture with different modules that were previously using QMHTM alone. The DQMHTM framework has allowed each module to broadcast real time messaging to relevant listeners while operating in parallel. The passing of relevant data is as simple as registering for an event. If you need to add any additional modules, there is no need to edit the existing code to change data types, add attributes, or add modules to a class because it’s private.  

DQMH Architecture

Taking the time to verify that your architecture solves the complete problem at hand and streamlining development through reuse for current and future projects is a worthwhile exercise. Identifying gaps in your current architecture and verifying it is the most efficient way to have a group of developers work together provides for a clear and concise design.

If software system design is holding back your team, contact us to see how we can help mitigate this challenge.

 

Contact Us

 

Blog Comments