Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

Counting Problem: How to avoid data overwritten?

Dear all,
 
I am using the 6602 board and the DAQmx  "count_digital_events_buffered_continuously_Ext_clk.vi" to realize the photo counting. I have set up two counters, one is for input signal, another is for sample clock use.  the data could be displayed either in a Graph or written to a file. (Graphic display/file store) The input signal has a frequence around 1MHz,  I would like to set my sample Clock frequence as high as 1MHz. following are my problems:
 
1. I always encounter an error called: " Data was over written before it could be read by system".  I have tried to give it a large sampling rate and a large "# samples to read" but the error could not be avoided. this happens when the Sample clock frequence exceeds 100KHz in Graph display and  exceeds 10KHz in file store mode.
 
2. sometimes another similar error happens: "Attempted to read sample that are no longer available. they are previously available but have been overwritten". I am not sure what is the difference, but still, whatever I do, I was not able to get rid of that.
 
My goal is to sample my signal at a frequence of 1MHZ. any suggestion would be welcomed.:)
 
Qi
0 Kudos
Message 1 of 21
(13,691 Views)

Hi Qi,

What you are seeing is a limitation of the max sampling rate that you can have with the 6602.  Counters have small onboard buffers, because of that they have to transfer their data quickly (and in small chunks), from the onboard memory to the RAM so that you can later read it in your program.  Due to PCI-bus latency you run into problems like this when trying to read counters at fast rates.

There is a KnowledgeBase online that shows some of the benchmark tests for devices similar to yours:
At What Signal Rates Can the Data Acquisition DAQ-STC Counter Chip Acquire?

Keep in mind that your own results can vary greatly because of other traffic on the PCI-bus.  Particularly if you have something like a PCI graphics card then your performance can be significantly decreased.

I hope this helps you understand why those errors are occurring and can help you to avoid further problems.

Regards,

Message 2 of 21
(13,657 Views)

Thank you so much. could you tell me will it be helpful to change a larger PC memory? currently I am using 1GB. it sounds already big enough, but somehow disappointing.

Qi

0 Kudos
Message 3 of 21
(13,627 Views)
Qi,

Unfortunately, more memory will not help you here. To achieve the maximum rate possible, please try to minimize all other PCI bus bandwidth. The problem here is latency. Because the onboard FIFO of the 6602 is small, the driver must constantly read data off of it to prevent it from filling up. If there are any other PCI bus transactions going on, they may prevent the data from being read off of the card, thus causing the FIFO to overflow.

Why exactly do you want to sample at the rate you are counting pulses? What do you intend to do with the data? What is the end goal? These counters have other modes of operation (frequency measurement, etc.) which may yield the same results.

Hope this helps,
Ryan Verret
Product Marketing Engineer
Signal Generators
National Instruments
0 Kudos
Message 4 of 21
(13,605 Views)

 done some similar fast acquisitions with a 6602 and here are a few points I have found.  

1. use DMA only,  note that there are only 3 DMA channels so you will only be able to use upto 3 counters atmost,  if you use interrupts you will not be able to transfer the samples fast enough. 

2. If you dont have to sample for continuous periods of time this will work, remember if you want continuous 1Mhz sampling you will be moving 1MS of data per second, this will quickly eat up RAM even if you are able to stream the data from your card to RAM.  I was able to look at small sample sections at 1MHz sampling.  I used 50-100 events where each event counted the TTLs for 1000 samples of 1microsecond periods each. 

3. Multithread the program, dont analyze ort present data in the same loop as the data acq.  I used quques to send small chunks of data for analysis.  This way you can give high priority to the daq loop, any delay in this thread will kill your buffer and explain the over runs.

4.  As stated before the PXI bus is on its way out because of the limited (and shared) data bandwidth.  I am hoping for the next generation (I have been using the 6602 for over 5 years) to be a PCI express (high bandwidth not shared data path) with more DMA channels.  Come on NI its time to produce the next generation ctr/timer card.

5.  Calculate the buffer size needed.  You should sample your card at intervals which allows for moderate amounts of data at a time so you dont add to many read calls (each with their own overhead) but also dont make these calls so infrequent that you will run out of buffer space.  lets say you are streaming 1 Million pts per second you might want to reat 100000 samples as fast as possible and you should make your buffer a few multiples of this (larger buffers will delay the inevitable buffer overrun if you can't keep up).

6.  Fast reading will limit your amplitude resolution, remember that at 1 Mhz you will get at most 80 cts per 1 microsecond.

7. *****IF YOU ARE USING DAQ MX AND 0 COUNTS IS A VALID READING- disable counterDuplicatPrevention!  This fact tripped me up for a few days and I have seen almost everyone have an issue with this problem.

 

Good luck,

 

Paul

 

Paul Falkenstein
Coleman Technologies Inc.
CLA, CPI, AIA-Vision
Labview 4.0- 2013, RT, Vision, FPGA
Message 5 of 21
(13,591 Views)
Excellent post, Paul! You made some really great points. One thing to remember, the DAQmx memory buffer is not the same as the on-board memory buffer. PCI bus transfers are automatically handled by the DAQmx driver, while DAQmx to LabVIEW transfers occur on DAQmx Reads. When you specify a buffer size and "number of samples to read," you are configuring the DAQmx PC memory buffer. The on-board (6602) buffer is a fixed size. You can, however, change the way DAQmx transferrs over the PCI bus through the use of the "Data Transfer Request Condition" property (DAQmx Channel Property Node->Analog Input->General Properties->Advanced->Data Transfer and Memory->Data Transfer Request Condition). I suspect that changing this property may help. Perhaps if you changed it to "Onboard Memory Not Empty," you would get transfers more often (less efficient), but there would be less of a chance of an on-board buffer overflow.






Message Edited by Voltage Viper [DE] on 01-06-2006 04:30 PM

Ryan Verret
Product Marketing Engineer
Signal Generators
National Instruments
0 Kudos
Message 6 of 21
(13,583 Views)

I second the motion -- the suggestions from falkpl  are an excellent set of tips!

However, I have a question about the recommendation from Ryan V. of NI.  I understand the idea of the "DataTransferRequestCondition" but thought that it only applied to analog acquisition.  After all, it's found under the AI instance of the DAQmx Channel property node.

Is it truly a generic property that would apply to other types of tasks?  Is it for all types of buffered tasks -- Analog In/Out, Digital In/Out, Counter In?  Or is it in fact restricted to AI only?

I'd try it out myself, but my LV system is tied up in a test now so I can't tinker...

-Kevin P.

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 7 of 21
(13,562 Views)
Kevin,

You got me! That property is for Analog input only. Previously, I had suggested it to increase the rate of a 6608 when used in conjunction with another MIO card (using it on the MIO card). As my mind wandered, I thought to myself, "Setting that property on the 6608 could also potentially help to 'interleave' the data." Since the counter buffer is so small, it doesn't really make sense for that property to exist on it. Now I remember why I didn't suggest it for the counter as well. Thanks for keeping me on my feet! Apologies, Paul.

Regards,
Ryan Verret
Product Marketing Engineer
Signal Generators
National Instruments
0 Kudos
Message 8 of 21
(13,556 Views)

Glad to share my experiences with the 6602, I have used it in several applications since it is a great card.  I am ready for NI to release the next generation card is there any talk of this yet?  I am hoping for the next generation to have 4 or 8 counters, with all DMA channels if possible (I know that the M series already supports 6 DMA) and switch from PCI to 1x (or more) PCI express  this will give a guaranteed bandwidth of 250MB (I think gen2 clocking will increase this by 2x) allowing for >1MHZ streaming of data (realtime analysis could be a problem but CPUs are very fast as well).  The multifunction DAQ cards have been upgraded but not the counter/timer cards.  I am not a hardware expert but this seems to be a step in the right direction.  The 6602 is very useful at high speeds in photon counting applications where the PMTs have TTL discriminators producing digital pulses for each photon detected, the need for time sensetive analysis is useful here.

Paul

Paul Falkenstein
Coleman Technologies Inc.
CLA, CPI, AIA-Vision
Labview 4.0- 2013, RT, Vision, FPGA
0 Kudos
Message 9 of 21
(13,562 Views)

Part 1 of 2 (due to 500 char limit)

While the thread is fresh and FWIW, I'd like to add my own additions to a counter/timer wishlist:

1.  Hardware-reload of count register based on signal edge.  Currently, the only feature that's fairly close is the "Z-index reload" feature for encoder position measurement.  There are many limitations and at least one quirk as presently implemented.

A. It only works in "position measurement" (a.k.a. "encoder") mode.   At minimum, it should also be supported in edge-counting mode provided the other limitations/quirks are addressed.  I've done a lot of measurements with an encoder mounted to a step-and-dir stepper motor.  The step-and-dir motor must be measured as an edge-counting task with hw-controlled direction.  The encoder's z-index pulse CAN'T be used to hw-reload the count of the edge-counting task in sync with the encoder task.  It'd be GREAT if it could.  Hw-reload of count could also be useful in other counter tasks, especially pulse(train) generation.  I can imagine some clever tricks in the other modes (such as period measurement) as well.

B. It must be programmed to be "active" only during a specific 1 of the 4 possible states of encoder channels A & B -- LL, LH, HL, HH.  This works out fine for real-life encoders that supply their own z-index signal.   However, I've had numerous occasions where I would have logically preferred to reset the count value based on some other system pulse signal (can you say "Limit switch"?).   I'd have liked to say, "perform hw-reload on rising edge of Z-index signal regardless of A&B state".  But no such designation exists.  I'd rather have the choices {Low, High, Either} for both A & B config.

C. The Z-index signal must be hard-wired to the counter's default GATE pin on the 6602 board.  I *think* but haven't verified that it's user-selectable on the M-series.  Dunno if it supports just PFI inputs or also RTSI signals.  I would like to see a next-generation Counter/Timer allow user-programmable inputs for Z-index as well as encoder A & B channels.

D. At least on the 6602, the Z-index behavior is STATE-driven rather than EDGE-driven.  Z-index reload happens whenever A&B are in the programmed state and Z is High.  I tested by hard-wiring the Z-index signal to +5V and my X4 quadrature task counted 0,1,2,3,0,1,2,3,0,1...   I don't recall this being spelled out clearly in the documentation -- I remember expecting it to be sensitive to a rising edge rather than a high state.  I would very much like the option of making the hw-reload sensitive to an EDGE -- ideally {Rising, Falling, Either}.

 

-Kevin P.

 

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 10 of 21
(13,545 Views)