How to Communicate Data Across FPGA VI

[nrahaim3]

I am Reading data off of several modules of my Crio right now and storing them in Fifos on the FPGA. Those Fifos, on the higher Crio level, are then started and read so that the data being stored in those Fifos can be saved to the computer. 

I am attempting to leverage this data to ultimately introduce a control loop on the FPGA level. To do this control I need access to some of the data being stored in those Fifos but I am struggling to figure out how I should go about doing this. My goal is to get that data from the "data acquisition loop" to a "control loop" on the FPGA level. It seems a registry method node could work but would that then replace the Fifos I currently have? 

I have attached the code for my FPGA Main vi. Right now that code has wires going from several Fifos out of the "Data Acquisition loop" to the "control loop". I am aware that this does not work, but hopefully that effectively communicates to the viewer of this post what data I am trying to transfer from 1 loop to the other. 

Any help is appreciated,

Nick

[GerdW]

Hi nrahaim,

you can use nearly everything as usual: local variables, global variables, wires, fifos, memory, …

[crossrulz]

As currently written, your control loop will never run because you wired directly between the loops.  Data Flow dictates that the second loop requires data to become directly available from the first loop, but the first loop won't make that data available until it stops, which will never happen.

What rate are you reading?  What rate do you want your control loop to run at?  The simple solution would be to have both run at the same rate by being in the same loop.  But if they are running at different rates, then I am left to assume that you only care about the latest measurement.  If that is the case, then I would look at using Tag Channels or Registers to store the data in the DAQ loop and read the data in the control loop.

[cbutcher]

As crossrulz pointed out, if you can then it may be simpler to place these in the same loop.

If that isn't a possibility, you can also define (additional) FIFOs that are local to the VI (you do this on the VI, not in the project view).

These can then be used to transfer data between loops as you'd expect (note you can also use project-defined FIFOs set to "Target-Scoped").

Registry storage will only hold the latest value, but will consume less resources than a FIFO.

Memory blocks are also a possibility, but require you to work out some addressing scheme.

If you want a queue of elements for processing, the FIFO is the best choice (you can also consider registers with handshaking, but I'd suggest this might be more complicated than a FIFO - decide based on available FPGA space and familiarity with handshaking I suppose...)

[nrahaim3]

So I've elected to wire the inputs to both a FIFO and a registers. I have a second loop acting as my control loop which takes in those registers and manipulates them to determine an output.

The reason I kept the FIFO is that I, on the crio level, use the FIFO for data acquisition. 

Is this best practice? Thanks for the help so far, the registers seem to be working really well in simulation and you were 100% correct on why data was originally not flowing to my second control loop. I've attached my FPGA vi for reference. 

Thanks!

Nick

[cbutcher]

That looks like it should probably work.

You will need to keep the DMA FIFOs in order to send something to your host (cRIO) system, so using multiple transport mechanisms for the same data is fine.

I'll point out that in principle you have a race condition between setting your "Desired Resistance" and using it in the Control Loop, but I think on FPGA this cannot possibly occur - the code outside of the loop should be compiled to start at the beginning of the VI (I think...) and the code in the second For loop cannot possibly execute for at least a few ticks (While loops take 2 ticks minimum, IIRC). You also presumably believe that "Laser Voltage" will be below 2 for a while, which would allow time for a valid value to be produced.

You could remove the possibility by introducing a data-flow dependency, of course 😉

You can also wire the reference for your Mod7/AO1 nodes if you'd like (to allow you to change it if needed later) but you might not be able to wire it into and out of a case structure - which could lead to some ugly branching... (Edit: to be clear, you can wire it into case structures, it's the wiring it out that's the problem - this leads my FPGA compilations to complain about "dynamic references" or similar, so you'd have to just wire into structures, not out).