Please follow the step-by-step instructions at the end of this post for how to get this example working.
This is an initial prototype of an alternative controller for the Measurement Utility that provides a TestStand interface for the measurement abstraction layer. I am posting this early version to gauge reaction and interest to this type of approach - I want to hear if this is useful and how/if it would be employed.
The goal of this system continues to be to make it as simple as possible to add functionality to an existing system through plugin layers that abstract pieces of a system that are subject to the most amount of changes. The same template that is installed by the Measurement Utility is used to define a new measurement strategy, which will use abstract hardware interfaces. Both new meausrements and new hardware devices are plugins that can be loaded by the framework at run-time. For more information please visit the Meausrement Utility download page or read: Designing a LabVIEW Measurement System with Multiple Layers of Abstraction.
This particular controller provides a very simple interface that is to be called from TestStand. Shown below are the VIs that would be called from test steps in LabVIEW (an example Test Sequence is included to showcase how).
Which in TestStand looks something like this (this is an included example):
Though the API appears to be synchronous (ie: 'Run Measurement' will block until a result is returned), it still uses a messaging scheme to send commands to and from a running background process (ie: the controller). Commands that must return data (such as 'Run Measurement') encapsulte an un-named queue into the message, wihch is sent to the controller. The controller handles that message by launching a measurement (or enqueueing it until the resources are available). When the measurement returns results to the controller, those are then retuned to this API using the unique queue reference.
This simple API is designed to make creating highly-parallel tests very simple (think parallel test steps in TestStand). The wire that flows between these mehtods is effectively a 'reference' to the running actor (to call it a 'pipe' would be more technically accurate). As a result, this wire can easily be branched to parallel test sequences that can dispatch run commands simultaneously. The Controller will receive all of these and dispatch measurements as quickly as the necessary resources are available. Unlike a reference, the data the actor acts upon (ie: available hardware and their settings) is safely encapsalted by the running actor, thereby mitigating the risk associated with delicate timing issues and deadlock that can occur if using a reference directly to data.
The screenshot below is of an included example that illustrates how this API can be used to parallelize message commands.
Installing required Software
Ensure LabVIEW 2015 and TestStand 2014 are installed