This post was originally published at Walking the Wires
For the past few months we have been working on an automated test project where several pieces of instrumentation (and the Unit Under Test) are handled by a DQMH module. These modules are launched by, and then run asynchronously to, a TestStand sequence.
This is a great way to implement automated tests, as it results in very “thin” TestStand sequences where the majority of the steps in a sequence are simply calls to the public API(s) of the various DQMH modules involved in the test. This allows TestStand to be used for things it’s great at, such as sequencing functional operations, producing great looking reports and providing an overarching test framework. The majority of the functional code remains in the LabVIEW domain, in an asynchronous module which has state and a public API.
This also means that your DQMH module can be debugged in the LabVIEW environment, and its API fully tested using the useful API testers that are included with every module created using the DQMH toolkit.
This is something I’ve presented on before, so if you are interested in learning more, this presentation is a great place to start.
One thing that people often don’t realise is that because the underlying message transport mechanism of a DQMH module is LabVIEW User Events, we can continue to use those API testers even if the module is already running and is being called from someplace else, like a TestStand sequence.
This gives us the chance to observe outbound module events (we call them Broadcast Events), and to also fire Inbound (Request) Events. Effectively, this gives us Peak & Poke functionality from a LabVIEW based UI. The ability to not only “sniff” data coming out of module but to also “Inject” data into a module should not be underestimated.
This video demonstrates a simple example:

So there you have it, with just a simple change to the application instance (context), your existing API Testers can make great debug tools allowing you to further test the behaviour and interactions between your modules and the calling code.
Here’s the  video timings if there’s a particular topic of interest.
6:44 Running DQMH Modules from TestStand
10:00 Using the API Tester as a “sniffer”
13:30 Using the API Tester to debug reentrant clones called by TestStand
As always, we love to hear your experiences and feedback.
Happy Wiring Folks!
Chris