We have a long-standing code base in LV 2015 SP1 and 2019 SP1. It implements quite a few control loops on RT including FPGA communications. The main time consuming portion of the RT loop is the transfer to and from the FPGA via DMA. On a PXIE-8840 with Linux (NI Linux Real-Time x64 5.10.59-rt52) we have an interesting and hitherto completely unexplained effect. When executing the main RT loop at 20kHz, we would expect a CPU load of approximately 68-70% with the DMA transfers taking approximately 6us for the Read and 8us for Write. Now, when I deploy from my development machine, I see pretty much half that, 3us for read and 4us for write. The software seems to execute correctly. This means the data is actually being sent to and from the FPGA correctly. Taking the exact same code, moving it to a different directory (to force a re-compile of the compile cache) shows no difference, still the unexpected "fast" execution. When a colleague takes the same code to their PC, the performance observed is as we would usually expect. Same hardware, same bitfile, same code. So the difference seems to have something to do with my LabVIEW environment on my development PC or my LabVIEW installation. One difference I have noted is that I'm running LabVIEW 2019 SP1 f3 whereas my colleague runs f4 patch. Don't know if that's relevant. I'm also running Windows 7 (due to FPGA toolchain limitations) and my colleague is running Windows 10. Both 64-bit OS. Does anyone have any inputs as to this really unexpected behaviour? If this performance could be replicated, it would be the single most impressive bosst to performance we've ever been able to produce for our software. Something tells me it can't be real.... I'm at a loss here.

LabVIEW

Author

They're both set to 5. That was also one of my ideas. Would have been nice.

I'm still waiting for feedback from my colleague, it may end up being a non-issue....

Message 11 of 11

(215 Views)