Real-Time Measurement and Control

cancel
Showing results for 
Search instead for 
Did you mean: 

why is FPGA fifo overflowing

Please see attached FPGA code. I am taking data for an engine all relative to certain cylinders' TDC. So, if cylinder 1 is at TDC, I grab data, and I continually do so at each tick of a 512 ppr encoder and add it to a FIFO. However, there are multiple cylinders, and each has an offset from cylinder 1. So maybe cylinder 1 is at TDC but cylinder 2 is not there yet so I'm not grabbing data for cylinder 2. When cylinder 2 gets to its TDC I start grabbing its data and adding it to a FIFO. I calculate this by having a counter, which is incremented each time the encoder is ticked. So cylinder 1 obviously has no offset from its self, so it starts taking data right away, then cylinder 2 waits, say, 25 ticks then it starts adding data to its FIFO. Then cylinder 3 does the same, it may be offset by 40 ticks from cylinder 1 so after 40 ticks it starts addding data to its respective FIFO, and so on. Once each cylinders data is available it sets a boolean to true and when all booleans are true I know I have all data which triggers queuing up all the data to send to the RT. If the engine is cycling at 1500 RPM, that means 25 RPS. So every 40 ms it should trigger that all data is there to be queued up to sent to the RT. That is plenty slow enough for the RT to read so the queue doesn't overflow. However, the elements remaining is immediately maxed out and I lose my RT system. It's as if elements are being repeatedly queued up eventhough they shouldn't be. Does anyone see a possible error for this? Attached is my FPGA code.

 

I know it may be tough to understand everything, I had trouble explaining it, so please ask questions if you are confused and I'll clarify.

0 Kudos
Message 1 of 6
(4,296 Views)

I don't completely understand your code, but is it possible that your problem is that the "Manage Counter" subVI starts counter the counter over at 1023 rather than, say, 512?  Are you trying to read one point of data from each cylinder per rotation?  It looks to me like the counter hits 512 and continues to count up from there to 1023, and each time you're adding a new element to the All Data queue.  Then, for each element in All Data, you write 2048 x 7 elements to the Dynamic Data FIFO (which I assume is the one that fills).  So that's possibly 512 x 2048 x 7 = over 7 million elements in the Dynamic Data FIFO, which is a lot.

Message 2 of 6
(4,281 Views)

I need it to start over at 1023, because what if a cylinder is offset by 512 ticks (360 degrees) from cylinder 1? It won't even start taking data until cylinder 1 is already at 512 ticks so in order to get data from all cylinders to send up, I have to wait another 512 ticks to get all the cylinder 8 data. And what I'm qeueing up is 512 samples*4 samples/cylinder*7 cylinders or 2048*7. I have 512 samples * 4 samples/cylinder in each cylinders FIFO, so I don't think it's trying to put 7 million elements in there.

0 Kudos
Message 3 of 6
(4,276 Views)

I don't know what your actual offsets are, but let's say that by the time you get to 800 you've reached the offset on all channels.  From 800 through 1023 you'll enqueue a boolean into the All Data fifo, which you'll then dequeue in the upper loop.  For each All Data element you dequeue, you'll try to pull 2048 elements off the individual cylinder FIFOs.  There may not be enough data in those cylinder FIFOs but you never check for it.  You might be able to solve the problem by checking the timeout from the individual cylinder FIFOs and only enqueue data into the Dynamic Data FIFO if none of the cylinders timed out.

Message 4 of 6
(4,272 Views)

@nathand wrote:

I don't know what your actual offsets are, but let's say that by the time you get to 800 you've reached the offset on all channels.  From 800 through 1023 you'll enqueue a boolean into the All Data fifo, which you'll then dequeue in the upper loop.  For each All Data element you dequeue, you'll try to pull 2048 elements off the individual cylinder FIFOs.  There may not be enough data in those cylinder FIFOs but you never check for it.  You might be able to solve the problem by checking the timeout from the individual cylinder FIFOs and only enqueue data into the Dynamic Data FIFO if none of the cylinders timed out.


 

Now that you say that, that must be exactly what is happening. I had a feeling it was something with that all data boolean. Right now I have offsets all being 0, so it's looping another 512 times and adding a "all data" boolean to the queue 512 times! Therefore the top loop keeps thinking all the data is there and sending it to the RT. I think I can keep the same thing I am using now, but just reset the counter if at 1023 OR all data is there.

0 Kudos
Message 5 of 6
(4,268 Views)

Hi,

  1. point of note check the firing order of your engine:manwink:
  2. Why not just capture data on all 8 cylinders then determine the respect TDC's?

For every  360 degrees of rotation on a 2 stroke engine you will have the cylinder pressure profile. Double up for a 4 stroke!

If you know the firing order then ploting each cylinder will provide the respect graph vs (time or angle). Smarter to use angle based( ie encoder) because it provides the physical location of the piston in relation to the crankshaft. Using time can  incur error due to acceleration deacceleration of engine loading!

An important consideration if you are determining the PMI of the motor.

 

NB  the max peak of the pressure curves does not indicate the TDC locations, especailly important on 2 stroke engines with variable  injector timing.

 

xseadog

 

0 Kudos
Message 6 of 6
(4,219 Views)