Passing Data Between Simutaneously Running For Loops

[Tim_C.]

I am using a Producer / Consumer Que tpye layout that has multiple Consumer Loops

I am trying to see what is the best way to get a Bool value to show simutaneously in all the consumer loops, note the

consumer loop may be running a for loop in which case the bool value will not only have to get inside the consumer loop but

also been seen in the active for loop.

I was thinking of either making a local variable of a control or a global variable....looking for most memory efficinent way

to do this.

Thanks

 Tim C

[F._Schubert]

A notifier with timeout 0 placed after each dequeue element?

Felix 

[cancancanopen]

I too go with Mr.Schubert.

[LV_Pro]

The suggestions mentioned before, of notifiers, will allow each loop to "know" essentially simultaneously when the data is available, but unless you have a "dequeue " inside the FOR loop you will need a means to pass it in. A local of a control that can be set when the data is available would work, IF the dequeue activity is not "in the data flow path" of the FOR loop, i.e., the FOR loop needs to be in parallel with whatever loop is handling the dequeuing (unless the dequeuing is inside the FOR loop). Of course this (locals, etc.) will add a level of unpredictibility to when the data is seen in that FOR loop, it will depend on the loop cycle, what has to be processed in the loop before it "gets back around to check for new data".

[Tim_C.]

I am not famiular with Notifiers,  at the present the producer adds elements to a que when a front panel button is pressed.

And the consumer while loops have deque element functions with then feed a case statements that  has the associated

que statement  (not all of the consumer loops have a case for each of the que elements sent,  used it like this to break up

funtionality).  

Where would the notifier fit into this arrangement?

Thanks

Tim C.

[Tim_C.]

I forgot to mention that each time I attempted to place the "Wat on Notification" (only one I found with a timeout input)

after the deque function it created broken wires.

Tihanks

[F._Schubert]

Notifiers work similar to queues as they allow to communicate between parallel loops.

The (main) differences are:

* Notifiers are not buffered, you only can get the latest one or wait for the next one (this is the ignore previous flag)

* Notifiers allow a one-to-many communication (they are not consumed like dequeueing an element from a queue)

I hope this helps you architecting your current multiloop architecture. My point of bringing them into wa, they are of the same language design as queues, but can be used similar to a AE (global + serialization via error wire) data.

Hmm, difficult to explain without coding a lot...

Felix

[Tim_C.]

Yes that explanation was very helpful.

I mayhave problem,  I notice I have to hit a front button a couple times to get the consumer loop code to fire.

I have verified that the producer loop event is firing.

I added a que function to see the number of elements in the que after the enque in the producer loop  but the element stays at 0.

I added a timeout event in the producer loop event structure with a time of 100ms,  each time this fires it adds an "Idle" element to the que

each consumer loop has an Idle case  (this may be a problem given your last explanation).

Should I try to keep data flowing in hope of a faster response in the consumer loops?   I guess I am at a lost point as I do not

understand why I am not seeing the element count increase in the producer loop  and the consumer loop cases are not taking

 off as expected.

Should I use a TimeOut event in the producer Loop?  If so what is a good time constant to wire to teh event?  If there is no

Timeout event is it simply waiting idle?

Thanks

Tim C.

[Kyle Smith]

How are you monitoring the number of elements in the queue? If you've got consumers waiting on a Dequeue Element it's possible that the elements in your queue are getting snapped up before you see them in your monitoring function.

Unless there is a function you need the consumers to process on a regular basis I don't see the need for an idle case in each - response time of the Dequeue Element should actually be faster if the consumer is simply waiting for an element.

An Event structure with no Timeout case will wait indefinitely for one of the included event cases to occur. If you want that producer loop to do something regardless of whether any of those events are occurring then a Timeout is a good idea: 50 or 100 ms is a pretty normal number for UI type applications.

[Tim_C.]

Can I use a producer / consumer utilizing 1 que, and multiple consumers as long as the consumers do not have identical cases?