Jump to content

Multi-developer/product TestStand strategies?


Recommended Posts

I work with a small-ish (5-6) team of developers at my company.  We're trying to update and improve a lot of our old test station software and we've decided to try using TestStand for sequencing instead of writing a custom sequence for each test station and product, or trying to write a generic but highly complicated sequencer ourselves that could work for every test station we have.

 

In order to keep things as modular as possible we'd like to come up with a set of rules/guidelines that we all agree to follow in some manner, so we can assign one person to develop for tests using one type of hardware, one for a different type of hardware, one to do all of the database interactions, and so on, but with the requirements and interactions for those clearly defined enough such that there's no unexpected interactions between VIs.

 

We'd also probably need to put in place a few new coding guidelines, such as perhaps a ban on global variables, trying to cut down/eliminate passing clusters/objects between VIs and passing primitives instead, and so on.

 

I'm just curious if there's anyone out there who has done something like this before and maybe has any advice for things to establish before getting started.  It's much easier to do things as right as possible from the beginning instead of waiting until we have hundreds of VIs written in an inconvenient way and we have to make the decision whether to rewrite them all to be "right" or to work around them even though they are "wrong", etc.

 

Thanks!

Link to comment
  • 1 year later...

As a suggestion, you may try to work as a group to create a "UML" based strategy on your needs for most aspects of the Tests in order to separate the work and know what is required for each developer.

For the first project of the company I'm working for, I created a set of VIs that will be universal (libraries, drivers, HW calls, etc.) and used for all future projects and will be independent. They are in a separate folder. Currently running in some deployment annoyance because my VIs aren't all within the Workspace folder, but I'm working around it.

As the main LV developer, I created sequence wrappers for all VI and hardware calls for it to be easier for people who develop the TestStand sequences. The wrappers allow quick changes that will not affect the sequences and most wrappers include an array of strings as input for future settings and configurations. Barely any code is visible within the procedure steps, unless you dig really deep past the step numbering of the test procedures.

Coding guidelines are very important in TestStand in order to avoid a major mess and being difficult to understand in the future. Note that one of the main issues with TestStand workspace is that their is no project globals, you will be required to use Station Globals. Which we had to create a container for the project (StationGlobals.ProjectName.IO.Serial1.port for example).

Take a good 2 weeks to plan out your architecture. I was cut a week short because of pressure, but in the end costed a lot more time because it wasn't fully completed.

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.

  • Similar Content

    • By Bryan
      TestStand Version(s) Used: 2010 thru 2016
      Windows (7 & 10)
      Database: MS SQL Server (v?)
      Note: The database connection I'm referring to is what's configured in "Configure > Result Processing", (or equivalent location in older versions).
      Based on some issues we've been having with nearly all of our TestStand-based production testers, I'm assuming that TestStand opens the configured database connection when the sequence is run, and maintains that same connection for all subsequent UUTs tested until the sequence is stopped/terminated/aborted.  However, I'm not sure of this and would like someone to either confirm or correct this assumption. 
      The problem we're having is that: Nearly all of our TestStand-based production testers have intermittently been losing their database connections - returning an error (usually after the PASS/FAIL banner).  I'm not sure if it's a TestStand issue or an issue with the database itself. The operator - Seeing and only caring about whether it passed or failed, often ignores the error message and soldiers on, mostly ignoring every error message that pops up.  Testers at the next higher assembly that look for a passed record of the sub assemblies' serial number in the database will now fail their test because they can't find a passed record of the serial number. 
      We've tried communicating with the operators to either let us know when the error occurs, re-test the UUT, or restart TestStand (usually the option that works), but it's often forgotten or ignored.
      The operators do not stop the test sequence when they go home for the evening/weekend/etc. so, TestStand is normally left waiting for them to enter the next serial number of the device to test.  I'm assuming that their connection to the database is still opened during this time.  If so, it's almost as though MS SQL has been configured to terminate idle connections to it, or if something happens with the SQL Server - the connection hasn't been properly closed or re-established, etc. 
      Our LabVIEW based testers don't appear to have this problem unless there really is an issue with the database server.  The majority of these testers I believe open > write > close their database connections at the completion of a unit test. 
      I'm currently looking into writing my own routine to be called in the "Log to Database" callback which will open > write > close the database connection.  But, I wanted to check if anyone more knowledgeable had any insight before I spend time doing something that may have an easy fix.
      Thanks all!
    • By Srinivas Iyer
      Hello,
      I am trying to do the following (LabVIEW2019, TestStand2019, Windows 10)
      Create a new sub-property under RunState.Engine.TemporaryGlobals as Measurements.TestName_DateTimeStamp 
      My TS expression:
       //get a handle to runstate.engine.temporaryglobals
      Locals.tmp_prop_object = RunState.Engine.TemporaryGlobals,
      //create a new obj ref type property under this
      Locals.tmp_prop_object.AsPropertyObject.NewSubProperty(Locals.name1, PropValType_Reference, False, "",0),
      where Locals.name1 is Measurements.TestName_DateTimeStamp (e.g: RunState.Engine.TemporaryGlobals.Measurements.RxGain12_16_58AM)
      I now want to assign a LabVIEW class object to this property as:
      RunState.Engine.TemporaryGlobals.Measurements.RxGain12_16_58AM = Locals.tmp_obj_ref
      where Locals.tmp_obj_ref is the output terminal of a LabVIEW class and tmp_obj_ref is a TestStand variable of type Object Reference
      If I do it like this in the expression window, I can see that my RunState.Engine.TemporaryGlobals.RxGain12_16_58AM has been assigned a LabVIEW class object
      However, the value RxGain12_16_58AM is known to me only at run-time, so I cannot hard-code the assignment expression as above.
      Any pointers on how to achieve this?
      Basically if,
      Locals.name = "RxGain12_16_58AM" (created at run-time)
      then i want to be able to assign, during run-time:
      RunState.Engine.TemporaryGlobals.RxGain12_16_58AM = Locals.tmp_obj_ref


    • By MRedRaider
      15. FIFTEEN. That's the number of current job postings  in my group. We're hiring! This is the most fulfilling, challenging, and rewarding position I've held. Job specific requirements listed on the website.

      https://www.lockheedmartinjobs.com/search-jobs/Test%20Engineer/Grand%20Prairie%2C%20TX/694/1/4/6252001-4736286-4684904-4694482/32x74596/-96x99778/15/2
    • By Jean LINISA
      Bonjour,
      Je recherche pour une mission longue durée (1 an minimum) en région parisienne un(e) ingénieur(e) LabVIEW & TestStand expérimenté(e).
      Une certification CLD/CLA et/ou CTD serait fortement appréciée.
      Un backgroud en électronique/mécatronique serait un plus.
      Disponibilité ASAP
      Français obligatoire.
      Contactez-moi en MP ou par Mail
    • By Avital_Testview
      Hi all,
      We're excited to announce the public release of TVI – our industry-proven test management framework for LabVIEW:
      http://tvi.co
      TVI is a flexible and easy to use test sequencer and reports generator for LabVIEW based functional testers.

      Key features:
      Simple and easy to use user interface Very short learning curve Creating test sequences in few clicks Viewing results in real time Exporting of data in various formats (CSV, PDF, HTML) Seamless integration with LabVIEW enables to write/edit tests directly from TVI (developer mode) Editing sequences and test parameters on the assembly line stations (runner mode, no need for LabVIEW) (TVI does not require TestStand to run)
      See it in action here: https://youtu.be/7Job4qMc66w

       
       
      We’d love to get any feedback!

      Thanks,

      Avital

       
×
×
  • Create New...

Important Information

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