I used cRIO 9024 and cRIO 9113 in my last project. All of control system was in FPGA. The host was only responsible of doing some mathematical calculations (counting cycle, last stroke, etc.), displaying sensor values (displacement, force) and controlling some situations, not so risky.
The first try was to communicate RT host with FPGA and then communicate RT host to PC host over ethernet (i.e., I used shared variable topology.). The first method was useless because there were 120 shared variables. It was much slower than communicating directly PC host with FPGA. Then I've communicated PC host with FPGA directly over ethernet. This was the second method and it still works without any problem.
Anyway, I really wonder the benefits of the first method over the second method I did. Do I really need RT if all critical actions (control system) and calculations are done in FPGA? If so, what is the reason?
I like the functionality of C Series modules so I'll keep using cRIO platform but I think there is something that I miss about RT.
Solved! Go to Solution.
It sounds like you're not missing anything, it's just a question of what's appropriate for your application. Some applications, such as yours, may not need an RT component. Other applications require one. For example, if you have a control and monitoring application where the cRIO is not always in contact with a host, an RT application can log values to a file that is retrieved periodically. An RT application can provide a more flexible networking interface than a direct connection to the FPGA , such as a server that accepts multiple connections from clients written in different programming environments. In one recent project I used a cRIO to control an inkjet printer. The RT application accepted a bitmap image over TCP, stored it in memory, and transferred it over a DMA channel to the FPGA which then triggered the inkjet head synchronized to an encoder input. The main application was written in C# by other developers. The RT application implemented an agreed-upon set of TCP commands so it acted as a standalone unit, and the other developers did not need to know anything about the FPGA implementation.