From Saturday, Nov 23rd 7:00 PM CST - Sunday, Nov 24th 7:45 AM CST, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Saturday, Nov 23rd 7:00 PM CST - Sunday, Nov 24th 7:45 AM CST, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
05-11-2023 07:56 AM
I am developing a general data acquisition and control application that interfaces with unknown hardware. I have observed significant inaccuracy when AIConv.Rate does not allow adequate settling time when measuring multiple channels on multiplexed devices (interestingly, the DAQmx default of AIConv.Rate = 1/[1/SampClk.MaxRate + 10us] has proven inadequate by about a factor of two with the NI hardware I have been doing testing with). However, this is obviously not an issue when not multiplexing. Therefore, I want to programmatically identify whether the device I am interfacing with multiplexes when measuring multiple channels so that my application knows to set AIConv.Rate and SampClk.Rate appropriately.
Is there a DAQmx property or similar that indicates whether an NI data acquisition device multiplexes when measuring multiple channels? I infer from the following page that DAQmx is able to determine this as it states "Padding time is only set by the NI-DAQmx driver when measuring multiple channels on multiplexed devices" (https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019PBzSAM).
Solved! Go to Solution.
05-11-2023 08:49 AM - edited 05-11-2023 08:50 AM
05-11-2023 09:04 AM
Thanks, GerdW. I haven't tested it yet, but that seems to be exactly what I'm looking for.
05-11-2023 10:39 PM
For @GerdW's solution to work with multi-device systems you need to specify the device, then query the property node. Like Below
05-22-2023 05:43 PM
Yeah, I realised that, but thanks anyway, Mcduff.
I just wanted to follow up to correct one of my original statements in case anyone else comes across this thread. My claim was that the DAQmx default AIConv.Rate was inadequate by a factor of two. This was based on being advised that there was no additional impedance between the sensor and the NI device, and knowing the source impedance was such that we should have achieved shorter settling times than those quoted on the NI device specifications. Following a DC signal settling time test, the total implausibility of the result demanded investigation, and it was discovered that a capacitor was actually present across the signal wires between the sensor and NI device that explained our long settling error decay time constant, and, once removed, we began observing settling times originally anticipated.