Is there any quick shortcut to create property nodes?

[thoult]

Another useful data structure is the notifier. Easy to set up, and helpful for use in broadcasting updates to multiple processes.

There's usually a valid use case for almost any of these structures somewhere within applications 🙂

[Vaibhav]

Aha,

Thanks Lynn for that explanation.

In fact, I always thought of having some normal variable which is not linked to any front panel object (like we have in other programming languages and always thought that in LabVIEW that's not possible. I use Queues, but never looked at them as a self containing single value variables (something I always wanted). So I end up creating unnecessary indicators and then hide them, just for the sake of having a counter or things like that.

Thanks for throwing that light to SEQ. When I had first read the help on Queues, I saw that limited value description, but that didn't blink in my mind to use them as variables.

Yes, I know notifiers, but for now, I never used them. Because if my loops have queues and the case structure inside the loop is controlled by one queue structure, I think the notifier's notifications will shout to deaf ears.

@thoult

You are right about the quick drop, but as you said also, there will be the steps to link it to the property. So again, it will not be that big a difference. And no, at the moment I won't be creating that many property nodes or local variables that would justify investing efforts to create my own Quick Drop.

[jcarmody]

---

@Vaibhav wrote:

[...] So I end up creating unnecessary indicators and then hide them, [...] 

---

At the risk of offering something you don't need, I'll say that you can always avoid doing that.  I've done that, too, but not for a long time.

[Vaibhav]

---

@jcarmody wrote:

At the risk of offering something you don't need, I'll say that you can always avoid doing that.  I've done that, too, but not for a long time.

---

I am always open to learning. So no risk involved. 🙂  In the worst case, you may end up earning Kudos. 😉

Please tell me how do you avoid? We talked about Single Element Queue above. Or do you use something different?

[jcarmody]

One method is to pass a cluster through your State Machine and update it every time through the loop (as shown below).  This could get expensive if you have a lot going on, though.  I often use the JKI State Machine, still using the same kind of cluster, and have UI states which I call whenever I need to update a particular indicator.  Any update to a control is handled by an event structure updating the appropriate cluster element.  Any state can get the data it needs from the cluster wire rather than using a local/value directly from a control.

[Vaibhav]

Thanks Jim,

That's a nice way to take care of all the three data types. So as I understood, you are saying to pass a relevant value in the cluster and in the next expected event, read that part of the cluster.

But isn't there a kind of a gamble? Because I may write something in the cluster, but before I read it, the user may have clicked something more and with a coincidence, that particular value might be changed (becuase I changed it for that event), before actually reading it, something that is taken care of in the Queue.

I have never used the JKI State Machine. I have it installed, but didn't open it. Started making it as my old structure, because of urgent work. But once I finish, I will go through the tutorials and see if that's a better implementation technique. What difference does the JKI State Machine make over your attached State Machine? Just curious to learn quickly. I know I should better go through the tutorials to understand, but I am in the middle of work and want to evaluate quickly.

Edit: I think you are reading directly from the cluster because of the single loop. If there are two loops, as in the producer-consumer, you would also use a Queue to pass data of that cluster from one loop to the other, right? (this is the answer to my first paragraph question, unless you have a different answer). So basically it's just one more queue. Right now I am using queue to pass the states. Now I will add one more queue for this cluster "messenger".

[Darren · Accepted solution]

This is a custom Quick Drop shortcut that can automatically create property nodes, references, etc., for front panel objects:

https://decibel.ni.com/content/docs/DOC-7445

[Vaibhav]

Thanks Darren,

That works like a charm. Wonderful!

Thanks for sharing it.

[Vaibhav]

---

@Neos wrote:

I am trying to avoid local variables, and instead using property nodes, because they are supposed to be better in terms of performance

---

and how do you know that.

---

Although the original question of this thread is answered, for the sake of discussion on some points of confusion that arose in the beginning of the thread, I am posting this message.

What made me think of value property nodes being better than local variables is actually the dichotomy like this.

Local variables are faster because they don't refer to UI, as opposed to the value property nodes. But, local variables create a copy of the data each time they are accessed. And this can be a performance killer especially when you are dealing with large arrays (like I am using arrays with index upto 3 millions or more). Of course, now I am more inclined towards variant to handle such large data, thanks to this.

Just thought to point this out because I came across that first post by Norbert. Because this question always stayed at the back of my mind. Now I have a good answer. Kudo!