Best practice for using hardware input to start tests from the parallel process model in TestStand

[KarinaTaylor]

Hello 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 driver is a LabVIEW VI (actually three instances of a cloneable DQMH module as we'll have 24 test sockets monitored by three serial ports), could we communicate with that driver from a VI in our PreUUT override sequence, and then somehow notify our test socket to start testing based on a certain message from the hardware driver?

I'm just after some advice on how best to implement this 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!

(I've also posted this question on the DQMH forum here: https://forums.ni.com/t5/Delacor-Toolkits-Discussions/Best-practice-for-using-DQMH-to-trigger-tests-..., I didn't know which forum was most suited!)

[mateusz_owczarek]

Yes, implementing it in PreUUT would be probably the best idea.

How does your driver work? Is a process running in the background or rather a send&receive VI query that returns the answer immediately? 

You may use just a simple VI that would return a boolean value to let the test start (or not) or maybe use TestStand notifiers (https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000kI6sSAE&l=pl-PL). There are also other options, I guess it depends on your application and driver architecture. 

[KarinaTaylor]

Hi Mateusz,

Thank you!

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 a 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. Or maybe we just in turn poll the serial monitor driver for a specific DUTs status in PreUUT... In either case, it looks like the VI that we call from the PreUUT sequence can output a boolean or notifier to TestStand to start the test. 

Let me know if you have any better ideas!

Thanks again for your help

[mateusz_owczarek · Accepted solution]

Hi Karina,

Yes, it sounds good. Sure, you can launch your DQMH modules in PreUUT Loop.

If I were you, I would probably use TestStand Notification (https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000kI6sSAE&l=pl-PL), though I don't like how complex it is on the VI side. Advantage is that you don't need to create any other VI. In PreUUT you just need to use Notification steps from TestStand palette.

Also, you may want to get familiar with Parameters.ContinueTesting variable in PreUUT. You need to set its value to True to enable the test socket to start.

Of course, as you probably know very well, there are usually multiple choices and many of them are good, it depends on you which approach you prefer and would be better for your application 🙂

[KarinaTaylor]

Thanks Mateusz,

Sounds like an excellent approach, yep the LabVIEW code is a bit complex for the notification but I shall learn all about it, then hide it away in a vi 🙂

Thanks!