Data Acquisition Idea Exchange

This is pretty trivial to achieve through LabVIEW itself, but...

Signal Express is a simple, stand alone data acquisition system that allows those with limited exposure to LabVIEW set up simple test and measurement routines. One area where this is ideal - at least, for me - is in environmental or long life testing. Instead of crafting a beautiful piece of custom software for my colleagues, I can hand them a DAQ, point them in the direction of the SignalExpress and DAQmx installers, and off they go. With a little fiddling, they can create a logger that suits their needs.

One thing I've noticed, however, is that when sampling with non-simultaneous cards such as the USB 6225, users will select 1-pt-on-demand, set to some big interval, and then come back screaming at the top of their lungs - "OHMYGOD THERE'S CROSSTALK BETWEEN CHANNELS!". With a little bit of fault-finding, it's easy to point out that it's not crosstalk, but ghosting between channels, because I would guess that 1-pt-on-demand uses interval sampling and rattles through the multiplexing as quickly as it can.

My idea: give users the option to either select round-robin mode with a sensible delay, or complete control over the interchannel delay.

I realise that the standard line is usually "use LabVIEW" - I do - but I'd rather spend my time working on the important stuff and empowering those with less experience and/or exposure to make accurate measurements.

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.

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. 

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.