12-22-2005 07:06 PM
12-27-2005 02:22 PM
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,
01-03-2006 06:37 PM
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
01-04-2006 05:07 PM
01-06-2006 01:17 PM
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
01-06-2006 04:29 PM - edited 01-06-2006 04:29 PM
Message Edited by Voltage Viper [DE] on 01-06-2006 04:30 PM
01-09-2006 09:53 AM
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.
01-09-2006 10:05 AM
01-09-2006 10:45 AM
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
01-09-2006 02:49 PM
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.