Problem with long dwell times on counter input

[PhotonCoder]

Dear all,

I am currently writing a readout application for a photon counting module (produces 10ns pulses in irregular intervals, which I want to count using a NI USB-6212). The counting itself works quite nicely thanks to a VI from user John_P1. The VI I adapted from his solution is attached to the question. As far as I understand his solution it is based on counting the period of the internal clock of the DAQ board against the "timebase" of the 10ns pulses from the counter, which means that the period of the internal clock is then simply the elapsed pulses of the photon counter.

Now: Due to the irregularity of the signal it might be that the counts will be as low as 20 per second, which means that if I set the dwell time to very low values, say, <10ms, my counting might be very inaccurate as I might catch only a single photon or no photons at all during this very short time period. This is not an error of the DAQ board or the detector, it simply means that the signal that is to be counted has very, very few pulses. This is why it would be very advantageous to set longer dwell times, such as 50ms to 1s. However, when I do this, I get the following error:

Error -200284: Some or all of the samples requested have not yet been acquired.

I do not understand this error as it occurs when I set a longer dwell time, other than, say, a shorter dwell time (which is where either the computer or the hardware cannot keep up with each other in continuous readout). Can you help me with this? Help would be greatly appreciated.

Best

[Kevin_Price · Accepted solution]

1. There are no wait times or specified timeouts in the code.  It's unclear what you mean by "dwell time".

2. You've created several problems for yourself in the course of "adapting" whatever specific code you started from.   (I'm confident of this mainly because I remember when John_P1 was very active around here, and his posts and examples were universally excellent.)

3. You almost certainly shouldn't be starting and stopping your tasks inside your loop.

4. You 100% certainly shouldn't be stopping your pulse train task immediately after starting it.

5. Reading 2 samples at a time is probably not going to be ideal.

6. You *may* find that you need to set a DAQmx property known as "duplicate count prevention" to cover situations where photon emission rates are slower than your counter pulse train.

Attached are a few fairly minimal mods I made that ought to get the code working better.  You'll probably want to add or change a few things, but hopefully it gives you a better place to start.

-Kevin P

[PhotonCoder]

Hey Kevin,

thank you very much for your input. I have downloaded your VI but as I currently don't have access to the lab due to COVID I will only be able to try it on Monday. Still, I want to respond to each of your suggestions as I do want to understand what is happening so I can write better code in the future.

1. With the wait time/dwell time I meant the integration time that is set.

2. Fully agreed. The original code is linked Original thread here for completeness sake so it is useful for other people in my situation.

3. and 4. The way I want to use the counter is in tandem with other hardware. In my naive understanding, I change something in the hardware, e.g. stage movement, leading to different signal, and my code tells the DAQ board to start the counting task only after the stage has moved, and stop it after the samples have been acquired. Going from your code example and also John_P1's, would it also be fine to just let the counter run continuously, and use only the DAQMX Read instead of additional start/stop (my example) after the stage has moved?

5. The 2 samples with additional indexing of only taking the 2nd sample was my attempt at accounting for John_P1's statement 'Also, the very first sample is not useful as it represents the count between the software starting of the counter input task and the first clock signal--you should disregard/delete the very first sample (or if you want you may configure an Arm Start Trigger).'.

6. Thank you, I will keep it in mind.

Thank you for taking the time to write this up - I will follow up after the weekend after I've tried out your code if you're interested.

Best

[Kevin_Price]

The best way to approach this counter task will depend on how closely you need to sync your measurements with your stage movements.

At the easy end of things are apps that can accept software-based decision logic and timing.  You wait until the stage motion has completed, then you fire off the counter task (perhaps as a finite sampling task, perhaps continuous).  Measurement starts "soon" after the stage arrives at its position, but the timing for exactly how soon will vary.

At the more precise end of things are apps that need hardware-level sync between the measurement task and other elements of the system.  These can get trickier, so if you think you need this level of timing and correlation precision, it'll take a longer discussion.

-Kevin P