Query on the cRIO systems

[Ano Ano]

Hello,

 

Usually when I want to acquire data I use a cDAQ chassis connected to a PC. I am thinking now for a new project of using either a CompactDAQ controller or a cRIO like the cRIO-9064 to combine both PC & module chassis.

 

Since I have never used the cRIO or FPGA systems before, my question is: During the process of writing code & trials, can I connect it on a PC, like I used to do with the cDAQ, or do I need to build/embed code on each software change?

 

Thank you in advance,

[hooovahh]

Disclaimer that a lot of my knowledge on this subject is not from hands on, but research.  I have lots of experience with cDAQ, and lots from FPGAs, but not so much when it comes to RT or embedded targets other than FPGA.

 

When using a embedded target, you'll program on your normal host (usually Windows) machine and in the project you will add your target.  Then you will write VIs for those targets and deploy from within your host.  Then some level of debugging is done on that host machine, for the code that is running on the target, this always involves seeing front panels, but also some level of probing for some targets.  (for example FPGAs don't allow probes breakpoints etc.)  

 

When using a cRIO almost all I/O go through the FPGA.  There are exceptions for things like serial ports which I think just show up as a VISA resource.  So full cRIO applications may have three targets, the FPGA, the RT, and Windows, all in the same project.  But for debug you can temporarily ignore the Windows target, and for the FPGA you might be able to get away with the Scan Engine, which is a FPGA profile that just reads all data and sends it to the RT.  So you might be able to get away with just needing to write one program, but then when you need more control you can write code for the FPGA, and then a custom UI might be needed on Windows.  All three targets have the familiar LabVIEW IDE, just some have a subset of palette items.

 

I have never used an embedded cDAQ chassis but I believe they are a target in the project and you write code and deploy it like before.  But in this case I/O go through DAQmx and not through an FPGA.  A lot easier, but less flexible.

[Omar Mussa]

If you use a custom FPGA, you need to recompile it for any change (unfortunately, even cosmetic UI changes  - unless you are running the FPGA emulated target which you can do to validate simple logic, etc before you compile for hardware).

 

The RT code can run from source though without recompile (it gets deployed to RT target and then it runs and is debuggable more or less like desktop LabVIEW).  I've personally had minor inconveniences where I had to reboot the target because the deployment for debugging failed but usually a target reboot is all that it takes to fix deployment issues during development.  Once you are happy with your RT code, you can compile an rtexe that you can deploy.

[Ano Ano]

Thank you both for your fast response.

 

So basically the cRIO is not as easy to use while troubleshooting code... Does it take long to recompile/download the code to the cRIO's FPGA?

 

The cRIO-9064 that I am thinking of using, is a linux system. Can I use a host windows based PC to write the code and download it to the cRIO? Will it work?

[Jordan Kuehn]

Thank you both for your fast response.

 

So basically the cRIO is not as easy to use while troubleshooting code... Does it take long to recompile/download the code to the cRIO's FPGA?

 

The cRIO-9064 that I am thinking of using, is a linux system. Can I use a host windows based PC to write the code and download it to the cRIO? Will it work?

 

Even simple FPGA code can take quite a lot of time to compile.  There are various strategies for maximizing each compile, and minimizing the compile time.

 

You can use a Windows PC to program all the cRIOs.  If you can use the scan engine, you can get a simple to moderate level system working without too much pain.  Adding the FPGA can add significant development time, especially if you have never programmed one before.

 

Here is the NI development guide that is a good resource as you have some more detailed questions.  http://www.ni.com/compactriodevguide/

[MarkCG]

Thank you both for your fast response.

 

So basically the cRIO is not as easy to use while troubleshooting code... Does it take long to recompile/download the code to the cRIO's FPGA?

 

The cRIO-9064 that I am thinking of using, is a linux system. Can I use a host windows based PC to write the code and download it to the cRIO? Will it work?

 

It sounds like you don't need custom FPGA functionality. Programming with the scan engine interface is easy, and I personally thinks it's even easier than NI-DAQmx, where you need to screw around with configuring tasks and channels. With scan engine interface, you just drag the I/O node onto your block diagram from the project and read or write from it.

[smithd]

As hoovah and mark said you probably want something more like the standalone cDAQ-9132 which has an RT controller but still uses daqmx (its $1k more though, because the cDAQ doesn't come in a "value" line -- it does come with the monitor out, x64 linux, and a much faster processor so it may be worth the cash anyway).

 

If you actually do need the FPGA because of timing, processing, or specific I/O needs then it is absolutely possible to simulate the FPGA and RT code, something which has gotten steadily better over the years. Is it seamless, no, but it works well enough.

http://www.ni.com/white-paper/51859/en/

Edited December 10, 2015 by smithd

[jacobson]

Disclaimer that this is from the perspective of someone who helps people who call in to NI with problems rather than a developer

 

If you have not built an application using RT/FPGA, are very familiar with DAQ, and do not need to use the FPGA for any of the reasons smithd mentioned I would agree with using the cDAQ controller. You'll probably save a lot of development time if you stick to something you're comfortable with.

 

In terms of general use and debugging for your real-time application, it will feel very similar to testing and debugging a windows application. When you click the run arrow on your VI it will deploy code to your target (minimal time) and you will be running your code interactively which means the application is running on the remote target but still gives you access to most of the normal debugging tools. When you are done and want to deploy an executable, you can build an rtexe and set that to run when your target powers on all from your project. You can troubleshoot this the same as you would a debuggable executable running on a separate computer.

 

FPGA is a separate beast and it does add to development time as people have mentioned, especially if it's your first time. I think RT is pretty good once you get past the whole finding the target in MAX part.

 

-Matt J

[Rolf Kalbermatter]

Disclaimer that this is from the perspective of someone who helps people who call in to NI with problems rather than a developer

 

If you have not built an application using RT/FPGA, are very familiar with DAQ, and do not need to use the FPGA for any of the reasons smithd mentioned I would agree with using the cDAQ controller. You'll probably save a lot of development time if you stick to something you're comfortable with.

 

In terms of general use and debugging for your real-time application, it will feel very similar to testing and debugging a windows application. When you click the run arrow on your VI it will deploy code to your target (minimal time) and you will be running your code interactively which means the application is running on the remote target but still gives you access to most of the normal debugging tools. When you are done and want to deploy an executable, you can build an rtexe and set that to run when your target powers on all from your project. You can troubleshoot this the same as you would a debuggable executable running on a separate computer.

 

FPGA is a separate beast and it does add to development time as people have mentioned, especially if it's your first time. I think RT is pretty good once you get past the whole finding the target in MAX part.

 

-Matt J

 

I second everything Matt said here.