Connecting the LabVIEW DSC Module Engine to a Real-Time Controller

The LabVIEW Datalogging and Supervisory Control Module is the ideal tool for your high-channel count and distributed applications. It offers easy-to-use I/O configuration tools for high-channel count applications, data logging, alarm and event management, and trending.
LabVIEW Real-Time extends LabVIEW graphical programming to create applications with deterministic, real-time performance. You can develop and debug your application using familiar LabVIEW graphical programming on Windows, and then download that time-critical code to run embedded on RT Series hardware.



There are a few possible ways to architect the whole system, and each of them provides different throughput and complexity. Two of the methods provide direct connectivity from Real-Time code to the LabVIEW DSC Module engine, which makes them great candidates for recommended architectures. The first method uses DataSocket native protocol (DSTP) to connect to the engine; the second one uses Logos protocol. Both methods differ in architecture and throughput.

Method 1: Using DataSocket Native Protocol (DSTP)

The LabVIEW DSC engine can act as a DataSocket client. Your RT code running on the RT controller can also act as a DataSocket client. They both can communicate through the DataSocket Server. The complete configuration is shown in the following picture:




Method 2: Using Logos Protocol

The LabVIEW DSC engine can act as a Logos server. RT code running on the RT controller can also act as a Logos client. This allows you to connect the RT code directly to the LabVIEW DSC engine, without the need for an extra application in the middle. The complete configuration is shown in the following picture:



Comparison of the Suggested Methods

The differences between the two methods are as follows:

1. Complexity
   The first method has to have an extra application running, the DataSocket Server. This is generally considered as a disadvantage. It consumes extra memory and adds more overhead.

2. Limitation of Used Tag Types
   Both methods use different tag types. There are some disadvantages on both sides. The first methods uses the LabVIEW DSC engine as a client that connects to DataSocket Server. The engine tags are created as Input or Output tags. The second method uses the engine as a Logos server. It is the RT Controller that connects to the engine, not the engine to the controller. Therefore the tags are created as memory tags, not I/O tags.

   Note 1: The items within the DS Server can be either predefined or created dynamically. The advantage of the predefined items is that multiple clients can write to them. This makes them 'both-way' items, read/write on both sides. By default each item can only be written by one client -> RT code writes, DSC reads or vice versa. If you want both peers to write and read an item, then you have to predefine the item and mark it with 'Allow Multiple Writers'. The disadvantage is that you have to manually define them. You can predefine them via DataSocket Server Manager: Start » Programs » National Instruments » DataSocket » DataSocket Server Manager.
   In case of dynamically created items - these are created on the first access - no configuration is required.

   Bottom line: the DataSocket connection can be only one-way, unless you predefine the items with 'Allow Multiple Writers'. However, this adds to maintenance, since you have to keep the tag configuration in two places - DS Server and DSC manager.

   Note 2: There is one disadvantage of memory tags against I/O tags. The memory tags don't support scaling. There is a good reason for that. Assume there is a memory tag with scaling that is supposed to multiply the value by 2. If you write, for example, value 3.14 into the tag it would be scaled by 2. The subsequent reads would get 6.28 from the tag. This means this single tag contains two values: 3.14 and 6.28.
   Note that this conflict does not apply for I/O tags even if they support scaling.
   In case you need to scale a value, you can either do it in the RT code and write the scaled value to the engine, or you can create an extra tag that will contain the scaled value. The scaling then has to be handled programmatically.

   Bottom line: if you need to use scaling in the Logos method, you need to work around it.

3. Overhead and Throughput
   Due to the fact the DataSocket native protocol architecture uses an extra node (the DS Server), but also because of the implementation of both protocols, the DSTP approach has higher overhead and lower throughput. Simple tests show the Logos throughput is about 50%-100% higher.

   With RT controller processor speed 1.3GHz and host computer (running DSC) 800MHz ,the throughput for 100 items written by the RT code to the engine was higher than 1000 total updates/sec (= 10 updates/sec/channel) for Logos protocol. All tags were logged to the Citadel historical database. The CPU usage on the LabVIEW DSC side was about 35%. RT controllers don't provide a tool to measure the CPU usage on the RT box; however, the same code running on a Windows OS showed fairly low CPU usage. No other code was executed on RT or LabVIEW DSC machines at the time of the test.
   When the number of items was increased to 500, the total number of updates went up to more than 2500 updates/sec, while the number of updates per channel went down to 5 updates/sec/channel. Due to the heavier load the total CPU usage went up to 100% on the LabVIEW DSC side, mostly consumed by the engine.

   These simple tests show the maximum throughput was limited by the CPU usage on the LabVIEW DSC machine. For an 800 MHz LabVIEW DSC machine, the reasonable throughput is around 1000 updates/sec. The number can be increased by faster processor speed; however, it is going to be decreased by additional code that is likely to be executed on the LabVIEW DSC machine. In case you need to achieve higher throughput, you might consider running multiple LabVIEW DSC stations each handling a portion of the total number of tags.
   The RT code for this test was comprised of a VI running a loop. The loop wrote a new value to all tags each iteration. The period of the loop was controlled by Wait Until Next ms Multiple and was set to 50ms.

Conclusions

For the above outlined reasons the Logos connections to memory tags (the second configuration) is the recommended method to connect the RT Controllers to LabVIEW DSC. It has higher throughput, lower overhead, and simpler configuration. The only disadvantage is lack of scaling for the memory tags.

Implementation

LabVIEW DSC Machine
Open the Tag Configuration Editor and create a memory tag (Edit>>Create>>Analog Tag). Make sure the Tag Access in the Connection tab is set to Memory. Once you have created the tag, you can save the configuration and start the LabVIEW DSC engine. To verify the engine is successfully running, open the Tag Monitor. Browse to the tag and add it to the view. Leave the utility open.


[+] Enlarge Image


LabVIEW RT Machine
You have to use the DataSocket primitives on the RT target. For example, the following VI sample writes the loop index to the LabVIEW DSC memory tag:



Shortly after you send this VI to the target, you should notice that the value in the Tag Monitor increments.

Tip: The easiest way to generate series of LabVIEW DSC tags that slightly differ is to use Excel. Refer to the Editing Tags Using a Spreadsheet Program topic in the LabVIEW DSC online help.

Reader Comments | Submit a comment »

downloadable examples of how to set up both logos and data socket servers would really complete the article. :-.
- terry bell, camh. terry.bell@camhpet.ca - Dec 7, 2004