Page 1 of 19

Hot Standby CPU Redundancy: an Overview

Basic Hot Standby CPU Redundancy System Types | Engineering Workstation Implementation of Hot
Standby CPU Redundancy
(PACSystems and Series 90-70.)
CPU Redundancy enables a critical application or process to continue operating if a failure occurs in a CPU
or if a CPU is taken out of service.
In Hot Standby CPU redundancy, the standby system is designated before any critical component failure
takes place. Any necessary state and control information is passed to this designated standby unit so that it
can take control quickly in the event of a critical component failure.
The Hot Standby CPUs contain redundancy firmware that is designed to work in conjunction with one or
more dedicated links that provide communications between the Hot Standby CPUs. The redundancy
firmware provides the coordination between the CPUs and determines the CPU that is the active unit and the
CPU that is the backup unit.
Note: (PACSystems redundancy CPUs with firmware version 5.50 or later.) If you perform a Run Mode
Store (RMS) and you select the Do synchronized activation of redundancy Controllers option, and both
primary and secondary Controllers have been updated with new data, that is, the download of information to
both Controllers is successful, then both Controllers begin to use the updated information. In this case, you
must perform an RMS on both the primary and secondary Controllers.
Active unit vs. backup unit
The CPU that controls the system is called the active unit, the other CPU is the backup unit.
Primary controller vs. secondary controller
In a Hot Standby CPU Redundancy system, one CPU resides in one Controller, which is the Primary
Controller, and another CPU resides in another controller, which is the Secondary Controller.
The Primary controller is not necessarily the active unit. Likewise, the Secondary controller is not
necessarily the backup unit. If the Primary controller fails or is taken out of service, the Secondary controller
becomes the active unit.
(PACSystems RX7i and Series 90-70 only.) The Primary controller contains all external redundancy Genius
Bus Controllers (GBCs) at Serial Bus Address 31; the Secondary controller contains all external redundancy
GBCs at Serial Bus Address 30.
Module requirements
For Hot Standby CPU operations, each controller in a redundancy system must contain a Redundancy CPU
module and other modules, depending on the controller family:
PACSystems RX7i: Must contain a hot standby redundancy CPU (IC698CRE0n0) and a redundancy
link for CPU redundancy (IC698RMX016).
Page 2 of 19

PACSystems RX3i: Must contain a hot standby redundancy CPU (IC695CRU320) and a redundancy
link for CPU redundancy (IC695RMX128).
Series 90-70: Must contain a hot standby redundancy CPU (IC697CPU780, IC697CGR772 or
IC697CGR935), a Redundancy Communications module (IC697RCM711), and a Bus Transmitter
Module (IC697BEM713).
Note: If you are using a hot standby redundancy CPU in a non-redundancy application, the other hot
standby redundancy modules are not required.
Control switching
Control automatically switches to the backup unit if certain system failures are detected in the active unit.
Control can also be switched manually by using the SVC_REQ 26, Role Switch function in the application
program.
In a PACSystems RX3i redundancy system, you can also switch the control manually by activating a toggle
switch on the RMX module. In a Series 90-70 redundancy system, you can switch manually by pressing a
push-button on the Redundancy Communications Module.
For more information
See Transfer List Shared I/O.
For more information on the IC697CGR772 or IC697CGR935 and redundancy systems based on them, refer
to Series 90-70 Enhanced Hot Standby CPU Redundancy User's Guide (GFK-1527A).
For more information on the IC697CPU780 and redundancy systems based on it, refer to Series 90-70 Hot
Standby CPU Redundancy User's Guide (GFK-0827).
Combining CPU Redundancy with Genius Redundancy
(PACSystems RX7i and Series 90-70 only.) CPU redundancy systems can be used in combination with
Genius redundancy systems to provide additional protection against component failure. Using a CPU
redundancy system with a Genius redundancy system is named CPU over Genius redundancy.
Combining CPU Redundancy with Ethernet Global Data (EGD)
For information on EGD combined with Hot Standby CPU redundancy, see Hot Standby Redundancy and
Ethernet Global Data (EGD).

Basic Hot Standby CPU Redundancy Types
Single Bus with Preferred Master (Series 90-70 only)
Single Bus with Floating Master
Dual Bus with Floating Master
(PACSystems RX7i and Series 90-70 only.) The basic Hot Standby CPU redundancy systems can be used as
such or in combination with Genius redundancy schemes. For examples, see CPU Redundancy over Genius:
an Overview and click the links.
Page 3 of 19

Single Bus with Preferred Master
(Series 90-70 only.) Uses a single Genius bus with Genius Bus Controllers (GBCs) in each controller. The
primary unit is always chosen as the active unit when the units initially synchronize. (This CPU redundancy
system type is supported by the Genius Hot Standby (GHS) control strategy.)
Single Bus with Floating Master
Uses a single Genius bus with Genius Bus Controllers (GBCs) in each controller. No switchover occurs on
initial synchronization to make the primary unit the active unit. (In a PACSystems, this CPU redundancy
system type is supported by the Hot Standby (HSB) control strategy. In a Series 90-70, the Genius Dual Bus
(GDB) control strategy applies: the GDB is a misnomer, because it also supports a single Genius bus.)
Dual Bus with Floating Master
Uses dual busses with the bus controllers in each controller. No switchover occurs on initial
synchronization. This option provides redundancy of both the controller and the I/O bus. (In a PACSystems,
this CPU redundancy system type is supported by the Hot Standby (HSB) control strategy. In a Series 90-70,
the Genius Dual Bus (GDB) control strategy applies: the GDB is a misnomer, because it also supports a
single Genius bus.)

Engineering Workstation Implementation of Hot Standby CPU
Redundancy
A Hot Standby GE IP CPU Redundancy system consists of two CPUs optionally connected to one or more
Genius I/O networks, and each CPU resides in a separate controller. In Engineering Workstation, you can
implement such a redundancy system in one of two methods.
Highly recommended method
By means of Engineering Workstation wizards, you can set up, in the Project tab of the Navigator, one target
that contains the following:
Two Hardware Configurations (Primary and Secondary), also known as a dual Hardware
Configuration.
One common set of Logic.
Possibly one common Ethernet Global Data (EGD) component (after someone adds it to the target).
The Primary Hardware Configuration corresponds to one of the GE IP Controllers, and the Secondary
Hardware Configuration corresponds to the redundancy GE IP Controller.
After configuring or updating the Primary Hardware Configuration, you can easily mirror your changes to
the secondary Hardware Configuration. This greatly simplifies the creation and maintenance of your Hot
Standby CPU redundancy system.
For a Series 90-70 example of a dual Hardware Configuration, see Redundancy Hardware Configuration:
Status Indicators.
For more information, see Redundancy Hardware Configuration: an Overview
Page 4 of 19

Alternative method
You can set up two independent targets, which can reside in the same project or different projects. You must
manually configure and maintain each target.
Most of the online help concerning Hot Standby CPU redundancy is written on the assumption that you are
using the highly recommended method.








Transfer List - Shared I/O

Shared I/O | Transfer List | Transferring CPU memory segments | Transferring variables | Transfer List Checksum | Removing variables from the transfer list |
Variable Transfer List report
(PACSystems and Series 90-70.)
In a Hot Standby CPU redundancy system or Hot Standby CPU over Genius redundancy system, you can
ensure that various values are shared between the Hot Standby redundancy CPUs. Sharing values means
transferring them from one Hot Standby redundancy CPU to the other on every scan.
(For CPU Redundancy on a PACSystems redundancy CPU, firmware version 5.50 or later.) If there are
symbolic variables in the logic and Hardware Configuration (HWC) (logic is coupled) being downloaded to
the Controllers, then you must Run Mode Store (RMS) transfer lists.
Note: (For PACSystems redundancy CPUs with firmware version 5.50 or later.) If you perform a Run Mode
Store (RMS) and you select the Do synchronized activation of redundant Controllers option, and both
primary and secondary Controllers have been updated with new data, that is, the download of information to
both Controllers is successful, then both Controllers begin to use the updated information. In this case, you
must perform a RMS on both the primary and secondary Controllers.
Shared I/O (Series 90-70)
On the Redundancy tab of a Series 90-70 hot standby redundancy CPU, you can specify which segments of
CPU memory areas to share between two redundancy CPUs. For more information, see Redundancy Tab,
90-70 CPUs.
Page 5 of 19

Transfer List (PACSystems with firmware version 2.80 or later)
The input and output transfer lists of a PACSystems hot standby redundancy CPU are the lists of data that is
transferred between two redundancy CPUs during respectively the input and output points of the scan.
A transfer list can contain any or all of the following:
Segments of CPU memory areas defined for the input transfer point or output transfer point in the
Transfer List tab of a PACSystems hot standby redundancy CPU
Variables mapped to the same memory areas as on the Transfer List tab, whether inside or outside
the segments defined on the Transfer List tab
Symbolic variables, except reference ID variables
I/O variables
Every variable on the transfer list has its Input Transfer List and/or Output Transfer List properties set to a
value other than False. For more information, see Transferring variables between two PACSystems
redundancy CPUs.
Maximum amount of data that can be transferred
Maximum transfer data size limit: 2 MB (including both transfer lists).
Maximum number of variable entries in each transfer list: 65,535.
Maximum number of variables on each transfer list: varies from 16,384 through 65,535, depending
on the number of entries required for each variable. The number of entries per variable depends on
the memory in which the variable resides.
Me
mo
ry
in
wh
ich
the
var
iab
le
res
ide
s
Nu
mb
er
of
ent
rie
s
per
var
iab
le

%I,
%
Q,
I/O
dis
cret
e
w
i
t
h

p
o
i
n
t

f
Page 6 of 19

a
u
l
t
s

e
n
a
b
l
e
d
:

4
w
i
t
h
o
u
t

p
o
i
n
t

f
a
u
l
t
s
:

3

%
AI,
%
AQ
,
I/O
non
-
dis
cret
e
w
i
t
h

p
o
i
n
t

f
Page 7 of 19

a
u
l
t
s

e
n
a
b
l
e
d
:

2
w
i
t
h
o
u
t

p
o
i
n
t

f
a
u
l
t
s
:

1

%
M,
%
Q,
sy
mb
olic
dis
cret
e
3

Page 8 of 19

%R
,
%
W,
sy
mb
olic
non
-
dis
cret
e
1

fun
ctio
n
blo
ck
inst
anc
e
dat
a
4
ent
ries
for
the
enti
re
inst
anc
e
dat
a


Each element of a custom structure variable (a structure variable that is not used for function block instance
data) requires the same number of entries as one variable.
An array that is transferred entirely requires the same number of entries as one variable. For example, a 64-
BOOL array in %Q memory with point faults enabled requires only four entries, not 256.
If you transfer only some elements of an array, then each transferred element requires the same number of
entries as one variable. For example, if you transfer only 12 elements of a 64-BOOL array in %Q memory
with point faults enabled, the transferred elements require 48 entries in total.

Transferring CPU memory segments between hot standby
redundancy CPUs
To transfer CPU memory segments between hot standby redundancy CPUs that are in the
same Logic Developer target (dual Hardware Configuration):
1. In the Project tab of the Navigator, expand the target.
2. Expand Hardware Configuration [Primary].
3. Expand the main rack and double-click the hot standby redundancy CPU.
Page 9 of 19

The Parameter editor displays the parameters of the redundancy CPU.
4. Do one of the following:
For a PACSystems, click the Transfer List tab and enter values for the Input Transfer Point
and the Output Transfer Point. For more information, press CTRL+F11 to open the Companion,
then click any parameter in the Transfer List tab to view Companion help for that parameter.
- or -
For a Series 90-70, click the Redundancy tab and enter values for the Shared I/O.
5. Mirror to the Secondary Hardware Configuration.
To transfer CPU memory segments between hot standby redundancy CPUs that are in
separate Logic Developer targets:
1. In the Project tab of the Navigator, expand one of the targets.
2. Expand Hardware Configuration.
3. Expand the main rack and double-click the hot standby redundancy CPU.
The Parameter editor displays the parameters of the redundancy CPU.
4. Do one of the following:
For a PACSystems, click the Transfer List tab and enter values for the Input Transfer Point
and the Output Transfer Point. For more information, press CTRL+F11 to open the Companion,
then click any parameter in the Transfer List tab to view Companion help for that parameter.
- or -
For a Series 90-70, click the Redundancy tab and enter values for the Shared I/O.
5. Expand the other target and repeat steps 2, 3, and 4. At step 4, ensure the following:
The value of every Length parameter on the Input Transfer Point, for example %I Length or
%Q Length, is the same for both targets.
The value of every Length parameter on the Output Transfer Point is the same for both
targets.
The values of the Reference parameters of one hot standby redundancy CPU do not need to match
the values of the corresponding Reference parameters on the other redundancy CPU.
6. If any of the %I Length, %Q Length, %AI Length, or %AQ Length parameters is set to a value other
than zero, then ensure that the Point Fault References parameter on the Memory tab is set to the same
value on both redundancy CPUs.

Transferring variables between two PACSystems hot standby
redundancy CPUs with firmware version 2.80 or later
When the hot standby redundancy CPUs are in the same Logic Developer target (dual Hardware
Configuration)
When the hot standby redundancy CPUs are in separate Logic Developer targets
Page 10 of 19

To transfer a variable between two PACSystems hot standby redundancy CPUs that are in
the same Logic Developer target (dual Hardware Configuration):
1. Anywhere in Engineering Workstation, for example on the Variables tab of the Navigator, right-click
a variable defined for the same PACSystems target as for the hot standby redundancy CPUs, and
then choose Properties.
Note: Bit references in non-discrete memory cannot be transferred.
The Inspector displays the variable's properties.
2. Ensure that the variable to be transferred is one of the following:
A BOOL variable of any length mapped to %G, %I, %M, or %Q discrete memory
A non-BOOL variable mapped to %AI, %AQ, %R, %W, %G, %I, %M, or %Q memory
An I/O variable
A function block instance variable or other symbolic variable except a reference ID variable
A User-defined Data Type (UDT) variable
Otherwise, the variable cannot be transferred.
Note: An alias variable cannot be transferred.
3. Set the Input Transfer List and/or the Output Transfer List properties to a value other than False.
To transfer a simple variable, that is, a non-array and non-structure variable, set the
appropriate property to True.
To transfer all the elements of an array or structure variable, including the instance data of a
function block, set the appropriate property of the array head or structure variable head to
True. This sets the corresponding property of each element to True and read-only.
To transfer only some elements of an array or structure variable, set the appropriate property
of the array head or structure variable head to Mixed, then for each element you want to
transfer, set the corresponding property to True.
For a UDT variable, the Input Transfer List and Output Transfer List properties are read-
only and set to False; you can transfer the UDT variable in its entirety (by setting the
property to True) or not at all (by setting the property to False).
You cannot set the Input Transfer List or Output Transfer List property to Mixed in the
following cases:
Function block instance variables. You can transfer an instance variable only in its
entirety (by setting the property to True) or not at all (by setting the property to False).
You multiselect variables and at least one of them is not an array head or structure
variable head.
Notes
o BOOL arrays mapped to %I, %Q, %M, or %G memory can be of any length, not necessarily
an exact multiple of 8 bits, and do not need to be byte-aligned. Symbolic BOOL arrays can be
of any length. Non-array BOOL variables are supported, whether symbolic or mapped to %I,
%Q, %M, or %Q memory. When calculating the transfer data size against the 2 MB limit, the
charged size for a BOOL variable or BOOL array is rounded up to the nearest complete byte.
Page 11 of 19

Caution: Transferring BOOL data that is not byte aligned and is not an exact multiple of 8
bits is slower than transferring BOOL data that is byte aligned and an exact multiple of 8 bits,
and increases the size of the redundancy configuration. There is a risk of exceeding the
maximum Fail Wait Timeout of 400 ms. For information on estimating transfer times, see
GFK-2308A or later, Chapter 4 "Data Transfer".
o Local variables are supported on the transfer list; however, the %L and %P memory areas are
not.
o If you use Hot Standby CPU redundancy over Genius, all redundancy Genius outputs must be
transferred in the output transfer list.
o If you enable point faults, the diagnostic data is transferred along with I/O variables and with
variables mapped to the %I, %Q, %AI, and %AQ memory areas.
o If a variable is not used in logic or in the Hardware Configuration, you can delete it even if it
is on the transfer list.
o If you copy a variable that is on the transfer list of a PACSystems hot standby redundancy
CPU to a non-PACSystems target or to a PACSystems target that does not contain a hot
standby redundancy CPU, the Input Transfer List and Output Transfer List properties of the
copied variable in the destination target are set to False and disappear from the Inspector.
o The values of the Input Transfer List and Output Transfer List properties are included when
you import or export variables.
o All transfer variables are included when you export the Hardware Configuration (HWC). If a
transfer variable is part of a structure variable, the entire structure variable is added to the
variables list in the exported HWC. Importing the HWC may result in HWC inequality if
there are variable conflicts during the import.
o When the transfer list contains symbolic variables, the HWC and logic are coupled. As a
result, if you make any changes to the transfer list, for example, if you change the Name,
Data Type, Array Dimension 1, or Array Dimension 2 of a variable on the transfer list, or if
you create or delete an I/O variable, or if you add, change, or delete an element of a structure
variable, then the following are true:
You can perform a Run Mode Store (RMS).
You cannot make a word-for-word change, or launch or complete a Test Edit session.
Tip: If you add a memory segment to the transfer list and download to a stopped PACSystems, then later
you can add to logic a variable that is mapped to that memory segment and download the changes to the
PACSystems when it is running. You haven't actually added the variable to the transfer list, but its value is
transferred anyway because it is mapped to the memory segment that was already on the transfer list.
To transfer a variable between two PACSystems hot standby redundancy CPUs that are in
separate Logic Developer targets:
1. Anywhere in Engineering Workstation, for example on the Variables tab of the Navigator, right-click
a variable defined for a PACSystems target that contains one of the hot standby redundancy CPUs,
and then choose Properties.
Note: Bit references in non-discrete memory cannot be transferred.
The Inspector displays the variable's properties.
2. Ensure that the variable to be transferred is supported on the transfer list.
3. Set the Input Transfer List and/or the Output Transfer List properties to a value other than False.
Page 12 of 19

4. Anywhere in Engineering Workstation, find the variable that has the same name in the PACSystems
target that contains the other hot standby redundancy CPU, and then choose Properties. The variable
must also meet other requirements.
The Inspector displays the variable's properties.
5. Set the Input Transfer List and/or the Output Transfer List properties to a value other than False. Set
the properties to the same values as at step 3.
Requirements for a variable to be transferred between two PACSystems hot standby
redundancy CPUs that are in separate Logic Developer targets
To transfer the value of one variable in one target to another variable in the other target, the corresponding
variable properties must meet the following requirements:
Property Requirement
Name Same value.
For a local variable, the block name must be the same, for
example, "ABC" in the variable name "ABC.DEF".
For an array element, the index must be the same, for
example, the "4" in Name[4].
Data Type Same value.
This is true for both conventional data types (INT, BOOL,
and so on) and function block types.
You can transfer a packed BYTE variable only to another
packed BYTE variable or to a BYTE element of a User-
defined Data Type (UDT). A packed BYTE variable
resides in discrete memory, or as an element of a UDT, or
as a member of a UDFB.
You can transfer an unpacked BYTE variable only to
another unpacked BYTE variable. An unpacked BYTE
variable resides in unmanaged non-discrete memory.
Caution: If you attempt to transfer an unpacked BYTE variable to
a packed variable, the checksum for the transfer list is different and
a fault is logged that the checksum is different with no further
explanation.
Array Dimension 1 Same value
Array Dimension 2 Same value


If point faults are enabled, the following limitations are imposed:
Co
ndi
tio
Mu
st
be
Page 13 of 19

n
of
a
BO
OL
var
iab
le
tra
nsf
err
ed
to
a
BO
OL
var
iab
le
tha
t
me
ets
the
foll
owi
ng
req
uir
em
ent
s

I/O variable I/O variable, or variable mapped to the %I or %Q
memory areas. That is, I/O, %I, and %Q BOOL
variables are interchangeable with regards to
transfers from one hot standby redundancy CPU to
another.
Mapped to the %I memory area

Ma
ppe
d
to
the
%
Q
me
mo
ry
are
a


Symbolic variable Symbolic variable, or variable mapped to the %M or
%G memory areas, all of which are interchangeable
Mapped to the %M memory area

Page 14 of 19

Ma
ppe
d
to
the
%
G
me
mo
ry
are
a


Co
ndi
tio
n
of
a
no
n-
BO
OL
var
iab
le
Mu
st
be
tra
nsf
err
ed
to
a
var
iab
le
of
the
sa
me
dat
a
typ
e
tha
t
me
ets
the
foll
owi
ng
req
uir
em
ent
s

I/O variable I/O variable, or variable mapped to the %AI or
%AQ memory areas, all of which are
interchangeable
Mapped to the %AI memory area
Page 15 of 19


Ma
ppe
d
to
the
%
AQ
me
mo
ry
are
a


Symbolic variable Symbolic variable, or variable mapped to the %R or
%W memory areas, all of which are interchangeable
Mapped to the %R memory area

Ma
ppe
d
to
the
%
W
me
mo
ry
are
a




Transfer List Checksum
To ensure the integrity of data transfers between PACSystems hot standby redundancy CPUs, a checksum is
calculated for each transfer list. The CPU firmware uses the checksum to ensure that the input and output
transfer lists of the hot standby redundancy CPU partner are compatible with its own input and output
transfer lists.
The checksum takes the following into account:
The requirements for each variable on the transfer list, except that the length of data includes point
fault data, not only the number of bits or bytes of the actual variable. For an array element, the
checksum includes the parent array's dimensions.
The number of entries in each list
Page 16 of 19

The Program Name property
The values of all the %n Length parameters on the Transfer List tab
The value of the Point Fault References parameter on the Memory tab (only if any memory segment
or variable transfer involves the %I, %Q, %AI, or %AQ memory areas)
The relative position of structure variable elements with regards to one another in the structure
variable
The data type of instance variables. For example, if an instance variable named ABC stores the
instance data of the function block TON, the data type of ABC is TON.
The packedness or unpackedness of a BYTE variable.

Removing variables from the transfer list
(PACSystems hot standby redundancy CPUs with firmware version 2.80 or later.)
Removing all variables from the Input List or Output List
Removing one variable at a time from the Input List or Output List
To remove all variables from the Input List or the Output List:
1. Generate the Variable Transfer List report.
2. In the Input List or Output List part of the report, click Remove all variables from list.
Respectively the Input Transfer List or Output Transfer List property of all the variables on the list is
set to False.
3. If the PACSystems hot standby redundancy CPUs reside in separate Logic Developer targets, repeat
steps 1 and 2 in the target that contains the other hot standby redundancy CPU.
To remove one variable at a time from the Input List or Output List:
1. Do one of the following:
Generate the Variable Transfer List report. In the report, click a variable. If the Inspector is
closed, press SHIFT+F7 to open it.
- or -
Anywhere in Engineering Workstation, for example on the Variables tab of the Navigator,
right-click a variable, and then choose Properties.
The Inspector displays the variable's properties.
2. In the Inspector, set the Input Transfer List or Output Transfer List property of the variable to False.
3. If the PACSystems hot standby redundancy CPUs reside in separate Logic Developer targets, repeat
steps 1 and 2 in the target that contains the other hot standby redundancy CPU.

Variable Transfer List report
Page 17 of 19

The Variable Transfer List report displays information on the variables to be transferred between two
PACSystems hot standby redundancy CPUs with firmware version 2.80 or later. The report is an HTML
page that appears in the InfoViewer.
The report is divided into two parts: Input List and Output List. The parts display the variables transferred
during respectively the input and output points of the scan. A variable can appear on both lists.
Each part of the report displays the following:
[Title]: Input List or Output List
Remove all variables from list: Click to remove all variables respectively from the Input List or
Output List.
Name, Type, Address, Publish, Description: The column headers for respectively the Name, Data
Type, Ref Address, Publish, and Description properties of each variable on the input or output list.
You can click Name, Type, or Address to sort the variables in the alphabetical order of their Name,
Type, or Address.
[The values of the aforementioned properties for each variable]: The variables are initially sorted
in the alphabetical order of the Name property. You can click any variable to display all its properties
in the Inspector if it is open. To open the Inspector, press SHIFT+F7.
Total Variables in Input List [or Output List]: Because a variable can appear on both lists, adding
the number of variables in the input list and the number of variables in the output list can yield a
number greater than the total number of variables in the target.
Total Variable Bytes Transferred (rounded up)
The following figures in each part of the report can assist you to determine the total time required for
the input transfer and the output transfer:
Whole Bytes Transferred: This value includes the associated force, transition, and diagnostic
entries, if any.
Entries Containing Only Whole Bytes: The number of transfer list entries that contain only entire
bytes.
Partial Bytes Transferred: (BOOL variables only.) This value includes the associated force,
transition, and diagnostic entries, if any.
Entries Containing Partial Bytes: The number of transfer list entries that contain at least one
partial byte.
For information on estimating transfer times, see GFK-2308A or later, Chapter 4 "Data Transfer".

To generate and print the Variable Transfer List report:
1. In the Project tab of the Navigator, right-click a target, and then choose Report.
The project is saved.
2. In the Select a Report dialog box that appears, click inside the Available Reports box, and then select
Variable Transfer List Report.
The Example box displays a sample report.
3. Click OK.
Page 18 of 19

If the Variable Transfer List is very large, the Building transfer list data dialog box appears: it
displays the estimated remaining time and contains a Cancel button. The Variable Transfer List
report appears in the InfoViewer window. If the report is very large, the cursor remains in the shape
of an hour glass until the report appears; this may take as long as it took to build the transfer list data.
In both the Input List and the Output List, the variables initially appear in the alphabetical order of
their names.
Caution: If you access Help topics in the InfoViewer while viewing the report, Help fills the
InfoViewer, the report is lost, and you need to regenerate it if you want to see the report again.
4. (Optional.) To sort the variables in the alphabetical order of their data types or reference addresses,
respectively click the Type or Address column headers. To re-sort them by name, click the Name
column header.
Tip: To view all the properties of a variable, select it in the report. The Inspector displays the
properties if it is open. To open the Inspector, press SHIFT+F7.
5. In the InfoViewer window, right-click the report, and then choose Print.
6. To print the report when it is no longer visible in Infoviewer, regenerate it, right-click the
InfoViewer, and then choose Print.

















Page 19 of 19