07-14-2005 04:12 PM
07-16-2005 11:50 AM
Hi Adam,
You could use a standard LabVIEW string indicator to display the Status information that can be passed with the UI Message as a string. When the RunState.Thread.PostUIMessageEx method is invoked, the UserMessage event of the Application Manager is fired. You can add an event to the Register Event Callback node in the Full OI - Configure Event Callbacks subVI to create a callback VI for the UserMessage event. This event can be added just by dragging the bottom of the node to display another event.
In the Full OI - Configure Event Callbacks subVI, wire the Application Manager reference to the event source (UserMessage) input in the Register Event Callback node's new event. A reference to the string indicator can be passed from the Full OI – Top Level VI into the Full OI - Configure Event Callbacks VI as a User Parameter where it can then be passed again as a User Parameter to the UserMessage event. Then, right-click on the VI Ref input and select Create a Callback VI.
Your callback VI will be something like the attached VI. Custom UIMessage event codes start at 10,000. The case structure in the Callback VI can have cases added for other custom UIMessages. As it is, the VI uses event code 10,000 and will work fine if the stringDataParam is the Step.Result.Status for the step last executed.
Hope this helps,
Eric M
07-19-2005 02:48 PM
07-19-2005 02:48 PM
07-19-2005 02:48 PM
07-19-2005 03:02 PM
07-20-2005 06:53 PM
Adam,
First of all, I am not sure that it is impossible to have multiple execution views on the OI front panel to display the executions of parallel test sockets. I do know that it would be very difficult relative to most OI customization. I also know that to have multiple execution viewers, you need to have one ExecutionView Manager control per viewer.
Eric
More to come....
07-20-2005 06:54 PM
Back to the other line of thought:
Instead of the string control, you could use something like a ListBox or even an array. These controls are designed to display multiple pieces of information. For example, the items in the listbox can be updated programmatically. much like the string control was earlier. In this case an array of strings is written to the control. After reading the array, the new string could be appended to the array and then the new array could be written to the control.
Now, as to having TestStand configured to pass this status information, I recommend using an Engine Callback (see chapter 10 of the TestStand Reference Manual). Specifically, you could add the ProcessModelPostStep callback to your parallel process model. This callback is a sequence that will be executed after every step in your test sequence.
In this callback, you could have the one ActiveX step that invokes the RunState.Thread.PostUIMessageEx method. You can pass
*** Parameters.Step.Result.Status ***
as the stringDataParam with this method. I was wrong in my previous post, Step.Result.Status won’t pass the right step’s status.
This way, the ListBox will be populated with a list of every step’s status.
Regards,
Eric M
07-20-2005 06:55 PM
PS. If you haven’t looked at Chapter 9 of the Reference Manual, I recommend you do. It covers Customizing Operator Interfaces. It covers both the nitty gritty details as well as some topics with a broader view.
Eric
07-26-2005 11:06 AM
Hey Eric,
Thanks a million for the pointers. I found an example that does what you suggested with the PostStep callback. Very Helpful. http://sine.ni.com/apps/we/niepd_web_display.display_epd4?p_guid=C42F09BEA4C15AD2E034080020E74861&p_...
This would be a great solution; however, there are some steps in the main sequence that I don't want status reports from. It looks like I'll have to insert an activeX step after each important step unless I can find out how to selectively execute the ProcessModelPostStep callback.
Adam