Data Acquisition Idea Exchange

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

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?

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.

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.

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