Data Acquisition Idea Exchange

Community Browser
Top Authors
Showing results for 
Search instead for 
Did you mean: 
Post an idea

I would like to see a version of the 4-slot cDAQ-9185, but where the 4 slots are arranged the long way, and the whole thing fits in a 1U slot on a standard 19" rack.

RSI support of the NI 9361 counter module would allow for use in scan-mode within 9144/5 EtherCAT chassis. I have several use cases for this that mostly would benefit from distributed acquisition and end-user-configurable I/O.

Having the ability to connected a cDAQ chassis to a PoE or PoE+ switch.

Then the cDAQ does not have to be powered locally.

Ethernet is throughout our facility the ability to drop a cDAQ chassis with sensors and not worrying about power would be helpful.

Currently I am using external hardware to power cDAQ chassis off of PoE+ switch, it would be nice if it was integrated.

One of my nodes includes 4-slot chassis with two CAN cards, a temperature card and an accelerator card.

Currently there are only two options for acquiring +/-60V input signals:

NI 9221: 8-Channel, ±60V, 12-Bit Analog Input Modules ($582)

NI 9229: 4-Channel, ±60 V, 24-Bit Simultaneous,Channel-to-Channel Isolated Analog Input Modules  ($1427)


I would like to see a new module provided that is identical to the NI9205 (32-Channel Single-Ended, 16-Channel Differential, ±200 mV to ±10 V, 16-Bit Analog Input Module, $881) but with an input signal range of ±60 V.



Dear NI Idea Exchange,


I had a service request recently where the customer wished to use a mass flow meter, using the HART protocol (massive industrial protocol used worldwide with over 30 million devices) to communicate updated values to a cRIO 9074 chassis using a NI 9208 module.


They did not know how they could use this protocol with our products. There was only one example online regarding use of this protocol using low level VISA functions. There is currently no real support for this protocol.


I suggested that if they wished to use this sensor they would be required to convert it to a protocol we do support, for example Modbus or to RS-232 (using a gateway/converter).


Then they could use low level VISA functions to allow the data communication.


They were fine with doing this but they felt that NI should probably support this protocol with an off-the-shelf adaptor or module. This is the main point of this idea exchange.


There is clearly a reason why we do not currently provide support for this protocol in comparison to PROFIBUS or Modbus.


I thought I would pass on this customer feedback as it seemed relevant to NI and our vision. 




Dominic Clarke


Applications Engineer

National Instruments UK

It would be great if there is c series CAN interface module which doesn't need an external power supply. This makes it easy to use and saves time to set up because we don't have to find or prepare an additional power source.

While I realize that there is already a third party option for this, it only makes sense that NI open an option for the cRIO users out there that can do what this module does...


in a cRIO platform module. That way we can have a North Anmerica source for this very important data input device.


Optimally two - four channel input on a single module design.

I would like to see a C series module just like the NI 9474 only with push-pull outputs.



There is a need for a quick low cost device to controlling/communicating with the popular low-voltage differential signaling (LVDS).  There is a need for transmit only, receive only, and transmit/receive USB devices.  The current solution is to buy the NI USB-6501 and build a daughter board with TTL-LVDS ICs on it to interface to digital equipment in the military/defense industry. Lots of time and energy is wasted on designing, building, and cabling boards as as additional interface step, where a simple USB solution could be made available.

Currently there are only two options available if you want a C-series card that has ±10V analog inputs with internal excitation voltage. Both of the available options have serious limitations which makes them impractical in dynamic testing environments. 


9218: With two input channels, it is impractical for large channel count testing. As an example at our test facility, we may run 60 analog channels which would require 30 of these cards. That would require 4 cRIO chassis' 

9219: With a max sample rate of 100 s/s, it cannot be used in a dynamic environment to accurately record data. 




There are two options that would be very beneficial to dynamic testing:

1) Add more input channels to the 9218 card so that high channel count tests don't need 3+ cRIO's. 

2) Make a new card similar to the 9218 with less capability but more input channels (No bridge, no IEPE, no ±20mA). 

For example:

± 5V, ±10V, ±60V Input Range

± 1V, ± 5V, ± 10V Internal Excitation

Minimum of 4 analog input channels.

Sample Rate 5 Ks/s


Does anyone else have a need for a card like this?

当我使用网络流将数据从CRIO传输到PC时,程序正常运行几秒钟后,它提示我断开与CRIO终端的连接。此时FPGA的采样时间为1 uSec。当我将采样时间增加到大于 1 uSec 时,程序运行良好。也就是说,当程序的采样率低于1MS/S时,程序可以正常运行,当采样率等于1MS/S时,程序就会出错。是不是因为队列和网络流写得太慢了?请帮帮我,谢谢。


We own mutliple cDAQ chassis: some with integrated controllers (913x) and some without (9188, 9189).


Sometimes all chassis without integrated controllers are used, and only chassis with integrated controllers are available.


In such cases, it would be nice to use a chassis with integrated controller just as normal cDAQ Ethernet chassis.


Maybe NI could make that possible by a upgrading the 913x Firmware?


I am aware of the previous idea here on a filter for the USB DAQ devices, this time I propose a different solution.

Some cDAQ moduls include an anti-aliasing filter, see a documentation here:

In many cases our cDAQ and cRIO system could be the solution to higher frequency (100 kS/s - 1 MS/s) voltage signal acquisition if the signal could be (from LabVIEW) programmatically conditioned prior acquisition. Two main processes are required most: amplification/attenuation and filtering.

I think amplification/attenuation is a trivial processing step, I just mention here a flat frequency and phase transfer requirement in the working range, allowing a bypassing of this stage.

Filtering is a little more challenging. My proposal is a "tunable" anti-aliasing filter, fo the sake of simplicity with one programmable cut-off frequency and fixed roll-off charasteristics. Similarly high pass and band pass filters could be implemented but these are just nice-to-have features. Please note that all filters should be in hardware, e.g. some ASIC before any ADC.

Thanks for your attention


Istvan Pinter | Sales Development Engineer, EMEIA

Currently with a multislot chassis, the system will operate at the requested sampling rate even if that rate is above the maximum supported by the module.  In this case, the chassis will replicate the additional required data points from the previous sample, and will not return an error in NI MAX.  With a single slot chassis, this is not an option.  However, it would be helpful if this feature was also supported with the single slot chassis so that data could be replicated at a higher sample rate without returning an error message.


Relevant KnowledgeBase article: Why is My Slow Sampled C Series Module Able to Operate at a Higher Sampling Rate than the Specified Maximum Rate?





When a cDAQ (I'm using both a 9184 and 9188) chassis is energized (or the host computer is rebooted) it is programmatically read as reserved (by either MAX or LAbVIEW program). To gain control of the chassis, one has to either use MAX (MAX deosn't save or remember the previous reservation) and reserve it or programmatically force the reservation in the LabView code. In addition, if a chassis is reserved by a different host, another host can force the reservation by itself programmatically. Both of these can be accomplished by using the reserve chassis function with the 'Override Reservation' input set to True. This really is not a good method - it's effectively a hostile-takeover of the hardware (I've tried this and I can literally reserve hardware that is actively being used by another host).


I would recommend the following firmware/driver/software updates/corrections:


  1. When a chassis is power-up it should be in an ‘unassigned’ state. Basically it will be in 'standing-by' waiting for a job/task.
  2. When a host interrogates the chassis it should only be able to ‘reserve’ it if it is in the ‘unassigned’ state. Once the chassis is reserved by a host it is locked to it until it is either unreserved by the host or power is cycled to the chassis and it reboots, returning it to the unassigned state.
  3. When interrogated, a ‘reserved’ chassis should provide the identification of what host has reserved it. This would allow redundant or multi-host configurations to find each other and do things like handing-over a chassis between hosts. This is useful if a host error is detected (redundant host system) or a host needs to be taken offline for service and the process can’t tolerate extended interruption (and it's useful to do this programmatically).
  4. The chassis firmware and functions in DAQmx should be updated or augmented consistently to support 1,2, and 3.
  5. There should be example code showing how to implement these features

We use often the NI CompactDAQ 9234 for sound measurements.

Our standard microphones with iepe amplifier have a noise level of about 16 dB(A) and sensitivity of 40...50 mV/Pa.

The noise of the 9234 is about 50μV rms, corresponding to a sound level about 32 dB(A). So we can use this microphones only for measurement above 35 dB(A).

A better version of a card 9234 with 2 ranges 5V and 0.5 V would be very useful. The noise in the lower range should of course  not exceed the range of 5...10 μV (12..18 dB(A)).

And many monitoring systems have only one Microphone, so we use only one channel of the 9234.

For this cases would be a lower priced one channel card OK.

A two channel card would be perfect: two channel measurement of one microphone signal in both ranges. The  sound level program can measure from 20 dB(A) ... 136 dB peak without range switching.



In the case of a power failure on a cRIO or cDAQ having a C Series module which could provide back up power would be helpful.


We can use this to:

  • Keep the system clock going on cRIOs that do not have an internal battery
  • Take time stamp of the crash
  • Grab the last known value of shared variables and store them for the reset
  • Perform any shutdown operations that are nessecary

I am not an electircal engineer, so I have no idea if there is some reason this has not been implemented in exiting versions of teh cDAQ chassis.  But there are a whole host of applications where a user wants to do Hardware timed digital output to different channels using DIFFERENT time bases.  It would be nice to have more than one DO timing engine available.  I would love to see that in future versions of the cDAQ chassis.




I'm not sure who reads this, but I'm not seeing any feedback in the forum so I thought I'd post up here.   This may seem like a simple thing, but hopefully my pain will be someone else gain.  I messed with this off and on for two months before I finally figured it out.  It's probably obvious to those who work with this equipment every day and have EE degrees, but not so much to those of us who do not. 


Please see for a description of the issues I was having. 


Some will tell me to "search"... well, I did.  ...and everywhere I looked all I found was that I needed to measure from the power leg to ground.  All of the examples either were only measuring 120 which is fine since what you have is one power leg and neutral... which is basically ground!  So those numbers come out fine.  Or they were for 3 phase, which I don't use currently.  BUT when you try and measure anything with two power legs (basically anything between 208VAC to 240 VAC) the numbers don't work out right if you try to measure between each power leg to ground and then try to recombine them and plug them into the Power VI's.  Not one place that I looked did it tell me that I need to measure both power legs across a single channel.  I only finally tried it because I'd done pretty much everything else.  I know this is pretty basic stuff, but when all you give me says one thing... that's what we do.  Just trying to help others.