Can Standard (Non Real Time) Labview Vi's be run on a RT system such as a cRIO?

[JohnDoe159]

We have a somewhat large control system running through a compact DAQ chassis connected to a windows machine. We are interested in moving this system to a cRIO but only if the work of migrating is easy enough to do.

If the entire LabVIEW program will need to be re-written or if there are a ton of heavy modifications to make it work it would not be worth the effort to migrate. I understand we would need a LabVIEW RT module license but generally is that all that is required?

[Bob_Schor]

I seriously doubt it.  The LabVIEW Development System (that you use to create LabVIEW Programs, including support for Displays, Files, large (32-bit or 64-bit) memory models, and support for a wide variety of Hardware (including cRIOs, Real-Time OSes, Cameras, Displays, keyboards, mice, human interaction) has a very different environment from that expected by a Real-Time OS, where the watchword is "small, fast, and deterministic".

Bob Schor

[JohnDoe159]

Sorry, I'm not 100% sure what you are saying when you say you doubt it. So just to be clear, you are saying you doubt migration of a LabVIEW program from (Windows 10) cDAQ to cRIO would be simple?

[Mark_Yedinak · Accepted solution]

---

@JohnDoe159 wrote:

Sorry, I'm not 100% sure what you are saying when you say you doubt it. So just to be clear, you are saying you doubt migration of a LabVIEW program from (Windows 10) cDAQ to cRIO would be simple?

---

It would depend on how your system is currently implemented. The basic core LabVIEW runs on both systems just fine. The areas where you really run into trouble would be if your business logic (the data collection, calculations, analysis) and your UI are tihgtly coupled. The code that will be running on the cRIO should not have any UI aspects in it. If your current code is structured well it should be fairly straightforward to migrate the necessary parts to your cRIO and leave the UI aspect on the Windows machine. You will need some mechanism for transferring data but if the system is well architected that should already be in place.

Now if your code is one big mess of everything together in a few VIs and you have mixed your UI elements with your core data collection and analysis you may have a harder time migrating.

[Bob_Schor]

---

@JohnDoe159 wrote:

We have a somewhat large control system running through a compact DAQ chassis connected to a windows machine. We are interested in moving this system to a cRIO but only if the work of migrating is easy enough to do.

If the entire LabVIEW program will need to be re-written or if there are a ton of heavy modifications to make it work it would not be worth the effort to migrate. I understand we would need a LabVIEW RT module license but generally is that all that is required?

---

Hello again, John.

     I apologize for mis-understanding the question you posed, above.  I thought you wanted all of the code to be migrated to a cRIO (perhaps I was misled by your noting, in your title, the phrase "Standard (Non Real Time) LabVIEW VIs", which I interpreted to include the User Interface parts, as well).

     One of the nicest things about RT Systems, especially those like cRIOs, is that they allow you to have three processors working "co-operatively" on a single problem, with all three processors working independently, truly asynchronously (no "sharing" of CPU times) and "in parallel":

• The Host (or UI) code, written in "standard LabVIEW", runs on a PC (or Mac), to which is connected a Keyboard, Mouse, one or more Displays, local disk storage, and connections to local and remote Networks using TCP/IP.  This code is responsible for interacting with the User (the "U" in UI) and serving as the "traffic manager" for the RT System's need to access PC "assets" (such as the local Network).
• The Real-Time Target (such as a cRIO) that runs an NI Real-Time OS (such as NI Real-Time Linux), and provides access to DAQ modules such as A/D converters, Digital I/O, possibly Video capture, and communicates with the Host over a TCP/IP connection.  The RT-OS is written to provide more precise timing and/or higher reliability of software tasks.
• The third processor is the FPGA that is part of the cRIO.  This is the ultimate in "parallel processing", as you literally configure a series of Gate Arrays to do arithmetic and logical tasks running on an independent fixed clock.  This means that if you need to process an array of, say, 1000 points, instead of doing each element in (temporal) sequence, the FPGA can "wire itself" to create 1000 mini-processors that do each point simultaneously.  It has its own Communication pathways to its "hosting" RIO, including a fairly rapid parallel transmission using a built-in FIFO.

I'm currently working on such an application.  The User Interface provides the Front Panel by which the User configures the Instrument, sets up its parameters (through interaction with standard Front Panel controls), and initiates Test Sequences.  The "settings" are transferred (using Network Streams over TCP/IP) to a RIO that uses "standard LabVIEW" (I'm using a QMH-like Framework here).  The test equipment involves generating precisely-timed Pulse Trains (we use DIO lines for On/Off timing of the Pulses, and D/A Converters for Pulse Amplitudes), with A/D measurements of various points at various times relative to the Pulse Trains.  We built a special-purpose Test Chamber that uses a number of SPI-based chips to do (some of the) A/D, D/A, and DIO, as we are running multiple channels (currently 16) at once (they all run at the same time, but their output pulse amplitudes are individualized on a per-channel basis).  The FPGA handles the generation of the DIO Timing Signals, as well as providing for individual and "in-parallel" communication with multiple SPI chips across 16 channels.

Bob Schor