LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

DAQmx counting acquisition with interval time

Solved!
Go to solution

Dear sir,

 

Hi, I enjoyed in project as a graduate students.

 

I have setup a single photon counting system by using a single photon counting module(Excelitas SPCM-AQ4C) and PXIe6358.

 

I have a question about how does edge counting system work with time interval.

 

Specifically, What I need is :

Edge of TTL signal from SPCM is counting with 1. certain time interval and 2. wait time.

 

Object:

Repeat edge counting as: Acquisition - wait - Acquisition - wait -  Acquisition - wait  ....

 

I use external time source and it is exploited in sample clock source.

For example, the time interval is set as 500 us, so I set the sampling rate as 1.25E+06 and number of samples as 625.

 

The problem is the part of wait time.

When I use wait funtion in loop, it counts the TTL output during 500 us + alpha (setting in wait function).

I was attemted to use the wait time to stop until next acquaition step.

Unfortunately, it acquisites during the wating time..

 

I attached my VI. 

 

Any assistance would be greatly appreciated!!

 

Thanks a lot!

 

Jun.

 

 

 

 

 

 

 

 

 

 

 

I attached my VI. 

 

Any assistance would be greatly appreciated!!

 

Thanks a lot!

 

Jun.

0 Kudos
Message 1 of 10
(3,174 Views)

Sorry, I don't *quite* understand what you're trying to do.  However, I'm forming some suspicions that you may have a misunderstanding or two about how counter functions and tasks work.

 

Unlike AI and DI, with counters you do *not* need to have a sample rate that's 2x-20x as fast as the signal being characterized.  Sampling and counting are two pretty much independent things with counters.  With other I/O, sampling is the only thing there is.

 

Your use of the rather high sample rate of 1.25 MHz makes me suspect that you're aiming for a sample rate that's at least 2x the fastest expected pulse rate.   That's the kind of thing you'd *need* to do with an AI or DI task, but it can actually be undesirable with counter tasks.  It's much more typical that the sample rate will be very much lower than the frequency of the pulses being counted.

 

You should also almost certainly be configuring DAQmx Timing for either Continuous or Finite Sampling, *not* Hardware-Timed Single Point.

 

My suggestions, at least for getting started (and I'm somewhat guessing b/c I don't quite understand your problem description):

  1. Try using a sample clock frequency of 1000 Hz instead of 1.25 MHz
  2. Configure DAQmx Timing for Continuous Sampling.
  3. Inside your loop when you call DAQmx Read, specify 100 as the # of samples to read.  That'll make your loop iterate 10 times a second.
  4. Your consumer loop needs work.  Failure to wire your data array across the True case is a bad habit that's asking for future problems.  Either wire it up, or simply get rid of the case structure entirely.
  5. More consumer loop stuff: there's little point in dequeuing the data as fast as it comes into the queue only to stuff it right back into a growing array.   Also, Insert Into Array isn't being indexed properly anyway.  What you should do write to your file incrementally in the consumer loop.  Then you don't have to accumulate the data in a growing array at all, neither the wrong way you're trying now, nor the right way (Build Array, set to "concatenate" mode).   You should also use the slightly lower level file functions so you can open the file before the loop, pass the file *refnum* into the loop for your writes, then close it after the loop.  The function you have there now wouldn't be good inside the loop because it would wastefully open and close the file every iteration.
  6. Watch your queue datatype!  You've defined it to be a waveform, but are enqueing an array of u32 integers.  Counter tasks don't produce waveforms so the queue datatype should also be an array of u32's.
  7. There's no need for the first sequence frame.  The only useful thing the 2nd one does is put a better initial Tick Count value into your shift registers for the very first loop iteration.  You're probably better off without it, mainly for the sake of not developing the bad habit of relying on sequence structures too much.
  8. Your error wire passes *behind* DAQmx Start rather than being wired in and out.
  9. Try sending a a known TTL square wave of ~100 kHz into your 'Input Terminal' to test things out under known and controlled conditions.
  10. Step back and be amazed at how well things run!  (I hope. If I didn't miss something.)   Your data will be count values that increment at a steady rate of about 100 counts per sample.  Possibly exactly 100, but it'll depend on how exact your input and sample clock frequencies are.  Your producer loop will iterate with a very consistent 100 msec period.  Probably your consumer too, but the file writing makes this not quite as certain.
  11. Eventually, you'll want to work on a more complete loop termination strategy that'll likely involve paying attention to your errors. 
  12. Give thought to the fact that a lot depends on having a good sample clock signal at PFI2.  Without it, your first producer iteration will get stuck waiting for the 10 sec timeout you wired into DAQmx Read.  Subsequent iterations will go really *really* fast (and produce empty data arrays) due to retaining the error in a shift register. 

 

-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).
Message 2 of 10
(3,128 Views)

Dear Kevin.

 

I appreciate to your detailed comments.

 

I didn’t recognize the independent relation between count tasks and sampling rate.

 

Unlike AI and DI, with counters you do *not* need to have a sample rate that's 2x-20x as fast as the signal being characterized.  Sampling and counting are two pretty much independent things with counters.  With other I/O, sampling is the only thing there is."

 

From this comments, It was ensured that I don’t have to use the sampling rate and sampling source when I setup edge counting system!

 

" Your use of the rather high sample rate of 1.25 MHz makes me suspect that you're aiming for a sample rate that's at least 2x the fastest expected pulse rate. 

That's the kind of thing you'd *need* to do with an AI or DI task, but it can actually be undesirable with counter tasks."

 

Exactly Right! I tried to and need to count the TTL pulse as fast as possible because I’d like to exactly count the TTL signal and the exact number of pulse.

 

Q. 1

I can understand that the exact count system does not depend on the sampling rate.

Then, what factors strongly have a impact on the performance of counting system?

(I guess that the answer is the spec. of DAQ hardware, but what spec.? sampling ) 

Actually, I have two DAQ hardware (PCI-6612 & PXCI-6358).

In my experience, the PXCI 6358 can exactly count the incident TTL signal.

What factors can makes PXCI-6358 get the exact counts..?

 

Q. 2 

Kevin, then as you recommended, When I use a sample clock frequency of 1000 Hz (with Continuous Sampling) and 100 # of samples to read in DAQmx Read, does it count TTL pulses per 0.1 sec? is it right? (I uploaded Fig.1 to explain my understand)

 

If I correctly understand,

when I’d like to count the incident TTL signals per 500 us, then I should set a sample clock frequency of 1E+06 (also Continuous Sampling) and 500 # of samples in DAQmx. Does it?

 

Thanks a lot!

 

Jun.

 

p.s. I considered your comments of the consumber loop and now try to revise it.

       When I complete then I’ll reply it.

0 Kudos
Message 3 of 10
(3,110 Views)

Q1: the specs for the 6612 are clearer, but I would expect the specs for your 6358 to be fairly similar.  Page 4 shows that you'll be capable of accurate edge-counting on externally-supplied TTL signals up to 25 MHz.  You just need a clean TTL signal, and your instrument is very likely to produce one.

 

Q2: With sample clock at 1 khz and reading 100 samples at a time:

- you'll get 100 distinct samples 

- each sample value will be the # of *cumulative* counts up until that time

- a simple finite difference in software will give the # of *new* counts per interval

- your software loop will iterate every 100 msec (10 Hz)

 

To count # pulses per 500 usec, set the sample clock rate to 2000.  And do the finite difference on the data you get.

 

There's a way to get your "counter per sample interval" more directly using "period measurement".  But you end up having to think about your whole problem kinda "inside-out" to get the counter task configured correctly, and that's probably better left as something to explore after you're more familiar with counters.

 

 

-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 4 of 10
(3,082 Views)

Such a helpful answer for me!

 

I have clear understand for the meaning of sampling rate!

 

In addition, I make the consumption loop be light by getting rid of the accumulate array and changing it to "concatenate" mode. The type of queue is also revised to u32 integer array.

 

Then, Kevin I have additional questions.

 

Q.1. Timing setting.

When I set the timing settings as followings:

1. sample clock source : Square pulse (period is 500 us) from the function generator

2. Sample rate : 4000 Hz

3. # of samples : 2

 

Dose the DAQmx reads 2 # counter per 250 us or 2 # counter per 500 us?

(I think the answer is 2 # counter per 500 us, but I'm not sure...)

 

I guess that the first step of sampling can't have exact period.

In fact, I saw that the people in this community ignored the first term.

That's why I divided the 500 us period into two parts (250 us, 250 us or 500 us, 500 us).

 

To verify whether is true,

I set the followings:

(1) Input terminal signal (PFI2) which period is 100 us, square pulse

(2) sample clock source (PFI3) which period is 500 us, square pulse

(3) the sample rate : 4000 Hz

(4) # of sample : 2 #.

 

The results showed that the difference between first term and second term is always 5.

This showed that the above timing settings indicates "2 # counter per 500 us".

 

Please any comments for precisely counting the pulse during certain period (500 us) and about the ignoring the first counting term.

 

Thanks a lot.

0 Kudos
Message 5 of 10
(3,068 Views)

I remain puzzled why you want to equate a 500 usec period with a 4000 Hz sample rate.  Samples are taken on the active edge of the clock, there is one such edge per period, so a 500 usec period clock results in a 2000 Hz sample rate.

 

There are circumstances where the 1st sample *from the entire acquisition* should be ignored or discarded in certain counter tasks because it probably captured *part* of the interval you intended to measure.  But you shouldn't discard the 1st sample from every read.

 

At 2kHz sampling, the general rule of thumb would be to read ~200 samples at a time, not 2.  There's some overhead in working through the driver to do reads so it's better to read a good-sized chunk less frequently than to (try to) read a sample or two at a time very frequently.

 

At this point, I think it's easier for me to help with code itself instead of just typiing.  I'm gonna modify yours to do that inside-out period measurement I mentioned so that the hardware takes care of resetting the count for each interval and can use the samples directly rather than need to do a finite difference.

 

There's a bunch of comments inside the code to explain (at least partially) some of the things I did and why.

 

 

-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).
Message 6 of 10
(3,034 Views)

Dear Kevin.

 

I really appreciated for your help.

 

Now, I got what the sampling rate and the number of sampling is.

 

To read samples during certain period, I should set the sampling rate the frequency of the corresponding period.

Also, the number of sampling is generally set as an appropriate value (e.g. as you said, 200 # for 2000 Hz), not too small value like 2 or 1.

 

One more time, thank u Kevin for spending your time to help me!

 

Q 1. The reason why I used a few number of sampling as 2.

I have an additional question about why I set the number of sampling as 2.

 

In my project, I'd like to synchronize two device: (1) photo-sensor to count pulse from the incident photon, (2) CCD camera.

The light source is equally divided into two direction, going through photo-sensor and CCD camera.

If two devices acquires data (counting, image) in the same time interval, the intensity (# of counting) of photo-sensor and that of CCD camera has the same value theoretically.

 

However, the camera takes a relatively long time to acquire an image, while the photo-sensor with DAQmx takes relatively short time to counting the edge.

That's why I did set the a few number of sampling as 2.

 

In the same condition : sampling rate - 2000 Hz (i.e. the acquire time is 500 us for 1 sampling)

1. If I set the number of sampling as 200, 

    two devices could not be synchronized because the camera takes a long time to acquire 200# image.

    (i.e. the counting is already finished, while the camera is going to acquiring.)

2. If I set the number of sampling as 1 (or 2),

    it is easy to synchronize two devices because both the DAQmx for edge counting and the IMAQdx for acquiring imaging is conducted during one interval time.

 

I hope that you do understand what I'm saying.

Actually, you already answered me in this rink: https://forums.ni.com/t5/LabVIEW/how-to-acquire-a-synchronized-image-and-voltage-signal-from-both/m-...

 

I have a problem in synchronizing the above two devices.

You already said that you have not used IMAQ.

But please check and give any comments to my VI for synchronizing two device to acquire data (counting and image) at the same time.

(The VI is not revised as you gave for me (q3 -modKP) yet. After I revised, then I will contact you in this post.)

 

Thanks a lot!!!

 

Jun.

       

p.s.

I guess you probably did not understand why I keep using the 500 us as a interval time.

Actually, in my final VI, the interval time for edge counting is set as the exposure time of the camera. (I think it would be ~130 us)

In other words, the sampling rate for counting DAQ is same to the ex. time of the camera.

0 Kudos
Message 7 of 10
(3,027 Views)
Solution
Accepted by topic author jun20

Ouch!  I sure wish you'd mentioned the need to sync with a frame-grabbing camera earlier.  I didn't happen to notice that you were the same person from that other recent thread you just linked -- I've been in kind of a lot of threads about photon counting.  The advice I've been giving solves *part* of your problem but may not work out so well when trying to integrate and solve *all* of it.  Remember in the future to reveal *all* relevant requirements of your app at the beginning of the discussion.

 

There are going to be further subtleties to consider when it comes to sync'ing image frames with photon rate measurements.  From what you've said so far, there are more details for you to learn about and think through.

 

The camera capabilities and your data needs are going to drive your decisions.   Counter tasks are very flexible and can likely accomodate your needs once you get them clearly and realistically defined.   Some things to learn and/or decide about:

 

- does a pulse sent *into* the camera start an exposure?

- does (or can) the camera generate a pulse when it completes an exposure?

- is the exposure time constant?  Or does it at least remain constant within your test duration, once you get it set up?

- what frame rate does the camera support?

- what sample rate do you want from your photon rate measurements?   If different from your camera frame rate, why?

- sync is easiest when the photon measurement sample rate exactly equals the camera frame rate.  Methods will likely be possible for integer multiples too, but will be more involved.

 

What I kinda think you *should* want to do is to use a pulse that occurs at the *end* of camera exposure as the signal that causes your counter task to take a sample.  (I'm very carefully not calling it a "sample clock" because of the possible inside-out config for period measurement where terms can get mixed up.)   

   Things you described don't sound like they'd give an appropriate degree of sync.  Good sync should be handled in hardware.  The # of samples you read at a time doesn't generally have any bearing on sampling sync.   Exposure time is probably not very relevant for your counter task as it's very likely not the same as (1/frame_rate).

 

I finally took a look at the code.  From what I see, you're trying to do everything at once.  There are several problems and I simply don't have time to guide you through every detail of every one of them.  You need to take 2 or 3 steps back, take a few deep breaths, and accept that this process of writing code to integrate multiple bits of hardware you're only partially familiar with IS GOING TO TAKE SOME TIME.

 

Break it down into smaller pieces.  Integrating is hard enough *after* getting the individual pieces working, but it's often exponentially more difficult when you don't.  Experiment with the camera -- frame rate, pulses in, pulses out, exposure settings, etc.  Learn what it can & can't do, and how.  Then experiment with the photon detector and counter task.  Try your edge counting method with finite differencing.  Try my "inside-out" period measurement.  Try to understand how and why it works.

 

Like I said in the other thread, it really isn't close enough to "right" yet that I can guide you all the way to the finish line.  Do come back with specific questions (but please link back to these earlier threads for context), but be prepared to put in some time learning and experimenting too.

 

 

-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).
Message 8 of 10
(3,019 Views)

Dear Kevin.

 

I'm sorry for being late to reply your answer.

 

Answer for your question.

 

- does a pulse sent *into* the camera start an exposure?

You mean that a pulse can be sent into the camera to start an exposure?

then, Yes. the camera can start acquire an image by a triggering pulse thorugh GPIO line0 (input).

I attached a two figure (10Hz, 50Hz) to explain how the camera works to acquire image during trigger mode.

The frequency indicates the freq. of square pulse generated by a function generator. 

 

In addition, according to the SPCM datasheet, the output signal can be pulled out through the GPIO line 1

But, I did not understand what it means... The following answer is also related to the output pulse from camera..

 

- does (or can) the camera generate a pulse when it completes an exposure?

No, it generated pulses but, it seems not to be related to the exposure.

I guess that the output pulse from GPIO line 1 shows a frequency that equals to the triggering signal for the triggered mode camera.

 

- is the exposure time constant?  Or does it at least remain constant within your test duration, once you get it set up?

The user can control the exposure time as a constant value.

The exposure time can remain constant as the value that user set up.

However, the exposure time can be set as specific value.

(e.g. when I set 500 usec as exposure time, the exposure time is set as 507.414 usec.

 Similarly, when I set 550 usec, the exposure time is also set as 507.414 usec.)

 

- what frame rate does the camera support?

50 fps, i.e. 50 Hz.

Is it indicates that it takes 20 msec for getting one frame???

(I guess it might takes 20 msec to acquire one frame, i.e. one snap image.)

 

- what sample rate do you want from your photon rate measurements?   If different from your camera frame rate, why?

- sync is easiest when the photon measurement sample rate exactly equals the camera frame rate.

  Methods will likely be possible for integer multiples too, but will be more involved.

Considering your comments (“Exposure time is probably not very relevant for your counter task as it's very likely not the same as (1/frame_rate).”), I don’t have to let the sample rate of photon measurement different with the camera frame rate. As you recommended, therefore, I will setup both the rate of photon detector and camera equally.

 

Unfortunately, I still have a problem how synchronize both devices.

What makes me confusing is that the camera does not operate in daqmx.

When I search about synchronization, most of thread showed the synchronization in daqmx like sync. Ai with AO, or AO with AO...

 

Q.1

Is it possible to sync. the camera (imaqdx) and the photon counter (daqmx) through the structure as shown in the following link??

https://www.ni.com/tutorial/3615/en/

 

A shown in 5.Multidevice sync, I tried to make sync. by replacing one of the DAQmx start Task to IMAQdx start acquisition.

Unfortunately, the PCI-6221 (and PXI-6358) is not available to use trigger ability so that it make error...

 

Q.2

As you recommended, I tried to make the rate of photon counting same with the frame rate of camera.

 

To sync. both devices, I connect a external trigger signal (50 Hz square signal from function generator) to both devices.

(i.e. sync. through hardware.)

 

Specifically, the trigger signal is transmitted to the camera, where the signal is connected with Opto-isolated input through GPIO 0 and the gate of photo sensor.

 

 

Similarly, the trigger signal is transmitted to the gate of photo sensor.

 

As shown in the attached figure (10Hz, 50Hz), the photon counting was conducted by triggering with falling edge.

 

Can I make sure that they operates at the same time by using the triggering signal from the same hardware?

(I attached the datasheet of camera, BFLY-U3-05S2M-CS (Mono CCD camera, 50 fps) and the photo-sensor (Exelitas SPCM-AQ4C))

 

- Jun

0 Kudos
Message 9 of 10
(2,964 Views)

I've had this tab open for days b/c I wasn't sure I'd have time to reply.

 

Answer 1 (to Q1): I know very little about NI-IMAQ.  I wouldn't count on being able to sync merely by substituting IMAQ calls for DAQmx calls in the linked tutorial.

 

Answer 2 (to Q2): Yes, by using the same hardware signal to initiate both a frame capture and photon count sample, you've gotten the right start toward syncing the measurements.  But that's not the *end* of the story.  There are 2 more factors.

1. Sequence - both the photon count task and the IMAQ frame grab task need to be running and waiting before the 50 Hz pulse train is started.

2. Alignment - The photon count task will capture a sample indicating how many photons were seen during the interval *prior* to his one.  The frame grab task will *initiate* a frame grab that extends into part of the *next* interval.

    You'll need to figure out exactly how you want to align things.  You might want to have the photo count capture happen on a rising edge while the camera starts a capture on the falling edge.  And then you could use a counter task to generate your 50 Hz pulse train with a duty cycle you can specify, in order to manipulate the relative timing of the rising and falling edge.;

   I don't know *what* you need to do.  But this is a way *how*.

 

The scope pics didn't really help me any, the signals don't mean anything to me.

 

The essence of sync is:

- drive both (all) processes with a common time reference.  This will often be a pulsetrain, also called a "clock"

- align them to start together.  This can be done with a trigger.  I like to do it by having control over when I start the common clock.

- retrieve and process the data in a way that retains the sync you've accomplished on the hardware side.  When everything samples at the same rate, you just want to keep retrieving the same # of samples from every device.

 

 

-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).
Message 10 of 10
(2,933 Views)