How to obtain which element changed in a clusters using events?

[billko]

---

@Ben wrote:

While all of the above are sound there is another option.

Register different events for each of the things in the cluster.

Let LV detect the change so when the event for the contained item changes we know exactly what needs to be done and no reverse engineering required.

Ben

---

Do you mean to get a reference for each control in the cluster and register an event for each one(s) you care about?

[Ben]

---

@billko wrote:

---

@Ben wrote:

While all of the above are sound there is another option.

Register different events for each of the things in the cluster.

Let LV detect the change so when the event for the contained item changes we know exactly what needs to be done and no reverse engineering required.

Ben

---

Do you mean to get a reference for each control in the cluster and register an event for each one(s) you care about?

---

Yes if you are doing dynamic event registration but as a simple example we can create an event from the Event Config screen.

Ben

[billko]

---

@Ben wrote:

---

@billko wrote:

---

@Ben wrote:

While all of the above are sound there is another option.

Register different events for each of the things in the cluster.

Let LV detect the change so when the event for the contained item changes we know exactly what needs to be done and no reverse engineering required.

Ben

---

Do you mean to get a reference for each control in the cluster and register an event for each one(s) you care about?

---

Yes if you are doing dynamic event registration but as a simple example we can create an event from the Event Config screen.

Ben

---

Oh, right.  It's been so long since I actually operated on a control directly, I forgot you can do that.  *blush*

[Basjong53]

---

@Ben wrote:

While all of the above are sound there is another option.

Register different events for each of the things in the cluster.

Let LV detect the change so when the event for the contained item changes we know exactly what needs to be done and no reverse engineering required.

Ben

---

This is exactly what I already have. See my topic start and the attached vi. The whole reason I opened this topic is to find if there is another way that is more dynamic and scalable.

[wiebe@CARYA · Accepted solution]

You can register the elements (recursively) in the cluster dynamically. That would make it dynamic and scalable:

[Basjong53]

---

wiebe@CARYA wrote:

You can register the elements (recursively) in the cluster dynamically. That would make it dynamic and scalable:

---

This looks like an elegant solution. However your vi freezes after 2 event triggers on my machine. LabVIEW 2018 32bit.

[wiebe@CARYA]

---

@Basjong53 wrote:

---

wiebe@CARYA wrote:

You can register the elements (recursively) in the cluster dynamically. That would make it dynamic and scalable:

---

This looks like an elegant solution. However your vi freezes after 2 event triggers on my machine. LabVIEW 2018 32bit.

---

The event structure need to be in a while loop... The post is just a quick muck-up.

[Basjong53]

---

wiebe@CARYA wrote:

---

@Basjong53 wrote:

---

wiebe@CARYA wrote:

You can register the elements (recursively) in the cluster dynamically. That would make it dynamic and scalable:

---

This looks like an elegant solution. However your vi freezes after 2 event triggers on my machine. LabVIEW 2018 32bit.

---

The event structure need to be in a while loop... The post is just a quick muck-up.

---

Of course I put the code inside a while loop. After fiddling around a little I discovered that inserting the Reg Events node inside the while loop causes it to freeze. Placing it outside solves it. Thanks for this code!

[wiebe@CARYA]

You should be able to unregister, re-register inside the event structure. That can be convenient to enable\disable functionality.

Haven't tried inside the loop, as it doesn't seem too useful. Not sure why that would hang. If it's consistent, it could be a bug. Unregistering each iteration might help...

[Ben]

This Nugget by Ton talks about dynamic event registration and is where I first learned how to use them.

I have used dynamic event registration in a loop to reduce distractions... I should explain a bit I suppose.

Say I have 200 RT targets I am watching and controlling from a single "master".

I use UDP broadcast messages to discover the RT units and then I have to let dedicated background VI open TCP connections to work with each RT system. So I need a method to let each dynamically created monitoring loop that the RT system they are looking for has been discovered.

So the UDP code uses a User Event to let all of the monitoring loops about the newly discovered RT system. The Monitoring loops use dynamic event registration to listen for an event letting them know about the RT system. Nothing earthshaking I know.

But once a monitoring loop has made a connection to the RT system it wants to talk to, it unregisters for the User Event as long as it has a valid TCP connection. Once connected it does not care about any other discoveries.

Now if a TCP connection fails, the monitoring loop re-registers again for the User Event so it can reconnect when the RT system comes back on-line.

Why bother with that?

If I have 200 RT systems all advertising themselves once every couple of seconds, that would be a lot of wasted CPU cycles to service the User Events and then decide to ignore it because it is already connected.

Now regarding the lock-up...

Yes unregistering may be the ticket but the other trivia not mentioned yet is if we right-click the event registration terminal, we find the option "lock FP" is true by default.

Ben