The term "Incomplete Sample Detection" comes from DAQmx Help. It affects buffered time measurement tasks on X-series boards, the 661x counter/timers, and many 91xx series cDAQ chassis. It is meant to be a feature, but it can also be a real obstacle.
How the feature works ideally: Suppose you want to configure a counter task to measure buffered periods of a 1-channel encoder. You use implicit timing because the signal being measured *is* the sample clock. The 1st "sample clock" occurs on the 1st encoder edge after task start, but the time period it measures won't represent a complete encoder interval. Reporting this 1st sample could be misleading as it measures the arbitrary time from the software call to start the task until the next encoder edge.
On newer hardware with the "Incomplete Sample Detection" feature, this meaningless 1st sample is discarded by DAQmx. On older hardware, this 1st sample was returned to the app, and it was up to the app programmer to deal with it.
Problem 1: Now suppose I'm also using this same encoder signal as an external sample clock for an AI task that I want to sync with my period measurement task. Since DAQmx is going to discard the counter sample that came from the 1st edge, my first 5 samples will correspond to edges 2-6. Over on the AI task, my first 5 samples will correspond to edges 1-5.
My efforts to sync my tasks are now thwarted because their data streams start out misaligned. The problem and workaround I'm left with are at least as troublesome as the one that was "solved" by this feature.
Problem 2: Suppose I had a system where my period measurement task also had an arm-start trigger, and I depended on a cumulative sum of periods to be my master time for the entire system. In this case, the 1st sample is the time from the arm-start trigger to the 1st encoder edge, and it is *entirely* meaningful. On newer hardware, DAQmx will discard it and I'll have *no way* to know my timing relative to this trigger.
Older boards (M-series, 660x counter/timers) could handle this situation just fine. On newer boards, I'm stuck with a much bigger problem than the one that the feature was meant to solve.
So can we please have a DAQmx property that allows us to turn this "feature" OFF? I understand that it'd have to be ON by default so as not to break existing code.
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).