Adding delay can easily cause a problem if the acquisition can continue. The purple wire coming out of the IMAQ VIs is a pointer to the image rather than passing the entire image around. Each time your wire splits, you create a copy of the data. That could add up quickly with a full image so it's better for you to pass the reference around in most cases. This also means it can be modified in other locations. If the new acquisition starts while you're writing to file, you'd expect to see part of the new image show up in the writing.
It's generally a bad idea to be confused AND tell others they can't possibly be correct. It's better for both sides to ask more questions to understand where they're coming from. This will allow you to learn from their thought process as well as allow them the chance to re-think things if more information you add makes them find another conclusion.
If you believe the write is the culprit, that's easy to test. Set up a loop to continuously write images to file. Remove acquisition from the equation. If this fails, you're right. If it doesn't, there's more to it than the write and you're chasing a red herring because that's the easiest place to look at. I'd expect you'd find the latter.
In terms of the acquisition, it's unlikely we COULD use the IMAQ functions. When we discuss cameras, we should be careful to work with a shared definition. As far as IMAQ is concerned, it needs to match a vision protocol of some sort. The camera being used here is a CMOS sensor by that definition. This is why the acquisition card is just an analog DAQ device. The drivers provided by the manufacturer are likey wrapper VIs around their dll so they can talk to the device that way. We shouldn't focus much on the idea of acquisition as something we can change. It's most likely set.
Instead, we'll want to focus on finding a way to make things more manageable. Have you viewed the community example to stream images to TDMS files? Does that result in the same "artifacts" you're seeing now?
