Jump to content

Design of (TS + LV + SQL inputs)


SebastienM

Recommended Posts

Hi,
 
I have a big project to manage which includes :
-TestStand + LabVIEW
-SQL Database for test inputs (UUT characteristics, sequences parameters,...)
-HTML Reports

-almost 10000 different part numbers (that's THE point) with common characteristics (almost 3000 families) + specific characteristics

 
Everything has to be imaginated.
The SQL inputs tables have to be created.
The number of sequences to code has to be reduced to the minimum because, of course, it's impossible to code 8000 sequences differents files...
The final solution must be as simple as possible.
 
Possible ways of reflexion :
-XML and Xpath for families and their children
-Intermediate LabVIEW OOP layer for families and their children
-Dynamically created sequences + variables (TS scripting)
-Dynamically created sequences (concatenating a bunch of generic sequences to build a specific sequence)
 
There is a lot of documentation about TestStand and SQL, but only for results (outputs), not really about inputs.
 
Does anybody manage this kind of project ? In which way ?
What would be your advices ?
 
Thanks,
 
Sébastien

CLA

Link to comment

I have a product line with a few dozen part numbers with common & unique tests based on product family and it sounds similar to your situation, although at a much smaller scale.  I use a product from an NI Alliance Partner called dTRAK (http://g2tek.com/dcp/i/products-dtrak). 

 

My first thought while reading your post was to ask how much experience you have, then I saw the "CLA" in your signature.  It's worth giving them a call, anyway, as they've already done a lot of the heavy lifting.  Good luck.

Link to comment

Hi,

 

Thanks for your answers.

 

To jcarmody :

I took a look to dTrak. I understand (but maybe I'm wrong) that it's a tool for managing Results, not for managing Inputs, just like skywats (http://www.skywats.com/).

My concern is about inputs.

(yes I'm a CLA :cool: )

 

To JKSH :

Yes, you're right about the property loader, but my questions is much more larger than that.

Especially, my main problem is to find a way to code the less possible number of sequences, by finding a smart trick, possibly like the ones I listed above.

 

Regards,

 

Sébastien

Edited by Callahan69
Link to comment

Generally, I'd approach this by having a top level sequence with sub sequences that define the high level tests. Then use pre conditions on tests & sub sequences to decide whether or not is should run. This let's you create generic top level sequences that execute specific tests for products at run time.

I'd push all of the model / part number identification code into the sequence model ( by creating a custom model) and maybe even put Pre Step actions in there to do checks before each test step.

My starting point would be to map out the tests required and look for commonality of tests. That would tell me what my sub sequences should be.

Have a look at the Test Stand advanced architectures PDFs & Test Stand 2 training course - that's good for custom sequences & architectures.

Link to comment

Yes, you're right about the property loader, but my questions is much more larger than that.

Especially, my main problem is to find a way to code the less possible number of sequences, by finding a smart trick, possibly like the ones I listed above.

 

If you are looking for a "Design My System" button. There is none. You have to design it. Welcome to the world of Systems Engineering.

 

If you have a definite specification or a question about a technology then we can assist. However, we cannot design it for you-that's your job. Getting data into and out of test stand is either a training course or reading the documents. Same goes for SQL and LabVIEW (although JKSH has told you a very easy way as long as its not a MySQL database).

 

If you are looking for an "in". I.e the issue is "where do I start". I would suggest reading up on SQL, download a few examples and decide what data and therefore what queries you will need to do each test in the specification. There are no short cuts here, I'm afraid. It is application specific. Once you have done that, it then becomes more obvious how difficult the tests will be to execute in each environment. Do this, do that, read result very easy in Test Stand. Increase until X, wait until Y stabilises then check Z much harder and probably better in LabVIEW.A lot will depend on your own preferences and your or your teams abilities' as to how much you do in Test Stand and how much in LabVIEW or if one will suffice for everything.

Link to comment

I will take a look to TS2 (as I'm a LV teacher, I also got all the stuff for TestStand... such a bad boy...) and process model customisation.

ShaunR, sorry for bothering you, maybe my question was too much "architectural" ... hum, you really are a nasty demon :P 

Just kidding, thank you both for your help and advices.

  • Like 1
Link to comment

To jcarmody :

I took a look to dTrak. I understand (but maybe I'm wrong) that it's a tool for managing Results, not for managing Inputs, just like skywats (http://www.skywats.com/).

My concern is about inputs.

(yes I'm a CLA :cool: )

 

My system begins when an operator scans a barcode containing a part and serial number.  The part number tells the system which sequence steps to execute and the limits for each test in those steps.  Results are stored and retrievable within the system, too.

 

It sounds like G2's web page doesn't do dTRAK justice.

Link to comment

jcarmody,

Where do you store the information about  "which sequence steps to execute and the limits for each test" ? File or database ?

Where is implemented the logical which decide which sequence steps to execute ?

Did you modify the process model ?

Did you customize and use the AditionnalData structure available in the UUT structure ?

Is dTRACK able to manage inputs in some way ?

Thanks,

Link to comment

jcarmody,

Where do you store the information about  "which sequence steps to execute and the limits for each test" ? File or database ?  It's all in the database (SQL Server)

Where is implemented the logical which decide which sequence steps to execute ? dTRAK does this in TestStand

Did you modify the process model ? I think they did.

Did you customize and use the AditionnalData structure available in the UUT structure ? I don't know.

Is dTRACK able to manage inputs in some way ? What do you mean?  It manages the test limits and which tests to run.

Thanks,

 

I have a few product families and one test sequence for all of them.  Not every step (subsequence) in the main sequence is executed for each family, and steps can have different test limits depending upon family/part number.  dTRAK manages all of this for me, I just have to configure all of this in dTRAK (it has a web interface for this).  If I had thousands of parts, I'd ask G2 to write a custom program to automate the configuration.

Link to comment

jcarmody,

Where do you store the information about  "which sequence steps to execute and the limits for each test" ? File or database ?

Where is implemented the logical which decide which sequence steps to execute ?

Did you modify the process model ?

Did you customize and use the AditionnalData structure available in the UUT structure ?

Is dTRACK able to manage inputs in some way ?

Thanks,

 

All implementation questions  :rolleyes:

Once you have figured out how to query a database and populate the station/sequence variables with the results (manage your inputs as you put it), the rest will be down to your specific design and preferences. :book:

Edited by ShaunR
Link to comment
  • 2 weeks later...

Hi all,

It's been a while !

I'm finally available to think serioulsly about this wonderfull subject.

Thanks to you here is where I am :
  • I have to do SQL queries based on the current UUT for :
    • UUT characteristics
    • Test plan (which sequences to run)
    • Sequences parameters
    • Steps limits
  • I can make this queries in different ways :
    • with property loaders
    • with SQL step types available in TestStand
    • with LabVIEW and database connectivity toolkit
  • I can make these queries in different locations :
    • somewhere in a customized process model
    • in the PreUUT callback
    • in a main test sequence
    • in each test sub-sequence
  • I can store the results of these queries in different locations :
    • in the UUT.AditionnalData structure (local variable) of the process model
    • in station globals
    • in locales variables
  • I can split the sequences in this way :
    • having a top level sequence with sub sequences that define the high level tests
    • use pre-conditions on tests & sub sequences to decide whether or not it should run
  • I'm questionning about :
    • insert some Object Oriented layer somewhere, since it's possible to easilly do dynamic dispatch in TS
    • using xml and xpath queries (I heard a little about that)

Well, what would be your choices between these points ?

Link to comment
  • I have to do SQL queries based on the current UUT for :
    • UUT characteristics
    • Test plan (which sequences to run)
    • Sequences parameters
    • Steps limits
    • test dependent hardware to use
  • I can make this queries in different ways :
    • with property loaders
    • with SQL step types available in TestStand
    • with LabVIEW and database connectivity toolkit
  • I can make these queries in different locations :
    • somewhere in a customized process model
    • in the PreUUT callback
    • in a main test sequence
    • in each test sub-sequence
    • All of the above-scope dependent.
  • I can store the results of these queries in different locations :
    • in the UUT.AditionnalData structure (local variable) of the process model
    • in station globals
    • in locales variables
  • I can store the test results in:
    • The database
  • I can split the sequences in this way :
    • having a top level sequence with sub sequences that define the high level tests
    • use pre-conditions on tests & sub sequences to decide whether or not it should run
    • All of the above
  • I'm questionning about :
    • insert some Object Oriented layer somewhere, since it's possible to easilly do dynamic dispatch in TS
    • using xml and xpath queries (I heard a little about that)

I have a feeling that when you say "Query" you only refer to getting information out of the DB. Queries are also used to put data in (like the results)

 

Take a look at the Board Testing Example in "examples\lvoop\BoardTesting". Look to see how you would convert that into being sequenced from test stand rather than LabVIEW. Look at where you would replace the board information, pass/fail criteria and results logging with SQL. Move the responsibilities, piece-by-piece, over to Test Stand until you are satisfied. If you can do it with that example, you can do it with most test systems. It will answer nearly all of your above questions and provide insight as to .where your design decisions are crucial and where they are arbitrary preference. You will reach an equilibrium point where things become a lot harder to move over or become overly complex (at the hardware abstraction usually). It will also be a good frame of reference to ask specific questions that we can give answers to with practical examples.

Just bear in mind that Test Stand is a sequencing engine using linear scripts. It is not a programming language!. Don't complicate it by trying to force a scripting IDE to operate an OOP architecture - let LabVIEW do that and use Test Stand to drive it. Test Stand does many things exceptionally well but much of what is advertised is better done elsewhere.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.