Triggering a user event in one subVI from another subVI

[msad66]

Hi,

One of the useful feature in the “obtain queue.vi” is that the function first searches for the queue and if it does not exist then create a new:

“If you wire name, the function searches for an existing queue with the same name and returns a new reference to the existing queue. If a queue with the same name does not already exist and create if not found? is TRUE, the function creates a new, named queue reference.”

This feature helps us to communicate through several subVIs without a lots of wiring.

Unlike “obtain queue.vi”, the “create user event.vi” must called once for each event. For example if I want to trigger a user event in one subVI from another subVI, I must define the event in the main VI and wire the “user event out” to the both subVIs:

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

It is ok in small software but what about the big applications with lots of user defined event in so many subVIs? Does the main VI in these applications contain all of create user event VIs?

I am looking for a standard style to trigger a certain dynamic event in several subVIs.

Thanks.

[Blokk · Accepted solution]

Usually what I do is to keep all User Event references in my MAIN vi. If I have multiple references, I just bundle them up using a typedef, and even better in this case you can register ALL your events using a single register node:

In the above example I also use a FGV to store the cluster holding all references, in this way I can register for all or any of the events from any subVI. But of course you can skip this part, and just use the wire through your main vi. I also atttach an example in zip, it also shows some dynamic subVI call and how you can use User Events for intercommuncation between a running subVI and the main vi.

[stevem181]

I think that Blokk and I are kindred spirits when it comes to User Events.

A couple of notes:

1. Use data flow to ensure that you can’t do a “Get” operation on the FGV before the “Set” operation has been performed
2. Only register for Events that you need to respond to
3. I always build in a FGV but don't use it much since most top level vis are wired

[msad66]

Thanks Blokk.

So the only way is to use a FGV to store the user events and use them in subVIs.

Since each user events is similar a state in queues and there exist a state machine style based on user events instead of the queues, I am still wandering why LabVIEW does not search for the user event based on the user event name just like the queues. In this case all these FGV VIs and the wiring are omitted and we can define and register for all the user events wherever we want (just like queues).

[msad66]

Thanks stevem181

Good notes and very clean block diagram. 

[Blokk]

---

@msad66 wrote:

Thanks Blokk.

So the only way is to use a FGV to store the user events and use them in subVIs.

Since each user events is similar a state in queues and there exist a state machine style based on user events instead of the queues, I am still wandering why LabVIEW does not search for the user event based on the user event name just like the queues. In this case all these FGV VIs and the wiring are omitted and we can define and register for all the user events wherever we want (just like queues).

---

It is the same level of effort (ok, you need to create an FGV, but it is 2 minutes). If you use Queues, you need to use the "Obtain Queue" function. In the case of User Events you use your FGV. Same number of elements.

[msad66]

---

It is the same level of effort (ok, you need to create an FGV, but it is 2 minutes). If you use Queues, you need to use the "Obtain Queue" function. In the case of User Events you use your FGV. Same number of elements.

---

You are right Blokk. I implemented your method and it was easy with the same effort.

Quick question:

Since it is the first time I use a FGV practically, I am wondering where else do you use FGVs? Do you use FGV for queues too?

[Blokk]

Depends on the requirements. You can read more about FGVs and other useful techniques here:

http://forums.ni.com/t5/LabVIEW/Community-Nugget-4-08-2007-Action-Engines/td-p/503801

[billko]

---

@msad66 wrote:

---

It is the same level of effort (ok, you need to create an FGV, but it is 2 minutes). If you use Queues, you need to use the "Obtain Queue" function. In the case of User Events you use your FGV. Same number of elements.

---

You are right Blokk. I implemented your method and it was easy with the same effort.

Quick question:

Since it is the first time I use a FGV practically, I am wondering where else do you use FGVs? Do you use FGV for queues too?

---

I do.  That way I can get them very easily anywhere I want.  You can even use them to carry around your control references so you can access front panel controls and indicator properties from anywhere, too.

[crossrulz]

---

@billko wrote:

---

@msad66 wrote:

---

It is the same level of effort (ok, you need to create an FGV, but it is 2 minutes). If you use Queues, you need to use the "Obtain Queue" function. In the case of User Events you use your FGV. Same number of elements.

---

You are right Blokk. I implemented your method and it was easy with the same effort.

Quick question:

Since it is the first time I use a FGV practically, I am wondering where else do you use FGVs? Do you use FGV for queues too?

---

I do.  That way I can get them very easily anywhere I want.

---

Just a warning for when using an Action Engine for queues.  I have a library for these that have a Initialize, Send, and Close actions.  Only VI that actually reads the queue should initialize or close it.  It is best to use a LabVIEW Library and set the AE to be private and then have another VI that calls the AE so that other processes can send/write to the the queue.  This abstracts the queue from the other processes and makes sure that nobody actually touches it except for the process that reads the queue.