Design Pattern using queues and notifiers and problem with syncing

[Bob_Schor]

So why say "See you later"?  Are you hoping I'll (as one Travel Agency's sign advertised) "Please Go Away Often"?

Well, the appropriate response is -- I'm Back!

So I looked at your code more carefully.  A lot of what seems to be going on in the Consumer Loop is getting the data ready to plot.  But then you plot the data!  What can take time?  Is it "crunching numbers"?  PCs are pretty fast doing this.  Is it running multiple loops in parallel?  LabVIEW (and PCs) are pretty good at this.  Is it updating a Front Panel Display?  Well, it can't go any faster than the Display can draw it, so it will depend on how much data you are trying to display, and it may also involve how you choose to display it.

So I need more information.  What is the rate (points/second) you are trying to send to each display?  I presume (but this may be wrong) that it will be similar to the sampling rate and number of channels being sampled.  Hmm, that may be wrong -- I see a Build Array with 5 inputs wired to Chart Channel 1, so how big are each of those arrays?

I see you have specified (for Chart 1, anyway) a History buffer of 400,000 points!  This means that it needs to mess with a lot of points (which it does "behind the scenes", and probably very efficiently), but do you really want to hold onto all that old already-displayed data?  [My Chart sizes are typically 1000 points or less].  You are also using a Strip-chart display, which means for every point that you put on the Chart, the entire Chart must be redrawn!!!  This is probably your "killer" -- try replacing it with the Sweep Chart (a.k.a Oscilloscope View), which only needs to redisplay the current point (should be many times faster).

If I'm right, you owe me a glass of nice wine (and maybe a Kudo ...).

Bob Schor

[Bob_Schor]

Hmm -- I hope you haven't left for the day, Karen.  After all of our Back and Forth (and thank you for testing my earlier suggestions so quickly), I was hoping that you'd test whether changing the Chart Update Mode to Sweep Mode would fix it.  Guess I'll just have to be patient ...

BS

[KarenM]

Hi Bob, 

I'm back as well!  Yes, I had 'hasta la vista' gone for the day (ie. Terminator reference), and thanks again for your timely posts/help! Much appreciated.

Now, down to business: 

My goal in working on this acquisition screen is to modify a pre-existing vi into the prod-consumer loop architecture in order to properly display datapoints onto 4 charts. The inputs to these charts is a 4-channel DAQ assistant which can samples at 1S/s (averaging 100 datapoints). The chart history must show a large number of datapoints since it displays to the user in real-time the voltage inputs. I would like to preserve all functionality of this code and simply refactor it to have a more efficient architecture, and the reason I must do this is because each chart is not updated in real-time properly. The observed time display on the charts (the length of the datapoints) do not correspond with actual time (eg. 30 minutes of displayed datapoints show same profile but is condensed to a shorter time (20 mins) on graph).

I will need to keep the 400,000 buffer. As for the calculations before data display, if the consumer loops are able to execute in parallel (ie. I assume that the current iteration period of consumer loop of 4s is due to the consumers executing one after the other, as shown in disabling all consumers but 1 loop and observing iteration period = 1s), the amount of array copying in the background will be reduced if in the consumer rather than producer loop. If calculated in the producer loop and passed to consumer, the main data array in producer will need to be indexed, passed through several functions and recopied several times prior to output. It would be more efficient to have this acquisition and display done on an as needed basis.

Desired chart rate:

The rate to send to each display would effectively be 1S/s, and input data (orange 2-D array: 4 channels by 100 datapoints continuous acquisition) is also 1 S/s. For the chart display, there are 5 input plots: each at 100 datapoints long. The first plot is the voltage display, other plots are set to -Inf and to Inf when activated by the user (to represent the marking of events on the plot). The purpose of the chart is to display cell clamping data and allow the users to add drugs to the cell and mark the timing when it happens. The markings will appear as one datapoint within the 100, since the 100 datapoints are averaged to show a per-second update of the voltage data. 

I will try out the chart sweep -- definitely sounds like a good solution in terms of updating and will let you know how it goes. Thanks!!

[Bob_Schor]

---

@KarenM wrote:

I will need to keep the 400,000 buffer. As for the calculations before data display, if the consumer loops are able to execute in parallel (ie. I assume that the current iteration period of consumer loop of 4s is due to the consumers executing one after the other, as shown in disabling all consumers but 1 loop and observing iteration period = 1s), the amount of array copying in the background will be reduced if in the consumer rather than producer loop.

---

You know, I missed that interpretation!  I assumed that it took a second to do the Consumer loop (i.e. the CPU was "busy computing and updating" for that long), not that there was a data-dependency between the loops.  I'll go back and take another look -- maybe I missed something important (wouldn't be the first time ...).

BS

[Bob_Schor]

---

@KarenM wrote:

I'm back as well!  Yes, I had 'hasta la vista' gone for the day (ie. Terminator reference), and thanks again for your timely posts/help! 

---

Yes, I did catch the reference.  I was going to respond "I'll be baaaack", but settled for the present tense, "I'm back".

BS 

[KarenM]

Hi Bob,

Thanks for the reply. I had tested the 4-channel acquisition again to include the update mode to 'sweep'.  Please see screenshot for results. 

Channels 1 and 2 show graphs with sweep (theoretically updating 1 datapoint)

Channels 3 and 4 show graphs without sweep. 

I will do another test with all graphs on sweep mode. 

Thanks!

[Bob_Schor]

The big question is, did it make a difference in the speed that they ran.  Is it still taking 4 seconds to do an update, or are the plots "lagging" less.  The critical timing (so wait until you've done the test) is with all of the plots in Sweep mode ...

BS

[KarenM]

Hi Bob, 

I am currently doing the test with all graphs in sweep mode. However, the architecture that I am using is not prod/consumer but with the original architecture with everything in one loop. This is not my code, but I am working with existing code (and refactoring if necessary). All functionality for the said acquisition screen is present, so the only thing is the acquisition/front panel updating consumption time. 

I have tested with all channels in sweep mode but after ten minutes there is a significant time disprepancy between displayed time and actual time. 

I can test sweep mode with the new architecture, but so far it does not seem to give notable update differences. 

In the past I had tried to delay front panel updates in the main loop to a rate of 1S/s during iteration, to no notable results.... any ideas? Thanks!

[KarenM]

Hi,

I am testing all graphs in scope mode currently to see how much time discrepancy there is. 

Thanks!

[Bob_Schor]

Please see the Private Message I just sent you.  I think we may be (as my wife's Grandmother was know to say) "Nearer than Farther" ...

Bob Schor