A few things.
1. What error are you expecting? Much of the discussion has been about the way DAQmx Read *allows* you to request more samples than the buffer size such that you don't *need* to expect an error. Please reread responses in msg #2 and msg #5 that provide more detail.
2. Simulated devices are not (and were never intended to be) *perfect* simulations of the behavior of a real device. They do a rather good job of catching problems with configuration syntax, settings limits, and device capabilities. Barring that, simulated reads and writes pretty much always succeed.
With a real device, I very much expect you'd need a buffer size larger than 10 when you sample at 250k. A 250k task would fill a size 10 buffer every 40 microseconds. It's extraordinarily unlikely that application-level code would be able to service that buffer frequently enough to prevent buffer overflow.
So in this kind of extreme case with a really tiny buffer, I guess you might expect an error on real hardware that the simulated device didn't anticipate. But it's a pretty artificial situation. You have to go out of your way to make the buffer size so small, much smaller than you'd get with DAQmx's buffer auto-sizing.
3. You referred to a "daq write" this time. Aren't we talking about an acquisition task and DAQmx Read? Behavior for writes is different as I mentioned in msg #9, and different in a way that might show up with a simulated device.
-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.
