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!
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.
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!
I use always MAX to configure my DAQ cards to remove the burden of writing every time the same code just to create a DAQ task. MAX is part of my LabVIEW tool base and every project where I use a DAQ card does have a MAX config file.
Everything is nice, until I have to add some third party hardware! Then I have either use the driver provided with the hardware or write my own driver. I cannot use MAX to configure it, therefore I have to write VIs to allow online configuration. I also have to write VIs to load and save the configuration of the hardware. It would be much simpler, if the supplier of the third-party hardware or I could write plug-ins for MAX (and DAQmx) to incorporate the hardware in LabVIEW (and of course other software, which uses MAX). I could use the same API for nearly all of my hardware. One example from a competitor for this kind of hardware integration is Ipemotion of Ipetronik. There is even a plug-in for DAQmx in Ipemotion!