Multi-developer/product TestStand strategies?

[Autodefenestrator]

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!

[crossrulz]

TestStand can handle clusters just fine.  But only make things clusters for those that are actually logically grouped.

 

You can pick up a lot of things from this article from NI: NI TestStand Advanced Architecture Series

[Stormshadow]

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.