Synchronous Messaging with User Events

[Hooovahh]

---

@mcduff wrote:

One key when doing this type of messaging is making sure all the loops and User Event Structures are up and running before sending any messages to them. (I found this bug in my program with the logger.) If they are not running, the message is lost. This is where the forums are extremely helpful. I modified a VI by Brian Hoover that gives a list of all of the VIs running Event loops. Before sending any messages, I check the names of the VIs with the Event loops to be sure that they are running.

---

Oh neat solution.  I've seen this issue in the past too, and I've solved it a few ways but no solution is ideal.  One option is to have a reply method in the user event, like a queue.  After the VI registers for the event, it waits for it to come in, then replies on the queue.  In the main VI I'll keep sending the user event until there is a reply on the queue then I know that loop has started.  Something similar has been discussed here. 

Another thing I might do for simple VIs is have the information I want to send to the VI through the user event, also be available as front panel controls.  So when I first call the VI I pass in a user event for future messages, and the actual value on the terminal for using it to start with.  That way I know the VI starts with the inputs I want, and can then give new inputs later.  Again this likely only works for simple VIs where there is essentially one user event with either data, or quit message. 

Channel wires sound like a good solution but I've still seen enough issues with it to avoid it from taking over all my designs. That being said Channel wires have been around for a few versions now and I feel like I can probably give them another shot.

[mcduff]

---

@Hooovahh wrote:

---

---

Your VI and being a "lurker" on LAVAG saved me. (Curiously I was able to download your VI without registering, usually I get an error when I try to do that.) I usually have simple loops spinning up in the being of my programs, one for data, instruments, etc. There were times in the beginning of the program that messages between the loops were being missed, but I could not figure out how to use the Event Inspector. Now I use your VI to see if my subVIs are running, and then start sending communication.

Thanks for your help.

Regards,

mcduff

[drjdpowell]

---

@Gregory wrote:

Possible Solution: ...The "Wait on Event" box shown below would be implemented as a SubVI, whose only purpose is to wait at the event structure for an event to be fired (or timeout).

---

You have a timing hole there.   You need be sure to create the reply communication channel before the lower loop can possible try to use it.   The thing with User Events is that the User Event itself is just a token; it is the Event Registration refnum that is the communication channel.   You have to Register for the User Event before sending the "Measure" request.

[Gregory]

Good catch drjdpowell!

[drjdpowell]

---

@mcduff wrote:

---

You also have the potential for a timing hole, as your Register for Event is in parallel to your Subscribe VIs.  Create User Event, Register it, and only then pass it to sending processes.  

[mcduff]

@drjdpowell

See Message #17. (The subVI is shown in Message 17, implementation shown below.) I think I closed the timing hole you are referring to, if not I am completely missing it. There may be a timing hole with respect to the bottom loop, but since it is just updating indicators, I do not care if it loses an initial message as it will be updated again shortly.

mcduff

[drjdpowell]

There is a difference between the phrase "obviously no bug" and "no obvious bug".  I only have pictures to look at, but if I had your code to look at it would take considerable study for me to conclude that you have prevented the possibility of sending a message to an unregistered User Event.   If you had used the Error wire to enforce the event registration to happen first, then I would see instantly that no such lost message is possible.