FIFOs and Assembling Data

[nslogan]

How would I get the analog value then? The same way that I'm accessing the Crank Count variable (with a local variable)? Would there be any issues with syncing between the analog and crank value?

[nathand]

Can the Analog Read run in a single-cycle loop? If not, you could read the analog value in a separate loop, write it to a register, and read that register in the single-cycle loop.

[nslogan]

I'm pretty sure it can't, I remember wanting to do that at first but the clock of the FPGA is way too fast compared to the max sample rate of the analog card.

I only currently have LabView 2011 and from my research it looked like registers were added in 2012. Will a local variable still be ok or is there another, better option?

[nathand]

Try a local variable then, it should be fine. If it doesn't work, you'll have good evidence that the problem is the local variables, and you could use a memory block instead.

[nslogan]

That's what I'm starting to wonder. The advantage to moving it to the SCTL like you suggested means that I don't really have to adjust the frequency of the analog read anymore (which seemed to mess with the Crank Count - but that could be the local variable causing problems, too). It definitely means I have to change the way the crank count is written, though, unless I want to deal with data pushed in at 40 MHz (ha!).

[nslogan]

Alright, I've tried a number of things, all inside the SCTL running at 40 MHz. The first thing I tried was just writing to the DMA which worked fine but produced an inordinate amount of data (as expected).

I then tried using the same logic I had before with the case structure and shift-register to determine if it should write or not and it didn't work - same behavior as before where Crank Count is 0 and acts like it's not syncing. My code looked like this (except with the Pressure local variable - I tried removing it thinking that was the issue but when I did and ran the same code shown here it still didn't work):

So, I removed the bool input from the case structure input and instead used a toggle, like this:

Now, what was interesting here is that when the toggle was TRUE the Crank Count was in sync and working as expected but when the toggle was FALSE it didn't work...

I'm now going to try the code seen above but with the Pressure local variable to see if it has any effect at all.

[nslogan]

 The same behavior applies to the version with the Pressure local variable - when I don't have the toggle set to TRUE the Sync Stopped LED lights in EPTData and the Crank Angle stays at 0. I'm not sure how a case statement not related to the EPTData can affect EPTData Sync Stopped...

[nathand]

Please get rid of the Select function. As I mentioned before, it's unnecessary. The Crank count should wire directly to the right-side shift register, and the left-side shift register should wire directly to the not equals. No other functions needed, although I doubt this is the problem.

Are you sure you're writing to the correct DMA FIFO? Is there any possibility that you're writing to that same FIFO somewhere else?

[nslogan]

Alright I updated my code and removed the select function as well as rewiring the output from Not Equal to my case structure. I doubled checked my DMA FIFO configuration and made sure I wasn't writing to it from somewhere else. I've attached my most recent code and an image of my DMA FIFO configuration.

At this point I'm not sure what is wrong with the way I'm doing it.

I tracked down some documentation on the Drivven VIs I'm using to make sure I've configured all of the inputs correctly. I attached my RT VI as it is (it's messy but it's only purpose is to display the data at the moment). I'm toggling the watchdog correctly (>4Hz) and there's nothing else that stands out as a problem (I have all of the other inputs configured correctly for my engine).

I might have to see if I can get ahold of a Drivven application engineer for an opinion.

[nathand · Accepted solution]

I finally have a possible explanation for what you're seeing.

In the RT code, you have a -1 (forever) timeout waiting for data. When you put the trigger for the DMA Write in the FPGA, data doesn't accumulate as quickly, and if CrankCount doesn't change (or your boolean trigger is false), then data doesn't accumulate at all. The DMA Read is limiting the loop rate on the RT side, and if it never reaches 10000 elements, then the RT code never loops at all. As a result, you never (or infrequently) update the value of EPTControl, which I'm guessing causes the problems you're seeing.

My recommendation is that if possible, you move all the control logic to the FPGA. Another option is to read the DMA FIFO into a separate loop from the control. You may not want to use a forever timeout, for the reasons explained here.