Retriggerable buffered counting edge task

[skuo1008]

Dear all,

I have been working on "Retriggerable buffered counting edge task" on a single counter input channel, let me describe what I want to achieve:

Create a CI to count finite rising edges with external sample clock (eg. Dev1/di/SampleClock) at certain sampling rate, and set CI.edge.Term at one PFI which is hardwired to another digital input channel. Furthermore, I'd like to set "retriggerable start trigger" to this CI by another PFI line.

It turns out that I can only set "arm start trigger" on this counter input channel, instead of "start trigger" since the error of 200452: attribute not supported in task context showed up at configuring digital edge start trigger. It seems that I can only set "retriggerable start trigger" on counter output task, and use two counters to achieve above, but I was wondering if there is a way to accomplish by single counter. Any suggestion is highly appreciated.

[skuo1008]

I forgot to mention the card is PCIe-6363.

[John_P1]

The start trigger isn't supported for counter inputs (and therefore retriggerable counter inputs aren't supported either).

Can you elaborate on your application?  Why do you need a start trigger?

Best Regards,

[skuo1008]

I am using a counter to count rising edges (buffered) on another digital input channel. I was using di/SampleClock as counter's sample clock for synchronous acquiring of these two channels. The DI channel is acquired in finite mode and set retriggerable by a designated PFI. Since I want CI to be synchronous with DI, I would expect to set start trigger on CI as well. Obviously, it is not possble based on your reply. I am aware of that counter input only has "arm start trigger" instead of "start trigger", and now I am able to achieve above with two counters setup. Just wondering if there is a better way by using single counter.

[John_P1 · Accepted solution]

Set the CI task to be continuous--it will only take samples when the finite DI task is triggered which is effectively the same thing as having a finite retriggerable CI task.

If you want the count to reset each trigger, you could configure the trigger input as a count reset line as well.

Best Regards,

[skuo1008]

Thanks a lot, I will try that, but I would like to confirm the outcome of both cases:

1. without reset counter, the counter value will continue increase (counting up) while digital signal is coming into DI channel.

2. with reset counter, the counter value will always start from the same initial value.

Am I right? 

[John_P1]

Once armed, the counter will increase regardless of whether or not you are sampling the count register.

Using a reset signal lets you reset the value of the count register to some pre-determined number (e.g. 0).  So in your case, you could start from 0 at the beginning of each trigger (if that's what you want to do).

Best Regards,

[skuo1008]

Dear John,

I just tried and run into another issue with overflow. The idea is to synchronize this counter with finite DI and to read both buffers out when DI's buffer is filled. Since I am running CI in contineous mode, it seems to be reasonable to run into overflow on buffered CI after a couple of triggers; Error: -200279 when trying to read CI buffer. Is there a way to skip/ignore overflow but still read buffer with size that I specified at attribute of SamplePerChannel? or any better idea of design to achieve what I am trying to do? I was wondering how effective it would be by increasing buffer size to avoid overflow since no known pattern on the trigger signal.

Really appreciate your help. Thank you.

[skuo1008]

In fact, it was not overflow error since the available samples per channel became 0 at the third trigger. I am pretty sure it is not insufficient buffer size because I am running way below the limit. I will continue to try if I can figure something out here.

[John_P1]

I would increase the buffer size (DAQmx Configure Input Buffer.vi).

The size depends on the sample rate, number of samples in the DI task, rate that you are triggering, and rate that you are reading back sampels.  There isn't really any harm in configuring a larger buffer than necessary other than increased memory usage.

Best Regards,