First, using LabVIEW 2011 and TestStand 2010 SP1.
We have a custum GUI setup to use the sequential model. At the heart of it, when we hit start, it accesses the Single Pass entry point and runs it with some modifications we've made. Now, we'd like to have a setup that can test multiple DUTs and use the Parallel Process Model. I'd like to have our GUI basically perform the same functions as the built in popup when running the TestUUTs entry point. I've seen the PreUUT callback where you can disable the built in popup. But what I can't seem to figure out is how to initiate a test socket test because it doesn't seem to line up with an entry point necessarily.
When they push the start button next to DUT 0, I want to start socket 0. And if they hit the start button next to DUT 1, I want to start socket 1. What entry point does the GUI use to make this happen? Does the GUI need to start an entry point (IE Test UUTs) then send more information later to start a test? if so, where does TestStand wait for that information within the parallel process model?
Hello Sir Mutt,
Test UUTs Execution entry point is the entry point that starts the UUT dialog box. If you compare the differences between the Single Pass entry point and the Test UUTs entry point, you won't see the Start UUT Info Dialog step in Single Pass. Here are the steps you should be interested in to see where the test sockets are initialized:
If you insert a few breakpoints in these steps, you will see what data is being passed. Here is a link that explains the TestStand Process Models.
Thanks Jeff. That's good info. I can follow where the individual sockets get created (although I'm not sure how they're used after that) and I've been looking through the example OverrideSerialNumForParallelModel.seq.
We have a GUI that would be pretty similar to the built in dialog with a table for 4 different UUTs to put in their serial number and hit OK to run that socket. I assume the GUI would have already started the Test UUTs entry point with the appropriate number of sockets (that part I can handle). But, what does the GUI need to do when someone hits the start button for a particular socket? Our current sequential model tests just use the Single Pass Entry Point to run the test. But since we're somewhere in the Test UUTs for the parallel model, I'm not clear where we are waiting within the model and what the GUI needs to send to get the socket to start testing.
Hello Sir Mutt,
The GUI will want to process user events in the Process Dialog Requests step:
This loop basically handles the timeouts and also calls your sequence file steps:
As a bonus, we provide the source code for the modelsupport2.dll which is the dialog that is running in the Parallel Process Model (C:\Program Files\National Instruments\TestStand XXXX\Components\Models\TestStandModels\). You can use this to see how things are being handled, one of which is getting ModelData.
Jeff - I've certainly beginning to see the light. I can use the example (OverrideSerialNumForParallelModel.seq) and see how things are running fine. But, I basically need the same functionality as the built in dialog, but with some added info. I am not a C programmer. So, while I can work through some portions of the provided code, I don't see much hope in getting what I need out of it. I'd be tempted to just use the built in dialog but we have some user interface requirements that won't allow it. Is there a similar dialog in LabVIEW anywhere? I need most of what is in that user dialog but some status updates (beyond just "running") and some presentation changes to match the rest of our GUI.
I see how to do the multiple popup in the example, but I need a single popup dialog to run all UUT (like the built in one). How does the dialog with all the UUTs in one dialog interact with the process model to get things going properly and get status?
One way you could do it is as follows:
Still override PreUUT like in the example and add code which posts a UIMessage synchronously to the UI and then waits for a persocket notification (e.g. you can use the socket index as part of the name to make a per socket notification). Then in your UI, handle the UIMessageEvent on the ApplicationMgr. When you get the UIMessage from your PreUUT you will know it's ready and you can then update your UI to enable the start button, and when the user presses it, you can then Set() the notification to tell the testsocket thread to continue.
for example, in preuut:
Create Notification "MyUIStartNotification Socket 1"
Thread.PostUIMessage(UIMsg_UserMessageBase + 1, RunState.TestSockets.MyIndex, "MyUIStartNotific
Wait on Notification "MyUIStartNotification Socket 1"
In your UI
Handle UIMsg_UserMessageBase + 1
Enable Start Button
When start button pushed, Set Notification that corresponds to that socket. Pass any data needed with the notification, for example, create a container that contains a serialnumber property and a continuetesting property and pass that with the Set operation. In your PreUUT code get that data from the notification and update your parameters.
Not simple, but doable.