Data Acquisition Idea Exchange

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

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 can't say I've investigated this at all, maybe it's already moving this way; all hardware should have it's own available parameters stored on-board, available to be read back by software, for example on startup. Things like available, valid, ranges in volts, current, frequency, channels etc...

 

It would always be a good idea to read those parameters from hardware by software, instead of relying on model number, manuals, drivers. Then, software could easily adapt to different models of the same main type. Plug in a new hardware and it would announce what it's main capabilities are.

 

My2c

The 6602 can take an external timebase up to 80 MHz (according to the spec, it's actually a bit higher than this in reality).

 

The newer counter products do not have this capability (e.g. the 6612 has the same 25 MHz bandwidth limit as most of the multifunction products).

 

 

So whenever an application comes up (e.g.) where the user wants to count a fast external signal, the only reasonable option from NI is the 6602.  This is fine for now, but in the future it would be nice to have some higher bandwidth counter options (unless you plan on selling the 6602 forever... hopefully it doesn't get too hard to come across computers with spare PCI slots though).

Hi,

I am aware of the previous idea here on a filter for the USB DAQ devices, this time I propose a different solution.

Some cDAQ moduls include an anti-aliasing filter, see a documentation here: https://www.ni.com/en/support/documentation/supplemental/18/c-series-modules-with-anti-aliasing-filters.html

In many cases our cDAQ and cRIO system could be the solution to higher frequency (100 kS/s - 1 MS/s) voltage signal acquisition if the signal could be (from LabVIEW) programmatically conditioned prior acquisition. Two main processes are required most: amplification/attenuation and filtering.

I think amplification/attenuation is a trivial processing step, I just mention here a flat frequency and phase transfer requirement in the working range, allowing a bypassing of this stage.

Filtering is a little more challenging. My proposal is a "tunable" anti-aliasing filter, fo the sake of simplicity with one programmable cut-off frequency and fixed roll-off charasteristics. Similarly high pass and band pass filters could be implemented but these are just nice-to-have features. Please note that all filters should be in hardware, e.g. some ASIC before any ADC.

Thanks for your attention

Cheers

Istvan Pinter | Sales Development Engineer, EMEIA

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.

Despite having dedicated RTD cards on other platforms, this doesn't exist on PXI.  The existing bridge input cards have significantly higher sample rates than needed for typical temperature measurements, and it would be nice to have a more economical drop-in option for RTDs that supported more channels.

Some users have expressed that they would be interested in getting a 4 port version of the USB-8502/2 CAN interface device with a metal housing, instead of plastic. 

I use a PXIe-6363 which a wonderful device.   But it lacks level shifting at the digital I/O.

 

I would recommend that most DAQ multi-io devices support programmable and externally driven level-shifting for digital IOs.   Range for DAC driven level-shift (0.8 - 3.6, 5V),  and support for external input.   It would also be nice if multiple ports are present that some of them allow independent logic levels.  Default level should be 3.3V.    Port configurable pull-up, pull-down and latch-hold.

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.

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?

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.

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,

 

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)

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.

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?

It matters less to me right now because I am about to change jobs but instead of a frame grabber to connect to cameras, we could use frame grabbers that acquire both Hi-Def and standard-def video. We've found some that usually work but get a bit flaky when we are using two simultaneously. Having robust LabVIEW drivers from NI instead of writing our own would save a lot of time.

There is a variety of connection posibillities (link below), but I really miss one for high channel counts, like a SubD25.

http://sine.ni.com/nips/cds/view/p/lang/de/nid/1721 

 

This is a continuation of another forum post, from here.

 

Hooovah, the capability I need is very similar to how the "ID CRC" feature currently works, I just need a little bit more flexibility in how the ID is added to the payload bytes, prior to CRC calculation.  As you described it, the 4-byte CAN ID is concatenated to the front of the CAN payload, and by your example, it is being added in "big endian" fashion.  What I require for my application, is to add that same 4-byte CAN ID to CAN payload, but I need it added in "little endian" format, such that:

 

if CAN ID = 0x1FFF313

and CAN payload = 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x[CRC]

 

then the CRC is calculated on:

0x13 0xF3 0xFF 0x01 0x01 0x02 0x03 0x04 0x05 0x06 0x07

Would be great to support NI USB TC01 Type K in Flexlogger to log the data from the device.