Create a Variable selector node

[1984]

I use single process shared variables quite often and I am always amazed how much space the take from the block diagram. As they requires room I either make long VIs or play with the wires. Not good...

The current situation:

So why dont we have something similar than what we have with property nodes, but applicable to the variables we have in the project? Each variable can be set to read or write, same as the properties of a UI element.

The proposed solution:

I dont have too much experience with locals and globals, but I guess this idea could be applicable for those as well.

[Norbert_B]

While i do share your opinion that single process variable elements are too big, the proposed solution is not what i find usable:

- You loose any information that these are single process variables (except maybe the {hidde} label of the node).

- What about error behaviour of the node? Currently, if a node generates an error, you can go on as you used your error cluster wiring. A single node would either stop execution and immediatly return the error or ignore ALL errors and continue execution of each variable access (top to bottom).

- It blurrs access to shared resources. It is already most times a nightmare of race conditions... it will only increase that issue.

So maybe you can come up with some other, better suggestion which addresses above mentioned concerns... but for now, no kudos. Sorry.

Norbert

[1984]

- I used the property node to create something similar to what I would like to see. NI easily can make a distinction by using a different color or adding a small icon as its done on the invoke method node.

- The Error cluster is not a concern. It should behave as it behaves on property nodes with multiple properties.

- I dont understand how would this increase the chance of a race condition. It is exactly as labview handles the properties, so if it is not a concern there, then why would it be a concern in this case.

[jcarmody]

You could work around the issue by making sub VIs.

[1984]

Oh my god... I can work around 90% of the problems by creating subVIs. [ Edited 07-30-2014 by moderator]

[Intaris]

@1984.

Any reason for the language?  Is that a positive of a negative expletive?

[1984]

90% of the problems can be resolved by subVis. I guess this forum is not about how to resolve problems with subVIs, but rather how to create new intuitive solutions for common problems without using subVIs. So was rather a negative one.

[jcarmody]

If existing functionality is simple to implement, do you really have a problem?

[1984]

Yes I have... 826 kudos, for an a functionality simple to implement.

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Wait-ms-with-error-pass-through/idi-p/1177437

[AristosQueue (NI)]

1984: It is about finding innovative solutions. But we never know when someone posts if they've thought of the existing solutions. Many ideas have ended with, "Wow, I never thought of that, yeah, that'll work great." So mentioning the existing options is generally a good idea. And mentioning the existing options gives us a baseline to judge just how much of an improvement a given feature request would provide.

As for the idea, I have some hesitations about what a unified node would imply about the timing of variable accesses. Would people be expecting any sort of atomic read/write locking for the duration of the node? Would people be hurt by the fact that the access to these variables is now performed serially instead of in parallel?

If the issue is just space on the diagram, I'd rather explore options that more directly address space on the diagram instead of ones that change the execution semantics.

[jcarmody]

1984 said: "Yes I have... 826 kudos, for an a functionality simple to implement."

That doesn't strengthen your position as it's not a problem.  It's just an inconvenience.