DAQmx reads occasional delays in labview RT on NI Linux RT target

[StruggleWithPXIeDAQ]

Hello,  

Hardware :

PXIe-8881 in the 1^st slot of a PXIEe-1092 chassis with a PXI-6345 on the 3^rd slot.

Software

I installed NI Linux RT 64bit 5.15.113 on the PXI target using NI MAX. 

I’m using Labview 2022 Q3 with Labview RT

DAQmx Drivers :

•  PXIe : 
  • NI-DAQmx 23.5.0.49389
• PC :
  • NI-DAQmx Device Driver 2023 Q3

As you can see in the project attached, I am reading 40 differential analog input from the PXIe-6345 at 1kHz in a RT loop.

I perform logging of the reading durations in another RT loop using RT FIFO, which are trigger by the “finished late” output of the RT Loop.

I tried various task configuration, as you can see in “Init AI Task Standard for test.vi” to perform the reading.

I manage to perform the reading. Depending on the configuration of the task, it takes between 10µs and 200µs, which is perfectly fine with the application.

The problem :

The cycle number I give hereafter are approximate.

There is occasional delay every 100 000 (+/-2000) cycle, or 100 (+/-2)seconds (it has been every 500 000 (+/-6000) cycle that time I switched to 5KHz, so 100 seconds also).

Depending on the configuration, the delayed cycles appear right at the 100 000” cycle (Hardware timed single point), or begin after 6 000 000 cycles. (continuous samples).

By reseting the PXIe6345 before initializing, and by reading only 8 inputs, I managed to increase the first delay appearance to 20 000 000 cycles and increase the delays periodicity to about 2 000 000 cycles.

Depending on the configuration, the reading duration of analog inputs takes more and more time, until it takes so much time it makes the RT loop trigger the “finished late” output, OR the reading duration seams to be constant until it suddenly takes 1ms more that it normally does.

What am I doing wrong ?

Thank you

[ZYOng]

It sounds like a memory issue to me.

Have you tried Monitor Execution Time and Memory Usage in LabVIEW VIs or Monitoring CPU and Memory Usage on Real-Time Embedded Targets?

Other than 6345 on slot 3, is there any other peripheral devices in other slots?

[StruggleWithPXIeDAQ]

Hello ZYOng, 

Yes, the complete system is : 

Slot 1 : PXIe-8881

Slot 2 : PXI-6515

Slot 3 : PXIe-6345

Slot 4 : PXIe-6738

Slot 5 : PXIe-7971R

Slot 6 : PXIe-8245

Slot 7 : PXI-8513

I did not try the monitor execution yet. I checked the CPU and memory usage occasionnaly but my test application is very light considering the target capabilities. I will try that anyway. 

[StruggleWithPXIeDAQ]

Hi, 

When I try  Monitor Execution Time and Memory Usage in LabVIEW VIs, It mostly shows that the memory usage of my RT app is far bellow (less than 1Mo) the target RAM (32Go) :

 

When I use Monitoring CPU and Memory Usage on Real-Time Embedded Targets

I manage to get the free ram available on my target : 

........

But it barely change during the execution. I performed a log of the available ram every 10 seconds : 

The occasional delay of the DAQme Read Analog Input vi doesn't seems to be related with the target available ram... 

Can someone spot a mistake in my code ? 

[StruggleWithPXIeDAQ]

Here is more details about the problem. I logged the DAQmx read duration every 10 seconds to display it relatively to the available memory.

The duration of the DAQmx reading inscreases until it takes too long to read and a sample is lost : 

The variation of the ram shows no correlation with the occurences of the lost samples. 

Maybe the problem is related to a lack of precision of some of the clocks I use : 

-> The timed loop is synchronzed to Scan Engine 

 

and the scan engine is configured as follow :

When the DAQmx task is configured as follows : 

Thanks for your help, 

[StruggleWithPXIeDAQ]

The problem was indead a bad sync between the timed control loop and the DAQmx analog input task. 

Both were configured at 1kHz, but thoses 1kHz are differents. 

I confirmed that by configuring the DAQmx task to 1000.00001 Hz and seeing that it changed the behavior. long story short it almost solved the problem. 

But this is a shity solution so I used the "control loop from task" cfg of the DAQmx create timing source at the end of the analog input task configuration, and wiring the "timing source" output of the vi to the "source" input of the timed controled loop.