Teststand in a Production test enviroment: lots of similar assemblies

[jeffh12345]

Hi,

new to teststand,
finishing second development project in CVI / teststand / some Labview

Third program to be developed has 18 different flavors (this is small, we have one with 200 distinct top level part numbers!)
all are similar, but may have different downloaded firmware
some have unpopulated hardware, some additional hardware
I can manage this in teststand ok, but how to choose?

I am using vanilla Teststand 3.1, no changes to process model.
What is the best way to present this info to the production operator?

We have a high mix, medium volume production enviroment. Operator is semi skilled, PC is severly limited in capability.

The way we do it now:
Operator chooses executable that handles a family of product
Operator must choose and verify UUT part number displayed on screen matches with production documentation.
This means a list to select from.

At start of next test, the executable remembers the last part number selected,
and then says "part number xxxx selected, ok to continue, no to choose"

Operator does this for many boards, then unloads the executable

Based upon Teststand, how to do this?
Click .seq icon for family
CVI for menu, store remembered value in local?

A menu program in the process model to choose family sequence, never leave teststand?

Any suggestions? Any examples? What do you like?

[CharlieRodway]

Hi Jeffh,

I would be tempted to do the following:

* Have menu program called from the process model where the operator selects the product family.
* The main sequence lists all the family product sequences. Using pre-conditions, the main teststand sequence calls the correct family product sequence.

Are you currently using/intending to use the TestStand Operator Interface?

[jeffh12345]

Hi Charlie,
Ok with the process model change: figured that I needed to do it anyways, as I am also going to support a
START and ABORT buttons.
preconditions appear to be the way to go for the body of the test
I need to investigate how to do this.

I intending to use the TestStand Operator Interface, unless it is not sufficient for our use.



Since there will be different test fixtures, all with ID resistors,

Modify process model to check for fixture ID
Modify process model to support START and ABORT buttons
Modify each sequence to support menu for assemblies it can test
(one sequence per fixture)

How about:
Operator: Attach fixture
Hit START

Check fixture ID from process model
load correct sequence and start

Prompt for menu of assemblies that this fixture tests

run test code

end


unload board

load a new one

Hit Start again? repeat? Seem feasable?
Anyone have any suggestions?

[jeffh12345]

Hi Charlie,
Ok with the process model change: figured that I needed to do it anyways, as I am also going to support a
START and ABORT buttons.
preconditions appear to be the way to go for the body of the test
I need to investigate how to do this.

I intending to use the TestStand Operator Interface, unless it is not sufficient for our use.



Since there will be different test fixtures, all with ID resistors,

Modify process model to check for fixture ID
Modify process model to support START and ABORT buttons
Modify each sequence to support menu for assemblies it can test
(one sequence per fixture)

How about:
Operator: Attach fixture
Hit START

Check fixture ID from process model
load correct sequence and start

Prompt for menu of assemblies that this fixture tests

run test code

end


unload board

load a new one

Hit Start again? repeat? Seem feasable?
Anyone have any suggestions?

[CharlieRodway]

Hi Jeffh,

Yep, this seems quite feasible and is similar to test systems I've implemented.

[RayFarmer]

Hi,

I would try to avoid 'Abort' or use of the Abort API calls, as this would generate an unclean shutdown of your sequencefiles if you make use of the Cleanup groups of your sequence files.

All ways try to use the Terminate, as this ensures the Cleanup groups are invoked.

Regards
Ray Farmer

[CharlieRodway]

Hi Jeffh,

I agree with Ray - it's preferable to terminate rather than abort, to allow the cleanup to run.

Plus, if you abort the test you won't get a report!

[jeffh12345]

Ok,

abort is such a strong word:


STOP is what I am looking for

Stop the test where you are, and do a cleanup.


There is smoke coming from the UUT:

Hit the stop switch
Turn power supply off
🙂


Thanks guys!

Jeff