Data Acquisition Idea Exchange

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

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

In NI MAX, mV/(m/s^2) should be added to the available choice in the dropdown menu for accelerometer sensitivity units.

 

(Currently avaliable choice is only mV/g and V/g)

Currently there are only two options available if you want a C-series card that has ±10V analog inputs with internal excitation voltage. Both of the available options have serious limitations which makes them impractical in dynamic testing environments. 

 

9218: With two input channels, it is impractical for large channel count testing. As an example at our test facility, we may run 60 analog channels which would require 30 of these cards. That would require 4 cRIO chassis' 

9219: With a max sample rate of 100 s/s, it cannot be used in a dynamic environment to accurately record data. 

 

 

 

There are two options that would be very beneficial to dynamic testing:

1) Add more input channels to the 9218 card so that high channel count tests don't need 3+ cRIO's. 

2) Make a new card similar to the 9218 with less capability but more input channels (No bridge, no IEPE, no ±20mA). 

For example:

± 5V, ±10V, ±60V Input Range

± 1V, ± 5V, ± 10V Internal Excitation

Minimum of 4 analog input channels.

Sample Rate 5 Ks/s

 

Does anyone else have a need for a card like this?

It gets a bit annoying that PXI1Slot2 is listed after PXI1Slot14 when doing an ascii sort. I (ok, admittedly, my coworker) proposes having naming conventions that will allow for a better ascii sort. For instance, PXI1Slot002 PXI1Slot014. 

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

To change a signal name within the Digital Waveform Editor, you double-click on it and in the box that pops up, you enter a new name.  But that same name-entry box does not allow cutting and pasting of text for more mass-production of similarly-named signals. It should (allow cut and paste).

Hi Idea Exchange team,

 

VirtualBench App looks great since last update, by the way it could be great to add features like boxed scopes have, like :

  • Channel scale customization : actually, we can only use the "10x", could be nice to be able to use also a custom scaling (equation and unit)
  • Native phase shift measurement : actually we can use cursors to retrieve this data, but will be great if directly displayed
  • Update mode : could be also great to switch between Strip, Scope and Sweep mode like in LabVIEW waveform chart 

Any suggestion welcome !

 

Mathieu,

 

Have had this feature idea passed on to me. Person sees this popup every time they wake up their computer:

 

capi1.PNG

This person was confused at how to prevent this from showing again. They did not know you had to scroll:

 

cap2.PNG

 

Maybe make this easier to discover? 

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)

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

I have an application in which I have to digitize a pulse across a shunt resistor.  The common mode voltage can be up around 60VDC.  The digitizing cards I was able to find cannot perform a differential measurement without digitizing both sides of the resistor and then subtracting.  This method causes a lot of error due to the needed voltage ranges.  I have been able to digitize some of these pulses with the PXI-4072 DMM with great success.  However, I can control when those pulses occur and setup trigger lines as needed.  Other pulses I need to digitize will occur whenever the UUT decides to put it out.  What is really needed is a way to trigger the DMM on a measured voltage level.  Just for reference, Agilent's PXI DMMs can do this.  It seems such a shame I haven't found a way to do this with NI's DMM.  As a final thought, some pretrigger data would be needed to properly capture the pulse.  Though, pretrigger data would be nice in any hardware triggered acquisition.

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.

Hi, It would be useful if daqmx has a property node to read the device pinouts.

Idea:

We've come across a few use cases where it would be nice to pull samples from the DAQ buffer based on position in the buffer instead of sample number. This gets a little hard to describe, but a NI applications engineer referred to it as absolute addressing without regard to FIFO order.

 

In its simplest form we could use a read operation that just pulls from the beginning of the buffer as it is (probably?) in memory, maybe using a RelativeTo option of "Start of Buffer", with no offset.

 

The thought is that sometimes a properly set up buffer can contain exactly the data we need, so it'd be nice and clean to just get a snapshot of the buffer.

 

Use cases:

Our use cases involve continuously and cyclically sending AO and sampling AI in tasks that share a time base, ensuring that every n samples will be the beginning of a new cycle. A buffer of that same size n will therefore be circularly updated like a waveform chart in sweep mode.

 

In other words, the sample at the first position in the buffer will always be the beginning of the cycle, no matter how many times the sampling has updated the buffer.

 

If we could take a snapshot of the buffer at any moment, we'd have the latest readings made at every point in the cycle.

 

Alternatives:

The idea is that the buffer at all times has exactly the samples we need in the form we need them. What's lacking in existing functionality?

 

With RelativeTo First Sample, we don't know exactly what samples are there at any moment. We can query Total Samples and do math to figure out what samples the buffer contained, but while we're doing math sampling continues, leading to the chance that our calculation will be stale by the time we finish and we'll get a read error.

 

RelativeTo Most Recent Sample can return an entire cycle worth of samples, but they'll probably be out of phase. The sample beginning the cycle is likely to be somewhere in the middle of the FIFO order.

 

RelativeTo Read Position requires that we constantly read the buffer, which is a hassle if we only want to observe a cycle occasionally. It kind of means we'd be duplicating the buffer, too.

 

Best alternative:

In talking with engineers and on the forums, it sounds like the best option for us is to use RelativeTo First Sample and Total Samples to calculate the sample number at the beginning of a sample, and then make sure the buffer is many cycles long to mostly guarantee that the sample will still be there by the time we request it.

 

Forum post: http://forums.ni.com/t5/forums/v3_1/forumtopicpage/board-id/250/page/1/thread-id/91133

NI support Reference# 2407745

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.

 

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.

I'm writing a paper on different sensors and how to choose the correct sensor when trying to measure a physical phenomenon.  Customers are going to want to search for boards that provide exciation or allow for external exciation, and I don't yet see that as an option on ni.com/products when narrowing a search of our products.  Does anyone else think this is a good idea?

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

 

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

 


Extract of help.jpg

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


 

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.

Since the drivers support the basic communication for the GPIB-USB-HS+ devices, the code should be ported to support the analyzer functionality as well. Create the driver API to support analyzer and then make that available to LV.  Create cross platform LV routines for the analyzer functionality so it is available on all platforms.