What happens if you change the estimated sample rate you wire into DAQmx Timing? Try something more like 150-160 kHz. Here's two possible reasons why:
1. Your posted code declares 200k samples/chan/sec. With 6 channels in your task, that's an *aggregate* rate of 1.2 MHz. Your 6351 is only spec'ed for 1.0 MHz aggregate in multi-channel tasks. So you're asking the device to set up its multiplexing clock to do something it isn't spec'ed to handle -- fit 6 channels worth of ADC conversions within a 5 usec interval. You're trying to convert the next channel before the previous one has had enough time to fully settle, according to the device specs. This alone might be the cause of the error.
With 6 channels, the "perfect world" max sample rate would be 166.66666 kHz to meet the 1 MHz aggregate max. There needs to be just a little leeway in there, so try declaring slightly less like 150-160 kHz. Then the multiplexing clock can be set up for a rate that the device supports. However, doing so will make you more prone to the 2nd possible error cause below.
2. Your *actual* sample rate where the problem occurs is something greater than (3600 samples/chan/rev) * (2300 rev/min) * (1 min / 60 sec) = 138k samples/chan/sec.
I haven't personally tested engines but have been in discussions about such tests. By my recollection, there's quite a bit of speed variation within an engine cycle, maybe at least +/- 25% from the nominal? Well here, speed variation directly maps to sample rate variation. So a 25% variation on a nominal of ~138 kHz might easily give you sample rates that vary through 100-175 kHz range.
If you *do* get up to that 175 kHz range, you'll be stuck one way or another. You can't declare such a fast sample rate or you'll violate the 1.0 MHz aggregate rate for 6 channels. But if you declare a slower rate, the multiplexing clock will be set slower and all 6 channels won't yet have converted before the next encoder edge tries to start a new set of 6 conversions.
Summary: you're probably pushing too hard against your hardware limits. I think I'd focus this 100+ kHz sampling to the (likely) more dynamic torque and pressure phenomena. With only 3 channels to support, you give yourself a lot more safety margin for your clock rates vs. device specs. Then you can use a 2nd DAQ device to capture the 3 thermocouples at a lower rate, perhaps using a 1-per-rev signal as a sample clock. (You'll also need to sync their task starts with a trigger so you know both data streams start on the same engine cycle.)
-Kevin P
ALERT! LabVIEW's subscription-only policy coming to an end (finally!). Permanent license pricing remains WIP. Tread carefully.
