Data Acquisition Idea Exchange

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

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

As documented in a previous post, it is currently impossible to install the nidaqmx-python library into a Docker container. Enabling this functionality would create an opportunity for software teams to build cutting edge big data pipelines for measurement instruments using container technology. This could also optimize development time by including custom DAQ code in continuous integration pipelines.

Not sure if this should be in another category, but here is the idea.

 

In DAQmx you  can register for events like Change Detection Event, Sample Complete Event, etc. These events occur in the Event structure.

 

Idea: Extend this capability to NI-Sync.

For example allow a future time event to occur in an event structure, instead of firing a TTL pulse. The steps would be:

1. Create a new NI-Sync instrument driver session;
2. Read the current time of the clock;
3. Define when the event will be generated by introducing a delay to the current 1588 time;
4. Program when the event will occur at the specified time;
5. Register for Event
6. Event Occurs - do something.
7. Clean Up

See below for diagram.

mcduff

FutTimeEvent2.jpg

I can't say I've investigated this at all, maybe it's already moving this way; all hardware should have it's own available parameters stored on-board, available to be read back by software, for example on startup. Things like available, valid, ranges in volts, current, frequency, channels etc...

 

It would always be a good idea to read those parameters from hardware by software, instead of relying on model number, manuals, drivers. Then, software could easily adapt to different models of the same main type. Plug in a new hardware and it would announce what it's main capabilities are.

 

My2c

Counter tasks can only take 1 channel, due to the nature of timed signals, obviously. When setting up a system with 16 DUTs with counter outputs, this requires 16 tasks. Every single one has to be painstakingly created and configured. (As an aside: Defining a tabulator sequence still seems a mystery to NI's programmers, even though LabVIEW supports this)

Wouldn't it be nice to have a Ctrl+c,Ctrl+v sequence for tasks and then only modify physical channel? IMHO: yes.

 

KR

nimic

I miss the possibility to select Global Virtual Channels defined in MAX into my Flexlogger project.

It is a lot faster to setup a measurement project for systems that don't change the connected sensors so often. 

Please add support for this.

Hi,

I am aware of the previous idea here on a filter for the USB DAQ devices, this time I propose a different solution.

Some cDAQ moduls include an anti-aliasing filter, see a documentation here: https://www.ni.com/en/support/documentation/supplemental/18/c-series-modules-with-anti-aliasing-filters.html

In many cases our cDAQ and cRIO system could be the solution to higher frequency (100 kS/s - 1 MS/s) voltage signal acquisition if the signal could be (from LabVIEW) programmatically conditioned prior acquisition. Two main processes are required most: amplification/attenuation and filtering.

I think amplification/attenuation is a trivial processing step, I just mention here a flat frequency and phase transfer requirement in the working range, allowing a bypassing of this stage.

Filtering is a little more challenging. My proposal is a "tunable" anti-aliasing filter, fo the sake of simplicity with one programmable cut-off frequency and fixed roll-off charasteristics. Similarly high pass and band pass filters could be implemented but these are just nice-to-have features. Please note that all filters should be in hardware, e.g. some ASIC before any ADC.

Thanks for your attention

Cheers

Istvan Pinter | Sales Development Engineer, EMEIA

The DAQmx API is extremely useful; one especially useful part of the API is the automatic logging feature. This part of the API is efficient, easy to set-up, and largely bug free, well-done NI.

 

One problem with the automatic logging feature is the value of the t0. This value is determined by the system clock, which is the clock onboard the controller. A lot of PXI systems have the ability to use GPS modules or other timing modules. It would be good to use this clock instead.

 

In NI-Sync we can create an event at a specific time and use this to trigger the DAQmx data acquisition. It would be nice to use this "event time" instead of the system clock. There is a property in the DAQmx Timing Property Node, under Advanced, called First Sample Timestamp:Value Property. However, this property is read only, please change it to writable also. In this case we can then write an exact GPS time start to the data acquisition.

 

Below is one simple use case of the property node.

 

mcduff

snip.png

 

 

 

Some users have expressed that they would be interested in getting a 4 port version of the USB-8502/2 CAN interface device with a metal housing, instead of plastic. 

AutoStart Property.PNG

Currently AutoStart is a feature of XNET that is not intuitively obvious.  One of my co-workers was trying to test out the idea of having several queued sessions start with slight delays between them (using the Start Time Offset CAN Frame property).  The code wasn't working properly due to preloading the array of frames to transmit using XNET Write (which caused some frames to transmit early).  Note that a NI Applications Engineer on a support request was not able to figure out that AutoStart was the issue before the co-worker noticed the AutoStart property a few hours later.

Note that no documentation on XNET Write mentions the AutoStart Feature.  The XNET Start VI context help doesn't mention it, but the documentation does indirectly mention being optional and points you to the AutoStart property's help for additional details.

I would recommend an optional input to XNET Write (defaulting to true) to activate AutoStart.  This would match the DAQmx API's Write VI.  It also would be a good idea to note that input sessions always start automatically somewhere in the XNET Read documentation.

When doing PWM with DAQmx, error -200684 is thrown if a 0% duty cycle is attempted.  For situations where a true 0% is needed, this is problematic. There are a few workarounds available, but some are less than ideal.  

 

The suggestion here is to pause the output if a 0% duty cycle is attempted.

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

 

 

In NI MAX, mV/(m/s^2) should be added to the available choice in the dropdown menu for accelerometer sensitivity units.

 

(Currently avaliable choice is only mV/g and V/g)

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?

When a DI change detection task runs, the first sample shows the DI state *after* the first detected change.  There's not a clear way to know what the DI state was just *before* the first detected change, i.e. it's *initial* state.

 

This idea has some overlap with one found here, but this one isn't restricted to usage via DAQmx Events and an Event Structure.  Forum discussions that prompted this suggestion can be seen here and here.

 

The proposal is to provide an addition to the API such that an app programmer can determine both initial state just before the first detected change and final state resulting from each detected change.  The present API provides only the latter.

 

Full state knowledge before and after each change can be used to identify the changed lines.  (Similarly, initial state and change knowledge could be used to identify post-change states.)

 

My preferred approach in the linked discussions is to expose the initial state through a queryable property node.  The original poster preferred to have a distinct task type in which initial state would be the first returned sample.  A couple good workarounds were proposed in those threads by a contributor from NI, but I continue to think direct API support would be appropriate.

 

 

-Kevin P

Often I need to create a simulated version of a real device in order to debug something. It would be nice if I could right-click on a real device in MAX and select "Create simulated version of this device", and it would create a simulated version of the device I'm running. This isn't so bad with standalone devices but it could make simulating modular devices easier and reduce the likelihood of a mis-click making an incorrect simulated device.

RSI support of the NI 9361 counter module would allow for use in scan-mode within 9144/5 EtherCAT chassis. I have several use cases for this that mostly would benefit from distributed acquisition and end-user-configurable I/O.

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.

Reasoning: Those of us who work with multiple systems need to import/export configurations often, to switch from system A to B to C and so on, since names are often interfering between projects.

Idea: Provide selectable profiles in MAX - this way you could choose which of systems configurations you would like to work with without exporting/importing the systems all the time.

Make the hardware capable of having more than one task tied to the Analog outputs . Each analog output should be capable of having the hardware timing for every analog output, so each output can generate its own separate hardware timed waveform.