Disabling Test Sockets in SinglePass.

[JVL]

I am new to TestStand and LabWindows and am trying to figure out how to pass serial number and socket status to a sequence file from a LabWindows application. I have an application that successfully opens a sequence file and executes it via the TestStand API. I can probably figure out a way to pass serial numbers and socket status via the Parameters.ModelData.TestSockets[x] sub property. The problem is that it appears that SinglePass is waiting for all the test sockets to complete whether they are enabled or not. It seems to never get out of the step "Wait For TestSockets" under the SinglePass entry point.

Is there an easy way to do this? I really don't want to use the TestUUT's entry point. Should I just customize the SinglePass entry point with logic in the "Wait For TestSockets"  loop or is there a much easier way to do this?

Thanks,
John

[Jesse_O]

Hello John,

To answer your first question, generally to pass information back and forth between an operator interface and a sequence you should have your sequence post a UIMessage, and your operator interface reads the message and responds.  If you look at the PostUIMessage help you see the following definition:

Thread.PostUIMessageEx ( eventCode, numericDataParam, stringDataParam, activeXDataParam, synchronous)

You can pass data with the message, and since the activeXDataParam is passed by reference you can update the value and use it in your sequence file.  This is how you could send a serial number between the Operator interface and the sequence file.

Next, you mention that you are having problems with test sockets waiting for disabled test sockets.  I think this is probably due to how the disabled flag is being set.  We have been able to disable a test socket if the user does not type in a serial number (in the batch process), by modifying the batchuutdlg.c in the modelsupport2.prj.  We first declared a variable static char string[200]; and in the goCallback we added the following instead of the statement at line 932.

GetCtrlVal(childPanel, panelData->testSocketDataArray[i].ctrls[kTSCtrl_SerialNum], string);
if (!strcmp(string, ""))
            tsErrChkMsgPopup( TS_PropertySetValBoolean (panelData->testSocketDataArray[i].testSocket, &errorInfo, TEST_SOCKET_DISABLED, 0, (VBOOL)(VTRUE)));

I hope you find this example helpful.

Regards,

Jesse O
Applications Engineering
National Instruments

[JVL]

Hello Jesse.
Thanks for your response. I have successfully added a UI Message callback to my application and have passed an array in via a sequence step that posts the message. I still have a few questions.

1. Within the ActiveX framework, what is the best way to add a string to an array of strings? I am concerned with pointer lifetimes, etc. I retrieved the data with CA_VariantGet1DArray after doing all the conversions to handles, variants, etc. I retrived the data using the type CAVT_CSTRING. Is the string array just an array of pointers? If so, then I will have to account for this when I add a new element and make sure that the memory being pointed to is not freed.

2. What is the best place to get this serial number information from the UI? I am thinking that it probably has to happen early in the Batch.seq file under the SinglePass entry point. Right after "Resize TestSockets Arrays" step?

3. Should I create another step after that to set the TestSockets arrays by calling a simple function in the model2support .dll that does what the GO callback does in the TestUuts dialog? I will have to add this function and create a slightly modified dll as a result.

I appreciate any insight that you might have. I am still early on the learning curve.
John

[JVL]

Jesse,
I am still having some problems trying to disable a test socket. You mentioned the Go callback which is associated with the Batch Dialog panel. This dialog is opened when the "Test UUTs" entry point is used. When I try to do something similar using the "SinglePass" entry point, the sequence editor gets stuck at "WaitForTestSockets". What I did was insert a step right in the SinglePass entry point of Batch.seq. The step was immediately after the TestSocket array was resized. This added step called a new function that I placed in modelsupport2.dll. For testing, I only disabled a single socket. The execution takes off but it hangs at "Wait For Test Sockets". If I terminate, I get a batch report that indicates that the socket that I disabled was truly disabled and the rest were tested. How does the SinglePass differ from Test UUTs as far as the process model goes? Are there differences that can explain why I'm getting the behavior that I am seeing?
Thanks,
John

[Jesse_O]

John,

To answer your first question, the string array should be an array of pointers. 

Before I start on the rest of your questions I would recommend that you try to modify the Test UUT sequence instead of the single pass.  The Test UUT sequence performs a number of other steps that you are probably missing from your modified single pass.  I would expect the reason why the execution is stuck at the "Wait For Test Sockets" step is because you have not removed the disabled UUTs from your batch.  The Test UUT sequence removes disabled sockets from the batch with the step called 'Remove Disabled/Readd Reenabled TestSocket Threads from/to Batch'.

Regards,

Jesse O.
Applications Engineering
National Instruments

[JVL]

Jesse,
After digging into the process models and entry points, I came to the same conclusion. I have successfully implemented what I wanted to do with the Test Uuts entry point. I was able to do this with very little modification to the BatchModel.seq file. The only thing that I had to change was to change the run mode on the Wait for Dialog to "skip". I overloaded the PreBatch and PostBatch callbacks in my sequence file. The PostBatch is just empty causing no action to take place. I implemented some simple logic in PreBatch to only run once using a boolean variable. On the first time through PreBatch, I set the flag, generate a UI Message to get serial number information from my OI application and continue through the batch loop. The next time through PreBatch, I simply set the "Parameters.ContinueTesting" variable to false to cause the batch loop to terminate. As part of the UI message, I pass the current context from which I can get access to the TestSockets array so I can set the serial number and disable flags right in my OI application. I use a synchronous call to block the calling thread until the OI picks up the message and stuffs the TestSocket array properties.

On first pass, this seems fine. I'm wondering if it is the best approach. The Test UUTs dialog panel is still being loaded but is hidden and never gets any update events due to the changes in my sequence files.  As a result, it stays hidden and out of the way. My only concern is any resources that may be consumed by the panel, etc. I didn't want to dig any further into modelsupport2 or the process model to figure this out right now.

Is my approach good or are there some inherent flaws in it?
Thanks again,
John

[Jesse_O]

John,

I am glad that you have gotten your setup working.  I do not see anything wrong with your approach.  The dll calls originally in the postbatch callback do not exit the panel.  If you look at the code in this stop callback, the panel is hidden since the sequence uses this dll file later on in the sequence.  The last call of the TestUTT sequence is "Exit Batch Info Dialog".  This is the step that closes the panel.

Regards,

Jesse O.
Applications Engineering
National Instruments