many to one notification

[Siamak]

Hi,

I have already left a comment in idea exchange, as I thought there is no NI VI for this case.

I am looking for a VI which can handle many-to-one "notification" so that one VI has to wait until several other VIs meet a certain point and continue.

Comments welcome.

Sia

[MikeS81]

Hi Siamak,

see the Rendevouz. This do what you have described.

Mike

Message Edited by MikeS81 on 08-20-2009 11:02 PM

[smercurio_fc]

You mean sort of like the way it's done in the "Wait for All Notifications Demo" example VI?

[Siamak]

Wait for All Notifications Demo.VI is the true example of the One-to-one nature of the Notifier. In this example, we see an array of notifiers being fired for each other on a one-to-one basis.

Although the many-to-one mechanism can be done using notifiers, we don't see unique VIs responsible for this strategy.

Sia

Message Edited by Siamak on 08-24-2009 06:27 AM

[Siamak]

Rendezvous do not perform what I want of course. If you use them in different VIs, when reaching the point, they all WAIT for each other, so it is many-to-many so to say.

a many-to-one strategy can look like one VI when reaching a point, waiting for several others. Those others, when reaching the "notification" point fire some flag and continue. When all have fired the flag, the waiting VI can carry on.

Sia

[MikeS81]

Hi Sia,

you can also use a normal queue or notifier.

See the attached example.

Mike

[Siamak]

Sure, but this solution is both resource and design space hungry.

Sia

[MikeS81]

---

Siamak wrote:

Sure, but this solution is both resource and design space hungry.

Sia

---

Sia,

what is your solution?

Mike

[F._Schubert]

I don't see that Mike's solution is resource hungry at all.

And for designe space, of course you would make it a sub Vi...

One flaw is: If a sender sends more than once, it will let the receiver run although not all senders have send their notification yet. 

Here one more idea based on queues:

For each sender there is a seperate queue of size one (this way, it will send no more than 2 times before the receiver finished). The receiver has n dequeue primitives (one for each queue). Could be inside a for loop as well. 

Felix 

[MikeS81]

Hi Felix,

another solution would be that each sender send's an ID which will be checked against a buffer.

Mike