I am trying to determine whether cDAQ or cRIO would be better to measure strain gauge, temperature (thermocouple), and accelerometer data from devices placed on a Formula SAE vehicle. Currently, I have both chassis (cDAQ and cRIO), as well as, all the modules needed (9237, 9213, and 9234) for the measuring devices. My concern comes from not having very much experience in determining which system is better in terms of counters/triggers, output, and device management. Also, where gathered data is stored and if a computer is always needed to be connected, etc. If anyone would be willing to share their experiences with either chassis in a similar senario that would be great.
If all you are doing is taking measurements and no control is really needed, use cDAQ. Yes, you will need to have a computer attached to it in some way, but it keeps everything simple. Now if you are trying to do some interesting control algorithms where time is critical, go with the cRIO.
cDAQ uses DAQmx. cRIO uses LabVIEW RT and FPGA.
Yeah cDAQ is super simple compared to cRIO. cDAQ is basically a dummy DAQ device that just does what a connected host PC tells it to. A cRIO is an independent Real-Time and FPGA beast. That means you may need to write 3 separate applications. One for the FPGA, one for the Real-Time, and one for the Windows host. But the Windows host could be optional because it can run headless, and actually the FPGA can be optional if you are okay with the slower scan engine.
The benefit of course is now a cRIO has smarts attached to it and can do things in real-time. On board logging can be done easily. Several have built in serial ports to talk to other devices like power supplies. If your needs are just take measurements, and you don't mind having a PC attached, go cDAQ, if you must have a headless task, or need real-time control, go cRIO.
What's the differences between a cRIO and a cDAQ with real-time?
cRIO has an FPGA backplane for controlling the modules. cDAQ, even with the RT, still uses DAQmx. But I find that the cDAQ controllers with RT are really expensive and you might as well get a cRIO.
Thanks for the response. We are actually getting a cDAQ with Windows. The system needs to be running headless but the end user needs to be able to plug a laptop and see the live data and pull files.
I am new to the smart cDAQs but my initial thought was to utilize the web publishing tools to push the UI and FTP for the user to get the the stored files.
I was also hoping they could customize the Tasks and scales on a remote desktop and push that to the cDAQ with window but I need to look into that.
What you described could be done with both cDAQ with Windows, or cRIO. But yeah it might be easier to work with familiar tools in Windows. Sending over a MAX config export over FTP then telling the chassis to restart DAQ using the new settings would probably be easier than doing the same on RT. I think both systems would support data dashboard, but there are tons of other technologies for publishing data to a web page, or another LabVIEW application running on the laptop. Many options, and you'll probably want to play around and see what you like.
I have not used cDAQ with RT but am considering one vs going with cRIO and came across this thread.
Seems like a benefit to using cDAQ with RT is that you do not need to buy a LabVIEW RT license. And if you have a DAQmx application that needs RT, there may be less changes to the software architecture.
Seems like a benefit to using cDAQ with RT is that you do not need to buy a LabVIEW RT license.
Where did you get that information from? I still need an RT development license to be able to deploy real time applications to the cDAQ with Linux RT. The benefit of the cDAQ over the cRIO is that it is cheaper (no FPGA), it can be easier to program for if you have no FPGA experience, since it uses DAQmx which is the first real API LabVIEW programmers likely learn.
Programming for it is still like a cRIO in that you add the target to your project, and code is compiles downloaded. It can then be set to run on startup and run headless (or with monitor keyboard and mouse with the embedded HMI)
But you are right that applications already written for Windows can likely be ported with hopefully minimal changes.
My mistake. The documents, IMHO are not direct about it:
Found this zip file (with three PDFs) on NI's website, could not find the link again.