User manual

Publication CNET-UM001C-EN-P - November 2005
6-4 Peer-to-Peer Messaging
Guidelines for MSG
Instructions
This table describes guidelines to use when working with message instructions.
Table 6.1 Guidelines for MSG Instructions
For more information on programming MSG instructions, refer to the
Logix5000 Controller General Instructions Reference Manual, publication
1756-RM003. The individual system user manuals for Logix5000 controllers
also provide MSG examples unique to specific controller platforms.
Guideline Details
1. For each MSG instruction, create a
control tag.
Each MSG instruction requires its own control tag. This tag contains control elements
for messages, for example: DN and EN, error codes and information to execute the
message such as destination path and number of words to transfer.
• Data type = MESSAGE
• Scope = controller
• The tag cannot be part of an array or a user-defined data type.
2. Keep the source and/or destination data
at the controller scope.
A MSG instruction can access only tags that are in the Controller Tags folder (controller
scope).
3. If your MSG is to a module that uses
16-bit integers, use a buffer of INTs in
the MSG and DINTs throughout the
project.
If your message is to a module that uses 16-bit integers, such as a PLC-5® or SLC 500™
controller, and it transfers integers (not REALs), use a buffer of INTs in the message and
DINTs throughout the project.
This increases the efficiency of your project because Logix5000 controllers execute
more efficiently and use less memory when working with 32-bit integers (DINTs).
4. If you want to enable more than 16
MSGs at one time, use some type of
management strategy.
If you enable more than 16 MSGs at one time, some MSG instructions may experience
delays in entering the queue. To guarantee the execution of each message, use one of
these options:
• Enable each message in sequence.
• Enable the messages in smaller groups.
• Program a message to communicate with multiple modules.
• Program logic to coordinate the execution of messages.
5. Cache the connected MSGs that
execute most frequently.
Cache the connection for those MSG instructions that execute most frequently, up to
the maximum number permissible for your controller revision.
This optimizes execution time because the controller does not have to open a
connection each time the message executes.
6. Keep the number of unconnected and
uncached MSGs less than the number
of unconnected buffers.
The controller can have 10 - 40 unconnected outgoing buffers. The default number is 10.
• If all the unconnected buffers are in use when an instruction leaves the message
queue, the instruction errors and does not transfer the data.
• You can increase the number of unconnected buffers to a maximum of 40.