Design Pattern using queues and notifiers and problem with syncing

[Bob_Schor · Accepted solution]

I believe I found out why, with a Producer "producing" data at 1 "chunk" per second, it takes 4 seconds for your displays to update.  A Big Fat Clue that I originally mis-interpreted was that three loops took 3 seconds, and a single loop took 1 second.  Once I had the "Aha" moment that this wasn't because the loops inherently took a second to update the screen (I advised using Sweep Mode instead of Scroll Mode for the Charts), I went back and looked more closely at the code.

Your Producer loop generated 4 sets of signals, one per Chart, then bundled them all together and placed them on a Data Queue.  The Data Queue then "fed" all four Consumers, which meant that there were four parallel loops all trying to dequeue from the same Queue.  Data Flow says we can't "know" which Consumer will try to run first, but let's assume it is Consumer 1 -- it will dequeue the data, thus emptying the Queue, and plot it.  Meanwhile, Consumers 2-4 are (patiently) waiting for data to appear on the (now-emptied) Queue, so they wait for a second.

Now the Producer puts more data on the Queue.  It appears that the algorithm that LabVIEW uses to decide which Consumer Loop runs next gives it to Consumer 2, which empties the Queue, plots the data, and goes back to waiting.  The next second, the data goes to Consumer 3, then Consumer 4, and now we're back to Consumer 1, having taken 4 seconds (and 4 sets of data) to finish the cycle.

The solution is simple -- instead of bundling the 4 sets of data into a single Queue, have 4 Queues and give each Consumer their own "private" data.  Among other things, you won't have to "split out" the individual Channel's data from the (no-longer-combined) Queue, saving steps in both Producer and Consumer, but more important, Consumer 1 will only be removing Consumer 1 data, so Consumer 2, 3, and 4 will get their own data every second, allowing all of the Consumers to run in parallel (as they all get data every second on their own private Queue line).

I'm so excited, I can hardly wait for you to test this and tell me if it works ...

Bob Schor 

[KarenM]

Hi Bob,

Thank you so much for looking into this! I am still working on the subvi and will let you know the results!!

Thanks!

[KarenM]

Hi!

After changing around the architecture, and using separate data queues, and indexing the DAQ assistant input into the 4 data queues, the acquisition vi properly syncs! Thanks! After multiple test runs, it seems that each consumer loop runs at a 1cycle/s, which is what is expected for the data execution. Each of the consumer loops sync with each other and also, in tracking the number of iterations between the producer and consumers, they are finally consistent! Hooray!

To prevent too many inputs/outputs from the loops, clusters were used to group together the inputs (typedefs were created for them as well). In terms of the main consumer loop, which executed other non data logging and display commands, the execution was moved into the producer and placed in the producer's event structure for neatness. All functions were limited to a processing time of 1 s, so as not to delay the incoming data timing. 

Thanks for the solution!