counter problem

[Stephan Bahr]

Hi, I´m using the two counters of my PCI6036E für simple event counting. I count the rising flanks of a TTL signal coming out of a Leybold energy analysator. My problem is that, ever when I open another application next to my measuremnt executable or browsing the network or simply doing something else with the PC (Athlon XP 1700+) than the counters get wrong values. So the recorded spectra look like this (see the link below). So every programm I open and every folder I browse produce spikes in spectra. How can I prevent my counters from counting wrong values.
My programs is adapted from the example "Count Edges (DAQ-STC)". The programm is written with Labview 7.1.1 but the problem is also reproducable in LV6.1 and 7.0.

http://www.pe.tu-clausthal.de/~pesba/download/niforums/counter.jpg

Thanks for your comments

Greets

Stephan

[gus]

I'm not sure that I understand your graphs, but if the graph is depending on a smooth change in counts on every read in a software timed acquisition like simple event counting, then you will definitely see some differences when running other programs at the same time. To ensure that your measurements are occurring consistently with a constant duration between measurements you should be using buffered event counting ("Count Buffered Edges (DAQ-STC).vi").

I hope this helps!
gus....

[Kevin_Price]

I'll second what gus said -- what you described and displayed is consistent with simple (unbuffered) event counting where you poll the counter values in a software loop. The time between successive samples is driven by software execution time, which can vary when Windows decides to give the other task you started some of the CPU allocation formerly used by LabVIEW app.

You can avoid this by setting up your counters for buffered event counting -- you can find examples either under help or here on ni.com. Note that on your board at least one of the counter tasks (and maybe both, depending on whether you are running any analog acq) will need to use interrupt-based transfers rather than DMA-based. This will limit your sampling rate somewhat, but for a finite sampling task you'll have a decent shot at several kHz.

Note also that with both counters tied up in measurement, you need a different source to act as a sampling clock, aka a Gate signal under traditional NI-DAQ. I would guess but am not 100% sure that your best bet would be to set up an analog output task configured as hardware-timed single-point. That should allow you to generate a clocking signal to share with the counters without tying up DMA.

-Kevin P.