How can I make controls save their state when the project is closed?

[pjr1121]

Excecution follows the dataflow of wires, as such it is advised to always wire error in/out and such to enforce flow when available.  That said, it is not always  possible to do so, say you are using a wait timer.  In these cases you can use sequences but you should try to use them as little as possible. 

Sequence structures can be further avoided by using architecture designs (such as state machine or producer/consumer)

[DroidFreak]

"You can force data flow by not allowing a subVI to execute because it requres an input from an output of another subVI.  This way you will know that the second subVI will not start execution until after the first completes."

Ok, that somewhat makes sense, but why shouldn't I use sequence structures? They're a whole lot more intuitive and make your code easier to understand. The only problem would be if NI coded them terribly inefficiently, which would be typical of graphical languages.

EDIT: I'd also like to point out that I don't really care if sequence structures are inefficient, I just want to be told how exactly to write to controls and how to read and write INI files.

[nathand]

---

DroidFreak wrote:

Ok, that somewhat makes sense, but why shouldn't I use sequence structures? They're a whole lot more intuitive and make your code easier to understand. The only problem would be if NI coded them terribly inefficiently, which would be typical of graphical languages.

---

It's a bit like saying "Why shouldn't I use goto in my C programs?"

LabVIEW is all about data flow. Functions and structures execute when data is available on all their inputs. The compiler optimizes for this. It can automatically schedule functions to run in parallel, and set execution order based on when data is available. If you enforce a specific order using a sequence structure, it is you who is writing inefficent code by preventing the compiler from doing its job. If you upload your code, we can provide specific suggestions on how to improve it.

Aren't you jumping to a lot of conclusions about LabVIEW for someone who apparently hasn't been using it for very long? Yes, there's a learning curve, and being stuck in programming in a different programming environment makes that learning curve worse. But that doesn't make the LabVIEW approach wrong, inefficient, or counterintuitive. Your "intuition" is really just your idea that other programming environments should look like the one you're used to using. LabVIEW is intuitive to someone with no prior programming experience (I know - I teach high school students to program robots in it). Consider instead that learning a different style of programming will make you a better programmer in any language. Have you ever tried programming in a functional language (Haskell, ML, etc), or a logic programming language (like Prolog)? It can be just as frustrating and difficult and the fact that it's text-based doesn't help.

[DroidFreak]

The reason you shouldn't use goto is becuase it's confusing, it's actually quite efficient in terms of operation. Your anology is backwards. Spagetti code in C is like wiring error wires everywhere to control execution, using a sequence structure is like well-structured C code. And the reason why I'm using them is because I DON'T want things to run in paralel. I want it to load the calibration values, run the main loop, and save the calibration values IN THAT ORDER. If it's loading or saving it's calibration values while it's running the main loop that's a problem.

[billko]

---

@DroidFreak wrote:

The reason you shouldn't use goto is becuase it's confusing, it's actually quite efficient in terms of operation. Your anology is backwards. Spagetti code in C is like wiring error wires everywhere to control execution, using a sequence structure is like well-structured C code. And the reason why I'm using them is because I DON'T want things to run in paralel. I want it to load the calibration values, run the main loop, and save the calibration values IN THAT ORDER. If it's loading or saving it's calibration values while it's running the main loop that's a problem.

---

Actually, everyone is right.

LabVIEW was designed specifically to be easily translated from a state diagram, while text-based programs work best with a flowchart.  If you think about the two different environments in that way, you see that each is both logical and predictable.

[nathand]

---

DroidFreak wrote:

EDIT: I'd also like to point out that I don't really care if sequence structures are inefficient, I just want to be told how exactly to write to controls and how to read and write INI files.

---

The INI functions are well documented in the help. They are under the File I/O palette, Configuration File VIs. To write to a control, the simplest approach is a local variable. You can create one by right-clicking on the control's terminal (on the block diagram) and choosing Create->Local Variable. For a small number of controls, it is manageable to explicitly read each value individually and write it to a local variable on startup, and do the inverse when the code stops. For a larger number of controls, you'll want an automated solution like the ones previously mentioned in this thread.

Here is a minimalist example of opening a configuration file, reading one value from it, writing that value to a local variable, allowing the user to edit the value, and then writing the new value back to the file when the user pushes the stop button.

(note: not attached as a snippet because it turned the local variable into a reference, and I don't have the code capture tool installed)

[DroidFreak]

By the way, I just figured out how to set the value of a control. Now how do I save and load numbers and strings from a INI file?

[nathand]

---

@DroidFreak wrote:

Spagetti code in C is like wiring error wires everywhere to control execution, using a sequence structure is like well-structured C code.

---

No. Properly-structured LabVIEW code uses wires to control execution order cleanly without introducing unnecessary dependencies.

[apok]

I was told once that my block diagram looks "constipated', but here's my solution....creates, opens, initializes,reads, writes file

[tst]

---

@DroidFreak wrote:

That looks simple, but you're forgetting the fact that LabView has hundreds of modules and I have absolutely no idea how to find those particular modules just by seeing a picture of them.

---

You're right, which is why I included a link where you can download the actual code. I will ignore the rest of the discussion about intuitiveness, best practices and the like and will just say the following points, which will hopefully be helpful:

1. LV has an example finder (Help>>Find Examples) which has many examples. I would suggest that as a first step for everything. The example are NOT always good, but they usually do show the functionality. Likewise, there are many examples online.
2. The context help window (Ctrl+H) is invaluable. It will show you the exact details of the function you're hovering over. Learn to love it.
3. LV has a small number of main palettes which are divided by topic in a way that generally makes sense. I would suggest looking through them and familiarizing yourself with the main categories.
4. Code which is good in C is not necessarily good in LV. The paradigms are simply different. For instance, LV doesn't really have variables and wires generally fill the functionality variables have in C. Obviously, such an idea is completely foreign to someone who just converts from C, so it takes a while to get used to. If you will use the unfortunately named local variables as you would use variables in C, your code will work, but you will probably create race conditions because of the parallel nature of LV.
5. I would suggest going through some tutorials or books, that's the best thing. You could try some of these tutorials or you could try NI's courses (I have no idea what either are like, but you could try contacting your local NI office to see if you could get a free course). I know that LV for everyone is a recommended book, but I have no idea what that's like. I know that the authors certainly know their stuff.