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.
I attached my VI.
Any assistance would be greatly appreciated!!
Thanks a lot!
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.
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.
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 !!!
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?
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:
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.