LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Make test operation more upgradeable

I would like to get some input on what is the best way to code this up.
 
Here is the scenario: this is going to be hard to explain
 
I have a user interface that works with teststand and that has been working great for about a couple of months now. Now I want to add more test options to the UI in LV. I thought during the process a couple of months ago that I had made this easy to do, now that I have came back to it I found that is not to be true.
 
I have acontrol on the UI that allow the user to select which test to run the control is a cluster of booleans. the test are broken down into stages (all one control), they can do the tests in stage 1 or stage 2 but not both at the same time, but the array that is input to teststand is an array of all the test combined (using cluster to array). I have a couple of small subvi's that take care of disabling the controls and hiding them as needed. The problem lies is that I have to go to many different places just to add a test.
 
Specs:
 
Array output to TS is an array of booleans with 56 elements.
UI must be generic enough to use for multiple board types (not all of the boards have the tests in the same order).
I must have a way to enable all and disable all test according to stage selection. Here is a screen sho of My FP You can see the cluster for the test control. this is one big cluster with all of the test in it.
 
 
Like I said before this is kind of hard for me to explain because there is a lot going on. I will accept any and all Ideas. I had even thought about using different Xcontrols for each of the different types of boards, but that idea has not worked out so well.
 
I will greatly appreciate any and all suggestions and examples. I know somebody has had to do this in the past.
 
 


Message Edited by Jhoskins on 02-22-2008 12:33 PM

Message Edited by Jhoskins on 02-22-2008 12:33 PM



Joe.
"NOTHING IS EVER EASY"
Message 1 of 12
(2,757 Views)

i had a related problem, but not totally similar.

a set of possible tests to be done, in specific order.

1) choose all the tests, in the order you want, from radio buttons. the order of clicking will define the order of the tests.

2) all the test are now displayed in a different screen, using a table, where one can drag and change the order of the tests.

3) in the UI loop, there is a record at every stage of the present test, the next one and the last one to be performed. a 'back' button allows to come back to the table screen. activating the button induce recording of important elements for plausible future tests.

4)the list screen with the table also allows you to jump a test, redo a test, or go to any test, just by double clicking the relevent element in the test. here, some care is required in order to keep trac of relevent information for each step. that is why in the state machine loop, i always have a 'init' step for every test, independant of previous test. it takes into account if previous necessary test has been or not performed.

the tric for all that was recording the 'next' test and 'back' info. hope this help.

.

 

-----------------------------------------------------------------------------------------------------
... And here's where I keep assorted lengths of wires...
0 Kudos
Message 2 of 12
(2,748 Views)
If you want expandability, using fixed controls for each test will kill you.  It may look prettier, but you are stuck with the hard design.  Add a new test, you have to modify the GUI, etc. (which it sounds like you are seeing now).

If you use arrays or listboxes, you can add items without having to even recompile your UI.  I personally prefer listboxes, but either should work.

For an array:  you can have an array of booleans and an array of strings for the tests, or an array of clusters with a boolean and a string.  This can give you a similar look to what you already have.  Just make sure you have scrollbars visible in case it doesn't fit.

For a listbox:  You create the item list and use symbols to indicate checked tests or, if your user can handle it, the user can use the CTRL and SHIFT keys to select the tests to perform.

With either, your tests can be stored in INI files by product.  If you need to add a new test, you include it in your INI file.  I would probably put a list of all tests, then for each product, a list of test numbers.  This way if you add a new test and have to increase to 57 booleans to TS, you add the test to your list, your LabVIEW code knows it needs to create 57 booleans.  The test numbers in the INi file server as index numebrs to set the values in the array.


Message Edited by Matthew Kelton on 02-22-2008 11:53 AM
0 Kudos
Message 3 of 12
(2,745 Views)

Thanks for the Info Gabi1, I have to keep this all on one screen and as simple as possible because there is no telling who may end up using the test fixture. I will keep this in mind though.

 

Thanks




Joe.
"NOTHING IS EVER EASY"
0 Kudos
Message 4 of 12
(2,743 Views)

Matthew,

You nailed exactly what I want to do. Is there any way thatyou could put together an example for me. I tried to do it a long time with a list box but I could not get it to work without having to doble click on each to get a change in the symbol that I was using to indicate whether or not a test was to be performed. I love the list box Idea.

Another advantage I would have in using a multi column listbox is that I could include the pass fail information next to the test. I am doing that now but with another custom control that I have to manage and deal with everytime I wanted to add a test.

Please show me or direct me to an example of this.

 

Thanks,



Message Edited by Jhoskins on 02-22-2008 01:02 PM



Joe.
"NOTHING IS EVER EASY"
0 Kudos
Message 5 of 12
(2,738 Views)
Here is a quick and dirty to demonstrate (no INI interaction).
Message 6 of 12
(2,732 Views)

I love this, I am going to play around with this a bit.

here are my thoughts.

  1. Have an INI file for each board that consists of the test that are to be run and the stage that the test is be run in and the test #.
  2. Read the INI at the beginning of the UI (it is already called from a main UI) and populate the list.
  3. Have the list to come up and only make the stage 1 test visible and all of them enabled (this is in a spec doc)
  4. Then if the user does not want to change anything then they can hit the run button. If they do then I can just handle it in an event.

Matt how would this work with a multicolumn listbox,

This is great stuff,

 




Joe.
"NOTHING IS EVER EASY"
0 Kudos
Message 7 of 12
(2,722 Views)
You should be able to replace the listbox I have with a multicolumn and it should run with no issues.
Message 8 of 12
(2,718 Views)
The only down side that I can see is that you have to click on another row and then come back to the row if you want to deselect it. The functionality I would like to have is if you click on a row it should change and even if the row is still selected and it is clicked on again then it should change. The functionality should mimick a boolean check box whehter or not the row is highlighted. Any ideas on that.



Joe.
"NOTHING IS EVER EASY"
0 Kudos
Message 9 of 12
(2,715 Views)
Use the Mouse Up Instead of Value Change Event.
Message 10 of 12
(2,706 Views)