Photon counting delay

[dmkopeck]

Hi,

I'm using LabVIEW 2020, PCI-6602, BNC-2121, Hamamatsu 6420 photon counting module, and a Texas Instruments DLP4500 digital micromirror device (DMD) as a structured light detection system. Light from a microscope is reflected from the DMD onto a photon counting photomultiplier tube (PMT). I've combined IMAQ Create, IMAQ WindDraw, and Photon count with dwell time to create a VI which modulates the DMD by displaying an image (similar to how a projector operates as a second screen) and recording the photon counts of the reflection of light from that image. I am troubleshooting the device by alternating the DMD mirrors to all "ON" and then all "OFF" ( by displaying black and white images) and recording the photon counts. As you can see by the data, occasionally I get the PMT still reading from the previous loop (or a delay from IMAQ?), which creates a mixed reading of ON and OFF states. In this measurement I took 4 samples and threw the first one away at 100 ms per data point. I get fewer of these "hang ups" by taking and deleting more samples, but the issue persist and it is detrimental to image reconstruction and significantly increases measurement times. This shows that even after >400 ms that the counter is still counting the photons from the previous image or that there is a delay in the image swap with IMAQ. I would like to solve why I get an occasional lag from the DAQ system which throws off my readings. This might be my counter, VI, or Vision systems fault so I appreciate any suggestions.

Thank you,

Dillon Kopecky    

[Kevin_Price · Accepted solution]

Sorry to say, but there really are a lot of problems with the way you've integrated the photon-related and the image-related parts of your code into a single loop.

As a *starting* point (but please realize -- it will not be a final *ending* point for your app!), do the following experiment:

1.  Put all the IMAQ stuff in its own vi (still in a loop I presume).  I can't otherwise comment on any of the IMAQ stuff in any detail as I have almost no experience with it.

2. Add code to measure delta time between iterations in both loops.  Run and observe.  You'll very likely see that the two chunks of code have a different natural pace.  I'm guessing the loop with the counter tasks wants to run faster than the IMAQ loop.  When you stick both in the same loop, you artifically slow down your handling of counter data, building up a big backlog, and retrieving increasingly old & stale data from the task.  Eventually you can expect a buffer overflow error when you fall far enough behind.

3. Do some reading on the "Producer Consumer" design pattern.  Use it to defer your photon measurement file operations into a separate parallel loop.  Redo your timing measurements.  You'll probably see the counter loop going even faster.  Significantly, it'll be a rate that totally makes sense based on the Ctr1 output frequency and # samples to read.

   This is your goal -- to have software loops that can keep up with your hardware.

4. Sorry, no insight on speeding up the IMAQ stuff.

5. This still leaves the not insubstantial challenge of coordinating & correlating a particular image to a particular set of photon counts.  I can't guide you through every step, but let me suggest the following to get started.  Get the photon counting tasks working well.  Then make a very simple IMAQ-related vi that gives you manual control over when to change images.  This gives you a platform for experimenting and verifying that the photon counting loop isn't bogging down and building up a backlog.

-Kevin P

[dmkopeck]

Kevin,

Thank you for the excellent suggestions! I know the code isn't great but it sort of worked for my application. I planned to trash it but it ended up being the best way to run my DAQ system out of many revisions and now I need to fix it instead of quick band aids.

Thanks,

Dillon Kopecky