The vast majority of my working life is spent with RIO devices or midrange X series cards, but I often come across applications where an inexpensive, reliable DAQ would be handy for low level tasks - monitoring presence sensors, measuring voltages at moderate precision and slow speed, providing interlocks for material storage bins etc.
Traditionally, you'll see a lot of USB 600X units being used for applications like these. However, running on USB has a few associated problems: unreliability of the Windows bus, cable strain relief on USB connectors, mounting of USB 600X units, connection type. Don't get me wrong, you can do a lot with these units but they're not an ideal, inexpensive solution for production processes.
There's a jump between the functionality of these USB units and X (or even M or E for the vintage crowd) series cards. The only thing that's really in that range anymore is the B series PCI-6010 card, which has the fantastic benefit of using a 37W DSUB connector too, but is a little limited in terms of channel offerings and the like.
I'd like to see the B series range revived to provide products that fit between the PCIe-6320 and the USB 600X devices, providing non-USB connection and preferably with a DSUB backplane connector for cost and ease of use. This would provide a more reliable offering for simple acquisition tasks in the industrial environment at a cost-effective price point.
We mostly develop PXIe based high speed (RF) applictions which stores data on one or more RAIDs.
Several customers already asked for a high speed ethernet connection do move this data over the net.
Yet there is only one PXIe 10 GBE availible and it is NOT from NI.
We would already need a 40 GBE solution the comming year.
PCI Express 40 GBE ist almost commonly avalilible, a mezzanine board solution would be sufficient if nothing else works.
But there is no carrier board availibe, too.
I feel kind of left alone with all this data, waiting on those bigg RAIDs for beeing processed / copied.
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.
How often you have build Labview applications using simulated DaqMx boards ...
And how often you were limited by the default behaviour of simulated boards ... ( Sinewave for analogic inputs, Counter square signal for digital inputs ... )
It would be nice to integrate in DaqMx simulated boards, the abilty to modify the default behaviour of simulated inputs ... thru dedicated popups
It would be nice, for each task linked to a simulated daqMx board, to launch a popup window ...
A more powerfull tool could also integrate a simulated channels switching mechanism ... A simulated output could be linked to a simulated input
This feature could be a good way to create an application which could simulate a complete process ... this application could be used to validate a complete system
(such a kind of SIL architecture)
Other idea .... A complete daqMx simulation API ...
Something like this ...
NI Terminal block layout should be designed so that wiring can be done straight from terminal to wire trunking.
For example TBX-68 has 68 wire terminals aligned to inside of the terminal block. This causes that each wire should make tight curve to wire trunking. Another problem with TBX-68 is that wires are heavily overlapped because of the terminal alignment.
Also the cables from terminal block to DAQ device should be aligned to go directly to wire trunking (not straight up).
I recently discovered that the SCXI-1600 is not supported in 64-bit Windows. From what NI has told me, it is possible for the hardware to be supported, but NI has chosen not to create a device driver for it.
I'm a bit perplexed by this position, since I have become accustomed to my NI hardware just working. It's not like NI to just abandon support for a piece of hardware like this -- especially one that is still for sale on their website.
Please vote if you have an SCXI-1600 and might want to use it in a 64-bit OS at some time in the future.
Based on this question, I would like to add a new category of events to LabVIEW: Max-events.
This category could contain the following events:
If you know other events, please post them.
I find myself quite often needing to modify the DaqMX tasks of chassis that aren't currently plugged into my system. I develope on a laptop, and then transfer the compiled programs to other machines. When the other machines are running the code and thus using the hardware I have to export my tasks and chassis, delete the live but unplugged chassis from my machine, then import the tasks and chassis back in generating the simulated chassis. When I'm finished with the task change and code update, to test it I have to export the tasks and chassis, plug in the chassis, and re-import to get a live chassis back.
Can it be made as simple as right clicking on a chassis and selecting 'simulated' from the menu to allow me to configure tasks without the hardware present?
Certified LabVIEW Developer
As someone who migrated entire product lines from PLCs to cFieldPoint platforms, and now is in the process of migrating further into cRIO platforms, I am finding some cRIO module selection limitations. One big gap I see in the selection is with analog in/out modules. A set of 2-in / 2-out analog modules would be very welcome, offering standardized +/- 10V or 0-20mA ranges. There are a many times in our products that we need to process just a single analog signal, which now with cRIO requires 2 slots be used, with many unused inputs and outputs (which just feels like a waste of money and space).
Every time I have to work with a NI daq device the first thing i need to know is what pins can or cant do something.
Currently this involves looking through something like 7 diffrent documents to find little bits of information and bringing them back to your applicaiton.
A block diagram could easily be a refrence point for the rest of the documentation (you want to know about pin IO for your device look at this document)
Plus a good block diagram can tell you what you need to know quickly, and clearly. A picture is worth 1000 words?
Some might find the current documentation adiquite, but personally i would really like to have a block diagram that represents the internals and capiblities of the pins and device in general. Most Microcontrollers have this and it is an extremly useful tool. So why not have one for the Daq devices as well?
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
NI supports almost any bus. Why not SSI (synchronous serial interface) ?
Of course, there is always the option to use an R series card and then build an interface. Why not have a low-cost PCI or USB card? Also, perhaps a C-series module, so that we don't have to take up FPGA space?
Dear NI, please consider a future hardware feature addition:
Add a "Power Up Delay DIP Switch" to the back of the PXI Power Supply Shuttle.
It would allow end users to reliably sequence the powering-up of multi PXI chassis solutions. It could also be handy to sequence any other boot-order sensitive equipment in the rack or subsystem. This would also be a world-voltage solution since this capability already exists in the power shuttle. We are seeing the need for more input-voltage-agnostic solutions. I'm sure you are too.
It might offer time delay choices of 1,2,4,8,16 seconds, etc.
We run into this problem on every multi-chassis integration. We have solved it several ways in the past like: human procedure (error prone), sequencing power strips ($$$ and not world-voltage capable), custom time-delay relays ($$$).
Imagine never having your downstream chassis(s) disappear. Or worse yet, having them show up in MAX, but act strangely because of not enough delay time between boots.
Thanks for reading this, and consider tossing me a Kudos!
Absolute encoders have been around for some time, but NI's motion hardware still supports only incremental encoders. I would like to see support for absolute encoders in NI Motion or NI Soft Motion.
With NI 9234 board you can use 4 IEPE sensors but you don' have IEPE open/short detection capability.
NI 9232 board has IEPE open/short detection capability but has only 3 channels.
I think that a board with 4 channels (as 9234) and an IEPE open/short detection capability would be great!
NI should make sure that the measurement uncertainty specifications for its DAQ hardware are aligned with uncertainty analyses that are performed according the ISO "Guide to the expression of Uncertainty in Measurement" (GUM). See http://www.bipm.org/en/publications/guides/gum.htm
May be speaking for myself here, but the M-Series DAQ in USB forms have mass termination option (to connect to VHDCI connectors) and the X-Series do not. Why?
We have hardware that is already setup for the 68-pin cables, and I would like to take advantage of the portability of the USB, and the extended performance of the X-Series vs. the M-Series. Specifically I was comparing teh USB-6361 X Series and the USB-6251. The price difference is minimal for the added sample rates and extra counters. But without the mass term option, I am forced to settle for lesser hardware. This should be fixed.