Better way to communicate bewteen top-level and sub-panels?

[JeffBuckles]

My first labview project has been somewhat over my head, but with some help from the Blume book and "Labview for Everybody" I think it's going to turn out OK.

On source of complication is the fact that there are over 700 unique controls.   I decided early on to use sub-panels so that I could develop and test each module standalone.  However, the actual hardware interface is at the top level.  So a Sub-panel GUI event usually kicks off a sequence that looks roughly like this:

Top Level                   Sub-Panel

---------------             ----------------

                            Gui Event occurs

                            Submit HW request to HW Queue

                            (a named queue seen at both top

                             level and in sub-panels)

Get Request from HW Queue

Service request

Post results to Notifier

Wait at Rendezvous

                            Receive Notifier with results

                            Capture notifier results to local Queue

                             (each sub-panel has it's own queue)

                            Wait at Rendezvous

                            (in parallel, each subpanel is updating

                             it's GUI from results in local queue)

When all subpanels have 

 captured the results (have recieved

 the notifier and are waiting at the 

 rendezvous)

 then service the next HW request

I guess some explanation might be needed.

Each subpanel has three parallel loops:

1) event loop to detect GUI events and submit hardware access

    requests in response to GUI event

2) loop to capture notifiers in local queue.  This is so that the top level

    does not have to wait for each sub-panel to finish processing the

    hardware results.   I use a notifier because some hardware results

    are received and acted on in multiple sub-panels, so it would be difficult

    to keep track if I had the top-level directly submit into each sub-panel's

    local queue.

3) loop to service hardware results from local queue.  This usually involves

    updating the state of controls and indicators in the GUI

The top-level has these three loops (there are some top-level controls

and indicators) plus a fourth loop that services the hardware request queue

and posts the results notification.

So I guess it succeeded in being modular enough that I can "plug in" 

new sub-panels without having to change the top-level code.  But the

"queue, notifier, local-queue, rendesvous" sequence seems complicated

and maybe slow.    

As we're nearing the end of this project I'm thinking ahead to the next version.

One problem I had is that I am finding I want to use the hardware request queue

and results notifier for more than just hardware access.  But I don't want to completely

replicate them just to have a side-channel for software control.    For now I added

a field to the queue objects that indicates the purpose of the request, but it feels

clumsy and inelegant and easy to make mistakes.    

So, I'm wondering if there is a better way to handle the communication between

the top-level and the sub-panels.   I need a "many-to-one" path from sub-panels to

top-level, and a "one to many" path from top-level to sub-panels.    Sub-panels 

do not communicate with each other.    Communications from top-level to 

sub-panels has to be guaranteed to be received by all sub-panels (that's why I needed 

the rendezvous after sending/receiving the notifier) but there is no inherent ordering

or priority among the sub-panels.

What would be the best way to do this in Labview?

Thanks and Best Regards,

-- J

[Ben]

Hi Jeff,

Could you sketch up a quick interaction diagram (types, direction and magnitude i.e. data set size) for us to try and follow along?

I'll hold back on comments until after I have seen a picture.

Take care,

Ben

[nathand]

Have you considered sending user events to your sub-panel VIs?  Each sub-panel could register for a user event, which would then be triggered by your top-level VI.  You'd get the many-to-one action you need, and guaranteed delivery since each event structure maintains its own queue.  This eliminates the notifier and the rendezvous, although depending on the exact implementation you might also have a case where one subpanel is still finishing one request while other subpanels are already working on the next one.

[JeffBuckles]

---

Ben wrote:

Could you sketch up a quick interaction diagram (types, direction and magnitude i.e. data set size) for us to try and follow along?

Ben, I understand the difficulty in following the verbal description (I had a hard enough time distilling it into those few words!).  I can' t post the code itself because of content that is under NDA.   So, I'm not sure what such an interaction diagram would look like to be useful.  Are there any examples posted that you can point me to?

Thanks,

-- J

[JeffBuckles]

---

nathand wrote:
Have you considered sending user events to your sub-panel VIs?  Each sub-panel could register for a user event, which would then be triggered by your top-level VI.  You'd get the many-to-one action you need, and guaranteed delivery since each event structure maintains its own queue.  This eliminates the notifier and the rendezvous, although depending on the exact implementation you might also have a case where one subpanel is still finishing one request while other subpanels are already working on the next one.

---

Nathan,

This looks like a move in the right direction (assuming you meant "many-to-one" in your post).  After spending some time reading the "Rube Goldberg" thread it was precisely the whole notifier and rendezvous kludge that I began to question...

There are no timing dependencies bewteen any two subpanels -- the rendezvous was needed only to assure that each subpanel could "capture" the notifier data before it was overwritten at the top-level by the next hardware results, so I think this could work.

So, since each sub-panel has its own event loop, is it possible for all the event loops to receive a single user event provided they all registered for it?  I was under the impression that the "first" event loop to see the event would "consume" it so the other event loops would not ever see it -- or does that not apply to user events?

Thanks and Best Regards,

-- J

[Ben]

Here are two interaction diagrams, the left is for run mode and the right is for edit mode.

They don't have to be fancy or detailed.but they should be thorough. the left hand diagram shows that something called the "RUI" does something to the widget named Picture. Since this is unidirectional (nothing comes back) I can match that up with a queue. So if we know the nature of the interaction between your elements, we can use the NI provided syncronization schemes (queues, one-or many senders, single reciever) and only re-invent the wheel when none of the out-of-the-box solutions fit our need.

Just trying to help,

Ben

Message Edited by Ben on 01-05-2009 01:22 PM

[nathand]

---

JeffBuckles wrote:

So, since each sub-panel has its own event loop, is it possible for all the event loops to receive a single user event provided they all registered for it?  I was under the impression that the "first" event loop to see the event would "consume" it so the other event loops would not ever see it -- or does that not apply to user events?

---

Multiple event structures can each react to the same event so long as they each register for it independently.  In your case you can pass the same user event refnum into each sub-panel VI, then put "Register For Events" in each sub-panel, register for the user event, and connect that to your event structure.  For all the details search for discussions about multiple event structures such as this one.

[mikeporter]

Try this on for an idea:

1. The basic structure would be a producer-consumer (events) but modified such that the producer and consumer loops are residing in separate VIs.
2. The logic for interacting with hardware is in the top-level VI, so in this case it would be the consumer loop.
3. The producer loop(s) would be in the VIs being dynamically run and inserted into the subpanel on the top-level VI.
4. One of the actions that the consumer loop can process is stopping one subpanel plugin and starting another one.

With this structure, the producer loop plugins would enqueue data that the consumer loop would process. If needed, other events could be used to pass data from the consumer loop back to the producer loop. Very clean, no semaphores or rendezvous needed. Queue and event references would be generated in the top-level VI and passed to the plugins when they are launched using property nodes.

Mike...

[nathand]

---

nathand wrote:
You'd get the many-to-one action you need...

---

Oops, yes, I should have written "one-to-many" here, not "many-to-one."

[JeffBuckles]

---

Ben wrote:

Just trying to help,

---

And succeeding, I should say.

Thanks for the picture to explain what you meant (getting a taste of my own medicine, yes?)

It may be a few days before I can put this together, but I do want to continue the discussion.

Thanks and Best Regards,

-- J