Channel Switching during DMA Interleaving/Synchronize data stored in different DMA FIFOs

[Harss]

Hi,

I tried out the solution suggested just today and now the channel data seems to be okay. Using Decimate 1D Array shows values to be consistent. However, using network streams again causes undesirable results and switching. I have attached the snapshot of the image of the VI on my RT.

I am not sure if the VI in the image attached is the right way to transport the values onto the host using network streams. I guess the implementation of network streams in my case is not correct I will have a deeper look into it and get back to you with more details tomorrow.

Any suggestions/hints about the right way to do this would be really appreciated.

I have also checked the Elements remaining from the FIFO and it is always less than the requested depth. So I guess the issue could not be due to time out .

Thanks.

[nathand]

What if the number of elements you read from the FIFO is not a multiple of 3? All of the array outputs from Decimate 1D Array must be the same length. If the data you read from the FIFO isn't a multiple of 3, you'll lose data. Round down the number of elements you read to the nearest multiple of 3 and see if that fixes the problem.

[mateh]

1. Did you mean to join the 1st and 3rd array for the U64? When you posted your FPGA VI, it looked like the AI data was written to the 1st element, and the split U64 was going to 2nd/3rd elements.

2. I see a coersion dot at the input to your network stream, which means the data types don't match. When you initialize the network stream, are the representations of the constants U64 and U32?

3. Are you checking the timed out boolean on the FPGA FIFO? Make sure that you're latching it as I've shown in the picture from earlier (put the boolean indicator in the True case, and leave the False case empty) that way you can be sure to catch any timeouts that have occurred. You can monitor the boolean indicator inside the RT while loop.

My guess is that it's still timing out. You're trying to read only 3000 elements from the FIFO and then process that data on the RT controller and stuff each sample one at a time into the network stream. The time that it takes the controller to accomplish this is going to be way longer than the 1 millisecond that it takes the FPGA to write the 3000 elements, so there's no way for the loop to keep up. Try reading 30,000 elements instead (a 10 ms loop period), and if you're still getting timeouts increase it even more. Also, try using the "Write (N Elem)" network stream function instead so that you only have to execute it once instead of thousands of times in a For loop.

For your "caution" indicator, try comparing it to a much lower number, like 150,000. Think about it this way: If you're trying to read 30,000 elements, the loop is going to keep checking Elements Remaining as fast as it can until there are at least 30,000 elements available, then it removes 30,000 elements from the FIFO and starts over again. There's likely going to be more than 30,000 elements remaining at the point where it reads data because the we can only check so often, but it should NOT be much more than that (assuming your loop can execute fast enough). If Elements Remaining is more than twice as much as the number you're trying to read (60,000 in this case) and rising, then the loop is obviously not keeping up.

[nathand]

---

@nathand wrote:

What if the number of elements you read from the FIFO is not a multiple of 3? All of the array outputs from Decimate 1D Array must be the same length. If the data you read from the FIFO isn't a multiple of 3, you'll lose data. Round down the number of elements you read to the nearest multiple of 3 and see if that fixes the problem.

---

Never mind, ignore this comment... I didn't realize that you have the "3000" wired to the number of elements to read, because the wire is hidden behind the border. A common approach here is to read all (or nearly all) the elements available rather than a fixed number.

[Harss]

Hi,

Thanks a lot for your inputs.

I added the boolean to the FPGA VI to check for timeouts and indeed there was a timeout on the FPGA.

I noticed one more thing even though the time out was there on the FPGA VI yet the  FIFO on the host had very few elements remaining. Further checks helped me find that the time out could also be related to the entire FPGA VI waiting for the start trigger placed in the first frame of the sequence structure. Probably waiting for the Timekeeper to be logged as well as the Start trigger too could lead to the delay and the FIFO getting timed out on the FPGA , because there was no effect on the RT side.

I also noticed that time out on the FPGA VI could be due to another reason. Right now I do not have the mechanism to trigger the acquisition using controls from the PC or the RT and the execution is started manually. The order in which the VI 's were executed earlier manually were as follows

1:The FPGA VI was turned on. The start button was trigerred on the FPGA VI.

2:The RT VI was turned on . However, due to a lag in manually turning on the RT VI probably caused the number of elements in the RT FIFO to rise dramatically and the FPGA VI to be timed out

The order of execution was later changed as follows

1:The FPGA VI was turned on.

2:The RT VI was turned on . The host VI was also turned on.

3:Finally the FPGA VI was trigerred by pressing the start button.

In this case the channels on the DMA did not switch and on the host VI too there were very few elements left in the FIFO and finally the data could be streamed to the host PC using network streams.

I however could not carry out an exhaustive testing of the data being logged.

Please find  the image of the VI as an attachment.

I will exhaustively check the nature of logged data and again get back to you by tomorrow.

Once again thanks a lot for all the help 🙂

It really helped me to closely troubleshoot this issue.

Thanks.

[mateh]

I'm glad you're making progress.

---

@Harss wrote:

I also noticed that time out on the FPGA VI could be due to another reason. Right now I do not have the mechanism to trigger the acquisition using controls from the PC or the RT and the execution is started manually.

---

That's a very good point, and something that I failed to notice before. You could also utilize the IRQ which you've already added to your VI to manage when the FPGA begins acquiring data. In your RT VI you acknowledge the IRQ, but by default the IRQ in your FPGA VI will not wait for this acknowledgement before it starts acquiring. If you wire a True constant to the "Wait Until Cleared" terminal of the IRQ on the FPGA, it won't begin to acquire data until the RT VI acknowledges it, which I think is the behavior that you want.

[Harss]

Hi,

Thanks a lot for the feedback . I will definetly add it to the FPGA VI and get back to you tomorrow.

Thanks once again.

[Harss]

Hi,

It seems the issue is fixed only a small issue it seems the data rate becomes low after immediately running the VI and then running it again. I mean I need to compile the FPGA VI and immediately then I get the sample rate of 1 MS/s . However, if I recompile the VI again the data rate becomes low.I am unable to understand this behaviour. However, the channel switching issue now seems to be fixed. Thanks a lot again for your help 🙂 once again.

I have few questions about the processing on cRIO. Is it okay if I keep this post updated with the new questions?

Thanks.

[mateh]

I'm not sure what you mean. Are you saying that you changed something and recompiled the VI, and now it doesn't run at full speed any more? Can you post your VIs with the latest changes? Please attach the VIs, not an image.

[Harss]

Hi,

Yes exactly I need to make some cosmetic changes in order to recompile the VI each time so that it acquires at 1 MS/s. If I stop the VI and just run the FPGA VI again it acquires at a slower rate(700KS/s)

I will attach the VI as soon as I would be able to connect to the crio, it would take roughly two days, since tomorrow and day after tomorrow I would not be able to access the cRIO. I would update this post  as soon as I have access to the VI.

Thanks.