LabVIEW vs Teststand

[Clint1000]

I know this question has been asked before but I need some help in explaining it to my colleagues.

I've been using Labview since it was LV5.0.  Between then and now I've used LV w Teststand.  The way I thought of it was you write your test in LV ( or another language C..etc.) and Teststand calls these vis and evaluates some pass/fail criteria.  Teststand is a Test executive.  There is some code that goes w teststand but for the most part it was only intended to help you from reinventing the wheel..determine pass/fail of a test..create a report.."if then.." etc.  I'm in a new job environment where the group is using teststand exclusively to write the code  !!!  I am having a hard time convincing them..and myself this isn't the correct way of doing the test.  Or is it??  It just doesn't feel right.  I think the test is relatively complex.  Can someone w extensive knowledge of both apps help me explain why calls to other programs should be done w and the low level code not written in Teststand??

Thxs.

[Norbert_B]

Do as much as possible in TestStand. Put only code in modules for tasks which:

1. Access hardware IO

2. Complex algorithm, possibly on large data structures. These are often easier to implement and debug in a code module rather than in TS

There are some exceptions though:

1. Using existing code which requires only little adoption (if at all) to be callable by TS

2. Performance (Time): Switching between code modules and TS requires little time. However, it can sum up....

3. Performance (Memory): Keeping large data in modules can lower memory footprint

[BowenM]

Well, TestStand is a complete language...  so what they are doing currently isn't necessarily "wrong".  The external adapters are to allow developers familiar with other languages to write the code in something that is familiar to them... as well as use external things like .NET and ActiveX.

That having been said, I think the best argument you could make is development time.  I've been using TestStand off and on for 3 years now and still find the IDE to be clunky.  A bit of code that would take me 20 min to do in LabVIEW will often times take me 2-3x that in TestStand.

So, demonstrate this to them.  Have one of the local guys arguing for TestStand write a pass/fail test, and you do the same thing in LabVIEW.  Prove to them that you are considerably faster.

[billko]

One of TestStand's selling points is that as long as you have a module for it, you can create tests in whatever programming language suits you (and the test).  Personally, I can't imagine someone who is proficient with TestStand not understanding this most basic point.

[Clint1000]

Never thought of this till now..can you even access external hardware w/o using something like LV or other modules?  Specifically like a DAQ Card? 

[Norbert_B]

For access of hardware, TS requires to call code modules (LV, .NET, C/C++, ...). The only exception for this are switches when using NI Switch Executive.

[crossrulz]

I learned after a major project about 5 years ago to follow the advice Norbert already gave: you want as much at the TestStand level as possible.  Use LabVIEW to access the hardware and handle some other tests where performance is necessary and let TestStand do everything else for you.  It makes it a lot easier for the non-programmers out there to understand what is happening.  Debugging is really simple in TestStand (you can update variables before and after each step when single-stepping, you can go back to previous steps, etc).

I am currently in an effort to completely redesign our test executive (was using TestStand's predecessor written for CVI).  So I am deploying my drivers and special libraries to PPLs.  I made a new report generator that TestStand uses.  I have been lucky enough to avoid making a custom model so far.  So the hope is that I can just hand a test requirements document to a lower level engineer and have them just run with creating TestStand sequences using my libraries as needed.  Fingers crossed.

[_S_G]

As a CLA and CTA, I have to say that BowenM said it better than I could have.  I completely agree with what he said.

---

@BowenM wrote:

Well, TestStand is a complete language...  so what they are doing currently isn't necessarily "wrong".  The external adapters are to allow developers familiar with other languages to write the code in something that is familiar to them... as well as use external things like .NET and ActiveX.

That having been said, I think the best argument you could make is development time.  I've been using TestStand off and on for 3 years now and still find the IDE to be clunky.  A bit of code that would take me 20 min to do in LabVIEW will often times take me 2-3x that in TestStand.

So, demonstrate this to them.  Have one of the local guys arguing for TestStand write a pass/fail test, and you do the same thing in LabVIEW.  Prove to them that you are considerably faster.

---

[njacacia]

---

@BowenM wrote:

Well, TestStand is a complete language... 

---

The tutorial I have seen from NI discusses LabVIEW in conjunction with Testand.

Is there a tutorial just on TestStand the language?

[crossrulz]

---

@njacacia wrote:

---

@BowenM wrote:

Well, TestStand is a complete language... 

---

The tutorial I have seen from NI discusses LabVIEW in conjunction with Testand.

Is there a tutorial just on TestStand the language?

---

All tutorials will be with TestStand calling LabVIEW and/or LabWindows/CVI.  TestStand is not really a language.  It is a test executive with hooks all over the place that you can customize what you want (I don't recommend it unless you really have to).