measuring counter periodicaly

[Olivier.Blanc]

Dear all,

So I have a counting edges task :

DAQmxCreateCICountEdgesChan(aoTask, "Dev1/ctr1", "", DAQmx_Val_Rising, 0, DAQmx_Val_CountUp);

wich I can interogate by the click of a button :

DAQmxReadCounterScalarU32(aoTask,1 ,&count,0);

now I would like to interogate this counter periodicaly  using an external clock and store the results in a buffer.

DAQmxCfgSampClkTiming(aoTask,"/Dev1/PFI15", samplesPerSeconds, DAQmx_Val_Rising, DAQmx_Val_ContSamps, bufferSize);

up until that point, I followed blindly the "Cnt-Buf-Cont-ExtClk" example. but it doesn't work : every time I try to read the buffer

DAQmxReadCounterU32(aoTask, bufferSize, 1.0, counterData, bufferSize, &read, NULL)

I get the following error message :

Some or all of the samples requested have not yet been acquired.

To wait for the samples to become available use a longer read timeout or read later in your program. To make the samples available sooner, increase the sample rate. If your task uses a start trigger, make sure that your start trigger is configured correctly. It is also possible that you configured the task for external timing, and no clock was supplied. If this is the case, supply an external clock.

Property: DAQmx_Read_RelativeTo

Requested Value: DAQmx_Val_CurrReadPos

Property: DAQmx_Read_Offset

Requested Value: 0

Task Name: _unnamedTask<1>

Status Code: -200284

even if I wait enough to be sure that the buffer is full...

so I tried to trigger the reading with a "every N Sample event"

DAQmxRegisterEveryNSamplesEvent(aoTask, DAQmx_Val_Acquired_Into_Buffer, bufferSize, 0, EveryNCallback, this);

but the function is never called.

I don't know what I doing wrong here, is my external clock badly configure (wrong source) or something else???

I'm using a PCIe-6351 and I code in CPP using DAQ-mx

Thanks in advance for your answer

[Kevin_Price]

I'm a LabVIEW guy who doesn't know the syntax of the text-based API.  Here are some general thoughts with that caveat in mind:

- it seems odd that you're making a counter task with regular reference to a function parameter named "aoTask".  This may end up being a meaningless name for your variable, but it strikes me as a point of suspicion

- the error you get sure sounds like you simply don't have a valid clock signal at the expected external pin "/Dev1/PFI5"

- assuming MAX is installed with the DAQmx driver, I'd try to test the assumed external clock.  Go to the MAX test panel for your device and try doing some edge counting on the PFI5 signal.  See what you get.  You should see a number that increments at the expected clock rate.

-Kevin P

[Olivier.Blanc]

Thanks for your answer Kevin!

It was just that I hadn't wired a clock to the "/Dev1/PFI5". I was actualy presuming that the routing was done internaly. Do you know if that is possible, rerouting clock signal internaly. I remember seeing fonction with name imlying such a thing. I'll have to look for them.

The next thing I'm trying to do is to gate the measurement to an external clock. To only count when true to stop when false an restart when true again etc etc.

What is best to use a "Change detection Event" or use a trigger like the  digital edge advanced trigger "DAQmxCfgDigEdgeAdvTrig"?

I'm not really sure to understand whatof both function actualy do.

[Olivier.Blanc]

@Zimou13

did you make sure that your clock is faster that your acquisition rate?

[Kevin_Price]

There's a lot of options available for signal routing between PFI pins and internal counter terminals.  But any external clock will have to be physically wired to a PFI pin first.

The counter when True, stop when False could be implemented with a Pause Trigger configured to pause when low.  However, watch out!   If all you do is turn counting on and off once in a while, the buffer of data will still *look like* continuous counting.  When paused, no counting occurs so when un-paused the count just picks up again from where it left off.  There's no good way to identify and know where the pause intervals happened or how long they were.

I don't think Change detection helps you particularly, plus change detection would be implemented with a DI task.  I'm not familiar with the "digital edge advanced trigger."

-Kevin P

[Olivier.Blanc]

Thanks a lot for your answer Kevin.

I would have another question about counter mechanism.

So far I have managed to do what I wanted which consist in interogating the counter every µs (can be change) and then transferring the data every N intererogations (buffer of N). What I don't understand is what's the clock behind the counter.

I'm using a pcie 6351 as my DAQ. specifications tells that the counter can use 3 internal base clocks : 0.1/20/100Mhz. But I do not specify wich to use in my code, and I haven't found a way to know which one is used. does anyone have an idea about that?

I suppose that the counter works by measuring the voltage every ticks of its internal clock. Assuming that it is using the 100 MHz clock, it measures the tension every 10ns, if it's high the counter gets incremented if it's low it doesn't. Am I right?

I know that my code produce coherent results but I'm well within the card parameters. I'm wondering how much farther I can push the card?

Thanks in advance for your answer

OB

[Kevin_Price · Accepted solution]

You say you're "interrogating" the counter every µs -- does that mean that you've set up sampling with a 1 MHz sample rate?   Then that IS your clock.

This is a way that counters are different than AI or DI.  Counters involve a hardware count register that increments on digital edges.  This is a hardware function and unlike AI or DI, you don't need to sample at a high rate to make sure you count accurately.  Each edge will increment the count register, each sample clock will store an instantaneous value of the count register.

You may be sampling much faster than necessary.  If you've set up 1 MHz sampling based on thinking you need to sample at least 2x the fastest rate of incoming edges, that's incorrect.  The sample rate can be entirely independent of the rate of incoming edges.  You can sample 1000x *slower* than the edge rate if you want.  Every successive sample would just show a larger difference in count value.

To answer your direct question, no the card does not measure voltage every cycle of its internal clock.  Edge-sensitive hardware causes a count register to increment exactly once on every digital edge of the chosen polarity.  Your ability to *capture* that changing count value over time is what you accomplish with a sample clock.

-Kevin P

[Olivier.Blanc]

Thanks a lot Kevin! Now I understant better. Would you know how fast can the Edge Sensitive hardware go?

[Kevin_Price · Accepted solution]

NI's boards will always be able to handle *internal* signals as fast as the board's max timebase.  For a 6351, that'll be 100 MHz.

The spec for external signals (where NI can't control the signal integrity) tends to be a little lower.  I'm not sure whether the input circuitry drives *all* this limitation (so that the spec is a pretty hard limit) or just part of it (so that good, clean, strong external signals may work at rates above the spec limit.)  For your board, the spec seems to be 25 MHz and is labeled as the "external base clock frequency."

To sum up: the internal hardware that increments the count register works for edges up to at least 100 MHz, but the board's input circuitry may not be able to cleanly deliver external signals above 25 MHz down to the counter hardware.   And again, the process of incrementing the count is entirely separate from the process of sampling the count.  You can sample as slow as you like without losing counts or you can sample as fast as your system allows.  I can't seem to find the link, but by memory I believe it's been benchmarked at over 10 MHz for X-series counters.

-Kevin P

[Olivier.Blanc]

OK, thanks Again