Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

Photon count synchronization

Solved!
Go to solution

Hi,

 

In my attempt to create a VI which synchronizes the image displayed on a second monitor with the photon counts from a photomultiplier module via an event structure, I've noticed that the photons and images aren't correlating and instead the photon counts are building a back log. Can someone take a look at my code and help me to improve it?

 

I'm using LabVIEW 2020 with a PCI-6602 counter and a BNC-2121.

 

Thank you,

Dillon Kopecky

Download All
0 Kudos
Message 1 of 7
(2,360 Views)

Start with these changes:

- remove the event structure from the photon counter reading loop.

- the control you call 'sample rate' is wired to DAQmx TIming as a '# samples per channel'.  You should probably call that control a "buffer size" and make it an integer.  Under Implicit timing, there's no place to wire in a rate.  

- read fewer samples at a time to iterate faster.  A typical rule of thumb is to read 1/10 sec worth, i.e., #_samples_to_read = (sample_rate/10).

    Alternately, time your loop some other way and specify the magic # -1 as the # samples to read.  That'll immediately return all available samples which is another way to prevent an accumulating backlog

 

 

-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 2 of 7
(2,323 Views)

Kevin,

 

I've made the suggested changes. Setting the DAQmx Read VI to read all the available samples was a good idea. Now I'm left with a VI that continuously counts TTLs from the PMT while I cycle through images. However, I don't want the mixed samples that occur between the frame changes. I am back at the issue of how to synchronize these two VIs. I've been looking into synchronization VIs like semaphores and rendezvous. I'm unsure of the best direction to proceed because I think limiting the VI again will cause the counts to backlog.

 

I always enjoy the insight you give on this subject in the other threads, thank you for your responses.

 

Thanks,

Dillon Kopecky

0 Kudos
Message 3 of 7
(2,309 Views)
Solution
Accepted by topic author dmkopeck

I just said this in a related thread -- real sync is going to come from setting up equipment to share hardware timing signals (such as clocks or triggers).   Semaphores, rendezvous, etc. will all suffer from the imprecision of software timing.  No point going down that road.

 

Can your image-capture equipment either:

1. capture an image frame on receipt of a TTL pulse?    OR

2. emit a TTL pulse when it starts or finishes capturing a frame?

 

You'll need to make use of at least one of those operating modes to sync with your DAQ equipment.

 

 

-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 4 of 7
(2,306 Views)

Kevin,

 

My DMD is setup to emit/receive TTL pulses. 

 

As a side note, usually it is operated in such a way that upon frame change a TTL pulse is sent to the DAQ but the DMD onboard memory is too small (1056 1-bit images) for the amount of images I need to display (>16,384 1-bit). Therefore, I have to set it up like a second monitor. Now it does not know when a frame changes because it has no control of the image loading.

 

I can however operate it in such a way that it sends out TTL pulses periodically. It seems like I may need to look into this direction. 

 

Thanks,

Dillon Kopecky

0 Kudos
Message 5 of 7
(2,294 Views)

I don't have any familiarity at all with your "DMD" device.  I tried a quick search and found a lot of very low-level chip-related info and talk about the need to pair it with a special controller chip.  Bottom line: I can't bring myself to sufficient understanding in a reasonable amount of time, considering that it's not my project and I'm just dabbling with advice in my spare time.

 

Sorry, I just don't have a handle on what the opportunities and constraints are.  I'm sure that some kind of hardware sync is the thing to aim for, but I don't know what kind, how to implement it with your "DMD" device, and how to work with the corresponding data to make sure you can keep the data sync'ed to your other equipment as well.

 

 

-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 6 of 7
(2,272 Views)

I always enjoy the insight you give on this subject in the other threads, thank you for your responses.

0 Kudos
Message 7 of 7
(2,122 Views)