User manual

Publication CNET-UM001C-EN-P - November 2005
Peer-to-Peer Messaging 6-5
Determine Connections for
Messages
Messages transfer data to other modules, such as other controllers, I/O
modules or operator interfaces. Each message uses one connection, regardless
of how many modules are in the message path. To conserve connections, you
can configure one message to read from or write to multiple modules. Also,
you configure multiple messages for the same path and use only 1 connection
if only 1 message is active at a time; however, this requires that you write your
ladder logic correctly to make sure only 1 message is active at any time.
These connected messages can leave the connection open (cache) or close the
connection when the message is done transmitting. The following table shows
which messages use a connection and whether or not you can cache the
connection:
Table 6.2 Message Connections and Communication Methods
Guidelines for Caching Message Connections
Follow these guidelines when you consider whether to cache a connection or
not:
Table 6.3 Caching Guidelines
This Type of Message Using this
Communication Method
Uses a
Connection
CIP data table read or write CIP yes
PLC2, PLC3, PLC5, or SLC (all types) CIP no
CIP with Source ID no
DH+ yes
CIP generic CIP
your choice
(1)
(1)
You can connect CIP generic messages, but for most applications we recommend you leave CIP generic
messages unconnected.
block-transfer read or write na yes
If the Message
Executes
Then You Should
Repeatedly Cache the connection.
This keeps the connection open and optimizes message
completion time. Opening a connection each time the message
executes increases execution time.
Infrequently Do not cache the connection.
This closes the connection upon completion of the message,
which frees up that connection for other uses.