UI - strategic Q

[LuI]

Hi all,

maybe I am too biased by my LV history, but at the moment I have no idea on the best strategy to solve this problem:

I have a test station for medical devices. We have switches. etc to connect up to 15 such devices and test them partially in parallel, partially sequential. A single test may take between some 10 minutes to some hours. Our aim is to connect as many of the devices to the system and let it test 'em automatically. An operator has to review the status only now and then. Most of the time the whole test system is aimed to run freely without any operators availabel (e.g. at night).
What I need is an idea for the operator interface, that:
* gives a short overview on the status of each single UUT test
* eables to activate the (more specific) execution and/or report window
* add new UUTs to a free test socket and put it into the queue of pending tests
* remove tested UUTs from their test socket, mark those sockets as free for new UUTs

My idea was to have a status array for all test sockets on the left side of the screen, that shows just:
* pending/running/error/passed/fail
* maybe a wild guess on how far the test is (e.g ~20% or ~123 minutes left)
* activation knobs for the execution window and the results window
Than most of the screen is empty to show the requested window.
Additionally I need just an abort/stop button. The test could handle standard finish itself. Whenever no test sockets are filled a message box could pop up asking to stop or continue.

I have experimented with TS2 and just received TS3. I tried the parallel process model, but this one opens all test executions in parallel (number is preset in the station options and is 15 in my case). This results in a huge clutter of mutilated execution windows, where one can not see or operate anything.

I have opened the full featured TS-OI in LabVIEW and have reviewed the 'User Interface Control Reference Poster', but up to now I feel more or less abandoned or lost in detailes.

Anyone out there that can point me into the right direction? Ideas, examples, solutions? There is no chance to buy a complete solution, because there are lots of device- and equipment-specific steps. I even fear there is no chance for some external project work - we are sitting here near Berlin/Germany (time shift) and money is limited too.

I'll put this message in parallel to TestStand-info and TS DevZone for better chances of answers.
And I'll post a summary if I get private answers that might be of interest to others too.

Greetings from Germany!
--
Uwe Frenz


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dr. Uwe Frenz
Entwicklung
getemed Medizin- und Informationtechnik AG

[Shannon R]

Uwe,

It sounds like you have quite the project ahead of you! Fortunately, with TestStand 3.0 your development time will be much shorter than with the previous versions of TestStand. With TestStand 3.0, we made ActiveX controls which handle almost every common behavior used in an operator interface, and you can customize the controls to show certain data, colors, or step information. Probably the best way for you to familiarize yourself with the controls is to look at the simple operator interfaces that ship with TestStand. They install in <TestStand>\Operator Interfaces\Simple and are available in C#, C++, LabWindows/CVI, LabVIEW, and VB.NET. This will give you a good idea of how to get started.

There's also a manual called "Using LabVIEW with TestStand". Chapter 6 is all about the operator interfaces and how to create a custom operator interface.

Since the operator interfaces are fully customizable, it is totally possible to show 15 executions on one panel and display have some information about each of the executions.

The process models that ship with TestStand are also fully customizable. It doesn't sound like you'll be using the default sequential or parallel process model, but you can start with one of these models and change them to meet your needs. They are really just controlling sequence files, so it is as easy to add a step to a process model as it is to add a step to a regular sequence.

There are also synchronization step types which can help you control which steps can execute at the same time and which cannot execute simultaneously. You can launch new threads and new executions in your TestStand sequence with just 3 mouse clicks.

If you haven't used TestStand at all, I'd start learning about the development environment by reading the Getting Started with TestStand manual. You are lucky to have TestStand 3.0, because the documentation is much better for new users.

If you have time, it might be a good idea to enroll in a TestStand class, or at least see if you can purchase the manuals. The course is a really great way to get a good in-depth introduction to TestStand. You can see what courses we have available at Customer Education.

I know this doesn't answer all of your questions, but I hope it gets you started in the right direction. There's a lot to address to get you going. Let us know if you have any other questions along the way.

Good luck!
Shannon R.
Applications Engineer
National Instruments

[LuI]

Shannon,

thanx for your answer.
I did some playing with TS2 and TS3ß and have just recently started with TS3.
I had participated in the TS basic course in Munich, Germany late last year. Allthough it was a lot of information I missed some basic info, at least in _my_ point of view:
* The first is an overview how those process models work. There is a graph for the serial process model and its callbacks in the manual, but nothing for the parallel and the batch model.
* Than there is nothing on the importance of the operator interfaces. They had been mentioned and we have been told that allmost everything can be done from such operator interfaces. But those interested in that should enroll in the TS advanced course. And implied (at least for me) I got the idea th
at one does not really need those operator interfaces until one has to solve really specific problems.
* I missed some guiding in strategic decisions on how-to-dos.

You know, i am quite familiar with LV since V3.0. I had some experience in Turbo Pascal, some basic dialects, assembler etc.
I got the idea of TS and how it could ease and fasten my test devellopment.
But I missed some road maps for the test design and devellopment. And I felt lost in the process control of the process models.

I invested a lot of time to study the process models, some examples and nowadays the operator interfaces provided with TS3. If I had waited some more days until I posted this Q I might have been able to answer parts of it myself.
But the replies I got showed me that this really is a problem others are faced with too.

Again thank you. I'll try to summarize what I have got and post it here. Maybe others will benefit too.
Greetings from Germany!
--
Uwe Frenz

[RayFarmer]

Hi Uwe,

For the documentation of the Process models you can find these, for TestStand 3.0,in Appendix A of the Reference Manual. For TestStand 2.0.x, you can find them in a pdf file called TestStandProcessModels. This is located in the same folder as the process models.

For the operator interfaces, for TestStand 2.0.x, there is a word document which you can find in the relevant operator interface folder. For TestStand 3.0, theres the new User Interface Controls poster and the Using LabVIEW with TestStand manual.
Although I have found that the only real way of find out that make the operator interfaces tick is to browse through the code and playing with the examples and trying thing out.

From reading your original question, although it look like
you want to perform some parallel process. It seemslike its running multiple sequential processes in parallel rather than one sequential process running several times in parallel (as in the default parallel process model). It also seems that looking at some of the simple operator interfaces would be the place to start, as you are looking for the basics in terms of the TestStand operations.

Hope this helps
Regards
Ray Farmer

[LuI]

Ray,

thanx for your answer. I've found those docs one-by-one and have reviewed it.

This test system is intended to be used on the production floor by simple test operators. I can not assume them to be able to handle different processes in totally independend windows. Neither should they see a patchwork of ~ 16 tiled windows for those parallel running executions in the parallel process model.

I got several answers now and I think I have to deploy a modified operator interface to handle the User interaction to all those processes. I made a plan for a set of sequences that should provide the needed functionality within the parallel process model.

Thanx again to all who answered. I'll post a summany when I see my concept is working.

Greetin
gs from Germany!
--
Uwe Frenz

[Herbert Koltschik]

Hello Uwe,

If all of your UUTs which should be tested in parallel use the same sequence file (product deviations might be handled by using the PropertyLoader) then it might be easier just to replace the process model dialogs with your own instead of modifying the operator interface.
When designing your dialog(s) you will get to the following problem:
How do my TestStand executions communicate with my LabView dialog?
The way I solved this problem was be utilizing TestStand’s Synchronization manager. Although this API is not documented it’s straightforward to use and very helpful. I personally used it for my LV-Dialog in my modified Batch-Model.
You can find more details about TestStand’s Synchronization m
anager here:

http://exchange.ni.com/servlet/ProcessRequest?RHIVEID=101&RNAME=ViewQuestion&HOID=506500000008000000593D0000&ECategory=TestStand

I normally hide the executions (process model options) and do most of the user interfacing through my LV-Dialog. I use the Operator Interface just to select the sequence file and to launch it. But I’ve automated even this by using command line parameters (of the OI) to automatically launch the proper sequence.

Just some thoughts…

Regards
Herbert
*********************************
Herbert Koltschik
Sagem Communication Austria
herbert.koltschik@sagem.com
*********************************