NI Home > Community > NI Discussion Forums

Data Acquisition Idea Exchange

Showing results for 
Search instead for 
Do you mean 
Announcements
The NI Idea Exchange is a product feedback forum where NI R&D and users work together to submit ideas, collaborate on their development, and vote for the ones they like best. View all of the NI Idea Exchanges to post an idea or add your opinion on an existing one today!
New Idea

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.

 

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

Currently, DSA devices that use voltage excitation have no method to provide that excitation to a particular device within test panels. The only method to do this would be to create a task in Measurement and Automation Explorer which takes much more time that doing a simple test panels test. This should be a fairly simple addition to the test panels user interface. One could simply have a box to check if they require excitation, and a control to determine the voltage level to provide to the DUT. They currently have this for IEPE devices, and it makes sense that voltage excitation should be the same.

Status: Completed

It has come up a few times from customers, and I wanted to gauge interest and solicit ideas on how this should work.

 

Currently, with the built-in TDMS logging support, if you want to change to a new file in the middle of logging, you need to stop the task and start again.  For some use cases, this isn't practical (for example, http://forums.ni.com/t5/LabVIEW/Why-the-TDMS-file-is-larger-than-it-should-be/m-p/1176139#M511099).

 

The question is: How would you like to specify the "new file" behavior and what are your use cases?

 

For instance, a couple ideas to get the ball rolling:

  1. Add an interval attribute like "Change file after n samples".   We would then auto-increment the file name and change to that file when we have logged "n" samples.
  2. Make file path attribute changeable at runtime.  We have a file path attribute for logging.  The idea here would be to support changing the file path "on the fly" without stopping and starting the task.  The problem here is that it would not suit very well a use case where you want a specific file size.  Additionally, it wouldn't be as easy to use as #1; it would be more flexible though.
  3. (Any additional ideas/use cases?)

Thank you for your input!

 

Andy McRorie

NI R&D

It has come up a few times from customers, and I wanted to gauge interest and solicit ideas on how this should work.

 

Currently, with the built-in TDMS logging support, if you want to change to a new file in the middle of logging, you need to stop the task and start again.  For some use cases, this isn't practical (for example, http://forums.ni.com/t5/LabVIEW/Why-the-TDMS-file-is-larger-than-it-should-be/m-p/1176139#M511099).

 

The question is: How would you like to specify the "new file" behavior and what are your use cases?

 

What I'm currently thinking (because it seems the most flexible to different criteria and situations) is to simply allow you to set the file path property while the task is running (on DAQmx Read property node).  The only downside I can think of with this approach is that you wouldn't know exactly when we change to the new file.  We could guarantee within (for example) 1 second, but you wouldn't be able to specify the exact size.

 

Would this be a good solution for you?  Can you think of a better way to specify this behavior?

 

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

rpursley8

Access to an amplifier in the Analog Output path

Status: New
by Active Participant rpursley8 on ‎04-30-2010 08:30 AM

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.

Jeff·Þ·Bohrer

DAQmx Device events

Status: New
by Proven Zealot on ‎09-11-2009 12:34 PM
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?
falkpl

Hardware Idea/requests exchange

Status: Completed
by Trusted Enthusiast on ‎03-09-2010 07:50 AM

It would be nice to have a hardware request forum as well so NI could see the demand for producing hardware for us. 

Just A few things I could use or want:

cDaq counter modules, like a 6602 in cDaq form so I can add more counters to my compact daq module, a lower end crio 'brick', think like a 6009 morphed with a single board rio, something under 1k for simple embedded data logging prototypes.  Maybe support for PIC micros (FPGA is so empowering, more microcontroller programming native to labview would be very nice to add to our toolbox).

 

would a seperate HW forum be helpful?

Status: Completed
We have a Data Acquisition Idea Exchange now. Please create new posts for individual requests.

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

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

 

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

SULLutions

Clarifying Single-Ended Measurement Modes

Status: New
by Member SULLutions on ‎05-05-2011 07:13 AM

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.

Crocker84

Built in Tare Function for TEDS load cells.

Status: New
by Member Crocker84 on ‎03-31-2011 03:32 PM

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

 

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

 

Klaus_M

Anti Aliasing Filters for (USB-) DAQ Devices

Status: New
by Member Klaus_M on ‎12-02-2011 08:38 AM

 

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

 

 

 

falkpl

labview brick HW

Status: New
by Trusted Enthusiast on ‎10-14-2010 07:51 PM

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.

I'm working with some B class devices and can't work on the project at home because I don't have the hardware and can't simulate it. Can you add the NI USB-6008 and 9 (whole class would be nice) to the MAX 'create simulated device'  list?

 

thanks

 

frank9

 
SteveP

Watchdog Timer Supported DAQmx Device property

Status: New
by Active Participant SteveP on ‎09-14-2011 09:49 PM

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.

 

PPLLC

Transfer function for simulated hardware

Status: New
by Member PPLLC on ‎07-15-2011 11:19 AM

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.

pblase

Command line parameters for MAX

Status: New
by Active Participant pblase on ‎09-17-2012 08:38 AM

I could program a whole panel to allow the user to modify the setup parameters for a DAQmx task, but decided that it's easer to simply stop the task and launch MAX with LaunchExecutableEx and let the user play with the task settings there. Unfortunately there seems to be no way to tell MAX, e.g. through command line parameters, to open up and display a particular DAQmx task upon startup. Might I suggest some facility for doing this, possibly through simple command-line parameters or even through an ActiveX utility?

About Data Acquisition Idea Exchange

Have an idea for new DAQ hardware or DAQ software features?

  1. 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!
  2. 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.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see implemented!
Idea Statuses
Top Kudoed Authors
User Kudos Count
2
1
1