Internal Variables

[Kura]

I've been writing a lot of programs lately and have been having to create lots of worthless front panel indicators just to generate internal variables that the user will never need to see. Is there some other way to create variables that will only be used within the program code itself and that are -NOT- associated with anything on the front panel?

[Dennis_Knutson]

The equivalent to variables in text based languages is the wire in LabVIEW. There is seldom any reason to create a dummy indicator with a properly written program. I'm assuming that when you create the dummy indicator, you then create a local variable of it to pass it's value to some other location in the program. As I said, the best way to do this is with a wire. Local variables create copies of the data and can result in race conditions. Besides wire, there are other ways to pass data, i.e. shift registers and queues. If you would post an example of one of your programs, I'm sure someone here on the forum could provide help in redesigning your architecure.

[LesHammer]

The problem with wires is that in big programs you can get a jumbled mess - many wires tangled throughout the program. One attempt to overcome this is to use the dummy indicator and property node (value). I'm assuming the cleaner solution is to create a cluster (with all the initial values), pass it around (on just one wire - avoiding clutter) and use the cluster widgets to get and set values. Correct?

Les

[Kura]

Well, the problem I'm having is that each time the program is run it saves a file for example test1.dat Now the way I see it, the easiest way to make the next file saved be titled "test2.dat" would be to have a variable that increments by one each time the user runs the program. It just seems to me like it would be immeasurably simpler to have an internal variable do this than some complicated architecture to accomplish the same goal.

[Dennis_Knutson]

A single shift register that holds the path is not any more complicated than some unused terminals and local variablesand is vastly more effecient for LabVIEW to handle. If your're creating the files inside a while loop, you don't even need that - see the attachment. I am simply pointing out the most preferred way. What looks simpler on the diagram (using locals instead of wires) is not simpler for the LabVIEW compiler and the dataflow paradigm that it is based on. The performance hit that you are taking with your approach might be insignificant in this application but you're eventually going to write something where it will and you'll be posting a question about why your app is using so much memory.

[Enrique]

You can always check the directory to check for the last file. Generating a new name for the file is then easy. Check the attachment.

[Enrique]

I don't know what I was thinking in my previous comment. The attached VI does it better.

[Dennis_Knutson]

Hi Les,

Since I almost always use a state machine, event structure, or a combination, that is exactly what I do - create a cluster with all of the elements I need to pass between different states and then use bundle/unbundle by name.