LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

cRIO v/s cDAQ

Can anybody help me out when to use cRIO system as cdaq can also be used for most of the control applications.

 

0 Kudos
Message 1 of 15
(3,992 Views)

cRIO - industrial embedded system with high resistance. Can work standalone.
cDAQ less resistance. Work with PC.

0 Kudos
Message 2 of 15
(3,974 Views)

what if we use cDAQ controller ,then can it work on standalone???

0 Kudos
Message 3 of 15
(3,966 Views)

Yes, cDAQ controller can work on standalone. But (imho) primary purpose is to use with PC.
And (the main difference) cRIO has FPGA. If you need fast (hardware strong timing) and standalone, you need cRIO. If "software" timing is enough, you can use cDAQ.

may be you can describe yous task?

0 Kudos
Message 4 of 15
(3,955 Views)

@umer777 wrote:

...as cdaq can also be used for most of the control applications.


I highly recommend AGAINST that.  cRIOs are more deterministic, making them the right tool for control situations.  cDAQs were designed for remote data acquistion (typically still attached to a PC via USB or Ethernet).  cRIOs were designed for control applications.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 5 of 15
(3,946 Views)

As stated cRIOs are likely more equipped to handle things like system controls in a way a PLC might since it has an FPGA.  That being said a cDAQ with an embedded RT OS is not a terrible choice for a control system.  It won't have the FPGA, but still can be a deterministic OS doing various things.  The real benefit of a cDAQ in my mind is it is cheaper, and you interface with hardware using DAQmx instead of through the FPGA which needs (in some cases) another application to be written.  Although NI has said they now have cRIO controllers that work with DAQmx, however this is relatively new and I don't have any experience with it.

 

cRIO - More flexible, higher cost, traditionally more development work for I/O.  Real-Time license needed (and possibly FPGA license, I can't remember)

cDAQ (real-time controller) - Easier to use, cheaper, DAQmx for I/O.  Real-Time license needed if on a Real-Time OS.

cDAQ (no controller) - Even cheaper, requires a PC to control it, not good for control systems since the host OS won't be deterministic.  Even easier to use.  No Real-Time license needed.

0 Kudos
Message 6 of 15
(3,931 Views)

@Hooovahh wrote:

cRIO - Real-Time license needed (and possibly FPGA license, I can't remember)


FPGA is only needed if you are programming the FPGA.  If you are just using the Scan Engine, you do not need FPGA.

 

As far as cost, just comparing the cRIO-9030 to the cDAQ-9132.  The only difference (other than the cRIO-9030 having the FPGA) that I found was that the cDAQ-9132 has a 16GB harddrive vs 4GB.  But price-wise, the cRIO-9030 is cheaper by ~$500.

 

In regards to that harddrive difference, I go back to my comment before: cDAQ was designed for DAQ, therefore it has the larger harddrive.  cRIO was designed for control, so FPGA for the hard timing and RT for the more loose timing (but not nearly as loose timing as Windows).


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 7 of 15
(3,925 Views)

Very good information in this thread. I wanted to add one more piece of information. NI has recently introduced a new line of CompactRIO controllers cRIO-904x, also known as CompactRIO with DAQmx. In a nutshell, you can now use DAQmx in addition to FPGA and Scan engine programming modes.

 

You can read more about it here:

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

0 Kudos
Message 8 of 15
(3,922 Views)

@crossrulz wrote: 

In regards to that harddrive difference, I go back to my comment before: cDAQ was designed for DAQ, therefore it has the larger harddrive.  cRIO was designed for control, so FPGA for the hard timing and RT for the more loose timing (but not nearly as loose timing as Windows).


This is a pretty good summary. cDAQ is a platform focusing on DAQ measurement and therefore will be more equipped to do that task.  cRIO is a platform focusing on control systems and therefore will be more equipped to do that task.  You can do controls with cDAQ but won't have an FPGA, and you can do DAQ related work on a cRIO but may have difficulties in DAQmx support, scan engine, or storage.

 

I was surprised by those prices so I looked at it a little further.  For me the price was $3,209 for both, if you get Windows embedded for cDAQ which doesn't seem like a good comparison.  The $500 difference is for Linux RT, which seems a bit steep for a semi-open source operating system.  As for differences I see cRIO has 2 serial ports cDAQ has 1. cDAQ has 2GB of RAM, cRIO has 1GB.  And as you mentioned 16GB storage versus 4GB of cRIO.  Still I didn't realize the price had dropped that much on competing cRIO hardware.  Maybe NI dropped features (like ruggedness) but when I remember researching it seemingly a year or two ago the cRIOs were always $1,000 or more than the cDAQs.

 

EDIT:  Okay I see now where cDAQ is cheaper than cRIO by a decent amount.  I wanted a 4 slot higher end RT chassis.  I went with the cDAQ-9136 with a 4 core CPU at 1.9GHz for $5,349 with Linux RT.  The only 4 slot cRIO with that CPU is a cRIO-9034 for $7,489.

0 Kudos
Message 9 of 15
(3,916 Views)

@Hooovahh wrote: but when I remember researching it seemingly a year or two ago the cRIOs were always $1,000 or more than the cDAQs.

I actually have the opposite recollection from about 2 years ago.  I had a customer come to us with a cDAQ system that some NI sales guy recommended.  We told them to ignore that and sold them a cRIO system that was half the price.  This was a control-ish application (acquire data when the PLC says to, make sure the values never go above a threshold, and indicate a pass/fail to the PLC via 24V digital lines) and I did all of the intelligence on the FPGA; RT just to store settings locally and PC just for GUI.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 10 of 15
(3,902 Views)