Because of the variety of uses for this information, the user of and those responsible for applying this information must satisfy themselves as to the acceptability of each application and use of the program.  In no event will Allen-Bradley Company be responsible or liable for indirect or consequential damages resulting from the use or application of this information.

The illustrations, charts and examples shown in this application note are intended solely to illustrate the principles of programmable controllers and some of the methods used to apply them.  Particularly because of the many variables and requirements associated with any particular installation, Allen-Bradley Company cannot assume responsibility or liability for actual use based upon the illustrations used and applications.

Allen-Bradley Company assumes no patent liability with respect to use of information, circuits, equipment, or software described in this text.

Reproduction of the contents of the application note, in whole or in part, without the express written consent of the Allen-Bradley Company is prohibited.

Document Purpose 

This document is not a manual or training material, but an Application Note, which could be useful in helping a Rockwell Automation customer with understanding ControlLogix Redundancy memory usage.

Intended Audience

This document is to be used by Rockwell Automation employees/customers supporting and selling ControlLogix Redundancy.

Concept of Application Note

In a ControlLogix controller (L55 and L6X) there are two separate areas of memory, I/O memory and data and logic memory.  When Redundancy is enabled, certain areas of memory will approximately double in usage; those are I/O memory and data memory.   We will discuss why these areas of memory double.

First let us look at an example using an L55M13 to illustrate:

Non-Redundant System:

    I/O memory:

    Total 208 Kbytes

    Used 75 Kbytes

    Data and Logic memory:

    Total 1.5 Meg

    Used 250 Kbytes data and 250 Kbytes logic

Now when Redundancy is enabled the amount of I/O memory and data memory will double.

Redundant System:

    I/O memory:

    Total 208 Kbytes

    Used 125 Kbytes

    Data and Logic memory:

    Total 1.5 Meg

    Used 500 Kbytes data and 250 Kbytes logic

Another example of the I/O and data memory doubling can also be shown by using V13 software and the offline memory estimation tool.

First we will look at the memory estimation of a blank non-redundant controller.  That is no I/O, data, or logic. This is only an estimation.

Baseline

The figure above will give us a baseline from which to work.  There is some memory used even if the controller program is empty.

Now we will add some I/O to the program.  The following I/O was added.

Redundancy not enabled:

Figure 1

Redundancy enabled:

Figure 2

By subtracting the Max Used bytes under Estimated I/O Memory from figures Baseline and 1 you can see that 2256 bytes were added to memory.   Then by subtracting the Max Used bytes under Estimated I/O Memory from figures Baseline and 2 you can see that 4176 bytes were added to memory, approximately double the size.

Now we will now add a 10,000 element DINT array to the program.

Redundancy not enabled:

Figure 3

Redundancy enabled:

Figure 4

By subtracting the Max Used bytes under Estimated Data and Logic Memory from figures 1 and 3 you can see that 39880 bytes were added to memory, approximately the size of the 10,000 element DINT array.  Then by subtracting the Max Used bytes under Estimated Data and Logic Memory from figures 2 and 4 you can see that 80108 bytes were added to memory, approximately double the size of the 10,000 element dint array.

The two examples above confirm that I/O and data memory are approximately doubled when redundancy is enabled.  The question that comes out of all this is why is I/O and Data memory usage double when redundancy is enabled?  Each section of memory will be addressed separately.

Why is I/O memory doubled?  Simply to have bumpless outputs for the highest priority user task.  Another way to say this is it prevents a momentary reversal of outputs immediately after a switchover for outputs of the high priority user task.  

The basic objective of the output handling approach in the redundant Logix Controller is to ensure that no data is sent to the output modules from the primary Logix controller without the secondary Logix controller having the same values in its output image.  This is accomplished via an output buffering mechanism.

There are two copies of the output image:

    1. Program Output Image

2. Output Transmit Image

The Program Output Image (POI) is the copy of the outputs that are directly accessed by the user program. All instructions, both output (write) instructions and input (read) instructions which reference output data values, will use the POI.  

The second buffer, the Output Transmit Image (OTI), is the copy of the outputs that are actually sent to the output modules.  If there is a qualified secondary controller in the system, then the changes in the primary controller’s POI are first sent to the secondary controller.  The OTI in the primary is not updated with the POI’s data until the secondary controller acknowledges that it has received the data and moved the data to its own OTI.  If there is no secondary controller present the data will be copied from the POI to the OTI at the end of every program.

So because of the creation of the POI we double the amount of I/O memory.  But you may ask you’ve only talked about “outputs” what about “inputs”.  If outputs are the only I/O that need to be buffered then my I/O memory should only increase by the amount used for outputs.  Yes that is true, but for increased performance it is easier and faster to make an exact copy of I/O memory.  Then when data is moved from the POI to the OTI we only have to use a constant offset.  Again, the pay off is performance over increased memory usage.

Why is the data table memory doubled?  As the primary controller executes its program data that has been accessed thru program execution is tracked.  When the primary controller transfers this tracked data to the secondary it transfers it to a buffered area, not right into the valid data memory.  This buffer area has the same layout as the valid data memory.  Once all the tracked data has been transferred to the secondary buffer area the data is then moved into the valid data memory.  The buffered area is used to guarantee that all data has been received first from the primary.  We would not want to switchover to the secondary with data memory that is a mixture of old and new.  This is why data memory is doubled.下载本文