Hi pelesl,
I understand that this is frustrating. DAQmx doesn't remember what channel settings you used with a previous task, and sometimes people expect it to remember, but I think the inconsistent behavior you are seeing is more related to how DAQmx chooses the default value for various properties.
> 1. When you create a thermocouple channel, it is single ended. You
*must* excplicitly change it to differential (if that's what you want)
in a separate line of code.
For AIChannel.TerminalConfiguration on M Series, DAQmx chooses the default value based on which physical channel you are using. ai0:7 and ai16:23 use Differential by default, but ai8:15 and ai24:31 don't support Differential so they use Rse by default.
To see what the default value for this property is, verify the task and get the property:
myTask.Control(TaskAction.Verify);
foreach (AIChannel ch in myTask.AIChannels)
{
AITerminalConfiguration termCfg = ch.TerminalConfiguration;
int x = 0; // breakpoint here
}
The debugger should show termCfg=Differential for ai0:7 and ai16:23, and termCfg=Rse for ai8:15 and ai24:31.
> 2. In MAX, you can't even create a differential thermocouple channel.
The thermocouple versions of DAQmx Create Channel and the DAQ Assistant thermocouple settings were designed for SCXI thermocouple modules (which all have fixed terminal configuration), so they don't include the terminal configuration property. As a result, you can't change the terminal configuration from the default. The default isn't Rse in all cases: it's device-dependent and often channel-dependent.
> 3. Everything was working fine (in single ended mode) until I changed it
to differential. After that, it seems I now must explicitly call for
single ended or it will "default" to differential and measure relative
to a floating channel.
Did you also switch to a different physical channel? (e.g. change from ai8 to ai0?)
> 3. In DAQmx .NET enabling the filter does nothing---and it lets you set a
cutoff frequency, so I figured it was a digital filter done in "post
processing" somewhere inside the DAQmx library (just like the conversion
from voltage to temperature is done hidden away somewhere when you
create a thermocouple channel). Moreover, it seems the filter is a
channel property, but when you verify the task it tells you all the
channels have to have the same value. So that requires me to write a
for-loop to cycle through all the channels to make the filter properties
the same? Seems dumb.
The NI 628x has a hardware lowpass filter with a fixed cutoff. However, the DAQmx filter properties were designed to support SCXI modules that have independent filters per channel and configurable cutoff frequencies, so yes, you must set the cutoff frequency to be the same value on each channel. However, you don't need a for-loop to set properties on multiple channels. In LabVIEW or C you can use activeChannels="" and in .NET you can use AIChannels.All:
myTask.AIChannels.All.LowpassCutoffFrequency = 40000.0;
myTask.AIChannels.All.LowpassEnable = true;
What happens if you set the cutoff frequency to something else? DAQmx either errors (if the cutoff frequency is too high) or coerces it to the next best supported value. A few SCXI modules have switched capacitor filters that support thousands of filter cutoff frequencies, so coercion is helpful in some cases, but in hindsight it turned out to be a bit confusing for devices that only support one cutoff frequency. However, the behavior is unlikely to ever change for already shipping devices like the NI 628x, because changing it might break users' applications.
When DAQmx coerces properties, you can see what it did by verifying the task and getting the values of the properties, like I described for TerminalConfiguration.
> It takes me longer to find out which manual/help file to look at than to just cuss at the problem until I figure it out.
The NI 628x Specifications and the M Series User Manual should be the final word regarding what the hardware can do. The NI-DAQmx Help covers high-level DAQmx programming concepts (including property coercion) and some device-specific information about the APIs and properties, but for the most part, it doesn't overlap with the device user manuals and specifications. And the DAQmx .NET Help covers the various classes, methods, and properties, but it doesn't cover the high-level DAQmx programming concepts (that's in the NI-DAQmx Help) or the device-specific info (that's in the device user manual and specifications).
If you have a constructive suggestion on how to make this better (no cussing 🙂 ), please post it to the DAQ Idea Exchange.
Brad
---
Brad Keryan
NI R&D
