Data Acquisition Idea Exchange

If the 5 volt output power terminal were available as an Internal Channel in DAQmx, then its actual value could be measured.  That would allow accurate use of it as the power source for example for external bridge or voltage divider measurements which rely on knowledge of that voltage.  On the X Series USB-6343 for example, that terminal is on pin 96.

Some of our competitors provide a module that can measure low frequencies (typically for water meters) with no needed excitation voltage. It would be great to see a Compact FieldPoint module with similar capabilities 

I have recently upgraded the CPU in one of out test stand to the Window 7 operating system.

I was able get drivers for all of the 13 PXI cards that are used in the tests stand with the exception of the PXI 4351.

I use this card primarily for voltage measurements although I occasionally do use it with thermocouples. 

I see that the card will be obsolete in September and that is disappointing. 

This card was not inexpensive when we purchased it and the replacement is near $2000. Dollars. 

I really hope that an updated driver would be available before NI quits supporting their current product.

There are a few different versions of the NI USB 9211 Thermocouple Module.  The USB 9211 is now a legacy device and the USB 9211A is the upgraded version for higher performance.  The issue that I have seen when using the USB 9211A for Mac is that the DAQmx Base drivers that support the USB 9211 are different than the drivers that support the 9211A, but the device itself does not specify which version of the 9211 the customer has. DAQmx Base 2.1 supports the 9211 and DAQmx Base 3.2 supports the 9211A, but the device will not be recognized if the incorrect driver is downloaded.

My suggestion would be to print the "A" after the 9211 on the new devices to make sure that the customer knows which driver to download for their device.

We have a need to a DAQ card that can handle more than 10V.  I know there's an SC module that does 300V, but antenuation by 30 in signal conditioning seems a bit much.  In retrospect, Agilent has a 100V input PXI card without the signal conditioning (32 Channels, 16-bit, 250kS/s).

Consider the case where you have a cDAQ II chassis filled with analog input modules. If I have several modules that are running at the same rate I can use channel expansion to include them in the same task. Since they're in the same task they will have the same timing and triggering and will share the same timing engine. This leaves the other two timing engines available for tasks with different timing constraints. If I want to dynamically change the sampling rate of just one of the modules I would have to stop the task and, hence, the acquisition on the other modules. If the same timing engine could be shared among tasks, each module could have its own task and be independently controlled. I imagine this would involve a lot of changes to the DAQmx task structure but it's something that would come in handy.

Some NI boards have different properties for different channels.  For example the NI 4432 has ICP power available for channels 0 through 3 but does not have ICP power for the channel #4.  Please add the IEPE or ICP power support and AC/DC coupling support information to the DAQmx Physical Channels Node. 

Based on this LabVIEW Idea...

Support the iPad as an execution target

Adding this type of support would allow NI and others to develop applications similar to the Oscium oscope using NI DAQ hardware.

I recently had a customer offer the suggestion to expand the support for the USB-8451 to include a coding environment that includes .NET. Currently the only supported development environments are:

LabVIEW™ 8.5, 8.6, LabVIEW 2009 (32-bit), and LabVIEW 2010 (32-bit)
LabWindows™/CVI™ 8.0 (or newer)
Microsoft Visual C/C++ 6.0

I just wanted to share this with the community.

I know it is possible to listen for multiple DI lines when performing a Change Detection (with a pxi 6511, for example), however it appears to not be a feature to know which channel was the cause of the event trigger  without building your own comparison logic around the DIO reads.

I would like to see an additional property, either under 'Timing', or under 'Channel' that would allow me to ask, for the specific channel / line in the task that caused the change-event instance rather than having to search for it manually in a 1D boolean array.

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.

Thanks

Matt

A customer of mine was trying to read 8 thermocouple readings simultaneously over the course of a week and then store the data.  She quickly found out that there are memory limitations with Signal Express.  Eventually no matter how She saved or logged their data, she would run out of memory.  My product suggestion is to write code that will determine the RAM on a customers computer as well as available hard drive space and show customers (at the start of a task) exactly how long they can acquire signals without filling up their hard drive or seriously draining their resources.  That way when they start a process, they are aware of what they're working with in terms of space at that instant rather than when an error pops up three hours or so later.  Most customers would figure out these needs in advance of any acquisition, but for the ease of the customer, this would be a welcomed additional feature.  It would also be nice to have a document that explained how this time frame was calculated.  I suggest that when a task is ran, there is a pop up that explains the maximum amount of samples that can be acquired and time that can pass.  The document I mentioned could be available via hyper-link, and the hyper-link text could read "How did we calculate this number?", which could explain the process in more depth.

I have submitted this idea for Signal Express at the product suggestion page found at www.ni.com/contact ("feedback" link in bottom left of window).  I figured this would be a good idea for DAQ in general for any extended signal acquisition.

Shawn Shaw

Applications Engineering Department

National Instruments

If NI already has the product, please let me know. I need it in my project. If otherwise, I would like to suggest NI to develope one based its NI-9234 and WLS-9163. It can be readily developed by just remove three channels of the NI-9234 and make a smaller version of WLS-9163 for one channel. I would like the product be one unit to achieve a small size. The one channel wireless data aquisition module will have two imporatnt advantages: 1) much smaller size, therefore can be fit into difficult locations; 2) much lower power consumption, therefore can make much longer recording. These two advantages are essential for wireless measurement, thus the product will have good market potential.

What I would like is a contious sampling DAQ task which resets the count to zero evey time the DAQmx Read.vi is called.  This way you see which direction and by how much the encoder has moved betwen samples.  If it also provided the delta time that would be ideal. 

There are ways to do things like this currently but I have run up aginst two applications which would benifit forom something like this and I cannot be the only one. 

While in the development environment it is easy to get a reference to a Fieldpoint IO channel - just drag and drop it from the target in the project file. Things are much more cumbersome if you need to create such a refnum dynamically. (If you are making software that should be possible to just copy onto different controllers (without involving LabVIEW) and then configure to match the available/required IO, static refnums are not usable. )

To dynamically get access to an IO point in a built general purpose application you currently have to save and download an iak file to the controller from Measurement and Automation Studio and then open that iak file in your code (Using FP Open) to get the server reference you need as an input to the FP CreateTag function. The need for FP Open and the iak file to create a server refnum is the main problem.

If FP Create Tag could do its job without any iak-file (e.g. just with the IP of the controller as an additional input)...OR even better - if there was a Create Fieldpoint IO Refnum VI avilable (no such today!?) that took the controller IP (use local if not wired), device name (or ID number) and channel name (or ID number)..then things would be much more flexible and intuitive.

There is one function that allows you to address channels just by the use of slot and channel numbers - and that is the Input Range function (which should not be called the input range either by the way as it could be an output...), so another good solution would be to offer that same functionality for the IO read and write functions.

This question goes for usb-6008 and 9

From the User Guide and Specs:

"The progammable-gain amplifier provides input gains of 1, 2, 4, 5, 8,
10, 16, or 20 when configured for differential measurements and gain
of 1 when configured for single-ended measurements"

Why can't I use the PGA in single-ended modes?

best

Niels

NI USB-4432 has 5 input，But only There are 4 channels with software-selectable IEPE signal conditioning (0 or 2.1 mA).

Make NI USB-4433  5 channels with software-selectable IEPE signal conditioning (0 or 2.1 mA).