How to Communicate with RT while Runing in RTOS

[Lux]

Please Post me::
I am trying to read the data from the AI read Vi in the DAQ which is runing in the LabviewRT target on RTOS .For this requirement I m trying the TCP/IP and VI Server in the Labview examples.

The problem is , in the examples on Client Programming algorithm is reading the server names and trying to open the reference of Exproted VIs in the server memory and runing that VI using Call by Reference Node.

But the AI Read.VI is already Runing so I don’t want to run it by call by reference mode.

For me requirement is , from Remote PC (host) i want to read the data of AI read .VI runing in the RT Target and write the read data to the file in the Remote PC using the above example.

If soluti
on is not possible using the VI server example, please suggest a solution for my requirement.

I want to Confirm :: As my Application System is giving nearby 3Mb of data per second this TCP/IP Mode of communication will miss the data that shoule be written to the file.

By
Lux.

[Chad_H]

Lux,

You will need to use multithreading. Perform you Data Acquisition in a time critical VI and the TCP in a normal priority VI. Communicate the data from the time critical VI to the normal priority VI using the RT FIFOs.

To find out if you will have enough network bandwidth, run the netbench.llb utility in parallel with your data acquisition code (put DAQ at time critical priority). This will show you the maximum transfer rate achievable while running your code. If you do not have enough speed, you may want to consider upgrading to LabVIEW Real-Time 6.1. The network performance has been enhanced. For instance, running just TCP
on a 700 MHz controller with LabVIEW Real-Time 6.0.3, and nothing else, 864 kB/second is achievable with a wait (sleep) of 1ms, and a payload of 1024 bytes per write. With LabVIEW Real-Time 6.1, 980.2 kB/s is achievable with a payload of 2048 bytes and no wait (sleep). Obviously, these are upper limits, as additional code will slow these rates down. You may also consider using a faster controller, such as the 1.26 GHz controller.