saving files across multiple tabs within the same run

[prober28]

I originally thought this was a simple issue I was having, but I've spent quite a bit of time trying to fix it and I'm out of ideas.

 The goal is to be able to save across different tabs for a VI that controls an instrument, with each tab being a different mode of measurement. So, first I created a VI such that I was able to press a start/stop button and save a separate file for each press. I was able to do this without a problem. Then I tried to add this VI's functionality to a tab structure. The goal being that I could press a start/stop button and save a separate file for each press on any of the tabs (and over the course of the run use every tab). However, regardless of what I've tried I can't seem to be able to save on more than one tab at a time. The first tab of the run is functional, but then any subsequent tab is not.  I've tried chaning the loop structure and how I write the files, but nothing has worked. I've attached a VI that displays the problem without the [extreme] amount of extraneous information the original has. 

Any ideas? Thanks in advance.

[James.M · Accepted solution]

You can't expect to run through different tabs during one run without a loop around the code. LabVIEW programming is based entirely on dataflow and parallelism. This is incredibly powerful and has lead to its success over the years (coupled with the graphical programming), but is usually one of the first things that new developers stumble over. Here's a simple resource to become more familiar with how it works. The Highlight Execution feature is a great way to watch how your application utilizes dataflow.

You need to move your boolean control inside the event structure to register the value correctly and your code is going to lock up since you have multiple event structures separated within the tab cases.

You're not going to like hearing this, but the tab control is incredibly dangerous because you can very easily lock up your code. This mean, ideally, you only use the tab control for appearances or for sub-sections of your code that you want to operate differently depending on which tab is selected.

One of the first applications I made, which I was soooo proud of, had a tab control as the main container for the code inside. This worked great for a while, but I found I was duplicating a lot of code and then sometimes it would lock up, so I would have to throw some code together to put out one fire after the other.

Notice how your tab cases all look the same with minor differences based on the boolean and/or measurement type? This means if you make a change to one tab case, you will probably end up wanting to make that same change to all the other tabs, and now your workload is tripled for one change.

Look in to the Simple State Machine template that ships with LabVIEW. It is really the best way for new developers to get familiar with LabVIEW while utilizing a semi-scalable architecture.

Here's a broad example of how a state machine works:

• States: Init, Idle, Exit, DoThing1, DoThing2, DoThing3
• Each state contains code that might take some time. Ideally, not too long because that's how long your code could be unresponsive.
• The Idle state contains an event structure for all user interaction.
• The front panel has a button that says "Do Thing 1".

1. Loop Iteration 0: Application begins, first state is Init. The Init state does some initialization stuff and tells the application to go to the Idle state when finished.
2. Loop Iteration 1: Application goes to Idle state. It sits there, waiting at the event structure.
3. Time goes by, then user presses button "Do Thing 1". There is no code, or minimal code, within this event case. The output of this event state tells the application to go to the DoThing1 state.
4. Loop Iteration 3: Application goes to DoThing1 state. There is code here that does some stuff. The output of DoThing1 state tells the application to go back to the Idle state.
5. Loop Iteration 4: Application goes to Idle state where it waits at the event structure again.

• Each of the states can tell the application to go to any state they want. Want to reinitialize? Go to the Init state again. Want to end the program? Go to the Exit state. Want each state to trigger another (like a sequence)? Have DoThing1 output DoThing2, which outputs DoThing3,  which outputs Idle.

You can have a different state depending on the measurement types you use and that state selection can still be governed by the tab control.

[altenbach · Accepted solution]

Your code is completely inside-out.

• Use one outer loop and exactly one event structure.
• Most of the code does not even need to know what tab you are on. It is obvious from a button event which tab is currently visible. Share one event for all booleans .
• Your saving code differs only by one diagram constant, so the rest of the code can be shared in one event for all three buttons. Use the tab terminal to decide which diagram constant to use.
• Use an array with three elements in a shift regsiter and increment the appropriate element based on the tab state.

[altenbach · Accepted solution]

Here is a simple draft that should get you started. (Not tested)

[prober28]

Thank you! I didn't think of this approach, or even know it was an option.