Test Stand Evaluation

[Alies]

Hi.

I would like to get some feedback regarding using Test Stand with Labview.

Currently I am using Delphi Interface as my Excecutive Engine and Active
X server to communicate with labview. The data logging, PLC I/O and Login/logout
are part of Delphi Inteface. The labview is used only to execute the actual
test. Now by switching to Test Stand, would that benefit me in any way.(For
instance: Does Test Stand(LV Server) allows me to run single or multiple
Vi's, without creating 'exe')?

[Richard McDonell]

Yes, TestStand is designed to call VIs directly thus preventing you from having to build your LabVIEW tests into .exe's. TestStand does offer the capability to call .exe's though if you need to. TestStand is a test management software that will allow you to concentrate more on writing your tests modules rather than trying to create your own test executive. Some of our customers are also using Delphi with TestStand. Therefore you may be able to reuse some of your Delphi interface and ActiveX server. In fact, TestStand works with any software language that supports ActiveX. Hope this helps.

[Mark_Ireton]

There could be lots of advantages to switching to TestStand, but it depends on your application.

1. If you deploy your applications to several different environments or uses (board test, system test, service, field service, etc.) then TestStand allows you to customize different "process models" for each environment. The actual test code is contained in a sequence file. Since the process model is shared by all sequence files, it is a great place to put the common functions such as UUT identification and data logging. Even if you don't need different process models, keeping all this code in one place makes it easier to maintain. There is no compiling with TestStand, so you can change the process model and the changes will take effect in all your applications.

2.
TestStand allows you to easily call many different types of code, not just Labview. You can call CVI, DLL's, EXE's, and ActiveX. I recently saw an article about a way to call Perl code. Again, the value of this depends on your application.

3. If you want to integrate your application with a database, TestStand has great database tools. The database logging utility allows you to log data to any table format.

4. If you are loading test limits from an external source, TestStand makes it easy with a tool called Property Loader.

I suggest you get a free demo copy and try it out. TestStand is incredibly powerful.

Mark (marki@tek.com)

[Dennis_Knutson]

We moved from a custom test exec to TestStand about a year and a half ago and it was probably the best decision we've ever made. TestStand gave us the ability to easily implement a wide variety of test strategies including testing multiple UUTs in parallel. Also, with the use of IVI instrument drivers and custom step types, a lot of tests can be created without any LabVIEW programming at all.

[dcabernel]

I was working on test programs for 6 related products and was developing a
test executive to provide automatic/manual testing, reporting, logging etc
and soon became overwhelmed with the enormity of the task. Then I found
out my test times would be to long to meet cycle times. I then looked at
TestStand since it has the capability for concurrent testing. I haven't
tried that feature yet, but for the most part TestStand has made my life a
whole lot easier and I was able to get the test programs done for our
prototype run. I don't belive I would have been able to going in the
direction I was.

One thing I don't like about teststand though, is at this time it only
supports passing one string to a Labview VI. You then have to parse that
in your VI if you want
to send multiple variables etc. There is probably
a way around this using the API but I haven't made that leap yet.

[Dennis_Knutson]

Don't understand what you mean about one string. You can define as many string variables as you want in TestStand and use "TestStand - Get Property Value (String).vi" to import the values into LabVIEW. What way are you passing strings to LabVIEW?

[dcabernel]

I was using the Input Buffer string control method. You add and string
control to your VI, name it "Input Buffer" then set the Step.InBuf
property to the string value you want passed to the VI.

The VI you are refering to uses the Active X API of TestStand which is
what I mean by 'API'. I hadn't noticed those VIs before, it sure looks
easier than I first imagined. Thanks!


Dennis Knutson wrote:

> Don't understand what you mean about one string. You can define as
> many string variables as you want in TestStand and use "TestStand -
> Get Property Value (String).vi" to import the values into LabVIEW.
> What way are you passing strings to LabVIEW?