AB 冗余系统内存使用详解.doc

Page 5of 5Understand ControlLogix Redundancy Memory UsageCreation Date:6-30-04DISCLAIMERBecause 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 AudienceThis document is to be used by Rockwell Automation employees/customers supporting and selling ControlLogix Redundancy.Concept of Application NoteIn 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 KbytesUsed 75 KbytesData and Logic memory:Total 1.5 MegUsed 250 Kbytes data and 250 Kbytes logicNow when Redundancy is enabled the amount of I/O memory and data memory will double.Redundant System:I/O memory:Total 208 KbytesUsed 125 KbytesData and Logic memory:Total 1.5 MegUsed 500 Kbytes data and 250 Kbytes logicAnother 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.BaselineThe 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 1Redundancy enabled:Figure 2By 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 3Redundancy enabled:Figure 4By 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 Image2. Output Transmit ImageThe 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 controllers POI are first sent to the secondary controller. The OTI in the primary is not updated with the POIs 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 youve 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 contr