Hardware Architecture: cDAQ vs cRIO

[Alexander_By]

I need to build RELIABLE system for fairly slow processes (cycle lop time about 0.5 seconds, total of ~100 I/O channels)

Windows LabView with cDAQ is not reliable enough, sometimes the computer kicks out ant loses communication with cDAQ. 

Window LabView is not considered as industrial application.

I have two types of architecture in mind:

1. Linux computer with cDAQ

2. cRIO based system with FPGA and RT

I repeat, that fast operation and low latency which is provided by RT FPGA is not required

Does anybody has experience and opinion on the architecture? Is cRIO with RT FPGA more reliable than Linux LabView with cDAQ in terms of operation stability?

[crossrulz]

What exactly is your application doing?  Simple data acquisition?  Control loops?

If it is a simple data acquisition, I would lean towards the cDAQ.  If there is control involved, I would go with a cRIO.

[Alexander_By]

The data processing is not complicated. I have about 30 Analog Input signals(Voltage) and about 30 temperature gauges, based on  these data, the control program sends control signals to about 5-6 DACs and about 60 Digital Output channels. The whole loop takes about 0.5 seconds. The system worked well under Windows LabView and cDAQ modules, except instability caused by loosing communication (IP addresses) between computer and cDAQs

As I understand, programming of FPGA and program debugging is way more complicated that using LabView with Linux Computer and cDAQs. And I hope that Linux will not experience these problems with loosing IP addresses.

Why you say taht if I need control lops, then cRIO is better than cDAQ?

[crossrulz]

Control loops add additional reliability requirements.  So if reliability is your main concern, I would go with a cRIO.  Even with a cRIO, you do not have to use FPGA.  You can use the Scan Engine to get your data (500ms loop rate is an eternity, so no issues there).  If you use a modern cRIO (904X or 905X series controllers), you can even use DAQmx (I have not done this yet).  So don't let the FPGA scare you.

And all current cRIO controllers, even the "Mature" ones, use Linux RT, just in case you care about that.

[Alexander_By]

Is it correct, that FPGA  and RT is required if I need very fast data streams?

Why do I need to switch from cDAQ to cRIO if I need control loops? Is cDAQ non-reliable?

I need to use several (2 or 3) cDAQ or cRIO modules and some master control device which will make global control and GUI interface for the whole system. Is it correct, that in case of using 3 cRIOs this may be one of the cRIOs with Linux RT? Or I need to use separate PC with Linux OS connected to the cRIOs? With cDAQs this looks clear: Linux computer connected to cDAQs and the program is on this computer. Switching to cRIO may take significant time, and the team does not have experience working with cRIOs but has with cDAQ under Windows LabView. I need to minimize the development time. Learning cRIO programming may become a bottleneck. 

What kind of non-reliability may be on cDAQs used for control loop?  So far I had only communication problems with Windows (loosing IP addresses, when computer and all cDAQs were connected through Gigabit Switch). Do you have in mind something different when you recommend switching o cRIOs for the control loops?

[crossrulz]

---

@Alexander_By wrote:

Is it correct, that FPGA  and RT is required if I need very fast data streams?

---

I don't know what the capabilities as far as data rate for DAQmx on cRIO are.  In the past, you did require FPGA for fast data streams.

---

@Alexander_By wrote:

I need to use several (2 or 3) cDAQ or cRIO modules and some master control device which will make global control and GUI interface for the whole system. Is it correct, that in case of using 3 cRIOs this may be one of the cRIOs with Linux RT? Or I need to use separate PC with Linux OS connected to the cRIOs? With cDAQs this looks clear: Linux computer connected to cDAQs and the program is on this computer.

---

Whether you are using cDAQ or cRIO, you will want to use a single chassis to hold your modules.

What I typically do with a cRIO is have the FPGA handle the control stuff, RT handle local file I/O and communications, and then a separate PC to communicate with the cRIO and act as a GUI.  I do this for reliability reasons.  The FPGA will have the highest reliability, followed by the RT, and finally the PC.  If the PC decides to reboot or stall for whatever reason or the network goes down, the cRIO is still doing its thing.  When the PC comes back up, it can connect with the cRIO again and pick up wherever the cRIO is.

---

@Alexander_By wrote:

Switching to cRIO may take significant time, and the team does not have experience working with cRIOs but has with cDAQ under Windows LabView. I need to minimize the development time. Learning cRIO programming may become a bottleneck. 

---

RT is mostly still normal LabVIEW.  Based on what you have stated, I would not worry about the FPGA (which is a different animal).  Just use the DAQmx on cRIO and most of your code should just port over.  You will want to add a communications loop so that the cRIO can communicate with whatever you want to use for a GUI.