Do I need custom Model?

[j_osh_o]

I am a TestStand beginner working on a 10-year-old test system for discrete power transistors.  These parts are very simple and are tested one at a time by an operator.  Ten years ago, another engineer built a system using TestStand and several instruments connected by GPIB.  Now the software needs to be rewritten since the old system is not compliant with test software version control requirements.  The original designer made a complete custom Model file, and modified the snacmodelsupport2.dll with LabWindows CVI.

I am under cost and time constraints to finish this upgrade, and it appears to be a very large learning curve to understand this custom Model.  I do not want to reinvent the wheel, but it seems to me that the stock sequential model is fine for this project.  What is the rule of thumb as to when a custom model file is requred?

[~jiggawax~]

In my opinion you should try to avoid customizing the Process Model.  It makes it easier to maintain.  It's even worse when you "need" to change modelsupport2.dll.  UGH!!

The current sequential model has a whole bunch of callbacks which make it really easy to get desired behavior from your client sequence file.

Here's what I use for my rule of thumb for customizing the Process Model:

- Will this modification be useful to multiple projects?

- Does this modification make it easier all around in the long run. (i.e. less support, less maintenance, less work when creating new tests, etc..)

- Is my modification strong linked to 1 client sequence file?  A process model should be something that can handle pretty much any sequence file.  If you customize it such that it's linked to a single sequence file then you are probably doing something wrong.

- Does this modification make sense?  In all reality what am I truly gaining by this modification?

A couple instances when I've changed the process model:

- Configuration Entry Sequences to change settings for a test.  This just had a simple callback in it that I always overrode with my client sequence.  It just put a menu item in the user interface so users could get to it.

- A callback/Configuration Entry which allowed users to link to a document describing what the test did.  Again overridden by my test.  Just used for the menu item.

- Disabling/Deleting an entry point.  Test UUTs and Single Pass are the default for the sequential model.  I only wanted users to select one.

Sounds like a crazy project.  I hope it goes well for you.

Cheers,

[RayFarmer]

Hi,

The easiest way to find out if you need a custom process model is to try to run your test sequence in the default process model. You will have to disable your Test Sequence from using the custom process model and you can do that in either the SequenceFile properties or the Station Properties depending on where this has been configured.

[j_osh_o]

I have more information which maybe explains why the previous engineer used a custom model.  This test requires several very different sequences, like calibration, repetitive standards test, and normal production test.  What was done was to create a very complicated custom model file with an execution entry point for each type of flow.  The strategy of the previous engineer was to cram all the information for all the different sequences into a single sequence file.  Then the type of test was selected by selecting the execution entry point.  Is this the standard way to use TestStand?

I would like to get the same functionality using the standard Sequential process model.  In a perfect world, I would create a GUI for the operator that would first query the test type (Cal, standards, production, etc.) and product.  Then somehow testand would automatically choose the correct sequence file, and select the appropriate exection entry point in the process model.  Is this possible?  Is the custom model approach better?

[~jiggawax~]

What version of TestStand are you using?  I have several ideas for how you can accomplish what you want.  One involves changing the process model.  The other doesn't.

The beauty of TestStand is that it's very customizable and you can generally find multiple solutions for a problem.  The problem with TestStand is that it's very customizable and you can generally find multiple solutions for a problem.  Basically what makes one solution work will shoot someone else in the foot.

Idea 1-  Customize the process model (in this case it would be OK) with Configuration entry point to do the calibration.  Have a callback in there that you override from you sequence file.  The Configuration entry point automatically puts a menu item in both the UI and the Seq. Editor under the Configure dropdown.  In fact if you open the Sequence Editor and open a sequence file then go to Configure.  You will see, at the bottom, 3 options (Report, Database, Model).  Those are Configuration entry points in the process model.  If you open the model you will see them.  This is great for things like calibration, configuration settings (obtaining and storing instrument addresses), etc...

Idea 2-  Add a Process Setup callback to your sequence file.  In there have a call to your code module which will allow the user to select which type of execution they want.  Save that to a FileGlobal.  Then in your MainSequence have calls to different sequences (each with the correct routine).  Only call the sequence that you want using the preconditions.

I can throw together some demos if you want but I need to know which version of TS you are currently using.

Cheers,

[j_osh_o]

I will be using TestStand 2010 and LabVIEW.  The old system I am replacing used an old TestStand version from 2001 and LabWindows CVI.  I am not very fond of the way the existing program was built with multiple entry points.  The model file becomes extremely complex and cluttered.  For example are pre-UUT and post-UUT callbacks for each flavor of test.  There are now five different entry points, and due to the 5x multiplication there are over a hundred callbacks.  It would be so much simpler if the UI could load a custom sequence and specify a standard entry point.  If you have to load a sequence file before the UI will start up, then I guess this is not possible.

[j_osh_o]

Maybe another option would be to use a very stripped down model file or even no model file at all.  What exactly does the model file provide besides asking for the UUT number and logging the result?  I could just make the MainSequence file a case structure that selects the test type, and each test type would have its own sub-sequence with all of the stepping, looping, logging, etc.

[~jiggawax~ · Accepted solution]

Idea 2.  This is exactly what you are suggesting.

Let me know what you think.

[j_osh_o]

Very nice, I think this is the kind of solution I am looking for.  Thanks for your help!