Have an idea for new DAQ hardware or DAQ software features?
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!
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.
Watch as the community gives your idea kudos and adds their input.
As NI R&D considers the idea, they will change the idea status.
Give kudos to other ideas that you would like to see implemented!
The term "Incomplete Sample Detection" comes from DAQmx Help. It affects buffered time measurement tasks on X-series boards, the 661x counter/timers, and many 91xx series cDAQ chassis. It is meant to be a feature, but it can also be a real obstacle.
How the feature works ideally: Suppose you want to configure a counter task to measure buffered periods of a 1-channel encoder. You use implicit timing because the signal being measured *is* the sample clock. The 1st "sample clock" occurs on the 1st encoder edge after task start, but the time period it measures won't represent a complete encoder interval. Reporting this 1st sample could be misleading as it measures the arbitrary time from the software call to start the task until the next encoder edge.
On newer hardware with the "Incomplete Sample Detection" feature, this meaningless 1st sample is discarded by DAQmx. On older hardware, this 1st sample was returned to the app, and it was up to the app programmer to deal with it.
Problem 1: Now suppose I'm also using this same encoder signal as an external sample clock for an AI task that I want to sync with my period measurement task. Since DAQmx is going to discard the counter sample that came from the 1st edge, my first 5 samples will correspond to edges 2-6. Over on the AI task, my first 5 samples will correspond to edges 1-5.
My efforts to sync my tasks are now thwarted because their data streams start out misaligned. The problem and workaround I'm left with are at least as troublesome as the one that was "solved" by this feature.
Problem 2: Suppose I had a system where my period measurement task also had an arm-start trigger, and I depended on a cumulative sum of periods to be my master time for the entire system. In this case, the 1st sample is the time from the arm-start trigger to the 1st encoder edge, and it is *entirely* meaningful. On newer hardware, DAQmx will discard it and I'll have *no way* to know my timing relative to this trigger.
Older boards (M-series, 660x counter/timers) could handle this situation just fine. On newer boards, I'm stuck with a much bigger problem than the one that the feature was meant to solve.
So can we please have a DAQmx property that allows us to turn this "feature" OFF? I understand that it'd have to be ON by default so as not to break existing code.
When creating a vi and wiring the terminals, there should be an option that allows for an automatically generated help file. Seeing how the vi knows the names and types of inputs, it should be able to generate at least a rudimentary template for the vi Help. Next, allow the user to fill in the details plus the required/optional connections. A few simple steps and now we have a functioning help screen with each vi.
As far as I can tell, DAQmx Configure Logging only allows for raw data and scaling information to be saved as part of a DAQmx task. This is great for throughput and disk space considerations, but a problem arises when using DIAdem to analyse the TDMS files with raw + scaling info - it is incredibly slow for large files (~500MB).
Some basic tests show it's around 10 times slower to process raw + scale TDMS files (stored as I16s) vs. already scaled TDMS files (stored as SGLs). DIAdem crawls when trying to generate calculation previews, zoom in and out of graphs, and so on.
It'd be great if the DAQmx logging provided the option to log scaled data (in the user's preferred datatype), and an option to not include the scaling information in the TDMS metadata.
It would be a Godsend if the PDF documents for all NI products, include the model number or part number.
Naming the PDF's the pdf document number I'm sure makes sense internally to NI. But these documents are for us customers to use - thus having a PDF I download have some obscure number - that does not relate to the product is irrating.
I'm constantly renaming the PDF to include the device model.
I know it's common sense...so rare it should be considered a Super Power.
The niRFSA Fetch IQ VI provides me access to the absolute time at which the first sample of the IQ recording was required, as well as the IQ samples.
I have two requirements for the data types involved:
I need to access the absolute timestamp t0 using LabView's 128-bit fixed-point timestamp format, because a 64-bit floating point format simply does not have enough mantissa bits to uniquely identify each sample-clock edge accurately across the potential lifetime of the application, and because using floating-point numbers for timestamps is generally a pretty bad idea (as their absolute resolution continuously decreases as time increases, causing difficult to test problems late in product life).
I also need the IQ samples in unscaled I16 format, which I assume is the most compact, native format that my NI PXIe-5622 down-converter records internally. (I want to do the scaling myself much later, in off-line processing)
Unfortunately, at present, I can only have one or the other (high-res 128-bit timestamps or native, unscaled 16-bit integer samples), but not both simultaneously. This is because the polymorphic niRFSA Fetch IQ VI offers me either unscaled I16 IQ data along with a wfm info cluster that contains the absolute timestamp in the inappropriate DBL format, or it offers me complex WDT records with nice 128-bit timestamps, but then the IQ data comes in inappropriate scaled complex single or double format, which are not the compact native unscaled integer data format I would prefer, and which is tedious to scale back into I16 (leading to an unnecessary I16->float->I16 conversion roundtrip).
Feature request: Could you please provide in the next RFSA release a variant of the unscaled I16 niRFSA Fetch IQ VIs that outputs the absolute timestamp in a fixed-point type (either scaled in LabView's128-bit timestamp type, or unscaled as a simple sample-clock integer count)?
Application: I'm acquiring IQ data in multiple frequency bands, and I need to know exactly (with <1 sample accuracy) the relative timing between these acquisitions. As my NI PXIe-5667 acquires IQ values with 75 megasamples per second, the required timestamp resolution is at least 13.3 nanoseconds, or 0.0000000133 seconds. But as explained here, absolute timestamps in DBL have only 5 decimal digits resolution left. Therefore I can only determine the relative timing between multiple recordings with an accuracy of slightly better than a millisecond.
Generally, I would recommend that event timestamps should always be provided in APIs in fixed-point timestamp format, to guarantee uniform resolution. They can always easily be converted into floating-point representation later. Floating-point timestamps are a pretty dangerous engineering practice and should be discouraged by APIs.
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.
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.
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.
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.
I have an application where I need to continuously acquire data, but I want to start logging that data (With file spanning) concurrent with a hardware trigger. Pause logging will only align to a read block so that isn't useful in this application. As it stands now (LabView 2016), this type of functionality requires manual buffering of data, use of TDMS file VIs, and custom logic for spanning TDMS files to implement.
Attached document describes how noise measurements were perfromed with oscilloscope. 9203 emits peaks with the same frequency as acquisition rate. These spikes do affect 4-20mA measurents accuracy quite a bit. It should not be like that. Probably 20pF capacitance on each input inside the module shoud be increased to 200pF or 2nF. I am sure that NI R&D knows better how to improve 9203 :-)
I am new to posting ideas, so I posted this someplace else and now see this is the more appropriate form for my need.....
My customer wants to be able to calculate mV/Pascal at various pressures to make sure the response is linear over the range. The problem is I have not been able to find a VI or property node that will give me access to the raw voltage of the input signal when using the DAQMx Pressure Bridge VI, which I would then calculate the actual voltage measured vs Pascals measured. I find it amazing that I can't easily get this raw voltage from a property node. I do NOT want to use the Analog Measurement (as suggested by my NI service request 2399613) and then do all the translation to pressure because that would aliminate all the great stuff the Pressure Bridge Measurement VI takes into account.
PCI Express bus became more and more popular. PCIe has a new type of interrupts - MSI/MSI-X. Today VISA driver is able to work only with old style interrupts (Legacy).
Let me explain the main difference:
Legacy interrupt mask intA/B/C/D signals (these signals was in PCI bus, but not exist in PCIe bus). These signals (for PCIe actually packets with Message setA/B/C/D) are shared between all PCIe devices. So VISA driver spend a lot of time when it looks who produced this interrupt.
MSI interrupt is actually a Memory Write packet to preallocated address. In this case VISA should already know which device produced this interrupt. Also MSI interrupt can contain different interrupt vectors inside of Memory Write packet. So it would be very helpful to get access to vector value too.
Requesting MSI/MSI-X interrupts support to VISA driver.
To help with system recovery in the case of system errors/crashes, it would be useful to have a tool to configure a more frequent backup of the system without having to manually export the system configuration.
It will be great if VirtualBench have an option that we can choose 7 or 8 digits to be decoded for I2C address. I understand that we usually decode 7 digits for address and the eighth digit for read/write for I2C protocol but sometimes we need to decode 8 digits for I2C address and the eighth digit still for read/write to satisfy our work.
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.