Buffered gated event counting PCI 6733

[maxmustermann90]

Hi!

I am trying to do a buffered gated event counting, i.e. I'd like to count photon pulses arriving in the high time of a gate signal. I'm using a PCI-6733 card with NI DAQmx 14.2 and Labview.

I'm relatively new to Labview, and I hope I'm just missing some details. I've attached two programme snippets tackling the question from two different points of view - in example1.vi a count-edges-task with a pause trigger is used, in examle2.vi I counted the pulse width of the gate signal in ticks, with the photon pulses as time source.

Unfortunately, neither of the two yields the desired results. I tried for a gate signal which is 10µs high and around 20µs low and the following photon pulse rates:

- 10MHz: example2 yields 100 counts/gate signal pulse as expected, example1 yields 300 counts/gate signal pulse -> the pause trigger does not seem to work. What am I missing here?

- 20kHz: example1 yields 0 or 1 count/gate signal pulse as expected, example2 gives out the Error -200140 "Two consecutive active edges of the input signal occurred without a counter timebase edge." -> A count of 0 causes the programme to fail. I'm aware of the problem of duplicate counting, but couldn't find any way to set "duplicate count prevention" to true or to otherwise make the programme work. Anyhow, it does not give me out the same values again but aborts, so I'm not sure if this is actually the source of the problem.

Is there any workaround for one of the two versions to obtain a gated event counting? Or is this not at all possible with the hardware I'm using?

I'd be glad if you could point me to any forum posts/examples dealing with the problem, I couldn't find any where there has been a solution which worked out for me.

Any help is highly appreciated!

Thanks a lot for your time,

Britta

example1example2

[Kevin_Price]

The 6733 is an older board whose counters are less capable than those found on newer boards released within the past 20 years.  I can't recall for sure whether it supports the "duplicate count prevention" property as an option.  (For research purposes, the counters are based on the DAQ-STC chip.  This same chip was used for the E-series family of multifunction boards -- the bulk of info you find is likely to be in the context of these E-series boards.

Pause triggering isn't working for two reasons.  (A) It isn't fully configured.  You would also need to define a "trigger type" property and should define a polarity.  (B) Even if fully configured, I'm pretty sure you'll get an error.  Down in the hardware, the counter has an input pin which can be used either like a sample clock to latch a count register value or like an enable line a.k.a. a "pause trigger."  But only one or the other, not both.  With buffered sampling going on, you won't also be able to have a pause trigger.

    The workaround is to have a 2nd counter set up to generate a continuous pulse train while being pause-triggered.   Your 1st counter would use its output as its timing signal, knowing it gets interrupted when the pause trigger conditions are met.

-Kevin P

[maxmustermann90]

Thank you very much for the information! I'll do some research about the "duplicate count prevention" then. Actually I would not mind so much about duplicate counts (as they would anyhow only occur in situations which are not of interest), as long as I don't get any errors...

Thanks as well for the information about the pause trigger! Indeed I already tried to configure it in the way you're describing and received an error - now I know it's not due to my faulty labview code but intrinsic for the hardware.

I'll try the suggested workaround - thank you!

Britta

[maxmustermann90]

Hi,

sorry for the late update. I finally tried the workaround, and attached an updated programme. I set up ctr1 to generate a continuous pulse train, but have some issues with data transfer now. Depending on the frequency of the pulse train, I obtain Error -200141 "Data was overwritten before it could be read by the system". For 500kHz it seems to work, for 1MHz it gives the error. As I need to discard the last pulse of the pulse train (since for this one I also count during the low time of the gate signal), I'd be interested in using a high frequency of the pulse train (my gate signal is in the range of some µs, i.e. for 500kHz I'd only get two to three pulses). What is the restraining factor here? Can I go to higher frequencies somehow?

Any ideas are highly appreciated!

Britta

[Kevin_Price]

A few thoughts for you:

1. 500 kHz is already a very fast sampling rate for the counters on your device.   See this old benchmarking article where continuous measurements tested out at only 150 kHz.

2. A newer X-series board would be far more capable of supporting faster sample rates due to having a much more usefully-sized hardware FIFO.

3. I reviewed your original posting and realized that in trying to answer the question you asked, I failed to give you a better answer to a question you didn't know to ask in the first place.

   There's another way to get the measurement you want while using just 1 counter.   You would perform a pulse-width measurement using units=Ticks.  The photon pulses would be used as the timebase while your gate signal would be considered the thing to measure.  Below is a snippet to illustrate based on slightly modifying a shipping example.

When I tried it on a simulated 6733, I tried to also set up duplicate count prevention and got an error that the property isn't supported.  Consequently, I can't tell you for sure what will happen in a scenario where no timebase (photon signal) edges occur during the high time of a gate pulse.  I have a vague recollection that it may either give you a repetition of the previous value or it may simply fail to buffer a measurement.  The "correct" behavior would be to buffer a 0 value, and that's why the idea of the confusingly-named "duplicate count prevention" property came into existence.

Overall I'd recommend adding an X-series board for both the speed and behavior, but you can at least try this pulse width idea on your older board for now.

-Kevin P

[maxmustermann90]

Thanks a lot for your time and for your ideas.

Unfortunately I couldn't see the attached snippet - could you maybe please send this again? Then I can at least try this idea on the older board once.

We'll indeed consider using an X-Series board then, as the speed is a critical point for this application.

I just gave a quick check for the X-Series boards - am I correct that there is currently no board with 8 AO available?

Moreover we're planning (maybe at some point in the future) to run a similar code on the PCIe-7852 - I assume that this board is capable enough for this application?

Thank you very much!

Britta

[Kevin_Price]

Oops, after mentioning an *intention* to attach a snippet, I kept writing more stuff & forgot.  Here it is for real this time.  (I now notice I also should have changed the type of the 'Data' array in the loop to U32.)

X-series are the most versatile and common boards that would have the needed counter capabilities.  The thing to look for is the STC3 timing chip and a FIFO over 100 samples for counters.  One option is to get an inexpensive X-series boards with no AO and pair it up with your 6733 that's dedicated to AO.  You'd then likely also need to connect them with a RTSI cable (34-pin ribbon cable, they used to be plentiful in the old days of floppy drives).

An alternative that should work (but verify with NI) is the PCIe-6738.  The manual and spec sheet show it to have the STC3 timing chip, a 127-sample FIFO for counter tasks (same as the X-series boards), and a full 32 channels of AO.

As to the 7852, that appears to be an FPGA-based board.  You wouldn't be able to run the same program on that board, you'd need to program differently for the FPGA.  Beyond that, I don't know the board well enough to say whether it has the inherent capability of being used for your app.  You'd need to explore this with your NI rep.

-Kevin P

[maxmustermann90]

Thank you for the snippet!

I indeed set it up now with a pure counter board paired with the 6733 and this works perfectly. I'll try the snippet at some point on the 6733, but I'm relatively sure I already tried something similar and got problems when there were no photon counts during one gate signal.

As to the FPGA 7852 board, I'm aware I won't be able to run this exact program, but I'll talk then to my NI rep to check whether it has the capabilities for this application.

Thank you for your help!