Local variables without Front Panel item

[JPrevost]

I'd like it if there were local's that didn't have a front panel item to hide. I use them infrequently but in large applications they seem to be the best way to sync parallel loops.

I also think there should be a way to label an indexed array item. There is no way to do this right now in 7.0, maybe in 7.1?

[crelf]

I'd like it if there were local's that didn't have a front panel item to hide. I use them infrequently but in large applications they seem to be the best way to sync parallel loops.

Isn't what you're after just a functional global? The whole idea of having a local is to access FP objects...

[orko]

I'd like it if there were local's that didn't have a front panel item to hide. I use them infrequently but in large applications they seem to be the best way to sync parallel loops.

I also think there should be a way to label an indexed array item. There is no way to do this right now in 7.0, maybe in 7.1?

Just to be clear, what do you mean exactly by "label an indexed array item"? It seems to me that arrays are indexed elements, and clusters are labeled controls. If you label 5 items in an indexed array and add a new element, what do you label the new one? What you may be after is an enum, or a ring?

Thanks for clarifying,

Joe (orko)

[JPrevost]

Isn't what you're after just a functional global? The whole idea of having a local is to access FP objects...

I thought FG were used to talk between vi's where as locals are used to talk within a single vi but multiple loops. I have no need to call the locals globally. Right now I'm using a local as a place holder. While data is being played back a slider is indicating the seek location of the file. When a user clicks on the slide I have it setup so it writes the new value to a local which is then called by a queue in the loop that does the file seeking. If that isn't clear I'll post images of the code.

As for naming a indexed array item I'm talking about giving that single element a name without wiring it to an indicator so that it can be clustered with a name. Again, if that isn't clear I'm sure it's my fault and I'll be more than happy to post an example.

Thanks for the replies so far and yes, I could use a FG but I thought they should be used when calling by seperate vi's... if it's more efficient than using a hidden FP object and queue then I'll do it . It would clear up the wiring diaghram.

[JPrevost]

Labeling an indexed array item... notice how it has no name is defaulted to "numeric" for every item. Only if I wire it to an indicator does it get a name .

[LAVA 1.0 Content]

Labeling an indexed array item... notice how it has no name is defaulted to "numeric" for every item. Only if I wire it to an indicator does it get a name .

I think I understan what you are asking, see attached VI. Create a constant on the middle node of the bundle by name, add what ever data tpes you want to the constant and lable them. Than wire what ever data you want into the cluster elements. I think maybe the problem is you are used to defining the name of your cluster elements by wireing a control to the elements and letting the cluster element name take on that of the control lable.

Download File:post-3882-1140044855.vi

[JPrevost]

I think I understan what you are asking, see attached VI. Create a constant on the middle node of the bundle by name, add what ever data tpes you want to the constant and lable them. Than wire what ever data you want into the cluster elements. I think maybe the problem is you are used to defining the name of your cluster elements by wireing a control to the elements and letting the cluster element name take on that of the control lable.

<-- version 7.0, not 8 but yes, I follow what you're saying. Last week was the first time I did what you just said with the cluster constant labeling. I'm thinking about using that for the configure part of of my program only I don't like the idea of having a configure.vi that requires passing a huge cluster to write but then when reading, having to read the WHOLE cluster (over 40 elements) just to read 1. This is why I'm still using local variables and sequence structuring to initially read the cfg file in, update the controls, then read them all over the program using local variables. Do you think I should use a seperate configure vi with a functional/LV2 global? These user configurables are read relatively often and relatively fast ~10 get read in different locations of the program >17Hz. It would really clean up the main vi if I did go to clustering and a seperate config vi but I don't want to do it if it'll hurt performance any (suporting slow ~400Mhz machines).

Thanks again for that reminder about labeling... I still wish it was easier to label wires. Like a right-click shortcut label feature :2cents: .

[LAVA 1.0 Content]

<-- version 7.0, not 8 but yes, I follow what you're saying. Last week was the first time I did what you just said with the cluster constant labeling. I'm thinking about using that for the configure part of of my program only I don't like the idea of having a configure.vi that requires passing a huge cluster to write but then when reading, having to read the WHOLE cluster (over 40 elements) just to read 1. This is why I'm still using local variables and sequence structuring to initially read the cfg file in, update the controls, then read them all over the program using local variables. Do you think I should use a seperate configure vi with a functional/LV2 global? These user configurables are read relatively often and relatively fast ~10 get read in different locations of the program >17Hz. It would really clean up the main vi if I did go to clustering and a seperate config vi but I don't want to do it if it'll hurt performance any (suporting slow ~400Mhz machines).

Thanks again for that reminder about labeling... I still wish it was easier to label wires. Like a right-click shortcut label feature :2cents: .

Sorry about that, here it is in 7.1. In my opinion there is nothing wrong with a subVI that reads in a config file and parses it to build a big bundle by name cluster to pass out. 40 elements in a cluster is not bad, you start taking performance hits with an array of clusters or even worse, an array of clusters with an array as one of the elements of the cluster.

Download File:post-3882-1140048702.vi

[JPrevost]

Sorry about that, here it is in 7.1. In my opinion there is nothing wrong with a subVI that reads in a config file and parses it to build a big bundle by name cluster to pass out. 40 elements in a cluster is not bad, you start taking performance hits with an array of clusters or even worse, an array of clusters with an array as one of the elements of the cluster.

Okay. I'll try it out. BTW, version 7.1 > 7.0 ... still can't open

[orko]

Okay. I'll try it out. BTW, version 7.1 > 7.0 ... still can't open

Here you go, hot off the press

Download File:post-3266-1140055304.vi

LV 7.0