Looking for TestStand Style Guide Examples

[codcoder]

Hi,

(This is a repost from NI's community forum. No answers there so I'm trying my luck here 😀 )

As many of you are likely aware, TestStand is a powerful tool with numerous features and incredible flexibility. While these aspects are undoubtedly valuable, they can sometimes result in the creation of test sequences that are challenging to read.

In my workplace, particularly with many newcomers learning TestStand, there's a tendency to be awestruck by its programming language-like capabilities, leading to the use of excessive loops, parameters, and if-cases where a simpler, flat sequence would suffice.

Recognizing the need for clarity in test sequences, I've taken on the task of creating a style guide. The aim is to keep sequences coherent without unnecessary complexity.

My question for the community is whether anyone has already developed such a guide and is willing to share it?

Thank you in advance!

Edited November 16, 2023 by codcoder

[ShaunR]

There is a "best practices" document (this too) but I suspect you are looking for a less abstract set of guidelines.

Edited November 16, 2023 by ShaunR

[codcoder]

Both your links were good. I've found the second one, but the first was new to me. But you are right to assume that I'm looking for something less abstract. At least, that is what I want to create here—a cooking recipe of sorts.

[ShaunR]

On 11/17/2023 at 2:25 PM, codcoder said:

Both your links were good. I've found the second one, but the first was new to me. But you are right to assume that I'm looking for something less abstract. At least, that is what I want to create here—a cooking recipe of sorts.

The problem with test stand is it tries to be all things to all people. IMO, simplifying is best. I haven't used TS for quite a while but when I did, I offloaded all tests to LabVIEW and just used it basically as a script. I had a VI with command/response capabilities (via TCPIP) which meant that TS sequences were a list of operations and just sent strings to execute tests and take measurements. One nice side-effect of the TCPIP meant that you  could also execute tests remotely so an operator didn't even have to be sitting next to the machine the tests were running on (quality engineers loved that they could run tests and calibrate from their desks instead of going out to the machine).

[Lior Bilia]

When I was using TS, I let it do all the drudgery - Report, limits, configuration management, database etc. I used LV to do the tests. I had a test template with a basic state machine for the tests (Initialize, Measure, Report), This way other engineers could generate tests and match the style guidelines.