Ni 9188 Chassis low sampling rate

[Duncan6286]

Hello,

I am trying to sample the temperature using a NI 9213 with a Ni 9188 network chassis or a NI-9162 USB Chassis.

When I use the USB chassis I get easily sampling rates of 20 Hz or higher when I use the 9188 I get only 0.3-0.5 Hz which is much too slow for my application.

I attached a picture of my program to acquire the temperature.

How can I speed up the 9188 device? I would be glad about any suggestions.

Best regards

[Tom_W_[DE]]

Hi Duncan-

Based on the picture you showed it seems like you are setting hardware-timed sampling at 10Hz.  Can you please clarify the 20Hz vs. 0.5Hz comparison you made?  Are you saying that setting a hardware-timed rate to those values is possible and that you see an error otherwise?  Or are you able to sample without DAQmx errors but otherwise verifying the sampling rate somehow by inspecting the data?

[Duncan6286]

If I use the 9188 the maximum sampling rate is always 0.5 Hz. When I use the USB chassis I can also get higher sampling rates. I mean with sampling rate every time I see the data change. I can't say whether the sampling rate is exactly 20Hz but its definitely faster with the USB chassis.

I have tried some things with express VIs which works fine at every sampling rate up to 20Hz. Is maybe the solution that the DAQ tasks have to be in a SubVI?

[Tom_W_[DE]]

Hi Duncan-

Without seeing more of your VI to know exactly what you're trying to accomplish, I would recommend some updates.

Is it more important for you to receive a single point at a time or to receive timely updates?  Judging by your use of two DAQmx Read operations (one with a multi-point buffered Read and another with a single-point Read), I suspect that you just want data as fast as you can get it.  You should know that, while accessing data from multiple threads is possible in DAQmx, it is strongly advised that you only have one DAQmx Read operation operating at a time per task.

I would encourage you to use the DAQmx example "Cont Acq Thermocouple Samples-Int Clk.vi".  You can find it by searching the NI Example Finder (from Help>>Find Examples in LabVIEW).  It shows how to acquire and scale thermocouple readings using a buffered input operation which means that the samples will be captured in a hardware-timed manner and transfered back to your host.  This will give much better throughput relative to the single-point operations that are not optimal for relatively high latency buses like USB and ENET/wireless. 

Once you have that buffered input data back on the host you can section out individual samples from the waveform array if you only need the single, newest point or only a subset of the larger dataset.

[Brad_K]

Hi Duncan,

> If I use the 9188 the maximum sampling rate is always 0.5 Hz. When I use the USB chassis I can also get higher sampling rates. I mean with sampling rate every time I see the data change.

I think that's the crucial clue. Check out this knowledgebase: NI 9219 Only Samples at 2 Hz Despite a Higher Sampling Rate

The KB is about the NI 9219 but the NI 9213 behaves similarly. When the NI 9213 is installed in a CompactDAQ chassis, it repeats data at high sampling rates unless you set AI.ADCTimingMode = High Speed.

The repeating samples behavior was needed for compatibility between slow and fast modules on the cDAQ-9172. However, the cDAQ-9188 has multiple AI timing engines, so the repeating samples behavior was kept around for compatibility with applications written for the cDAQ-9172.

Brad

[Duncan6286]

Thank you both for your suggestions! I needed both your answers!

I adjusted the example that you suggested for my needs and it works. Just one final question: If I run that example for a longer time, won't the buffered data take up too much of my memory? Or is Labview automatically erasing this data?

[Tom_W_[DE]]

Hi Duncan-

The LabVIEW host buffer used by DAQmx is a circularly continuous buffer.  So, it has a configurable size (via the DAQmx API), but DAQmx chooses a reasonable default value.  Once the task is started the overall memory usage should be mostly constant, and you will receive buffer overflow errors from your DAQmx API accesses if you were ever in danger of losing data that hasn't yet been read from the buffer.

[Duncan6286]

---

@Tom W [DE] wrote:
Once you have that buffered input data back on the host you can section out individual samples from the waveform array if you only need the single, newest point or only a subset of the larger dataset.

---

One more thing turned up: How can I read out only the newest point from my buffer? when the program runs for a longer time I read only old values.

Thank you!

[Duncan6286]

Additionally, the Program gets slower when I run it for 20 minutes. Do I have to increase buffer size?

[Tom_W_[DE]]

Hey Dave-

In order to get the most recent sample you need to tweak a couple of DAQmx Read properties.  You may want to configure the task to allow unread samples to be discarded, since it sounds like you don't necessarily need all of the samples that are acquired.  You should also use the RelativeTo and Offset Read properties to indicate that you want the most recent sample, plus some negative offset (that indicates the number of 'most recent' samples you want, to be returned by DAQmx Read in chronological order).

I would advice making these settings in the DAQmx Task configuration flow after you setup channels, timing, and any buffering options, as they may be reset to default values if you adjust items like timing and buffering after making these settings.  In other words, make this the last step in the Task configuration before you call Start Task.

The application slowing down after some time would seem to indicate a resource leak of some kind.  Be sure that you're not creating a new task with each loop iteration and not clearing it later at some point.  Otherwise, I'd be surprised to see a slowdown unless your system is otherwise being taxed by other processes (like graphing, logging, etc).