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.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Is it possible to programmatically determine whether an NI DAQ device multiplexes when measuring multiple channels?

Solved!
Go to solution

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).

0 Kudos
Message 1 of 5
(1,067 Views)
Solution
Accepted by topic author banksey255

Hi banksey,

 

check the DAQmx properties:

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 2 of 5
(1,039 Views)

Thanks, GerdW. I haven't tested it yet, but that seems to be exactly what I'm looking for.

0 Kudos
Message 3 of 5
(1,028 Views)

For @GerdW's solution to work with multi-device systems you need to specify the device, then query the property node. Like Below

 

ship.png

0 Kudos
Message 4 of 5
(940 Views)

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.

Message 5 of 5
(714 Views)