Most LabVIEW test applications start small: one DUT, two instruments, one engineer. Five years later there are twelve product variants, three instrument generations and one big VI nobody wants to open. The problem is rarely LabVIEW itself. The problem is architecture that was never meant to grow.
That is why we build our test systems on DQMH (Delacor Queued Message Handler), a free, open framework maintained by the DQMH Consortium and widely used in the LabVIEW community.
What DQMH gives you
- Modules with a public API. Each part of the system – an instrument, the DUT communication, the sequencer, the logger, the UI – is a module. Other code talks to it only through defined requests and listens to its broadcasts.
- An API tester per module. Every module comes with a tester, so you can exercise it in isolation – on the bench or before the hardware even arrives.
- Scripting tools. New modules and events are created by scripting, so every module looks the same. A new team member understands the tenth module after reading the first.
- Singleton and cloneable modules. One power supply or eight parallel test channels – the same pattern scales.
What it changes in practice
| Typical problem | With a DQMH architecture |
|---|---|
| A new instrument model breaks half the application | Only the instrument module changes; its API stays the same |
| Nobody can test a change without the full test bench | API testers and unit tests exercise modules in isolation |
| Knowledge sits in one developer's head | Uniform structure and documented APIs make handover realistic |
| Adding a product variant means copying code | Variants are configuration and sequencing, not new code paths |
Migrating a legacy application – step by step
A rewrite from scratch is rarely the right answer while production depends on the tester. We migrate incrementally:
- Review. Map the existing code: instruments, DUT communication, sequencing, data handling, UI, and the shared state between them.
- Define the target modules and their requests and broadcasts – on paper first.
- Wrap, don't rewrite. Move existing, working driver code into modules behind the new API.
- Replace shared state (globals, functional globals) with module messages, one dependency at a time.
- Secure each step with tests – API testers and unit tests – so production keeps running throughout.
When DQMH is not the answer
For a one-off lab script or a single-instrument measurement, a simple state machine is fine. DQMH pays off when a test system has several asynchronous parts, a long lifetime, and more than one developer.
LabVIEW code & architecture review
A review of your existing test application with a concrete migration plan – a good first step.