Event structure in both main vi and sub-VI with queues

[mattkindig]

Hi all,

I have an application using the producer/consumer architecture in which a queue passes messages from a main VI to a sub VI, in response to user events in the front panel. Inside the sub VI, the queue is dequeued and processed based on the dequeued message, and the result is displayed on the sub VI's front panel. The user events are captured in the main VI using an Event Structure. This works as expected.

However, I would also like controls on the front panel of the sub-VI to be able to modify the queue. My approach is to have another event structure in the sub VI to do this. However, while the events in the main VI work fine, the sub-VI events never get processed.

Attached is a simplified sandbox VI of what I'm trying to do. As you can see, events from the main VI are triggered as expected, but events in the sub VI are never triggered.

I looked at this white paper: Detecting an Event in a SubVI from a Top Level VI but this is not exactly what I'm trying to do; rather, I'm just trying to detect an event generated within the sub-VI. I searched this board and found some related queries, but none of them seemed to address what I'm trying to do.

Thanks

Matt

[crossrulz]

Your code is too new for what I have been allowed to install so far (2014).  Could you post a snippet of your code or downconvert?

[Wolleee]

In your subvi youre going to have difficulty catching user events because you are lacking a while loop around your event structure.  In my opinion having nested user events is not your solution here. 

Why do you want to front panels to perform the same functions? It would be easy enough to have all the processing in the subvi controlled by the front panel on the main vi. 

Cross i attached some snippets for you.  Im sure youve got some good suggestions.

[mcduff]

However, I would also like controls on the front panel of the sub-VI to be able to modify the queue. My approach is to have another event structure in the sub VI to do this. However, while the events in the main VI work fine, the sub-VI events never get processed.

I am really confused as to what you are trying to accomplish. The events in the subVI are "Front Panel" events, that is, they occur/fire when a user interacts with one of the controls. Your subVI does not have its front panel open, so how would a user interact with its controls? That is why your events never occur.

If you want to fire an event from a subVI look at examples for "User Events". These event loop have a little more development overhead, ie, you need to register for events, destroy events when closing, etc.

Cheers,

mcduff

[crossrulz · Accepted solution]

Your major issue here is loop location.  The While structure should be INSIDE of the subVI in order to make it a proper Queued Message Handler.  In fact, you should have 2 loops inside of your subVI: 1) the QMH and 2) the event loop.  You should use a User Event to commend the event loop in the subVI to stop.  You should NOT be using the timeout of the Event Structure unless you absolutely have to.  And since everything in that subVI is message based, you do not need any waits.  They will be idle (using no CPU) when there are no elements to process from the queue or event queue.

[mattkindig]

Thanks everyone. While I digest these solutions some more, I am attaching these files in Labview version 10.0. Please let me know if an older version still is needed.

[Bob_Schor]

This is definitely possible (I've done it).  In my case, the sub-VI was run in a sub-Panel of the Main VI.  I don't recall (and, looking at the code, I don't see) any other special properties of the sub-VI (like "Open Window when run" -- it has largely Default Windows properties).

I'm about to disappear for a brief "vacation from my computer", so don't have time to look at your code.  However, others have made useful suggestions, and mine can be considered another "Yes, it is possible, try this ...".

Bob Schor 

[altenbach]

Your subVI is "transparent and does not need any event structure. Just make sure the front panel stays open during the run of the main VI and you should be good. Have the dequeue operation timeout instantly and retain the previous operation if a timeout occurs.

[mattkindig]

Answering a few questions that I've gotten:

@mcduff:   During normal operation, the front panels of both the main VI and sub VI are both open (on seperate monitors of the operator's workstation). My assumption was that if the sub VI front panel were open, that events in the sub VI could be triggered. Perhaps I am mistaken in that assumption.

@Wolleee: You asked why I want to have two front panels that perform the same function. In my actual application (rather than this simplified example that I posted), the two front panels don't have identical controls as shown here. Rather, in the real application, the types of events that enqueue messages is quite different between the main and sub VIs. 

[Wolleee]

---

@mattkindig wrote:

Answering a few questions that I've gotten:

@mcduff:   During normal operation, the front panels of both the main VI and sub VI are both open (on seperate monitors of the operator's workstation). My assumption was that if the sub VI front panel were open, that events in the sub VI could be triggered. Perhaps I am mistaken in that assumption.

@Wolleee: You asked why I want to have two front panels that perform the same function. In my actual application (rather than this simplified example that I posted), the two front panels don't have identical controls as shown here. Rather, in the real application, the types of events that enqueue messages is quite different between the main and sub VIs. 

---

You can have events triggered on both front panels, but your architecture will need to change.  I havent seen the task at hand so i cant suggest the perfect solution, but id take a look at these examples and you may be able to modify this for your needs, the first link may be more what youre looking for.

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

http://digital.ni.com/public.nsf/allkb/A882E27D1D7A949386256E0D0066B91A

http://www.ni.com/example/28769/en/