06-12-2014 01:12 AM
I'm now in a situation to make a choise how we want to design our UUT.
There are 2 situation in which I think of.
- use a popup in a sequence as a UUT.
- Build a UUT in labview which then calls the teststand API like the teststand operator interface example.
06-12-2014 08:10 AM
UUT generally stands for Unit Under Test. Which means that a UUT is the item in which you are testing? I am very confused by your question here. Is your UUT a piece of software?
Typically what happens with TestStand is that you have the sequence editor to develop your test. Then you deploy it. Then you run it on a User Interface (I recommend one of the ones that ship with TestStand, that way you don't have to build anything).
Can you clarify a little for me and I'll be able to provide better help?
Thanks,
06-12-2014 08:12 AM - edited 06-12-2014 08:17 AM
I'm very sorry.
I mend user interface, got confused but teststands standard interface.
The user interface examples are very nice, I will still add more options which are needed here.
What we want to make is a standard user interface for test systems that will be used by all our factories.
We also have the idea to use microsoft visio to build(simple) tests, as time permits we will expand this to also make more complex tests with visio.
06-12-2014 05:26 PM
Hi,
Start with the User Interface examples that you mention. The source code is included:
C:\Program Files (x86)\National Instruments\TestStand 2013\UserInterfaces\Simple\LabVIEW
C:\Program Files (x86)\National Instruments\TestStand 2013\UserInterfaces\Full-Featured\LabVIEW
There's also source code for C and .Net there.
Edit the source code to add the options you need.
Since you are creating something for all your factories, you should follow established best practices for making these edits. Your options:
1. Take the TestStand class
2. Use this forum, ni.com, and National Instruments tech support
3. Hire a National Instruments Alliance partner
Following best practices will make the job easier. You can really generate much unnecessary work if you do this without the proper research. just my opinion.
cc
06-13-2014 12:32 AM
Hi Downow,
thank you for replying.
I already did follow class 1 and 2 of teststand.
And as you can see I also use this forum.
What I was thinking as you also mentioned was to hire a teststand pro to define which way to go.
We also get support by NI for help and such but I wanted to ask the forum first.
06-13-2014 04:54 PM
i was thinking about that too... i have the same problem. i could run the test stand interface for our test. but i would be nice to have a nice simple UI for operators to load sequence files and test across the company. i look at the exmple provider and in my case it looks time consuming so my best bet is to hire someone to do that UI.
i would rather focus my time on doing test sequences.
06-13-2014 05:19 PM
Hi,
Because the TestStand UI is decoupled from the test execution, many companies benefit by having one base UI that can be used for many product lines.
Buton, AFAIK the best examples are the Simple and Full examples that come with TestStand. Your local National Instruments rep can probably refer you to an Alliance member in your area. If not I can help you find someone.
There is a chapter with exercises in the TestStand class that shows how to modify the default TestStand Uis. It is a very simple example but it does show the key concept of how to use UI messages. What I do is start with the TestStand UI, then add my customizations, and just scoot the TestStand UI elements I'm not using off to the side of the panel so they are not visible. That way I don't break things. As you get more comfortable you can delete them.
The general concept is that the UI is a thin application that the operator uses to send commands to the test, and to view test status. Imho do not put any test code in the UI. By that I mean code that communicates with instruments or databases or files, etc. You can use the TestStand UI controls, and the TestStand api to send commands to your executions, or to set Station Globals that the executions poll. UI messages should be used to transmit information in the opposite direction, from executions to the UI. Use the PostUIMessageEx method for this. The UI has a message handler to pick up the messages. One good test of your design is, can you run your test sequences in both the UI and in the Sequence Editor interchangeably.
Follow those rules to keep the UI fully decoupled from your test sequences. Of course it's alway 80%-20%, you may need to make an exception.
cc
06-16-2014 01:19 AM
Downow: thank you for your input.
We are now planning how to make all the modules needed for the standardisation of the test software.
The test sequence which will be called from the main will allways run independently.
We are planned to use object oriented programming for the modules.
The modules for now which we like to inplement are:
- HAL(hardware abstraction layer)
- test configurator(create simple tests which microsoft visio)
- Trouble Shoot Database(data base to store previous fault found)