LabVIEW
Start Trigger and Stop After Desired Number of Pulses - random errors in my implementation
Solved!
- last edited on by
Content Cleaner
The example looks like it is based off of this one--both have the same flaws that somebody from NI should probably correct (or just move the developer zone example to the community and then we users can correct them for you instead 
). The issue that you have encountered comes from how DAQmx uses default parameters to configure the buffer and the number of samples to read:
1) For a finite task, DAQmx chooses a default buffer size to be equal to the samples per channel property (the input to DAQmx Timing.vi--in your case, 20000 samples).
2) For a finite task, specifying -1 for the number of samples per channel input to DAQmx Read.vi results in reading back the number of samples specified for the finite task (the same 20000 samples mentioned in #1).
So, you can see the problem. You are constantly filling the buffer, but are only removing samples from the buffer in chunks that are the size of the buffer itself. If something happens in software that slightly delays the reading of samples from the buffer, you will end up overwriting data. The buffer needs to be larger to compensate (alternatively, you could specify a number of samples to the DAQmx Read call that is less than your number of samples configured for the finite task, but doing this seems like it would be a confusing way to go about it).
The other major issue with the example (it would lead to a different error) is the use of querying the task being done to determine whether or not to read the full amount of samples. What if the task finishes after the check has already been made and the read is still waiting for the full amount of samples to become available? You'll block for the full timeout of the read call and will get a timeout error, then wouldn't read the remaining samples at the end due to the error chaining (or actually I think the samples would be available on the Data terminal instead--but this inconsistency doesn't seem desirable--I don't really like blocking for a full 10 seconds waiting for data in any case).
There are also a couple minor issues with the example:
- Why does it use so many post-trigger samples when this will just make your acquisition run longer than necessary???
- The "remaining samples" indicator doesn't get updated if there are no remaining samples, shouldn't we update it so it reads empty rather than persist whatever value was on the indicator from the last run of the VI?
Well now I've gotten off on a tangent. The point is, there are some flaws in the example. I think this is a great use-case for DAQmx Events, and would have probably done something more like this (Warning, snippet is untested--it also doesn't have the extra counter stuff that your example did to divide down the ref trig source):
The fix to your specific problem is to configure the buffer (DAQmx Configure Input Buffer.vi). Here I went with 2x the number of samples read per loop iteration (should probably be enough, might need to come up with an algorithm based on sample rate though).
The other fixes are that the post trigger samples are now the minimum 2 (for faster stopping), a DAQmx event is now used to determine when to read the full amount of data (to prevent timeout of read after stopping), and the remaining data indicator is always updated (to prevent stale data from being displayed on the indicator in the case that there is no remaining data).
Hopefully I'm not missing anything else...
Best Regards,
