A couple further remarks:
1. The main thing I know of that can make DAQmx Write stall out for a long time is when the buffer(s) between the app and the D/A converter are full. In such cases, DAQmx will wait as samples that are already in the buffer get generated, gradually clearing out space for the new ones you're trying to write.
2. So why might that be happening here? Well, I'm not certain *exactly*, but there are several things I see that are "unconventional" that might contribute.
3. You write a big waveform to a task that was never configured for multi-sample generation with DAQmx Timing. Maybe DAQmx auto-configures a clock and buffer according to your waveform timing and size? I haven't really experimented, I've just always done the config explicitly with a call to DAQmx Timing.
4. Your use of auto-start=True may play a role as well. I'd be curious whether setting that False, followed by an explicit call to DAQmx Start, might change things. This is only speculation, but I wonder whether DAQmx's decision about a buffer size to create might depend on whether it's about to, or has already auto-started.
5. More speculation, but since you never call DAQmx Timing, how should DAQmx know whether to perform Finite or Continuous generation? When calling DAQmx Timing, Finite is the default so I suppose it might be the default here as well. Perhaps the buffer size is set to a smallish default size too? If so, DAQmx Write will get stuck waiting for space to free up over and over so it can deliver all its samples a little at a time.
-Kevin P
CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
