Producer/Consumer structure for two data sources

[CharStark]

I have two detectors that collect data at very different rates. One is a frequency counter that integrates for two seconds before sending its output. The other is a power meter that sends a new data point every couple of milliseconds. On top of this, I want to be able to send computer controls to each source.

Currently I have a program that is a state machine, which cycles through the collection of the two sources in tandem (Input -> collect Power -> collect frequency -> Input, etc.). However it is very slow to react to manual inputs, and the sources are not synchronized.

I'm looking for a simple means to collect both sets of data simultaneously, while integrating the data collected by the power meter to match the much slower frequency counter. A brief look through different structures indicates that a master/slave or producer/consumer setup could work, although I'm rather a beginner at LabView still and am not sure how to implement it quite yet. I'm curious before I start if the vastly different rates of data collection will be problematic when designing these newer vi's.

[DuncanW.]

Hi CharStark,

You will probably want to use a producer/consumer architecture if you are looking to speed up the sampling of your signals. It will allow you to move costly processing code to a separate loop so your reads can happen more frequently. You can implement this architecture with two consumers: one for the counter and one for the power signal.

However, I am confused as to why you want to do this. It is a widely-used, highly-effective design choice, but should still be properly motivated. Based on what you have described, it seems you are trying to measure the frequency of some counter signal. Without knowing the frequency ahead of time, you will need to configure the counter as a hardware trigger to sample the power line synchronously. This can be used in conjunction with a producer/consumer architecture, but is a tangential concept. Also, why do you need the sampling to be synchronous?

Some other questions:

Why are you integrating the frequency counter signal? Are you somehow trying to determine the phase of the signal?

What is your application doing at a high-level?

What do you mean by "matching" the slower frequency counter?

If you could provide more details, that would be help us help you!

Best,

Duncan W.

[cbutcher]

This sounds quite similar to a setup I had some time ago with a DAQ board measuring rotation speed using a pulsed rotary encoder output and torque as voltage from a load cell. I wonder if you're trying to do something similar.

I used a Producer/Consumer setup - your requirements are likely a little more complicated because you want the results to be synchronous, but like DuncanW wrote, it's not obvious why you need that, or what exactly it is that you want to be sychronous. Some more detail there would probably help.

Since my measurements were both made by the same DAQ board (USB-6356) I only had one producer loop (at least for these measurements). I iterated over a loop of 'measurement' clusters, which held my DAQmx Task, an enum giving the type (although you can get this from the DAQmx task using the appropriate property nodes, so I should have dropped that - I have done in a more recent Actor Framework implementation) and some constants I used for processing the measurements.

I made my measurements all at once using the DAQmx Read, then looped through the array of waveforms output (perhaps a 2D array of doubles would have been simpler, but it's more or less the same) processing according to the clusters I mentioned above.

Perhaps something similar would work for you?

[Kevin_Price]

A fairly typical approach I've taken is to have independent loops for each logical device interaction.  These loops are data Producers and you have 2, one each for freq counter and power meter.  Now youare free to interact with the distinct devices at distinct rates, depending on the capability of the device, the data rate, etc.

I'll usually have 1 Consumer that receives the data from *all* Producers and which manages the job of keeping it correlated.   Sometimes this is as simple as replicating the most recent slow data to match the # of samples of fast data so the arrays you graph or write to file will have the same size.

-Kevin P