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
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
