NI 9223 at 1Mhz on a cRIO-9024

[PeanutButterOven]

negnin,

My apologies for the lack of clarity, if you search for National Instruments Producer Consumer Architecture, you will see the basis for what I am talking about. I have provided a link to a community example as well that will show you how it can be used.

https://decibel.ni.com/content/docs/DOC-32708

[negnin]

Thanks for the suggestion on using queues. I've tried it (see attached), however, the FIFO still overflows (at 40 ticks or 1Mhz). When the  'elements remaining' exceeds the 'requested depth' of the FIFO.configure, it times out. Even with the queues, the host loops can't keep up. I've tried flushing the queues etc (not in the attached code), but it doesn't seem to make a difference.

Obviously, I'd prefer to keep up with the FPGA, but since that seems unlikely, is there perhaps a way to flush the FIFO?

I tried wiring the elements remaining to the number of elements through a shift register, but that is apparently not fast enough either.

Any ideas?

Thanks!

[PeanutButterOven]

negnin,

I looked at the code and see a few points of contension. Lets try removing the static number of elements read in the producer loop. Instead insert another FIFO READ node and set the number of points to read to zero, read out the elements remaining and wire it to the second FIFO Read as the number of elements to read off the queue. It is very easy for our RT OS to get bogged down and overflow if we are not clearing every element off of the read buffer every time we call a FIFO Read node.

[negnin]

Hi,

Thanks for the suggestion, but I've tried that before and it didn't help unfortunately.

The bogging down of the RT sounds like what is happening, because it usually runs ok for 5-10 seconds (the elements remaining returns to zero), but then the elements remaining just takes off and the vi times out when it hits the maximum depth of the FIFO.

You mention 'a few points of contension'. Anyting else I should try/change?

Thanks!

LK

[PeanutButterOven]

I will try to get the same HW setup as you and run some tests to see if I can achieve the 1 MHz data rate.

[negnin]

Thanks! I'd really appreciate that.
LK

[negnin]

How long do you think it will take you to get the hardware?
Thanks a lot!
LK

[PeanutButterOven]

negnin,

It appears that the data rate is not achievable. The issue seems to stem from RT controller not being able to keep up with the DMA transfer resulting in not enough bandwidth to support the 6 channel 1 MHz acquisition. I apologize for the length of time it took to come to this realization. Please let me know if there is anything else I can do to help you with your application.

[negnin]

Do you know what the maximum rate is?

Does the maximum rate scale linearly with the number of channels you acquire?

Thanks!

LK

[KHartley]

Hey Negnin,

We only have specs for how fast we can send data through a DMA FIFO. This doesn't take into account things like viewing the data or post processing. As soon you add in displaying the data with a graph then the RT processor is over utilized and it can't keep up. Each data sample you view is having to be copied in memory out of the FIFO first and then copied into the graph's memory.

The FPGA alone can handle the 1 MHz rate for your control application we just want to setup sending a subset of data back to the host on a trigger or user input. It sounds like from your previous post that you don't need all the data streamed to the RT side just several seconds when the user wants to inspect some things. You can use the DMA approach once the user has clicked a button you send 2-3 seconds back to the RT side for inspection. Since we aren't streaming in Real-Time the processor isn't burdened with continuously pulling all 6MB/s out of the DMA Fifos. If you can provide the AE with some further requirements for your application then I'm sure we can help point you into a good architecture that will do what the requirements are. I think he just needs some more information about your application.

Please let me know if this makes sense