Data Acquisition Idea Exchange

Community Browser
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!
Top Kudoed Authors
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

A DAQmx channel control allows available channels to be filtered for IO type (Analogue Input, Analogue Output etc) using the "IO Name Filtering..." function

 

channel.jpg

 

A DAQmx task control on the other hand doesn't.

task.jpg

 

I'd find the option to filter listed tasks on IO type pretty usefull.

 

cheers.

 

I bought a NI USB-6251 BNC but the support explained me that it would have no Linux support out of the box. I will have to find out how to use it on Linux systems myself now (perhaps with help of the forum). It would be a nice feature, if it would ship with Linux support.

When using a buffered counter output task, the initial delay value is not used at all.  Instead, the user specifies an array of high and low times and the first low time is used as the initial delay.

 

If the output pulse train is repeated multiple times (or continuously), the first low time represents both the time from the trigger until the first pulse as well as the time between the last pulse and the first pulse.

 

It would be desirable to decouple these parameters by allowing for the option to use Initial Delay on buffered counter output tasks (e.g. with a channel property).  Here are a couple use cases off the top of my head where Initial Delay would be very helpful (if not required):

 

1.  This is the case I ran into (posted here):  if you want to repeat a pulse train continuously every N seconds, you have to either have that N second delay at the start of the task or use another counter as a trigger source.  Depending on high and low times you might be able to get away with writing new values to the counter on-the-fly but this isn't a universal solution.

 

2.  If you wanted to synchronize multiple continuous buffered counter output tasks (with each one sharing a fixed desired period) to a common trigger source but with a different initial delay, you would be unable to do so since the requirement of having different initial delay would affect the period of your actual signal.  You would have to compensate by tweaking the other high/low times in your waveform (giving you something that you don't really want).

Hello everybody!

 

Currently the AI.PhysicalChans property returns the number of physical channels for measurement (e.g. 16). However, to calculate the maximum sampling rate for the device programmatically (e.g. 9213), we need the total number of channels including the internal ones such as cold-junction and autozero (for 9213 it's 18).

 

Therefore I would like to suggest to include a property node with the number of the internal channels or the total number of physical channels or something similar.

 

Use case: programmatically calculate the maximum sampling rate in a program that should work for multiple types of devices without being aware of their type.

 

Thanks for consideration and have a great day!

 

[actually a customer's idea]

Hello,

 

DaqMx Vis only works when the NI Device Loader service is running.

 

If this windows service is not running, DaqMx functions generates error like "Device not found..., undefined board, undefined hardware ...."

 

For some week, i get such an error and it take me a long time to point the real cause !

A windows or software update had changed the service startup sequence ... and the Ni device loader service was no more starting.

The solution to this problem was to configure the NI Device Loader service in order to force restart on start failure. 

 

It should be nice if daqMX functions could generate the "right error".

 

An error like : "Ni services are not running please check their current state ... The DaqMx devices could not be accessed when Ni Device Loader service is not running".

 

This problem also generates problem in MAX ! (The device treeview takes a long time to expand ... and the device autotest fail)

 

 

Thanks for kudossing this idea which could help understanding windows services problems.

NI should make sure that the measurement uncertainty specifications for its DAQ hardware are aligned with uncertainty analyses that are performed according the ISO "Guide to the expression of Uncertainty in Measurement" (GUM). See http://www.bipm.org/en/publications/guides/gum.html. Furthermore, the language used could conform to the ISO "International Vocabulary of Metrology" (VIM). See http://www.bipm.org/en/publications/guides/vim.html.

Support for .net 4.5

With NI 9234 board you can use 4 IEPE sensors but you don' have IEPE open/short detection capability.

NI 9232 board has IEPE open/short detection capability but has only 3 channels.

 

I think that a board with 4 channels (as 9234) and an IEPE open/short detection capability would be great!

Is there any technical reason why this cannot be added to DAQmx?  M series boards still have features that cannot be found on X or S series such as analog current input.

Ideally, it would be best to be able to have multidevice tasks for both M and X at the same time.

We need a way to query an output task to determine its most recently output value.  Or alternately, a general ability to read back data from an output task's buffer.

 

This one's been discussed lots of times over the years in the forums but I didn't see a related Idea Exchange entry.  Most of the discussion I've seen has related to AO but I see no reason not to support this feature for DO as well.

 

There are many apps where normal behavior is to generate an AO waveform for a long period of time.  Some apps can be interrupted unexpectedly by users or process limit monitoring or safety range checking, etc.  When this happens, the output task will be in a more-or-less random phase of its waveform.  The problem is: how do we *gently* guide that waveform back to a safe default value like 0.0 V?  A pure step function is often not desirable.  We'd like to know where the waveform left off so we can generate a rampdown to 0.  In some apps, the waveform shape isn't directly defined or known by the data acq code.  So how can we ramp down to 0 if we don't know where to start from?  This is just one example of the many cases where it'd be very valuable to be able to determine the most recently updated output value.

 

Approach 1:

  Create a DAQmx property that will report back the current output value(s).  I don't know if/how this fits the architecture of the driver and various hw boards.  If it can be done, I'd ideally want to take an instantaneous snapshot of whatever value(s) is currently held in the DAC.  It would be good to be able to polymorph this function to respond to either an active task or a channel list.

 

Approach 2 (active buffered tasks only):

   We can currently query the property TotalSampPerChanGenerated as long as the task is still active.  But we can't query the task to read back the values stored in the buffer in order to figure out where that last sample put us.  It could be handy to be able to query/read the *output* buffer in a way analogous to what we can specify for input buffers.  I could picture asking to DAQmx Read 1 sample from the output buffer after setting RelativeTo = MostRecentSample , Offset = 0 or -1 (haven't thought through which is the more appropriate choice).  In general, why *not* offer the ability to read back data from our task's output buffers?

 

-Kevin P

We do atomic physics experiments with everything run off of hardware time. Low noise electronics are fairly crucial to getting things to work properly.

 

It would be fantastic to have some very low noise analog output modules with >16-bit resolution. We currently use the cRIO platform and the NI 9263 analog output modules. However, these have poor noise performance. The best module I have seen from NI is the PXI-6733, but it would be great to have something with an output voltage noise density on the order of ~5-10 nV/sqrt{Hz} in the range of ~100 Hz to a few MHz. The Analog Devices AD5791 20-bit DAC seems like a good candidate for this.

 

Any thoughts?

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.

Hi All,

 

In my post on the LabVIEW board I asked if it was possible to have control over the DIO of a simualted DAQ device. Unfortunately it seems this feature is not available. Once MAX is closed the DIOs run through their own sequences.

 

If there was a non-blocking way to control a simulated DAQ device through MAX it would permit much simpler prototyping of systems before they need to be deployed to hardware. For example if you want to see how a program responds to a value change simply enter it in the non-blocking MAX UI. Or as in my original case can make an executable useable even if you don't have all the necessary hardware.

 

I think this feature should only be available for simulated devices.

 

Thanks for reading - and hopefully voting,

Dave

 

Why new NI MAX does not sort global virtual channels by name? It used to be very handy to have that option, however, after 2014, they decided to remove this very useful function away without any reason (at least I can not think of any reason). I am currently using NI MAX 15.0 and I could not find anything in the menu about how to sort my global virtual channels by name. They could have implemented something in the menu easily to sort channels by name or something else instead of removing that useful function.

I would like to see a C series module just like the NI 9474 only with push-pull outputs.

 

MOSFET_Push_Pull_Amp.png

Currently when streaming analog or digital samples to DAQ board, output stays at the level of last sample received when buffer underflow occurs. This behavior can be observed on USB X Series Multifunction DAQ boards. I have USB-6363 model. The exact mode is hardware-timed, buffered, continuous, and non-regenerating. The buffer underflow error code is -200290 “The generation has stopped to prevent the regeneration of old samples. Your application was unable to write samples to the background buffer fast enough to prevent old samples from being regenerated.”

 

I would like to have an option to configure DAQ hardware to immediately set voltage on analog and digital outputs to a predefined state if the buffer underrun occurs. Also, I would like to have an option to immediately set one of PFI pins on buffer underrun.  

 

I believe this could be accomplished by modifying X series firmware and providing configuration of this feature in the DAQmx API. If no more samples are available in the buffer the DAQ board should immediately write predefined digital states / analog levels to outputs and indicate buffer underrun state on PFI line. Then it should report error to PC.

 

Doing this in firmware has certain advantages:

  1. It can be done quickly (possibly within the time of the next missing sample – at 2Ms/s that’s 0.5us).
  2. Handles all situations (software lockups, excessive CPU loading by other processes, loss of communication do to bus traffic, interface disconnection…)
  3. It does not require any additional hardware (to turn off outputs externally).
  4. Buffer underrun indication on PFI line could provide additional safety measure (it could be used for example to immediately disable external power amplifier connected to DAQ AO). 

Doing this using other methods is just too slow, does not handle all situations, or requires additional external circuitry.

 

Setting outputs from software, once error occurs, is slow (~25ms / time of 50000 samples at 2MS/s) and does not handle physical disconnection of the interface. Analog output does eventually go to 0 V on USB-6363 when USB cable is disconnected, but it takes about half a second.  

 

Using watchdog timer would also be too slow. The timer can be set to quite a short time, but form the software, I would not be able to reset it faster than every 10ms. It also would require switching off analog channels externally with additional circuitry, because watchdog timer is not available for analog channels.

 

The only viable solution right now is to route task sample clock to PFI and detect when it stops toggling. It actually does stop after last sample is programmed. Once that occurs, outputs can be switched off externally. This requires a whole lot of external circuitry and major development time. If you need reaction time to be within time of one or two samples, pulse detector needs to be customized for every possible sampling rate you might what to use. To make this work right for analog output, it would take RISC microcontroller and analog electronic switches. If you wanted to use external trigger to start the waveform, microcontroller would have to turn on the analog switch, look for beginning of waveform sample clock, record initial clock interval as reference, and finally turn off the switch if no pulse is received within reference time.

 

I’m actually quite impressed how well USB-6363 handles streaming to outputs. This allows me to output waveforms with complexity that regular arbitrary generators with fixed memory and sequencing simply cannot handle. The buffer underflow even at the highest sampling rate is quite rare. However, to make my system robust and safe, I need fast, simple, and reliable method of quickly shutting down the outputs that only hardware/firmware solution can provide.

 

Thanks,

Sebastian

Hi all,

 

Any series card should have a feature listing different  parameters like voltage, temperature etc it supports(May be a property node should be used). so that user can configure the required parameter among the supported.

Ex: SCXI -1520 module can be configured as Strain, Pressure or voltage but this information will be known only by seeing its manual or when a task is created in MAX. But in LabVIEW               Software i cant get this information directly. Because it allows me to configure 1520 as temperature also and we will come to known that 1520 module doesn't support for temperature       parameters only when once tried to acquire.

 

So what you people think about you.Share your ideas on this please. 

 

Regards,

geeta 

Hi

 

I'd like to see PCI express versions of existing PCI Analogue Output cards eg PCI6713 and PCI6733.

 

I'm finding it quite difficult (and quite a bit more expensive) to source desktop PCs featuring PCI slots.

 

 

I continually come to your site looking for the DAQmx base API manual and have yet to find it.  I eventually have to dig out an old CD to find my copy.

 

How 'bout posting these online so that we can help ourselves out of jams?

 

Thanks,

Jeff

Currently, there is no way to format a .txt file to log data with a time stamp that includes the current time that the data is being acquired. When creating a "Save to ASCII/LVM" event, the "Time Axis Preference" setting under the File Settings tab has two options: Absolute Time or Relative Time. Relative time works as expected, logging the time starting from 0 seconds until the data acquisition is complete. However, the Absolule Time setting logs the time stamp as time in seconds from some arbitrary point in time, usually the Windows system time in seconds. 

 

This timestamp is essentially useless without a conversion to the actual time. It would be great if the Absolute Time logged the current time in hours:minutes:seconds instead.