From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Data Acquisition Idea Exchange

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

In MAX, you can open up a test panel for a DAQmx device.

 

I woudl like to format the numbers on the axis of the graphs. I have a calibration routine that requires that the signal get as close to 5 V as possible. When you get to less than 10mV, you the numbers on the vertical axis go from 5.01 to 5. So all you see on the graph is a bunch of 5's. It would be nice to be able to see the values in as much resolution as the channel will handle. Even at the maximum range, it can still do 2mV per bit. It would be nice to see 5.004 instead of 5.

 

 

 

We normally have a DAQ system consisting of several elements:

-Sensor

-Custom filtering/attenuation

-Signal conditioning

-NI-DAQ device

 

When we use scales in DAQmx we have to create a scale for every 'route' we use (sometimes we have to use a 4 kAmps sensor for a 100 amps signal).

If we could define a scale in a task consisting of multiple scales, we could directly pick the sensor and signal conditioning we use for each signal. A change in one of these elements could easily be adjusted.

 

Ton

Idea:

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.

 

Use cases:

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.

 

Alternatives:

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.

 

Best alternative:

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.

 

Forum post: http://forums.ni.com/t5/forums/v3_1/forumtopicpage/board-id/250/page/1/thread-id/91133

NI support Reference# 2407745

A DAQmx Device property "Watchdog Timer Supported" would provide indication of that capability for the selected hardware device.  Few devices (X series being one) have a watchdog timer.  Since they are often used as a means of safeguarding, it is important to know that the selected device supports that function.  Currently, one has to attempt to Create a Watchdog Timer Task and then trap error -200662 which says the device does not support that feature.

 

When a piece of hardware is simulated with MAX, I would like to be able to insert a transfer function or a signal simulating VI to allow me to get a more realistic test of a system. The current default of generating a sine wave for simulated acquisition only lets me test part of the code. If a transfer function, lookup table, or custom vi were able to be substituted for the sine wave generation, then I would be able to test many other facets of a system.

Screenshot from the help for number of samples per channel for a Read task :

 


Extract of help.jpg

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


 

Please add an option for a continuous sample task to read all currently available samples (-1) but with a wait for a minimum number of samples (#min). Behavior of this configuration :

  • #available samples >= #min : read all available samples
  • #available samples < #min : wait until #min samples are available or until timeout

 

This would be very useful in several cases. For example :

  • No extra coding to handle or avoid the error that appears if 0 sample is available.
  • Avoid the use of a wait function in the loop to ensure a minimum number of samples are available.

The size of for example the NI-Rio driver package is 4GB in the most recent version which is comparable to size of common operating systems. This is too much in my opinion if someone needs only a specific driver for a specific NI hardware. Therfore i suggest granularity reduction of driver packages to a more mouth friendly morsel (for ex. 200MB max).

 

Occasionally, I need to create global virtual channels that are used to acquire AC voltage signals. Currently, I just acquire the instantaneous values and take the RMS average in LabVIEW. However, this does not let you calibrate the global virtual channel in MAX (because the acquisition is the instantaneous DC voltage).

 

It would be nice to have the custom scales allow user customizable LabVIEW programming plug-ins, such as RMS average point by point, so that I can calibrate an AC voltage channel in MAX.

I'm working with some B class devices and can't work on the project at home because I don't have the hardware and can't simulate it. Can you add the NI USB-6008 and 9 (whole class would be nice) to the MAX 'create simulated device'  list?

 

thanks

 

frank9

 

Have Max maintain a database of your transducers calibration due dates that can be monitored in LabView. Currently I maintain a lot of transducers that are used throughout my programs. I have them selectable through the Custom scale input. Unfortunately I cannot conduct a quick check to make sure that my transducer is in or out of calibration through the program. I would be nice to have that capability.

Right now lossy and lossless compression can be achieved as presented here: Data Compaction for High-Speed Streaming to Disk where AI.RawDataCompressionType and AI.LossyLSBRemoval.CompressedSampleSize are used (see figure below).

lossy and lossless compression

In this case raw data are stored and additional header info has to be added. The idea is to implement and optimize it in DAQmx (DAQmx Configure Logging VI). This will allow high-speed streaming and to save disk space for higher sampling rates or long-term measurements.

 

Afterward implementation in the TDMS API could help to read directly compressed raw data without additional operations in LV. This will allow to work on TDMS files in Excel or Matlab using nilibdds.dll.

 

The issue is discussed a little here: Why the TDMS file is larger than it should be.

 

What do you think about it?

 

Lukasz Kocewiak

Attempting to add a channel (Ch8) to an existing task which already uses that channel as a result of having already assigned its paired differential channel (Ch0) results in that channel correctly not being added to the task but also does not generate a warning or error.  Thus when attempting to configure a task with 2 channels as Ch0 differential and Ch8 RSE, the resulting task only contains 1 channel.  This may be not be apparent because the channels 0 and 8 appear as different from each other.  Having a warning could give notification of this fact. 

 

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019KxoSAE&l=en-US

 

While using NI USB-6008/6009, I am encountering a strange error which I have failed to find the source of it. As you can see, there are 2 types of outputs. When I comment out one of the outputs, other one works fine. However, when I use them both, it gives me an error as shown below in the picture. What could be the problem?
Error : Invalid data format for digital channel
However, error direct to analog output.Error.JPG

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

This Topic is base on other topic in PXI Forum (Link).

The main problem is the Range passing the Min/Max limitation.

 

I would like to simulate a channels in "Nominal" Case.

1. The range should be based on the Min/Max limitation.

2. I could select input style (Sin Wave, Triple Wave, Random in sub range, DC with error range, based on external data,...)

3. Near to Real timing simulation include cases of sync between different channel rates.

 

Currently,

1. The range is limited to the Min/Max Values. Excluded the cases show below.

2. Only Sin Wave. Excluded an Odd Case show below.

3. I tried case of sync between 2 channel with different rates. the simulation is not close to the real DAQ case. 

 

 

Here are the cases from the PXI Forum (Link😞

1st problematic case

1. Define a Simulated Device - PXIe-4353 in MAX.

2. Open "Test Panel"

3. Use the default parameters of the test:

  a. Measurement type - thermocouple

  b. Max Input Limit - 100

  c. Min Input Limit - 0

  d. Units - Deg C

  e. Thermocouple type - J

  f. CJC Source - Built In

4. Click Start.

 

The result is Sin Wave.

The sample values range ~[-1030,-74.7], out of the Max/Min Limits.

=> BAD sample results, values lower than -273 C ?!?!?!?!

 

2nd Problematic Case

If I change the Max/Min Limits to other valid range like [-200,1200]

The sample values range is BAD

And, the result is some kind of Non-Sin Wave

 

3rd Non-temperature Case

If I change the Measurement type to Voltage.

The sample values range is based on the Max/Min Limits.

=> So it is OK

 

Tnx,

Raz

 

 

Today, we can create a DAQmx custom scale in MAX or Labview via the "DAQmx Create Scale" VI. This VI changes a pre-scaled value, e.g. 5Volts, to a scaled value in a physical unit, e.g. 100Newtons. This scale can be Linear, Map Ranges, Polynomial or Table.

For all of these four options, only a mono-channel sensor can be used.

 

However, multi-channel sensors are not so rare and there is actually no way to scale a 6-components load-cell, for instance. For this kind of transducer, F = M*U where F is a 6-components vector including the 3 forces in Newtons and the 3 moments in Newtons*meters, U is a 6-components pre-scaled vector including the 6 input channels in Volts and M is a 6*6 matrix. M is never diagonal, because the forces affect the moments.

 

Finally, what I'd like to have is an extension of the "DAQmx Create Scale" VI which could enable a multi-channel pre-scaled input to be scaled in physical units through a matrix.

 

Thanks.

Hi,

     i need to create a vi with 16 bit channel output to show a waveform graph and my point is i need to display a list and the user should select which channel they want to display in a graph.

For example, if the user wants to see a graph for the channel 1 & channel 2, whatever it is, up to 16 channel, is anybody got a idea? that what i was telling actually.

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.

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.

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.