Galvo mirror lose sync with APD at certain frequencies

[yashp23]

Hello everyone,

I'm using Labview 23 and PCIe-6323 to drive my 2-axis Galvos and the APD obtained from Thorlabs. To set them in sync I am using the code provided under 'Synchronization Beyond Analog' at this link: Timing and Synchronization Features of NI-DAQmx - NI. My only problem is I'm losing sync between the components, i.e. the galvos and the APD, only at some frequencies. I am using the raster scan pattern with front+flyback scans, and fast & slow axis scans.

Here are some examples with their attached images (GalvoSyncIssue1, GalvoSyncIssue2, GalvoSync3) of the results of scans.

Scanning Voltage Range: -2 to 2V

GalvoSyncIssue1 parameters: 1100 (1000+100) x 100 points at 80, 70 & 100kHz respectively

GalvoSyncIssue2 parameters: 800 (750+50) x 80 points at 80, 70 & 100kHz respectively

GalvoSync3 parameters: 800 (750+50) x 80 points at 30kHz

In all the images, the yellow dotted line represents the end of the front scans and the start of the flyback scans.

In the GalvoSyncIssue1 one can see that the scan is comparatively stable at 80 & 100kHz, but if watched closely at 100kHz, some of the flyback scans have become part of front scans.
This issue is more evident in the GalvoSyncIssue2 image where some part of the flyback scans have become part of the front scan at all the scanning frequencies.
The GalvoSync3 shows how the scan is supposed to look like.

I have also attached a PNG of my front panel and the block diagram.

I don't understand what can be the issue here. It'd be helpful to hear if you guys have any insight into this issue.

Thank you so much.

Yash

DAQ: PCIe-6323 - NI
Galvos: Thorlabs - GVSK2-EC 2D Galvo System Kit, Silver-Coated Mirrors, 230 VAC

APD: Thorlabs - APD410A2/M Si Variable-Gain Avalanche Detector, Temperature Compensated, UV Enhanced, 200...

[Henrik_Volkers]

Just some points that came to my mind:

If you use the same clock for generating and sampling, try to use different slopes of your timebase so you generation  (say rising slope) can settle and you sample on the falling slope.

If you say certain frequencies..  every update of your output sends a step pulse to your mechanical system...  mmm  maybe resonances?

If you read more than one channel , be aware that you use a multiplexed input DAQ... see settle time error in the specs.

[Kevin_Price · Accepted solution]

I've never done galvo work myself but have been on a number of related threads around here due to the need for multi-task synchronization.  I would suggest the following sync-related things, though I don't think they explain the symptom you see:

1. Configure the AO task timing the same way as AI -- using "/Dev2/Ctr0InternalOutput" as the sample clock source.

2. Follow Henrik's earlier advice to run AO on the counter's leading edge (probably rising) and AI on the trailing edge (probably falling).

3. I would then also set the duty cycle to something more like 0.95 to maximize the time from issuing the stimulus until capturing the response.   I see from the AI Read that you only have 1 AI channel in your task which is why it's ok to wait until just before the next AO sample will be generated.   (If you were multiplexing across more channels, later ones wouldn't get captured until after the *next* AO sample, which isn't what you'd want.)

4. You can then get rid of the trigger config in your AO task.  The shared sample clock alone is sufficient to keep AO and AI in sync, provided you start the counter task last (as you already do).

5. By the looks of things, it seems to me you might want your AO and AI tasks to be set for Finite Sampling.  You're basically treating them that way, clearing all tasks immediately after your first and only AI Read.

However, none of that is probably the cause of the problem you see.  My suspicion is that your galvo hardware simply can't quite keep up with your AO waveform signals as you increase your commanded speeds, particularly during flyback.  I note that at the "slow" speed of 30 kHz in the 3rd pic, the light blob falls right in the middle of what you call your "front" and "flyback" regions.  This tells me that the galvo is able to keep up with the AO waveform during flyback.  But in the other pics at higher frequencies, The AI signal that's captured right there in the middle of the flyback time still shows darkness.  I think that's because the galvo hasn't been able to keep up and is still lagging behind.

    It's only later, when the AO waveform control signal commands the galvos to be near the end of flyback or the beginning of the next front scan, that the lagging physical system finally passes through the light blob region during its actual flyback motion.

    The front scan isn't similarly displaced because, apparently, the galvo system can keep up with the implied speed of the front scan.

That's my theory.

-Kevin P

[yashp23]

Thank you Kevin_Price,

Getting rid of the trigger config in the AO task and configuring the AO task timing the same way as AI did helped with the consistent shifts at 70kHz. Also based on your suggestion of the galvos not being able to keep up with the flybacks I tried to increase the number of flybacks and it seems like you were right. There is this range of ratio of front/flybacks that works the best for a given range of frequencies for my galvos. If I keep the ratio in the range then the flybacks don't get recorded as frontscans, and the scan looks like how it looks with the 30kHz speed.

So thank you so much for your input.