cRIO v/s cDAQ

[Lovie631]

When you say cRIO is more deterministic, what does that actually mean for a real-world application? How can I determine if my application needs FPGA determinism or will cDAQ real-time be sufficient? 

We are looking to develop an application for a dynamometer type test bench.  Automated control, high speed acquisition and safety are required - cRIO? But we also need to develop the system so that it is simple and can be easily configured with different hardware by a technician with limited LabVIEW experience - cDAQ & DAQmx? What physical aspect of my system do I need to consider to determine where cDAQ no longer becomes an option? 

I have little experience of LabVIEW myself, but i'm trying to understand the big picture so i can better help a developer to deliver our requirement.

[crossrulz]

In my experience, anything on a safety level should be in the FPGA since it is the least likely spot to have runtime issues (ie the OS crashes, memory issues, etc).  But NI does now have modules with safety regulations in them.  I have not dived into them to see their specs.

Being configurable is typically just being able to set the right settings where you need to.  What I have done for this is have a PC application that can send the settings to the RT via a TCP connection.  The RT can store the settings (to reapply on bootup) and pass them on to the FPGA.

[Hooovahh]

It isn't a bad reaction to say IF "Safety" THEN "use FPGA".  If you are thinking of your safety systems, and are okay with it behaving like Windows but a little better, than RT might be all you need (I'm having a hard time coming up with a better example).  If you think of your system and want it to behave more like an IC or a set of mechanical hardware, than FPGA is probably what you want.  RT can still crash, or get stuck doing something eating up your resources, it is just much less likely to than Windows but it can happen.  RT is running a full operating system as overhead, and is doing all kinds of OS type things at the same time as your LabVIEW program.  But an FPGA really is like an IC with hardware doing things, and nothing else.  But at the same time can you interact with an ethernet controlled device with a set of mechanical hardware?  Maybe but you wouldn't want to.  RT can do that easily.

[Lovie631]

Thanks for your responses, so for a system like mine the decision to go with  cDAQ (RT) or cRIO (FPGA) comes down to the required level of controller reliability? Both RT & FPGA are deterministic and should be able to run the system, but there is a risk of the real-time OS on the cDAQ crashing/hanging up. 

If that's the case, can the cDAQ be configured so that in the event of a crash it will reboot into a safe mode? Could a supervisory program on a host PC detect and trigger this? 

[crossrulz]

---

@Lovie631 wrote:

If that's the case, can the cDAQ be configured so that in the event of a crash it will reboot into a safe mode? Could a supervisory program on a host PC detect and trigger this? 

---

Again, NI now has C series modules geared to safety.  You can somehow program them to perform specific actions in given failure modes.  I have no clue on the specifications nor price.  I recommend you give your local NI rep a call and discuss your exact situation.