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 standard Advanced_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 Allen-Bradley PLC2, PLC3 Allen-Bradley PLC5, PLC5 Enhanced Allen-Bradley PLC5-250 Allen-Bradley SLC5, SLC5 Enhanced Allen-Bradley Soft5 Allen-Bradley Control Logix Address Validation Channel Level Redundancy Foreground / Background Scan Rates Immediate Tag Write Feedback Measuring Network Performance More than 4 Configured Networks Node Level Redundancy Optimized Writes (Pokes) RSWho Browse Unsolicited Messaging Direct Node YES YES NO YES YES NO YES YES YES YES NO NO YES YES* YES NO DDE Node YES* YES YES YES YES YES NO NO NO NO YES YES YES YES NO YES OPC Node YES* YES YES YES YES YES NO NO NO NO YES YES YES YES NO YES

*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 AllenBradley 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 ControlNet NO DF1 Half NO Duplex DH NO DH+ NO DH485 NO TCP/IP NO TCP/IP NO Bridge PLC2 PLC3 NO YES YES YES NO NO YES NO YES YES YES NO NO YES PLC5/250 PLC5 NO NO NO NO NO NO NO* NO YES NO YES NO YES YES PLC5 Enhanced YES YES NO YES NO YES YES SLC500 SLC500
Enhanced

NO YES YES NO YES NO NO

NO YES YES YES YES YES YES

Soft Logix5 NO NO NO NO 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.

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 equivalent functionality 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 Node definition. 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.

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 updated every 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 an acknowledgement 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):

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.