Synchronizing the Readout of Externally Triggered Hardware

[lcgroff2]

A few details to set up the problem:

I have an optical setup where a laser pulsing at 1 kHz is split off and half of it is chopped at 500 Hz. The laser itself is producing a TTL synchronization pulse that I'm using to trigger the synchronized readout of a camera at 1 kHz frame rate. Both beams pass through my sample, and the chopped beam is monitored by a photodiode after the sample that is meant indicate whether the 500 Hz chopped beam was coincident with the kHz beam for a given image (i.e. "light on" vs. "light off").

I also have a PCI-GPIB based computer interface setup on the same TTL trigger source to readout the voltage on the photodiode at 1 kHz, so the voltage reads out high (~2 V) when the chopped pulse was there, and low (~0.05 V) when it wasn't. I've independently verified that both my camera and my GPIB interface are externally synchronized with the TTL external trigger from the laser, and that no triggers are skipped. So, as long as I know whether the first of the array of images was voltage high or voltage low, the rest should alternate high/low from that point (and my test analysis vi where I just work with the image buffer verifies this to be true, I get 500 "light on" images and 500 "light off" alternating). My end goal is to subtract the images (On-Off), and so I need to synchronize the photodiode output with the first frame so that I know which set of images corresponds to "light on" to do my subtraction for a given acquisition.

My problem:

I have an overarching data acquisition and analysis VI, and in one of the sub-VIs, I want to collect 1000 camera frames, and simultaneously scan the voltage on the photodiode at the start of the camera acquisition to determine high/low voltage on frame 1 of 1000. I've tried setting up a pair of Timed Loops where one scans a photodiode voltage and the other starts the camera acquisition using the Synchronize Time Structure Starts.vi function, but the analysis that results from correlating these images with the photodiode readout suggests that the readouts aren't lining up (I'm randomly doing On-Off some times and Off-On others, which inverts my data randomly). How can I nail down this synchronization to ensure that I'm properly correlating my externally triggered hardware?

[Bob_Schor]

Start by posting code, that is, something that we can bring into LabVIEW to examine, fiddle with, maybe even execute.  The easiest way to do this is to attach the actual VI (with extension .vi).

If everything is running off the same clock, it is usually better to have a single loop.  The other thing is you want to do as little as possible in the loop, only that which is time-critical.  For example, any data processing (such as looking at the images) you want to "export" from the loop using a Producer/Consumer architecture.

Looking forward to seeing code ...

Bob Schor

[lcgroff2]

Well, here's the whole sub-VI with extensive notes on what it's meant to do. It runs well whether I do or don't use the GPIB Write command in the Flat Sequence Structure, but those are the two acquisitions that I need to synchronize, and my analysis is showing that they're effectively asynchronous in LabVIEW despite sharing the same hardware external trigger. I'm running LabVIEW 2009 SP1.

[Kevin_Price]

What I see in the code is not what I'd *like* to see for a sync'ing operation.  It appears that you're depending on 2 parallel Timed Loops running at 1 kHz each to remain in sync as you retrieve 1 reading per iteration.  I'd *like* to see the use of shared hardware timing signals to clock data into their respective buffers, then a more leisurely pace of reading data out in chunks at a time.  Basically, shift the critical timing elements of sync over to the hardware.

Now, all that said, I really don't know the capabilities or limitations of your equipment.  You might be stuck.  I'm just saying that it'd be best to pursue hardware sync and buffering *really* hard before settling for fast-iterating software timing.

I'm inclined to suspect the high speed camera is capable of hw-sync and buffering.  If the device hanging off your GPIB connection isn't capable, *and* sync is really important (as I suspect it is), it may be worth checking into an alternative measurement device that *is* capable.

Fundamentally, software timing will never be fully reliable in an OS like Windows, especially down to the single msec.  The best "backup plan" advice I can think of is to consider putting both the GPIB scan command and the framegrab command in the same loop.  I suspect that makes them at least a *little* more likely to be more nearly sync'ed.

-Kevin P