RT & FPGA Modules – I am missing a fundamental concept

[joe11361]

Recently I have been asked to program a compactRIO 9074 and in the midst of researching how to do that, I have become thoroughly confused…

I understand that the RT module is used for precise timing (i.e low jitter) and somehow it interfaces with the host computer (i.e. computer with the VI).  I also understand the FPGA module allows you to, and forgive the simplicity, recreate the circuit on the chip, thus allowing virtually true multithreading and really fast speeds.  Also, the FPGA interacts with the IO modules/ports.

The thing that I am unclear about is:

When you program the compactRIO 9074, do you select only one module (RT, FPGA) and ignore the other?

     -or-

Do you use both modules - the RT module for the embedded hardware and the FPGA module for the FPGA bitstream?  If so, how does the embedded hardware talk to the FPGA?  Is this something you have to manually program?  Any literature/tutorials on this?

     -or-

I’ve even read something to the effect- the embedded module gets programmed with the RT module when the cRIO boots up for the first time.  If that’s true, then does RT module get used only that only time and all programming thereafter is done with the FPGA module?  Is the one-time RT module provided by NI or is this something I would have to create?

I think that I am missing something so fundamentally simple that this whole project is becoming so unnecessarily complicated.

Thanks in advance for the help.

Joe T.

[PackersFan]

The short answer: You will always use the RT module.  The FPGA module is optional.

The long answer: http://www.ni.com/compactrio/setup/

[mahu]

for the crio you need both sides, but is available to work with SCAN MODE when custom input is not required

http://zone.ni.com/devzone/cda/tut/p/id/7338

http://zone.ni.com/devzone/cda/tut/p/id/7693

maybe is best for you begin with this option, and later use fpga advantages. Not every application need customize input, only in special cases.

regards

[PackersFan]

I may need to correct myself.

The FPGA module is required, however, you do not need to program the FPGA.  As mahu said you can use the Scan Interface to communicate to your IO.

[nathand]

It is a bit complicated, but powerful and flexible.  If your needs are simple, NI provides tools (such as the scan engine) so you may not need to get into all the details.

The cRIO is almost a full computer, running a dedicated, real-time operating system (either PharLap ETS or VxWorks, depending on your cRIO).  On top of that, there's the LabVIEW runtime.  That computer also contains an FPGA, similar to if you bought one of the NI PCI FPGA cards and installed it in your PC.

The FPGA talks to the processor in the cRIO.  If you need full control over the FPGA, then you write that code yourself and use DMA FIFOs and front-panel controls to transfer data between the cRIO and FPGA.  If you just need access to the IO, you can use the Scan Engine, as previously noted.  You also need a way for the cRIO to talk to your computer.  Again, you can write code yourself, or use the NI-provided tools such as network shared variables.  If you don't need the cRIO to do anything other than act as an expensive data acquisition device, you can link a shared variable to an I/O channel and access it directly from your PC, or share your IO variables over the network.  Run a search on the NI site for "network shared variable scan engine" for more information.

You write separate code for the cRIO and the FPGA.  You can run your VIs on the cRIO within the LabVIEW development environment and use most of the standard debugging tools, it will just be a bit slower to respond than when the LabVIEW code runs on your PC.  When you have a working program, you can build an application and deploy it to the cRIO so that it will run at startup.  You can do this as many times as you like.  The LabVIEW program on the cRIO may contain an FPGA bitstream embedded in it.  Writing code for the FPGA is more complicated - there are limitations, and you must compile the code before you can run it (no interactive debugging unless it's running in simulation).

[joe11361]

Thank you all for your help.  It makes more sense now.

Joe