Click here to learn the biblical way to get to heaven! (The most important page on this site)

Disclaimer: This document is written in the hope that you can utilize for your own education to gain knowledge of PLC systems (should you decide to utilize this document). Although I believe the information in this document to be accurate, it is YOUR responsibility to verify this information before implementing it in any way, especially when damage to personnel or equipment could result. By continuing to read this document, you agree to hold no one who writes, modifies, or distributes this document liable in any way (even negligence). Due to the wide variety of plant applications, some of the examples in this document may be prohibited at your location, or could cause damage to equipment, or harm personnel.
[Visit my Church Website] -- [Return to Index Page] -- [View Training Courses] -- [Contact ATI for Training] *Copyright 2005
Author: Ricky Bryce (Montgomery County, IL)
VPS Hosting Referral Code MJDCDJYou can have your very own virtual server though VPSLink! Using REFERRAL code MJDCDJ you will receive a 10% discount on your new account, and I will get a service credit on my account. My personal preference is the Link 2 package running XEN for starting out (You can upgrade any time). You can choose from a variety of Linux distributions such as CENTOS, Fedora, Debian, and Ubuntu. This is a great package for learning Linux, and setting up your own web page, or email server.

ControlLogix Messaging


The producer consumer model is very efficient for transferring data between processors, but if the data transfer does not need to occur at periodic intervals, you may be able to conserve network bandwidth using the message instruction. Using the message instruction, data can even be received (or sent) from another processor, even if that processor is not present in the I/O Configuration tree.


For this example, we will set up a message instruction that will read data from another ControlLogix processor, and store that data in a memory location in our own controller.


Below, you can see the path that we will take to connect to the target processor. Once, the connection is made, msgInbox will then receive data from msgOutbox each time the message instruction is executed. Data actually flows in the opposite direction of the communication path for a data read because the connection has to be made first, then we can begin receiving data from the target.








  1. First let's set up the memory locations we will be using for this transfer. We will create three new items in the controller tag database:

    1. msgOutbox as DINT

    2. msgInbox as DINT

    3. msgControl as message


msgOutbox will be the memory location that another controller can read from. This tag has nothing to do with our own message instruction, but we will populate this tag with data, so the station reading from your controller can test their connection. You will be reading the msgOutbox tag of another station later in this exercise.


msgInbox is where the data will be stored within our own controller. After the message instruction executes, whatever data was stored in the msgOutbox of the target processor will appear in the msgInbox tag of your own processor.


msgControl is simply the workspace for the message instruction to be able to operate. It stores information about the message instruction such as when it is enabled, waiting, or done.



  1. There are several ways we can add these tags. You can right click 'Controller Tags' at the top of the controller organizer window, and add a new tag, or you can open the controller tag database, and add the tags to the bottom of the spreadsheet. Note: You must be in 'Edit Tags' mode to add tags to the controller tag database. This can be done either online or offline. Add these three tags to the controller tag database as shown:




  1. Next, add a self-running timer as shown. This timer will be used to trigger the message instruction. You will have to declare msgTimer as Timer. You can do this by creating another entry in the tag database, or right-click msgTimer once you've typed it into the timer instruction, and then select 'new msgTimer' to declare the new variable for use in logic. This procedure will make the entry in the tag database for you.




Notice the preset on the timer is 500. Because the time base for ControlLogix is milliseconds only, the preset for this timer is half of one second. We'll be using the DN bit from this timer to trigger the message instruction.


  1. Next, enter the following rung of logic for the message instruction. All variables in this rung have already been declared.





  1. Click the ellipsis to configure the message instruction. The ellipsis is the 3 dots next to the control element


  1. The message instruction is very versatile, and there are a lot of options. The message instruction can be used to initiate block transfers, read or write module status, and even reset an electronic fuse on an output module. For this exercise, we are just interested in a CIP data table read. CIP (Control and Information Protocol) is the means by which ControlLogix processors natively exchange data through the message instruction.





  1. Next, you are asked for the source and the destination element. The source is the name of the tag from which we are getting data, and the destination is the memory location in which this data is to be placed. Recall that we are getting data from the msgOutbox tag of the remote processor, and we will be placing that data into our own msgInbox tag. The length will be just one element.





  1. We have told the processor what the source and destination tags are, however, this PLC could reside on a network of many ControlLogix systems. We have not yet specified what path the controller needs to take to connect to the msgOutbox tag. Go to the 'communication' tab, and we'll discuss how to configure the communication path.







  1. Look again at our communication path:


From our PLC (Top left), we must first connect to the backplane. The next step would be to connect to our own Ethernet module (or ControlNet if you have a ControlNet connection). Next, we will specify what our exit port is (we will come out the front port of the Ethernet module. Next, we specify which IP address to connect to on the Ethernet network (or ControlNet node), then we go to the backplane, and then connect to the processor in slot 0. The chart below will help you to determine what the connection path will be (alternate between step A and B):

Note for step B you can also use the following formats: address:port, DNS name, or DNS name:port)


Using this chart you will come up with the path 1,3,2,192.168.0.57,1,0



  1. How did we get this path?

    1. From the processor you are programming, you must first choose '1' to get to the backplane in step A.

    2. Step B tells us to specify the slot number we need to go to next. This would be the slot # for the 1756-ENBT module. (Slot 3)

    3. Go back to Step A. Since we are now on-board the ENBT module, you must specify a 2 to get out the front port of the module.

    4. Back to Step B... Since we came out of port 2, we are now on the Ethernet network, so we must specify which address to go to. For this example, the address was 192.168.0.57.

    5. Go back to Step A. Now that we are on-board the Ethernet module, specify 1 to get to the backplane.

    6. Back on Step B we specify which slot to connect to. That would be the processor in Slot 0.


Note: If the target processor was already in your I/O Configuration you could just browse to the processor.


  1. You path will appear as shown





  1. Apply your changes then press OK.


  1. Download to your processor, and put the processor into 'run' or 'remote run' mode.



  1. In the Controller Tag database, populate the msgOutbox tag with a value. You must be in 'Monitor Tags' to inject a value, then press enter.





  1. If your MSG instruction is working properly, and if the msgOutbox tag is set up properly in the remote processor, you should receive this value in your msgInbox.





  1. Open the control element for the message instruction, and you will see the the status bits change as the MSG instruction executes. For a more detailed explanation of these bits, and error codes you might find in this control element, refer to the help file in RSLogix 5000. (Not all status words are shown below)


  2. If you was using this for an application, you would write logic next to populate the msgOubox tag with information you need another controller to receive (Using your own tag names)