I am working with the NI 9223 module, on a cRIO-9082, trying to sample at 1 MS/s (or at least half that at 500kS/s). I am running the "NI 9223 User-Controlled IO Sampling" code example (found on a prior forum post), slightly edited, to test out the sampling rate. The problem I am running into is that I am consistently getting the "Overwrite" error after just a few cycles, unless I set the sampling period up to 4 us, which is too slow for my application's needs. I need it to run without any data overwrite at either 2 us or 1 us. I am only reading from two channels on the NI 9223.
Please let me know what might be causing this overwrite problem, and how I might be able to avoid it.
This is still the original poster (I realized I posted the topic while still logged in under my colleague's account on a shared computer). I just wanted to post a follow-up with a little more detail. I removed some of the extraneous error-checking to limit the computation in each loop, and now it seems to be sampling at 1 MS/s without throwing the overwrite error. However, when I plot my recorded data, I am getting the same artifacts that appear to show overwrite occurring.
Here is an example, in which I am sampling two different signals from two different sources through the same 9223 module (one from the system I am trying to measure and one from a separate waveform generator). At the same location in both channels (toward the center of this plot), it appears as if data was lost/overwritten. These dropped signals occur frequently.
With the current design within your LabVIEW FPGA code, we are sampling data faster than we can stream it back to the host so the buffer is filling up and eventually hitting the overflow point; causing this error to occur. One way we can avoid this issue is by using queues to store the data. This will allow us to store more data and allow the cRIO to stream the data at the fastest rate that it can process without losing any data along the way.
The best way to implement queues is within a producer-consumer structure. I have included a link below which provides example code for this design and describes the procedure more in depth.
Application Design Patterns: Producer/Consumer
Ah thank you! This seems to have been exactly what the problem was. I implemented the Producer-Consumer architecture as you mentioned on the RT host and now it's running smoothly without the buffers filling up.
did this producer consumer actually help within the FPGA application?
This is a confusing reference. I have an application doing something very similar, User controlled io in the fpga.
I'm trying to decide if I can trust the acquisition within the FPGA, is there error only because I'm trying to view the data.
How can I confirm the sampling rate is proper in the FPGA application?