Data Acquisition Idea Exchange

Post an idea

I often use one DAQ device to test the basic functionality of another device and like to be able to quickly do this through test panels. Unfortunately, MAX does not allow the user to open more than a single test panel at once. The current workaround for this is to launch the test panels outside of MAX (see this KB).

It would be nice to have the same functionality when opening test panels in MAX. Specifically, I would like to be able to do the following with a Test Panel open:

1. Be able to navigate through MAX to do things like check device pinouts, calibration date, etc.

2. Be able to move and/or resize the original MAX Window (it always seems to be blocking other applications that I want to view alongside the Test Panel)

3. Open a test panel for a second (or third...) device.

It is nice that there is a workaround in place already but I think it would be nice if MAX had this behavior to begin with.

As someone who migrated entire product lines from PLCs to cFieldPoint platforms, and now is in the process of migrating further into cRIO platforms, I am finding some cRIO module selection limitations. One big gap I see in the selection is with analog in/out modules. A set of 2-in / 2-out analog modules would be very welcome, offering standardized +/- 10V or 0-20mA ranges. There are a many times in our products that we need to process just a single analog signal, which now with cRIO requires 2 slots be used, with many unused inputs and outputs (which just feels like a waste of money and space).

View All (6)

Dear NI Idea Exchange,

I had a service request recently where the customer wished to use a mass flow meter, using the HART protocol (massive industrial protocol used worldwide with over 30 million devices) to communicate updated values to a cRIO 9074 chassis using a NI 9208 module.

They did not know how they could use this protocol with our products. There was only one example online regarding use of this protocol using low level VISA functions. There is currently no real support for this protocol.

I suggested that if they wished to use this sensor they would be required to convert it to a protocol we do support, for example Modbus or to RS-232 (using a gateway/converter).

Then they could use low level VISA functions to allow the data communication.

They were fine with doing this but they felt that NI should probably support this protocol with an off-the-shelf adaptor or module. This is the main point of this idea exchange.

There is clearly a reason why we do not currently provide support for this protocol in comparison to PROFIBUS or Modbus.

I thought I would pass on this customer feedback as it seemed relevant to NI and our vision.

Regards,

Dominic Clarke

Applications Engineer

National Instruments UK

View All (4)

I have a data acquisition NI-DAQmx/C++ program where I am continuously acquiring 5 channels of data at 40KHz/channel and reading them in 0.1 second chunks. This successfully works perfectly for over 14 hrs continuous acquisition, but at 14hrs, 54 min and 47 seconds the program hangs up due to an overflow in the int32 DAQmxInternalAIbuffer_Offset value sent to the DAQmxSetReadOffset() function. In the DAQmxSetReadRelativeTo() function, I set the offset relative to the first sample using DAQmx_Val_FirstSample. (See "32-bit lmitation pof the NI-DAQmx int32 DAQmxSetReadOffset() function?")

It would be very helpful for the DAQmxSetReadOffset() offset value to be 64-bits rather than the current int32 value. This would make this function analogous to the DAQmxGetReadTotalSampPerChanAcquired() which returns a 64-bit value. I understand that the offset is maintained internally as a 64-bit value, so perhaps this would not be too difficult to do.

I hope that National Instruments fixes this limitation in their API, not just for 64-bit Windows, but also for 32-bit Windows because a lot of us are still using 32-bit compilers and our users are using Windows XP. Perhaps it could be implemented as a separate DAQmxSetReadOffset64() 64-bit function for the 32-bit Windows.

Thank you,
Bill Anderson

View All (5)

The vast majority of my working life is spent with RIO devices or midrange X series cards, but I often come across applications where an inexpensive, reliable DAQ would be handy for low level tasks - monitoring presence sensors, measuring voltages at moderate precision and slow speed, providing interlocks for material storage bins etc.

Traditionally, you'll see a lot of USB 600X units being used for applications like these. However, running on USB has a few associated problems: unreliability of the Windows bus, cable strain relief on USB connectors, mounting of USB 600X units, connection type. Don't get me wrong, you can do a lot with these units but they're not an ideal, inexpensive solution for production processes.

There's a jump between the functionality of these USB units and X (or even M or E for the vintage crowd) series cards. The only thing that's really in that range anymore is the B series PCI-6010 card, which has the fantastic benefit of using a 37W DSUB connector too, but is a little limited in terms of channel offerings and the like.

I'd like to see the B series range revived to provide products that fit between the PCIe-6320 and the USB 600X devices, providing non-USB connection and preferably with a DSUB backplane connector for cost and ease of use. This would provide a more reliable offering for simple acquisition tasks in the industrial environment at a cost-effective price point.

View All (12)

View All (2)

Multiple people have requested that there be a natural way for Labview and SignalExpress to do a rotational speed measurement using a quadrature encoder. An express VI under "Acquire Signals>>Counter Input>>Rotational Speed" that asks you basic quadrature encoder type questions and computes the rotational speed would be very useful. The information it asks would be things such as Ticks per Revolution, Decoding type (x1, x2, x4) would be useful in computing rotational speed. In addition, this can be then converted into a shipping example for DAQmx relatively easily. I have had multiple people ask this question and believe that especially within SignalExpress, this would be very useful.

View All (6)

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:

It can be done quickly (possibly within the time of the next missing sample – at 2Ms/s that’s 0.5us).
Handles all situations (software lockups, excessive CPU loading by other processes, loss of communication do to bus traffic, interface disconnection…)
It does not require any additional hardware (to turn off outputs externally).
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

It has come up a few times from customers, and I wanted to gauge interest and solicit ideas on how this should work.

Currently, with the built-in TDMS logging support, if you want to change to a new file in the middle of logging, you need to stop the task and start again. For some use cases, this isn't practical (for example, http://forums.ni.com/t5/LabVIEW/Why-the-TDMS-file-is-larger-than-it-should-be/m-p/1176139#M511099).

The question is: How would you like to specify the "new file" behavior and what are your use cases?

For instance, a couple ideas to get the ball rolling:

Add an interval attribute like "Change file after n samples". We would then auto-increment the file name and change to that file when we have logged "n" samples.
Make file path attribute changeable at runtime. We have a file path attribute for logging. The idea here would be to support changing the file path "on the fly" without stopping and starting the task. The problem here is that it would not suit very well a use case where you want a specific file size. Additionally, it wouldn't be as easy to use as #1; it would be more flexible though.
(Any additional ideas/use cases?)

Thank you for your input!

Andy McRorie

NI R&D

It has come up a few times from customers, and I wanted to gauge interest and solicit ideas on how this should work.

The question is: How would you like to specify the "new file" behavior and what are your use cases?

What I'm currently thinking (because it seems the most flexible to different criteria and situations) is to simply allow you to set the file path property while the task is running (on DAQmx Read property node). The only downside I can think of with this approach is that you wouldn't know exactly when we change to the new file. We could guarantee within (for example) 1 second, but you wouldn't be able to specify the exact size.

Would this be a good solution for you? Can you think of a better way to specify this behavior?

Many users (such as our customers) expect from devices in the mid-price segment like the USB-62xx family a proper input signal handling adapted to the selected input sampling rate.

Proposal:

Include anti-aliasing filters in mid-class hardware,such as the USB-62xx family. As an immediate action, please include at least a warning remark in the user manual of the devices.

Every application with variable sampling rate needs appropriate and adaptable input signal filtering.

Many NI DAQ devices do not contain anti-aliasing filters corresponding to the sampling frequencies (e.g USB-62xx family).

Signals containing higher frequency components than nyquist frequency will be folded to lower frequencies causing wrong spectrum information.

Many applications need different sampling frequency settings but use the same external hardware. In these cases, hardware including filters have to be designed for the highest possible frequency. This situation leads to unrecoverable errors in the frequency spectrum, if input signal components do not meet the nyquist criteria.

Thanks

Klaus

www.rfbeam.ch

View All (1)

LVDS Low-Cost USB Digital I/O Device

There is a need for a quick low cost device to controlling/communicating with the popular low-voltage differential signaling (LVDS). There is a need for transmit only, receive only, and transmit/receive USB devices. The current solution is to buy the NI USB-6501 and build a daughter board with TTL-LVDS ICs on it to interface to digital equipment in the military/defense industry. Lots of time and energy is wasted on designing, building, and cabling boards as as additional interface step, where a simple USB solution could be made available.

View All (4)

View All (7)

Expand Number of inputs on 9218 Card

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?

View All (2)

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.

View All (1)

Watchdog timer for X Series analog outputs

View All (6)

当我使用网络流将数据从CRIO传输到PC时，程序正常运行几秒钟后，它提示我断开与CRIO终端的连接。此时FPGA的采样时间为1 uSec。当我将采样时间增加到大于 1 uSec 时，程序运行良好。也就是说，当程序的采样率低于1MS/S时，程序可以正常运行，当采样率等于1MS/S时，程序就会出错。是不是因为队列和网络流写得太慢了？请帮帮我，谢谢。

QQ图片20220412152952.png

Howdy!

I am trying to use a data acquisition system using python. There are thermocouple modules and voltage modules that I would like to read from. It is set up and ran in 2013 LabVIEW and I am trying to put the test system into python for easy changing of the test and user control.

I am wondering if the NI-DAQmx python library is kept up-to-date and if this is possible. I have been doing a lot of nitty gritty reading through the documentation on this library because there are not many examples of data collection using python to talk to the NI sensors. After trial and error attempts I have gone back to the basics to try and see if I can even change settings in the configuration of thermocouple channels. All I am trying to do is to take measurements from the thermocouple and I am changing the units from Fahrenheit to Celsius in separate runs. I can't even get this to work, even looking at example of this from Stackoverflow and the documentation where it specifically says how to configure the thermocouple channel (https://nidaqmx-python.readthedocs.io/en/latest/ai_channel.html and Ctrl-F to find thermocouples).

Here is a snippet of the code I'm writing:

try:
    with ni.Task() as task:
        
        #Add the thermocouple channels to read from NI-9214's
        task.ai_channels.add_ai_thrmcpl_chan("cDAQ1Mod1/ai0:11", name_to_assign_to_channel='',
                                             min_val=0.0, max_val=100.0, units=ni.constants.TemperatureUnits.DEG_F, 
                                             thermocouple_type=ni.constants.ThermocoupleType.T)
        task.ai_channels.add_ai_thrmcpl_chan("cDAQ1Mod2/ai0:7", name_to_assign_to_channel='',
                                             min_val=0.0, max_val=100.0, units=ni.constants.TemperatureUnits.DEG_F,
                                             thermocouple_type=ni.constants.ThermocoupleType.T)
        
        #Set the thermocouple type to T
        #task.ai_thrmcpl_type = ThermocoupleType.T
        
        #Add the voltage channels to read from NI 9209
        task.ai_channels.add_ai_voltage_chan("cDAQ1Mod3/ai0:7")
        task.ai_channels.add_ai_voltage_chan("cDAQ1Mod3/ai9:12")
        task.ai_channels.add_ai_voltage_chan("cDAQ1Mod3/ai19:27")
        task.ai_channels.add_ai_voltage_chan("cDAQ1Mod3/ai29:31")
        
        #Set the rate of the Sample Clock and samples to aquire
        task.timing.cfg_samp_clk_timing(rate=Hz, sample_mode=AcquisitionType.CONTINUOUS)
        
        #Set the ADC Timing Mode to speed up the collection
        #task.ai_channels.ai_adc_timing_mode =  ADCTimingMode.HIGH_SPEED 
        task.ai_channels.ai_adc_timing_mode = ADCTimingMode.AUTOMATIC

This is a little frustrating to filter through the problems because there is not much out there that has the python use for help. If you search in the documentation search, the links of the results that you can click on are broken so that is another pitfall to this method.

Any help is greatly appreciated but I am curious if NI will keep the python library updated and running for future use.

NI-DAQmx python documentation: https://nidaqmx-python.readthedocs.io/en/latest/index.html

Stackoverflow example help: https://stackoverflow.com/questions/47479913/python-nidaqmx-to-read-k-thermocouple-value

Thermocouple example: https://www.youtube.com/watch?v=NMMRbPvkzFs

View All (4)

This is something I had to design for our company's test benches because nothing existed off-the-shelf. (What does exist off-the-shelf is beyond incredibly expensive.) It's a card chassis holding 4 cards with 8 individual (5 amp) relay channels per card. Each relay channel has eight selectable sources or sinks. In our case, we have V+ (from a programmable bench power supply), ground, 4 individual resistive dummy loads each with analog DAQ channel, digital input, and an external header connector. There are four programmable 50 watt resistive dummy loads ranging from 1 ohm to 255 ohms. There are also two analog output channels. All of the switches, power supply, and dummy loads are controlled from a PC serial port (I would use USB now, if I had a chance to re-design it.) The inputs are all fed to a PCI-6221 and a PCI-6514. Again, if I had a chance to re-design it, I would ditch the PCI cards and use an FPGA with several A/D converters and digital opto-isolators. I would also consider getting rid of the mechanical relays and try solid-state relays, although we have not had a relay failure in any of the 292 relays (per chassis) in over ten years of daily use.

Something like that, only more widely expandable would be very useful to anyone testing a wide range of devices with different signal connections and high output currents. I would design these myself to sell, if I were more ambitious.

View All (4)

DAQmx Auto Zero

View All (5)

High Voltage DAQ card

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

How can we help?

Please enter your information below and we'll be intouch soon.

This field is required

Preferred communication method

Email Phone call

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

Data Acquisition Idea Exchange

Allow Multiple Test Panels Simultaneously Through MAX

cRIO Analog In/Out Combination Modules

C Series HART (Highway Addressable Remote Transducer) Module/ HART Adapter

Increasing the 32-bit NI-DAQmx int32 DAQmxSetReadOffset() function to 64-bits

Low cost PCI-based alternative to UBS 600X series units

Post the NI-DAQmx base C Function Reference Help pages on your fora somewhere

DAQmx and Labview needs an Express VI and/or Shipping Example for doing a rotational speed measurement using a quadrature encoder.

Configurable DAQ Output Behavior on Stream Buffer Underrun

Ability to split between multiple TDMS files while logging

Anti Aliasing Filters for (USB-) DAQ Devices

LVDS Low-Cost USB Digital I/O Device

USB Multifunction DAQ X series with more than 4 AO analog output channels

Expand Number of inputs on 9218 Card

Clarifying Single-Ended Measurement Modes

Watchdog timer for X Series analog outputs

When data is transferred from CRIO to PC by network stream, LabVIEW prompts to disconnect from CRIO terminal?

Data Acquisition using NI-DAQmx and python

Hardware idea: High current switching matrix and multi-channel dummy loads

DAQmx Auto Zero

High Voltage DAQ card