Skipping TestSockets in Batch model process.

[kevmi2ca]

Teststand 3.1

Labview 7.1.1

My application uses various vi's to prompt the user for DUT part numbers. ModelOptions.NumTestsockets is determined by number of part numbers. Naturally, Teststand activates test windows in numerical order for each part number.

What I want to do is skip testsockets. For instance, the user will be able to use 'blank part numbers' for the testsockets he wants to skip. I already have the vi to recognize blank part numbers - what I need is a way for TestStand to recognize this 'blank' and increment the testsocket accordingly.

Hope I explained this well enough...

I need to do this because the rest of my code uses the Testsocket Index for a lot of other dynamic functions and it must always match the DUT order.

I.E., testsocket #2 is always DUT #2.

Thanks

[Patrick_P.]

Hi kevmi2ca,

I guess I am still a little confused as to how this works. You are prompting the user at the very beginning of the test to enter in the DUT serial #, and this is determining the ModelOptions.NumTestSockets? Then what you are wanting is to have TestStand recognize the blank part numbers, and not count that in the ModelOptions.NumTestSockets?

Unless I'm misunderstanding, the number of test sockets is initialized right as the batch process model starts.  This doesn't change.  You can disable certain test sockets so that they do not run, but they will still be present.  You should be able to programmatically disable these test sockets which would essentially skip them for that run. The property that determines whether they are disabled or not is Locals.ModelData.TestSockets[x].Disabled, and this needs to be set before the step "Add TestSocket Threads to Batch" in the process model. I think this might give you the behavior you are looking for. Hope this helps!

[kevmi2ca]

I am not asking Teststand to recognize the "Blank Part Numbers"; this is done is Labview. The same vi would also recognize "Real Part Numbers" and use that to determine the number of active Test Sockets.

All I want Teststand to do is allow me to control which TestSockets get activated. For instance: The are 6 active Testsockets, but they are all odd numbers 1, 3, 5, 7, etc. (These socket numbers are used in my application to power up specific DUTS)

That being said, I think your suggestion of  "Locals.ModelData.TestSockets[x].Disabled" will also work. I can simply Disable any TestSocket that contains a Blank Part Number. I should be a ble to add a Sequence Context Property in my vi here.

Please let me know what you think.

Thanks for the help Pat.

[Patrick_P.]

Hey Kevmi2ca,

My recommendation would be to go with disabling test sockets. I have talked to other customers that used a similar solution.  I definitely think this is the easiest way because it requires very little customization of the process model. Have a good one!

[kevmi2ca]

Well good news Patrick. I got everything working, now I just need to figure out how to close the "disabled" testsockets.

You see, my application closes the acitve sockets in its cleanup section using "RunState.TestSockets.MyIndex; it then exits the Batch Process (cleanup portion of Batch process does run - only if Terminate button is pressed, I think).

I need a way to tell the Batch Process to close those disabled testsockets. I'll be working it today if you have any ideas.

Thanks again for the help.

[James M]

Hi kevmi2ca,

What do you mean by close the "disabled" test sockets? They are disabled from the beginning so there is nothing to close - are you seeing different behavior?

Regards,

[kevmi2ca]

Hi James,

Yes, I'm seeing something different. Once my test runs are complete, the active TestSockets are closed within the Batch Process Loop; however, the disabled Testsockets continue running and eventually hang the program because the app is "waiting" for those testsockets. The only way I've figured out to close these Disabled Sockets is to programmaticly terminate them. (I don't like this, though, as it doesn't allow the rest of my cleanup to execute correctly.

Hope this makes sense. i can send screen shots if needed.

[SteveSmith]

Don't know if this will help but I'm doing something similar in my application. I'm using TestStand 4.0 and I have 17 test slots that can be populated in any order.  I use a PreBatch callback in my client sequence to set TestSockets[ ].Disabled using a loop in a statement and an array that is generated by my user interface.

Parameters.ModelData.TestSockets[RunState.LoopIndex].Disabled = FileGlobals.SlotActiveArray[RunState.LoopIndex ]

The disabled test sockets don't run at all in my application.

[James M]

Hi kevmi2ca,

After looking into the issue further, I found that you must disable the test sockets before they are initialized. If you wait until after this (as in your case), the process model will end up waiting for them to send their terminate signals. This, of course, never happens since they are disabled from your point of view, and the resulting behavior is: TestStand hangs. In order to avoid this, you should disable the sockets ahead of time as Steve has described (in the PreBatch callback). Do not try to do it in PreUUT since the sockets will have already been initialized by this point. In other words, you will either need to modify the process model or override the PreBatch callback.

Regards,

[kevmi2ca]

Hey guys,

Well I still can't get this to work.

I have this statement immediatley following the "Get Model Option" sequence in my Batch Process.

Locals.Local[RunState.LoopIndex]==true?(Locals.ModelData.TestSockets[RunState.LoopIndex].Disabled=true): (Locals.ModelData.TestSockets[RunState.LoopIndex].Disabled=false)

Locals.Local is my array of Booleans indicating whether the Testsocket should activate or not.

Appreciate the help!

Message Edited by kevmi2ca on 09-17-2007 10:55 AM

Message Edited by kevmi2ca on 09-17-2007 10:55 AM

Message Edited by kevmi2ca on 09-17-2007 10:56 AM