Data Acquisition Idea Exchange

Community Browser
Top Authors
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

 

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

 

 

 

There is a need for a quick low cost device to controlling/communicating with the popular low-voltage differential signaling (LVDS).  There is a need for transmit only, receive only, and transmit/receive USB devices.  The current solution is to buy the NI USB-6501 and build a daughter board with TTL-LVDS ICs on it to interface to digital equipment in the military/defense industry. Lots of time and energy is wasted on designing, building, and cabling boards as as additional interface step, where a simple USB solution could be made available.

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.

 

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:

 

MAX idea.png

 

 

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.

414-566-7938

rick.yahn@quadtechworld.com

 

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.

Filter Analog Input Measurement Type.jpg

Just what the title says!

When a DI change detection task runs, the first sample shows the DI state *after* the first detected change.  There's not a clear way to know what the DI state was just *before* the first detected change, i.e. it's *initial* state.

 

This idea has some overlap with one found here, but this one isn't restricted to usage via DAQmx Events and an Event Structure.  Forum discussions that prompted this suggestion can be seen here and here.

 

The proposal is to provide an addition to the API such that an app programmer can determine both initial state just before the first detected change and final state resulting from each detected change.  The present API provides only the latter.

 

Full state knowledge before and after each change can be used to identify the changed lines.  (Similarly, initial state and change knowledge could be used to identify post-change states.)

 

My preferred approach in the linked discussions is to expose the initial state through a queryable property node.  The original poster preferred to have a distinct task type in which initial state would be the first returned sample.  A couple good workarounds were proposed in those threads by a contributor from NI, but I continue to think direct API support would be appropriate.

 

 

-Kevin P

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!

 

Cheers,

 

Kris

Measurement and Automation Explorer MAX's Test Panel's Analog Input provides a quick method to examine a signal and vary acquisition parameters.  It would be useful to be able to zoom the time axis and have a cursor display so that for example noise level or rise time could be looked at in more detail.  The time axis limits can currently be manually overwritten as a way to zoom but that is cumbersome.  Assuming the graph being used in this test panel is built from a standard NI graph, it should have zoom and cursor capability already part of it and thus easily added.

 

Steve

 

Would it be possible to update the export wizard in MAX so that the NI-DAQmx Tasks list under Data Neighborhood is listed in alphabetical order?  In the main MAX application the list is in order, so finding tasks that are named with a common prefix is easy.  However, in the export wizard you have to scroll and hope you clicked them all.

 

Thanks,

-Brian

Certified LabVIEW Developer

Lead Engineer - LabVIEW

Advanced Development

GE Appliances

 

T 502-452-3831

F 502-452-0467

D *334-3831

E brian.schork@ge.com

Hello

 

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.

It seems the only indication in MAX that a device is simulated is that under the Devices and Interfaces section, the tiny glyph to the left of the device name is colored yellow instead of being white/transparent.  I end up not remembering what color means what.  It would be useful to add text "Simulated" next to the device name.  It would also help to distinguish simulated devices by having the color of that glyph be green (instead of its current transparent/white) when the device is installed and detected.  Have the color change to red (and keep the existing red X) if had been detected and a device number assigned but is currently not installed/detected.  Then simulated devices being yellow may imply "warning/caution" or "not real".  Perhaps also have a help-hint popup ("Detected" or "Not Detected" or "Simulated") when the mouse hovers over device names.

 

MAX Simulated Device.jpg

I rarely have to set up hardware for a new analog measurement and always have to puzzle over the difference between RSE and NRSE modes. I think of the inverting input as the reference, so "Non-Referenced Single-Ended" doesn't make sense to me. And, if I run the AISense line to my remote sensor, isn't that a Referenced Single-Ended measurement?

 

Yesterday, I noticed that at least some on-line documentation now refers to GRSE (Ground Referenced Single-Ended); adding that single letter helps a lot. What about adding another single letter and referring to the other mode as RRSE (Remote Referenced Single-Ended)? One letter could save a lot of people a lot of time.

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

 

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.

 

 

 

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.

We normally have a DAQ system consisting of several elements:

-Sensor

-Custom filtering/attenuation

-Signal conditioning

-NI-DAQ device

 

When we use scales in DAQmx we have to create a scale for every 'route' we use (sometimes we have to use a 4 kAmps sensor for a 100 amps signal).

If we could define a scale in a task consisting of multiple scales, we could directly pick the sensor and signal conditioning we use for each signal. A change in one of these elements could easily be adjusted.

 

Ton

When configuring DAQ such as the M-series etc. as I configure the PFI connections I always read the "I" as a "1" e.g. PFI4 as connection 14.

Please change it from "PFI4" to "PFI 4" or "PFI_4" or anything better!

I know this is really a DAQ problem but LabVIEW could present the terminals better in the purple DAQ box

daq.jpg

Al

I configure DAQmx channels, tasks, and scales as well as CAN messages and channels in MAX. It would be nice, if I could change the ordering of these elements after creation. It would also be nice to have an option to remove all configured channels (and tasks and scales) as well as CAN messages and channels, if I want to load the configuration of another project. Now I have to go to every section and delete the configuration by hand.

 

It would also be cool, if I could configure DAQmx variables in MAX, which I can use (write and read) in LabVIEW, too. E.g. I have a lot of tasks, which all use the same aquisition rate. If I have to change the rate, I have to change every task by hand. If I could use a variable, I just would change the variable. This would save a LOT OF WORK with huge DAQmx configurations.