Well, I don't have ready access to a LV PC and for some very odd reason, my attempt to search for "error code" (and even just plain "error") on the ni website returned 0 hits?!? Strange...
Anyhow, I'll take a guess and offer you an idea for a workaround. Could your error mean that your call to AI Buffer Read times out before the requested # samples have been taken? This kind of error wouldn't be surprising as it's difficult to determine a reasonable timeout value. Based on my own past experience with a 4351 board, I'd say that the whole notion of "sample rate" turns into something of an odd duck.
As I recall, all you can specify is a filter frequency which will establish a ceiling for your actual sample rate. However, the board also has some sort of criteria for signal stability. If you have several different channels to measure which use different input ranges, your actual sample rate can be reduced pretty dramatically. So you might get a few samples per second or a few seconds per sample.
The workaround I used was to always request data that had already been collected and was immediately available. One of the inputs to the AI Buffer Read lets you set some parameters where you can specify that you want to read the most recent sample that's already in the buffer. Granted, this may represent a temperature from a second or two ago, but this lag is not necessarily a major issue for temperature measurements.
Note: in my app, I could query for Temperature any time I wanted, as frequently as I wanted. I would always get data back, but there was no guarantee that I'd get *unique* data back. In other words, if I called it 10 times in a tight loop, I might get the exact same sample # back each of those 10 times.
-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.
