Analog task acquisition sometimes giving zero samples to read

[JurPas]

Hi,

I am new to the forum but have some experience with the Labview. 

I have an issue with cDaq9188 ethernet chassis and NI9205 card. When creating an analog task for measuring 30 channels continuously with 5kHz and looping my acquisition loop with 50Hz I came to a strange behavior. I get around 100 samples in each loop continuously but at some point it happens that my loop is still running at 50Hz while there are no available samples in the buffer. This is happening for couple of loops but at the end I get all missing samples and continue looping with 100 samples per loop. 

Chassis is on an isolated network together with PC, cRio and PLC.

Is this behavior somehow known to someone? I have lost a lot of hours of debugging without success. 

Thank you.

[GerdW]

Hi JurPas,

---

@JurPas wrote:

When creating an analog task for measuring 30 channels continuously with 5kHz and looping my acquisition loop with 50Hz I came to a strange behavior. I get around 100 samples in each loop continuously but at some point it happens that my loop is still running at 50Hz while there are no available samples in the buffer. This is happening for couple of loops but at the end I get all missing samples and continue looping with 100 samples per loop. 

---

You know you read 32 channels because of those two DIFF readings!? (You are reading at 160 kS/s with your MUX device, but still within the specified 250 kS/s maximum.)

• Why do you set the buffer size at the DAQmxConfigureTiming function for a continuous task? Any special reason?
• Why do you read "-1" samples from DAQmxRead?
  Why not read exactly 100 samples: then DAQmx will define your loop iteration rate to be (mostly accurate) 50 Hz…

[JurPas]

Hello GerdW,

Buffer size stayed set from debugging times. There is actually no need to set it higher than default value.

I also thought about setting DaqRead to 100 samples and I think I had tried it out in the past. The problem will stay the same. I will have to just wait longer to get those samples at the time of occurrence of my issue.

The problem as I see here is not in the reading of the buffer but in filling it. I do not understand why there is no samples in the buffer. To me it seems like the chassis is not filling it continuously. I am getting "real time" samples each loop, then I lost "real time" since there is no samples in the buffer, but later I get all missing samples in one loop and continue with "real time" samples.

[GerdW]

Hi JurPas,

---

@JurPas wrote:

I also thought about setting DaqRead to 100 samples and I think I had tried it out in the past. The problem will stay the same. I will have to just wait longer to get those samples at the time of occurrence of my issue.

The problem as I see here is not in the reading of the buffer but in filling it. I do not understand why there is no samples in the buffer. To me it seems like the chassis is not filling it continuously. I am getting "real time" samples each loop, then I lost "real time" since there is no samples in the buffer, but later I get all missing samples in one loop and continue with "real time" samples.

---

Oh wonders of DAQmx on cRIO RT targets… (I used the FPGA to handle all NI9205 stuff in my applications.)

• What happens in parallel to the AI task? Any other stuff, especially with DAQmx?
• How do you set the iteration rate? (We cannot debug/edit/run images showing small portions of your code.)

[JurPas]

Here are main vi-s.

Hope this will be enough for the insight.

Thank you.