Shipping Examples and Integration with TestStand

The fact that the DQMH Module owns its own event references facilitates integration with TestStand. Refer to the Thermal Chamber Control example available from the Help>Find Examples…>Directory Structure>DelacorDelacor QMH>DQMH Fundamentals – Thermal Chamber for the Thermal Chamber Controller TestStand example sequences.

The ability to call the Public API methods of any DQMH module directly from TestStand results in a very clean TestStand sequence without the need for passing communication references or state data between the calling sequence and the code modules. A vital part of this architecture from a TestStand perspective is that the event reference lifetimes are owned by the DQMH module itself. TestStand can simply make a call to start a module and then make further calls to the module’s API as required. An added benefit of the DQMH module’s use of events is that theAPI Testers that are created with each DQMH module can be used as ``sniffers'' to aid in debugging. Likewise a TestStand sequence can make calls to a DQMH module that is already running, allowing you to treat the module as a service. As the TestStand sequence is only making calls on the Public API of a module, the majority of any debugging required will be carried out in LabVIEW.

To start a DQMH module from TestStand, a call should be made to the Start Module.vi of the module:

The Start Module.vi returns a Wait for Event Sync? value that should be passed to the Synchronize Module Events.viof the same module - This Boolean value can be persisted in a sequence local in TestStand. This approach is used to ensure the events are appropriately created (and therefore ``owned'') by the DQMH module before calls are made to it using request events.

From this point onwards calls can be made directly to the Public API of the DQMH Module directly.

For cloneable DQMH modules the only additional point of note is that the Module ID should be provided to all API calls so the events will be handled by the correct instance of the module. The Module ID is returned by the call to Start Module.vi and should be persisted in a sequence local in TestStand so that subsequent calls to the module can be addressed correctly using this Module ID.