rsview32 data source options

7/27/2019 RSView32 Data Source Options

1/5

RSView32 Data Source Options

Direct, DDE, and OPC - Understanding the Differences

Background:

RSView32 provides 3 different ways to configure communications. This technote describes the differences

between the Direct node (available for Allen-Bradley devices only) the DDE node and the OPC node

definition. The comparison uses RSLinx in all 3 instances. RSLinx as a DDE or OPC server provides for

much of the same functionality. This is because the RSLinx OPC server also uses the configured topic

information for communication. When another 3rd party DDE or OPC server is being used, that server may

not have implemented the same set of features described here; or it may have implemented the same feature

in another way. For example, not all OPC servers use DDE topic configuration settings.

Definitions:

Direct Node - Legacy connection for Allen-Bradley devices. It is selected by default in the Node editor. The

Direct node uses a C-API interface to communicate with RSLinx, instead of the more standardAdvanced_DDE or OPC. The Direct Node interface requires RSView to build packets, and manage packet

optimization, (normally this is done within RSLinx).

DDE Node - The DDE Node is the second choice in the Node editor. A DDE Node supports Advanced_DDE

and CF-Text. RSView can serve DDE to Excel using XL-Table format, but RSView is not an XL-Table DDE

Client. DDE Nodes do not support the WonderWare Fast DDE protocol.

OPC Node - The OPC Node type is the newest addition to the Node types, and so it appears as the last

selection in the node editor. The OPC node is the preferred node type and is continually being enhanced with

each new release of RSView32. For example, in the 6.2 release of RSView32, the OPC Node will support

server address browsing. Of course the way the server address browse will work depends largely on the

OPC server implementation of this feature.

The following table lists each main feature and indicates which type of node configuration supports the

feature. Each feature is described in more detail later in this document.

Feature Direct Node DDE Node OPC Node

Allen-Bradley PLC2, PLC3 YES YES* YES*

Allen-Bradley PLC5, PLC5 Enhanced YES YES YES

Allen-Bradley PLC5-250 NO YES YES

Allen-Bradley SLC5, SLC5 Enhanced YES YES YES

Allen-Bradley Soft5 YES YES YES

Allen-Bradley Control Logix NO YES YES

Address Validation YES NO NO

Channel Level Redundancy YES NO NOForeground / Background Scan Rates YES NO NO

Immediate Tag Write Feedback YES NO NO

Measuring Network Performance NO YES YES

More than 4 Configured Networks NO YES YES

Node Level Redundancy YES YES YES

Optimized Writes (Pokes) YES* YES YES

RSWho Browse YES NO NO

Unsolicited Messaging NO YES YES


2/5

*Allen-Bradley PLC2, PLC3:

RSView32 fully supports these legacy devices on DH through the Direct Node. When using DDE or OPC

topics it is not possible to build a path to the device in RSWho, unless bridging the DH network through a

1775KA module, or through a serial connection from the PC. When using a KF2 module not all DH station

numbers are available through RSWho. Therefore the Direct node is the "preferred" type of connection for

the PLC2 and PLC3.

*Optimized Writes:

RSView32 6.20.49 & later supports optimized writes using the direct node type.

Allen-Bradley Device Support

The Direct Node provides support for the PLC2, PLC3, PLC5, and PLC5 Enhanced, SLC5 and SLC5

Enhanced, and the Soft5 processors. The Control Logix 5550 and Control Logix Gateway are NOT

supported by the Direct Node and require a DDE or OPC node configuration to communicate. DDE and OPC

can be used to communicate to any Allen-Bradley processor. The following table illustrates which Allen-

Bradley devices are supported on the various networks as Direct Nodes. Any combination not listed should

be verified as a valid combination and will need to use OPC or DDE to communicate.

Channel

Type

Control

Logix

PLC2 PLC3 PLC5/250 PLC5 PLC5

Enhanced

SLC500 SLC500

Enhanced

Soft

Logix5

ControlNet NO NO NO NO NO YES NO NO NO

DF1 Half

Duplex

NO YES YES NO YES YES YES YES NO

DH NO YES YES NO NO NO YES YES NO

DH+ NO YES YES NO YES YES NO YES NO

DH485 NO NO NO NO NO NO YES YES NO

TCP/IP NO NO NO NO YES YES NO YES YES

TCP/IP

Bridge

NO YES YES NO* YES YES NO YES NO

*PLC5/250 Additional Information:

This processor is not supported as a Direct Node device. To read data table values from the PLC5/250

an OPC or DDE node must be configured. The TCP/IP Bridge channel is intended for bridging other PLC

networks such as DH or DH+ through the PLC5/250 Gateway. The ControlLogix platform also can act as

a gateway to other networks. This gateway device is not supported via TCP/IP Bridge. All ControlLogix

devices require DDE or OPC node definitions to work with RSView32.

Device Net Additional Information:

Device Net is not supported as a Direct Node network. DDE or OPC node definitions are required for

Device Net.

Address Validation:

Only the Direct Node configuration performs address validation. For example, the database editor won't allow

an analog tag to be mapped to a string data table (ST). Input and output file address offsets are validated

against the processor type selected in the node definition.


3/5

Channel Level Redundancy:

Only the Direct Node configuration provides channel level redundancy, because only the Direct Node uses a

channel configuration. A channel represents a communications card such as a KTX, KTCX or Ethernet card.

DDE and OPC nodes use the driver configuration of the DDE / OPC Server. The RSLinx server can support

more than 4 driver configurations. The Channel editor provides a Primary and a Secondary channel

selection. A channel driver can be switched during a communication error event through the use of the

DRIVERPRIMARY, DRIVERSECONDARY, and DRIVERTOGGLE commands. There is no equivalentfunctionality in DDE and OPC, redundancy is only done at the Node or Topic level.

Scanning Data - A comparison of Direct Foreground Background Scan Rates, DDE Poll rates, and

OPC Update Rates:

Example for Comparison:

For the purpose of this comparison of scan rates, consider the following example. The application requires

data at N7:0 through N7:10 to be logged every 10 minutes. Occasionally a graphic presents data at N7:11

through N7:20 to the user and needs to be updated every 5 seconds. All data falls within the same

optimized packet.

Direct Node:

Only the Direct Node implements the concept of Foreground and Background scan rates. For both OPC and

DDE, this concept does not apply. Even though all device tags are associated with a scan class (internally),

only Direct Node device tags implement scanning data at the configured rate. The scan class editor provides

a background and foreground scan rate. This background and foreground scanning mechanism allows the

application designer to specify slower and faster read data depending on the nature of the RSView32

application. Graphics, Tag Monitor and VBA code are considered Foreground and everything else (Alarming,

Datalogging, Events, Derived tags) are considered Background.

Using the Direct Node each tag would be mapped to a scan class that had a foreground rate of 5 seconds,

and a background rate of 600 seconds. When the datalog model is started, the packet is scanned every 10

minutes. When the graphic is brought up, the packet is re-optimized to include the new data, and the entire

packet is scanned every 5 seconds. When the graphic is later closed, the packet is re-optimized to remove

the unwanted screen data and returns to being scanned every 10 minutes. There is no optimized packet view

when using Direct node tags.

DDE Node:

The DDE node has an associated topic that specifies a poll rate. All DDE and OPC node tags are mapped to

Scan class A by default, but the scan rate is not used. The reason all device tags are mapped to a scan class

is to allow switching the tag configuration between node definition types. When some data needs to be read

much slower than other data in the same device, multiple topics must be configured for the various poll rates.

RSLinx will optimize the requests for data to the same device at the different poll rates as long as the data

falls into a single packet. In our example above, the application designer would create 2 topics both mapped

to the same physical device. Topic FastData has a poll rate of 5000 ms, while topic SlowData has a poll rate

of 600000 ms or 10 minutes. Each RSLinx topic would be mapped to a corresponding RSView DDE Nodedefinition. For the purpose of this discussion, we will use the same Node name as the Topic name. The

application designer must remember to link all screen data to the FastData Node / Topic, and all datalog data

to the SlowData Node / Topic.

When the datalog model is started, the RSLinx polls the optimized packet every 10 minutes. When the

graphic is brought up, RSLinx re-optimizes the packet to include the new data, polling the entire packet every

5 seconds. When the graphic is later closed, RSLinx re-optimizes the packet to remove the unwanted screen

data and returns the packet to being polled every 10 minutes. The packet re-optimization behavior can be

verified in RSLinx through the DDE/OPC Optimized Packets.


4/5

OPC Node:

The OPC node definition contains a Node Update Rate which controls how often the data is updated in

addition to the topic poll rate. For example, the topic poll rate is set to 10 minutes and the Node Update Rate

is set to 5 seconds, therefore the data is read every 5 seconds. The OPC node definition allows the

application designer to configure one topic, and many nodes for the various update rates required. The

RSLinx OPC server will always update the packet at the fastest configured rate. Therefore if the topic poll

rate is set at 5 seconds, and the Node Update Rate is set at 10 minutes, the optimized packet will be updatedevery 5 seconds.

Other than the Node Update Rate, the OPC node functions the same as the DDE node.

Conclusion:

Reading different data in the same packet at various scan or poll rates is possible with all 3 node types. Only

the Direct Node can read the same data at different rates, and the Direct Node's configuration of the different

scan rates is easier to implement than the DDE/OPC multiple node requirement.

Immediate Tag Write Feedback:

Only the Direct Node type updates the Current Value Database immediately after receiving anacknowledgement from the PLC that the write has been received. Both DDE and OPC tag writes update the

Current Value Database the next time the value is read, at the next poll interval or node update rate. The

Current Value Database is where all current tag values are stored in memory for fast runtime retrieval.

Measuring Network Performance:

Communication status information is restricted to the information provided in RSView32. None of the RSLinx

diagnostic information such as active items, optimized packets, server diagnostics, client diagnostics, or group

diagnostics apply to the Direct node. The Direct Node interface provides no performance information.

Performance comparison:

When comparing PLC network read performance, there is little or no difference between the Direct node, the

Advanced DDE node and the OPC node when both RSView and RSLinx reside in the same computer.There is a significant performance gain when using OPC instead of CF-Text DDE. As documented earlier

there is a slight single tag write performance advantage with the Direct node, as of version 6.20 there is also a

performance advantage for block downloads with the Direct node over DDE and OPC. When implementing a

project that uses Remote OPC or NetDDE, Remote OPC is more reliable and performs better than NetDDE.

More than 4 Configured Networks:

When more than 4 configured networks are required, the application designer must use DDE or OPC. The

Direct Node uses a Channel for each configured network driver in RSLinx. Each channel represents a PLC or

SLC network interface such as an ethernet card, a serial port, a KT card, etc. The Channel editor allows the

configuration of 4 primary and 4 secondary channels.

Node Level Redundancy:

Node level redundancy provides a mechanism to switch the HMI software between a primary and backup

controller. Node Level redundancy can be achieved in all 3 node types through the NodeSwitch command.

The NodeSwitch command is restricted to switching between like nodes. In other words the NodeSwitch

command can't be used to switch between Ethernet and DH+. It can only be used between devices of the

same family on the same network type. The DDE and OPC nodes can implement Node level redundancy in

RSLinx through Alias Topic configuration. For more information about this.

Optimized Writes (Pokes):


5/5

DDE / OPC topics can be configured to optimize pokes, which means data is written down in blocks instead of

one item at a time. This functionality is newly available for Direct nodes, in the 6.20.49 release of RSView32.

To optimize a block of tag writes, the server must receive the write requests in a block, and that block must be

contiguous memory in the PLC.

RSWho Browse:

The direct node allows the application designer to browse the configured network by launching the RSWho

ActiveX provided by RSLinx (Requires RSLinx 2.0 or higher). When browsing a bridged network and

selecting a device through RSWho, the software automatically builds the routing information for the driver

making the configuration task easier to implement. When using DDE and OPC, the RSWho browse is

accomplished in RSLinx. There is no corresponding browse the server for a list of all configured topics.

Therefore the application designer must remember the topic name when configuring DDE nodes. The topic

name is optional for OPC nodes, but if omitted from the node definition, it must be supplied in the tag

configuration.

Unsolicited Messages:

Unsolicited messages are not supported as Direct nodes, either DDE or OPC node definitions are required to

receive unsolicited data into RSView32 from the PLC.

rsview32 data source options

Documents