Data Acquisition Idea Exchange

When using TEDS load cells it would be useful to have a built in tare function  The null offset function only offsets the electrical value by the intialy measured amount.  This essentially shifts the calibration curve horizontally only.  The tare function could also shift the calibration curve vertically, in the load direction.  Since two point calibrations don't always create a line that goes through zero, a tare function is needed to get to zero.  Please see the attached VIs.  Also, check out my thread on this subject.

 

http://forums.ni.com/t5/Signal-Conditioning/9237-Null-Offset-with-TEDS/td-p/1499954

 

I am using DAQmx Physical channel controls in user Interface to select the particular DAQ modules.I would like to display only the particular type (AI,DI,AO,DO.....) of modules which is connected in the system.For example i need to display only, DO-NI-9477 cDAQ modules in the physical channel not the other DIO models like NI 9403...IO name filtering option not useful to filter the other models which is same type.

 

That should be great if NI provides the option for filtering the modules name based on their  product type or user configurable naming (for example, if cDAQ1 device renamed as "DEV1" means user can enter filter the device based on the string "DEV").

I would like to see more USB switching options. For example, a device similar to the USB-6525, but with 16 solid state relays, not just 8. (Skip the DIO)

A DAQmx Device property "Watchdog Timer Supported" would provide indication of that capability for the selected hardware device.  Few devices (X series being one) have a watchdog timer.  Since they are often used as a means of safeguarding, it is important to know that the selected device supports that function.  Currently, one has to attempt to Create a Watchdog Timer Task and then trap error -200662 which says the device does not support that feature.

 

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?

When a piece of hardware is simulated with MAX, I would like to be able to insert a transfer function or a signal simulating VI to allow me to get a more realistic test of a system. The current default of generating a sine wave for simulated acquisition only lets me test part of the code. If a transfer function, lookup table, or custom vi were able to be substituted for the sine wave generation, then I would be able to test many other facets of a system.

It would be beneficial to have DAQmx property "Default Signal Type" for each Device. It would return what is the primary measurement type for given device such as NI 9201 would return Analog Input Voltage, 9203=Analog Input Current, 9211=Thermocouple, NI 9263=AO Voltage...

 

Original discussion here

There is currently no API available to develop applications that will use the functionality of the GPIB Analyzer. There are customers who would like to be able to monitor the GPIB bus from LabVIEW, so this would be helpful.

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.

The X Series has support for a watchdog timer that can be used to define the states for all DIO and PFI lines.  It would be useful to me if it could also set the states of analog outputs since those are also outputs often used to control systems that should have a defined condition upon a fault.

 

Steve

 

I would like to see a new line of HW on the lines of the lego NXT brick.

basically something between the sbrio and low end usb daq.

this could be a bare bones arm processor, low to mid end daq (8-32 dio (fpga to make them optional ctrs i2c/spi pwm  or timmed io, a few Ai and AO).  this line is for stand alone robotics or data logging.  lower cost and power and expandablilty than the crio but not requiring a PC (except as a client) like the crio.  This would fill in to the labview everywhere model, and programmed just as the crio with labview RT and FPGA.  The cost of the crio makes it not practical and an overkill for some applications and for the hobbiest/education robotics market, maybe something like the NXT brick but higher end would be nice to see.

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".

Screenshot from the help for number of samples per channel for a Read task :

 

---

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

---

 

Please add an option for a continuous sample task to read all currently available samples (-1) but with a wait for a minimum number of samples (#min). Behavior of this configuration :

• #available samples >= #min : read all available samples
• #available samples < #min : wait until #min samples are available or until timeout

 

This would be very useful in several cases. For example :

• No extra coding to handle or avoid the error that appears if 0 sample is available.
• Avoid the use of a wait function in the loop to ensure a minimum number of samples are available.

The NI DAQmx read is currently limited to 4 multithreaded tasks due to the fact that it is merely a wrapper for an underlying DLL call.  Significant jitter and performance degredation is experienced (#7339294) as the number of parallel reads is increaced beyond 4. As NI transitions to the PXI platform and away from SCXI and users begin acquiring data from large numbers of PXI devices, this thread limitation limits the flexibility and ultimately performance that can be had with such a versatile platform.

 

NI marketing pictures frequently show PXI chassis fully outfitted with various DAQ input cards, but this limitation limits the practical usability of running large numbers of PXI DAQ devices much more so than the bandwidth limitation of the bus. Also, this limitation is referenced nowhere in any documentation pertaining to PXI DSA, DAQ, or SC series hardware. 

 

DAQmx read should be fully thread safe.

 

Many users (such as our customers) expect from devices in the mid-price segment like the USB-62xx family a proper input signal handling adapted to the selected input sampling rate.

 

Proposal:

Include anti-aliasing filters in mid-class hardware,such as the USB-62xx family. As an immediate action, please include at least a warning remark in the user manual of the devices.

Every application with variable sampling rate needs appropriate and adaptable input signal filtering.

Many NI DAQ devices do not contain anti-aliasing filters corresponding to the sampling frequencies (e.g USB-62xx family).

Signals containing higher frequency components than nyquist frequency will be folded to lower frequencies causing wrong spectrum information.

Many applications need different sampling frequency settings but use the same external hardware. In these cases, hardware including filters have to be designed for the highest possible frequency. This situation leads to unrecoverable errors in the frequency spectrum, if input signal components do not meet the nyquist criteria.

 

Thanks

Klaus

www.rfbeam.ch

 

 

 

Currently it is hard to find out whether a property can be set for a specific channel, or only per module. An example is the Strain Gauge Excitation property, which can only be set per module. Other properties can be different per channel.

 

Idea: Add a device specific comment in for example Max, about the different properties.  For example:

 

 

 

In MAX, you can open up a test panel for a DAQmx device.

 

I woudl like to format the numbers on the axis of the graphs. I have a calibration routine that requires that the signal get as close to 5 V as possible. When you get to less than 10mV, you the numbers on the vertical axis go from 5.01 to 5. So all you see on the graph is a bunch of 5's. It would be nice to be able to see the values in as much resolution as the channel will handle. Even at the maximum range, it can still do 2mV per bit. It would be nice to see 5.004 instead of 5.

 

 

 

In the DAQmx Physical Channel Control if Analog Input is selected I would like to filter on the type of module i.e. Thermocouple, strain, Current, etc.