In a Producer/Consumer structure utilizing a Queue, the Producer loop is producing faster than the Consumer loop can consume.

[rhkdgkrtlf1]

@Kevin_Price

Thank you for the words of encouragement regarding my beginner-level VI.

1. The Ctr output pulse is physically shared with the Analog Clock Source through a BNC cable. When you suggest adding data dependency, do you mean placing the DAQmx start task for the AI task at the front part of the flat sequence structure, like the edge count task? I will do that.

2. I experienced similar slowdowns in the loop even when not using the wavemeter dll call. I will look into and resolve sending a scalar value in the queue cluster.

3. I understand what you mean. I will improve this part as well.

4. I knew my method for tracking time and counts per second wasn't fancy, but I didn't know there was a better way. I would appreciate an explanation or a source for this method.

I will improve by changing the XY graphs to Waveform Charts.

Thank you for pointing out several issues

[rhkdgkrtlf1]

Unfortunately, as the experiment data is obtained by modulating the wavelength, it's necessary to track the wavelength. Although it doesn't change as rapidly as the sample rate, the wavelength is modulated at approximately a 0.1 to 2 Hz frequency, so it needs to be tracked in real-time.

[Kevin_Price]

1. Yes, that, or something like that.  The key is to use data dependency to make sure DAQmx Start for the AI and Edge Count tasks must complete *before* DAQmx Start for the Counter Clock task is allowed to run.

2. Right now you only replace the same final value in an array full of NaN's.  Only 1 value is relevant, so only send 1 in the cluster.

3. Check the error status *after* the enqueue where they're all merged.  Then set your Stop boolean to True after the producer loop ends (but before you subsequently reset it back False after the consumer loop also ends).

    (BTW, this is *not* the preferred way to signal parallel loops to stop, but for now the simplest route forward I can easily describe is to make use of what you already have in place.)

4. You're already sampling at a fixed rate so you *know* you have the same delta time for all samples.  All you need to do is track your delta counts in an array.  It could look like the pic below, then you can divide the whole array of delta counts by delta time just once to get counts/sec.

Note: the counter hardware can give you even more precise counts/sec measurements using other methods if you find that you get too much quantization error using this method.  But you can also smooth out your quantization error here by summing the delta counts over more intervals.  This of course accomplishes the same thing as reducing your sample rate, with one possibly useful caveat.  Here you could apply it as a sliding window.

    For example, with a 1000 Hz sample rate and summation of 10 intervals, you're effectively sampling your count rate at 100 Hz.  But you *can* make that a sliding window which produces a new average count rate every msec.  (Note: 9 of the 10 raw samples used for that next average are the same as the previous.)

-Kevin P