FIFO issue

[Mudda]

Hello,

           I am having a problem in writing and reading the data from FIFO. I am writing data in a FPGA VI. The loop rate is 100micro seconds. I declared the data depth in the properties of FIFO as 2047. In my host VI I have a big state machine. The loop rate for the state machine is 1Milli Second. In my host VI I declared the depth as 4000 in the invoke node of the FIFO. I go through roughly 3 or 4 iterations between each read state. In my read state I declared the elements to read same as the FIFO depth. I am not getting a continuos stream of data. Could any one help me out so that I will get continous data. I think I am having a loop time conflict and also the depth of the FIFO. I am attaching the screen shots of my VI's.

Thanks,

Mudda.

[Thaison_V]

Hi Mudda,

I hope you're doing well.  It sounds like you aren't receiving the data you are expecting on the host.  When you say you don't receive continuous data, are you seeing discontinuities in the data between each DMA FIFO read on your host VI?  This shouldn't be happening necessarily because you do have your FPGA VI continuously trying to write to the DMA FIFO until it is no longer full.  Do you see discontinuities even within the array of data from the same DMA FIFO Read?  If this is the case, what may be happening is in the FPGA VI, your while loop (containing the DMA FIFO Write) is waiting so long for the DMA FIFO to no longer be full that it has slowed down your analog input acquisition rate.  For example, if your FPGA loop rate was set to acquire AI data every 10 ms, but the DMA FIFO stays full for longer than 10 ms, you won't meet the acquisition rate you desire.  Since the acquisition rate has slowed, it's possible that your waveform has changed more since the last time it should've acquired.  I see you use a tick count when the FIFO is full, so maybe we can use this to determine if the your FPGA loop still meets the loop timer rate even when the DMA FIFO is full.  You may also want to try to simplify your host VI in the meantime to troubleshoot by reducing it to only the state that receives the data.  Let us know if this is helpful, or if you can provide a bit more insight along the lines of my suggestion.  Thanks Mudda!

Thaison V
Applications Engineer
National Instruments

[Mudda]

Hello Thaison,

                               Thanks for your reply. I called the application engineer yesterday and I forwarded him my project. He pointed out to me that I created the FPGA target under "My Computer" instead of under the crio target. I put my FPGA under crio, I think the problem is sloved regarding the slow update of the analog input data, But I still have one more issue. I created a very simple Host vi and I am using the same FPGA vi. In the Host vi I am just monitoring digital IO and analog input. what's happening is after so many iterations my host vi is stuck, no response at all. when I click on any controller or indicator on the front panel or if I put a probe on the block diagrarm the host vi is running again. I also observed that the FPGA vi was running in the back. Could you tell me what might be causing this? If this issue is resolved I will make a good progress on my application. again I appreciate your help.

Mudda.

[Thaison_V]

Mudda,

The behavior you described does not point to anything specific right away, but with a bit more information, we may be able to help you diagnose the problem.  When you refer to the Host VI, are you referring to the VI running on the Real-Time cRIO target or on the host PC?  How do you read the digital IO and analog input, via DMA or polling/interrupts?  You may want to create an indicator in your host loop with the iteration count of the loop wired into it to make sure that the While loop is actually running.  When you say it's stuck and there's no response, does Windows report that LabVIEW is not responding?  If you are running the host VI on your RT cRIO controller, you can use the Real-Time System Manager to monitor the CPU usage to make sure the processor is indeed still running the VI.  This KB has tips on the RTSM if you are running into trouble using it.

Thaison V
Applications Engineer
National Instruments