Losing track of analog inputs

[A_squared]

I'm using the PCI-6229 in continuous acquisition mode and transferring the data using DMA transfers.  The data is packed together so I get something like ai0, ai1, ai0, ai1, etc.  I need to parse the data every 250 ms and average all the data for each input into a single voltage for each analog input.  I'm acquiring the data at 80 kHz and my control loop is running at 4 kHz.  I'm currently acquiring approximately 20 data points (10 for each input).  My program determines how many complete sets of data are available and transfers that amount thus leaving an analog input 0 data point if no analog input 1 data point exists to go with it.  Every so often (once per day maybe) the program loses track of which input is which and starts thinking ai0 is ai1 in the data stream.  Most likely this is associated with a buffer overflow or similar event that I'm not currently detecting properly.  My question is if any method exists to do what I want to do and simultaneously keep track of each data point, or if I have to write a bugfree program and trust that I haven't lost track of the data?  Thanks.

My other posts in the DDK forum are about the same application and the bugs I found in the DMA code should be properly accounted for and any buffer overflows are handled by stopping the acquisition and restarting it.  Nevertheless, further information about my program and such can be found in those posts.

Thanks.

[Mark_E]

Hi Aaron,


I'll take a look at this and see what I can come up with. In the meantime, is there a particular post that would help get me up to speed more quickly, rather than searching all of your posts?
How are you made aware that your program is losing track of the inputs? Do you have error handling in your program that would confirm your buffer overflow error theory?

[Tom_W_[DE]]

Hey Aaron-

I'm curious whether you have been able to observe where the channel switching occurs (i.e. by noticing a repeated ai0 or ai1 scan in a logfile or something).  If so, does the switching always occur at the beginning of a DMA read buffer or usually somewhere in the middle?  If you are able to observe the channel switching during the acquisition, is it possible to determine whether ai0 or ai1 was the first to be repeated? 

One other question- if you add a third channel to the mix does the problem persist?  If so, try to determine whether the scan output repeats a single channel (ex: ai0, ai1, ai1, ai2) or if the scan seems to be interrupted (ex: ai0, ai1, ai0, ai1, ai2).  I'm not sure exactly what might be going wrong, but this info might help give some ideas of whether we're looking at a hardware or software problem.

Thanks-

[A_squared]

I basically knew it was a software problem on my side all along but was looking for a possible added layer of redundancy.  I tracked down the bug, which was not handling all of the dma errors properly all of the time.

Keeping track of the inputs is extremely important because it could possibly kill someone.  This is the reason I was wondering if there was an additional way to monitor which input was which.  I'm obviously striving for bug free code, but any redundancy I could add would be helpful.  From the sounds of it though, proper accounting seems like the only way.  If I am incorrect though, please let me know.

Thanks
Aaron