Occasional problem extracting data from circular buffer

[Ron Norton]

Hi,

I'm having a problem with continuous, background analog input using a Measurement Computing PCI-DAS6052 with their latest LabVIEW VI's in LabVIEW 7.0. I can't tell yet whether the problem is due to their VI's or driver, or if it could be due to the way LabVIEW passes array data to SubVI's (which I am not at all clear about). One of MCC's tech support people is looking into the issue, but I thought I'd see if anyone else had any helpful insights into the issue.

Here is the problem. I configure and start continuous, background, multi-channel, AI scans, then repeatedly call their VI which checks the status of the acquisition, returns the cumulative count of samples acquired and provides access to the circular buffer which receives samples from the board. I pass the buffer to a SubVI which extracts any new, complete scans and converts them from raw unsigned integers to voltages and returns a 2D array of doubles. Depending on the system load at the time I get to the end of the circular buffer, occasionally I get a block of raw zeroes from the beginning of the circular buffer. If, after this happens, I stop the acquisition before it gets all the way through the buffer again and look at the buffer then, it has the correct non-zero data in the first block. Which suggests that somehow the SubVI sees a new value for the cumulative sample count and tries to access the data before the new data is quite ready.

My thinking is that if it were that the MCC driver was updating the count and returning before the transfer of samples from the board to the buffer was complete, then I would at least re-read the samples from the previous pass through the buffer. It seems to me the same logic would apply to the input control of the SubVI - i.e. that if the problem was that the values had not finished being copied (if they are, in fact, even copied at all - this happens whether I have the front panel of the SubVI open or not) from the buffer to the input control, then I would expect to get samples from the previous pass through the beginning of the control data array.

I am attaching the SubVI which extracts the data in case it shows something I neglected to describe.

If anyone has any idea what could be causing the problem, I would greatly appreciate hearing them.

Thanks a lot,

Ron Norton

Faculty Research Assistant

Gravitation Experiment Research Group

University of Maryland, College Park

[johnsold]

Ron,

I don't see any big problems in the VI you attached. You could move the divide by 65536 and conversion to double outside the loop and eliminate the subtraction in the loop by replacing the constants in the lookup table with the differences. This will slightly speed things up.

I suspect the issue is in the circular buffer. How is the circular buffer implemented? How are the read and write pointers handled? Under what conditions does the buffer get cleared or initialized? Does the problem occur if the buffer is made larger? Does the buffer return any errors (Overwrite, no unread data available, ...)? Is there any possibility of a race condition with the buffer?

Lynn

[Ron Norton]

Thanks for the reply Lynn. I am encouraged that you don't see any major issues with my approach.

The circular buffer is implemented in the package of VI's from Measurement Computing, and each of their VI's is mostly a Code Interface Node which I assume makes calls to their driver routines. About the only detail I've gotten from them so far is that the buffer is initialized once at the start of the acquisition and there is no zeroing of data in the buffer before it is written to each time. Increasing the size of the buffer reduces the frequency of the problem because it takes longer to reach the end of the buffer, but if I increase the machine load, by maximizing or minimizing the Windows calculator, for example, just before the program gets to the end of the buffer (which I can tell because I'm applying a sine wave to one of the channels and charting the data as it is returned from my SubVI), I can almost always induce the problem to occur.

I guess I really have to wait for the MCC tech support person to get back in touch with me to get more details on how their VI's work.

Thanks again,

Ron

[altenbach]

It's hard to tell without seeing the toplevel VI, but I suspect a dataflow issue that creates a race condition.

Are you absolutely sure that all critical nodes are correctly lined up by data dependency or sequence structures?

[Ron Norton]

Can you open these without the MCC UL for LabVIEW VI's? You might at least see the dataflow dependencies, etc.

Thanks,

Ron

[altenbach]

To me the dataflow looks ok at first glance.

Could it be that the "CurCount" output of "get status" is "overloaded" that for example a "-1" output would signify something special? Try to replace the "not equal zero" with a "greater than zero". Sorry, I don't have any other ideas at the moment.