Basic Buffered Edge Counting

[Kevin_Price]

You can select your device in MAX and then select the "Device Routes" tab to check, but you'll probably find that any of your counters can route their outputs to pretty much any PFI line, and any PFI line can be routed to any counter gate.  You can even do something like this where (I *think*) the signal routes internally without coming out to a PFI line at all.  (Though it *might* still show up on the default output PFI pin.)

Note: the commit will both make DAQmx define a pulse terminal for you to query and will also force the pulse task into its idle state.

What do you mean by the following?

---

It is really a pity that one cannot tell the read VI not to stop in the case of an error.

Can you post the code for the reading loop?   Error -201314 may be in the category of fatal errors that stick to the task and prevent any future useful interactions with it.  Buffer overflows are an example of such a fatal error - the task itself goes into a perpetual error state that won't go away until you at least stop and possibly also clear the task.

    The persistence of these error states is meant to be protective, based on the idea that it's better to stop giving you data altogether than to give you data that might be wrong or untrustworthy.   Your error is about failure to capture a sample when the "clock" signal called for one, so it wouldn't surprise me if it's treated as a persistent fatal error.

-Kevin P

[cghuebner]

What do you mean by the following?

It is really a pity that one cannot tell the read VI not to stop in the case of an error.

What I meant is that it would be nice if I could define what kind of error is fatal for my application. 

Background: The detectors detect single photons emerging stochastically from the sample. We'd like to record the arrival times (timestamps) for these photons. If we miss some of them if they arrive within very short times, we can handle this, as long as the time stamps for all the other photons are correct. 

Speaking of default PFI lines: We are using a self-made Cable/BNC terminal, since we feed the pulses into another registration device with 50 Ohms impedance. There, the connections physically go to the gate inputs of the counters. Is it possible to route them to another PFI line (for use as the trigger) and then still use the originally assigned counter as the one to generate the single pulse?

Best, Christian

[Kevin_Price]

Have you tried using the retriggerable single pulse idea as an alternate method for "filtering" out overly fast bursts of pulses?  How's it going?

I don't fully understand the question in the last paragraph.  There will be at least some flexibility available for you to assign PFI terminals to be routed to non-default places.  Probably quite a bit of flexibility -- what DAQ device are you using?

You can test out a lot of these kinds of things in MAX test panels or with various shipping examples.

-Kevin P

[cghuebner]

The retriggerable single pulse did the trick, however, at the cost of spending two counters for one signal. Finally, I found another solution: Prescaling by a factor 2 works as well. I clearly must say that the documantation by NI is just a nightmare. In the documentation for buffered event counting, the diagram showing the principle with gate and source is very clear. If it comes to the wiring of the create channel and timing VI's, nothing is like in the diagram. It turns out that the "gate" is the sample clock source, while the "source" is the input terminal. What???? And also for the prescaler there is no word as to which of both, source or gate, it applies.

[Kevin_Price]

But doesn't prescaling act on the Source input, a.k.a. the timebase clock?  I thought you needed to prevent rapid bursts of pulses from your detector that go to your Gate input, which acts as a sample clock in your app.

-Kevin P

[cghuebner]

Yes, it acts on the source input. The problem was that I received an error if two detector pulses occurred within one source clock cycle. With the prescaling, this cycle is now half as long and therefore short enough that the mentioned error is prevented?

[cghuebner]

From the NI-DAQmx Handbook: "Prescaling can be also used for counting edges provided it is acceptable to have an error of up to seven counts when using 8X prescaling or one count when using 2X prescaling."

The terms "event counting" and "edge counting" seem to be used arbitrarily in the handbook.

It is also not made very clear which type of measurement is referred to: Counting the number of source (input terminal) pulses in fixed time intervals (periodic signal at the gate a.k.a sample clock source) or time stamping events, with a periodic signal at the source (input terminal) and the events to stamp on the gate (sample clock source). Pretty confusing. 

Christian

[Kevin_Price]

Agreed that the terminology isn't always consistent and crystal clear.

The (very) old legacy driver kinda made you learn about low level hardware behavior of the Source and Gate inputs b/c you did your configuration in terms of Source and Gate.  The learning curve for common apps was a bit steeper, but it gave you better prep for understanding how to do some less common things.

The DAQmx API tries to abstract most of that away, referring to measurement modes like frequency measurement, edge counting, semiperiod measurement, etc.  Common apps are a little easier to set up, but the way to set up different kinds of operations aren't as obvious or discoverable.   Meanwhile a lot of the docs and MAX and pinouts still go back to the basic hardware terminology of Source and Gate.

I'll link to this very old post of mine that tries to define some of this stuff.  

Bringing it around to your app, prescaling is only applicable to the Source input, which in your case seems to be an internal timebase clock.  You're probably set up for frequency or period measurement.  The count register increments for each edge at the Source input.  The external detector pulse is directed to the Gate input where it acts like a sample clock, latching the internal count register value in a buffer and resetting the count to 0 when an active edge arrives..   

    Since the detector signal is the root of the problem, I don't think prescaling is going to be the solution.

Do you *need* to free up some of your counters?   Or was it more the case that 2 counters per detector just felt wasteful and you wanted to get back to a 1 counter solution?

-Kevin P

[cghuebner]

This is exactly the point, everything worked fine with traditional DAQ. I actually need just the source counter value for every gate pulse, not the period. As I wrote in a previous post, the appearance of two detector pulses within one source period is vary rare, and I do not care if this pulse is counted or rejected, the sole problem was that the whole VI stopped on that error. With prescaling, to my understanding, this should not happen any more, since the period of the source is now always shorter than the shortest possible time between detector (gate) pulses. 

Regarding your question: At the moment we do not need to free up counters, but we might use up to six detectors in the future. Also, the code is much simpler with the prescaler.

I agree, the most common timing is to acquire data (digital or analog) in constant time intervals, and in this case the DAQmx is more comfortable.

Christian  

[Kevin_Price]

No I don't think so.  Prescaling would *lengthen* the period of the source, not shorten it.  It'll do a divide by 2 or divide by 8 so the counter will see 1/2 or 1/8 the frequency, thus x2 or x8 the period.

And again, I'm pretty sure that prescaling only affects the counter *source* signal, the one that increments counts.  Not the *gate* signal that latches and buffers those count values.  Have you tried it yet?  I don't have appropriate real hardware available to test with, but I'd recommend you try some things out.  Start with simple example programs and save them somewhere else so you can tinker with things like prescaling.

1. Generate pulse trains with 2 of your device's counters.  Start with 50 kHz and 500 kHz.  Choose your PFI output terminals so you can reference them in a measurement task.  Run them continuously.

2. Set up a period measurement task where you give yourself front panel controls for the timebase source (which will route to the *source*), the input terminal (which will route to the *gate*), and the prescaling divisor.

3. Now you can actually try out lots of combos.  Between the 2 pulse trains you generate and the possibility of sometimes choosing the internal 100 kHz timebase in place of one of them, you've got a lot of things you can explore to see the *actual* effect of prescaling.  Just be careful about what you declare about the timebase rate when you specify a PFI terminal.  DAQmx is simply going to believe you when it does its period calculations, even if what you tell it isn't true.

    So maybe you should do your measurement in units of "Ticks" and do your counter reads as U32 integers.  Then you can't accidentally mislead DAQmx with wrong scaling.  With integer tick counts, there *is* no scaling.

-Kevin P