Changing cluster values on the fly

[David99999]

I apologize in advance, I have no VI's to share with you because my test VIs are not even close. They would just give you a headache.

I have a bunch of clusters that are configuration settings. They initially get read in as they are from a config file, but I would like the user to be able to change them when they want. It sounds so simple when I write it out like that, but I'm getting really confused on how to handle cluster indicators and controls either in the same loop or between separate loops. I think what's throwing me off is that I have 2 separate entities here, a cluster indicator and a cluster control.

So, values are read from a config file into a cluster indicator. User sees indicator. If they want to, user presses button and opens a new window that allows them to change the settings. When user presses "send" or "Ok" button on new window, the new settings are transferred from that window/VI back to the original VI where the indicator is updated and from there they are sent off to be written to the config file.

For some reason I cannot figure out how to do this. 

[David99999]

I also should mention that I don't want the main loop to stop. So I'm assuming it would be in separate loop where this manipulation happens

[GerdW]

Hi David,

you just place the data for those cluster indicators in a shift register of your main VI/statemachine loop.

Then your subVI to edit the cluster data gets an input with the current data and outputs the edited data: THINK DATAFLOW…

---

@David99999 wrote:

I apologize in advance, I have no VI's to share with you because my test VIs are not even close.

---

I apologize too: because you didn't supply an example VI I have no VI to start from…

[altenbach]

Yes, these cluster values simply need to go in a shift register. The indicator belongs after the left shift register and before that case or event structure. They you have events for init, modifiy, save, etc. and each would operate on the values of the cluster which then will be written back to the indicator.

Alternatively, you could make the cluster a control so the user can modify the values directly. rest of the architecture would stay the same except that you now would have a "cluster: value change" event that would write the new value back to the shift register. The init state would update the cluster via a local variable, for example.

[David99999]

Ok, thanks guys. I'm tracking both of you.

But what if I've got a graph that is taking in values and I don't want it to stop? Like this

I mean, I guess I could bring the cluster down into the while loop with the event structure, but lets pretend there is a tcp connection in the top loop. I would need to get that new cluster data to top loop to be transferred back to the tcp server

[David99999]

I think I'm on to something here 🤔

MAIN VI

SUBVI

[altenbach]

I very strongly recommend to use unique names when attaching VIs. For example, my downloads folder already has a "subvi 2.vi", so yours got renamed by the browser to "subVI 2 (1).vi" and the caller will load with the wrong subVI.

Even better would be to zip your two VI so they will be together in a new folder and collisions are less likely.

[David99999]

Woops, sorry!

Ok I think I'm getting closer

MAIN VI

SUBVI (I imagine this one should also be using an event structure)

[Yamaeda]

That Button Value change is the same as just dropping the subvi in place plus some Rube Goldberg.

[altenbach]

Please do NOT maximize diagram and front panel to the screen. You cannot work efficiently of you only see one at a time. You can't even show the help window while editing, but that seems to be needed.

• Why do you call the subVI by static reference instead of just placing it on the diagram?
• Closing a static reference is a noop.
• You don't need a local variable in the subVI of you would use the correct mechanical action.
• Your subVI needs a small wait. no need to burn the CPU.
• Just wire the "done button" to the termination condition and make it latch action. None of that rube Goldberg Case structure needed.
• You might want to add a cancel button to return with the input unchanged.
• How exactly do you stop the main VI?
• ...