LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

how to acquire a synchronized image and voltage signal from both CCD camera and photo-detector.

Dear sir,

 

This is my first post and I introduce myself as a newbie with LabView, but I hope I can get some answers. Here it goes.

 

I have setup a simple optical system to acquire an intensity correlated image called ghost imaging by using a CCD camera (BFLY-U3-05S2M-CS) and a single photon counting module(Excelitas SPCM-AQ4C).

CCD was directly coupled with PC through USB 3.0 cable. In contrast, SPCM was transmitted its signal through BNC-2121 and PCI-6602.

 

To simultaneously acquire the intensity correlated data between an image from CCD and intensity of voltage signal from SPCM, they should be synchronized through trigger mode.

I was attempt to make CCD directly triggered with SPCM, but unfortunately it did not work well.

So I used an external trigger signal from function generator and tied it with both CCD and SPCM.

 

Object of this code:

CCD and SPCM should acquire data in certain time range (e.g. 0~ 500us, 500~1000us, ....) and save each data in loop.

 

gttgt.JPG

 

I attached my VI. 

 

Any assistance would be greatly appreciated!!

 

Thanks a lot!

 

Jun.

0 Kudos
Message 1 of 4
(959 Views)

Just as fair warning, you probably have a lot of work and learning ahead of you.  You're not just a day away or something.

 

I say that not to discourage you, but to help you have realistic expectations.  Now, let me get on with the  little bit of help I have time for now.  All of it will relate to the photon counter part of things as I really haven't used IMAQ.

 

- you mention a 6602 counter/timer board which only supports counter and digital tasks but your code sets up an Analog Input task.  Your sketch also shows analog-looking pulses, but when I looked up your photon counter, I found that it puts out digital TTL pulses.  So right at the start, you have some misunderstandings about your equipment that you'll need to correct.

 

- your photon counter produces TTL pulses with 25 nanosec pulse width.  The 6602 is an older device and the spec sheet is less thorough about the distinctions between internal and external signals.  (Compare with its replacement, the newer PCIe-6612.)  You might be pushing the limits of the 6602 with such short pulses and may need to pay special attention to your wiring to maintain signal integrity

 

- A counter edge-counting task will be easiest to configure.  It will maintain a *cumulative* count of pulses, so if you want to bin them into counts-per-interval, you'll need to do the finite difference in software.  Very fast pulse rates for very long periods of time may bring counter rollover into play, but that'll take 2^32 pulses, so most apps don't need to worry about it.

 

- You can get the counts-per-interval info directly from the hardware if you configure for a period measurement task.  However, it'll require a kind of inside-out configuration that is a bit more complicated and will not be illustrated in any of the shipping examples.  Many seem to find this approach confusing, at least initially.  If you do too, you're not alone.

 

- At some point you'll likely need to learn about and use a "Producer / Consumer" approach to separate data capture from the subsequent processing and logging.

 

- I don't know IMAQ, but you may find that it takes some special care to make sure that a specific frame grab corresponds to a specific photon count (i.e., making sure they're both correlated in time.)    Even if both are clocked by the same signal, that may only guarantee that there *exists* a correct photon count for a given frame grab.  There still may be work to do to control or identify which one it will be.

 

My time's up.  Most of this is fairly general advice because there's a lot of work ahead.  You probably need to get a bit further along with things before some of the details will be a difference-maker.

 

 

-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 4
(939 Views)

Dear Kevin.

 

Thank u for all comments for me. As you recommend, I plan to make VI in step by step.

To acquire the count info. of TLL signal, I make "A counter edge-counting task" with Producer/Consumer structure.  

 

Q1.

But I got a Error 1122 when using queue functions.

I guess that it is related to the performance of DAQ, PCI-6602 counter/timer as you saying that it could be poor to acquire very short TTL pulse (25 nsec). 

 

Pleas tell me any comments to solve this error 1122 !!!

 

Q2.

I don't exactly understand

Very fast pulse rates for very long periods of time may bring counter rollover into play, but that'll take 2^32 pulses, so most apps don't need to worry about it. "

 

According to your comments, PCI6602 can achieve the edge-counting task for short TTL pulse, is it right?

0 Kudos
Message 3 of 4
(893 Views)

Q1 - no, the queue error is unrelated to your DAQ device.  Your producer loop ends after 11 iterations and subsequently releases the queue, making the queue ref invalid.  Once that happens, the Dequeue function in your consumer loop will return with that error (which will also cause the consumer loop to terminate).

   To solve this requires a new *strategy*.  Best practice recommendations include:

 

- the consumer should decide when to release the queue (usually not until after consuming everything in it

 

- some kind of "signalling" mechanism is used to *inform* the consumer loop that the producer's done and nothing more will be coming.  Common methods:

  • Metadata.  Change the queue datatype to be a cluster that contains both the DAQ data and some kind of metadata.  Use the metadata to signal the end -- it can be as simple as a boolean.
  • Sentinel value.  Define a specific value of your data that can't possibly be real data.  Send this special sentinel value when the producer's done.  The consumer must then recognize it and know that it can be done too.   Example: when your data is an array of numbers, an empty array could act as a sentinel value.  (But be wary that you never send an empty array unintentionally.)    Another example is based on your counter data being an unsigned 32-bit integer.  The queue datatype could be signed 64-bit integer.  Then any negative number like -1 can act as a special sentinel value.
  • Use a Channel instead of a Queue.  Channels are somewhat newish in LabVIEW and seem to have relatively low adoption by many of the folks with long experience (myself included).  But if you search around you'll find very strong advocacy and helpful posts from Bob Schor about Channels.  Others too, but he's really stood out when it comes to Channels.    Anyway, when Channels were developed, NI recognized this little difficulty of needing the producer to signal to the consumer when it's time to end.  So the mechanism is built right in as an extra boolean (like the "metadata" approach above) in the Channel Writer and Channel Reader functions.

 

Q2 - Two separate things.  I expressed concern about the short *duration* of your photon counter's pulses at 25 nanosec each.  You'll need to investigate this with your actual hardware to determine whether you can count those short pulses reliably.   The count "rollover" is a separate thing.  Once you start your counter task, the count register wants to keep incrementing with every pulse it sees.  However, the count is a 32-bit unsigned integer that will *eventually* max out at a highest possible value of 2^32-1.  The next pulse after that will make the count "rollover" back to 0, and it will continue to increment again for subsequent pulses.

   To get a sense of proportion, a constant stream of 1 MHz pulses would need more than an hour to make the count roll over.  (Calculate seconds with: 2^32 / 1 000 000)

    There are other counter operations where you end up counting an internal 80 MHz or 100 MHz timebase.  In those cases, rollover happens in less than a minute and is more likely to be encountered.

 

 

-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 4
(885 Views)