Best practice for using DQMH to trigger tests from the parallel process model in TestStand

[KarinaTaylor]

Hello DQMH and TestStand users!

We are working on a test system that uses the parallel process model in TestStand, but unlike in all the examples I've seen, the tests for each test socket need to be "triggered" from hardware rather than from the operator entering a serial number and pressing "go".

I'm not that experienced with TestStand, but I believe the best way to do this will be to override the PreUUT model callback in the main sequence with something that monitors our hardware input, correct?

Now, if our hardware monitoring software is a lovely, testable DQMH module (actually a cloneable module as we'll have 24 test sockets monitored by three serial ports), could we register for it's broadcast events in a VI in our PreUUT override sequence so we don't have to continuously poll the DQMH module? and then somehow notify our test socket to start testing on this broadcast event? Or, should we be doing this differently somehow, i.e. are we better to keep polling the DQMH module via a request event?

I'm just after some advice on how best to implement this DQMH hardware trigger in a parallel process mode. Any examples or experience would help greatly as we'd rather code it up right the first time!

Thank you!

[~jiggawax~]

You can certainly call a broadcast event from TestStand so you don't have to poll.  I did a presentation at NI Week last year that kinda shows how to do this.  I'm attaching it here.  Look at the broadcast section.

Essentially you'd need to make your broadcast VI cloneable and pass in the unique ID for each thread.

Questions I have for you:

Is the trigger that starts the sockets individual to each socket or does a single trigger start them all?  I'm assuming they each have their own since it is a parallel model.

Let me know if you have any specific questions. 

Hope this helps,

[KarinaTaylor]

Hi Sam,

That's awesome! thank you, I will study the presentation!

We will have three serial devices, each monitoring 8 separate digital lines in effect. Each digital line represents the status of the DUT connection where a change from F to T should trigger a start test for that DUT/socket. Any of the 3x8 DUTs can trigger a test at any time (hence parallel not batch). The state of the digital lines are just polled from the serial port, so we are planning on launching 3 instances of our serial monitor DQMH module (maybe from the PreUUT Loop callback?), which will poll the status of each DUT, and then generate a broadcast event if a DUT needs to start testing.

Let me know if you have any better ideas!

Thanks again for your help, will get back to you with any specific queries!

[~jiggawax~ · Accepted solution]

So I had a minute and threw together and example of what I think you want.  Attached is a zip with all of the files that you would need to test the example.  It was written in TestStand 2017 and LabVIEW 2017 both 32-bit.

Basically the broadcast for events would be your GUI that you could manage the sockets from and stop the testing. 

The PPL is the DQMH module I threw together that will trigger a "digital" line.  You basically tell the front panel which line to trigger and then click the button to trigger it. 

The sequence file of course is your client file and uses the out of the box parallel model... BTW...if you are changing the process model then you are doing it wrong and you need to immediately stop that nonsense... haha.  PM me with your justification and I'll be more than happy to tell you why you are wrong.

So I've overwritten a few callbacks:

ModelOptions to set the sockets and disable the default dialog

ProcessSetup kicks off the DQMH modules and the broadcast for events

ProcessCleanup closes the modules and tells the broadcast for events to stop

PreUUT monitors when one of the modules has triggered an event

And of course MainSequence is your test- I threw in a dialog to display the socket number so you could see the different sockets getting triggered.  Don't worry it has a timeout on it so it won't be a pain to click too much.

I've added a test API for the PPL- otherwise Fabiola would kill me.  You can call this from a tool menu in TestStand as well.

Let me know if you have any questions.

Hope this helps,

[~jiggawax~]

Forgot to mention that this example demonstrates just 2 digital lines per DQMH module... not 8 like you have.  I only wanted 6 UUTs not 24.  24 was too many to play around with.  You'll have to scale it to 24.

[KarinaTaylor]

Oh my goodness! you're amazing!!!! 

Do you know how long it would've taken me to get to this point playing with all these TS callbacks I don't yet understand!

Thank you! I'll take a look and get back to you with any queries - you've certainly set us on the right path. And I agree about changing the process models, but everyone seems to do it... if I find myself leaning in that direction i'll come back to you and ask why it's a terrible idea and what I should be doing instead 🙂

Thank you thank you thank you!

[~jiggawax~]

Not sure if you remember the days when everyone used to use stacked sequence structures in LabVIEW.... that's akin to everyone changing the process models in TestStand.... It works but is a knucklehead move and makes life harder down the road.

Feel free to ping me if you have any more questions.

Cheers,

[KarinaTaylor]

Haha! Unfortunately I do remember.... in the days of LabVIEW 6 when I was just a wee student 🙂

Your example works a treat! Now to start developing and plugging all my bits and pieces together!

Thanks again for the advice, we're definitely off and running now - with callbacks, no process model changes! (I'm quite relieved about that to be honest!)

[KarinaTaylor]

OK, we have our 24 test sockets being fired nicely from our 3x8 inputs via DQMH broadcast events, using callbacks in our main sequence which is working great thank you! 

In order to keep our main test code modular and readable, we planned to use a very simple main sequence (actually created from csv via a custom translator), that calls a sequence file full of available "Test Method" sequences. As such, I'd like to move these callbacks out of the main sequence file.... Now since we should never change the process model, my idea was to use the TestStand Public\Components\Callbacks\Station\StationCallbacks.seq to hold the PreUUT, ModelOptions, ProcessSetup and BroadcastEventCatcher etc.. I got this to work kind of, in that the 24 test sockets load up, however they don't "fire" from the DQMH modules any more... I assume the sequence context or something is incorrect given that it's not coming from the same sequence any more?

Any tips?

Thanks 🙂

[KarinaTaylor]

Never mind, it works today - maybe too much coffee the other day!