Just recently started looking at TestStand GUI's and i am working with one of the examples that came with TestStand.
An important aspect of my test program is that i want the user to be able to dynamically pick which of the plugged in hardware that he/she wants to conduct testing on,
so i thought i would display the connected COM-ports in a ListBox on the GUI, to let the user pick which com-ports to use.
Is this a feature that you would "normally" use the TestStand GUI for?
How could i populate a TestStand ListBox from a LabView VI? Say a simple one that uses "Find VISA Resource names".
Solved! Go to Solution.
You cannot use a TestStand ListBox for this. All of the TestStand UI Controls are built on top of a COM Object (ActiveX). This means that they get connected to the manager controls and then behave based on events from the manager controls.
You will want to ouse a LabVIEW control (ListBox in your case). Then use UI Messages to retrieve the information.
Or your other option is to just have your sequence file pop up a LabVIEW VI that has the list of HW in it. Then the user selects it. This would be the easiest route but it would have an annoying popup if you don't like that.
Let me know if you have questions about this.
Thank you for your answer!
Using UI messages seems most appealing at this time. The LabVIEW control, is this just a LabVIEW ListBox that i could place wherever on the TestStand GUI?
The other solution with having a dialog popup when a sequence is run could be good as well, as it would let the user setup and configure the tests at that point. I do plan having
more options available to the user so this might be the best way to go, since the GUI might be cluttered otherwise.
What ever option i go for, would you recommend writing configurations to a file or set variables in TestStand?
If you use UI Messages then yes you would use a simple LabVIEW ListBox. Just place it where you want on the GUI. The advantage of this option is that it give the user everything they need right there. No annoying dialog boxes popping up whenever. The disadvantage is that you have to create your own UI and this can be time consuming. And then you have to worry about deploying it. Not a big deal if you know what you are doing.
The option I pointed out is just simply pop up a VI in your sequence file. The VI would just be a list box where they could choose their options and click OK. The advantage here is that it is simple to implement. The disadvantage is that some people might view it as an annoying dialog.
Do you need the data to persist from run to run? If so then you can write it to disk. If you only want the user to configure it occasionally then you might consider creating a configuration entry point in your process model.
Choosing the right option depends on your requirements and time constraints.
Hope this helps,
Again thanks for the replies!
As i am somewhat pressed for time and have limited experience of both LabVIEW and TestStand i think that creating a new GUI to use UI messages is out of the question.
The popup of a VI from a sequence file was straight forward and it seems that this could indeed be used for what i want.
Could the call and popup of a VI to show it's front panel to bind variables/write files etc. be done from a button on the TestStand GUI? I think that this would be a bit more intuitive for the user, while also not requiring the opening of a VI in the sequence files.
From what i have seen after searching most solutions is to open a VI in the sequence file as you suggested here.
Which UI are you using? If you use the full-featured UI I have a hack that makes it so you don't need to edit the UI. Consider the example attached. It contains a client with a callback. It also contains a process model with a new configuration entry point which calls the callback. This way your client can be invoked from the Configure menu on the full-featured UI.
Open the client file and click on Configure>>Bench Settings.
NOTE: you will have to edit the process model.
Let me know if you have questions.
I have reconsidered a bit.
Not sure if i should continue this line of questioning in this thread.
I am now thinking that i will create my own simple LabVIEW GUI for the test system, as i do not really need many of the features in the included User Interfaces that came with TestStand.
I am hoping that this will enable only having to work in one window throughout the configuration and execution of tests.
So, i want the user to be able to choose (in the LabVIEW GUI) what hardware that should be included in the tests, running diagnostics on the hardware would also be done via the LabVIEW GUI. The user can select what sequence to run and i want to send the selected COM-ports to TestStand as parameters.
The idea is that while TestStand is executing tests, it will only indicate to the LabVIEW GUI that the sequence is running, as well as reporting errors and/or tests that might have failed.
So what i want is to both be able to send parameters from LabVIEW to TestStand as well as sending them from TestStand to the LabVIEW GUI.
I have found examples of how to run sequence files from LabVIEW. I have included a code snippet below.
For the task of sending and receiving parameters to and from TestStand, would using UI messages be a good solution here? Or is there an easier/better way?
Do you think that this overall would be a good and simple solution to what i want to accomplish?
On second thought, would using UI messages even work here? Since i would not be using a TestStand UI...
Maybe the sequenceArgsParam could be used for what i want?
I do not recommend having LabVIEW run TestStand without making it a UI. Using the manager controls gives you so much flexibility and control and scalability. A TestStand UI can be as simple as an Execute button. Or you can even use native LV controls and just link them to TestStand commands.
Moving data back and forth via UI messages is quite simple.
Consider this: On your LabVIEW UI you could have a configure button. It could pop up a dialog and that dialog could save data off to a file. Then in your sequence file you could read in that data. OR it doesn't even need to pop up a dialog. They could just click a button that commits it to disk. The reason putting it on disk would be important is because it will persist the data from run to run. Unless that isn't important to you. Then just use UI messages.