CRIO 9024 crashes when running a timed loop <0.9msec

[UncleFungus]

Hi guys, I am stuck at figuring this one out, I am doing some work on a CRIO-9024 and I am basically reading some ADC inputs over the FPGA, writing those to a FIFO and then reading the FIFO on the RT APP side. When reading the FIFO I am using a timed loop instead of a while loop so I get less time jitter. If I set the clock to <0.9 msec I lose connection and the CRIO just freezes. Seems to work well >0.9msec -  am I missing something? Have you come across this before? I cannot attach the code but I have uploaded an image. Thank you for your help.

 

[GerdW]

Hi Fungus,

why do you need to read the FIFO that often/fast?

Have you checked the CPU usage of the cRIO when running the TWL at rates of 1kHz and higher?

Other items:

• Why are there so many coercion dots?
• Why do you need to compare with a "0" constant? There's a dedicated function…
• What's the point of the CloseFPGAReference when the loop never stops?

[UncleFungus]

Hi GerdW,

I got a lot of data I need to acquire so the faster I can send the data through the FIFO the better really, I don't want to overflow the buffer. I had a look over the CPU usage, I don't think it's a CPU loading issue as I have tried replicating it by adding lots of while loops with no delays and this had no effect, but here is the CPU loading:

- regarding the coercion dots, this is not my final code and a lot of it is just for debugging

- I need the 0 constant to check if the buffer has overflowed, I guess I can just replace it with the not equal to 0 function

- i agree the CloseFPGA reference is a bit extra

[rolfk]

FIFOs are not meant to be used as synchronous buffer but in fact to keep sender and receiver decoupled and run on their own speed, with the reader side usually having to be faster in order to prevent the FIFO from overflowing. So your setup trying to keep the receiver coupled by adjusting its speed to match exactly the senders speed is in reality abusing FIFOs. If you need to process 63 samples each time for some reason, request that many and don't try to force a speed besides that through a timed loop.

Now, that loop has to try to satisfy the FIFO read, which may or may not complete in those 800 timer ticks on 1 MHz and then at the same time also try to satisfy the 800 us interval for the timed loop, one of them will not be satisfied sooner or later.

My guess is, that with a higher loop interval, the loop interval determines the loop speed (and your FIFO eventually gets overflowed, respectively your check that there are no elements left in the FIFO after the read will reset the FIFO continuously). With a lower interval the FIFO read determines the loop timing, causing the timed loop to lag more and more in the interval that it tries to maintain and at some point there is an internal overflow because the interval counter gets to much out of sync and things go haywire. Replace the timed loop with a normal loop and let the FIFO read determine the speed of it.

[UncleFungus]

I found a work around for this.

So the FIFO RT side was reading 4 times faster than the FPGA side as to not overflow the buffer already.

However I just discovered that there are 2 types of Buffers on the FIFO side. An FPGA buffer and a RT side Buffer, I have now increased the RT side buffer at 20 x the size of the elements being written to the FIFO and I am now reading it in 20x chunks thus allowing me to lower the read speed massively.

I think you are right as in I was abusing the FIFO a bit and things going haywire.

[GerdW]

Hi Fungus,

---

@UncleFungus wrote:

I had a look over the CPU usage, I don't think it's a CPU loading issue as I have tried replicating it by adding lots of while loops with no delays and this had no effect, but here is the CPU loading:

---

So you think it's not a CPU load issue? Why do you think so?

Your image shows 100% total CPU usage, with nearly 60% in the TimedWhileLoop and ~40% in "Normal" activity.

Again I have to ask: why do you think the CPU is NOT the limiting factor in your VI algorithm???

Usually the FPGA is/should be faster than your RT host: have the FPGA fill the FIFO and let the RT read larger blocks of data with a lower loop rate…