Photon count synchronization

[dmkopeck]

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

[Kevin_Price]

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

[dmkopeck]

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

[Kevin_Price · Accepted solution]

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

[dmkopeck]

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

[Kevin_Price]

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

[shubharora734]

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