How is targeting an RT controller different from running natively on the controller?

[eaolson]

I am embarking on my first project to control some RT hardware, and I'm just a bit confused about how it differs from running a VI on my normal Windows PC. It seems the preferred method of running an deterministic application is to have the VI that needs to be deterministic running on the RT hardware (PXI controller in my case) all the time, and using TCP to transfer data to the host PC for display and the UI. 

So what is going on when I have a VI on my host computer and run it by targeting the RT hardware as the execution target?  I suppose there is some sort of automatic TCP communication going on, even though I didn't include anything like that in my VIs.  Is this inherently non-deterministic?

[devchander]

to put it in simplest terms, its like this

When you 'have a VI on your host computer and run it by targeting the RT hardware as the execution target', the VI will be transferred/down loaded on to the RT controller and the VI is executed by the processor on it.

Now, your Host PC will only show the front panel of that VI and will not have any role in executing the VI.

Now, even if you switch off your Host PC, the VI will still be running on your RT system

Plus this link wil help u undertnd these concepts better

http://www.ni.com/support/labview/real-time/faq.htm 

[eaolson]

I figure there must be a difference between targeting a VI to the RT hardware from a host computer and deploying it as an exe.  Otherwise, why go to all the trouble of building and using a TCP/IP messaging protocol?

When targeted from a host, the host PC displays the front panel of the VI running on the RT hardware.  Therefore, there must be some sort of communication occuring between the RT hardware and the host hardware. The communication must be taken care of "behind the scenes" by Labview, since I didn't account for it in my application.  Might this communications overhead add jitter to my application?

[Efosa O.]

Hello eaolson,

I hope all is well.

When you have an application targeted and run on an RT target from the Host PC, updating front panel controls, there is "default communication" (TCP) that is being generated.

You were absolutely correct, LabVIEW sends data back and forth using TCP and this will inherently slow down the application you have running on the RT target. However, you can get around this by having a deterministic loop where you perform all your time critical tasks and then another loop that will perform TCP to another VI that will take care of front panel updates.

For debuggable purposes, you can program your application with front panel updates, however, when you build your exe and download it to the target, only the block diagram gets downloaded to the RT target... for obvious reasons.

Efosa O.

National Instruments

[eaolson]

That's about what I expected. I see why RT programming is such an added hurdle.

[Doug M]

eaolson,

There are some good KBs that give an intro to RT Architecture -- it is somewhat more complex in that if you want the user to be able to interact with the real time portion, you need to program different loops at different priorities -- your host VI runs on Windows and communicates via some communication protocol (TCP, UDP, DataSocket, Shared Variable) to a normal priority - non-deterministic loop running on the real-time target, which then communicates to the time-critical-deterministic loop also running on the real-time target.  In previous versions of LabVIEW programming the low level TCP/IP communication between the host and normal priority loops was somewhat tedious, but in LabVIEW 8 you can leverage the power of the Shared Variable to abstract much of this away.  The Real-Time Communication Wizard is a great place to start to see how to break your program up into the 3 pieces -- it takes a VI you would normally run in LabVIEW on Windows and creates the the VIs for you using a protocol of your choice.  See the following:

Using the LabVIEW Shared Variable
Best Regards,
Doug Mumford
Applications Engineer
National Instruments