General CRIO question

[rscott9399]

So i have a CRIO at the moment. 

I have seen a few example projects built. 

My question is general in nature. 

There are 3 pieces to this thing. The host, the FPGA and the Real Time.

 

Can someone help me out with some guidelines as to what type of tasks should be assigned to each of these 3 pieces. 

I understand the FPGA handles the IO.

However, the division of labor between the RT and the host is somewhat hazy. 

Thanks in advance. 

 

 

[MarkCG]

All I/O goes through the FPGA, and you can program a cRIO with both a program running on cRIO real time processor and one on the FPGA (also called a "personality") . You do not however HAVE to explicitly program the FPGA. You can use the "scan engine" if all you want to do is read and write I/O at a rate up to 500 Hz or so. All your program logic can be done in a LabVIEW program running on the real time processor. 

Where the FPGA comes in is when you need to do things at high speed, or with very high timing precision . For example, you want multiple PID loop controllers that run at 10 kHz, reading an analog input as the process data and outputting the control signal on an analog output or as PWM signal. You can do this on the FPGA-- you wouldn't be that fast otherwise. That or doing things like responding to digital triggers to perform some action within microseconds, things that generally require you to access I/Os on the in microseconds. You can also use the FPGA built in digital signal processors to do things like fourier transforms of data coming in and a whole myriad of other signal processing things that's contained in the Xilinx IP that you can access on some cRIOs.

You are more limited in the datatypes and functions you can use on the FPGA-- typically you do things in LabVIEW fpga code you would not do in normal LabVIEW.

On the real-time side of the cRIO, you can do pretty much anything you do on a normal computer with far fewer limitations-- you have access to the internet, serial communication to instruments, all the various math and analysis VIs, pretty much anything except UI related things (unless you have cRIO with a display port)

The host is generally just the thing you use as a user interface. PC, tablet, phone, what have you. Typically the cRIO has the machine's logic built into its real time program, and the "host" sends commands or makes requests of it to do something via TCP/IP, network streams, or even UDP. The cRIO handles those requests and then lets the host know whether it can do them and whether it did or not. 

 

 

Edited April 30, 2019 by MarkCG

[smithd]

This is a good guide to look through: https://www.ni.com/en-us/shop/compactrio/compactrio-developers-guide.html

Mark mostly covered it, the way I'd think about it:

Default -> run on host

Does my code protect human beings -> generally don't use NI products* and don't even touch the application unless you know what you're doing (*exception is maybe the SIL module but even then I'd want an experienced safety person consulting)

To move to the compactRIO you want one or both of these to be true:

• Does my code need to run 24/7 headlessly
• Does my code need to operate in a moderately precise (~100 usec) time frame

To push the code from RT down to FPGA you want one of these to be true:

• Does my code protect a mechanical system (eg look for voltage to go past limit, open relay)
• Does my code need to close a loop in a precise (>25 ns variation) time frame (eg motor control)
• Does my code analyze a large amount of data that my RT CPU is unable to keep up with, AND
  • Does my code analyze data in such a way that otherwise wasted time (eg time between samples of an ADC chip) can be effectively utilized (eg performing a filtering operation on each sample)
  • Does my code analyze data in such a way that a large amount of data can be compressed to a small amount of data (eg integrate a curve after a trigger, or find peak and valley of a waveform)

The reason that last one is an AND is that if you can't pretty easily pick up the slack on the FPGA by seriously reducing the data rate or doing a lot of work in otherwise 'idle' time, its probably cheaper to just buy better hardware. Theres a limit to this of course, but...

[rscott9399]

Thanks for the replies

I appreciate the help

 

[hooovahh]

Oh and lets not forget that some cRIOs now support DAQmx so programming the FPGA part is even more optional.

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019PUNSA2&l=en-US

Some times I find myself changing what things I want to be done where.  I might start with an idea that certain tasks will be on RT and others on the Windows host, but as time goes on I realize my decision might not have been ideal.  I guess what I'm saying is whatever you do, make sure you let your design be flexible enough, that a total rewrite isn't needed if some part of your software needs to be done on a different target than first intended.

[Jordan Kuehn]

21 hours ago, hooovahh said:

Oh and lets not forget that some cRIOs now support DAQmx so programming the FPGA part is even more optional.

From my limited testing the cRIO DAQmx support is fairly limited in speed. Perhaps it will improve, but it did not fit the intended application like I had hoped. By all means give it a try though if you have the hardware for it and I'll still consider it for future applications myself.

On 4/30/2019 at 8:33 PM, smithd said:

Default -> run on host

/...

To move to the compactRIO you want one or both of these to be true:

/...

To push the code from RT down to FPGA you want one of these to be true:

/...

Very good points. Another thing I'll mention to customers is that each layer down involves a significant additional software component (aka $$). Not only is the FPGA a different beast (despite improvements over the years) compilation time and iterative development is slow. Like smithd mentioned, it can often be better to spend the money on hardware if applicable.

[rscott9399]

Thanks for all the replies

Generally speaking is DAQMX software or hardware?

I seem to find references to both?

[smithd]

daqmx is a driver that supports all of NI's standalone daq cards as well as cdaq devices and now the newest generation of crio

[rscott9399]

Ok so this allows Cdaw devices to run on the CRIO then as i understand it?

[Tim_S]

5 hours ago, rscott9399 said:

Ok so this allows Cdaw devices to run on the CRIO then as i understand it?

Sorta. DAQmx is the software interface the same way a print driver (software) is the interface to a printer (hardware).

[rscott9399]

Thanks for the info Tim

[viSci]

Curious to know more about the performance issues you were seeing with DAQmx on the cRIO.  I would think it should be fairly high performance.