Echelon OpenLNS Commissioning Tool - Manual (Page 134)

118 Designing Networks
eliminates the need to manually move functional block, connector, and connector reference
SmartShapes to keep your OpenLNS CT drawing organized.
To align all reference connection SmartShapes in a subsystem, right-click an empty space in the
subsystem, point to Display Options, and then click Align All Reference Shapes on the shortcut
menu. This will set the Align Reference Shapes option on all the functional blocks in the subsystem
and align all the reference connection SmartShapes in the subsystem based on the settings in the
Network Properties: Functional Block options category.
To enable automatic reference connection SmartShape alignment for one or more functional blocks,
right-click the functional block (or select multiple functional blocks and right-click one of them), point
to Display Options, and then click Align Reference Shapes if it is not set. The reference connection
SmartShapes attached to the selected functional block(s) will then be aligned based on the settings in
the Network Properties: Functional Block options category.
Once the automatic alignment feature is enabled on a functional block, all attached reference
connection SmartShapes will follow the functional block when it is moved. In addition, reference
connection SmartShapes will automatically be re-aligned when you make changes your OpenLNS CT
drawing (for example, if you add or remove network variables or reference connection SmartShapes).
When this feature is disabled, the attached reference connection SmartShapes are no longer locked to
the location of the functional block SmartShape. The attached reference connection SmartShapes will
initially still move with the functional block SmartShape, but they can also be moved independently.
However, once you move a reference connection SmartShape, it will no longer follow the functional
block SmartShape.
See
4
Functional Block Options in Appendix A for customizing the automatic reference connection
SmartShape alignment feature.
Using Connection Descriptions
You can set the properties for a connection by either manually selecting a connection description or
having OpenLNS CT automatically select a connection description.
Connection Description Properties
A connection description is a set of properties, namely the message service type and addressing mode,
that apply to a network variable connection. The message service type determines how network
variable updates (messages) are delivered and verified. The addressing mode determines how a
message packet travels over the network. There are three main message service types: acknowledged,
repeated, and unacknowledged. Addressing modes include subnet/node ID for unicast connections,
and alias, broadcast, or group for multicast (fan-out) connections.
Message Service Type
You can specify one of the following message service types for each connection description. The
message service types vary in reliability and resources consumed.
• Acknowledged. The sending device expects to receive confirmation from the receiving device or
devices that a network variable update was delivered. The sending application is notified when an
update fails, but it is up to the developer of the sending device to handle the notification in the
device application. While acknowledged service is very reliable, it can create excessive message
traffic, especially for large fan-out or polled fan-in connections. When acknowledged messaging
is used, every receiving device has to return an acknowledgment. Acknowledged messaging can
be used with up to 63 receiving devices, but an acknowledged message to 63 devices generates at
least 63 acknowledgements—more if any retries are required due to lost acknowledgements.
• Repeated. The sending device sends out a series of network variable updates, but does not expect
any confirmation from the receiving device. Repeated service with three repeats has a 99.999%
success rate in delivering messages. Repeated service provides the same probability of message
delivery as acknowledged messaging with the same number of retries, with significantly lower