Scalable Teststand UI with DQMH

[PNHorn]

As a by-product of another project, I decided to create a Teststand UI which uses 2 DQMH modules, the first to manage the Teststand execution (TS_Manager) and the second is a cloneable module which shows the execution status of each thread within a parallel test sequence (TS_Display). This code may be useful for others looking to use DQMH (and I'd be keen for any thoughts on ways it could be improved) so I wanted to share it.

I have developed this code with Teststand 2014 32-bit and LabVIEW 2014 32-bit.

To run the code, download and install the attached VI Package. Open "DQMH TS Demo.lvproj" which should be located in "C:\Program Files (x86)\National Instruments\LabVIEW 2014\vi.lib\NI_PH\Teststand_DQMH_Example".

Navigate to, open and run "My Computer >> Libraries >> TS_Manager >> Test TS_Manager API.vi". Start the TS_Manager module by pressing Start Module. Before you can start a test execution, you need to select how many test sockets you want to run. This can be anywhere between 1 and 10. Set the numeric control to the required number and then press Start Application.

At this point you will get the Teststand login prompt unless you have set your copy of Teststand to automatically login with the Windows User as described in this knowledge base on ni.com.

http://digital.ni.com/public.nsf/allkb/4979F8FDB7ED698B8625712B000CFD14?OpenDocument

This should end up looking similar to the image below.

You can then press New Test Execution to start a new Single Pass run of the test sequence as shown below - you can repeat this as often as you like. Each time the new test execution is pressed, it checks to see if an execution is currently in progress and if it is, does not start a new execution until it is ready (this is tried for 5 seconds and then times out).

The current code is set to execute a customised version of the standard Computer Motherboard Test Sequence example that ships with Teststand. The only modifications to the standard sequence are:

• Force it to use the Parallel process model.
• Remove the pop-up dialog at the start of the sequence which selects which test to fail. Instead it randomly generates a pattern of pass fail results to use.

Hopefully that all makes sense and helps. Feel free to pass on any questions/feedback and I'll be happy to discuss further.

Cheers,

Pete

Edit 21st October 2016

I've been back and made some modifications to this now as recommended by Chris in the comments below. Version 1.0.0.3 of the package is now attached below.

Note this version and future versions will install to LabVIEW 2016\examples\NI_PH instead of vi.lib as described in the notes above.

To run this install the package then:

1. Open "TestStand UI in DQMH.lvproj" and then "Test TS Main API.vi" which is located in the Testers virtual folder.
2. Run the vi
3. Select "Start Module"
4. Select a number of test sockets (anything from 1 upwards should work until you run out of memory, although I haven't tested above around 20)
5. Select "Show Module Panel"
6. Select "Start TestStand". A number of test execution view windows should open (based on the number of test sockets selected) and you will be asked to login to TestStand.
7. On the "TS Main.lvlib:Main.vi" front panel, press the Entry Point 1 Button (which should now be displaying "Single Pass"
8. The test sequence should execute a number of different instances each displayed on a different instance of the execution view window (TS Display Module).

I hope that helps and makes sense to everyone.

Cheers,

Pete

Edit 1st November 2016

Couple of edits as discussed with Chris in the comments below. As well as updating the installation location (now noted in the steps from the 21st October) the vi tester now has a file path control to allow the user to browse for the correct sequence file as part of the test sequence.

Hope that all makes sense.

Cheers,

Pete

[PNHorn]

Just as an FYI, I've just installed and tested this on LabVIEW 2015 32-bit and it appears to be working fine.

[CRoebuck]

Peter,

Firstly sorry for the delay in getting back to you. What with, NI Week and then summer holiday this managed to slip off the radar for longer than I would have liked.

Many thanks for taking the time to look into DQMH and share this interesting use case with the wider community.  I certainly like the direction where you're taking this and have a few ideas how the concept could be expanded. I've often needed to spin up several (n) TestStand executions with arbitrary start points but have them be aware of the overall Termination / Abort status and be able to globally stop them all should I need to.

A couple of points / questions;

1. I noticed that the TestStand sequence requires 2014 SP1 (not 2014 as stated)

2. I am able to launch n test socket executions. When I stop the application and the calling module I get an error from the TestStand engine stating that several property object references have been left open. Am I doing something wrong or out of order perhaps ? Have you seen this behaviour ?

3. I'm interested in your thought process for creating the Application Stop user event, was this to be able to have either the calling module or callee module(s) stop the application ?

Chris

[PNHorn]

Hi Chris,

Great to hear you like the code and the concept - I've been using DQMH for building a few other modules which should hopefully be combined together with this for some pretty interesting content.

On your points, you're right about 2014 SP1 - my bad....

You were using it correctly, I'd forgotten about that error when I posted and hadn't had time to properly look into it. I've figured out now that the reference to the sequence file needed to be closed off after closing the Sequence File, and also the Application Manager Shutdown method needs to be called in a loop, as this takes some time to execute and needs to be out of memory by the time the main DQMH module shuts down. My Stop_TS_Application case now looks like this.

I'll rebuild the package and repost when I have a bit more time.

On the Application Stop user event (I haven't touched this for a few weeks so memory might not be 100% accurate) I was copying a lot of the functionality from the Simple UI Teststand shipped example and making modifications to scale it up. I was initially thinking of was to be able to dynamically start new test sockets up and shut them down, but didn't have time to fully implement this so it probably came from that. I'd be interested to hear thoughts on more efficient ways I could have written this though.

Cheers,

Pete

[CRoebuck]

Peter,

I know this is an old thread but I wanted to re-visit it for a number of reasons.

Firstly the DQMH 2.1 release earlier this year contains a number of improvements, among them an improvement in the mechanism used to report the stopping of a module to anyone who is registered to hear about such things. This is of particular importance in your example where the TS_Display.lvlib module has open references to child objects of the TestStand Engine (which is held open by the TS_Manager module)  and it must be ensured that they are closed BEFORE closing the parent object (if errors are to be avoided).

Another change is the use of a single initialisation state where registration for event callbacks should be performed rather than spreading it accross several states (more on this later)

In addition there were several cases in the MHL (Message Handling Loop) of the TS_Mananger.lvlib where additional states were being enqueued directly using the message queue functions instead of using a call to the modules' public API.

Unfortunately this technique means that the end user is unable to test any isolated function of the code using the API Tester. In addition there is no guarantee that additional states will not be enqueued from the EHL (Event Handling Loop) in between states being enqueued in the MHL, this could lead to unpredictable behaviour.

I suggest that a public API event "wrapper" is created for each atomic state so that it can be tested in isolation. This should include the functional code contained within the TestStand Callback VIs which should be replaced by an API method call and a specific state in the MHL loop allowing the callback functions to be tested (or interacted with during execution) by the API Tester (see below)

I think the proposaed scalable TestStand UI is a great idea and what you've posted has certainly given me a few ideas that I'd like to play with. The only drawback being the static binding of TestStand Executions to the TS_ExecutionViewManager controls meaning the maximum number of executions is finite.

Chris

[PNHorn]

Hi Chris,

Sounds like a good plan, I've had a bit of time this week to look into this and have had some thoughts on avoiding the issue with the finite number of TS_ExecutionViewManager controls - basically put one of them on the front panel of the display main vi and then pass the information needed to make each connection over from the manager to the display vi when they are launched.

I've put this together and it seems to be working partly, but still with some bugs (I had to try a few different methods to get to where I am now). I think it should work and is just some kind of timing/race condition issue I'm currently facing.

I'll post it up here once I have it working robustly.

Cheers,

Pete

[CRoebuck]

Peter,

Thanks for re-visiting this and incorporating some of the suggestions. This now gives a better demonstration of what I think was your original intention.

Can I request a couple of issues are addressed as visitors to this page may run into issues when following the instructions and might just give up and miss out on a useful demo.

First thing of note is that the package now installs into C:\Program Files (x86)\National Instruments\LabVIEW 2016\examples\NI_PH where previous versions installed into VI.lib

Can you edit the 21st October update in the original post to reflect this please?

In addition the path to the computer motherboard test is hard coded in one of the API tester cases, again, this could confuse.

What's your plans with this demo. Any scope for presenting this in future ? Given the complexity of the TestStand API when being used in this manner (callback registration can be a little tricky for users who are not familiar with this concept) I'm thinking it might be better covered in a user group code review ?

Chris

[PNHorn]

Hi Chris,

Good points about the hard coded path and installation directory. I'll try and correct these in the next couple of weeks.

Regarding presenting this to help users better understand how it works, I'm fine with presenting it or subjecting it to a code review through CSLUG or similar. If we video the session then the link to the video could be posted back here for the wider audience to also benefit from.

Cheers,

Pete