Architecture Question

[UnspecifiedError]

Hello All,

I am in the process of designing an Test System and would like to have some input from the experts here.

We have a proposed Operator interface where the operator selects a unit under test and its corresponding test sequence is loaded from a database. The operator should then be presented with the following options (these options could change) to run.

production (this would also include some flash programming subsequences) - Fixed number of tests, operator cannot change the test selection

repair - initial (where the units flash is read and saved to analyses any fault codes) - Fixed number of tests, operator cannot change the test selection

repair - intermediate (where the operator can chose a particular test/s to run - Operator is allowed to chose the tests

repair - final (final test before the unit is sent back to the customer) - Fixed number of tests, operator cannot change the test selection

This is the same across many UUT's and I would like to standardise this without hardcoding the OPTIONS in to my Operator Interface. As the options above can change.

My thoughts were as follows:

1. Modify process model to add extra Execution Entry Points, but this seems ugly to me and is not very flexible.

2. Overriding the MAIN SEQUENCE by passing corresponding subsequence names to the Process model using Parameters.Sequence

3. Have these options as sequence call steps in the MainSequence and each of these are acually calls to subsequences which lists the tests in the sequence.

What would be nice is to read the OPTIONS from the selected sequence file and to display it on the Operator Interface and then based on operator selection execute a corresponding subsequence. We are not allowed to have multiple sequences for the same UUT unfortunately.

[Daniel-E]

Hey UnspecifiedError,

Why not handle this task with a simple VI or code module called from your execution entry point, perhaps in the PreUUT callback when the UUT information dialog is displayed? You could access the names of the sequences in your client sequence file at RunState.ProcessModelClient.Data.Seq, and use that to populate a list of choices for the operator. Once they choose one of these options, you could pass that out of the code module and use it to set a variable in the client sequence file to choose which subsequence will be selected.

This has the advantage of letting the options be defined in the client sequence file, so they can be different for each unique type of UUT you might test. However, the common code of choosing an option is located in the process model so it doesn't have to be added into each client sequence file individually. Finally, by handling this within the process model instead of in a user interface, the code will work the same way if you need to run it from the Sequence Editor or a different user interface in the future.

[~jiggawax~ · Accepted solution]

Personally I'd go with option 3.  So basically you have your base sequence file.  We'll call that BaseSF.seq.  Then you will have UUT Sequence Files.  UUTA.seq, UUTB.seq,etc...  Let's call your different options test selections (productions, repair-init, etc...).  

Basically in each UUT sequence file I would have rule that each test selection is its own sequence.  But you have to have a rule that each sequence is named with Test Selection in the name.  For instance:  

• UUTA.seq contains 4 sequences-
  Production Test Selection
  Repair-Initial Test Selection
  Repair-Intermediate Test Selection
  Repair-Final Test Selection
• UUTB.seq contains 3 sequences-
  Production Test Selection
  Pre-Production Test Selection
  Repair Test Selection

The point of this is that in your PreUUT callback you can determine which file to call based on a lookup table.  So the operator scans in the UUT number and then you can look up which UUT sequence file to call.  Then in the Setup of the MainSequence in your BaseSF.seq you can have a dialog that will use the TestStand API to see what options are in the file.  It can then display those to the user.  Hence why you need Test Selection in the name of the sequence.  To distinguish between other sequences and the ones that you want the operator to see.

I have created a simple example for this.  I threw it together quickly so don't pick too much at the mistakes.  Let me know if you have any questions.

Hope this helps,

[~jiggawax~]

Just saw your post Daniel. I guess I was off writing the example while you were replying.  🙂

[UnspecifiedError]

Thanks very much for the replies guys, much appreciated.