FIFOs and Assembling Data

[nslogan]

I can see how this:

---

nslogan wrote:

The Real Time (RT) loop is way too slow to synchronously collect and analyze data (this RT loop is also running spark and injection of this engine) which is why I've been developing this current code with a FIFO.

---

Might be confusing. What I was trying to say is that the old way I did it - using an FPGA Read/Write Control block to collect the CAD and Pressure was way too slow. Hence, I've been looking in to the FIFO way (which I should have done first anyway - this is my first venture in FPGAs in LabView so I'm quite new to it).

The data structure I'm looking for is a 2D array of pressure data where the first indice is the sample number (so you specify the number of cycles you want to acquire - say 20) and the second indice is the position in the cycle (always 720 elements, 0 to 719 CAD). It would look like:

I don't need a bundle because the array indicie indicates which CAD the pressure sample is associated with. I initialize the 1D array (720 elements) with a default value that I know the samples can never get to (something like "100") and then I do some filtering after acquiring samples for missed values.

What you described for transfering the data from the DMA FIFO sounds like exactly what I need, the only portion I'm shaky on is how to read points until I get back to 0. I think I know enough to modify my FPGA to only push a single pressure sample per CAD to the DMA and I'm going to try that out tonight.

Thanks for being understanding and working with me, like I said this is my first FPGA adventure and it's definitely been complicated.

[nslogan]

Well my method didn't work, I've attached my FPGA code. I'm not sure why it doesn't work but I know that when I use the code I've attached the Crank Count and Current Position never change which indicates that it's somehow out of sync. When I remove the case structure but leave the rest of the logic it works fine (I've also attached this code, it's v1.1).

So, I'm not sure if you had a different method for only pushing data to the DMA when the CAD changes but if you do I'm willing to try anything.

[nathand]

You have the right idea but I don't understand your logic. What's the point of the Select which sends through the previous shift register value only when the two inputs are equal? You could drop the Select and get the same result.

If you haven't already done so, I highly recommend running your code in simulation. In the LabVIEW project, under the FPGA target, right-click and choose to execute the VI on the development computer with simulated IO, so you can probe what your code is doing using the standard LabVIEW debugging tools. I wonder if there's a bug in one of the subVIs that you didn't include, such that you're not calculating the crank count properly.

What I meant about getting back to zero is that you could read one point from the DMA FIFO, and extract the crank count from it. If you're getting one point of data per crank count, then you know from that value how many more data points you'll need to read before you're back at zero. Another approach would be to let the FPGA handle more of this - you tell the FPGA how many cycles, and it waits until it's back at zero, then puts that many cycles of data into the FIFO.

[nslogan]

That's true about the select, I hadn't really thought about it ha.

I'd love to be able to check out the subVI block diagram but it's a proprietary Drivven block that does the calculation so I can't really do anything about it. I'm currently looking in to the Drivven examples again to see if there have been updates since my counterpart in the lab designed the code that runs our engine.

That makes sense, hopefully I can work out these bugs and implement that.

[nslogan]

On the topic on the mysteriously breaking subVIs, could my reading of the Crank Count with a local variable somehow affect it?

[nathand]

Reading the local variable should not cause problems. Is there a possibility you're not reading the DMA FIFO fast enough, and it's filling? How large is it, and are you reading it constantly on the RT host side? If you're reading full cycles out of the DMA buffer and it's large enough to hold only a certain number of complete cycles, maybe there's a situation in which every time the DMA buffer has empty space it's back at the same crank count value, although I admit that seems highly unlikely.

If you have the option, I still highly recommend running the FPGA VI in simulation on the development computer. Alternatively, make a copy of the FPGA logic that you can run on your development computer, and replace all the IO with controls (or with some sort of simulated logic) so you can debug it. Make sure that you are seeing the CrankCount increment the way you expect and that it never goes to some unexpected value.

[nslogan]

My DMA FIFO is the size used in the tutorial I read, 8191 32-bit unsigned integers. I read all of those elements at once on the RT side and it just barely covers a full cycle (at 50 kHz I was getting around 10 to 12 samples per CAD). I'd like to modify the code like you suggested to only log one pressure sample per CAD but I haven't been able to get that code to work yet.

I was able to start and the run the simulation mode but realized that it's useless unless I generate my own representative data (so simulating the shaft encoder A and Z phase and the pressure transducer, although the transducer could really be random). I'm not familiar with the LabView testbench programming so I haven't figured out how to generate the encoder signal yet.

[nathand]

A DMA FIFO is actually 2 buffers, a larger one on the RT side and a smaller one on the FPGA. See the help for details on the RT buffer size; it's set automatically but you can configure it yourself if necessary. The default is probably fine for your application though since it's not huge amounts of data. I assume the 8192 is the size on the FPGA side, but you're probably reading more elements than that on the RT side. How many elements at a time are you trying to read?

Maybe you could add a second DMA channel into which you constantly write the Crank Count, so you can verify that it is in fact changing, and never resetting to some unexpected value. I'm not sure what else to recommend other than that you continue experimenting and debugging. I'm happy to attempt to answer specific questions.

[nslogan]

I'm currently also reading the suggested example value of 10000.

I'm trying as many things as I can on the FPGA side right now but still haven't figured out what causes the Crank Count value to stay at zero. I'll just keep messing with it for now, thank you for all your help!

Logan

[nathand]

One thing you can do easily is move the DMA Write into the same loop where you calculate the Crank Count, and in fact you might want to use a shift register instead of having a control and an indicator. If you do write to the DMA inside the single-cycle timed loop you'll need the timeout to be 0, but that should be fine so long as you're reading it fast enough on the RT side.