Architecture for RT

[jyang72211]

Is using a producer consumer a good idea for RT?  What about all the other standard architecture such as state machine, master-slave?  

[Bob_Schor]

The best architecture for RT (or anything else) is whatever best fits the Problem.  What are you trying to do?  What to you mean by RT?  On what are you trying to run this code?

Sorry, but a Vague Question gets a Vague Answer.

Bob Schor

[jyang72211]

RT stands for real-time target.  Let me reword my question.  Can I use the same architecture I used for PC target on a RT target? The main problem is using myRIO to listen to an UART and output a waveform through the FPGA, while monitoring the waveform and send it back to the RT.  

[Bob_Schor]

I don't have a lot of experience with FPGA, but I believe that most LabVIEW Structures and many of its functions can be implemented on the FPGA.  Thus you could have State Machines, Producer/Consumer (assuming FPGA supports Queues or Channels), etc.

You talk about "monitoring the waveform and send it back to the RT".  I admit I'm a little confused (possibly because of lack of FPGA experience).  My LabVIEW RT experience has been with a PXI system, where the PXI through DAQmx can acquire data into a Waveform and send it to the Host for monitoring (since only the Host has display abilities).

Bob Schor

P.S. -- both of my Host and Remote systems had similar architectures -- multiple loops, Producer/Consumer pairs, a Queued Message Handler acting like a State Machine with Optional Data, etc.  They were "connected" via four Network Streams, two for exchanging Messages, two for Target-to-Host data streams.  The Network Stream routines could also be considered Producer/Consumer with TCP/IP being the "transmission" path instead of a Queue ...

[Sam_Sharp]

I suggest you take a look at the cRIO developers guide (http://www.ni.com/compactriodevguide/) - it is a great resource for architecting an application that uses RT/FPGA/Windows. There's also a great built-in sample project and it's associated 'decisions behind the design' presentation (http://australia.ni.com/sites/default/files/Decisions%20Behind%20the%20Design%20-%20LabVIEW%20for%20...)

For RT, you generally want to avoid sources of jitter so that things can run deterministically (e.g. avoiding memory allocations, not having to wait for other things etc.). You can use queued message handlers on RT but you will probably also have some timed loops for your important/deterministic processes. A producer/consumer would be good if you have a deterministic process (e.g. controlling a motor) which then enqueues that data to another loop for logging (because writing to disk is slow).

[Vincent90]

If i understand your need, your system need

- Host to display your UART data and send a waveform

- RT which get your UART data and send it back to HOST (FIFO)

- FPGA which play waveform you sent from HOST via FIFO DMA, Memory Block or LookUpTable

One architecture which could fit :

- Producer/Consumer loop on Host

- State Machine on RT

- Maybe state machine depending on way you choose to code your FPGA

Can't guess more than that.

BR,

Vincent

[crossrulz]

---

@jyang72211 wrote:

Can I use the same architecture I used for PC target on a RT target?

---

In general, yes.  However, you need to be a lot more sensitive to memory allocations and usage.  An RT system typically does not have nearly as much horsepower as a PC.  Also you typically are looking for determinism with an RT (another reason to avoid memory allocations).  The cRIO Developer's Guide is a great resource.

---

@jyang72211 wrote:

The main problem is using myRIO to listen to an UART and output a waveform through the FPGA, while monitoring the waveform and send it back to the RT.  

---

I am pretty sure all of that can be done in the FPGA.  Just use a DMA FIFO to pass the waveform data up to the RT.  In the RT, you can just read the DMA FIFO and pass whatever data to the PC via a Network Stream.  I am not currently seeing a reason for the Producer Consumer here.

Just to pass a one of my lessons learned across the last year or so: Put everything you can into the FPGA.  It is the ultimate in determinism and then you don't have to worry about CPU and memory nearly as much.  Best of all, if the RT crashes, the FPGA is still running, so you can still do testing (in my case, I was communicating with PLCs and reporting the pass/fail status to the PLC via DIO).  In my last couple of cRIO projects, all my RT was doing was saving/loading test parameters and sending data to the PC.  I found no need for anything fancy.  Just have an Action Engine for the network connection to the PC and then my 3-4 loops (status/watchdog, test data pass through, network read) could just write to it if there was a connection.