Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

Counting pulses using PCI 6602

Here's a simple finite diff where the first count value will be preserved as the first diff value.  It also illustrates an efficient way to handle the rollover issue.  (Conversion between u32 and i32 doesn't require any bit operations, just a flag to indicate which of 2 interpretations are applied to the unchanged bits.)

 

 

-Kevin P

 

finite diff.png

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 21 of 28
(5,112 Views)

Thank you very much.I will implement it and let you know if it works.

 

-snh22

0 Kudos
Message 22 of 28
(5,108 Views)

Hello Kevin,

 

In the last post you suggested that I am not getting counts for frequncy greater than 20MHZ  due to duplicate counting.So I just disabled duplicate counting property and the program is giving me correct counts now.So I did not implement the count edges program.

 

Now that I get correct counts my program works only for a few seconds before it shows buffer overflow error.Is there any way in which I can clear the buffer after I have written the pulse count in the file?For example can I read 1000 counts and write those counts  and then clear the buffer.What I mean is if I clear the buffer after every short interval of time then I won't have buffer overflow at all.Is that possible?

 

Thank you.

 

Snh22

0 Kudos
Message 23 of 28
(5,074 Views)

Which error code are you receiving?

 

There are two different forms of buffer overflow that you might run into:

 

1.  If the data cannot be transferred from the hardware fast enough, the on-board FIFO will overflow. 

 

One feature that the 6602 is lacking compared to more recent DAQ hardware is an adequately sized onboard FIFO for high rate continuous counter measurements.  The manual has some transfer rate benchmarks that you might find interesting.  A 1 us sample interval (which you mentioned earlier) is probably not sustainable (though the numbers in the benchmark are from a very dated PC, so I wouldn't be surprised if you can get higher than what is shown in the manaul).  You should make sure the channel's "Data Transfer Mechanism" is set to DMA  (it's settable via a DAQmx channel property node), though I believe this should be the default.

 

If your issue is this one, you might consider a newer X Series card for this application (benchmarked up to 20 MHz).

 

 

2.  If your applicaiton is not reading the data quickly enough, the software buffer would overflow.  There is no need to "clear" the buffer--it is circular and old data is overwritten as new data comes in.  The error you would see would occur when you try to read samples which have already been overwritten (presumably you don't want to miss samples).

 

This problem should be solvable without any hardware changes--the software buffer size is configurable and you can read back however many samples you'd like per loop iteration.  

 

You could even avoid the requirement of reading altogether if you configure the DAQmx TDMS Logging feature (set to log only) which will write directly to disk from the software buffer.  If you're actually logging counter data to a file at 1 MHz then I would suggest using the TDMS Logging anyway.

 

 

 

Best Regards,

John Passiak
0 Kudos
Message 24 of 28
(5,060 Views)

Hello John,

 

Thank you for the reply.The error I am getting is "Error 200141 - data was overwritten before it could be read by the system".I tried your suggestion about reading the specific number of samples per loop iteration.Now my program does work for around 15 minutes but eventually it gives me the same error.I am also using TDMS is my file type for saving the data as you suggested.Is there any other way possible to stop the buffer overflow so that the program runs at least for an hour?I need at least that much for my application.

 

Thank you for all the help,

 

Snh22

0 Kudos
Message 25 of 28
(5,018 Views)

-200141 is the hardware buffer overflow.  Did you confirm that the data transfer mechanism is set to DMA (I believe it is the default though...)?

 

Untitled 1 Block Diagram _2015-02-10_14-20-44.png

 

There isn't much else I can suggest--keeping the CPU usage down might help a bit (which is likely why reading a fixed number of samples per loop helped as this would slow down the loop rate).  I'm confused though, since if you use "Log Only" mode you wouldn't need to read at all.  It would be worth trying this ("Log Only") if you haven't already.

 

If you're still having problems, you might consider switching to an X Series device (e.g. 6320) which has 4 counters which can sustain much higher transfer rates (if you decide to do this, use a PCIe version, not USB).

 

 

Best Regards,

John Passiak
0 Kudos
Message 26 of 28
(5,005 Views)

Hello John,

 

My data transfer mode is set to DMA.I don't exactly understand what you mean by " Log only"  though.Currently what my VI does it reads the specific number of sample and then writes it into a file( file format  is TDMS).Is this same as "Log only".If not how do I implement "Log only"?

 

 

Thank you 🙂

 

snh22

0 Kudos
Message 27 of 28
(5,001 Views)

DAQmx has an integrated TDMS logging feature, you can configure it by calling DAQmx Configure Logging before starting your task.  Setting the logging mode to "Log" will write the data directly to disk from the kernel buffer without having to transfer the data to application memory. 


Best Regards,

John Passiak
0 Kudos
Message 28 of 28
(4,999 Views)