Home > Community > Discussion Forums

Data Acquisition Idea Exchange

Showing results for 
Search instead for 
Do you mean 
The NI Idea Exchange is a product feedback forum where NI R&D and users work together to submit ideas, collaborate on their development, and vote for the ones they like best. View all of the NI Idea Exchanges to post an idea or add your opinion on an existing one today!
New Idea

PCI express versions of PCI AO cards

Status: New
by Member Peasoup on ‎06-13-2011 04:04 AM



I'd like to see PCI express versions of existing PCI Analogue Output cards eg PCI6713 and PCI6733.


I'm finding it quite difficult (and quite a bit more expensive) to source desktop PCs featuring PCI slots.



Hi all,


Any series card should have a feature listing different  parameters like voltage, temperature etc it supports(May be a property node should be used). so that user can configure the required parameter among the supported.

Ex: SCXI -1520 module can be configured as Strain, Pressure or voltage but this information will be known only by seeing its manual or when a task is created in MAX. But in LabVIEW               Software i cant get this information directly. Because it allows me to configure 1520 as temperature also and we will come to known that 1520 module doesn't support for temperature       parameters only when once tried to acquire.


So what you people think about you.Share your ideas on this please. 




I continually come to your site looking for the DAQmx base API manual and have yet to find it.  I eventually have to dig out an old CD to find my copy.


How 'bout posting these online so that we can help ourselves out of jams?




The title pretty much says it all. I would like the ability to either configure a full hardware compliment as simulated devices then switch them over to real devices when the hardware arrives or go from real devices to simulated devices without the need to add new, discrete simulated devices to MAX.


This would make for much easier offline development and ultimate deployment to real hardware.

When it comes to documentation of an measurement, you need to report ALL settings of a device that effects that measurement.

From a core memory dump written as a hex string to a XML document.... anything that shows up a difference in the settings that affect the measurement would be fine for documentation.

Something like a big property node readout followed by a format into string .... but make sure not to miss a property.... and a bit more complicated when it comes to signal routing....


A measurement that isn't sufficiently documented is all for naught. 


Just think of a nasty auditor Smiley Wink


It's so easy to make measurements with LabVIEW, please make it easy and consistent to document it.



A quick measurement setup with the DAQ-assistant/Express fills Gigabytes but after a certain time they are useless because nobody knows how they where taken. A simple checkbox could add all this information in the variant of the waveform. (or TDMS or ...) even if the operator don't have a clue of all the settings that affect his measurements.


This is pretty trivial to achieve through LabVIEW itself, but...


Signal Express is a simple, stand alone data acquisition system that allows those with limited exposure to LabVIEW set up simple test and measurement routines. One area where this is ideal - at least, for me - is in environmental or long life testing. Instead of crafting a beautiful piece of custom software for my colleagues, I can hand them a DAQ, point them in the direction of the SignalExpress and DAQmx installers, and off they go. With a little fiddling, they can create a logger that suits their needs.


One thing I've noticed, however, is that when sampling with non-simultaneous cards such as the USB 6225, users will select 1-pt-on-demand, set to some big interval, and then come back screaming at the top of their lungs - "OHMYGOD THERE'S CROSSTALK BETWEEN CHANNELS!". With a little bit of fault-finding, it's easy to point out that it's not crosstalk, but ghosting between channels, because I would guess that 1-pt-on-demand uses interval sampling and rattles through the multiplexing as quickly as it can.


My idea: give users the option to either select round-robin mode with a sensible delay, or complete control over the interchannel delay.


I realise that the standard line is usually "use LabVIEW" - I do - but I'd rather spend my time working on the important stuff and empowering those with less experience and/or exposure to make accurate measurements.

Multiple people have requested that there be a natural way for Labview and SignalExpress to do a rotational speed measurement using a quadrature encoder. An express VI under "Acquire Signals>>Counter Input>>Rotational Speed" that asks you basic quadrature encoder type questions and computes the rotational speed would be very useful. The information it asks would be things such as Ticks per Revolution, Decoding type (x1, x2, x4) would be useful in computing rotational speed. In addition, this can be then converted into a shipping example for DAQmx relatively easily. I have had multiple people ask this question and believe that especially within SignalExpress, this would be very useful.






New Terminal Block for 100-Pin-Devices

Status: New
by Member A-T-R on ‎11-19-2012 04:14 AM

NI provides some 100-Pin-DAQ devices, e.g. one for INDUSTRIAL DIGITAL IO



But why doesn't you offer also a basic connector block for a reasonable price, especially for industrial applictations, where it is common to wire (DIO) signals through DIN rail mounted terminal blocks?


This connector block should have the following features:


- DIN rail mountable

- simple wire connection, best with spring terminals

- 100 Pin-cable connection


- relatively small for installation in a switch cabinet

- no signal conditioning, just clamps

- much cheaper than then currently available SCB-100 block


Please see also this related idea:






Provide better Daqmx .NET API documentation

Status: New
by Member KrisJa on ‎08-20-2013 02:53 PM

I use Daqmx a lot for writing .NET based measurement software.


Whereas the API itself is quite decent, the docs are horrible. Accessing them is convoluted at best, requiring the VS help viewer. Almost nothing is available online and decent examples are quite scarce, which will definitely be an issue for absolute beginners...


This definitely deserves some attention!





Data Acquisition for iPad

Status: New
by Member JeffGrove on ‎04-13-2011 07:55 AM

Would like to be able to collect a couple channels of analog inputs to the iPad.  This is nice but I need a minimum of 2 analog inputs and I would rather have NI:  http://www.oscium.com/


Response from coorporate:

"We don't currently have anything that would meet the customer's requirement of being able to plug in directly into the iPad for data acquisition.

I don't believe that the iPad supports Silverlight which is a framework developed by Microsoft.  Also, wireless DAQ has to communicate with a host running DAQmx, so the customer would still need a 2nd computer even if using wireless DAQ.

If you want to connect data acquisition hardware (of any form-factor) to a machine running LabVIEW and DAQmx,  then use LabVIEW Web Services to publish the front panel to the web and view/control it from his iPad.

We do have several USB products that will work with Windows-based netbooks that could be an alternative solution if topic is open to a non-Apple platform.  For example, the 5132/5133 are bus-powered digitizers with much higher sample rate, bandwidth, and buffer size compared to the Oscium device.  However, the price is also quite a bit higher."

I could use a USB X series multifunction device with more than 4 AO analog output channels.  My current application does not require them to have waveform generation capability.  There are devices available with more than 4 AO but I need AI and DI/DO and CTR as well and prefer them all on one device.


It has come up a few times from customers, and I wanted to gauge interest and solicit ideas on how this should work.


Currently, with the built-in TDMS logging support, if you want to change to a new file in the middle of logging, you need to stop the task and start again.  For some use cases, this isn't practical (for example, http://forums.ni.com/t5/LabVIEW/Why-the-TDMS-file-is-larger-than-it-should-be/m-p/1176139#M511099).


The question is: How would you like to specify the "new file" behavior and what are your use cases?


For instance, a couple ideas to get the ball rolling:

  1. Add an interval attribute like "Change file after n samples".   We would then auto-increment the file name and change to that file when we have logged "n" samples.
  2. Make file path attribute changeable at runtime.  We have a file path attribute for logging.  The idea here would be to support changing the file path "on the fly" without stopping and starting the task.  The problem here is that it would not suit very well a use case where you want a specific file size.  Additionally, it wouldn't be as easy to use as #1; it would be more flexible though.
  3. (Any additional ideas/use cases?)

Thank you for your input!


Andy McRorie


It has come up a few times from customers, and I wanted to gauge interest and solicit ideas on how this should work.


Currently, with the built-in TDMS logging support, if you want to change to a new file in the middle of logging, you need to stop the task and start again.  For some use cases, this isn't practical (for example, http://forums.ni.com/t5/LabVIEW/Why-the-TDMS-file-is-larger-than-it-should-be/m-p/1176139#M511099).


The question is: How would you like to specify the "new file" behavior and what are your use cases?


What I'm currently thinking (because it seems the most flexible to different criteria and situations) is to simply allow you to set the file path property while the task is running (on DAQmx Read property node).  The only downside I can think of with this approach is that you wouldn't know exactly when we change to the new file.  We could guarantee within (for example) 1 second, but you wouldn't be able to specify the exact size.


Would this be a good solution for you?  Can you think of a better way to specify this behavior?


DAQmx Device events

Status: New
by Proven Zealot Proven Zealot on ‎09-11-2009 12:34 PM
While running a test I developed I noticed an odd DAQmx behavior.  After a USB 6212 connection was momentarilly interupted all read and write tasks associated with the device hung until the USB cable was disconnected.  It would have been easy to code around if there was a Dev connection event and a Dev disconnection event that I could use to pause operations and trigger a Device reset.  Since the devices are PnP couldn't the DAQmx API simply make the system hardware connect/disconnect events visable?

USB 3.0 support

Status: New
by Active Participant NIF_Vincent.O on ‎02-10-2012 04:41 AM



I don't know if there is already an "idea exchange" about this, it could be usefull that USB devices or adapter support USB 3.0.

A device isn't recognized through an USB 3.0 port.


Thanks !


Vincent O.

Currently, DSA devices that use voltage excitation have no method to provide that excitation to a particular device within test panels. The only method to do this would be to create a task in Measurement and Automation Explorer which takes much more time that doing a simple test panels test. This should be a fairly simple addition to the test panels user interface. One could simply have a box to check if they require excitation, and a control to determine the voltage level to provide to the DUT. They currently have this for IEPE devices, and it makes sense that voltage excitation should be the same.

Status: Completed

I would like to have an programmable gain amplifier in the analog output path that I can use to adjust the amplitude of an output signal.  In control applications, this would be much better than having to stop a continuous task, reload the data with a new amplitude, and start the task again.


Ideally, for some of my applications, it would be nice to be able to generate a basic waveform scaled to +/- 1V and then have a property that I can write to while the task is running to set the gain.

Dedicated RTD card for PXI platform

Status: Already Implemented
by Member BWP on ‎01-27-2012 10:51 AM

Despite having dedicated RTD cards on other platforms, this doesn't exist on PXI.  The existing bridge input cards have significantly higher sample rates than needed for typical temperature measurements, and it would be nice to have a more economical drop-in option for RTDs that supported more channels.

Hardware Idea/requests exchange

Status: Completed
by Trusted Enthusiast on ‎03-09-2010 07:50 AM

It would be nice to have a hardware request forum as well so NI could see the demand for producing hardware for us. 

Just A few things I could use or want:

cDaq counter modules, like a 6602 in cDaq form so I can add more counters to my compact daq module, a lower end crio 'brick', think like a 6009 morphed with a single board rio, something under 1k for simple embedded data logging prototypes.  Maybe support for PIC micros (FPGA is so empowering, more microcontroller programming native to labview would be very nice to add to our toolbox).


would a seperate HW forum be helpful?

Status: Completed
We have a Data Acquisition Idea Exchange now. Please create new posts for individual requests.

When I want to do an installation build of my project, I have to include the whole NI-daqmx into my build in order to insert my (in this case) USB-6251-driver. Thus my install package expands from about 150 MB to more than 1 GB. This is way to much!


It would be nice to be able to choose only the wanted driver (in my example the NI-6251 and the SCC68) in the "adding additional driver's" menu and just add this one to the distribution instead of "adding them all".

Suggest NI produce an inexpensive (<$100) USB "stick" that has 2 hardware counters on it for optically isolated measurement of encoders, or other high-speed devices. The stick would have a standard connector it for easy wiring of differential encoders with ABZ lines. The device would enable measuring two separate encoders or track two sections of a shaftless drive line that needs to position-follow. One or two DIO lines would be a bonus. This would seem to be a good fit for the industrial machine markets (at the very least). Today you need to buy a multifunction daq for a several hundred dollars if you want two counters.


Contact me with any further questions.



Thank you!


Rick Yahn

QuadTech, Inc.




About Data Acquisition Idea Exchange

Have an idea for new DAQ hardware or DAQ software features?

  1. Browse by label or search in the Data Acquisition Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see implemented!
Top Kudoed Authors