Building an "Observer" GUI for a TestStand/LabVIEW application?

[LRoy]

I admit that I am having a bit of trouble getting my arms around the relationship between TestStand and LabVIEW....

I have been writing traditional (if you can call it that) custom applications that use a scripting language to drive behavior among a loose federation of ActiveX components.  In my case, each component has a viewer (observer UI) that allows me to see what that particular component state is during a test process.  I can switch around between viewers while the UUT is being tested to allow me to debug the app from various angles if I need to.  That's all well and good, mostly.

I have just returned from some TestStand training (excellent materials and very knowledgeable instructor, by the way), and I am wondering whether I have the correct architecture in mind to rebuild my testing framework with TestStand and LabVIEW.  I basically want to replace my own script engine with TestStand, and I basically want to "observe" a running test using LabVIEW from a measurements and I/O visualization point-of-view (as opposed to a test results value point-of-view).  In other words, I would love to be able to observe switches being flipped, scope measurements, meter readings, LEDs, etc. during a test process....

Do I use LabVIEW as the OI for TestStand, and have LabVIEW GUI objects basically view results via the TestStand API?  That sounds like an after-the-fact mechanism...I wouldn't be able to view a scope waveform, for example, while the test is running?  Is there some way to build a front panel in LabVIEW (along with the TestStand controls) that is more-or-less automated/controlled by the TestStand sequences when they execute?  I don't see a clear path to make that kind of thing happen....

[SercoSteve]

That sort of thing is certainly possible.  The LabView OI that comes with TestStand, uses the built in mechanism for passing data from TestStand to LabView (called UIMessages), the controls on the LabView OI update accordingly in response to messages received.

You can define your own controls on a Labview OI and your own UIMessages to pass data to those controls at different points in the test execution. 

The TestStand II Customisation course covers UIMessages, I am guessing that isn't the course you did?

Its not to complicated but not easy to explain over the forum.  I'd contact NI for some UIMessage examples if you have tech support.  

Steve

[LRoy]

Yeah, I took the TestStand II course, and I am aware of the UIMessage stuff...I didn't consider using the UIMessages to indirectly control a LabVIEW front panel, but that would certainly be an option....thanks for the reply.

[DWeiland]

Hi LRoy,

If you have the TestStand II Training Manual, I would recommend taking a look at Exercise 5-2A. This does pretty much exactly what you mentioned earlier, displays a waveform on your OI front panel during sequence execution, and as Servo Steve mentioned, it uses UIMessages.

Hope this helps LRoy, have a good one.

[LRoy]

I do have the manuals....I'll look at that example right now!  Thanks...

[Dennis_Knutson]

I'll throw out a couple of other possibilities. You could keep your ActiveX components and call those instead of re-writing them into LabVIEW or have LabVIEW call them. Then your viewer apps could still work the way they did before. One thing that I've done with pc-based instruments (I use them a lot), is to create a front panel that displays what it is doing. Normally, I don't want them displayed to the operator because it's simply not necessary for them to see this information, but if a debug technician logs in, he can choose to display instrument panels. The VIs check the status of a global variable, and if set, it changes the properties of the VI to Execution.Show Front Panel On Call.