Data Acquisition Idea Exchange

Post an idea

1U Rack Mount cDAQ

cDAQ Chassis with integrated PoE/PoE+

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.

View All (2)

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.

Regards,

Dominic Clarke

Applications Engineer

National Instruments UK

View All (4)

LVDS Low-Cost USB Digital I/O Device

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.

View All (4)

Hi,

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: https://www.ni.com/en/support/documentation/supplemental/18/c-series-modules-with-anti-aliasing-filters.html

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

Cheers

Istvan Pinter | Sales Development Engineer, EMEIA

Expand Number of inputs on 9218 Card

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?

View All (2)

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

QQ图片20220412152952.png

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:

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.
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.
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).
The chassis firmware and functions in DAQmx should be updated or augmented consistently to support 1,2, and 3.
There should be example code showing how to implement these features

View All (1)

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.

View All (4)

View All (2)

Standard wiring examples.

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 http://forums.ni.com/t5/Multifunction-DAQ/Measuring-220VAC-with-CompactDAQ/td-p/1145956 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.

Thanks,

Chad

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

How can we help?

Please enter your information below and we'll be intouch soon.

This field is required

Preferred communication method

Email Phone call

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

Data Acquisition Idea Exchange

1U Rack Mount cDAQ

Add RSI Support to 9361 for Scan-Mode in EtherCAT 9144/5 Chassis

cDAQ Chassis with integrated PoE/PoE+

Create a new ±60 V version of the NI9205 C-Series Module

C Series HART (Highway Addressable Remote Transducer) Module/ HART Adapter

cRIO support hardware module for LVDT input

C series CAN interface module without external power supply

C series Digital Output module with push-pull outputs

LVDS Low-Cost USB Digital I/O Device

Signal conditioning modul in NI C Series incl. anti-aliasing filter

Expand Number of inputs on 9218 Card

When data is transferred from CRIO to PC by network stream, LabVIEW prompts to disconnect from CRIO terminal?

Use a NI cDAQ 913x chassis with integrated controller (WES7 OS) like a normal cDAQ Ethernet chassis

Add the ability to replicate data from a slow-sampled device to single slot DAQ chassis

Host Reservation of cDAQ Chassis (network/CAT5 Interface)

Low noise CompactDAQ card for microphone measurements

C Series Module which Provides Back Up Battery

More than one DO Timing Engine in cDAQ Chassis

Standard wiring examples.