I did some thread searching just now but came up (mostly) empty-handed. I remember at least reading if not participating in prior discussions about some odd observations when using this property. The closest thread I found is a very old one I was in, but that's not the one I was trying to find.
Anyway, here's my take based on a combination of memory and inference. There are circumstances where the TotalSampPerChanGenerated property refers *merely* to the # samples the driver has delivered from the task buffer to the device. The old linked thread is one of them. I *think* that (some) USB-connected devices might be another.
If so, then what you see with your low-cost USB-6001 device is that the driver has decided it should transfer all the data to the device as quickly as possible (and the device has a big enough onboard FIFO buffer to receive all of it). So you start the task, the driver immediately transfers data, and then you query the property and it tells you that *all* the samples have been *generated*. In fact, they haven't. It's just that the kind of low-latency two-way communication needed for a more accurate assessment of *actual* generation progress isn't available in the DAQmx driver for your USB-6001 device. So it reports the next best thing -- how many samples have been *delivered* to the board.
There's a thread within the last several months where this was explained more clearly by someone from NI, maybe your search skills are enough better than mine that you can find it.
Bottom line though is that this is more like a design decision than a bug waiting to be fixed. You shouldn't expect the difference in behavior to change in the future.
-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.
