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.
National Instruments UK
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.
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.
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.
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:
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.
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.
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 ...
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/Measurin
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.
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: