Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

Buffered gated event counting

Solved!
Go to solution

Dear all,

 

I'm trying to add gating to buffered event counting. The latter works, however, making it gated gives errors. Since turning the counter on and off seems simple enough, I hope I'm missing something. Gating would be in the order of microseconds, while sampling is in the order of milliseconds.

 

Below the example I tried, which gives the error: Pause trigger is only valid for event counting if sample clock is not used.

 

TaskHandle task_out;
DAQmxCreateTask( "", &task_out );
DAQmxCreateCOPulseChanFreq( task_out, "dev1/ctr3", "", DAQmx_Val_Hz, DAQmx_Val_Low, 0, 20.0, 0.5 );
DAQmxCfgImplicitTiming( task_out, DAQmx_Val_ContSamps, 2 );
DAQmxStartTask( task_out );

 

TaskHandle task_in;
DAQmxCreateTask( "", &task_in );
DAQmxCreateCICountEdgesChan( task_in, "dev1/ctr1", "", DAQmx_Val_Rising, 0, DAQmx_Val_CountUp );

 

DAQmxSetPauseTrigType( task_in, DAQmx_Val_DigLvl );

DAQmxSetDigLvlPauseTrigSrc( task_in, "dev1/ctr1" );

DAQmxSetDigLvlPauseTrigWhen( task_in, DAQmx_Val_Low );

 

DAQmxCfgSampClkTiming( task_in, "/dev1/ctr3InternalOutput", 20.0, DAQmx_Val_Rising, DAQmx_Val_ContSamps, 2 );

 

DAQmxStartTask( task_in );

// Reading

DAQmxStopTask( task_in );

DAQmxStopTask( task_out );

 

Does anyone know whether there is a different way to do this, or would I have to put a switch at the input of the counted signal?

 

Kind regards

 

(Using PCI 6601, windows 7, version 17.0.0 for NIDAQmx, c++)

 

PS One post seemed to ask something similar (post title being 'Buffered gated event counting'), but for the application in that post, buffered gated event counting was not required and a different kind of measurement was proposed.

0 Kudos
Message 1 of 7
(4,660 Views)

What error code # are you getting?  What device are you using?  The error text makes it sound like a device limitation.

 

On the other hand, the following line looks wrong syntactically to me:

DAQmxSetDigLvlPauseTrigSrc( task_in, "dev1/ctr1" )

I *think* you need to designate a terminal.  I'm a LabVIEW guy so no guarantees on syntax, but I'd be looking for something more like "/dev1/PFI2".  Note the leading '/' character used to designate an i/o terminal.  Try clearing this up first.

 

 

Edit: I tried coming up with a sneaky way to do something similar using an encoder task and taking advantage of a quirk in the Z-index behavior.  It didn't really come together b/c I remembered that the z-index reset does not have a configurable polarity, it is always active high.  An inverting circuit isn't hard to add, but if you're gonna add circuitry at all you may as well just AND your gating signal and your signal-to-count.

 

 

-Kevin P

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).
Message 2 of 7
(4,639 Views)

Dear Kevin P,

 

Thank you for your reply. My apologies for the mentioned line, it actually reads:

DAQmxSetDigLvlPauseTrigSrc( task_in, "dev1/ctr0" );

 

So a different source is used. The error code is -200145, which occurs when starting the task_in. When setting the trigger, there are no errors (all return a warning/error code of 0).

 

I tried as well the following three lines instead of the line above:

DAQmxSetDigLvlPauseTrigSrc( task_in, "/dev1/ctr0" );
or
DAQmxSetDigLvlPauseTrigSrc( task_in, "dev1/PFI2" );
or
DAQmxSetDigLvlPauseTrigSrc( task_in, "/dev1/PFI2" );

 

These all give the same error, all when starting task_in.

 

The device is a NI PCI-6601.

 

Indeed, the switch I mentioned as plan B would have the same function as the AND gate you propose. I still hope I don't need to get extra circuitry though, any sneaky way would be better.

 

Kind regards

0 Kudos
Message 3 of 7
(4,630 Views)

The "sneaky" idea can only work with an active low gating signal.  I.E., count when low, don't count when high.  It probably isn't perfect, but here goes:

 

Configure the counter for position measurement using a Two-Pulse encoder with units=Ticks.  (Later, read count values as u32 integers).  Wire your signal-to-count as your A pulses and wire the B pulse input directly to DGnd.  Set both for rising edge sensitivity.

 

Configure z-indexing to be enabled, to reset count to 0, and to do it with A High and B Low.  Wire your active-low gating signal to the Z input for the counter.

 

While the Z signal is low, active edges on A will increment your count just as it does for edge counting.  While the Z signal is high, each time the A/B state is High/Low the count will reset to 0.

 

This isn't exactly ideal for you since you'd rather just maintain an unchanging count. But you can at least go back with post-processing to find these points where the count resets and restarts and calculate the right offsets to add back in.

 

 

-Kevin P

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).
Message 4 of 7
(4,620 Views)

Dear Kevin P,

 

Thanks again. After writing my reply, I realised it is basically full of question marks. I understand it might be too much, in which case, if you have an answer to just the first question that would be great already.

 

Inverse gating is not an issue. However, and please correct me if I'm wrong, in this way there won't be any sample clock to fill the buffer? And even if there is, I need to sample every millisecond, while the gating is every microsecond, hence if the count is reset to zero every time, basically I'm losing most counts? The sampling is important for me as well, since I'm looking for very small variations in rates.

 

Therefore, for this to work, I would need to get all data from the counter continuously, and extract the rates with knowledge of the gating rate? But in that case no sampling is used anymore, so wouldn't pause triggering (also without sampling) do the same thing?

 

And if so, then variations in the readout moment (say a bit before the count is reset to zero, while counts can still occur) would cause some fluctuations in the counts as well (which would potentially nullify the effect I'm looking for)? Even with interrupts (which I didn't look into, so if this is the solution, I'll look at it first myself), if there are no counts in a certain gate period, then I would miss this period and still make mistakes?

 

Kind regards

0 Kudos
Message 5 of 7
(4,615 Views)
Solution
Accepted by topic author Kyoto

Good points.  I didn't review everything fully enough.

 

Because your "gating" operation happens at a much greater rate than your sampling, the sneaky encoder method won't work at all.  It would only have worked when there are many samples per gating event.

 

Other ideas that started coming to mind are probably not good options for a 6601 since it only supports 1 DMA channel.  Sampling via interrupts has much lower performance than DMA.  A 6602 supports 3 DMA channels but is still performance-limited (like the 6601) due to a tiny 2-sample FIFO on the board.

 

I'm starting to think your best option is to use the external AND circuit.  Another option would include upgrading your DAQ hardware for additional future options.   A PCIe-6612 is a more capable counter/timer board, but I'd probably opt for a PCIe-63xx X-series MIO board that would give you 4 similar counters plus some analog DAQ capability.

 

If you externally AND your gating signal with your signal-to-count, your 6601 should do just fine with a 1000 Hz sampling rate.   Just note that you'll need to generate that sample clock yourself using one of the other counters.  The data you get will be in units of (AND'ed pulses / sample interval).  Further note: there is a DAQmx property known as "duplicate count prevention" that you might need to configure to handle situations where there there are no edges to count between 2 consecutive sample clocks.

 

 

-Kevin P

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).
Message 6 of 7
(4,607 Views)

Dear Kevin P,

 

Thanks for all suggestions. In the end, I went for the switch (AND-port), which works as expected.

 

In each sample period there are many counts (just not in each gating period), and also I vaguely remember that the "duplicate count prevention" is on by default, but I'll have a look at it to be sure. I indeed use an internal sample clock, this part already worked, it just came to mind that gating would improve the signal-to-noise ratio.

 

Thanks again for your time.

0 Kudos
Message 7 of 7
(4,595 Views)