How to make a multi to one notifier

[alex.]

Hi tbd, the method is great. What I original thinking is

1. use only one queue and one notifier to handle all the comunication. The queue is for component to apply to main.vi. The notifier is used for reply and later for component to inform main.vi to start transfer. A component ID will be send in the header of the notifier.

2. use one queue and multi notifier. Each component has one notifier, which used by component talk to the main.vi. The name of the notifier is the name of the component. This name will be transferred by the the queue in application at first time linkup.

I am not sure which one is good.

[Eugen_Graf]

You can use one Queue. Your Main.vi will be the Consumer and your SubVIs will be Producers. If you put a message into the queue you can put the SubVI Name in this message too. So your main.vi will now from which SubVI the data come. And don't forget you can use Flatten/Unflatte To/From Variant/String VIs to transfer every type of data.

Some advansed Design Pattern, which support all of them and much more you can find here:

http://www.labviewtutorial.eu/viewtopic.php?f=19&t=271

Regards, Eugen

[Eugen_Graf]

I'm so sorry, you will find this pattern here:

http://www.labviewtutorial.eu/viewtopic.php?f=19&t=9

[alex.]

The code project is amazing, may you give more intro inside the project. Thanks.

[tbd]

---

turbot wrote:

Hi tbd, the method is great. What I original thinking is

1. use only one queue and one notifier to handle all the comunication. The queue is for component to apply to main.vi. The notifier is used for reply and later for component to inform main.vi to start transfer. A component ID will be send in the header of the notifier.

2. use one queue and multi notifier. Each component has one notifier, which used by component talk to the main.vi. The name of the notifier is the name of the component. This name will be transferred by the the queue in application at first time linkup.

I am not sure which one is good.

---

Hi turbot,

      I don't know which option is more appropriate for you application.  Having each Component filter Notifications - so one response Notifier can be shared - seems awkward to me.  Personally, I don't use Named Notifiers - I'd rather see a [unnamed] Notifier-wire routed to every place it's used because then I easily know which parts of the program are dependent on each other.  However, you know your application and it sounds to me like you have a very good understanding of the fundamental principles - you can probably develop a better solution than I can suggest.

Although it seems you won't need it, my example needs an important improvement!  Late responses (after timeout) could be confused with subsequent "transactions".  I think each "transaction" needs an unique "index" so late responses can be identified.  This late-response consideration may apply to you solution(s) as well!

Cheers.

[Eugen_Graf]

turbot, you can read more about here

http://forums.lavag.org/publish-subscriber-t7793.html

or ask me what do you want to know about this pattern.

It's not to complex. If you have paralell loops in your programm, they should communicate. For communication you can select following:

local variable

global variable

notifier

queue

user event

tcp/ip

...

I implemented in this pattern 4 last communication types, because I don't like any variables.

So the dispatcher have the task to dispatch incomming (over one dispatcher queue) messages to loops interested in. So the dispatcher is the main VI and should be started as first. In the dispatcher you will find a table. Row headers are loop names, column headers are message names and in the table you will see the communication type (one of 4 implemented) of the loop.

If if the dispatcher is started, you can begin to start your tasks (parallel loops). At the start of one task, this task have to say to the dispatcher it's name, it's reference, it's type of communication and which messages it want do receive from the dispatcher. The dispatcher will add this informations into the table. So if any task will send a message to the dispatcher, it look in the table which tasks are interested in this message and will send the message to the interested tasks. All the communication should go over the dispatcher, so it's much easier to debug your programm, because you have all informations about all tasks in your programm on one place. And not only, all messages go over the dispatcher, so you can spy every message from every task, and YOU CAN DO IT REMOTELY from an other PC, because TCP/IP is implemented too.

If you have more questions, so post it in my forum please.

Regards, Eugen

[alex.]

Is there any intro or reference of User Event, thanks.

[Ben]

Not sure if this helps but Jim Krnig poasted a design pattern here  entitled "

Queued Message Handler with Response Notification

" that may help.

Ben

[alex.]

Hi Eugen Graf, I am looking into the code. May I know your contact so that I may contact you later when I work on it. Thanks.

[alex.]

Hi Eugen Graf,

Have you made any performance testing on it, thanks.