Is TestStand Applicable to our Application?

[Joe Shmoe]

Our company is in the process of designing complex electrical/pneumatic test stands and we are currently programming the control systems using Visual Basic. Our applications seem rather complex because there are many switches and instruments to control. I would like to know if there are any advantages using National Instrument�s Test Stand/Lab View vs. programming the complete control system from scratch using Visual Basic?

The test stands are used to qualify complex pneumatic devices. There are many electric/pneumatic switches within the test stand that are use to create hundreds of possible pneumatic circuits that can pass through the device to be tested. There can be up to 100 sequences in a single test.
During each sequence�s step, there is a possibility that the unit will fail and the user then needs to be routed to a corrective action to fix the part being tested.

Additionally, the computer code needs to be an executable because the end user will be military personnel in remote locations. Database storage and reports are also required.

We currently use NI boards to gather the data, however, we are programming the controls using Visual Basic. For each part to test, we have many required test sequences and hundreds of instruments and switches to both control measure and record. Additionally, we have many possible test errors to handle.

We have spent almost a year working on the underlying code to be able to control the test stands. We have just started to delve into the individual tests that consist of many sequence steps.

It just seems that we are reinventing the wheel. How well do you think that Test Stand/Lab View could be able to handle this application for us
?

I look forward to your response.

[Shiner]

The disadvantage of using a standalone application produced in whatever language is that you have all you eggs in one basket. You will spend much of your time developing report engines, sequence engines, error handling etc, as well as the code that you need to drive your UUT and associated test equipment.

Using TestStand will allow you to concentrate your development on just the test code to drive your UUT and / or test equipment.

For example (very simply), if you produce a function in CVI / LabView / ActiveX / (VB DLL) to read a port, and a function to set a port on your control cards. You could then create a series of sequence steps to control your UUT. If you want to change the behaviour of the very simple test above, you only have to modify the sequence and don�t even have to open your main coding environment. (This has its own benefits).

Put quite simply TestStand allows you to create better more stable drivers for your UUT / test equipment without the overhead of the items I mentioned below.
I have said this when I first started using NI�s TestStand that its main downfall is its power, in that there is not much you can�t do with it, so keeping control of developers (when developing sequences) is a much of a problem for us as we had with C programmers and LabView programmers developing in there own style.

We have deployed TestStand in 4 countries world wide and almost no C, C++, or LabView is required to generate tests now. We all have the same User Interfaces, report formats, database access etc, and we all test completely different products. We have a single team responsible for the upkeep of TestStand and its drivers, and we let individual sites create and manage their sequences. More stable code and code reuse has cut our development times down to weeks instead of months.

Yes there is some initial up front work where it appears that you are achieving no results, but its worth it in the end.

If you have the underlying code to control your Test Stands then you are more than 75% there already. Why spend time developing reporting tools, sequence engine (Big development area), when you can change or provide an interface to your already generated code and control it from TestStand.

Please contact me directly if you want any more information,

Regards

Chris

[Joe Shmoe]

Chris,

Thanks for the excellent response.

You mentioned the underlying code to control the test stand. We have written this code from scratch in an object-orientated manner in Visual Basic.

We have spent many months designing this underlying code and it works, but it took a long time and I do not know how expandable it is for the future. Can NI TestStand or Lab View easily handle this underlying code and then could we use TestStand to control the many sequential tests above the NI underlying code?

How well does TestStand/Lab View handle errors? In our case some errors will be due to the test stand and in others due to the failure of the parts being tested. Can we tie instructions into the sequences, including text and images? If so, how well is it
organized?

Also, how well does TestStand/Lab View tie in with Visual Basic? We have many different products for the users to test and we need a lot of flexibility with regards to the user interface or do you think that TestStand/Lab View can easily handle this on its own?

Again, thanks for your response and I hope to hear from you again soon.

Sincerely,

Jon

[Mark_Ireton]

I agree with the previous response that TestStand seems well suited for your application. TestStand has database logging capability and it is fairly easy to customize the logging to match your schema. However, if your database is very complex (highly normalized) you may have problems. You can use the TestStand report generator to get HTML or text reports, customizing the format if you want.

As for error handling, TestStand is very flexible. Sometimes a run-time failure can be caused by either a system problem or a device failure. If your operator is not highly skilled, you can configure error handling so that any run-time error will go directly to a "cleanup" sequence that can put everything in a safe state and exit gracefully. If your operator is more sophisti
cated, you can set error handling so that a dialog box is displayed, giving error information and the choices of "run cleanup", "retry", "ignore", or "abort".

TestStand can call ActiveX components, DLL's, or EXE's, so that should allow you to use your VB code. TestStand is especially useful for tests where you have multiple steps that are basically just running the same code with different parameters. I recommend you get a free evaluation copy and try it out.

Mark