CRIO scanned variable reads are slow. Do you know why?

Question

I have a cRIO 9073 with a few I/O modules (for a total of 8 AI, 2 AO, 30 DI, 50 DO). I want to read and write the I/O from a PC.
This is the code I used on the PC (LV 2011):
(And no, opening the variable once before the loop doesn't help).
This is the basic structure:
It's supposed to use the scan engine on the cRIO to read and write the I/O values. The scan engine was left with its default values of a 10 ms scan rate and 100 ms network update rate.
My Problem is that the updating of both the DI and the DO is slow (it varies between immediate and ~6 seconds). It almost looks like there's a cycle somewhere and the time it takes for updating is dependent on where in that cycle the DI or DO was actually set. The primitives themselves run quickly (the loop has a 100 ms delay in it and it always runs at that speed), but the data takes time to arrive.
The cRIO hardly has any code running on it - the FPGA reads two DI cards and transfers the data as a U64 value through a DMA FIFO and the code on the RT target only takes this value from the FIFO and writes it to a network stream (not too quickly either, since most of the time there's no data in the FIFO). There's another network stream in the same loop which the cRIO uses to send error clusters to the PC. And that's it. That was all the code running on the cRIO, and yes, it did have a delay.
As far as I could tell, the code which managed the network stream always responded immediately. Triggering data in the FIFO results in an immediate display of the data on the PC. It's just the I/O read through the scan engine which is slow (and apparently not even all of that, since the AI display on the FP would update at several Hz).
At some point we tried moving the I/O reads to the cRIO (using ni.var.io instead of ni.var.psp), but that heavily loaded the CPU on the cRIO (although I can't understand why, since it was a simple loop which read a SV and wrote the data from it to the IO variable).
The latest thing we tried was to take the data from the SV, convert it to a U32 and send that to the FPGA VI. The FPGA VI then writes and reads the actual I/O. This seems to work, but makes me unhappy as it's considerably less inelegant from the system we had originally.
This didn't happen on another test unit which had less cards and code in it, so I'm not sure if this is a problem with too many cards/code or with something we did to the unit. I don't have experience with the cRIO, so I don't know how it's supposed to behave. Maybe we'll try configuring the test unit to be the same as the real unit and see what happens.
If I understand correctly, the real problem here is in the diagonal line in the diagram above, but I'm not sure why.
Does anyone have any idea why this is happening and if there is any way to do this (read and write the I/O from the PC at around 5-20 Hz) elegantly?
Try to take over the world!

Answer 1

Hi tst,
The scan engine is certainly not the fastest option for acquiring data from the i/o modules. However, you should be able to acquire the data consistently in the rate range you are looking for. The face that you're inconsistently getting ~6 s pauses in updating the DI and DO is strange.
One thing that was unclear in your explanation is how you're using hybrid mode. What I/O modules are you using with scan mode and which ones are you using in FPGA mode?
You said that you have found an "inelegant" solution by writing data from the shared variable (data transferred from the host VI?) directly to the FPGA and having the FPGA write and read the result. Programming the FPGA directly will always be quicker then accessing the i/o through scan mode. Do you have this module set to program in FPGA mode? Did you have it set to program the scan engine when you were using that interface?