Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Edge counting in a loop too slow

Solved!
Go to solution

Hi all,

I am using USB-6361 for photon counting. I want to get the photon number (light intensity) of corresponding patterns projected by a projector, and use it as feedback to optimize the pattern to achieve the highest intensity. Here the DMD_trigger_line is a digital signal that tells the card when to count; the MPD_acq_line is a TTL signal to be edge-counted. However, the time of each iteration is much longer than the total projected time. I suppose it is because I start and stop the task in the loop. I check other posts and find that there is something called retriggerable task. However, it seems that counter-input task does not have this property (I check that for ai channels and it works, which means my device supports such functions). I am wondering if ci task has a way to start/stop outside and read inside the loop. Or is there any other thing that can speed up this process?

 

Here is my python code:

counter_channel = "Dev1/ctr0"
DMD_trigger_line = "/Dev1/PFI0"
MPD_acq_line = "/Dev1/PFI1"

sample_number = 65



read_task = nidaqmx.Task()
read_task.ci_channels.add_ci_count_edges_chan(counter_channel,initial_count=0,edge=cst.Edge.RISING,count_direction=cst.CountDirection.COUNT_UP)
read_task.channels.ci_count_edges_term = MPD_acq_line
read_task.timing.cfg_samp_clk_timing(rate=sample_rate, source=DMD_trigger_line, sample_mode=cst.AcquisitionType.FINITE, samps_per_chan=sample_number)



for n in range(200):

    # Here I hide the code for projecting sample_number=65 patterns
    read_task.start()

    read_task.wait_until_done(timeout=cst.WAIT_INFINITELY)
    photon_count = read_task.read(number_of_samples_per_channel=sample_number)

    read_task.stop()

    # Here I hide the code for optimization


read_task.close()

 

If I directly put start/stop outside the loop then it would not read data for the second time. When I try to use

read_task.triggers.start_trigger.retriggerable = True

it says "Specified property is not supported by the device or is not applicable to the task." I can understand why it happens but cannot figure out another solution. The optimization works well but is just quite slow. Could you please give me some ideas?

 

Thank you in advance,

 

0 Kudos
Message 1 of 6
(798 Views)
Message 2 of 6
(782 Views)

I'm not exactly sure what you're trying to do here.  I don't use Python, but it appears that you're configuring DMD_trigger_line as an edge-sensitive sample clock while your verbal description *sounds like* you want it to be a level-driven gating signal (aka "pause trigger").

 

You also configure for finite sampling, but are concerned about missing data between iterations.  So why finite instead of continuous?

 

Please describe your goals and intentions in more detail.  I can't really offer up much in the way of directions until I know where you're trying to go.

 

Now some info:

- counter *input* tasks cannot use the regular Start Trigger.  They need to configure an "Arm Start" trigger instead.  Can't tell you why, but it's been that way since the dawn of DAQmx (circa 2003-2004?) and before.

 

- the Arm Start trigger cannot be set to be retriggerable

 

- counter *output* tasks *can* use the regular Start Trigger and *can* be retriggerable

 

- there are ways to combine multiple counters working together to accomplish things that a single counter cannot.  This may prove useful for you, but I can't tell for sure yet.

 

 

-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).
0 Kudos
Message 3 of 6
(757 Views)

Hi Kevin,

 

Thank you for your reply!

Here I draw an illustration to show what I try to do. I hope it is clear. DMD_trigger_line is the sample clock and MPD_acq_line is the digital input to be counted.

Screenshot 2023-03-04 205201.png

I guess continuous sampling would be a good idea, but I'm not sure if I can read the data in the loop again and again. Then it would be great.

Here I reset the counter value just to mean that I don't care about the data between iterations. In fact, I will calculate the difference, e.g., [5,3,4] for the first loop and [3,4,3] for the second one.

 

Thank you in advance!

0 Kudos
Message 4 of 6
(745 Views)
Solution
Accepted by topic author Kate97

Still not fully clear on all the details.  If you expect DMD_trigger_line pulses to come in groups of 65, without really long intervals from the end of one group to the start of the next, you very much should be able to configure your edge counting task for continuous sampling, start the task just once before the loop, perform reads of 65 samples each iteration of the loop, and then end the task just once after the loop is done iterating.

 

There are also ways to configure the counter so that the differences you care about are captured directly in the hardware.  Namely, you could do period measurement with units of "Ticks".  This is a bit more of an advanced usage which requires non-standard configuration and a little bit of "inside out" thinking about the role played by your signals in the counter task.  It's probably unnecessary for you this time around, but can be worth being aware of as another option.

 

 

-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).
0 Kudos
Message 5 of 6
(729 Views)

Hi Kevin,

 

Thank you so much for your advice! I configure it to continuous sampling and now the time is as expected. I didn't find a way to capture the differences directly but it's fine. Maybe I will look into it when I deal with larger data.

0 Kudos
Message 6 of 6
(682 Views)