Having a Labview VI as a permanent display on a test run

[Gig52]

Using LabView 8 and TestStand 3.5

Currently, the test sequence is composed of 5 sub-sequences.
Each sub-sequences will perform test using some VI and creating success, warning and failures.

Now, I would like each sub-sequences to  call a common vi to update the current progress of  Test count, Success, warning and failures.
The VI is simple, it takes an increment and display the updated number.

However, the current problem is I am unable to have the VI always displayed.
It will quickly flash on the screen when called by TestStand since it has the Show VI when called checked.
But it closes right away.

Is there a way to have a VI always loaded (and displayed)??

Thanks.

EG
 

[smercurio_fc]

How is this subVI set up? Does it have a loop that keeps the VI running until it's forced to close or it closes by means of a front panel control?

[Gig52]

Basically, I tried different approach so far.
None of them working to my expectation...

Test 1) Using a while loop (with a close button)

In this case, since the VI never return control, I am block in the VI

Test 2) Simple VI with LabView properties

In this case, I tried the Execution properties, apperance properties from Labview.
It only quickly flashes on the screen.

Test 3) Simple VI with TestStand properties

Same as test 2 but trying to configure the load logic on TestStand without success since
the VI only flashes quikcly on the screen..

*****

Is it possible to have a VI always on top and feed him data to show progress??
What kind of VI is needed and how to return control to TestStand without quitting the VI??

EG

[Gig52]

Update:

Possible solution on the current problem.

!) In TestStand, have the VI run asynchronously.
2) Update VI content with Data socket....

EG

[tbob]

The best thing to do would be to modify the TestStand operator interface.  This is not an easy task.  But you could include the indicators you want on the TestStand screen.  TestStand ships with Labview code for the TestStand operator interface.  You could modify this vi to include the indicators you want.  Good luck, it is quite complex, but this would be the best solution.  Warning: copy the vi from the NI folder to the User folder and modify the one in the User folder.  You can direct TestStand to use the User folder instead of the NI folder.  This way, when upgrading or re-installing, you won't be overwriting your modified vi.

[smercurio_fc]

Unfortunately, I don't have TestStand, so I can't really test out this idea. However, one thought that comes to mind, if I understand your objective correctly, is to create this "status" VI as a simple VI that has a while loop that keeps it running so that it can display status. How you get data to it can be done by Data Socket, but I think a queue would be easier. The status VI just needs to monitor the queue for messages and update its front panel when it receives updated information. Now, write a very simple VI that calls and runs this VI dynamically to basically launch it. This shell VI is what you call from TestStand. This will basically allow you to create a step in TestStand that calls this shell VI. The shell VI launches your "status" VI and then ends, returning control to TestStand. As I said, I'm not sure if I completely understood your objective.

[tbob]

Even with using a simple separate vi, you would still have to change the TestStand Operator Interface to write the desired information to a queue.  Might as well just put indicators on the operator interface front panel and update directly.

Ray Farmer is the TestStand expert in this group.  Perhaps he could expand a little more.  Where are your Ray?

[Andrew W]

Howdy EG -

First, lets address how you are going to send this message from TestStand.  Obviously, whether using DataSocket or not, you are going to need to post this information.  I would recommend using the SequenceFilePostStep engine callback to post the information you are referencing.  Furthermore, you will need to send a "kill" message to the asynchronous LabVIEW VI.  You would most likely need to modify your process model.  This could be as simple as adding a sequence at the end of your process model execution entry point (Test UUT, Single Pass, or both).  This sequence could contain a single step which issues the "kill" command.
________________

To post this information, you could use a LabVIEW VI which posts with DataSocket, and that may work.  However, using this method, I would recommend using LabVIEW queues to ensure no data loss.  Additionally, TestStand also has built in functionality to post messages through the engine.  The PostUIMessageEx could be used to post asynchronous messages regarding any information you would like.  You would give each message you would want to post a different User-code for the message which could be interpreted by your LabVIEW VI.  You can take a look at the help file regarding Thread.PostUIMessageEx for more information on posting messages.

On the LabVIEW side, you would have LabVIEW queues to bring in the information which should work just fine.  Alternatively, with PostUIMessageEx, you would want a simple interpreter that figures out which message was posted, and then updates your VI accordingly. 
________________

Tbob was right in that the functionality can be built into your OI instead of having a separate asynchronous VI.  Usually this would be easier, because the managers used by the OI already interpret UI messages for us.  However, since you are going to be dealing with information that you will be posting through LV queues or UIMessages, the manager controls would not help here.  Thus, the option is up to you whether or not to build in the additional functionality into the OI.
________________

In summary, you can use the asynchronous VI, and post the information using LabVIEW queues.  I just wanted to make you aware of some of the alternative functionality built into TestStand .  Also be aware of the fact that you will most likely need to post the information in an engine callback, and will also need to post a message to "kill" the asynchronous VI, most likely within at the end of the process model execution entry points.

Hopefully this answers some of your questions.  Let me know if you need anything else.

Have a great day!

Regards,
Andrew W || Applications Engineer
National Instruments