When to look at LabVIEW RT for your solution.

[danny_t]

I have a project and I am trying to decide if I should be considering using LabVIEW RT.

It made me realise I don’t have a firm grasp of where the boundary for transition from LV to LV RT in terms of functionality and key issues to drive such a decision.

I would love some guidance on what I should be concerning.

Maybe

  Number if sensors.

  Polling rate.

  Polling accuracies.

[Bob_Schor]

If you do a Google search for "LabVIEW Real-Time", you'll find some White Papers where NI discusses this.  Here are (some of) the major points:

• The key component of a Real-Time system is the Real-Time Operating System, i.e. "not Windows", but something that says "the RT Hardware has priority", with the goal of being "dedicated" to the RT Task, and not to such niceties as User Interface (there basically is none), I/O (ditto, including Keyboard, Mouse, and Display, not to mention disk, substituting, instead, TCP/IP).
• Real-Time means that the code runs "deterministically" (if possible) -- a Timed Loop structure will use a precise hardware clock and will slavishly try to execute the code you put inside it at the rate you specify (and will throw exceptions when it can't).
• You can make better use of multi-core processors by dedicated time-critical code to its own processor, making it really run in parallel with the rest of the RT code.
• With the Real-Time Operating System comes Real-Time software, for which there is a "learning curve", not too severe, but experience with LabVIEW (and a good mentor, if possible) is preferable -- you will be working with two processors (the Host code running on a PC, which provides the User Interface and storage, and the Target hardware running the Real-Time OS and executing the Real-Time part of the LabVIEW Project you develop).
• The White Paper will show you that you'll need a different set of Hardware Modules to run LabVIEW Real-Time.  While you can purchase USB-based DAQmx modules to do A/D, D/A, Digital I/O, etc. at "reasonable rates" (multiple channels, 10s of kHz or more), getting the equivalent in a Real-Time system will require something like a PXI system or something like a CompactDAQ or CompactRIO, all of which come with the internal Processor running the Real-Time OS that you need, and connecting to your PC host through TCP/IP, not through USB.

I've over-simplified things a bit, but do a little Web searching, talk to some colleagues, maybe give NI a call (though you should remember they are interested in selling hardware).

Bob Schor

[danny_t]

Thanks for your reply Bob,

I am aware of the principles of what you have said, I did do real time programming several decades ago in C, but that was not due to timings or determinism  but due to working on embedded systems. 

I'm am looking at a fairly typical data logging system low MHz at most typical checking level for alarm type thing and something somebody said to me pushed me towards a RT solution, but my inner voice is strongly pushing  back saying I do not need that level of control for this project.

It is your second and third points, I am trying to get some real feel for. So at what point does the measurement "jitter" and multitasking provided by a modern PXI controlled running Windows, no longer, meet my requirements.

Obviously I need to do more reading.

[Bob_Schor]

Think for yourself "When will Windows (or the Network Administrator) schedule something (anti-virus scan, Windows Update, etc.)" and steal time/cycles away from your running task.  If the answer is "almost never" or "I can live with the task going offline for a few hours or a day before I notice it isn't running", then running your task under Windows (as opposed to a Real-Time OS) may be OK.  But if you need the basic task to run 24/7, 365, and can configure it to run "mostly headless" (i.e. if the Host, running Windows, dies or gets rebooted, the RT Task running in the PXI (running not Windows, but NI Real-Time Linux!) can keep running).  

To be honest, I've never understood the logic behind purchasing a fancy PXI-based system that has Windows as the OS in the controller.  Yes, you do have a fast backplane, and good clocking, but you also have Windows OS "in charge" of the System clock.  I'm not even sure if the Timed Loop can be counted on to be accurate in this situation (I'm sure someone on this Forum can set me straight on this ...).

Bob Schor