CS for Real-Time Systems

Introduction

Starting with release CS-V2.10, CS is also supported on LabVIEW-RT, which is based on the real-time OS Pharlap. An overview, background information and some details are presented in the proceedings of the RT2005 conference in Stockholm. Real-time does not mean, that execution is terribly fast. Real-time only means that a system has a guaranteed and deterministic response or execution time.

Update: The realtime version for fieldpoint system has been ported to CS 3.00. However, it has been set to deprecated since there is no real user. This means, that everything required for real-time is not ported to CS 3.10 unless there will be at least one real user.

Principle

CS real-time has two different scenarios depending on the hardware platform.

1. For PXI systems with lots of memory and a fast CPU, the CS system can basically be used without changes. By default, all threads of all objects run with the same priority. It is the responsibility of the developer, to assign the required priorities to the individual threads. The connectivity to the configuration database is provided via an SQL server.
2. For Fieldpoint systems with limited RAM and CPU power, dedicated classes have been developed that are available via the CS - package "CSRealTime". Today (July 2005), the main startup-up VI of a application is "CSRealTime.CS_Start_RT_3.vi", which is part of the CSRealTime package. This VI loads all required objects.

Configuration for Fieldpoint Systems

The configuration database is implemented with ini-files. This was done to be independent of the network. For "CSRealTime.CS_Start_RT_3.vi", the ini-file is named "CSRealTime.ini". This ini-file contains the class names. Each class name is a section that contains the names of the objects as keys and a data string for each object. If the data string equals "N/A" or "", the object is disabled and will not be created. For any other data string, the object will be created and the data string passed to the constructor of the corresponding class.

Typically, each object needs configuration data provided via an object specific ini-file. The name of the ini-file then equals the data string given in the ini-file of the main VI (see above). As an example for a good naming convention, the name of the ini file of the object "MyObject" should be "MyObject.ini".

Each object of the RTBase class (or a child class) has the following entry in its ini file
[RTBaseConfig]
UseCAEObj = 0
In case UseCAEObj equals 0, no thread for event handling is created and the object remains a passive object without active code. Having no active threads is useful, if the object is only used via direct method calls on the RT target itself. Moreover, if no threads are created, objets use significantly less RAM on the RT target. If UseCAEObj equals 1, threads for event handling are created. In this case, the object can receive (and respond to) events sent by other objects. It does not matter whether the sender of the event sits on the same RT target or somewhere on the network. In case of active threads, one thread will also take care of the access mechanism. The object can be locked by another object for exclusive access.

Process/CPU Information

For publishing process and CPU information, an object of the dedicated class "RTNodeMon" can be used on the real-time system. By this, all information is published.

Notes to Developers

Connectivity to Other Nodes

Usually, the communication within CS is based on DIM. However, DIM is not supported on PharLap. Thereofore, the CS communication on LabVIEW RT uses a dedicated library which is based on DataSocket from National Instruments. In order to use the CS classes without changes, a dedicated wrapper library replaces the library implementing the LabVIEW-DIM interface, see a dedicated How-To.

How-To Run an Application

In an case, the *.ini files should be placed in the folder c:/ni-rt/STARTUP/ on the RT system. One can transfer them via FTP, ftp://NODENAME/ni-rt/STARTUP/ , where NODENAME equals the node name of the RT system.

Important: In the development system as well as in the runtime system, LabVIEW only takes care to compile and transfer those VIs to the realtime system, that are sub(sub-sub, ...)-VIs of the main VI starting the application! This means that all sub-VIs of VI-templates are neither compiled nor transferred to the real-time system. Therefore, it is recommended to use a VI CS_RT_contents_runtime.vi, which contains all sub-VIs and place that CS_RT_contents_runtime.vi in the diagram of the main VI. In order to do this, one has to create a copy NAME 1.vi for each VI template NAME.vit. That copy must be placed into the CS_RT_contents_runtime.vi together with the constructor and desctructor for each class. Each time a VI template changes, one has to re-create the copy for that VI template.

This behaviour of LabVIEW RT shows up with LabVIEW 7.1. Hopefully, this will improve with future versions of LabVIEW.

Development System

• All VI templates (*.vit) have to be transferred to c:/ni-rt/STARTUP/ on the RT system via FTP.

Runtime System

• All VI templates (*.vit) have to be included as "dynamic" VIs in the build script of the application builder.
• In order to save memory, one can remove the CLASSNAME.constructor.vis from the CS_RT_contents_runtime.vi (RT Systems are restarted or switched off, but never shut-down)

-- DietrichBeck - 27 Jun 2006