Fastest configuration for DAQmx digital read

[RocketB]

Hello,

I'm a self taught Labviewer who is trying to find the optimal setup in DAQmx to read 24 bits of digital data, check 8 bits of them to determine the validity of the data (Those 8 bits are a frame counter, I only want my frames), then process the other 16 if the data is valid.

I have an NI-6536 PCI card doing the data acqusition on a windows 7 PC.

The data is clocked in at a rate of 250 Khz by an external sample clock. But the processing code seems to top out at 220 Khz. No data is lost because of the buffer, but I need to be able to process in real time and this causes an ever growing lag as the software can't keep up.

I have tried all sorts of different clocking methods (change detection, pipelined sample clock, etc), but none seem to be faster in any meaningful way. I have also stripped the code down to just the DAQmx read function and the 8-bit check to see if all my shift registers and the like were weighing things down, but that also seemed to do very little.

I have also tried to set up some kind of pattern match triggering, as more than half the time the 16-bit word is all 0's and needs to be thrown out anyways.  That stops the lag, but I only seem to get ~40% of the valid data (I have counters to tell me the "good" rate so I know what I'm missing).

I'm hoping there's some way to setup a zero-screen at the hardware level or in the memory so that I don't have to read the zero's into the program. Either that or there's a smart way to seriously up the speed. Attached is some code (note that in this code the sample clock is only running at 125 Khz, that's because I've been forced to split the matrix in 2 and process through two different cards, but that's not a good solution long term).

Also note if looking at the code, the while loop is within a case structure selecting "GSE" or "TM". I have no problem in GSE mode, only TM. That DAQmx in the "TM" tab is the problem.

Any help would be hugely appreciated. Thanks!

[crossrulz]

Some general thoughts.

You should consider using the Producer/Consumer architecture.  Read the data in the producer loop and process it in the consumer loop.

You should probably open the file before the loop, write to it inside of the loop, and then close it after the loop.  This will speed things up a little bit since the file won't be constantly opened and closed.

Are the build arrays necessary?  I haven't studied your code enough to tell yet.  In general, dynamically building arrays will cause slow downs.  If necessary, you could preallocate your arrays (Initialize Array) and use the Replace Array Subset along with a counter to act as a pointer.

[MarcoMauri]

Hi,

as already pointed out by Crossrulz, it's better to split the code doing the acquisition from the code processing and saving to a file.

I may be wrong but instead of acquiring 1 sample per each channel it would be faster to acquire all available samples in the buffer.

Regards,

Marco

[RocketB]

I'll try producer/consumer arcitecture, thanks.

I think the build arrays are necessary. I have no foreknowledge of how many good counts I get (The data is from a detector), so I have no foreknowledge of an array size. Would it still be faster to say, preallocate a very large array (80,000 elements or so) and then when I write to file dump out all the 0's? 

Even so, that is not the limiting factor as I have experimented with taking out the write altogether and it didn't speed things up. Thanks though!

[RocketB]

The file OPEN/CLOSE is already outside the processing/read loop. Only the inner WHILE loop handles data. The outer one is just used to wait until things start to happen.

[MarcoMauri]

Hi!

Try changing from "NChan 1Samp" with "NChan NSamp".

Reading one sample at each iteration cannot work: software can't keep up with the hardware acquisition.

Marco

 

[RocketB]

I'll try, but I need to process each sample individually... so if I get a block of samples at a time I'll probably have just as much trouble, no? I'll try though, thanks.

[RocketB]

Producer/consumer with a queue was slower. No love there. Thanks for the suggestion though.

[RocketB]

When I set to NSAMP I then need to parse out the 2-d array not only into each individual sample, but then back to boolean so I can analyze certain control bits. I appears to make things even slower due to the need to break down every sample into componants.

Again, the problem here is not reading the data and storing it, just making the initial processing ~10% faster than I have it already. The only thing that needs speeding up is determinging a single 8-bit number displayed on the port and/or setting up a 0-screen on the other 16 bits. The rest of the code only is executed at a few Khz at most.

Does anyone know a way to set up a 0-screen? Most of the time half my data is 0 (the other half is a frame counter) and when that half is 0, I don't need to read. But I don't see any way to reject data without reading it into the software and that slows things down too much already.     

[RocketB]

Thanks very much for your help so far though, they were good suggestions and I will keep looking at them.