Select Physical Channels From Front Panel

[Wolleee]

Here is the .vi I am currently working with.  When i built an .exe with it, the .exe file was also unable to scroll.  I dont know if there is a property node somewhere that i am missing.

[Hooovahh]

I only have 2011 SP1 to test with but it scrolls as expected, front panel and tables.  When the VI is running or not.

I'm sure you know this but your code could be improved.  Why do you need two loops when they both react to UI events.  Just have one event structure in one while loop.  

Remove the Use Channels button and replace the event with the Start button.

You can redesign the UI to fit everything on one screen so you don't need to worry about scrolling.  An easy solution is to use tabs and organize controls into similar groups.

Handle errors like the user canceling the browse button.  Stop if an error is detected.

Give the user a way to cancel a test in progress.  Right now the only way to stop is to wait the Duration of Test.

[johnsold]

Once you have clicked the Use Channels button, the event case will lock the front panel until the code inside that case completes execution. With the default setting of Duration of Test = 20, it will take 20 minutes before anything on the front panel works again.

This is why you should never place any code which takes more than a few milliseconds to execute inside an event structure.

Look at the Producer/Consumer Design Pattern/Template. I think it was available in LV 2010. Regardless, you need a parallel loop architecture for a program like this.

Lynn

[Wolleee]

Thank you for the advice.  I am still relatively new to labview.  I will give those a try.  Im really just trying to get it work before i optimize haha. Even if i decrease the size of the front panel, the user cannot use the tabs after the test begins and i would really like the user to be able to monitor the data.

[Hooovahh]

---

@matt198717 wrote:

Even if i decrease the size of the front panel, the user cannot use the tabs after the test begins and i would really like the user to be able to monitor the data.

---

This goes back to what John just said about events.  You basically coded it so the UI would lock up until the test ends.  I don't think that is what you want.

[Wolleee]

Lynn,

What would you happen to have an example of this?

[Hooovahh]

---

@matt198717 wrote:

Lynn,

What would you happen to have an example of this?

---

File New... (not new VI) go the VI >> From Template >> Frameworks Design Patterns >> Producer/ Consumer.

Also Help >> Example finder and search.

[Wolleee]

No it isnt at all haha.  I will take a look at that and see if i can solve it.

THank you for all your help

[Wolleee]

I will take a look at this.

Thank you for your help

[johnsold]

Hooovahh showed where it is located. I checked to make sure that it is present in LV 2010.

You are in a situation where we are not talking about getting it working and then optimizing. You have fundamental structural problems with your program which will keep from ever working without a lot of awkward code.  I predict that it will be faster for you to learn how to use the Producer/Consumer Design Pattern than to continue "tweaking" your existing VI.

I also recommend that you spend some time with pencil and paper defining exactly what the program needs to do under various conditions.  Consider it from the point of view of the user. What does the user need to do first? What is the user prohibited from doing until that first task is completed? How will the user stop the program? How will errors be handled? The answers to these questions can guide the design of the front panel so that only relevant controls and indicators are visible at any given time. For example the graphs/charts do not need to be visible before the chassis is selected and reserved.

Also consider the program requirements from the point of view of the data. Selection and initialization of DAQ equipment. Acquisition of data. Analysis of data. Display of data. Saving data. Shutdown of DAQ equipment. DAQ errors. Analysis errors. File errors.

When you have all the requirements written down, then you should start working on the code to implement them. Write subVIs to perform separate tasks and test each one as you go.

Lynn