From Friday, January 17th 11 PM CDT (January 18th 5 AM UTC) through Saturday, January 18th 11:30 AM CDT (January 18th 5:30 PM UTC), ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
I am using cRIO 9045 with NI-9227. One issue that I have been having is with streaming current on all 4 channels interleaving the 4 points of data. Occasionally, these will go out of sync. For example, [1.12, 0, 0, 0] becomes [0, 0, 0, 1.12]. Despite my best efforts (flushing the FIFO/reading any remaining data), the out-of-sequence pattern persists. As you can see in the screenshots below, I have been very particular with my state machine, to properly Start/Stop and leave On/Off the card. This includes reading any remaining data on the card.
None of this however works 100%. I still get out-of sequence data even after turning on/off my card and the related FIFO logic. This got me thinking, is there any real downside to have 4 smaller FIFOs instead of 1 large one? This would stop my FIFO out-of-sequence error completely. Why would anyone interleave anything when they run the risk of something like this happening?
Hi eli,
Be careful when flushing a FIFO with interleaved channels. If you flush the full buffer, the number of flushed elements will likely not be a multiple of the number of channels (here 4), which will shift your data's positions in the packet. Here it appears you flush your FIFO irrespective of the number of channels on both sides (host and FPGA).
2 solutions:
1. Flush always a multiple of the number of interleaved channels, from the host side, exactly like a normal read (and don't flush from the FPGA side);
2. Or, first make sure the FPGA stops writing to the FIFO, then flush the FIFO from the FPGA side, then flush the full FIFO buffer from the host side, finally you can make the FPGA start writing to the FIFO again. This is much more complicated and requires a kind of state machine on the FPGA side and a synchronization mechanism with the host.
Also, why using "Acquire Read Region" when flushing? You are creating (and not destroying) block references for nothing. Use the simple Read instead.
Regards,
Raphaël.
Not really, I will try to be clearer:
On the host side:
- Before running your FPGA VI, the FIFO should have been configured using the "Configure" method with a sufficient depth.
- Always read the FIFOs as you do in your "standard read" case, then use the values or not depending on your needs. It should be done frequently enough so that the FIFO depth is never reached.
- Remove your "False" case, which is useless.
On the FPGA side:
- Do not flush here, you do not know how many you flush.
If the buffer on the host side is correctly sized and the read operation frequent enough, the FIFO buffer will never fill up and you avoid having to manage the complicated case were the data are out of place.
Check example "Interleaving Channel Data (DMA).lvproj" in the example finder.
When that works, if it is still a requirement to manage the case of the buffer filling up, then you can proceed using a state machine and a synchronization mechanism (using interrupts, controls, handshakes or whatever...). As explained, you must ensure the FPGA stops writing, then empty both buffers (FPGA and host sides), then you are good to start writing again.
Regards,
Raphaël.
@eli.barber wrote:
I think I am OK with some small amount of variance now in the starting data as it depends on how much data is already in the FIFO block.
You can avoid that by delaying the FPGA acquisition until you are completely ready to read the elements on the host side.
2 possibilities come to my mind:
1. Use a boolean control on the FPGA front panel to enable writing to the FIFO.
2. Uncheck "Run the FPGA VI" in the "Open FPGA VI Reference" node configuration and use the "Run" method later.
Thank you, I will need to look into running the VI immediately before the the loop somehow. I added a loop indicator and realize that I occasionally get the massive spikes in loop time which is most likely the culprit for giving me an out of sequence problem. I still am getting this even after replacing a loop with a timed loop at 20ms. Thoughts?
@eli.barber a écrit :
[...] I occasionally get the massive spikes in loop time [...]
Which loop? Host side? FPGA side?
I can't really help further unless you post some actual code (".vi", ".ctl" and ".lvproj" files in a zip, not screenshots of code). Also post both FPGA and host codes. Maximum version LV2021, otherwise from the project explorer, use menu "File" > "Save for Previous Version..." > 21.0.
Is there some kind of toolkit I could use to track what is going on during the time spikes? Nothing would run unless I share all the VI's and there are a lot of them, I don't think I can do that. Anything with the timed loop that is obviously wrong?
Nothing seems wrong with the Timed Loop configuration.
It mostly depends on what is done inside your timed loop. If you initialize things or allocate a lot of memory on the first iteration, that may take a lot of time. Try measuring your max iteration time by ignoring the first few iterations to confirm that.
Then simply by adding "Tick Count (ms)" functions in your code and computing the time differences, you will be able to see what part of your code takes longer sometimes.
If you want to go further with advanced tools, there is the Desktop Execution Trace Toolkit (for PC applications) and the RT Execution Trace Toolkit (for RT applications). However, I would really try the techniques I explained above first, because it is usually quite hard to get something out of these tools.
Regards,
Raphaël.
