Reset counts trigger

[dmkopeck]

Hi,

I've Constructed a VI which displays an image on a second screen and cycles through images via an event structure. I would like to generate a trigger upon completion of the loop which would be used to trigger the count reset of the Counter- Count Edges VI. Is this something I can do with my current hardware? If so, what do you suggest?

I am using LabVIEW 2020 with a PCI-6602 and BNC-2121.

Thank you,

Dillon Kopecky

[Kevin_Price]

I don't think the 6602 supports the count reset feature.  You'd need the newer 6612 or an X-series MIO device (or something else built around the STC3 timing chip).  But counters are very flexible and there's probably another way to get you where you need to go.

Describe more about this edge counting task -- what are you counting?   How are you capturing the count data (is it software on-demand sampling or hardware-clocked)?  How does the count reset operation help you?

-Kevin P

[dmkopeck]

Kevin,

I have a 6612 I could try but I was able to test that the count reset feature works on my hardware by inputting a TTL pulse to PFI0 and measuring the counts from a photon counting photomultiplier module on counter 1, which reset when the trigger was received at PFI0. I've been considering an alternative VI for my application.

I am trying to display an image on a second screen which is measured using a photon counting photomultiplier module. I want the image and photon counts to correlate. Instead of trying to synchronize loops I'd like to generate a TTL when my image cycles, which would trigger counts to rest in the count edges VI resetting the photons counts for each image. Ideally this VI would run faster and not suffer from the backlog issue I'm getting with the previous VI.

I'm unsure, but I think it must be software on-demand sampling with the count edges VI.

I've been reading up on the 6602 and its seems like counters 2-8 are limited to either all input or output, so I'm unsure if I could output a pulse and read it on the PFI lines.  

Thank you,

Dillon Kopecky

[Kevin_Price · Accepted solution]

I was surprised that you seemed to get count reset behavior on the 6602.  It had been my understanding (until now) that the newer STC3 chip would be needed to support that.  So I did some more in depth research around here and found:

1. The initial announcement of its implementation from 2010 -- only for X-series and 2nd-gen cDAQ chassis at that time.  Since this was a direct response to my idea submission, this limitation stuck in my mind.

2. A more recent help document from 2019 suggesting that count reset IS supported on the 6602.

3. A closing comment from 2013 by a very knowledgeable ex-NI employee that I must have never interpreted correctly.

It appears that the 6602 does indeed support count reset in *some* circumstances (software-timed on-demand tasks), but it does not support it in others (hardware-clocked buffered tasks).  There's only 1 internal counter pin to support one behavior or the other, but not both at once.

That's unfortunate, because you likely OUGHT to be planning on taking your photon measurements with a hardware-clocked buffered task.  The hardware clock is likely necessary to give you the proper degree of sync with the frame captures from your independent camera.

All in all, you should switch over to the 6612 which has several enhancements over the 6602.  The ability to do hardware clocking together with count reset is the one we're discussing here, but the bigger hardware FIFO can also be crucial for sustained high-bandwidth tasks.

It's been over a decade since I last used a 6602, but I'm quite sure that there aren't any input-only or output-only restrictions on the counters.  Any of them can be set up for either direction.  If I recall correctly, only Ctr0 and Ctr1 had *dedicated* PFI lines.  Ctrs 2-7 used PFI lines that are shared with DIO.  That can lead to conflicts and task errors if you try to configure the same pin as both a DO output and a Counter output.  Such sharing IS allowed as long as one of them (either Digital or Counter) treate the PFI line as an input -- then the other is free to treat it as either input or output.

Very generally, you're going to need to start thinking of sync happening via precision-timed hardware signals, NOT via software that monitors, compares, decides, and initiates a response.  You seem to be taking a hybrid approach where there's a little bit of hardware stuff, but also still some reliance on slower, less repeatable, less predictable software timing.

-Kevin P