Have an idea for new DAQ hardware or DAQ software features?
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!
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.
Watch as the community gives your idea kudos and adds their input.
As NI R&D considers the idea, they will change the idea status.
Give kudos to other ideas that you would like to see implemented!
I love simulated devices, but one major drawback is the static nature of the simulated data. It would be awsome to have the ability to import real world data for playback in the simulated devices. Essentially analog input channels could take a waveform in or waveform file, digital in could take a digital file or even a popup probe for the input where the user can turn on/off digital lines or turn a nob on an analog line would be very nice to have. This would allow the programmer to capture real data that a system might expect to recieve and then run the daq application in simulation using daqmx simulated devices with the exact real-world data.
It would be great if NI offered a simple 4 Counter bus-powered USB device, like a USB-6601, but with the counter capabilities of the new X Series DAQ devices. This would give people who only need to perform counter operations a low-cost alternative to the bus-powered M Series, with double the counters.
For some time a few Mac and Linux users are complaining to me that they want DAQmx on the Mac and Linux. This makes LabVIEW more cross platform compatible and enables the users to use their measurement equipment to it's full potential. The Mac market share hits about 10% and Linux about 2% this seems to be a growing market. And mosth netbooks use linux as an os, therefore this will make excelent portable measurement station. This will open a new market for National Instruments and for LabVIEW programmers.
Since the drivers support the basic communication for the GPIB-USB-HS+ devices, the code should be ported to support the analyzer functionality as well. Create the driver API to support analyzer and then make that available to LV. Create cross platform LV routines for the analyzer functionality so it is available on all platforms.
It is a frequent requirement to make measurements on production lines. Position on these is often tracked with Rotary Encoders https://en.wikipedia.org/wiki/Rotary_encoder . Many NI devices can accept the quadrature pulse train from such a device, and correctly produce a current position count. The information in the 2 phase pulse train allows the counter to correctly track foward and reverse motion.
What would be very useful would be a callback in NI-DaqMX that is called after every n pulses, ideally with a flag to indicate whether the counter is higher or lower than the previous value, i.e. the direction.
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!
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.
Since NI already has the hardware interface devloped to USB and the PCI bus and its variants, why not leverage on that and create a line of hardware dongles that are compatible with MAX, LabVIEW and LabWindows IDE's. The volume may be low but it would be an integrated solution for ease of hardware/software interaction. Each dongle would have a unique serial number that the programmer's application can check and verify before allowing software operation.
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.
When using TDMS on cRIO systems, there are a couple of considerations that doesn't normally play in too much when storing data as TDMS files and they are:
* The current version of the file system used on cRIO controllers degrades significantly in performance if -any- folder on the cRIO contains more than ~100 files. (work-around> more elaborate folder structures, but a lot of this structuring would be only to work around this shortcoming of the (old) version of the file system
* The drives are SSD with limited life-length and wear-leveling etc. Writing and re-writing these index files add un-necessary overhead and wear on the disks
* They use up space which is (very) limited on some cRIO's (even if not much). (people may be quick to point out that you can add a thumb-drive, but down-sides to that is the thumbdrives (as far as I know) needs to be FAT. Compared to storing on the cRIO file system which is atomic and fail-safe where you pretty much don't have to worry about sudden power outages and interruptions mid-write.. on a thumb drive you would have all these issues that could worst case corrupt your whole thumb drive.)
I propose to add a boolean (default to false) on the TDMS Open called "supress writing tdms index to disk" or some smart name along those lines. What this would do is still allow for the tmds index to be created, but it will remain in memory only and never be written to disk. When the TDMS Close is called, the memory is released and the tdms file is written to disk without the index file. If the same file is opened again, extra time would be needed since the index file would be re-created (again in memory only if boolean indicates this), but I think for the most part this overhead would be more than acceptable.
I'm not sure how "simple" modifying the TDMS open and close functions would be, but I do know that there are many cases where this flag would make sense.
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?
I have a hard time explaning to clients that the little application that just monitors a few AI channels requires a huge (several 100'sMB) installer to run. It would be nice to allow for a small subset of daqmx to work. Maybe there is a way of doing this or maybe it is way too hard, but it would be nice to have the ability to filter support for devices and daq type on the drivers installation.
install only 6609 or 6008 AI only support where the installer would be a small fraction of the current size.
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?
There isn't anything in the event data node to tell you which line triggered the interrupt. I'm proposing we add something in the event data node for this event (like a bit field or a reference to the channel) so the programmer would know which line fired the event.
The workaround is you do a DAQmx read at this point and you mask the data vs previous data.. but I would prefer not to do this.
The 6602 can take an external timebase up to 80 MHz (according to the spec, it's actually a bit higher than this in reality).
The newer counter products do not have this capability (e.g. the 6612 has the same 25 MHz bandwidth limit as most of the multifunction products).
So whenever an application comes up (e.g.) where the user wants to count a fast external signal, the only reasonable option from NI is the 6602. This is fine for now, but in the future it would be nice to have some higher bandwidth counter options (unless you plan on selling the 6602 forever... hopefully it doesn't get too hard to come across computers with spare PCI slots though).
"Without needing to clear "all" associated events, or EVEN opening MAX, I would like the ability to replace NI-USB Device "Doohickey123" serial number "junkgarbagestuff" with another NI-USB device of the same type- perhaps a pop-up option like.... ""Replace no longer installed NI-53xx alias "gizmo" with new NI-53xx?""
Sure would help when I swap NI-xxxx devices amongst systems- especially the USB devices!
How feasible is the idea of setting up an open source driver project? This would be something that NI could host, but anyone could participate in to build a driver that can fit into different platforms. It can build on the DDK driver, but be centralized for collaborative effort. I like the name Open-DAQ driver. This would be a good way to address Linux users who are accustomed to source code. I know we have a DAQmx Base as a separate driver for different platforms, but an open source project would allow the Linux community to build a solution for novel or unusual Linux versions.