Basic Buffered Edge Counting

[jpedrego]

Dear all,

I used to do a lot of LabView long time ago, and I am a bit rusty...

I am trying to implement 'Buffered Edge Counting' as illustrated in the X-series manual, fig7.3 ( that I attached just in case).

I am a bit lost...

I know that I need to use the internal 100MHz clock base as 'source', and the signal that I want to know when arrives is named the 'sample clock'.

When I go to table 7.8 of the same manual is stated that for 'Buffered Edge Counting', the purpose of source terminal is 'input terminal'...

But none of the examples available on LabView (under "Hardware Input and Output" --> "DAQmx" --> "Counter Measurements") seems to correspond to a 'Buffered Edge Counting'.

I am using a bit old version, LabView 11.0.1, with DAQmx14.5. The hardware is a USB-6343 of the X-Series.

Anybody willing to share a very basic vi screen-shot to illustrate it, together with where the input needs to be connected (hardware I mean)???

Thanks in advance!!!

Confession: The worst of all is that I already did the same thing 15 years ago with a E series and I can not find the code...

[Kevin_Price · Accepted solution]

I don't have LV 2011, but here's a relevant 2016 shipping example that was back-saved to 2011.

Your approach is a bit unconventional but absolutely valid.  It just depends on what you mean to accomplish.  Your approach will essentially "timestamp" the edges of interest by counting the number of 100 MHz cycles that occurred before the edge in question.   A more typical use of edge counting would be count the edges of interest by feeding it to the counter 'source' input while sampling at a constant rate.  (The board won't support 100 MHz sampling though).

Anyway, whichever you intend, the attached example gives you flexibility to config accordingly.

-Kevin P

[jpedrego · Accepted solution]

Thanks Kevin for your piece of code.

Yes, timestamp the event is exactly what I need to do!

and your code is exactly what I needed, awesome!!!

Quick remark for the future: I had to changes the defaults to:

"Input Terminal"=>: /Dev1/100MHz Timebase

"Timing Settings: Sample Clock Source'"=> /Dev1/PFI8 (the signal I want to timestamp, with the 100MHz timebase).

Second remark: your code really should be part of the Labview examples...

Thanks again Kevin!!!

Awesome!!!

[Kevin_Price]

For the record, that code *IS* in the LabVIEW examples, at least as of LV 2016.  I literally took the example and back-saved to LV 2011 format without making any changes.  It is not in any sense "mine".

-Kevin P

[cghuebner]

Dear Kevin,

Thank you very much for sharing this information. I was searching for this since years... Since the passing of traditional DAQ, where I had implemented this type of measurement, my 6602 was retired. Now, it's back to business. I have, however, one problem. One of the detectors connected to the sample clock seems to have too short pulses, which after a while leads to a stop of the measurement with the error message that two sample pulses appeared within one clock pulse. Is there a way to ignore this and to keep the measurement task running?

Best, Christian 

[Kevin_Price]

Maybe.

You mentioned "short pulses" but seemed to describe a short period *between* pulses.  Or is it both?   I'd guess the detector pulses would have a constant width, what is it?  And what's the maximum frequency it can emit at?

The 6602 will correspondingly have some limit for the minimum required pulse width as well as the maximum frequency of external signals.  Are you beyond or near those limitations?

What's the exact error message & number?  It sounds like the kind of problem that used to be attributed to the "Duplicate Count Prevention" property.  When disabled, the counter task may error out if there are consecutive Gate (aka sample clock) signals without an intervening Source (aka timebase) signal.  Or it may simply fail to take that sample -- I think the behavior has been different for various DAQ boards and driver versions, especially back in the early years of DAQmx.  Here's a couple sanctioned articles with more info though:

https://www.ni.com/en-us/support/documentation/supplemental/21/using-duplicate-count-prevention-for-...

https://zone.ni.com/reference/en-XX/help/370466AH-01/mxdevconsid/dupcountprevention/

There's another option you might want to consider, though you'll need to do more searching here to get the details.  You could configure digital filtering for the PFI line where you connect one of your too-fast signals, bearing in mind that you will basically ignore some pulses to serve the interest of preventing task-ending errors.

-Kevin P

[cghuebner]

Dear Kevin,

Wow, this was an incredibly fast answer. You're right, it's both: the pulses are short *and* occasionally have a short period in between (basically, it is detector afterpulsing). I have attached 2 scope pictures for 2 different detectors. Interestingly, for detector 1 there is no problem, whereas detector 2 is the one causing the problems. As you see, detector 2 has slightly shorter pulses. Actually, this time the board is a 6624. The source ist synced to the 100 MHz timebase. 

The error message reads:

Error

-201314 occurred at DAQmx Stop Task,vi,

3590002

Multiple Sample Clock pulses were detected within one

period of the input signal, Use a Sample Clock rate that is

slower than the input signal, If you are using an external

Sample Clock, ensure that clock signal is within the jitter

and voltage level specifications and without glitches,

Digital filtering probably would be the best solution, as we don't want to count the after pulses anyway, although they occur rather sparsely (the routine sometimes runs for top to a few minutes before the stop).

Best, Christian

[cghuebner]

update: the digital filtering probably won't help. If I understood it correctly, it will simply sort out all the short pulses. So the width of the pulses seemingly is a problem. Or is there a way to do the digital filtering the other way around, namely, to sort of disable the sample clock for some time after the detection of an edge? The easiest way would be to simply tell the counter task to somehow ignore the error. 

[Kevin_Price]

Have you tried experimenting with the "duplicate count prevention" property?  That *might* help you avoid the error.

Another thing to try is to gang up 2 counters for this job.  The first would be a retriggerable single pulse, with all params (low time, high time, initial delay) set to the bare minimum of 2 timebase cycles, i.e., 20 nanosec.  When a detector pulse triggers it, it will be stuck in pulse generation mode for 40 nanosec and won't react to any other detector pulses during that 40 nanosec.  Once the pulse ends, it'll re-arm and be ready to be triggered again.   It will basically act to filter out bursts of detector pulses that exceed ~25 MHz.  Then your main app can measure the detector pulses indirectly by measuring this counter's pulse output instead.

-Kevin P

[cghuebner]

Thanks again for the continuing help. Yes, I fiddled around with the duplicate count prevention, however, seemingly for this type of counter it cannot be disabled. 

The use of a second counter to produce longer pulses sounds promising. Will try it tomorrow. The PFI line for triggering probably does not have to belong to a counter, right? As long as only 4 detectors are used, the 8 counters will be sufficient. It is really a pity that one cannot tell the read VI not to stop in the case of an error. It seems that this abortion of function occurs on the dll level. 

Best, Christian