ICS TRIPLEX Regent User's Guide

User's Guide
Regent® Fault Tolerant Programmable Controller
Issue 4, Sep-98
Catalog No. T3930
Notice
This document contains proprietary information that is pro-
tected by copyright. All rights are reserved. No part of this
document may be photocopied, reproduced, or translated into
another language without the prior written consent of ICS.
The information contained in this document is subject to
change without notice. The reader should, in all cases, consult
ICS to determine whether any such changes have been made.
Regent, Triplex, and Guarded are registered trademarks of
ICS. WINTERPRET and Safetybus are trademarks of ICS.
Other trademarks are owned by their respective companies.
© Industrial Control Services, Inc. (ICS) 1997.
Disclaimer
Because of the variety of uses for this equipment, and because
of the differences between this solid state equipment and elec-
tromechanical equipment, the user of and those responsible
for applying this equipment must satisfy themselves as to the
acceptability of each application and use of this equipment. In
no event will Industrial Control Services, Inc. (ICS) be re-
sponsible or liable for indirect, special, or consequential dam-
ages (including, but not limited to, lost profits) resulting from
the use or application of this manual or the equipment de-
scribed herein, even if ICS has been advised, or should have
known of the possibility of such damages.
The illustrations, figures, charts, and layout examples in this
manual are intended solely to illustrate the text of this man-
ual. Because of the many variables and requirements associ-
ated with any particular installation, ICS disclaims all re-
sponsibility or liability for actual use based upon the illustra-
tive uses and applications. ICS disclaims any implied war-
ranty of fitness for a particular purpose.
ICS reserves the right to make changes in the specifications
and other information contained in this document without
prior notice, and the reader should, in all cases, consult ICS to
determine whether such changes have been made.
ii Industrial Control Services

Federal Communications Commission (FCC)
Statement
Warning: This equipment generates, uses, and can radiate radio fre-
quency energy and if not properly installed and used in ac-
cordance with the instructions in this manual, may cause in-
terference to radio communications. The equipment described
in this manual has been tested and found to comply with the
limits for Class A computing devices pursuant to Subpart J of
Part 15 of FCC Rules, which are designed to provide
reasonable protection against such interference when operated
in a commercial environment. Operation of this equipment in
a residential area is likely to cause interference, in which case
the user will be required, at his or her own expense, to take
whatever measures may be necessary to correct the
interference.
Important Grounding Notice:

Grounding Requirements
The product described herein is equipped with grounding lugs
for the user's safety. They are to be used in conjunction with
a properly grounded receptacle to avoid electrical shock and
damage to the equipment.
R e g e n t User's Guide, Issue 4 iii

iv Industrial Control Services
Table of Contents
Section 1 Introduction
Fault Tolerance, HIFT and TMR ..........................................1
Fail-Operational / Fail-Safe .........................................7
Hot Replacement .........................................................8
The Regent .............................................................................10
The Controller Assembly.............................................10
The I/O Power Supply Assembly.................................17
The I/O Assembly ........................................................19
Flexible Architecture..............................................................28
Classes of I/O Protection .............................................28
Communications..........................................................33
The Winterpret Application ...................................................35
Projects, Programs and Function Blocks....................37
Data Structure.............................................................38
Working with Winterpret ............................................39
Programming Languages ............................................44
System Security ...........................................................46
TÜV Certification Compliance...............................................48
Section 2 Installing the Regent Hardware
Installation Planning .............................................................49
Equipment Mounting ..................................................49
Environmental Considerations ...................................50
Heat Dissipation ..........................................................50
Power Consumption ....................................................51
Power Distribution ......................................................52
I/O Power Supply Assembly Loads .............................54
Power Filtering, UPS ..................................................55
Grounding....................................................................56
Cabling.........................................................................57
Cable and Wire Routing ..............................................57
Hardware Installation............................................................58
Delivery and Inspection...............................................58
Unpacking....................................................................59
Installing the Controller Chassis ................................59
Installing the I/O Power Supply Chassis ....................61
Input Power Wiring.....................................................61
R e g e n t User's Guide, Issue 4 v

Table of Contents
Installing the I/O Chassis............................................62

Installing Processor Modules ......................................65
Installing Communications Modules and Blanks .......67
Installing I/O Power Supply Modules .........................68
Installing I/O Transceiver Modules ............................69
Installing I/O Module Slot Keys..................................70
Wiring the I/O Assembly to Field Devices...................73
Installing I/O Modules and Blanks .............................75
Installing Retaining Screws and Brackets ..................76
Connecting the I/O Safetybus Cables..........................77
Connecting the I/O Power Supply to the I/O
Assembly......................................................................79
Connecting Your PC to the Regent........................................80
System Startup Tests .............................................................80
Powering Up the Regent System.................................81
Faulted Status Check ..................................................83
Section 3 Installing the WINTERPRET Application
Installing WINTERPRET Version 3.2 or Above .......................87
Installing WINTERPRET Version 3.1.......................................88
Making the WINTERPRET Directory ............................88
Installing the WINTERPRET Application Files.............89
The SHARE Program..................................................90
Creating a WINTERP.INI File ...................................90
Making a Program-Item Icon......................................91
Running the WINTERPRET Application..................................92
Logging On ..................................................................92
Passwords, User Names and Classifications...............92
Read-Only Privileges ...................................................93
Logging on for the First Time.....................................93
Navigating the WINTERPRET Application ..............................94
WINTERPRET Application Window ..............................94
Active and Inactive Windows ......................................94
Dialog Boxes ................................................................95
Defining Classifications .........................................................96
Using the Classifications Command ...........................97
Defining System Users...........................................................100
Using the System Users Command.............................100
Changing Your Password.......................................................101
Commands Common to all WINTERPRET Windows ...............102
vi Industrial Control Services

Table of Contents
File Menu.....................................................................102
Options Menu ..............................................................103
Window Menu..............................................................104
Help Menu ...................................................................104
What Next?.............................................................................106
Section4 Working with Projects
Using the Project Selector......................................................107
File Menu.....................................................................108
Definitions Menu.........................................................110
Options Menu ..............................................................111
Window Menu..............................................................111
Help Menu ...................................................................111
Using the Project Editor ........................................................111
File Menu.....................................................................112
Controller Menu ..........................................................117
Tools Menu ..................................................................128
Options Menu ..............................................................129
Window Menu..............................................................131
Help Menu ...................................................................131
Configuring Your Project’s I/O ..............................................131
Using the I/O Configuration Editor.......................................132
File Menu.....................................................................137
Edit Menu....................................................................139
Search Menu................................................................142
Options Menu ..............................................................142
Window Menu..............................................................144
Help Menu ...................................................................144
Closing the I/O Configuration Editor ....................................145
Using the Shared Variable Editor..........................................146
Allocating Register Space ............................................147
Creating Shared Variables ..........................................147
File Menu.....................................................................149
Edit Menu....................................................................151
Search Menu................................................................152
Configure Menu...........................................................153
View Menu...................................................................155
Options Menu ..............................................................155
Window Menu..............................................................155
Help Menu ...................................................................155
R e g e n t User's Guide, Issue 4 vii

Table of Contents
Closing the Shared Variable Editor .......................................155

Regent Variable Types and Memory......................................156
Input and Output Variables ........................................157
System Variables .........................................................157
Shared Variables..........................................................158
Local Variables ............................................................159
Data Types...................................................................159
The Symbol Table........................................................162
Regent Memory ...........................................................163
Section 5 Working with Programs and Function Blocks
Where to Start ........................................................................170
Planning Programs ................................................................171
Programming with Function Blocks ...........................171
Using Multiple Programs ............................................172
An Example of Program Planning ..............................172
Creating Programs with the Project Editor...........................174
Using the Program Editor .....................................................175
Creating New Function Blocks ...................................176
Copying Function Blocks ............................................178
Opening a Function Block for Editing ........................179
Changing the Order of Function Blocks .....................180
Deleting Function Blocks ............................................180
Program Editor Commands ...................................................181
File Menu.....................................................................181
Edit Menu....................................................................188
Tools Menu ..................................................................191
Options Menu ..............................................................191
Window Menu..............................................................191
Help Menu ...................................................................191
Using the Function Block Editors .........................................191
Commands Common to all Function Block Editors ..............192
File Menu.....................................................................192
Using the Ladder Logic Editor...............................................197
The Ladder Logic Diagram..........................................197
Starting a New Ladder Logic Diagram .......................198
Ladder Logic Editor Commands ............................................201
Edit Menu....................................................................201
viii Industrial Control Services

Table of Contents
Relay Menu..................................................................206
Coil Menu ....................................................................210
Logic Menu ..................................................................215
Math Menu ..................................................................231
Search Menu................................................................238
Options Menu ..............................................................240
Window Menu..............................................................241
Help Menu ...................................................................241
Documenting Your Ladder Logic Function Blocks ...............241
Entering Rung Comments ..........................................241
Cell Comments ............................................................242
Ladder Logic Constraints and Limitations............................242
Using the Analog Scaling Editor............................................243
Scaling Analog Values to Engineering Values ............243
Scaling Engineering Values to Analog Outputs
(Unscaling) ..................................................................245
Register-to-Register Scaling ........................................247
Analog Scaling Editor Commands .........................................247
Edit Menu....................................................................248
Search Menu................................................................252
Window Menu..............................................................253
Help Menu ...................................................................253
Analog Scaling Sizes and Execution Speeds ..........................254
Analog Scaling Summary ............................................254
Section 6 Version Tracking
Managing Your Versions........................................................258
Using the Comparison Commands ........................................258
Comparing Versions of Your I/O Configuration .........259
Comparing Versions of Your Shared Variables ..........261
Comparing Versions of Your Programs ......................264
Comparing Versions of Your Function Blocks............266
Section 7 Loading, Monitoring and Testing Application Programs
Connecting Your PC to the Regent........................................270
Initializing the Regent with WINTERPRET .............................271
Validating the Regent Equipment .........................................272
Validating the Functional Operations of Your System .........274
Placing the Validated Regent System On-Line......................278
R e g e n t User's Guide, Issue 4 ix

Table of Contents
Using the Execution Controller .............................................281

Application Program Execution ..................................281
File Menu.....................................................................284
Program Menu.............................................................284
Initialize Menu ............................................................290
Network Menu.............................................................294
Options Menu ..............................................................296
Window Menu..............................................................297
Help Menu ...................................................................298
Using the Program Monitor...................................................298
File Menu.....................................................................299
Control Menu ..............................................................300
Window Menu..............................................................306
Help Menu ...................................................................306
Monitoring Function Blocks ..................................................306
Commands Common to all Function Block Monitors ...........307
File Menu.....................................................................307
Control Menu ..............................................................308
Window Menu..............................................................309
Help Menu ...................................................................309
Using the Ladder Logic Monitor............................................309
File Menu.....................................................................310
Control Menu ..............................................................310
Search Menu................................................................311
Options Menu ..............................................................311
Using the Analog Scaling Monitor.........................................311
File Menu.....................................................................312
Control Menu ..............................................................312
Search Menu................................................................313
Regent System Operating States ...........................................313
State 0, Shipped from Factory.....................................314
State 1, Cold Start .......................................................315
State 2, TRIOS Loaded................................................315
State 3, Initialize, Load and Run ................................315
State 4, Operational.....................................................315
State 5, Time-Out ........................................................316
State 6, Stand-By.........................................................317
State 7, Restart Self Check..........................................317
x Industrial Control Services

Table of Contents
Section 8 Safety Considerations

Second Fault Occurrence Time..............................................319
Environmental Considerations..............................................319
Temperature ................................................................321
Humidity......................................................................321
Contaminants ..............................................................321
Vibration and Shock....................................................322
Electromagnetic Interference and Electrostatic
Discharge .....................................................................322
Power Supply Requirements..................................................324
Controller Assembly Power Supplies ..........................325
I/O Power Supply System............................................326
Using Multiple Input Power Sources ..........................326
Using an Uninterruptable Power Supply ...................330
Power System Isolation...............................................330
Requirements for Energize-to-Trip Applications........331
I/O Module Application ..........................................................333
Configuring I/O for Safety-Critical Applications ...................335
Safety-Critical Input Configurations .....................................336
Single Sensor, Multiple Input Modules.......................336
Redundant Sensors with Redundant Input
Modules........................................................................337
2oo3..............................................................................338
2oo2..............................................................................340
1oo2..............................................................................340
Midvalue Select............................................................341
Safety-Critical Outputs ..........................................................342
Fail-Safe Configurations .............................................343
Fault Tolerant Configurations ....................................343
Maintenance and Repair Requirements ................................344
Periodic Testing Requirements...................................345
Input/Output Testing ..................................................346
Application Software Requirements ......................................346
Internal Watchdog Timers ..........................................347
Using Software Overrides ......................................................348
Protecting External Communications ...................................350
Regent Application Requirements .........................................351
Host (Data Source) Application Requirements...........352
R e g e n t User's Guide, Issue 4 xi

Table of Contents
Maintenance Override.................................................353
Section 9 Troubleshooting
Maintenance...........................................................................358
Troubleshooting .....................................................................358
Fault Detection............................................................358
Fault Annunciation .....................................................360
Clearing Faults ............................................................363
Troubleshooting Techniques.......................................364
Troubleshooting with the Fault Indicators ...........................366
Processor Module Faults .............................................366
Primary Power Faults .................................................373
Communications Module Faults .................................375
I/O System Faults........................................................378
Using the Fault History Viewer.............................................387
Opening the Fault History Viewer..............................387
Fault History View Commands..............................................388
File Menu.....................................................................388
Controller Menu ..........................................................390
Window Menu..............................................................390
Help Menu ...................................................................391
Closing the Fault History Viewer................................391
Using the Fault History Viewer to Diagnose Faults .............391
Using the Fault Status Dialog Box ........................................392
Opening the Fault Status Dialog Box .........................392
Diagnosing Faults with the Fault Status Dialog
Box ...............................................................................393
Returning Failed Modules......................................................394
Repacking Modules for Shipping.................................395
Section 10 Additional Resources
The Readme File ....................................................................397
On-Line Help..........................................................................397
Add-In WINTERPRET Capabilities ..........................................398
Communications Package, T3831 ...............................398
Software Validation Package, T3835 ..........................398
Historian Package, T3832 ...........................................398
Math Package, T3833 ..................................................399
Continuous Control Package, T3834 ..........................399
xii Industrial Control Services

Table of Contents
Conversion Utilities Package, T3836 ..........................399

Hardware Product Descriptions ............................................399
R e g e n t User's Guide, Issue 4 xiii

Table of Contents
xiv Industrial Control Services

Section 1
Introduction
The Regent fault tolerant programmable controller is a micro-
processor-based controller with internal redundancy of all
critical circuits. The Regent's patented design offers the fol-
lowing features:
• High-speed real-time control of discrete and continuous
processes;
• Triplication of all critical components — no single point of
failure;
• Automatic detection of faults within internal circuits;
• Continued operations when faults occur;
• Hot-replacement of any failed module without affecting
operation.
Since the Regent can provide continuous operation in the
presence of faults — and supports full on-line hot-replacement
of all modules — it can approach 100 percent uptime.
The Regent controls complex and often critical processes in
real time, executing programs that accept external sensor sig-
nals, solve logic equations, perform calculations for continu-
ous process control, and generate external control signals.
These user-defined application programs control real-world
processes such as burner management, emergency shutdown,
fire and gas, turbine control, process safety interlocks, and
plant and equipment protection systems.
Programs for the Regent are written and monitored using the
Windows-based WINTERPRET application running on a per-
sonal computer.
Fault Tolerance, HIFT and TMR

Fault tolerance is the ability of a system to continue function-
ing predictably even if one or more of its components should
fail. True fault tolerance also provides for fully automatic re-
covery without disrupting operations.
R e g e n t User’s G u i d , I s s u e 4 1
HIFT stands for “hardware-implemented fault tolerance” —

indicating that the Regent relies on robust hardware circuits
(as opposed to complex software algorithms) to perform the
fault detection and redundancy management functions. An-
other significant advantage HIFT has over software-imple-
mented fault tolerance (or SIFT) is that HIFT eliminates the
overhead for communications between processors, leaving
more time for controlling the process. This makes HIFT sys-
tems significantly faster, and more reliable, than systems us-
ing software-implemented fault tolerance.
TMR stands for “triple-modular redundant.” This refers to
the redundancy scheme in the Regent, whereby critical cir-
cuits are triplicated and perform identical functions simulta-
neously and independently. Each of these triplicated circuits
is referred to as a “slice.” The outputs of the three independ-
ent circuits are voted in majority-voting circuits before affect-
ing the system's outputs. The Regent system uses TMR
throughout — providing continuous, predictable operation.
If any of the three redundant processors fails, the majority-
voting circuit automatically ignores the output from the failed
circuit. The system continues to output to the process the
value (voltage, current level, or discrete output state) that
agrees with the majority of the functional circuits. When such
discrepancies occur, the outvoted circuit is automatically de-
tected and flagged as failed, and can be removed and replaced
with a new module. This process of detection, flagging, and
replacement can be done with no downtime.
Figure 1 is a simplified block diagram showing the key ele-
ments of the Regent's TMR fault tolerant operation.
2 Industrial Control Services

Introduction Section 1
Figure 1. Key Elements in the Regent TMR System.
Regent User’s Guide, Issue 4 3

The Regent operates in the following sequence:
Process state information (transducer readings, switch posi-

tions, etc.) is sensed by the input modules.
Process state information is buffered by the input modules

and transmitted over three redundant data buses to the I/O
transceiver modules.
The I/O transceiver modules relay the process state informa-

tion along the I/O Safetybus™ to the TMR processor modules.

Synchronous I/O processors read state information and two-

out-of-three vote it before storing it in memory.
The main processors synchronously execute application pro-

grams during which all I/O, internal data and application pro-
gram instructions are voted.
I/O processors vote the output data and transmit the voted
values over the I/O Safetybus.

The I/O transceivers relay the output data from the I/O
Safetybus to the output modules.
The output modules receive the output commands from the

triplicated data bus and majority vote the information.
Output circuits are driven by the majority-voted command.

The Regent continuously repeats this operating sequence at
very high speed, providing continuous high-speed closed-loop
process control. If an internal circuit in the Regent fails, it is
simply out-voted. This comprehensive distributed voting both

out-votes failures, preventing them from being propagated

into the process, and simplifies the process of identifying
where faults have occurred.
Fail-Operational / Fail-Safe
Using the TMR principle, the Regent is designed to be “fail-
operational/fail-safe.” This means that when a failure occurs,
the Regent continues to operate: it is in a fail-operational
state. The system will continue to operate in this state until
the failed module is replaced and the system is returned to a
fully operational state. If, for any reason, the failed module is
not replaced before a second failure in one of the triple-redun-
dant circuits occurs, the second failure will cause the Regent
to shut down to a fail-safe state.
This fail-operational/fail-safe design is sometimes called 3-2-0
operation. This is because the system's normal operational
state uses three circuits, or slices. If one of these three slices
fails, the system will continue to operate using the two re-
maining slices until the failed slice can be replaced. If a sec-
ond failure should occur before the first failure has been re-
paired, the system will shut down.
The 3-2-0, fail-operational/fail-safe strategy is the only safe
and predictable strategy for a TMR-based system to use.

Figure 2. The Regent's Predictable Fail-Operational /

Fail-Safe Strategy.
Hot Replacement
The Regent's TMR architecture provides fault detection, isola-
tion, and containment, and hot replacement necessary for
high availability and true fault tolerance. In the Regent, the
fault cycle looks like this,
fault→ detection→ annunciation→ repair→ recovery
Hot replacement is the ability to repair faults without inter-
rupting system operation. Without hot replacement it would
not be possible to achieve continuous operation (since the sys-
tem would have to be stopped for repairs).
All the Regent’s modules can be hot replaced. New modules
are initialized without degrading system performance.

Figure 3. The Regent.

The Regent
As shown in Figure 3, the Regent has three main types of
hardware components: a controller assembly (top), I/O as-
semblies (middle), and I/O power supply assemblies (bottom).
Up to 32 complete, fully configured Regent systems can be
linked together using peer-to-peer communications.
The Controller Assembly

The Regent's controller assembly consists of a controller chas-
sis, three independent, redundant processor modules, and as
many as three communications modules. Each controller as-
sembly supports up to 16 I/O assemblies.
Figure 4. The Controller Assembly.

Controller Chassis
The controller chassis holds the system's three processor
modules and its communications modules. A triple-redundant
Safetybus on the backplane of the controller chassis handles
all communications voting within the controller assembly.
The controller chassis also contains external power terminals
(which let you to use up to three separate power sources),
three fault contacts (to indicate when faults have been de-
tected by the system), and connectors for two triple-redundant
I/O Safetybus channels.
Figure 5. Block Diagram of the Controller Assembly.

The controller assembly's power system provides triply re-
dundant internally regulated voltages to all the logic circuits
within the Regent. The controller assembly's power supply
system is separate from the I/O assembly's power supply sys-
tem.
Processor Modules
The controller assembly's three processor modules store and
execute application programs, scan and update the I/O mod-
ules, and detect system faults. Each of the processor modules
executes the application programs independently, but in lock-
step synchronization with the other two. And each processor
module independently communicates in lock-step synchroni-

zation with the I/O assembly over its own dedicated I/O
Safetybus link.
The front panel of each processor module has status and diag-
nostic indicator lights, a reset button, and a memory lock
keyswitch.
The reset button is used to clear errors and to synchronize an
uninitialized processor module with the two operating proces-
sors. The reset buttons on at least two separate processor
modules must be pressed to generate a reset signal. If two or
more processor modules require resetting (such as at power-
up) the reset signal will be generated automatically.
After a failed processor module is replaced, the new module is
initialized by pressing the reset buttons on the two operating
processors. All application programs and data are automati-
cally moved into the new processor module and the new mod-
ule is synchronized with the other two — without interrupting
system operation.
The memory lock keyswitch prevents programs in the proces-
sor modules from being changed or modified by WINTERPRET
or another system. When the memory is locked, programs and
status can still be monitored using WINTERPRET or another
system. The memory locks must be switched to on for at least
two processor modules to lock the memory. To prevent un-
authorized tampering, the keys can be removed from the
keyswitch in either position.
Inside each processor module is a main processor, an I/O proc-
essor, and a power supply. A battery inside each of the proc-
essor module maintains user application programs and the
downloadable portions of the system's RAMcode if there is a
power failure. Each processor module has interfaces to the
processor Safetybus and the I/O Safetybus. These interfaces
consist of an input voter, discrepancy detector logic, and an
output driver.
The processor modules also contain hardware voting and fault
detection circuits that continuously vote all data used during
system operation. These voting and fault detection circuits
allow the processor modules to identify and isolate transient,
intermittent, and permanent faults as they occur. All faults
are recorded in the system's fault history.

Each processor module contains its own power supply that

converts input power to the logic power levels used by the in-
ternal processor circuits. The failure of one power supply will
only effect one processor module — allowing the other two
modules to continue operating — thus keeping the Regent on-
line by virtue of its majority two-out-of-three voting architec-
ture.
Programs are stored in on-board battery-backed RAM.
Program instructions are fetched from each processor’s mem-
ory and executed by the processors. Data from inputs are read
from the I/O modules in the I/O assembly. The main proces-
sor coordinated the Regent’s activities and solves the applica-
tion algorithms programmed by the user. Outputs are driven
by transmitting data through the processor module’s I/O proc-
essor to the I/O assembly (see Figure 6).
Figure 6. Block Diagram of a Processor Module.

Communications between the main processor and the I/O
processor are maintained through shared RAM that is used as
a “mail box” for data transfers between the two processors.
The main processor places data in the shared RAM, and then
interrupts the I/O processor to signal that data is ready. The
main processor then releases control of the shared RAM to the
I/O processor. After the I/O processor has read the data from
the shared RAM, it writes the information to be transferred to
the main processor into the shared RAM. The I/O processor

then interrupts the main processor, signaling that data is

ready. This handshake protocol operates continuously and is
controlled by the operating system software in the two proces-
sors.
The controller assembly’s backplane wiring connects the out-
put drivers of each processor module to a different redundant
section of the I/O Safetybus, so that each section of the
Safetybus is driven by a different processor module. When a
processor module turns on its output driver to transmit data
to the Safetybus, it simultaneously enables its discrepancy
detection logic and compares the data it is transmitting on it
section of the Safetybus to the data on the other two sections.
As long as there are no discrepancies between the data on the
three sections of the Safetybus, operation continues normally.
If a processor module detects that the data it is transmitting is
not the same as that being transmitted on the other two sec-
tions of the Safetybus, the processor module is disabled and its
error indicator is set.
This detection logic is tested periodically to ensure its contin-
ued correct operation. Testing is done using self-tests that are
automatically scheduled by each processor module’s real-time
operating system.
Communications Modules
All communications modules provide at least two ports that
can support communications with WINTERPRET, other Regents
(Guarded Peer-Link), or Modbus Masters (most distributed
control systems and man-machine interface suppliers support
connections to programmable logic controllers using Modbus).
Communications modules are available to support different
types of communications interfaces, and may include a real-
time clock that can be used by the Regent for time stamping
historical logging features such as sequence of events record-
ing and the system’s process historian.
Four types of communications modules are available for the
Regent: a standard serial interface module, a real-time clock
module, an intelligent serial communications module, and an
intelligent communications module with serial and Ethernet
interfaces.

Standard communications modules have,

• Two ports,
• RS-232, RS-422, or RS-485 communications,
• Point-to-point or multi-drop connectivity.
Real-time clock modules have,
• Two RS-232 communications ports,
• Point-to-point connectivity,
• Battery-backed year, month, day, hour, minute, second,
and millisecond real-time stamping.
Intelligent communications modules have,
• Two ports (one serial, one configurable for either serial or
parallel),
• Serial interfacing for RS-232, RS-422, or RS-485 communi-
cations,
• Parallel interfacing for Centronics communications,
• Point-to-point or multi-drop connectivity,
and millisecond real-time stamping,
• Enhanced interfacing of historical data to external devices
(DCS, MMI, or direct printers).
Intelligent communications modules with Ethernet interfaces
have,
• Two ports (one serial, one configurable for either serial or
parallel),
• One additional port for Ethernet TCP/IP/802.3 communi-
cations,
• Serial interfacing for RS-232, RS-422, or RS-485 communi-
cations,
• Parallel interfacing for Centronics communications,
• Point-to-point or multi-drop connectivity,
and millisecond real-time stamping,
• Enhanced interfacing of historical data to external devices
(DCS, MMI, or direct printers).

There can be up to three communications modules of any type

or combination of types on each controller assembly.
The front panel of each communications module has commu-
nications ports and indicator lights showing port activity and
overall module health.
Figure 7. Typical Communications Module.

When a communications module receives data from an exter-
nal source, a buffer inside the module buffers the data and
generates three identical signals. These three signals are then
transmitted to the processor modules by way of the processor
Safetybus.
To transmit data to an external source, the processor modules
send the data along the Safetybus to the communications
module. The communications module then votes the data it
receives and transmits the voted signal through the communi-
cations driver to the external equipment.
Each communications module receives power from all three of
the processor modules. A power-sharing circuit in each of the
communications modules receives the power from the three
processor modules and combines it through a diode OR power-
sharing circuit. This ensures that if one processor module's
power supply fails, the communications module will continue
to operate by drawing power from the two remaining power
supplies, and the system's communications functions are
maintained.

The I/O Power Supply Assembly

The I/O power supply assembly provides power to the I/O as-
semblies. Each I/O power supply assembly is capable of pro-
viding power to as many as four fully configured I/O assem-
blies.
Figure 8. The I/O Power Supply Assembly.

The I/O power supply assembly consists of an I/O power sup-
ply chassis and three I/O power supply modules.
Figure 9. Block Diagram of the I/O Power Supply Assembly.

I/O power supply assemblies and I/O power supply modules

are available for 24 VDC, 110 VAC, or 220 VAC input power
voltages.
I/O Power Supply Chassis

The I/O power supply chassis holds the I/O power supply
modules. Each I/O power supply chassis has four DC output
connectors — allowing it to supply power to up to four I/O as-
semblies.
An input power filter suppresses input transients and distrib-
utes input power through the I/O chassis to the I/O power
supply modules. A fuse further protects the assembly.
I/O Power Supply Modules

Each of the triply redundant I/O power supply modules within
the I/O power supply assembly provides power for one slice of
the three redundant slices of the I/O Safetybus transceivers,
and provides power to all the I/O modules within its associated
I/O chassis. As with processor communications modules, each
I/O module contains a diode OR power-sharing circuit that
3receives power from all three I/O power supply modules.
Should any I/O power supply module fail, only one slice of the
transceiver modules will lose power: the two remaining slices
will maintain proper operation of the Regent. In addition, all
the I/O modules will continue to operate properly by drawing
their current from the two remaining power supplies within
the I/O power supply assembly.
Figure 10. Block Diagram of the I/O Power Supply Modules.

Each I/O power supply module has an indicator light to show
that the module's DC output is within tolerance. If the mod-
ule fails, or stops receiving input power, the indicator light

switches off. Failed I/O power supply modules can be hot re-
placed without interrupting system operation.
The I/O Assembly

The I/O assembly handles communications between the
Regent and the field devices being monitored and controlled.
The I/O assembly has an I/O chassis, three I/O transceiver
modules, and up to ten digital or analog I/O modules.
Figure 11. The I/O Assembly.

Each Regent system can have up to 16 I/O assemblies, each

I/O assembly can have a maximum of 10 I/O modules, and
each I/O module will typically have 16 I/O points (the number
of points will vary from 6 to twenty-four according to module
type).
Any combination of analog and digital I/O modules, in a vari-
ety of voltages and current ranges, can be installed on an I/O
assembly.
I/O Chassis
The I/O chassis houses the I/O transceivers and I/O modules.
The I/O assembly is connected to the controller assembly by
three I/O Safetybus cables; with each section of the I/O
Safetybus cable carrying data between one of the I/O assem-
bly's three transceiver modules and one of the controller as-
sembly's processor modules. A buffered I/O Safetybus at the
back of the I/O chassis handles communications to each of the
I/O modules in the chassis (see Figure 12).
Figure 12. Block Diagram of the I/O Assembly.

Each I/O chassis also has a fault mode jumper and ID
switches.
The fault mode jumper is used to set the I/O assembly's fault
mode to either switch all outputs off (shutdown mode) or hold
outputs in their last state (hold mode) if failures cause the

Regent to shut down. Power to the I/O assembly must be

maintained for this hold state to be valid.
The ID switches provide a unique identification by which the
controller assembly can identify each of the system's different
I/O assemblies.
I/O Transceivers
Each of the I/O assembly's three I/O transceivers receives data
from the I/O assembly's inputs, transmits the input data to its
associated processor module, receives output data from the
processor, and then buffers and re-transmits the output data
to the I/O assembly's outputs. All data are transmitted along
the I/O Safetybus cables.
Figure 13. Block Diagram of an I/O Transceiver.

Each I/O transceiver has two indicator lights. An ACTIVE in-
dicator shows when the module is transmitting data normally;
and a FAULT indicator shows when a fault has occurred within
the module. A failed transceiver module can be hot replaced
without interrupting system operation.
I/O Modules
The Regent’s I/O modules interface with field devices. Input
modules receive input signals from the field and output mod-
ules send output signals to the field.

There are four basic types of I/O modules: simplex input mod-
ules, simplex output modules, Monitored input modules, and
Guarded® output modules. Each of these module types can be
either analog or digital, and any combination of module types
can be installed in one I/O assembly.
I/O modules can be used either singly or in various redundant
combinations to extend fault tolerance out to the field devices.
Simplex Input Modules
Each simplex input module has input receiver circuits that
detect field signals, electro-optical isolation of up to 2,500
volts, Safetybus interface circuits, and a watchdog shutdown
timer.
Figure 14. Typical Simplex Input Module.

Digital simplex input modules receive data from discrete field
sensors such as limit switches, pushbuttons, and motor con-
tacts. Each module senses up to 16 binary-valued AC or DC
inputs. Input signals travel from the field sensors to the field
wiring terminals associated with each I/O slot on the I/O chas-
sis. When a module receives field data, it conditions the sig-
nal and electrically isolates, triplicates, and buffers it. The
data are then sent to the I/O Safetybus by way of the I/O
transceivers.
The front panel of each digital simplex input module has indi-
cator lights showing the overall status of the module as well as
indicators showing the status of each input point on the mod-
ule.

Analog simplex input modules receive data from transmitters

measuring process values such as temperature, pressure, and
flow. Each module measures 16 voltage inputs, which are
converted using a 12-bit A-to-D converter to produce 0 to
4,095 numerical readings that can be scaled in the user’s
application program. Input signals travel from the field
sensors to the field wiring terminals associated with each I/O
slot on the I/O chassis. When a module receives field data, it
conditions the signal and electrically isolates, triplicates, and
buffers it. The data are then sent to the I/O Safetybus by way
of the I/O transceivers.
The front panel of each analog input module has ACTIVE and
FAULT indicator lights showing the overall status of the
module.
Equipment for thermocouples or resistance temperature de-
vices (RTDs) includes an input module, a termination panel,
multiplexer, and interconnect cable. Thermocouple input
modules measure 24 type J, K, S, or T thermocouple inputs;
RTD input modules measure 16 100 Ω platinum RTDs. Both
are jumper-configurable for either Fahrenheit or Celsius
(centigrade) temperatures in units or in tenths resolution.
Figure 15. Typical Temperature Sensor Interface and Input

Module.
Input signals travel from the field sensors to a field termina-
tion panel. Low-level signal conditioning, A-to-D conversion,
and multiplexing of the inputs is performed on the multi-
plexer. Data from the multiplexer are serialized and transmit-
ted to the input module. A microprocessor inside the input

module automatically calibrates the multiplexer. The micro-

processor program includes digital notch filtering for 50 and
60 Hz. When the input module receives field data, it condi-
tions the signal and electrically isolates, triplicates, and buff-
ers it. The data are then sent to the I/O Safetybus by way of
the I/O transceivers.
The front panel of each temperature sensor input module has
ACTIVE and FAULT indicator lights showing the overall status
of the module as well as indicators showing multiplexer faults;
the thermocouple module has an additional indicator showing
cold junction faults.
Simplex Output Modules
Each simplex output module has Safetybus interface circuits,
electro-optical isolation of up to 2,500 volts, output driver cir-
cuits, and a watchdog shutdown timer (Figure 16).
Digital simplex output modules drive field devices such as ac-
tuators, solenoids, valves, pumps, and motors. Each digital
output module provides up to 16 output switches for AC or DC
voltages. Triplicated output signals are sent by the processor
modules, by way of the I/O Safetybus and I/O transceivers, to
the digital output modules. The three signals are voted by the
module and a single signal is sent to the field device.
The front panel of each digital simplex output module has
indicator lights showing the overall status of the module as
well as indicators showing the status of each output point on
the module.
Analog simplex output modules are used to drive field devices
such as valve positioners, control motor speed, and drive dis-
play meters. Each analog simplex output module provides
eight 4-20 mA outputs driven by a 12-bit D-to-A converter.
Triplicated output signals are sent by the processor modules,
by way of the I/O Safetybus and I/O transceivers, to the digital
output modules. The three signals are voted by the module
and a single signal is sent to the field device.
The front panel of each analog simplex output module has
ACTIVE and FAULT indicator lights showing the overall status
of the module.

Figure 16. Typical Simplex Output Module.
Multiplexed I/O Modules

Each multiplexed I/O module has Safetybus interface circuits,
a microprocessor, and two isolated serial interfaces to com-
municate with external remote multiplexed I/O equipment.
Multiplexed I/O modules are used to provide an economical
serial interface to inputs and outputs for matrix and mimic
displays in fire and gas systems or other applications requiring
simplex remote multiplexed digital I/O.
Two RS-422 serial communications ports can detect 512 digi-
tal inputs and 256 digital outputs. The communications ports
can be configured as either a simplex or dual for added
reliability and protection. In a dual configuration the
information is tested on a two-out-of-two basis.
Figure 17. Typical Multiplexed I/O Module.

The front panel of each multiplexed I/O module has ACTIVE

and FAULT indicator lights showing the overall status of the
module as well as indicators showing the transmit, receive,
and fault status of each port.
Monitored Input Modules
Monitored digital input modules and fire detector input mod-
ules employ special input conditioning circuits that provide
complete automatic testing of the module’s circuitry. This
testing fully detects stuck on and stuck off input module cir-
cuit faults. When an input circuit fault is detected, the input
state reported to the application program is set to the safe
(input tripped) state.
Additionally, each module can monitor the field input wiring
to differentiate between switch open and switch closed states
and wiring open and wiring short circuit faults. This line
monitoring is point-by-point configurable.
Line monitored digital inputs require a line monitor device
(series-parallel resistor network) connected across the field
input switch. Fire detector inputs require a terminator at the
end of the fire detection input loop. In both modules line
faults are indicated on the module’s front panel and reported
back to the Regent for use in application programs.
Fire detector input modules provide 16 input loop interfaces
for devices such as smoke detectors, flame detectors, tempera-
ture detectors, and manual alarm call points. Each channel
can support up to 10 detectors on a two-wire loop, and each
field loop is monitored for normal and alarm conditions as
well as open and short conditions. Fire alarm status and line
fault status are reported back to the Regent for use in applica-
tion programs.
The input module controls the individual channel reset volt-
age to the input loops through commanded data from the ap-
plication program.

Figure 18. Typical Monitored Digital Input Module.

When a Monitored digital input module or fire detector input
module receives field data, it conditions the signal and electri-
cally isolates, triplicates, and buffers it. The data are then
sent to the I/O Safetybus by way of the I/O transceivers.
The front panels of Monitored input modules and fire detector
input modules have indicator lights showing the overall status
of the module as well as indicators showing the status and line
fault of each input point on the module.
Guarded Output Modules
Guarded output modules have redundant circuits designed to
ensure the fail-safe operation of each output. Each Guarded
output module is designed either to operate properly or to fail
to a safe, high-impedance output state if one of its internal
circuits should fail.
Another feature of the Guarded output modules is that they
can be wired in parallel to provide full fault tolerance for out-
put drive signals. When two Guarded output modules are
wired in parallel, they can both drive the actuator device
(digital Guarded modules will both operate at the same time,
while analog Guarded modules will have one active module
with the other in a stand-by mode). If either module fails, it
fails to the high-impedance state, leaving the parallel module
to continue controlling the output.

Figure 19. Typical Guarded Output Module.

The front panel of each Guarded digital module has indicator
lights showing the overall status of the module as well as indi-
cators showing the status of each input point on the module.
Flexible Architecture
The Regent’s architecture provides a flexibility that allows
each system to be easily adapted to the different needs of any
installation. This flexibility lets you choose from different
levels of I/O fault protection (which can vary from point to
point according to the needs of your installation) and provides
a wide variety of communications methods allowing the
Regent to communicate with other equipment.
In addition, the Regent can be easily reconfigured to meet
changing needs or expanded to accommodate future growth.
Classes of I/O Protection

The Regent's flexible architecture lets you choose from four
different classes, or levels, of I/O fault protection, and to mix
and match different classes of protection within a system.

Figure 20. Classes of I/O Fault Protection.
Class I: Non-Critical I/O Solutions

Simplex inputs and outputs can be used for non-critical I/O
points to reduce overall costs. Simplex I/O modules retain the
benefits of a secure TMR interface to the processors; while
input signal conditioning and output driver circuits have the

same failure characteristics as standard, non-redundant pro-

grammable controller I/O modules. Inputs use single signal
conditioners and outputs use single transistors, TRIACs, or D
to A converters.
In safety-critical applications, simplex inputs and outputs are
certified to be non-interfering with other Regent equipment
involved with safety functions.
Figure 21. Fault Protection in Non-Critical I/O.
Class II: Fail-Safe I/O Solutions

Fail-safe I/O provides either continued correct operation or
failure to a predictable (de-energized, or off) state in the event
of an I/O circuit failure.
Monitored inputs provide this fail-safe capability through
complete diagnostic testing of all input-sensing circuits. This
testing automatically detects what would otherwise be stuck-
on or stuck-off failure modes of the input circuits. When such
a failure occurs, the fault is annunciated and the input state to
controller becomes the safe off state.

Figure 22. Fault Protection in Fail-Safe I/O.

Guarded outputs provide this fail-safe capability through re-
dundant logic and drive circuits. Each Guarded module has
drive circuits connected in series that automatically test for
turn-on and turn-off capability. This series arrangement be-
comes fail-operational should one drive circuit fail to on; and
becomes fail-safe if a drive circuit fails to off.
Both Monitored input modules and Guarded output modules
test and annunciate field wiring open, short, and load (output)
failures.
Class III: Fault Tolerant I/O Solutions

Fault tolerant I/O uses redundant I/O modules connected in
parallel to the field devices — providing complete fault toler-
ance in the presence of any I/O module fault.
In fault tolerant configurations, the field devices are con-
nected to each of the redundant modules, and each module is
addressed by the application program.
For fault tolerant inputs, redundant input modules (either
simplex or Monitored) are installed in parallel and connected
to the same input device. If an input module fails, the system

will continue to operate using the remaining module while the

failed module is hot-replaced.
For fault tolerant outputs, redundant Guarded output mod-
ules are installed in parallel. For digital outputs, both mod-
ules send signals to the output device. For analog outputs,
only one of the two modules is allowed to send outputs at a
time, if a fault occurs in this “on-line” analog module, control
is automatically switched to the second module in less than a
millisecond. Both digital and analog output modes can be hot-
replaced using this configuration.
Figure 23. Fault Protection in Fault Tolerant I/O Modules.
Class IV: Redundant Sensor and Actuator Solutions

When redundant sensors and actuators are used, fault protec-
tion is extended to include field devices for the highest level of
process availability and reliability.
Because this class of protection uses the same module configu-
ration as Class III, and does not require any additional in-
vestment in modules or system configuration, fault tolerance
can be extended to sensors and actuators on a per-point basis
simply by adding redundant field devices and wiring.

Figure 24. Fault Protection Extending to Sensors and

Actuators.
Communications
The Regent system supports a variety of communications con-
figurations including the WINTERPRET application, Guarded
Peer-Links, operator interfaces, historical logging, and alarm
logging.
The WINTERPRET Application

WINTERPRET is used for developing application programs. On-
line features support program loading, monitoring, and trou-
bleshooting.
A central computer running WINTERPRET can be connected to
multiple Regents through a multi-drop RS-485 network run-
ning Regent R2 protocol.

A local, or portable, computer running WINTERPRET can be

connected directly to any serial port for local system trouble-
shooting.
Guarded Peer-Link
The Guarded Peer-Link provides secure peer-to-peer commu-
nications for up to 32 Regent controllers over single or redun-
dant links. These communications links allow Regents to pass
safety-related data among each other.
Figure 25. Different Types of System Communications.
Operator Interfaces
Safety systems are typically connected to an operator inter-
face. These operator interfaces may be a local PC, a DCS, or a
host computer. The Regent can be connected to any of these
interfaces in point-to-point or multi-drop networks using
Regent R2, Modbus, or Ethernet TCP/IP/802.3 communica-
tions links.
When communications redundancy is required (and supported
by the operator interface equipment), the redundant links are
simply connected to different ports on two the Regent’s com-
munications modules.

Historical Logging
The Regent provides valuable sequence of events and process
historian logging functions within the TMR processors. This
historical information can be presented to plant operators and
maintenance personnel in a variety of ways.
• The Regent can be configured to log historical information
to a printer connected directly to an intelligent communi-
cations module.
• A local or central PC running WINTERPRET’s historical col-
lection software can be used for archiving, logging, and
displaying sequence of events and process historian infor-
mation.
• The intelligent communications module also supports ac-
cess to historical data by DCS equipment and other opera-
tor interfaces supporting Regent R2 or Ethernet
TCP/IP/802.3 protocols.
Alarm Logging
ASCII output messages configured within the Regent’s appli-
cation programs provide custom alarm and report logging to
printers connected directly to any Regent communications
module.
The W INTERPRET Application

Programming, program maintenance, and hardware configu-
ration for the Regent are all done on a personal computer
running the easy-to-use Windows-based WINTERPRET applica-
tion.
By following Microsoft’s Windows standards, WINTERPRET
provides a consistent set of graphical components — windows,
pull-down menus, dialog boxes, command buttons, option but-
tons, text boxes, list boxes, help files, and other features that
apply equally to everything that WINTERPRET does.

Figure 26. Some of WINTERPRET’s Development Tools.

WINTERPRET is an integrated set of development tools that
lets you define how the Regent will function. WINTERPRET is
used to,
• Configure I/O points;
• Develop and compile application programs;
• Load application programs into the Regent;
• Control and monitor programs running in the Regent;
• Document programs;
• Provide system security;
• Assist in maintenance and troubleshooting.
The Regent is programmed much like any conventional pro-
grammable controller. All applications programming and
documentation can be done off-line in the convenience of your
office. When downloaded, all programs are automatically trip-
licated by the Regent system —with all triplication being done
transparently.
WINTERPRET provides several languages for developing appli-
cation programs. These languages include,
• Ladder logic
• Analog scaling

• Sequence of events recording

• Process historian
• Continuous control
• Floating point math
Application programs can be developed using any combination
of these different languages.
The application programs are loaded into the Regent over a
communications link between the personal computer running
WINTERPRET and the Regent. The computer running
WINTERPRET can also remain connected to the Regent to
monitor the status of your application programs and the proc-
esses they control.
Projects, Programs and Function Blocks

WINTERPRET works with three basic categories of information.
These are projects, programs, and function blocks.
Projects
A project associates a set of programs with a particular
Regent. The ability to have multiple projects makes it possible
to use a single computer running WINTERPRET to configure,
program, and monitor up to 32 Regents.
Programs
A program, sometimes called a user application program, con-
sists of a set of function blocks and the variables that are as-
signed to them. Each program can have as many as 100 func-
tion blocks.
Programs for the Regent are developed in they same way as
programs for a conventional, non-redundant controller. No
special programming is required to coordinate the triplication
inherent in the Regent.
The Regent can run as many as 30 completely independent
programs at one time — with each program controlling a dif-
ferent process or part of a process.
Programs are executed in the order in which they are started,
with each program finishing its tasks before the next program
begins. Individual programs within the Regent can be started,
stopped, modified, single-scanned, and deleted.

Programs can be easily copied from one project to another.
Function Blocks
Function blocks are the basic building blocks of a program.
Each function block exists as both source and object. The
source for each function block is created using one of
WINTERPRET's language editors and then compiled into a
common object format. The compiled object code is then
loaded into the Regent for execution.
Because all function blocks are compiled into object format,
different types of function blocks can be combined to create an
application program.
Function blocks can be easily copied from one program to an-
other.
Data Structure
There are three types of data in the Regent: variables
(internal data values that can be accessed by a program's dif-
ferent function blocks), which can be either I/O, shared, or
local.
I/O names are defined using the Configuration Editor. Shared
variables are defined using the Shared Variable Editor.
WINTERPRET combines all the variable names and tag names
into a dictionary. This dictionary contains a list of all the
names that are common between function blocks.
I/O
I/O consists of the system’s digital and analog input and out-
put points. User-defined I/O points are similar to shared vari-
ables in that they can be accessed by any function block.
Shared Variables
Variables that are global, or shared by any function block in
any program. A shared variable must be defined as either a
control relay, register, or floating point register. In addition
to user-defined shared variables, there are also predefined
system variables.
Local Variables
Local variables are used only within one program. A variable
is local because it is not defined as a shared variable or an I/O

point. A local dictionary for each program maintains all local

program data.
Tag Names
Tag names are used to reference all three types of data. Tag
names begin with a letter and consist of between one and
twelve alphanumeric characters. Tag names are used as pro-
gramming references.
Working with WINTERPRET

WINTERPRET has a number of features for creating and man-
aging projects, programs, and function blocks. These include,
• Project Selector
• Project Editor
• Execution Controller
• Fault History Viewer and Fault Status Dialog Box
• Configuration Editor
• Shared Variable Editor
• Program Editor
• Program Monitor
• Program, configuration, and version management
• On-line Help
Along with these features, each different type of function
block has its own editor and monitor.
Project Selector
The Project Selector lets you create new projects, open pro-
jects that you want to work with, and delete old projects.
You can also use the Project Selector to add or change
WINTERPRET system users, their classifications, and their
passwords.
Project Editor
The Project Editor lets you add new programs, open programs
that you want to work with, and delete old programs. The
Project Editor also opens the Execution Controller, Fault
History Viewer, I/O Configuration Editor, and Shared
Variable Editor.

Figure 27. The Project Editor and Project Selector.
Execution Controller
From the Execution Controller you can load, run, stop, single-
scan, and monitor your application programs. You can also
force I/O points and shared variables to desired states.
Fault History Viewer and Fault Status Dialog Box

The Fault History Viewer lets you view, save, and print fault
history information that has been accumulated by the Regent.
The Fault History Viewer's list box displays a chronological
list of all the faults, warm starts, and voted resets that have
occurred in the Regent.
The Fault Status dialog box lets you view the Regent’s current
fault conditions. This dialog box displays fault annunciations
for each module, and lets you print the current fault status or
initiate a voted system reset.
I/O Configuration Editor

Since the Regent does not have a predetermined numbering
scheme that relates each I/O point to its position in the I/O
assembly, each I/O point is given a tag name of up to 12 char-
acters to uniquely identify it within the system. The
Configuration Editor lets you assign tag names and designate
the type and position of each module in the Regent's I/O as-
sembly.

Shared Variable Editor

The Shared Variable Editor lets you define the names of the
internal control relays and registers used in application pro-
grams. These shared variable names are combined with the
I/O names to form the system's dictionary — and provide a
common data reference between programs.
Program Editor
The Program Editor lets you open the function block editors
and edit a program's function blocks. You can also use the
Program Editor to print your programs.
Figure 28. The Program Editor.
Program Monitor
The Program Monitor lets you monitor, force, run, stop, and
single-scan your programs. The Program Monitor also opens
the various function block monitors.
Function Block Editors and Monitors

Each different type of function block has its own editor and
monitor. The function block editors are used to create and
edit the function blocks. Using the function block monitors
you can run, stop, single-scan, and monitor individual func-
tion blocks.

Program, Configuration and Version Management

Each time the system’s I/O configuration, shared variables,
programs, or function blocks are edited and the changes saved
a new version is created and the version number increments.
Before changes are saved, WINTERPRET prompts you for a de-
scription of the reasons for the changes. This description be-
comes part of the version’s history.
Previous versions are kept by WINTERPRET so that during de-
velopment each version’s descriptive history can be displayed
to assist in tracking and managing revisions. By saving and
describing previous versions it is possible to return to them if
necessary.
Another benefit of tracking file versions is the ability to com-
pare one version to another and see specifically what has been
changed. WINTERPRET’s automated source comparison indi-
cates which elements have been added, deleted, or modified —
making it an invaluable tool for program and configuration
management and recording.
Figure 29. A Sample Program Version History Display.

WINTERPRET also provides a number of sophisticated tools for
documenting programming and configuration information.
• Names and descriptions are attached to every project, pro-
gram, function block, and tag;
• File details are attached to every project, program, and
function block;
• Tag descriptions automatically link to elements in function
block displays and printouts (even during monitoring);
• Ladder logic rung comments allow detailed annotation of
each element of function.

These features ensure that WINTERPRET can meet even the

most stringent tracking and management requirements.
On-Line Help
On-line Help is a quick and convenient way to look up infor-
mation about a task you are performing, a feature you would
like to learn more about, or a command you want to use. Help
is always available either by pressing F1 or by clicking on the
Help command.
Figure 30. An On-Line Help Topic.
Programming Languages
WINTERPRET's programming languages allow someone with a
knowledge of process control to develop application programs
for the Regent without requiring a detailed understanding of
computer programming.
These application programs consist of one or more logical
units called function blocks. Each type of function block has
its own editor for creating and modifying source files. The
appropriate editor is invoked automatically when you open a
function block.
Although function blocks differ in both appearance and func-
tionality, they can be combined with other types of function
blocks to create a complete application program.

Ladder Logic
Ladder logic function blocks let you define logic equations and
control sequences in a graphical form using standard
ANSI/NEMA symbols for relay, coil, logic, and math elements.
ASCII output functions within ladder logic function blocks let
your program transmit messages through the Regent's com-
munications ports to an external device such as a terminal or
printer. ASCII output messages can contain text as well as
the values of the variables used by the program.
Figure 31. The Ladder Logic Editor.
Analog Scaling
Analog scaling function blocks provide an efficient way of con-
verting analog values to scaled units.
Sequence of Events Recording

Sequence of events function blocks are used to create a history
of the changes in the Regent's I/O states and variable values.
Sequence of events history files can be monitored in real-time,
printed, and saved.

Figure 32. The Sequence of Events Editor.
Process Historian
Process historian function blocks let you record and times-
tamp the values of selected process variables. In a typical ap-
plication, the process historian begins recording when a start
signal is received. At defined intervals, the process historian
records values and timestamps in an event list. When a reset
signal is received, the process historian clears the event list
and waits for a new start signal.
Floating Point Math

Floating point math function blocks let you write expressions
to be evaluated, using floating point math, integer, and logical
variables.
Continuous Control
Continuous control function blocks let you keep a measured
process signal at a desired value, provided that the process
has,
1. A measurable process variable;
2. A setpoint at which the process variable is to be main-
tained;

3. A control variable that causes the process variable to

change;
4. A set of rules for how the control variable should be
changed to make the process variable equal to the setpoint.
Control loops can be cascaded within a function block to form
a master-slave arrangement in which the control output of the
master is the setpoint for the slave.
System Security
WINTERPRET has several security features that help guard
against accidental changes to critical operational parameters
such as application programs, configuration data, and the
status of the programs in the Regent. WINTERPRET's security
measures are flexible; they can be made as stringent or as le-
nient as desired.
Password Protection and Classifications

Each person using WINTERPRET must log on by entering their
name and password. Associated with each user is a classifica-
tion that can be used to restrict a user's access to various fea-
tures within WINTERPRET. Classifications allow access to
WINTERPRET’s features to be consistent with user-defined job
classifications or descriptions. Users logging on to the system
without a valid name and password are given a classification
with no access rights and cannot make any changes; they may,
however, browse through the secured files.

Figure 33. Each User has a Name, Classification, and

Password.
User names, passwords, and classifications are set up by a sys-
tem administrator. Name, password, and classification infor-
mation is stored in an encrypted password file.
Communications Protection
Communications protection lets you explicitly identify vari-
ables that are not to be overwritten by any type of external
communications. These protected variables become read-only
variables.
Inter-Program Access Protection

Programs are given ownership of the variables they control;
other programs can only read these variables, they cannot
write to them. This ensures that programs cannot violate
each other’s control variables.
Confirmation Protection
WINTERPRET requests a confirmation before allowing any
changes to be made to the status of the Regent. These con-
firmations help make certain that the user is aware of the ac-
tion about to be taken and provide a convenient way of termi-
nating unintended actions.

TÜV Certification Compliance

Both the Regent control system and the WINTERPRET applica-
tion software have been independently certified by the
German government's Technischer Überwachungs-Verein
(TÜV) to meet the requirements of Risk Class 5.
TÜV certification is recognized throughout the world, with
many companies specifying that only TÜV-certified safety
systems be used in their safety-critical processes.
Conditions and configurations that must be adhered to if the
system is to remain in compliance with the requirements of
Risk Class 5 certification are clearly marked with a TÜV
symbol.
For more information about the Requirements of Risk Class 5
certification, please see Section 8, Safety Considerations.

Section 2
Installing the Regent

Hardware
The procedures described in this section for installing hard-
ware can also be used when replacing failed components or
changing the system's hardware configuration.
In addition to installing the Regent hardware you will also
need to install the WINTERPRET application software and con-
figure your system. For more information about installing the
WINTERPRET application software see Section 3, Installing the
WINTERPRET Application. For more information about con-
figuring your system see Section 4, Working with Projects.
Installation Planning
The following planning information provides general guide-
lines that are applicable to most installations. Some installa-
tions will, however, require special installation considerations.
In such instances, please contact ICS for assistance.
Equipment Mounting
The Regent's design gives you the choice of front or rear
mounting. Each chassis is provided with removable-reversible
mounting brackets. With the brackets mounted to the rear of
the chassis, the chassis can be rear mounted using RETMA
Standard RS-310-B rails spaced for 19-inch panels. With the
brackets mounted to the front of the chassis, the chassis can
be front mounted inside RETMA rails.
Each Regent chassis is mounted using eight 10-32 x 1 bolts.
You will need eight bolts for each chassis you are mounting.
If you are mounting the chassis in a rack or panel that is not
pre-drilled, you will need a drill motor, a #21 drill bit, and a
10-32 tap.
R e g e n t User's Guide, Issue 4 49

Assembly Weights
Before mounting any of the assemblies' chassis, be sure that
the mounting location can support the weight of the assembly
being mounted. Table 1 provides a guide to the weights of
each assembly fully loaded with modules.
Table 1. Assembly Weights.
Controller Assembly 60 lb. (27 kg)
I/O Power Supply Chassis 45 lb. (20 kg)
I/O Chassis 75 lb. (34 kg)
Environmental Considerations
The Regent's environmental requirements are shown in Table
2.
Table 2. Environmental Considerations.
Operating Temperature
(inside enclosure) 32 to 140° F (0 to 60° C)
Storage Temperature -40 to 185° F (-40 to 85° C)
Humidity 0 to 95% non-condensing
Vibration and Shock 1.5g sinusoidal sweep, 55 to 200
Hz
EMI/RFI Tested to MIL-STD 461A, IEEE
STD 472, FCC Class A.
Input transient tolerance to 300
volts.
Static discharge tolerance to 5.5K
volts.
Tolerant to radiated fields of 10
v/m 14 kHz to 1 GHz.
For special safety and environment considerations see Section

8, Safety Considerations.
Heat Dissipation
To ensure proper ventilation and heat transferal, always allow
a minimum clearance of 3 inches (8 cm) around all sides of
each chassis and a minimum clearance of 6 inches (16 cm)
above the top chassis in an enclosure.
If adequate clearance is provided and the ambient air tem-
perature outside each unit is under 140° F (60° C), the assem-

Installing the Regent Hardware Section 2
blies will be operating within their specified temperature

ranges.
For calculating the heat rise inside enclosures, the following
are typical power dissipations for the Regent's assemblies and
I/O modules.
Table 3. Dissipation Values.
Controller Assembly 200 watts
I/O Power Supply Assembly 75 watts
I/O Assembly (without I/O modules) 25 watts
Input Module 10 to 20 watts
Output Module 15 to 30 watts
Power Consumption
The power and current requirements for each assembly are
shown in Table 4. The requirements shown in this table are
the maximum requirements for a fully configured system
(three communications modules, 40 I/O modules) and should
be used when determining your system's primary power dis-
tribution. Inrush current is for one AC cycle (approximately
20 msec).
Table 4. Typical Power Consumption.
Cont. Inrush Cont.
Voltage Current Current Watts
Controller Assembly 24 VDC 8 amps 180 amps 200
110 VAC 2 amps 60 amps 200
220/240 1 amp 120 amps 200
VAC
I/O Power Assembly 24 VDC 20 amps 360 amps 500
110 VAC 5 amps 120 amps 500
220/240 2.5 amps 240 amps 500
VAC
If triple-redundant power feeds are used in your system, the

current requirements for each feed should be the total divided
by three.

Power Distribution
Primary AC or DC power must be provided to both the con-
troller assembly and the I/O power assembly. The recom-
mended power distribution arrangement is shown in Figure
34. The power for the Regent equipment should be provided
from the isolated instrument power source.
Figure 34. Regent Power Distribution.

The I/O power supply assembly provides logic power to the I/O
assemblies — not field power to I/O devices such as sensors
and actuators.
Important! Do not connect field devices or field device power supplies to
the isolated instrumentation power source. Primary AC/DC
power for field devices must be provided by the user and must
be provided from a separate power source.
Important! The field device power must be referenced to ground through
the green safety ground conduit.
Two alternate primary power schemes are shown in Figure 35.
At the top of the figure, three separate power connections are
provided by three separate panels. As shown, all three panels
must share a common ground. There is no requirement that
all three feeds be of the same phase. At the bottom of the fig-
ure, the power inputs are shown daisy-chained.
Figure 35. Regent Power Connections.

If separate power feeds are used for redundancy, you must be

aware that if there is a power failure, on resumtion of power a
voted reset needs to be initiated to clear any system faults.
I/O Power Supply Assembly Loads

Each I/O power supply can provide power for up to four I/O
assemblies in the Regent system. The maximum number of
I/O assemblies powered is limited by the number of power
connectors provided (four) and by the power consumed in each
I/O assembly. Calculating the number of load units in your
system will help you determine the number of I/O power sup-
plies your system will need.
Table 5 shows the number of available load units available
with one to four I/O chassis (the available load units decrease
as you add I/O chassis because each I/O transceiver on the
chassis uses 1.33 load units).
Table 5. Available Load Units.
Number of Available
I/O Chassis Load Units
1 52
2 48
3 44
4 40
The load units consumed by each type of module in the I/O as-
sembly are shown in Table 6.

Table 6. Load Units.

Load
Part Number Description Units
T3401,02,04,08 Digital Inputs 1.15
T3411,11F,18F Monitored Digital Input 0.85
T3419 Fire Detector Input 0.85
T3420A,AF Analog Inputs 1.85
T3431A Thermocouple Input 1.80
T3432 RTD Input 1.80
T3441A DC Digital Output 0.80
T3444 AC Digital Output 0.80
T3446H,L Relay Output Module 1.00
T3454 Isolated AC Digital Output 0.75
T3461,62,68 DC Guarded Output 1.05
T3461A,62A,68A DC Guarded Output 0.85
T3464 AC Guarded Output 1.50
T3470A Analog Output 0.50
T3480 Analog Guarded Output 0.80
T3481,82,84,88 Monitored Guarded Output 1.50
T3485 Isolated Guarded Output 1.50
T3491 Multiplexed I/O Module 1.00
Calculate the load units required by your system to ensure

that the power consumed does not exceed the available power.
Power Filtering, UPS

AC power system quality problems generally consist of loss of
power, intermittent noise, low voltage, or transients and
surges on the power line. While the Regent system is designed
to be robust in the presence of low-quality AC power, addi-
tional measures will have to be taken in extreme cases.
An isolation transformer will solve most AC power quality
problems — except for loss of power. The isolation trans-
former should have a ferromagnetic shield and the neutral
line should be connected to the safety ground at the output.
When loss of power or low line power is the problem, the only
cure is to use an uninterruptable power supply (UPS). A

commercially available UPS designed for use with computer

systems containing switching power supplies and rated for the
loads described above in Power Consumption will be adequate
in most cases.
Grounding
Grounding can be divided into two categories: safety ground-
ing and EMI grounding.
Safety Grounding
In the controller assembly, safety grounding is provided
through the primary power connection. All three ground ter-
minals on each input power assembly in the system must be
connected to the power system safety ground. The ground
terminal on the I/O assembly must also be connected to a
suitable safety ground.
EMI Grounding
In the lower left hand corner of each chassis is a ground ter-
minal. Besides serving as the primary safety ground for the
I/O assembly, these terminals can provide additional high fre-
quency (EMI) grounding between multiple chassis in a single
system.
There are two methods that you can use for EMI grounding,
1. The ground terminal on each chassis in the local Regent
system should be connected to a single-point ground (such
as a bolt on the cabinet) using a 0.5 inch (13 mm) ground
braid soldered to a ring lug.
2. Alternatively, the ground braid can be connected between
the chassis ground terminal and the equipment mounting
rails. This method is acceptable only if all Regent equip-
ment is located in a single cabinet or in multiple cabinets
that are welded together.

Cabling
Cabling Multiple I/O Assemblies to a Controller
Assembly
The maximum distance between the controller assembly and
the last I/O assembly in the daisy-chain cannot exceed 150
cable feet (45 m).
Cabling I/O Power Supply Assemblies
The maximum distance between the I/O power supply assem-
bly and any I/O assembly it is powering cannot exceed 30 cable
feet (9 m).
Figure 36. Regent Cable Connections.
Cable and Wire Routing

Wires of different voltages and power levels should be kept
separate (they should, for example, be run in separate race-

ways and conduit). Specifically, there are five types of wiring

that should be separated,
1. Regent primary power wiring (power going to the control-
ler assembly to the I/O power supply assembly);
2. Regent secondary power wiring (power cables from the I/O
power supply assembly to the I/O assembly);
3. Regent internal communications cables (triplicated I/O
Safetybus cables);
4. Low voltage field wiring (less than 60 VAC/DC);
5. High voltage field wiring (greater than 60 VAC/DC.
While it is often impossible to totally separate wires of differ-
ent categories, the lengths of parallel runs should be mini-
mized and distance between the wires should be maximized
(do not tie-wrap the Safetybus cables together with the pri-
mary power for the Regent). Wiring for devices other than the
Regent can be mixed with the same category.
The product descriptions for each I/O module contain detailed
wiring requirements for each type of I/O module.
Hardware Installation
The instructions for installing the Regent hardware have been
divided into a series of specific tasks and arranged in chrono-
logically logical sequence. This installation sequence is de-
signed to make installing the Regent hardware as quick, and
as easy, as possible.
Important! Before performing any type of meggering test, always discon-
nect all line filters and remove all modules from their chassis.
Delivery and Inspection

When you receive the Regent, carefully inspect all the ship-
ping cartons for damage. If any cartons are damaged, make a
note of the damage on the carrier's shipping document before
signing it. If any part of the system has been damaged during
shipping, notify the carrier and ICS immediately. Save any
damaged cartons for inspection by the carrier.

Unpacking
Before unpacking any of the Regent components, be sure to
take the following precautions:
1. Modules contain static-sensitive components that can be
damaged by small amounts of static electricity. Do not
touch the module connectors as doing so may cause dam-
age due to electrostatic discharge.
2. Do not remove components from their antistatic bags until
you are ready to install them. When you do remove the
components, observe proper handling procedures to avoid
possible damage due to electrostatic discharge.
3. The EMI gasket material on the chassis and modules is
fragile. Be careful not to touch the gasket (as this can
leave oil residues that will impair its effectiveness) or dam-
age the gaskets’ flanges.
4. Save all shipping materials to use should it be necessary to
transport or ship any of the Regent components. Never
ship the Regent with modules installed. If the Regent is to
be moved to another site after being mounted in an enclo-
sure, the modules must be removed and shipped in their
original packaging.
The Regent components are packed according to the specific
hardware and configuration requirements of your system.
Installing the Controller Chassis

The controller assembly includes a controller chassis, three
processor modules, and up to three communications modules
(or a combination of communications modules and communi-
cations module blanks).
The mounting brackets for the controller assembly are simi-
lar, but not identical. The left bracket in a front mount con-
figuration is reversed and used as the right bracket in a rear
mount configuration (and vice versa).

Figure 37. Controller Chassis Mounting Dimensions.

After installing the mounting brackets on the controller chas-
sis, mount the chassis to the mounting panel or rack.
If you are mounting the chassis to a panel, drill and tap eight
10-32 holes in the panel. Refer to the dimensions shown in
Figure 37.
Align the mounting brackets with the holes in the rack or
panel and attach the controller chassis using eight 10-32 x 1
bolts.
Three sets of fault contact terminal blocks are provided on the
controller chassis. Each set of contacts has three #6 wire
clamp screw terminals (labeled NC, Common, and NO). Each
terminal block provides a fault status interface for the proces-
sor module directly above it. The fault contacts are rated for 2
amps at 30 volts RMS or 0.4 amps at 49 volts RMS. All three
sets of fault contacts are actuated when an error is detected.
A single controller chassis ground connection is provided in
the lower left corner of the chassis. Use this connection to at-
tach an EMI ground braid. The chassis ground connection is
a #6 machine screw stud with a nut and washers.
Installing the I/O Power Supply Chassis

Attach the mounting brackets to the chassis. These mounting
brackets are identical and interchangeable. The hole patterns
on the mounting brackets let you choose front or rear mount-
ing. If you are mounting the chassis within a panel, drill and

tap eight 10-32 holes in the panel. Refer to the dimensions

shown in Figure 38.
Figure 38. I/O Power Supply Chassis Mounting Dimensions.

bolts.
Attach the ground braid to the ground lug and I/O chassis.
Before installing any of the I/O power supply modules, first
install and test the input power wiring to the I/O chassis.
Input Power Wiring

Danger! Make certain that all power to the system is off before starting
to wire input power. Attempting to wire assemblies with live
power can result in serious injury or death.
Before starting to wire the input power, always verify that in-
put power is matched to the range specified for each unit.
Input power for the I/O power supply assembly comes from
the nine-terminal input power filter at the bottom right corner
of the I/O power supply chassis.
Figure 39 shows input power wiring for 110 and 220/240 VAC
systems and 24 VDC systems.

Figure 39. Input Power Wiring.

Testing
Check the power at the source (power distribution terminals
or breakers). Close the breakers and check the power at the
chassis. Verify that the power at the chassis is within the ac-
ceptable power range (this range is shown on the label above
the chassis’s input power filter).
Installing the I/O Chassis

Attach the mounting brackets to the chassis. These mounting
brackets are identical and interchangeable.
If you are mounting the chassis within a panel, drill and tap
eight 10-32 holes in the panel. Refer to the dimensions shown
in Figure 40.

Figure 40. I/O Chassis Dimensions.

bolts.
Setting the Identification Switches
Since each controller assembly can have as many as 16 I/O as-
semblies attached to it, each I/O assembly has identification
switches that are set to provide a unique identification to the
controller. The identification switches are behind the ID
switch cover (located at the bottom left corner of the I/O chas-
sis). On the back of the ID switch cover is a chart showing the
switch settings for each I/O chassis.
The I/O chassis comes from the factory with the switches set
to chassis number one of 16.
To set the identification switches for the I/O assembly, remove
the ID switch cover retaining screw and open the door. Set
the 12 DIP switches as shown in the chart on the back of the
door cover.

Figure 41. I/O Chassis ID Switch and Fault Mode Jumper.

Identification switch settings must not be changed while the
system is running.
Setting the Fault Mode Jumper
The fault mode jumper determines the shutdown mode for all
the output modules in the I/O assembly. The fault mode
jumper is inside the ID switch cover (located at the bottom left
corner of the I/O chassis).

The two options for the fault mode jumper are hold and shut-
down. If the jumper is installed in the hold position, all out-
puts hold their last state if the Regent shuts down. When the
jumper is in the shutdown position, all outputs are switched
off if the Regent shuts down. The I/O chassis must have
power from the I/O power supply in order to hold outputs in
their last state.
The I/O chassis comes from the factory with the fault mode
jumper set in the shutdown position.
To change the setting for the fault mode jumper, remove the
ID switch cover retaining screw and open the door. Remove
the fault mode jumper and reposition it. Replace the ID
switch cover.
The fault mode jumper should not be changed while the sys-
tem is running.
Installing Processor Modules

The three processor modules are installed in the three left po-
sitions on the controller chassis. Before installing the proces-
sor modules, always make certain that their input power
voltage matches the voltage of the controller chassis. Also
make certain that the processor modules all have the same
memory sizes. Use Table 7 to verify voltage and memory size
compatibility of the processor modules and the controller
chassis. Because the modules must be identical, it does not
matter which module is in installed in which position.
Table 7. Matching Controller Chassis with Processor
Modules.
Input Processor Processor
Power Controller Module Module
Voltage Chassis (128k byte) (512k byte)
110 VAC T3100 T3110 T3120
220/240 T3101 T3111 T3121
VAC
24 VDC T3102 T3112 T3122
Module revision label On the side of each processor module is a module revision
label. The module revision label identifies the revision level of
each printed circuit board in the processor module as well as

the EPROM firmware revision level. The software revision

level of all three processor modules must be identical for the
units to operate together.
Before installing the processor modules, you must,
1. Check that the EPROM revision level, voltage, and memory
are the same for all three modules.
2. Inspect the connectors at the back of the processor module
for bent pins. If any pins are bent, do not install the mod-
ule. Do not try to straighten bent pins. Return the mod-
ule for replacement.
3. Attach the battery lead button connector to the battery's
positive terminal. Do not use metal tools to install the bat-
tery lead button connector as they may short-circuit the
battery. You should be able to install the connector with-
out tools.
4. Remove the memory protect key from the side of each
module and insert the key in the keyswitch.
Install the modules one at a time. To help make alignment
easier, install the first processor module in the left-most posi-
tion, the second module in the center position, and the third
module in the right-most position.
Hold the module by its handle, supporting it from underneath
if necessary. Align the two printed circuit boards on the proc-
essor module with the alignment guides at the top and bottom
of the controller chassis.
Open the two module release levers by pulling them toward
you.
Carefully slide the module into the chassis. Be careful to keep
the module aligned while sliding it straight into the chassis.
The module should mount into the chassis with a minimum of
resistance. If the module does not mount easily, do not force
it. Remove it and check it for bent or damaged pins. If the
pins look okay, try reinstalling the module.
When the module is almost fully into the chassis, the release
levers will contact the chassis and begin to rotate closed.
Press the levers closed to seat the module in the chassis.
If the module does not seem to have seated correctly, open the
release levers and gently pull it back off the seat and out of the

chassis. Check for bent or damaged pins. If the pins look

okay, try reinstalling the module.
After the module is properly seated, tighten the retaining
screw at the top of the module.
Installing Communications Modules and Blanks

The communications modules are installed beginning with the
first slot to the right of the processor modules. The first mod-
ule is installed in the left-most position, the second module in
the center position, and the third module in the right-most po-
sition. If less than three communications modules are being
used, communications module blanks must be installed first in
the right and then in the center slots .
Before installing the communications modules you must,
1. Inspect the connectors at the back of the module for bent
pins. If any pins are bent, do not install the module. Do
not try to straighten bent pins. Return the module for re-
placement.
2. For communications modules with real-time clocks (such
as the T3151), attach the battery lead button connector to
the battery's positive terminal. Do not use metal tools to
install the battery lead button connector as they may
short-circuit the battery. You should be able to install the
connector without tools.
3. T3150A communications modules are pre-configured for
RS-232 and RS-422 communications. If you want to use
RS-485 communications you must configure the module as
described in its product description.
4. Intelligent communications modules (such as the T3180
and T3181) must be configured as described in their prod-
uct descriptions.
5. Align the printed circuit board in the module with the
alignment guides at the top and bottom of the controller
chassis.
Install the modules one at a time. Open the two module re-
lease levers by pulling them toward you.
Carefully slide the module into the chassis. Be careful to keep
the module aligned while sliding it straight into the chassis.


When the module is almost fully into the chassis, the release
levers will contact the chassis and begin to rotate closed.
Press the levers closed to seat the module in the chassis.
The top release lever on each communications module is
switched. When the lever is in the open position, the module
is disabled.
If the module does not seem to have seated correctly, open the
After the module is properly seated, tighten the retaining
screw at the top of the module. Fastening the retaining screw
will also help ensure that top (switched) release lever remains
in position.
Install the communications module blanks in the remaining
positions.
Installing I/O Power Supply Modules

Before installing I/O power supply modules, always make cer-
tain that their input power voltage matches the voltage of the
I/O power supply chassis. All the power supply modules on
the chassis must also have the same voltage.
Use Table 8 to verify voltage compatibility for your I/O power
supply chassis and I/O power supply modules.
Each primary power input is individually fused and filtered
(with both standard line filters and metal oxide varistors, or
MOVs. The filters are used to attenuate high frequency com-
mon mode and normal mode noise that can be present in
power distribution systems. The MOVs provide clamping of
high voltage transients.

Table 8. Matching Input Power Voltages.

Input Power I/O Power Supply I/O Power Supply
Voltage Chassis Module
110 VAC T3500 T3510
220/240 VAC T3501 T3511
24 VDC T3502 T3512
The three I/O power supply modules are identical, so it does

not matter which module is installed in which position.
Before installing the power supply modules, inspect the con-
nectors at the back of each module for bent pins. If any pins
are bent, do not install the module. Do not try to straighten
bent pins. Return the module for replacement.
Align the top and bottom latches at the back of the module
with the two slots at the back of the I/O power supply chassis.
Carefully press the module into the chassis. Be careful to keep
the module aligned while pressing it straight into the chassis.
As you press the module fully home, the two latches will snap
into place, securing the module in the chassis. Verify that the
latches are flush with the module housing.
If the module does not seem to have seated correctly, press the
Installing I/O Transceiver Modules

The three I/O transceiver modules are installed in the three
left positions on each I/O chassis. The modules are identical,
so it does not matter which module is in installed in which po-
sition.
Install the modules one at a time. To help make alignment
easier, install the first transceiver module in the left-most po-
sition, the second module in the center position, and the third
module in the right-most position.

Before installing the I/O transceiver modules, inspect the con-

nectors at the back of each module for bent pins. If any pins
are bent, do not install the module. Do not try to straighten
bent pins. Return the module for replacement.
with the two tabs at the back of the I/O chassis.
If the module does not seem to have seated correctly, press the
Installing I/O Module Slot Keys

Each I/O module slot can be “keyed” to accept only one type of
I/O module.
Important! Before installing the I/O module slot keys, make sure that the
configuration for your system has been defined, and use this
configuration information when placing the slot keys. This is
important because, while any combination of module type can
be installed on each I/O chassis, the placement of the modules
in the chassis must match the I/O configuration used to de-
velop the system's application programs. Failure to match
module placement with the I/O configuration could result in
unsafe or unpredictable operation.
Danger! Power to the I/O assembly must be switched off, and no field
voltage signals may be present at the terminal blocks (located
above and below the module slots on the I/O chassis), when
slot keys are being installed.
Using the figures below, determine where the slot keys should
be inserted for each type module.

Use needle-nose pliers to insert the I/O slot keys in their

proper positions.
Figure 42. Slot Key Position Numbering.

Table 9. Slot Key Positions.

Slot Key Position
Module Upper Connector Lower Connector
T3401 4 15
T3402 10 15
T3404 17 15
T3408 12 15
T3411 4 7
T3411F 9 7
T3418F 17 7
T3419 11 7
T3420A, T3420AF 9 15
T3431, T3432 15 15
T3441A 10 5
T3444 15 10
T3446H, T3446L 17 2
T3454 16 2
T3461, T3461A 13 2
T3462, T3462A 13 6
T3464 17 3
T3468, T3468A 13 4
T3470A 9 2
T3480 9 10
T3481 4 3
T3482 9 3
T3484 10 3
T3485 12 3
T3488 11 3
T3491 4 2

Wiring the I/O Assembly to Field Devices

Before installing the I/O modules in the I/O chassis, wire the
field devices to the terminal blocks on the I/O chassis accord-
ing to the I/O configuration defined for your system. Before
wiring the field devices to the terminal blocks on the I/O chas-
sis, make sure that the I/O configuration for your system has
already been defined in the WINTERPRET application, on pa-
per, or both. Make sure you install the wiring according to the
configuration. Please refer to the appropriate product descrip-
tion for additional information on wiring specific modules.
Field devices are wired to the two terminal blocks above and
below each I/O module slot on the I/O chassis. These terminal
blocks carry I/O signals and provide power connections. The
modules do not generate field power but are connected to the
power supply through these terminals.
Each terminal block has ten screw terminals. The terminals
on the top terminal blocks are identified as one through eight,
plus A and B. The terminals on the bottom blocks are identi-
fied as C and D, plus nine through 16.
A label on the side of each module shows which terminals are
used for I/O and power signals.

Figure 43. Example of an I/O Module’s Side Label.

Each screw terminal will accept one 12 AWG wire or two 14
AWG wires. Route the wiring from the field devices either
over or under the I/O chassis to the appropriate terminal block
(plastic wiring ducts, such as Panduit, can help make the wir-
ing both easier and neater). Fan the individual wires into the
terminals on the block and tighten the screws to ensure a good
connection. An example of I/O module wiring requirements is
shown in Figure 44.

Figure 44. An Example of I/O Module Wiring Requirements.
Installing I/O Modules and Blanks

Before installing the I/O modules, inspect the connectors at
the back of each module for bent pins. If any pins are bent, do
not install the module. Do not try to straighten bent pins.
Return the module for replacement.
If you are using I/O module slot keys, verify that all keys are
installed in the correct positions and properly seated in their
slots.

with the two tabs at the back of the I/O chassis.
resistance. If the module does mount easily, do not force it.
Remove the module and check it for bent or damaged pins.
Check the I/O module slot keys to be sure that they have not
been dislodged, damaged, or inserted in the wrong positions.
If the pins and slot keys look okay, try reinstalling the mod-
ule.
Installing I/O Module Blank Covers
Holding the blank cover with the long tab up, slip the blank's
long tab through the top I/O slot retainer.
Slide the blank all the way up into the top I/O slot retainer.
Press the blank flush with the chassis to align the bottom tab
with the bottom I/O slot retainer. Let the blank drop into the
bottom I/O slot retainer.
Installing Retaining Screws and Brackets

Included with each I/O chassis are two retaining brackets
(labeled top and bottom) and 26 retaining screws.
After the modules are properly seated, thread a retaining
screw into the upper and lower module latches of each I/O
transceiver and I/O module.
It’s usually easiest if you install the top retaining bracket first.
To install the top bracket, hold the bracket so that its notched
end with retaining pin is on the right (and the bracket’s nuts
are facing away from you). Insert the notch on the retaining
bracket into the rearmost position on the I/O chassis mount-
ing bracket. Lower the left side of the retaining bracket into
the rearmost notch of the left I/O chassis mounting bracket.
With the top retaining bracket in place, tighten the retaining
screws at the top of each module.

To install the bottom retaining bracket, hold the bracket so

that its notched end with retaining pin is again on the right
(and the bracket’s nuts are facing away from you). Insert the
notch on the retaining bracket into the rearmost position on
the I/O chassis mounting bracket. Raise the left side of the
retaining bracket into the rearmost notch of the left I/O chas-
sis mounting bracket.
With the bottom retaining bracket in place, tighten the retain-
ing screws at the bottom of each module.
Connecting the I/O Safetybus Cables

The I/O Safetybus cables connect the controller assembly to
the I/O assembly, If there is more than one I/O assembly,
each assembly is connected in a daisy-chain arrangement.
The maximum distance between the controller assembly and
the last I/O assembly in the daisy-chain cannot exceed 150
cable feet (45 m). You will need three I/O Safetybus cables for
each I/O assembly.
Important! Follow the I/O Safetybus cabling sequence carefully. I/O Safe-
tybus cables must not be cross-connected. Cross-connected
cables will prevent the Regent from correctly identifying fault
locations.
I/O Safetybus cables are always connected to the lower row of
connectors on the controller assembly (these connectors are
located below the processor modules).
Connect one end of the first I/O Safetybus cable to the lower
left connector on the controller assembly. Connect the other
end of the cable to the upper left connector on the first I/O
assembly (these connectors are located above the I/O trans-
ceiver modules).
Connect the second cable to the lower middle connector on the
controller assembly. Connect the other end of the cable to the
upper middle connector on the first I/O assembly.
Connect the third cable to the lower right connector on the
controller assembly. Connect the other end of the cable to the
upper middle connector on the first I/O assembly.

Figure 45. I/O Safetybus Cabling and Terminators.

Secure the I/O Safetybus cables by tightening the screws on
the cable connectors.

Daisy-Chaining Additional I/O Assemblies

Additional I/O assemblies are daisy-chained from the I/O
assembly that was connected previously. Each I/O Safetybus
cable runs from the bottom connector on the previous I/O
assembly's transceiver module to the top connector on the
transceiver module on next assembly in the chain. Always be
careful not to cross-connect the cables.
Terminating the I/O Safetybus Cable
To terminate the I/O Safetybus cable, install the I/O Safetybus
terminator plugs on the connectors of the last I/O assembly in
the chain. If there is only one I/O assembly it must still have
terminator plugs installed on it.
Connecting the I/O Power Supply to the I/O Assembly

The I/O power cable connects each I/O assembly to an I/O
power supply assembly. Each I/O power supply assembly can
power up to four I/O assemblies. The maximum distance be-
tween the I/O power supply assembly and any I/O assembly it
is powering cannot exceed 30 cable feet (9 m). You will need
one I/O power cable for each I/O assembly being connected.
Connect one end of an I/O power cable to any one of the four
I/O power connectors on the left of the I/O power supply chas-
sis. Connect the other end of cable to the I/O power connector
in the lower left corner of the first I/O assembly.
Connect additional I/O assemblies using the remaining power
connectors on the I/O power supply chassis.

Figure 46. Connecting the I/O Power Supply to the I/O

Assemblies.
Connecting Your PC to the Regent

WINTERPRET communicates with the Regent through an
RS-232 cable that runs from serial port 1 on the controller
assembly’s left-most communications module to a serial port
on the personal computer running the WINTERPRET applica-
tion.
While this cable must be connected to port 1 on the Regent’s
left-most communications module, it can be connected to any
Comm port on the personal computer (use WINTERPRET’s
Project Editor to set which comm port will be used; see Setting
Your PC’s Communications Port, in Section 4, Working with
Projects).
System Startup Tests

After installation of the Regent and the WINTERPRET applica-
tion software has been completed, various tests should be run
to verify correct installation. These tests will also serve to
demonstrate the system's fault tolerance.

The system startup tests are required by TÜV to meet Risk

Class 5 requirements.
The system startup tests have two steps:
1. Initializing the Regent with WINTERPRET and observing
the initial diagnostic functions;
2. Faulted status check.
Before beginning the system startup tests, check that all the
Regent components are properly installed (for example, that
the processor module batteries are properly connected, and
that the I/O shutdown state has been set on the I/O chassis).
Powering Up the Regent System

Always switch on the power to the I/O power supply assembly
and the I/O assemblies before (or at the same time as) switch-
ing on power to the controller assembly. Failure to power up
these assemblies in this order will prevent the controller as-
sembly from recognizing the available I/O assemblies.
When power is applied to Regent system, you should see the
following indications on each of the modules described in
Table 10.

Table 10. Diagnostic Indicators.

Processor Modules PROC Red, changing to green
COMM Red, changing to green
I/O Red, changing to green
RUN Off
BATT OK Green, if battery connected
POWER Green
MEMLK Off if keyswitch is in off

position
On if keyswitch is in on
position
Communications
Modules COMM Green
Transceiver
Modules ACTIVE Green, then off
FAULT Red after ACTIVE light
switches off
I/O Modules ACTIVE Green, then off
FAULT Red after ACTIVE light
switches off
SHUTDOWN Off (always off after initial
(output power-up regardless of I/O
modules only) chassis’ fault mode jumper
position).
I/O Power Supply
Modules PWR GOOD Green
If these modules all display the correct indications, you can

continue on to Initializing the Regent with WINTERPRET in
Section 7, Loading, Monitoring and Testing.
If any of these modules display different indications, check the
following:
1. Proper input power connections;
2. Correct input power voltage;
3. Correct module installation;
4. Correct I/O Safetybus connections.

If you cannot find the problem after checking these items,

please refer to Section 9, Troubleshooting, for additional
information.
Faulted Status Check

After you have initialized the Regent, and before you place the
system into safety operations, you should perform the tests
described below. These tests verify various functions in the
Regent related to status indications, simplex output module
hold-shutdown, processor recovery circuits and power fail
detection circuits. During the following tests, various modules
will be removed and the Regent's response will be verified.
Testing the Processor Modules
Unscrew the retain screw at the top of the processor modules
and remove the module. After one module has been removed,
verify that the corresponding I/O transceiver in each I/O
assembly indicates a fault. Using WINTERPRET's Fault Status
dialog box, verify that the correct faults are indicated. (For
information about how to use the Fault Status dialog box, see
Section 9, Troubleshooting.)
Verify that there are no other error indications.
If other error indications are present, check the I/O Safetybus
cabling, reinstall the processor module, reset the controllers,
and repeat this test.
If no other error indications are present, with the processor
module still removed, cycle the power to the Regent off and
then on again. Reinstall the processor module, reset the error
indicators by pressing the reset buttons on the two running
processor modules, and verify that all error indications have
cleared out.
Repeat this test with each of the two remaining processor
modules.
Testing the I/O Transceiver Modules
After testing all three of the processor modules, unscrew the
retaining on one of the I/O transceiver modules and remove
the module. After the module has been removed, verify that
the corresponding processor module's I/O error fault
indication is on and that the fault indication on the

corresponding I/O transceiver assembly is also on. Using

WINTERPRET's Fault Status dialog box, verify that the correct
fault is indicated. (For information about how to use the
Fault Status dialog box, see Section 9, Troubleshooting.)
Verify that there are no other error indications.
cabling, reinstall the I/O transceiver module, reset the proces-
sor modules by pressing the reset buttons on two of the proc-
essor modules, and repeat the test.
If no other error indications are present, reinstall the module
and verify that the red fault indicator is lit. Reset the error
indicators by pressing the reset buttons on two of the proces-
sor modules, and verify that all error indications have cleared
out.
Repeat this test with each of the two remaining I/O trans-
ceiver modules.
Testing the I/O Modules
Unscrew the retaining screw on one of the I/O modules and
remove the module. Verify that the I/O fault indication is on
for all three processors. Using WINTERPRET's Fault Status
dialog box, verify that the correct faults are indicated. (For
information about how to use the Fault Status dialog box, see
Section 9, Troubleshooting.)
Verify that there are no other error indications. Reinstall the
I/O module and verify that the red fault indicator is lit. Press
the reset buttons on two of the processor modules and verify
that the red I/O module fault indicators are off.
cabling, reinstall the I/O module, reset the controllers, and re-
peat the test.
If no other error indications are present, cycle the power to
the Regent off and then on again. Verify that the system has
properly warm-started and that all error indicators have
cleared out.
Repeat the test for each of the remaining I/O modules.

Testing the Fault Mode Status

Unscrew the retaining screws on two processor modules and
remove the modules. At each I/O assembly, verify the shut-
down or hold condition. Reinstall the processor modules and
reset the system.
Testing the Communications Modules
Lift the upper release lever on communications module. This
should open the limit switch and cause a fault. Verify that the
COMM fault indicators on all the processor modules are lit. If
no other error indications are present, cycle the power to the
Regent off and then on again. Verify that the system has
properly warm-started and that all error indicators have
cleared out.
Repeat this test for each of the communications modules.
Testing the I/O Safetybus
Remove one I/O Safetybus cable. Verify that the correspond-
ing processor module's I/O error fault indication is on and
that the fault indicators for each of the corresponding I/O
transceivers in each I/O assembly are also on. Using
WINTERPRET's Fault Status dialog box, verify that the correct
faults are indicated. (For information about how to use the
Fault Status dialog box, see Section 9, Troubleshooting.)
Verify that there are no other error indications. Replace the
I/O Safetybus cable and reset the system.
Repeat this test by removing each of the remaining I/O
Safetybus cables in turn, and verifying that the correct faults
are indicated by the Fault Status dialog box. Replace the I/O
Safetybus cable and reset the system after each test.


Section 3
Installing the W INTERPRET

Application
The WINTERPRET application software can be run on any per-
sonal computer running Microsoft Windows version 3.1 or
higher with the minimum hardware configuration shown in
Table 11.
Table 11. Minimum and Recommended Hardware
Configurations for Running WINTERPRET.
Minimum Configuration Recommended Configuration
80486 processor Pentium 100MHz
8 MB of memory 16 MB of memory
100 MB available hard disk storage 500 MB available hard disk storage
VGA-compatible graphics adapter High Speed SVGA with 1MB of memory
Printer
Optionally, you will probably want to have a mouse or some

other type of pointing device.
Installing W INTERPRET Version 3.2 or

Above
Important! The WINTERPRET software on the distribution diskette is in
compressed form. You cannot simply copy the WINTERPRET
programs to your hard drive — they must be decompressed
before they will run.
To install WINTERPRET Version 3.2 or above, use the following
sequence:
1. Insert the WINTERPRET base package distribution disk into
drive A: or B:
2. Start Windows (if it isn’t already running).
3. Choose Run from the Program Manager’s File menu.

Section 3 Installing the W I N T E R P R E T Application
4. Type a:\setup.exe in the text box. (If you inserted the

WINTERPRET distribution disk in drive B: type
b:\setup.exe.) Choose OK or press ENTER.
5. In the WINTERPRET Setup dialog box enter the name of the
program directory into which you want to install the
WINTERPRET application files (Setup will create the direc-
tory for you, if necessary). Choose Continue.
6. In the WINTERPRET Installation dialog box check the pack-
ages that you want to install. Check Users and Classifica-
tions if you are installing WINTERPRET for the first time
(this option installs the default password and user defini-
tion; see page 93 for more information).
The installation program will install the WINTERPRET applica-
tion files, create a WINTERPRET program group and program-
item icon, and build a WINTERP.INI file in your WINDOWS
directory.
Installing W INTERPRET Version 3.1

Important! The WINTERPRET software on the distribution diskette is in
compressed form. You cannot simply copy the WINTERPRET
programs to your hard drive — they must be decompressed
before they will run.
Before you can run the WINTERPRET application you will need
to create a WINTERPRET directory on your C: drive, decom-
press the files from the WINTERPRET distribution diskette and
place them in the WINTERPRET directory using the install
command, and start the DOS share program.
Making the WINTERPRET Directory

Using either the Windows File Manager or the DOS mkdir
command, create a directory off the root directory on your C:
drive called WINTERP.
Important! If you decide to name the directory something other than
WINTERP or place WINTERPRET files in any directory other
than the WINTERP directory off the root directory on the C:
drive, you will have to create a file named WINTERP.INI and
install it in your Windows directory (for instructions on how
to do this, see page 90, Creating a WINTERP.INI File).

Installing the W I N T E R P R E T Application Section 3
To create a WINTERPRET directory using Windows open the

File Manager and select the C: drive’s root directory. From
the File Manager’s File menu choose the Create Directory
command. In the Create Directory dialog box type WINTERP
and choose OK or press ENTER.
To create a WINTERPRET directory in DOS go to C: drive’s root
directory and enter:
mkdir \winterp
Installing the WINTERPRET Application Files

Install the WINTERPRET files that are on the distribution disk
and copy them to your WINTERP directory using the install
command. This command is on the distribution diskette.
The WINTERPRET files can be installed from within Windows.
Open the File Manager. From the File Manager’s File menu
choose the Run command. From the Run dialog box enter:
[source drive:] install [destination drive:] [path]
The source drive is the drive containing the WINTERPRET dis-
tribution disk. The destination drive and path is where the
WINTERPRET files will be copied to. If you have used the File
Manager to select the source drive, you won’t need to enter it
as part of the command.
For example, to decompress the WINTERPRET files from a dis-
tribution disk in drive B: and copy them to a directory called
WINTERP on drive C:, you would enter:
b: install c:\winterp\
The progress of the install command, as it decompresses, or
explodes, the files will be reported as the command is being
executed.
After installing the WINTERPRET files, be sure to put the
WINTERPRET distribution diskette in a safe place.
The SHARE Program

As a security measure, WINTERPRET uses the DOS share pro-
gram's file locking and sharing capabilities. Before you can
run WINTERPRET you must first start the share program.

The share program cannot be started either from Windows or

from the Windows DOS prompt. You must exit Windows be-
fore you can run the share program.
To start the share program enter:
share
After the share program is running, you can start Windows
and run WINTERPRET.
If you like, you can also include the share command in either
your AUTOEXEC.BAT or CONFIG.SYS file. In the
CONFIG.SYS file the share line should look like this:
install = [drive:] [path] share.exe
If you choose to put this line in your AUTOEXEC.BAT file in-
stead, it should look like this:
[drive:] [path] share.exe
If your AUTOEXEC.BAT file starts Windows, be sure to put
this line above the win command.
For more information about the share program, see your DOS
manual.
Creating a WINTERP.INI File

By default, WINTERPRET assumes that all of its necessary pro-
gram and resource files are located in a directory called
WINTERP, and that this directory is off the root directory on
the C: drive. If you have chosen to put your WINTERPRET files
in a directory called anything other than WINTERP or located
anywhere other than off the root directory of the C: drive, you
will need to create a file named WINTERP.INI and place it in
your WINDOWS directory.
If your WINTERPRET files are in the WINTERP directory off
the root directory on the C: drive, you do not have to create
the WINTERP.INI file, and should skip this step.
The WINTERP.INI file must contain the following:
[WINTERP]
SystemPath = [drive:] [path]
The WINTERP.INI file must be in your WINDOWS directory
before WINTERPRET will run.

Making a Program-Item Icon

After installing the WINTERPRET application software, assign a
program-item icon to it using the New command in the Pro-
gram Manager’s File menu. If you want WINTERPRET to have
its own program group you can also create a new group using
the New command in the Program Manager’s File menu.
Select the program group that you want WINTERPRET to be in.
From the Program Manager’s File menu choose the New
command. In the New Program Object dialog box choose the
Program Item button (or the Program Group button if you
want to make a new program group).
In the Program Item Properties dialog box enter the follow-
ing:
Description
What you want to appear under the program-item icon
(something descriptive, like WINTERPRET, is good).
Command Line
This will be WINTERP.EXE unless you chose to put
WINTERPRET in a different directory (in which case it will be
the drive designation and path you chose).
Working Directory
This will be C:\WINTERP unless you chose to put
WINTERPRET in a different directory (in which case it will be
the drive designation and path you chose).
Shortcut Key
Keystrokes that you want to use to open the WINTERPRET ap-
plication. This is optional.
After entering this information, choose the Change Icon but-
ton and select a program-item icon from the available icons.
Choose OK.
When all of the information in the Program Item Properties
dialog box is correct choose OK to install the program-item
icon.

Running the W INTERPRET Application

After you have installed the WINTERPRET software, you can
start the WINTERPRET application from within Windows.
WINTERPRET is started just as any other Windows application
— either double-click on the icon or highlight the icon and
press ENTER.
Logging On
To help ensure system security, WINTERPRET requires that
you enter a user name and password when you log on.
When WINTERPRET displays the Logon dialog box, enter your
user name and password. The password text box will not dis-
play your password as you enter it (it will, instead, display a
series of asterisks corresponding to the number of characters
you type). After you have entered your user name and pass-
word, choose OK or press ENTER.
Figure 47. The Logon Dialog Box.

Users logging on without entering a user name and password
are given read-only privileges and are not allowed to change or
modify anything in the WINTERPRET application or the Re-
gent.
Passwords, User Names and Classifications

Each person using WINTERPRET must log on by entering a
user name and password. Associated with each user name is a
classification that can be used to restrict a user's access to
various features within WINTERPRET. Classifications allow
access to WINTERPRET’s features to be consistent with user-
defined job classifications or descriptions. Users logging on to
the system with an invalid name or password cause an error

message to be displayed and are prompted to re-enter both

their user name and password.
Passwords, user names, and classifications are set up by a sys-
tem administrator (although users can later change their
passwords). Name, password, and classification information
is stored in an encrypted file.
Passwords must be no less than four, and no more than 16,
printable ASCII characters. Passwords are not case-sensitive
(that is, upper-case letters are not distinguished from their
lower-case equivalents).
Each user name is associated with a specific classification, and
each must be unique. Most user names only allow access to a
limited set of features. The level of privileges, or set of fea-
tures to which a particular user has access is called a classifi-
cation. Like passwords, names are not case-sensitive.
Classifications can be defined by users with adequate access
privileges to allow other system users varying levels of access.
Classifications can also be added and deleted.
Read-Only Privileges
If you do not have both a valid user name and a valid pass-
word, choosing OK or pressing ENTER (without entering a
valid user name and password) will allow you log on to
WINTERPRET with read-only privileges. Read-only privileges
let you view most of WINTERPRET’s features. You cannot,
however, make any changes to either WINTERPRET or the Re-
gent.
Logging on for the First Time

WINTERPRET comes with a default user definition that lets you
log on to the system the first time.
Name: All
Password: All Password
Use this default to log on to WINTERPRET the first time. Re-
member, names and passwords are not case-sensitive and can
be entered in upper-case, lower-case, or a combination of both.
After logging on, it is recommended that you immediately
change the password.

Important! Be sure to change the default password. Leaving the default

password unchanged defeats the purpose of password security.
Navigating the W INTERPRET Application

As you use WINTERPRET to configure and program your sys-
tem, you will navigate through an assortment of windows.
Figure 48 shows an example of the WINTERPRET application
with several of these windows open to illustrate key items
about the WINTERPRET.
Winterpret Application Window

The WINTERPRET application window is the overall window of
the WINTERPRET application. It has a Title bar, a control-
menu box, and minimize/maximize buttons at the top. Di-
rectly below the title bar is a menu bar, listing menu items for
the currently active window within WINTERPRET. As you open
new windows, or switch between different windows within
WINTERPRET, the menu bar selections will change. The status
bar at the bottom of window displays activity status and other
information about the currently active window.
You can resize the application window by using the mini-
mize/maximize buttons, or by clicking and dragging the win-
dow borders. The control-menu box can also be used for
minimizing and maximizing the application window as well as
closing and exiting WINTERPRET or switching to another ap-
plication.
Active and Inactive Windows

While you may have several windows open in WINTERPRET at
one time, only one of these windows is active. When the win-
dows are cascaded as shown in Figure 48, the active window is
always the top window (the active window is the window
whose title bar is highlighted). You can switch to another
window and make it the active window by simply clicking on
any exposed area of an inactive window.
The active window can be resized much like the application
window. The maximize button of the active window resizes
the active window to fill the entire WINTERPRET application
window. The minimize button is used to reduce the active

window to an Icon. You can also click and drag the borders of
the active window to resize it as you like.
Dialog Boxes
Many commands you perform within WINTERPRET open dialog
boxes. Unlike windows, dialog boxes are fixed size and cannot
be resized or minimized. When a dialog box is open you must
complete the functions available for the dialog box and close it
before you can switch or return to a window, or make any
menu selections. Often the dialog box includes command but-
tons such as OK, Cancel, Save, and so on that will terminate
the dialog and close it automatically. Each dialog box also has
a control-menu box that can be used to close the dialog box.

Figure 48. Key Areas of the WINTERPRET Application

Windows.
Defining Classifications
Classifications are defined by choosing a set of access rights
and assigning them a name. These classifications are then as-
sociated with different system users, giving those users access
to all the features allowed by the classification.
For example, the user name ALL is associated with a classifica-
tion named Administrator. This classification has access to all
rights. However, there are times when it is not appropriate
for all system users to have access to all available rights. In
such cases you can create a classifications having only those

rights that you have determined to be appropriate for a par-

ticular user or group of users. These classifications can then
be associated with the names of any users who you want to
have access to the rights defined by the classification.
You can define as many as a thousand different classifications
and can assign classifications to more than one user.
Using the Classifications Command

Classifications are defined and edited using the Classifications
command in the Project Selector’s Definitions menu (ALT,D,C).
To use the Classifications command you must have logged on
as a system user whose name is associated with a classification
that allows you to edit WINTERPRET classifications.
The Classifications command opens the User Classifications
dialog box from which you can edit, add, or delete user classi-
fications.
Figure 49. The User Classifications Dialog Box.

If you are editing or adding user classifications a second dialog
box will allow you to enter a name that you want to associate
with the classification, a description of the classification, and
choose rights from a list box of available rights.

Figure 50. Editing a User Classification.

The available rights, and their associated WINTERPRET com-
mands, are shown in Table 12.
Select a right (use CTRL+click to select multiple rights) and
choose Enable or Disable. Alternately you can double-click a
right to enable or disable it or choose Select All to select all
rights.
Important! If you delete a classification that is used by system users, you
will have to edit each system user definition and select a new
classification before they can log on.

Table 12. Available Access Rights.

Rights Provides Access to WINTERPRET Commands
Access all programs The user does not have to be added to the program user lists.
Access all projects The user does not have to be added to the project user lists.
Allocate shared register space Configure shared allocation sizes (using the Shared Variable
Editor).
Bypass confirmation prompts Change the confirmation level (i.e.: none, yes-no, codes).
Change password Change your own password (recommended for all users).
Clear the fault history Clear the fault history in the Regent.
Collect process data Not currently linked to any WINTERPRET command.
Configure Guarded Peer-Link Edit and save the Guarded Peer-Link (GPL) configuration. Network
commands (Load, Connect, Start, etc.). for Regent GPL operations.
Configure the serial ports Edit and save the serial port definitions for the Regent’s
communications modules
Create and copy programs Define new programs and copy existing programs.
Create and copy projects Define new projects and copy existing projects.
Delete loaded programs Delete programs from the Regent.
Delete programs from disk Delete programs from the PC.
Edit all users and their rights Edit and save user classifications, edit and save system users.
Edit I/O point definitions Edit I/O definitions and load the I/O configuration into the Regent.
Edit program source Create, edit, copy and delete function blocks. Compile programs
and function blocks. Edit program and function block descriptions
and details.
Edit the program user list Add, delete, edit program users.
Edit project title and description Edit project description and details.
Edit the project user list Add, delete, edit project users.
Edit shared variable definitions Add, delete, edit shared variable definitions. Load the shared
allocation and load comm protection.
Edit I/O module layout Define I/O module types and their positions in the I/O configuration.
Load the I/O configuration into the Regent.
Force and data change Add, delete, change value of forced variables. Enable or disable
forcing. Change value of variables from the Data Monitor. Reset
local variables for a program.
Load programs Load programs into the Regent.
Load RAMcode Load RAMcode to the Regent. Start and stop I/O.
Run programs Run the programs that have been loaded into the Regent.
Perform voted reset Initiate a voted reset for the Regent.
Set the designated comm port Define the PC’s comm port for a particular project.
Set the real-time clock Set the Regent’s real-time clock.
Stop programs Stop programs that are running in the Regent.
Single-scan programs Single-scan programs that have been loaded in the Regent.
Reserved for future use These ten rights are identified for future use by ICS.

Defining System Users

Defining system users lets you give each user a password and
associate that user with a particular classification, or level of
access to WINTERPRET’s features. Anyone logging on to
WINTERPRET who has not first been defined as a system user
will only be allowed to browse through the system’s features
without making any changes or affecting system operation in
any way.
Using the System Users Command

System users can be added, edited, and deleted using the Sys-
tem Users command in the Project Selector’s Definitions
menu (ALT,D,U). To use the System Users command you must
have logged on as a system user whose name is associated with
a classification that allows you to edit WINTERPRET’s system
users.
The System Users command opens the System Users dialog
box from which you can choose to edit, add, or delete system
users.
Figure 51. The System User List Dialog Box.

If you are editing or adding system users a second dialog box
will allow you to enter a logon name, the name of the classifi-
cation that you want to associate with the user, and a pass-
word for the user.

Figure 52. The Add System User Dialog Box.
Changing Your Password

WINTERPRET provides a convenient way to allow users to
change their passwords. By regularly changing your pass-
word, you maintain the highest level of security for the
WINTERPRET application.
The user who is currently logged on to WINTERPRET can
change his or her password by choosing the Change password
command from the Project Selector’s Definitions menu
[ALT,D,A].
Figure 53. The Change Password Dialog Box.

In the Change Password dialog box, enter you existing pass-
word, a new password, and repeat your new password
(repeating your password makes sure that a simple typo-
graphical mistake doesn’t forever lock you out of the

WINTERPRET application). Choose OK to complete the opera-

tion or Cancel if you decide not to change your password.
After you have changed your password, you remain logged in
to WINTERPRET. You will need to use your new password the
next time you log on to WINTERPRET.
Commands Common to all W INTERPRET

Windows
There are a number of commands that are common to all of
WINTERPRET’s windows. These common commands include
Print Setup, Logoff, Exit, Prompt for Delete, and the Window
and Help menus.
File Menu
Print Setup
Use this command to select a printer and a printer connection.
The options in the Print Setup dialog box will vary, depending
on the printer you install. The title of the dialog box changes
to reflect the name of your printer.
Select the printer you want to use (only installed printers ap-
pear). You install printers and configure ports through the
Windows Control Panel. For information on installing print-
ers, see the Microsoft Windows User's Guide and your
printer’s documentation.
The Setup command button inside the Print Setup dialog box
displays another dialog box that lets you control the default
printer settings for the printer you select. For more informa-
tion, choose the Help button after choosing the Setup button.
Log Off
Use this command to end your WINTERPRET session without
exiting from the WINTERPRET application.
To maintain system security, after you have finished using
WINTERPRET always be sure to log off or exit. Logging off
leaves the WINTERPRET application running, but helps prevent
unauthorized users from making changes to WINTERPRET, its
programs, or the Regent.

To log off, from any File menu choose Log Off (ALT,F,L). If a
file (such as a program or function block) is still open and has
been revised, you will be prompted to either save your changes
or exit without saving.
After logging off, WINTERPRET displays the Logon dialog box.
To return to WINTERPRET, enter your user name and pass-
word.
Exit
Closes the WINTERPRET application, logs you off, and returns
you to the Windows Program Manager.
There are four ways you can close the WINTERPRET applica-
tion:
1. From the File menu choose Exit (ALT,F,X); or
2. Click the WINTERPRET application window’s Control-menu
box and choose Close (ALT,SPACEBAR,C); or
3. Double-click the WINTERPRET application window’s Con-
trol-menu box; or
4. Press ALT+F4.
As with logging off, if a file (such as a program or function
block) is still open and has been revised, you will be prompted
to either save your changes or exit without saving.
Tip: If you want to close a window within the WINTERPRET application
without closing the WINTERPRET application itself use one of the
following methods:
1. Click the window’s Control-menu box and choose Close
(ALT,HYPHEN,C); or
2. Double-click the window’s Control-menu box; or
3. Press CTRL+F4.
Note: When there are many applications open under Windows, it is a
good idea to occasionally save your work, exit and restart Winterpret.
This will help with defragmentation of memory under Windows.
Options Menu
Prompt for Delete
When this command is checked, delete actions will always dis-
play a prompt requesting confirmation of the action. If it is
not checked, the delete action will occur immediately.

Important! For most actions there is no undelete or undo — deleted items

are gone (except function blocks).
Window Menu
The Window menu commands provide convenient ways to ar-
range WINTERPRET’s windows and icons. As you open various
windows
Cascade
Arranges all of the open windows within the WINTERPRET ap-
plication in an overlapping cascade flowing from the upper left
to the lower right. The active window will always be on top.
Tile
Arranges all of the open windows within the WINTERPRET ap-
plication in a non-overlapped, or tiled fashion.
The more windows that are open, the smaller each tiled win-
dow becomes. If tiled windows become too small to work with,
it is often useful to maximize the window you’re currently us-
ing. When you want to switch to another window, click the
restore button to return the maximized window to its normal
tiled size and maximize the next window that you want to
work with.
Arrange Icons
The windows within the WINTERPRET application can be
minimized to icons. The Arrange Icons command arranges all
of the icons along the bottom left of WINTERPRET application
window.
1, 2, 3, ... 9, More Windows
The Window menu lists the open windows and icons numeri-
cally (according to the order in which they were opened). You
can use this command to switch to a different window by se-
lecting it from the list. If more than nine windows are open at
a time, choose More Windows to see a list of the windows not
shown in the menu list.
Help Menu
On-line Help is a quick and convenient way to look up infor-
mation about a task you are performing, a feature you would

like to learn more about, or a command you want to use. Help

is always available either by pressing F1 or by choosing on of
the commands from the Help menu.
Help Index
Opens WINTERPRET Help and displays the index for all
WINTERPRET help topics.
Commands
Opens the Help topic showing the commands available for the
active window. For example, selecting Commands in the Lad-
der Logic Editor opens Help and displays all of the commands
available within the Ladder Logic Editor.
Using Help
Use this command to get assistance on how Help works and
commands that are available while you’re using Help. This
command can help you get information on searching for top-
ics, making bookmarks within Help, annotating Help topics,
printing Help, and more.
About WINTERPRET
Displays a dialog box showing the version number, serial
number, currently logged-on user name and when logged-on,
and the WINTERPRET system directory in use.
Figure 54. The About Winterpret Dialog Box.

What Next?
Working with WINTERPRET is an iterative process of configur-
ing hardware and writing and editing the function blocks that
will make up your application program. The following sec-
tions of this User’s Guide are arranged in what will most
probably be the order of your first iteration. The next few sec-
tions will guide you through,
• Creating projects.
• Configuring the Regent’s I/O points.
• Using the Shared Variable Editor to create shared vari-
ables.
• Allocating register space.
• Creating and editing programs.
• Configuring your hardware (including setting the commu-
nications ports on both your computer and the Regent to
enable them to communicate).
• Loading the RAMcode, I/O configuration, shared alloca-
tions, and comm protection into the Regent.
• Starting and stopping inputs and outputs.
• Loading programs into the Regent.
• Running, monitoring, and testing programs.

Section 4
Working with Projects

WINTERPRET can be used to develop configuration and appli-
cation programs for multiple Regents systems. WINTERPRET
refers to these different Regents as projects. For
WINTERPRET, each Regent is a unique project with its own
unique I/O configuration, programs, and function blocks,
shared variables, serial ports, and so on.
Using the Project Selector

WINTERPRET opens the Project Selector every time you log on.
The Project Selector shows the list of defined projects. Each is
listed by name and description.
The Project Selector lets you create new projects and open,
copy, or delete existing projects. The Project Selector is also
where Guarded Peer-Link communications are configured,
classifications are defined, system users are added, deleted, or
modified, and where you can change your password.
When you first install WINTERPRET there are no projects. You
must use the Project Selector to create a project for each
Regent — even if there is only one Regent in your installation.

Section 4 Working with Projects
Figure 55. The Project Selector.
File Menu
New Project
Use this command when you want to create a new project
from scratch. Enter a name and description in the New Proj-
ect dialog box.
Figure 56. The New Project Dialog Box.

Using this command requires the access right “create and
copy projects.”
Open Project
Opens the Project Editor for the selected project. For more
information see Using the Project Editor on page 111.
6 Shortcut: Select the project you want to open and double-click or press
ENTER.

Working with Projects Section 4
Copy Project
Use this command to create a new project as a copy of an ex-
isting project. Select the project that you want to copy and
choose Copy Project. Enter a name for the destination (or
new) project in the Copy Project dialog box.
Figure 57. The Copy Project Dialog Box.

copy projects.”
Delete Project
Deletes the selected project. If Prompt for Delete is selected
from the Options menu, you must confirm your delete request
by choosing the Yes command button from the confirmation
prompt:
Using this command requires the access right “delete proj-
ects.”
View Project Details
This command opens the Project Details dialog box. While
you can scroll up and down through the project’s details text
box to view its contents, you are not allowed to add or edit
those details using this command. You can add or edit a proj-
ect’s details using the Project Editor (see page 111, Using the
Project Editor).
When you have finished viewing the project’s details, choose
Cancel.
Log Off
Ends the activities of the current WINTERPRET user, closes all
open windows within WINTERPRET, and prompts the next user
to log on. For more information on using this command see
Commands Common to all WINTERPRET Windows in Section
3, Installing the WINTERPRET Application.

Exit
Closes the WINTERPRET application. For more information on
using this command see Commands Common to all
WINTERPRET Windows in Section 3, Installing the
WINTERPRET Application.
Definitions Menu
Guarded Peer-Link Config
Use this command to configure the projects and variables for
Guarded Peer-Link communications between multiple Regent
systems.
Using this command requires the purchase and installation of
the WINTERPRET Communications add-on software package
(Catalog No. T3831). For more information, please refer to
the Guarded Peer-Link product description.
Using this command requires the access right “configure the
Guarded Peer-Link.”
Classifications
Opens the Classifications dialog box allowing the creation and
modification of user classifications. For more information on
using this command see Defining Classifications in Section 3,
Installing the WINTERPRET Application.
Using this command requires the access right “edit all users
and their rights.”
System Users
Opens the System Users dialog box allowing the creation and
modification of user classifications. For more information on
using this command see Defining System Users in Section 3,
Installing the WINTERPRET Application.
Using this command requires the access right “edit all users
and their rights.”
Change Password
Use this command to change your password. For more infor-
mation on using this command see Changing Your Password
in Section 3, Installing the WINTERPRET Application.
Using this command requires the access right “change pass-
word.”

Options Menu
Prompt for Delete
Activates and deactivates delete command prompts. For more
information on using this command see Commands Common
to all WINTERPRET Windows in Section 3, Installing the
Window Menu
The Window menu commands are standard throughout all
WINTERPRET windows. For more information on using the
Window menu commands see Commands Common to all
WINTERPRET Windows in Section 3, Installing the WIN-
TERPRET Application.
Help Menu
The Help menu commands are standard throughout all
Help menu commands see Commands Common to all
Using the Project Editor

Choosing Open Project from the Project Selector’s File menu
opens the Project Editor. The Project Editor shows the name
of the open project in its title bar and displays a list of existing
programs for the opened project. Each program is listed by
name, version number, and description.
The Project Editor lets you,
• Edit project descriptions and details;
• Create and modify application programs, I/O configura-
tions, shared variables, and the Regent’s serial ports;
• Get program histories;
• Open the Execution Controller;
• Define the comm port your PC will use to communicate
with the Regent;
• Set the Regent’s real-time clock;

• Perform comparisons of programs, I/O, and shared vari-

ables.
Figure 58. The Project Editor.

You should normally begin by configuring the common re-
sources of the Regent before creating application programs.
These common resources include I/O configuration, the shared
variable definitions and the serial ports. By configuring these
resources first, you will have created a foundation on which to
build your application programs. If you choose to begin creat-
ing programs first, you may encounter various compilation er-
rors until you complete the I/O, shared variables, and serial
ports definitions. The configuration steps for each of these
resources are described later in this section. For more infor-
mation on developing application programs see Section 5,
Working with Programs and Function Blocks.
File Menu
New Program
Use this command when you want to create a new program
from scratch. Enter a name and description in the New Pro-
gram dialog box.
copy programs.”

Figure 59. Creating a New Program.

Open Program
Opens the Program Editor for the selected program. For in-
formation on using the program editors see Section 5, Work-
ing with Programs and Function Blocks.
6 Shortcut: Select the program whose editor you want to open and double-
click or press ENTER.
Get Program History
Use this command to open the Program Version History dia-
log box listing program versions by version number and ver-
sion description. The creation date and the system user who
created the version are shown at the bottom of the dialog box
for the selected version.
Figure 60. The Program Version History Dialog Box.

From this dialog box you can modify version descriptions, de-
lete versions you no longer need and open any version for
viewing and editing. Choose from the following buttons:
Close
Closes the Program Version History dialog box.

Description
Using this button requires the access right “delete programs.”
Opens the Version Description dialog box and lets you edit the
version description.
Delete
Using this button requires the access right “delete programs.”
Deletes the selected version of the program source file, but
does not delete any function blocks (or versions) that were
used by the program version (see the File menu command
Unused Function Blocks in Using the Program Editor, Section
5, Working with Programs and Function Blocks).
If Prompt for Delete is selected from the Options menu, you
must choose Yes when you receive the Delete confirmation
prompt.
Open
Opens the Program Editor for the selected program version.
This option provides a good way to make an older version the
most current. Opening, saving, and compiling an older ver-
sion makes it a new version at the next highest version num-
ber.
Copy Program
Use this command to create a new program by copying an ex-
isting program. In the Copy Program dialog box select the
source project and program to copy from the drop-down lists.
Enter a name for the destination (or new) program and choose
whether to copy all versions or only the latest version.
When you have finished making your selections choose OK to
make a program copy or choose Cancel to return to the Project
Editor without making a program copy.

Figure 61. The Copy Program Dialog Box.

Copying a program also copies all of the function blocks in the
program.
copy programs.”
Delete Program
Deletes the selected Program. If Prompt for Delete is selected
from the Options menu, you will receive a confirmation
prompt.
Using this command requires the access right “delete pro-
grams.”
View Program Details
This command opens the Program Details dialog box. While
you can scroll up and down through the program’s details text
box to view its contents, you are not allowed to add or edit
those details using this command. You can add or edit a pro-
gram’s details using the Program Editor (see Using the Pro-
gram Editor in Section 5, Working with Programs and Func-
tion Blocks).
When you have finished viewing the program’s details, choose
Cancel.
Edit Project Description
Use this command to modify the description field for the proj-
ect. When you have finished editing, choose Save or Cancel.
Using this command requires the access right “edit project ti-
tle and description.”

Edit Project Details

Opens the Project Details dialog box where you can enter nar-
rative details documenting key aspects of the project. Whereas
the project description is limited to 40 characters of text, proj-
ect details provides up to 6,500 lines of text in which you can
enter comments.
Figure 62. Editing Project Details.

Using this command requires the access right “edit project ti-
tle and description.”
Use the Print Project Summary command to print the project
details.
Print Project Summary
Use this command to generate printouts of project summary
information. Use the check boxes to indicate which summary
information you want to print.
Figure 63. The Print Project Dialog Box.

Print Project Details

Prints the project’s name, description, and details.
Print Program List
Prints the project’s name, description, its I/O and shared vari-
able configuration version, and the list of programs contained
in the project. Each program is listed by name, version, and
description.
After making your selections, choose OK to print or Cancel to
return to the Project Editor without printing.
Print Setup
Use this command to configure various options for your
printer from the standard Windows Print Setup dialog box.
Consult your printer documentation for details.
Log Off
Exit
using this command see Commands Common to all WIN-
TERPRET Windows in Section 3, Installing the WINTERPRET
Application.
Important! This is not how to close the Project Editor, as this command
will close the entire WINTERPRET application. Close the Proj-
ect Editor using CTRL+F4 (or click the Project Editor’s con-
trol-menu box and choose Close [ALT,HYPEN,C], or double click
on the control-menu box).
Controller Menu
Commands from the Controller menu are used for on-line in-
teraction between WINTERPRET and the Regent. You must
have your PC connected to a Regent to use these commands.
Execution
Opens the Execution Controller. From the Execution Control-
ler you can initialize the Regent, load, run and stop programs
and so forth. For information on using the Execution Con-

troller see Section 7, Loading, Monitoring and Testing Appli-

cation Programs.
Fault Status
Use this command to view the Fault Status dialog box show-
ing the fault status information for the Regent controller.
Faults are displayed on a module-by-module basis. For more
information on viewing the Fault Status, see Displaying Re-
gent Fault Status in Section 9, Troubleshooting.
Fault History
Opens Fault History Viewer which displays a time-stamped
chronological list of faults for the Regent.
For more information on using the Fault History Viewer, see
Using the Fault History Viewer in Section 9, Troubleshooting.
Set Real Time Clock
Use this command to view and set the Regent’s real-time
clock.
No access right is required to access the Set Real-Time Clock
dialog box; however, you must have access right “set the real
time clock” to choose OK, to set the real time clock in the Re-
gent, otherwise you can only choose Cancel.
The date and time are entered and displayed in fields named
Month, Day, Year, Hour, Minute, and Second.
Figure 64. The Set Real-Time Clock Dialog Box.

Use the Source option buttons in order to:

Get From PC
Updates the date and time fields using the clock time from the
PC running the WINTERPRET application.
Get from Regent
Communicates (once) to the Regent to read the real-time clock
values and display them in the date and time fields.
After making your choices or changing the time and date
fields, choose one of the following buttons:
OK
Communicates to the Regent and sends the displayed values
to the Regent to set the real-time clock (to set the real-time
clock you must have at least one T3151 real-time clock com-
munications module installed).
Setting the real-time clock in the Regent automatically sets
the millisecond value to zero.
Important! Setting the Regent’s real-time clock to an earlier time may ef-
fect the retrieval of sequence of events and process historian
logs. You should collect the logs before setting the real-time
clock. For more information on collecting sequence of events
and process historian logs see Using the Sequence of Events
Monitor and Using the Process Historian; both are in Section
7, Loading, Monitoring and Testing Application Programs.
Cancel
Closes the Set Real-Time Clock dialog and returns you to the
Project Editor.
Definitions Menu
I/O Configuration
Opens I/O Configuration Editor. For more information on us-
ing the I/O Configuration Editor see page 132.
I/O Configuration History
Use this command to display the I/O Configuration Version
History dialog box. I/O configuration versions are listed by
version number and version description. The creation date
and the system user who created the version are shown at the
bottom of the dialog box for the selected version.

Figure 65. The I/O Configuration History Dialog Box.

From this dialog box you can modify version descriptions, de-
lete versions you no longer need and open any version for
Close
Closes the I/O Configuration Version History dialog box.
Description
Opens the Version Description dialog box allowing you to edit
the version description.
Using this button requires the access right “edit I/O module
layout.”
Delete
Deletes the selected version of the I/O configuration. If
Prompt for Delete is selected from the Options menu, you will
receive a confirmation prompt.
Using this button requires the access right “edit I/O module
layout.”
Open
Opens the I/O Configuration Editor for the selected I/O ver-
sion. For more information on using the I/O Configuration
Editor see page 132.
ber.
Shared Variables
Opens Shared Variable Editor. For more information on us-
ing the Shared Variable Editor see page 146.

Shared Variables History

Use this command to display the Shared Variables Version
History dialog box. Shared variables versions are listed in by
Figure 66. The Shared Variables History Dialog Box.

From this dialog you can modify version descriptions, delete
versions you no longer need and open any version for viewing
and editing. Choose from the following buttons:
Close
Closes the Shared Variables Version History dialog box.
Description
Using this button requires the access right “edit shared vari-
able definitions.”
Delete
Deletes the selected version of the shared variable configura-
tion. If Prompt for Delete is selected from the Options menu
you will receive a confirmation prompt.
Using this button requires the access right “edit shared vari-
able definitions.”
Open
Opens the Shared Variables Editor for the selected version.
For more information see page 146, Using the Shared Variable
Editor.


ber.
System Variables
Use this command to view and print the standard System
Variables that are included with every Regent system. The
system variables are internal variables within the Regent that
represent a variety of operational and fault status information
about the Regent system.
Figure 67. The Regent System Variables Dialog Box.

The System Variables dialog box lists the system variable reg-
isters and control relays by tag name, type (SW or SCR), read-
only status [R], address, and description. Choose from the fol-
lowing buttons:
OK
Exits the System Variables dialog box.
Print
Prints the system variable listing.
Serial Ports
Use this command to open the Serial Ports dialog box to view
and edit the definitions for the serial ports on the Regent
communication modules. From this dialog box you can also
load the serial port configuration into the Regent.

Figure 68. The Serial Ports Dialog Box.

The Regent may contain up to three communications modules,
each with two configurable ports. These ports are logically
numbered from top to bottom, left to right as you look at the
Regent controller (that is, the top port on the left-most com-
munications module is port one and the bottom port on the
right-most communications module is port six).
Table 13. Logical Port Numbering.
Logical Communications Port Numbers
Slot 1 Slot 2 Slot 3
Port Number 1 3 5
2 4 6
The Serial Ports dialog box has three primary selection areas:
Port Settings, Source, and Save options.
Port Settings
The dialog box lists each serial port by port number, node ad-
dress, port type, baud rate, data format, and port description.
Select a particular port in this list before you choose Edit (see
below).
Source
The serial port configurations displayed in Port Settings dia-
log box are retrieved from the Source selection you choose.
Get from Disk
Retrieves the serial port configuration previously saved to
disk and displays it for editing.

Get from Regent

When you need to check what the Regent is currently us-
ing for its comm port configuration, choose Get from Re-
gent to retrieve the serial port configuration from the Re-
gent for display and editing. Your PC must be connected
to a Regent in order to choose this option. Port descrip-
tions are not stored in the Regent, so they will always be
blank after making this choice.
Save Options
Chooses the desired action to take when the port settings are
saved.
Disk Only
Serial port configuration is saved to disk (for all serial
ports, not just the one port selected in the list box).
Disk and Regent
Serial port configurations for all ports are saved to disk
and also sent to the Regent. This is how you load the se-
rial port configuration into the Regent.
Save to Disk and Regent must be used before any port
other than port 1 can be used by the Regent. Regardless of
how many communications modules the Regent has in-
stalled, until this function is used, the Regent defaults to
having only port 1 configured (as a comm port).
Port type definitions where communications modules are
not installed must always be “None,” otherwise an error
will occur if you choose Save to Disk and Regent.
Your PC must be connected to port 1 of the Regent and the
Regent must have RAMcode loaded before you can load the
serial port configuration to the Regent the first time. For
more information about loading RAMcode, see Section 7,
Loading, Monitoring and Testing Application Programs.
Option buttons in the Serial Ports dialog box let you edit the
port settings, save the port settings, or cancel and abandon
any changes you may have made. Each of these functions is
described below.
Edit
Choose this button to open the Settings for Serial Port # N
dialog box to configure an individual port. You must have the
right “configure the serial ports” to choose Edit.

Figure 69. Editing Serial Ports.

Configure the serial port by entering values for the following
configuration fields:
Type
Various port types are configured for the Regent in order
to provide particular communications functions and con-
nections. See Table 14 for guidelines on choosing a port
type.

Table 14. Regent Port Types.

Port Type Requirements/Guidelines
Comm Used for point-to-point serial connection to a PC
running W INTERPRET, or another communications
master that supports the Regent R2 protocol.
Port 1 must always be configured as a Comm port.
Multidrop Used for multidrop (multiple Regents) serial
connection to a PC running W INTERPRET, or another
communications master that supports the Regent R2
protocol.
Requires a node address (1-247). Each node address
on a multidrop cable must be unique.
Net Master Used for Guarded Peer-Link communications. This
Regent will be the Master of the network leg connected
to this port (there can only be one Master per network
leg).
Requires a node address (1-31), unique to other
Regents on the Guarded Peer-Link network.
Net Slave Used for Guarded Peer-Link communications. This
Regent is not the Master of the network leg connected
to this port.
Regents on the Guarded Peer-Link network.
All Net Master and Net Slave ports on a single Regent
must have the same node address.
Modbus Used for point-to-point or multidrop connection to a
communications master (DCS gateway, MMI, etc.)
supporting the Modbus protocol (RTU format). The
Regent acts as a Modbus Slave.
devices on the Modbus network.
ASCII Used for sending ASCII output messages from the
Regent to a printer or other similar device. ASCII
output messages are configured in ladder logic
function blocks of your application programs.
None Select None for ports where no communications
module is installed.
Baud Rate
Select the desired baud rate (300 to 19,200) for the port.
Port 1 must always have a baud rate of 19,200.
Node Number
If the port type is Multidrop, Net Master, Net Slave or
Modbus you must enter a node number. See recommenda-
tions in Table 14 for each type of port.

Data Format
Select the desired data format for data bits (7 or 8), stop
bits (1 or 2) and parity (odd, even, none) for the port. Port
types Comm, Multidrop, Net Master and Net Slave must
always be configured for 8 data bits, 1 stop bit and odd par-
ity.
Description
Enter a brief description for the port (for example, what is
connected to it).
When you are finished making your selections choose OK to
accept your configuration or choose Cancel to abandon any
changes you may have made.
Save
Performs the function chosen by save options (see above) and
closes the Serial Ports dialog box. You must have the right
“configure the serial ports” to choose Save.
Cancel
Closes the Serial Ports dialog box without saving any changes.
Project Users
Use this command to define which system users can use their
classification rights (for example, editing, loading, forcing, de-
leting, and so on) in the selected project.
Figure 70. The Project User List Dialog Box.

System users with the access right “access all projects” do not
have to be added to the list, nor will their names be shown
automatically. Only the project’s creator and the names of us-
ers specifically added to the list will appear in the Project User
list. System users who do not have the access right “access all

projects” must be added to each Project User list for which

they should have access.
Using this command requires the access right “edit the project
users list.”
Choose a button for the desired action.
Save
Saves your changes and closes the dialog box.
Cancel
Closes the dialog box without saving your changes to the Proj-
ect User list.
Add
Opens the Add Project User dialog box. Use the drop-down
list box to select a system user to add to the project user list.
Choose OK to add the user or Cancel to return to the Project
User list without adding the user.
Delete
Deletes the selected user. If Prompt for Delete is selected
from the Options menu, you will have to confirm your selec-
tion.
Tools Menu
Compare Programs
Compares different versions of a program and lists where the
programs are different. For more information see Comparing
Application Programs in Section 6, Version Tracking.
Compare I/O Configurations
Compares different versions of an I/O configuration and lists
where they are different. For more information see Compar-
ing I/O Configurations in Section 6, Version Tracking.
Compare Shared Variables
Compares different versions of a shared variable configuration
and lists where they are different. For more information see
Comparing Shared Variable Definitions in Section 6, Version
Tracking.

Options Menu
Prompt for Delete
Set Confirmation Level
Use this command to set the type of confirmation prompts you
prefer. Confirmation codes are required for all operations that
load or change information in the Regent (for example, pro-
gram loading, program stopping, forcing, and so on).
Figure 71. Setting the Confirmation Level.

Choose one of the following three confirmation levels. To
change confirmation levels command you must have the ac-
cess right “bypass confirmation prompts.”
None
Choose None to turn off confirmation prompts. When confir-
mation prompts are turned off, commands like Stop Program
occur immediately when you choose them.
Yes-No
Selecting Yes-No will cause a Confirmation Prompt dialog box
to appear requiring a yes response before continuing with the
requested command.
Codes
Choosing Confirmation Codes will cause commands to display
a dialog box showing a randomly generated character that you
must press before the requested command is performed.

After you have selected your confirmation level, choose OK to

save or Cancel if you decide not to change the confirmation
level.
Set PC Comm Port
Use this command to identify which of your PC’s comm ports
WINTERPRET will use for this project to communicate to the
Regent.
Figure 72. Setting the PC Comm Port for a Project.

From the Set PC Port dialog box make the following selec-
tions. To use this command you must have access right “set
the designated comm port.”
Baud Rate
You should normally set this to 19,200, unless long distance
serial communications lines are used. If the PC is connected
to port 1 of the Regent the baud rate must be 19,200.
Connect to Node
Set to 0 if the PC running the WINTERPRET application is con-
nected to a Regent port type configured as comm port.
If the PC running the WINTERPRET application is connected
over a multidrop serial network to more than one Regent, en-
ter the node number defined for the Regent multidrop port.
Port
Choose Comm 1 through Comm 4 to indicate which of the se-
rial ports on the PC running the WINTERPRET application is
connected to the Regent.

When you have finished making you selections choose OK to

save the PC port setting or choose Cancel to return to the
Project Editor without saving your changes.
For additional information about communications cabling re-
quirements, see Connecting Your PC to the Regent in Section
2, Installing the Regent Hardware.
Window Menu
Help Menu
Configuring Your Project’s I/O

WINTERPRET includes an I/O Configuration Editor that lets
you define the physical layout of the input and output modules
connected to the process.
The I/O configuration should reflect the physical layout of the
I/O modules connected to the Regent. A typical Regent con-
figuration will have one or more I/O assemblies containing I/O
modules of various types. Each I/O module is of a certain type
(analog or digital, input or output) and has a certain number
of points that can be connected to sensors (inputs) or actua-
tors (outputs). WINTERPRET must know this configuration in
order to translate application programs into code that will run
in the Regent.
The I/O Configuration Editor lets you designate the type and
position of each module in the Regent's I/O system and lets
you assign a tag name and brief description to each input or
output point. The I/O Configuration Editor also has a com-
piler that associates the tag names with physical addresses
and saves them in the symbol table. Once the configuration

has been established, you can then refer to input and output
points by their tag names.
I/O slots that have not been configured are labeled as empty.
I/O slots that have been configured are labeled with the ICS
catalog number of the I/O module type selected and module
type identifier.
Using the I/O Configuration Editor

The I/O Configuration Editor is used to define the exact I/O
configuration for the Regent. This I/O configuration is saved
on disk and must be loaded into the Regent before loading any
application programs.
Use the I/O Configuration Editor to define module types and
positions and to enter a name and description for each I/O
point.
Important! The I/O configuration you create using the I/O Configuration
Editor will be loaded into the Regent regardless of the actual
I/O modules connected to the Regent. If the loaded I/O mod-
ule configuration differs from the installed I/O modules, faults
will be reported for each I/O module where the configuration
does not match. These faults will be reported after you use
the Start Inputs command (for more information on the Start
Inputs command see Section 7, Loading, Monitoring and Test-
ing Application Programs).
To open the I/O Configuration Editor, open the project whose
I/O configuration you want to edit. To open a project, select
the project that you want to open and choose Open from the
Project Selector's File menu (ALT,F,O).
6 Shortcut: Select the project that you want to open and double-click or
press ENTER.
From the Project Editor's Definitions menu choose I/O Con-
figuration (ALT,D,I) to open the I/O Configuration Editor.
When the I/O Configuration Editor is opened an I/O map is
presented as shown in Figure 73. Using the mouse or arrow
keys you can select a particular slot of an I/O chassis for edit-
ing.
During I/O configuration you will perform two primary ac-
tions,

1. Choose the type of I/O modules for each slot (see Assigning
Module Types to the I/O Slots, below).
2. Edit the I/O module definition to specify names, descrip-
tions and other applicable information for each I/O point
(see Editing I/O Module Definitions, below).
Figure 73. The I/O Configuration Editor’s I/O Map.

I/O Assembly Numbers and I/O Slot Numbers
Each I/O assembly has an I/O assembly number that differen-
tiates it from the project’s other I/O assemblies. I/O assem-
blies are numbered according to their I/O chassis identifica-
tion switch settings. For more information see Setting the
Identification Switches in Section 2, Installing the Regent
Hardware.
Each I/O assembly has ten I/O slots. These slots are num-
bered from slot one on the left through slot ten on the right.
The ten I/O module slots are exclusive of the I/O transceiver
slots. I/O transceiver modules do not require configuration
and do not appear in the I/O Configuration Editor.
Assigning Module Types to the I/O Slots
The I/O module type you assign to each slot must match the
type of I/O module you plan to install in each slot. Place the
cursor of the I/O map on the desired slot. From the Edit
menu choose the Set Module Type command (ALT,E, S) and
choose the module type from the dialog box (see Figure 714).
Repeat this procedure for each module in your I/O configura-
tion.

Figure 74. The Set I/O Module Type Dialog Box.

Tip: For fault tolerant I/O configurations, set the module type for
the first of the redundant I/O modules and complete the defi-
nition of the I/O points (see Editing I/O Module Definition, be-
low). Copy the completed module and use the Insert Module
command for each of the redundant modules. After inserting
the redundant modules, edit each module’s definition, chang-
ing the names of the I/O points so that each redundant point
has a unique name (a good way to do this is by adding a suffix
character to each of the names).
Editing I/O Module Definitions
After you have set the type for an I/O module use the Edit
Module Definition command to assign names, descriptions,
and other configuration data to each point on the I/O module.
From the I/O map select the module whose definition you
want to edit. From the Edit menu choose Edit Module Defini-
tion (ALT,E,E). A dialog box applicable for the module type
will be opened, an example of which is shown in Figure 75.

Figure 75. The Edit Module Definition Dialog Box.

The Edit Module Definition dialog box shows each of the I/O
points by name and description. Position the cursor on an I/O
point and choose Edit to open an I/O point definition dialog
box. This dialog box contains all of the appropriate fields for
the particular I/O point you are defining. An example is
shown in Figure 76.
Figure 76. The Edit I/O Point Definition Dialog Box.

I/O Point Definition Fields
Depending on the type of I/O point selected, some combination
of the following configuration fields will be presented. Follow
the guidelines explained below to complete the I/O point con-
figuration.

Please note that not every possible I/O point configuration

field is described below. Refer to the I/O module’s product de-
scription for details on configuring specific I/O modules.
Name
The I/O point name you define is the programming reference
you will use in the function blocks of your application pro-
grams to reference this I/O point.
Description
A text description of the associated I/O point. Descriptions
will automatically link to several documentation fields in vari-
ous function blocks (such as cell comments in ladder logic).
Initial Value
The initial value of the variable when it is loaded into the Re-
gent (when the I/O configuration is loaded and when the pro-
gram that owns the variable is loaded).
Final Value
The final value of the variable is loaded to the Regent when
the program that owns the variable is deleted.
Important! You should always configure the final values for outputs to be
the safe state, in most cases this will be 0 (0 is off for digital
outputs). If you do not enter a final value for outputs when
the program is deleted the outputs will remain in the last state
solved by the application program.
Comm Protect
Choosing Comm Protect prevents the variable from being
overwritten by communications commands when comm pro-
tection is loaded and enabled. For more information on the
Load Comm Protect and Enable Comm Protect commands see
Section 7, Loading, Monitoring and Testing Application Pro-
grams.
Note that digital I/O modules can be assigned module names
as well as point names. Module names represent the status of
the 16 I/O points of the module in a 16-bit word. It is often
useful to assign module names to redundant digital input
modules. Using the module names you can configure digital
input voting logic on a module level rather than on a point-by-
point basis.
I/O points that are left as spares (and are not connected to
field devices) do not have to be named; however, it is a good
idea to enter a description of the point noting that it is a

spare. If you decide to use these points at some later date,

simply open the I/O Configuration Editor and assign names to
the spares that you want to use. After assigning the point a
name it can then be used in your application program.
File Menu
Save Configuration
Saves changes made during the edit session to a new version
number. Repeated saves during a single edit session replace
previous saves during the edit session.
This command is normally disabled until changes are made
during the edit session. An exception is when you open an old
version from the I/O configuration version history, which al-
lows a Save Configuration without making any changes. This
saves the old version to the next highest version number
available.
Revert to Last Saved
Abandons any changes made since the last Save Configuration
command was issued in the current editing session. If you
have not issued a Save Configuration command during the
current editing session this command will return to the origi-
nal version opened at the beginning of the edit session. This
command is dimmed unless the I/O Configuration Editor’s ti-
tle bar displays the “(modified)” flag indicating that changes
have been made but not yet saved.
Compile
Compiles the current configuration. If any errors are found
during the compile process a compiler error dialog box will be
displayed.
View Error Messages
Use this command to display a list of errors generated by the
last compile operation. From the View Error Messages dialog
box you can print the errors by choosing Print. The printout
is useful as a guide to where you must edit the I/O configura-
tion and make changes in order to successfully compile. After
viewing or printing the error messages choose OK to return to
the I/O Configuration Editor.

Figure 77. The View I/O Error Messages Dialog Box.

Print Configuration
Use this command to generate a variety of printouts docu-
menting the I/O configuration. From the Print I/O Configura-
tion dialog box choose Print I/O Map, Print I/O Summary, and
Print I/O Source. Choose OK to print your choices or Cancel
to return to the I/O Configuration Editor without printing.
Figure 78. The Print I/O Configuration Dialog Box.

Print I/O Map
Prints a grid map of all 10 I/O slots for all 16 I/O chassis.
Each grid position indicates what type of module is configured
for the I/O slot. Modules are referenced by their catalog num-
ber and a type designation indicating the type of I/O (such as
DI, DO, AI, AO, TC, RTD, MGO, LMI, FDI, etc.) and the
number of I/O channels (6, 8, 16, or 24).

Print I/O Summary

Prints a summary list of the types of I/O modules installed.
Lists the catalog number, type designator and description (for
example, T3481 MGO 16 Monitored Guarded Output Module,
24 VDC) for each type of I/O module.
Print I/O Source
Prints a complete listing of all I/O module and point configu-
rations. Each module listed in sequential order by slot num-
ber and unit number followed by complete tag name, descrip-
tion, and other configuration information (initial and final
values, comm protection, fault fields, etc.) for each I/O point.
Print Setup
Log Off
Exit
Application.
Important! This is not how to close the I/O Configuration Editor as this
command will close the entire WINTERPRET application. See
page 145, Closing the I/O Configuration Editor.
Edit Menu
Edit Module Definition
Use this command to open the Module Edit dialog box to edit
I/O configuration for the selected module. This contents of
this dialog box will vary depending on the type of I/O module,
but it will generally list the names and descriptions of the I/O
points for the module.

If no module type is yet defined, this command will first open

the Set Module Type dialog box (if the user has the access
right “edit I/O module layout”).
From the Edit Module dialog box select an I/O point and
choose the following buttons to perform various I/O configura-
tion functions.
Done
Saves any changes you have made to the module definition,
and returns you to the I/O Configuration Editor.
Cancel
Abandons any changes you may have made to the module
definition and returns you to the I/O Configuration Editor.
Edit
Opens the I/O Point Definition dialog box allowing you to en-
ter configuration information for the selected I/O point.
Insert
Shifts all point definitions down one position from the current
selection point. The insertion point will either be blank or
will be a duplicate of the point last selected by Copy (see be-
low).
Delete
Deletes the selected point from the module configuration and
shifts all I/O point definitions below this point up one posi-
tion.
Copy
Copies the selected point to an internal buffer that can be in-
serted at another position in the I/O module definition (see
Insert above).
Clear
Clears all configuration information for the selected point.
Set Module Type
Use this command to set the type of module for the selected
I/O slot. For more information see page 133, Assigning Mod-
ule Types to the I/O Slots.
Insert Module
Use this command to insert an empty module (or a copy of a
module, see below) at the current position and move other

modules (until the next empty slot) to the right one slot.
There must be an empty slot to the right in the I/O chassis to
insert a module. The Insert Module command effects only the
modules in the selected chassis; modules cannot be pushed to
another chassis (in other words, they are not going to move
from slot 10 in the current chassis to slot 1 in the next chas-
sis).
Using this command requires the access right “edit I/O mod-
ule layout.”
Delete Module
Use this command to delete the module at the current position
in the I/O map and shift all other I/O modules in the chassis
left one slot. If Prompt for Delete is selected from the Options
menu you will receive a confirmation prompt.
ule layout.”
Important! There is no undelete function. If you accidentally choose De-
lete I/O Module you should either use the Revert to Last
Saved command or close the I/O Configuration Editor without
saving your changes.
Copy Module
Copies a module definition. Use the Copy Module command,
followed by the Insert Module command to place a copy of a
module into the desired position.
ule layout.”
Make Module Empty
Use this command to remove the selected I/O module and
make the slot “empty.” Similar to Delete Module but does not
shift remaining modules in the chassis to the left. When the
Make Module Empty dialog box is displayed, choose Yes to
continue or No to cancel this operation.
ule layout.”
Insert Empty I/O Assembly
Use this command to insert an empty I/O assembly at the se-
lected chassis position and shift the selected (and any subse-
quent) I/O assemblies down one assembly. There must be an

empty I/O assembly below the current position to insert an I/O

assembly. When the Insert Unit dialog box is displayed,
choose Yes to continue or No to cancel this operation.
ule layout.”
Delete I/O Assembly
Use this command to delete all of the I/O module definitions
in the selected I/O assembly and shift all assemblies below up
one. If Prompt for Delete is selected from the Options menu
ule layout.”
Important! There is no undelete function. If you accidentally choose De-
lete I/O Assembly you should either Revert to Last Saved, or
close the I/O Configuration Editor without saving your
changes.
Search Menu
Go to Slot
Use this command to move to a specific I/O slot in the I/O
Configuration Editor. From the Go to Slot dialog box enter
the desired I/O assembly number, I/O slot number. Choose
OK to go to the selected slot or Cancel to return to the I/O
Configuration Editor.
Figure 79. The Go to Slot Dialog Box.
Options Menu
Prompt for Delete


Compare to Regent
Use this command to compare the WINTERPRET I/O configura-
tion to the I/O Configuration information from the Regent
Controller. From the Compare to Regent dialog box you can
choose various options for the configuration comparison (these
options are explained below). After making your choices select
OK or Cancel to return to the I/O Configuration Editor.
Figure 80. The Compare to Regent Dialog Box.

Typical choices would be Configuration (Physical) and Display
Differences (Yes). This would compare the physical I/O con-
figuration that was connected to the Regent at cold start with
the configuration currently open in the I/O Configuration Edi-
tor.
If there is a difference between the selected I/O configuration
and the WINTERPRET I/O configuration, the I/O map will show
a module type in brackets for each I/O slot that is different.
An example of this is shown in Figure 81. In order to execute
this command the PC running the WINTERPRET application
must be connected to a Regent.

Figure 81. Example of I/O Map, Compare to Regent.

Configuration
Choose Physical to compare to the actual I/O modules that
were connected to the Regent when it cold started. Choose
User-Defined to compare to the user-defined I/O configuration
that was loaded into, and is being used by, the Regent.
Show Differences
Choose Yes to see the differences on the I/O map. Choose No
to hide the comparison differences.
You must choose Yes before you can make selections for Con-
figuration.
Window Menu
Help Menu

Closing the I/O Configuration Editor

Close the I/O Configuration Editor using CRTL+F4 (or click
the I/O Configuration Editor window’s Control-menu box and
choose Close [ALT,HYPHEN,C], or double-click on the Control-
menu box). From the Close I/O Configuration Editor dialog
box you should enter a brief version description of your rea-
sons for changing the I/O configuration. This description is
displayed when you view the I/O configuration history.
Figure 82. Closing the I/O Configuration Editor.

Choosing Yes, No, or Cancel performs the actions described
below.
Yes
Saves your changes and prompts you to compile (if you ha-
ven’t already compiled during your editing session). Closes
the I/O Configuration Editor.
No
Abandons your changes and prompts you to compile (if the
previous compile does not match the last saved version).
Cancel
Returns you to the I/O Configuration Editor.
Important! Choosing No at the Compile prompt will remove all I/O con-
figuration tag names from the compiled project dictionary.
Subsequent compiling of function blocks will not link to I/O
configuration information and may produce function block
compile errors. You should normally answer Yes to the Com-
pile prompt.

Using the Shared Variable Editor

The Shared Variable Editor lets you define the names of the
internal control relays and registers used in application pro-
grams. These shared variable names are combined with the
I/O names to form the project's dictionary – and are the only
common data reference between programs. Before a shared
variable can be used in a function block it must be defined us-
ing the Shared Variable Editor.
To use the Shared Variable Editor, open the project whose
variables you want to add to or edit. After opening the proj-
ect, choose Shared Variables from the Project Editor's Defini-
tions menu [ALT,D,S].
Defining shared variables involves two primary steps,
1. Allocating the amount of memory for shared variables in
the Regent controller. Do this using the Configure menu’s
Allocate Register Space command.
2. Creating and editing individual shared variable definitions
for control relays, registers and floating point registers.
In the Shared Variable Editor, use the View menu to switch
between the control relay, word register and floating point
register definition lists. The Shared Variable Editor is shown
in Figure 83, with the view selected for control relays.
Figure 83. The Shared Variable Editor.

Allocating Register Space

The Allocate Register Space command in the Shared Variable
Editor's Configure menu lets you define the amount of mem-
ory in the Regent to be set aside for shared variables. By allo-
cating a quantity of each shared variable type, you can plan
for on-line expansion and growth during the service life of
your system.
If you do not specifically perform this command WINTERPRET
uses default values for shared variable allocation. There are
also maximum values for shared allocation that cannot be ex-
ceeded. These limits are listed in Table 15. For more details
see the Allocate Register Space command on page 15353.
Table 15. Shared Variable Allocation Limits.
Type Default Maximum
Control Relays 2472 7592 - digital I/O
Word Registers 500 6500
Floating Point Registers 100 6500
Creating Shared Variables

You create shared variables by using either Add or Insert
commands from the Edit menu. When you add a shared vari-
able it is placed at the end of the variable list in the Shared
Variable Editor. Inserting a shared variable inserts a new
variable before the selected position in the list moving existing
variables down one position from the point of insertion. When
you create a shared variable, a dialog box similar to the one
shown in Figure 84 will open.
Figure 84. The Add Shared Control Relay Dialog Box.

All shared variables are defined by assigning them a name,

and description and an optional initial value, final value, and
comm protection.
Name
Each shared register, control relay, and floating point register
must have a name that is different from the names of all other
shared variables, I/O points, and local variables. The name
you define is the programming reference you will use in your
programs’ function blocks to reference this shared variable.
Description
The Description text box lets you add a text description of the
shared variable. Descriptions will automatically link to sev-
eral documentation fields in various function blocks (such as
cell comments in ladder logic).
Initial Value
The initial value of the variable is loaded to the Regent when
the shared allocation is loaded and also when the program
that owns the variable is loaded.
• The initial value for shared control relays can be set to ei-
ther 1 (on) or 0 (off).
• The initial value for word relays can be set to any integer
between -32,768 and +32,767.
• The initial value for floating point relays can be set to any
value between 1.175494e-38 and 3.402823e+38.
Final Value
The final value of the variable is loaded to the Regent when
the program that owns the variable is deleted.
• The final value for shared control relays can be set to ei-
ther 1 (on) or 0 (off).
• The final value for word relays can be set to any integer
between -32,768 and +32,767.
• The final value for floating point relays can be set to any
value between 1.175494e-38 and 3.402823e+38.
Comm Protect
Choosing Comm Protect prevents the variable from being
overwritten by any type of external communications when
comm protection is loaded and enabled. For more information

on the Load Comm Protect and Enable Comm Protect

commands see Section 7, Loading, Monitoring and Testing
Application Programs.
File Menu
Save Shared Variables
Using this command requires the access right “edit shared
variable definitions.”
Saves changes made during the edit session to a new version
number. Repeated saves during a single edit session replace
previous saves during the edit session.
This command is normally disabled until changes are made
during the edit session. An exception is opening an old ver-
sion from the Shared Variable Version History, which allows a
Save Shared Variables without making any changes. This
saves the old version to the next highest version number
available.
Abandons any changes made since the last Save Shared Vari-
ables command issued during the current edit session. If you
have not issued a Save Shared Variables command during this
edit session, this command will return to the original version
opened at the beginning of the edit session. This command is
dimmed unless the title bar of the Shared Variable Editor’s
title bar shows the “(modified)” flag indicating that changes
have been made but not yet saved.
Compile
Compiles the current configuration. If any errors are found in
the compile process a compiler error dialog box will be dis-
played.
View Error Messages
last compile operation. From the View Error Messages dialog
box you can print the errors by choosing Print. The printout

is useful as a guide to where you must edit the shared vari-

ables and make changes in order to successfully compile. Af-
ter viewing or printing the error messages select OK to return
to the Shared Variable Editor.
Figure 85. Viewing Shared Variable Errors.

Print Shared Variables
Use this command to generate a printout of the shared vari-
able definitions. Use the check the boxes to choose the shared
variable types to be included in the printout. Each shared
variable type will be printed in the order in which they appear
in the Shared Variable Editor. Each variable is listed by ad-
dress number (useful for MMI and DCS communications ad-
dressing), tag name, description, initial/final values, and
comm protection status. Choose OK to print your selection or
Cancel to return to the Shared Variable Editor without print-
ing.
Figure 86. The Print Shared Variables Dialog Box.

Print Setup
Log Off
Exit
Application.
Important! This is not how to close the Shared Variable Editor as this
page 155, Closing the Shared Variable Editor.
Edit Menu
Add New Definition
Use this command to define a new shared variable, which will
be placed at the end of the variable list. In the dialog box en-
ter the name, description, initial value, final value, and comm
protect configuration. For more details about these configura-
tion fields see page 147, Creating Shared Variables.
When you choose Add New Definition the dialog box fields
automatically contain a copy of the last entry entered or ed-
ited. You can use this to move a definition or make a copy of a
definition that you want to edit.
When you are finished choose OK to complete your definition
or Cancel if you decide not to add the new definition.
Edit Definition
Use this command to edit an existing shared variable. In the
dialog box edit the name, description, initial value, final value

and comm protect configuration. For more details about these

configuration fields see page 147, Creating Shared Variables.
or Cancel to close the dialog box without saving your changes
to the definition.
Insert Definition
Use this command to insert a new shared variable, which will
be placed before the selected variable. In the dialog box enter
the name, description, initial value, final value, and comm
protect configuration. For more details about these configura-
tion fields see page 147, Creating Shared Variables.
When you choose Insert Definition, the dialog box fields
automatically contain a copy of the last entry entered or ed-
ited. You can use this to move a definition or make a copy of a
definition that you want to edit.
or Cancel to close the dialog box without inserting the defini-
tion.
Delete Definition
Deletes the currently selected variable from the shared vari-
able list. If Prompt for Delete is selected from the Options
menu you will receive a confirmation prompt.
Search Menu
Find
Use this command to search the shared variable definitions for
a particular text string. The search constraint options avail-
able in the dialog box are described below. After making your
search selections choose Find Next to perform the search or
Cancel to return to the Shared Variable Editor.

Figure 87. Finding Shared Variables.

Find What
Enter the text string that you want to find.
Match
Choose the match conditions, Anywhere in Word, Beginning
of Word, Whole Word, Description Text (word refers to the tag
name).
Variable Type
Choose All to search the control relay, register and floating
point register lists. Choose Current Only to constrain the
search to the currently viewed variable type.
Direction
Choose Up or Down to define in which direction you want to
search in the variable list.
Find Next
Repeats the last specified Find command.
Configure Menu
Allocate Register Space
variable definitions” and “allocate shared register space.”
Use this command to define the amount of each variable type
to allow for in the Regent system. This allocation is loaded
into the Regent before any application programs are loaded

(see Section 7, Loading, Monitoring and Testing Application

Programs, Using the Execution Controller, Load Shared Allo-
cation command). Control relay space is allocated from the
digital I/O space of SRAM memory of the Regent. The maxi-
mum combined digital I/O space is 512 words (8,192 bits).
The word registers and floating point registers space is allo-
cated from the Regent’s RAM (128K or 512K, depending on
the catalog number of the processor modules).
Be sure that the space you allocate is sufficient to allow for fu-
ture tag name definitions to be added to those required at the
time you commission the system. For example, if at comple-
tion of program development the shared variable definitions
contain 500 control relays, 100 word registers and 20 floating
point register tag names, an allocation of 600, 150 and 30
would allow 100 control relays, 50 word registers and 10 float-
ing point registers to be added to the list and used in applica-
tion programs without requiring the programs in the Regent
to be stopped and deleted to create more shared variables. For
further information on other allocation considerations, see
page 163, Regent Memory.
In the Allocate Register Space dialog box enter values for Max.
Control Relays, Max. Word Registers and Max., Floating Point
Registers. After entering your values choose OK or choose
Cancel to close the dialog box without changing the allocation.
Figure 88. The Allocate Register Space Dialog Box.

Set Comm Protect
Sets the comm protection flag for all of the selected variables
in the current variable list.

Click and drag with your mouse to select multiple definitions.

Clear Comm Protect
Clears the comm protection flag for all of the selected vari-
ables in the current variable list.
Click and drag with your mouse to select multiple definitions.
View Menu
This command lets you choose the type of shared variables list
to display in the Shared Variable Editor. Choose either Con-
trol Relays, Word Registers, or Floating Point Registers.
Options Menu
Prompt for Delete
Window Menu
Help Menu
Closing the Shared Variable Editor

Close the Shared Variable Editor using CRTL+F4 (or click the
Shared Variable Editor window’s Control-menu box and

choose Close [ALT,HYPHEN,C], or double-click on the Control-

menu box). From the Close Shared Variables dialog box you
should enter a brief version description describing your rea-
sons for changing the configuration. This description is dis-
played when you view the Shared Variables History.
Figure 89. Closing the Shared Variable Editor.

Choosing Yes, No, or Cancel performs the actions described
below.
Yes
Saves your changes and prompts you to compile (if you ha-
ven’t already compiled during your editing session). Closes
the Shared Variable Editor.
No
Abandons your changes and prompts you to compile (if the
previous compile does not match the last saved version).
Cancel
Returns you to the Shared Variable Editor.
Important! Answering No to the Compile prompt will remove all shared
variable names from the compiled project dictionary. Subse-
quent compiling of function blocks will not link to shared
variable definitions and may produce function block compile
errors. You should normally answer Yes to the Compile
prompt.
Regent Variable Types and Memory

When you configure and program the Regent you use names
to represent may types of data in your system. Some of these
names represent inputs and outputs to monitor and control
process sensors and actuators connected to the Regent. Other

names do not represent physical devices, rather they represent

internal values, stored only in the Regent. These may be cal-
culated values, timer/counter accumulates, alarms, buffered
values for communications, status information about hard-
ware faults, and much more. In addition to the I/O variables,
inside the Regent there are three other categories of variables
used for data: system variables, shared variables and local
variables.
Before you create your application programs you should un-
derstand all four of these variable categories, in order to effec-
tively configure your Regent system.
Input and Output Variables

I/O variables represent the operating status of the field devices
connected to the Regent’s input and output modules. Using
the I/O Configuration Editor, you define the types of I/O mod-
ules to be installed and assign names for the appropriate input
and output variables.
One characteristic of I/O variables is that they can be used in
any application program you create for the Regent. For in-
stance, any input variable can be used in any application pro-
gram, allowing the application program to monitor the status
of the input sensor. An output variable can also be used in
any application program, however only one application pro-
gram can “own” the output. A program owns a variable when
it contains program instructions that solve and write to the
variable. This means that an output can be controlled by only
one program, but all other programs can monitor the state of
the output variable for other interlock purposes.
System Variables
System variables are internal variables that have been prede-
fined to represent a variety of information about the operating
status of the Regent equipment. Because they are predefined
you do not need to configure these variables, they are avail-
able in every Regent system. From the Project Editor you can
open a dialog box to view and print the system variables.
Most of the system variables represent fault status informa-
tion for the Regent modules. Because the Regent controls the
status of these variables, most of them can only be monitored
by your application programs (your programs cannot “own” or

write to them). These read-only variables are clearly marked

in the system variable list.
Some system variables are available for your programs to con-
trol, if desired. These include the system variables used to set
the Regent’s real-time clock and a general alarm bit your pro-
grams can set to energize the Regent’s fault contacts.
For more information, refer to the descriptions of the vari-
ables found in the System Variables dialog box.
Shared Variables
Shared variables are internal variables that you configure us-
ing the Shared Variable Editor. This internal variable cate-
gory is called “shared” because the variables you define can be
shared among all of your application programs. Similar to an
output variable, a shared variable can only be “owned” by one
application program, but can be monitored by any application
program.
When you begin to create your system configuration, it may
not be clear what variables you will need to define as shared
variables. Some guidelines to help you determine your needs
for shared variables are listed below.
1. If you plan on creating more than one application program
for your system, any variable that you control in one pro-
gram and need to monitor in another (other than I/O and
system variables) should be defined as a shared variable.
2. If your system has redundant input modules configured,
you will probably want to define shared variables to repre-
sent the results for the voted (digital inputs) or mid-value
selected (analog inputs) input data. By defining them as
shared variables, the resolved input data will be available
to all application programs.
3. If you plan on connecting the Regent to an external com-
munications interface (such as a DCS Gateway, MMI, etc.)
you may want to “pack” all of the required I/O and inter-
nal Regent data into a block of shared variables that can
simplify the communications configuration and enhance
the communications throughput. If your communications
equipment is to be configured to write data to the Regent,
the associated variables must be configured as shared vari-
ables. See Section 8, Safety Considerations, for safety
critical communications requirements.

4. If you plan on connecting the Regent to other Regents us-

ing the Guarded Peer-Link, all internal data to the Regent
that you need to communicate should be defined as shared
variables. Any variable received by one Regent from an-
other should be configured as a shared variable.
5. Certain application programming instructions and fields
may need to be defined as shared variables if they are in-
ternal variables to the Regent. Examples include timing
parameters for sequence of events and process historian
function blocks, as well as latch and unlatch coils in ladder
logic function blocks.
Local Variables
Local variables represent internal variables that are local to a
single application program. You are not required to perform
any particular configuration steps to define local variables. A
variable used in an application program will automatically be
local to a program because it has not been defined as an I/O
variable, shared variable or system variable.
For example, if the name “MOTOR1FAIL” is used in your appli-
cation program, but is not defined as an I/O variable or shared
variable, it will be local to the program and can be used in any
of the function blocks of the application program. If you use
this name in a second application program, it will not refer-
ence the same data as the first program. Instead, it will repre-
sent another, independent local variable in the second applica-
tion program. If the name “MOTOR1FAIL” should represent a
single common internal variable, it should be defined as a
shared variable.
Note: The DOS-based Program Development System (PDS) for the
Regent associates local variables with an individual function
block, not an individual program as is done in WINTERPRET.
If you upgrade a system that was originally configured using
PDS to WINTERPRET you should examine the use of local vari-
ables carefully to determine whether you need to make modifi-
cations to your previous local variable names in order to main-
tain variables individual to function blocks.
Data Types
For each category of variables in the Regent, there are differ-
ent data types representing bit, word, or floating point types
of information, as shown in Table 16.

Table 16. Variable Categories and Data Types

Data Type
Floating
Variable Category Bit Word Point
Inputs/Outputs DI DIW Not
applicable
DO DOW
AI
TI
AO
System Variables SYCR SYW Not
applicable
Shared Variables SHCR SHW SHFP
Local Variables CR W FP
Data Type Formats

Bit data types are either on (1) or off (0).
Word data types are signed, 16-bit integers that may range
from -32,768 to +32,767.
Floating point data types are 32-bit floating point registers that
may only be used in floating point math function blocks. Float-
ing point registers represent values between 1.175494e-38 and
3.402823e+38.
The acronyms for the data types for each variable category in
Table 16 are described below. They appear in various
WINTERPRET windows and dialog boxes. For I/O variables,
detailed descriptions identify specific I/O point configuration
fields, module types, and data formats applicable to each data
type.
Digital Input (DI)
A digital input is the name of an input point on a digital input
module, monitored input module, fire detector input module
and matrix interface module, and also the fault name of an in-
put point on a monitored input module, fire detector input
module, or Monitored Guarded output module.
Digital Input Word (DIW)
A digital input word is the name or fault name assigned to the
module types indicated above for digital inputs. The digital
input word represents all sixteen of the corresponding digital
inputs.

Digital Output (DO)

A digital output is the name of an output point on a digital
output module, matrix output module, guarded output mod-
ule, and monitored guarded output module, and also the reset
name and LED force name for a fire detector input module.
Digital Output Word (DOW)
A digital output word is the name, reset name and LED force
name assigned to the module types indicated above for digital
outputs. The digital output word represents all sixteen of the
corresponding digital outputs.
Some digital output modules have only eight points. In these
cases the digital output word still is a sixteen bit word, where
the least significant eight bits are the digital outputs.
Analog Input (AI)
An analog input is the name of an analog input point on an
analog input module. The lower 12 bits in the 16-bit word
represent the analog input data, ranging from 0 to 4,095. The
most significant bit is a no signal bit representing an out -of-
range input signal. When used in application programming
instructions, the most significant 4 bits are always masked,
and only the 12 bits of data are processed (an exception is
Block Move in ladder logic which does not mask the most sig-
nificant 4 bits). The no signal bit can be examined in ladder
logic by using the NOSIG instruction.
Analog Output (AO)
An analog output is the name of an analog output point on an
analog output or guarded analog output module. Analog out-
puts have the same data format as analog inputs (0 to 4,095
data range). Analog outputs do not have no signal bits.
Temperature Input (TI)
A temperature input is the name of an input point on a ther-
mocouple input module and RTD input module. These mod-
ules provide linearized temperature data in either degrees
Fahrenheit or Celsius and in units or tenths of degree —
based upon user-configurable jumpers on the associated
thermocouple and RTD multiplexers. The most significant bit
is a no signal bit similar to analog inputs.

System Control Relay (SYCR)

System Word (SYW)
Shared Control Relay (SHCR)
Shared Word Register (SHW)
Shared Floating Point Register (SHFP)
Local Control Relay (CR)
Local Word Register (W)
Local Floating Point Register (FP)
The Symbol Table

WINTERPRET maintains a symbol table for each project. The
symbol table contains a compiled list of all the names, data
types, and addresses of the I/O variables, system variables,
and shared variables. Each time you compile the I/O configu-
ration or the shared variables the symbol table is updated.
The symbol table allows WINTERPRET to “translate” the
names you use in your application programs into Regent
memory addresses. This translation occurs when you compile
the function blocks of your application programs to create ex-
ecutable code that can be loaded to the Regent.
When a function block is compiled, the compiler examines the
symbol table for the names used in the function block. For
names found in the symbol table, corresponding memory ad-
dresses are used in the compiled function block. Any names
not found in the symbol table are automatically identified as
local variables for the application program. When you load
the application program, WINTERPRET links all of the function
block lists of local variables into a program local variable list.
During the course of project development you may edit your
configuration and application programs several times. It is
important that this iterative development process does not
lead to inconsistent symbol table references by your function
blocks and programs. WINTERPRET and the Regent check the
consistency of your symbol references very thoroughly when
you load your application programs.

Regent Memory
The Regent’s processor modules contain memory used to store
your application programs, and variables. The Regent’s mem-
ory is divided in two particular areas of interest: main proces-
sor RAM and shared RAM. Each of these memory areas is
discussed below along with particular details that you need to
consider when planning your configuration and programs.
Shared RAM
The shared RAM (or SRAM) is used to store all of your I/O
variables, system control relays and shared control relays.
Every Regent system has 8K bytes of SRAM as shown in
Figure 90.
Figure 90. Shared RAM.

Within SRAM is an area of 1,024 bytes for bit addressable
data. Within this memory area all of your digital I/O, system
control relays, and shared control relays are allocated and
stored. Another 6,556 bytes of SRAM is used to store the ana-
log and temperature inputs and analog outputs. There is also
612 bytes of SRAM that are used internally by the Regent.
WINTERPRET automatically develops a map for SRAM memory
based on the type of I/O modules you define in the I/O Con-
figuration Editor and the shared control relay allocation
amount you define in the Shared Variable Editor.

The 1,024 bytes of bit-addressable SRAM limits the amount of

bit type variables (DI, DO, SYCR, and SHCR) you can define
to 8,192 (1,024 multiplied by 8 bits/byte). Since there are al-
ways 600 system control relays predefined for each Regent,
the maximum total of digital I/O points and shared control re-
lays is 7,592.
You can use the information in Table 17 in order to calculate
the amount of SRAM used for your I/O modules. Using the to-
tal of digital I/O memory required you can calculate the
maximum number of shared control relays that you can allo-
cate for your system, using the following formula:
7,592 - (digital I/O memory) =
maximum shared control relay allocation

Table 17. I/O Module Memory Requirements.

Bit I/O Word I/O
Catalog No. Module Description Field DI 1 DO 1 AI AO
T3401, T3402, Digital Input Modules, 16 pt Name 16

T3404, T3408
T3411, T3411F, Monitored Digital Input Modules, 16 pt Name 16

T3418F
Fault 16
T3419 Fire Detector Input Module, 16 pt Name 16
Fault 16
Reset 16
LED 16
Force
T3420A, T3420AF Analog Input Modules, 8 chnl Name 8
T3420A, T3420AF Analog Input Modules, 16 chnl Name 16
T3431 Thermocouple Input Module, 32 chnl Name 24
T3432 RTD Input Module, 16 chnl Name 16
T3441A, T3444 Digital Output Modules, 16 pt Name 16
T3446L, T3446H, Digital Output Modules, 8 pt Name 16 2

T3454
T3461A, T3462A, Guarded Digital Output Modules, 8 pt Name 16 2

T3468A, T3485
T3464 Guarded Digital Output Module, 16 pt Name 16
T3470A Analog Output Module, 8 chnl Name 93
T3480 Guarded Analog Output Module, 6 chnl Name 6
T3481, T3484, Monitored Guarded Output Module, 16 Name 16

T3488 pt
Fault 16
T3491 Matrix Interface Module, (max. 12x64

pt)
Name 64
- 64 pt. Mux Input Module (max. 8
Name 128
mod's)
- 64 pt. Mux Output Module, 2-bits per

output (max. 4 mod's)
1. Digital I/O “Module Names” (type DIW, DOW) refer to the same 16-bits, no additional
memory required.
2. Digital Output Modules with 8 points require 16 bits in memory, of which only 8 are
used.
3. Analog Output Modules with 8 points require 9 words in memory, of which only 8 are
used.

Main Processor RAM

The Regent’s processor modules contain either 128K or 512K
of main processor RAM. This memory is used to store the
RAMcode portion of the TRIOS operating system, the shared
registers, shared floating point registers, variable ownership
tables, application programs, and additional workspace areas
for various system functions. A simple memory map is shown
in Figure 91. The various portions of memory are described
below.
Figure 91. Main Processor RAM.

TRIOS RAMcode
The Regent’s operating system, called TRIOS, has a RAMcode
portion that is loaded into the Regent from the WINTERPRET
application. The TRIOS RAMcode takes up approximately
27,492 bytes.
Workspace Area
The TRIOS operating system allocates approximately 25,544
bytes of memory as a workspace in which several Regent sys-
tem functions take place. These functions include things like:
fault reporting, forcing, communications buffers, and system
registers.
Shared Variable Space
The shared variable space is where the shared registers and
floating point registers are stored. The memory required for

the shared variable space is determined by the values you en-

ter for shared allocation in the Shared Variable Editor. Each
shared register requires 2 bytes (1 word) and each floating
point register requires 4 bytes (2 words). For example, the de-
fault allocation in the Shared Variable Editor is 500 registers
and 100 floating point registers, which require:
500 x 2 bytes + 100 x 4 bytes = 1400 bytes
Ownership Tables
The Regent contains an ownership table to keep track of pro-
gram ownership of all variables in the symbol table. The own-
ership has a minimum size that is allocated to track ownership
of all possible variables in SRAM. In addition to this mini-
mum, the ownership increases in size to track the allocated
shared registers and floating point registers. The size of the
ownership table, in bytes, can be determined using the follow-
ing formula:
SRAM variables + shared registers +
(2 x shared floating point registers)
where:
SRAM variables = 11,982 bytes (this is the minimum own-
ership table size),
shared registers = shared register allocation quantity
shared floating point registers = shared floating point reg-
ister allocation quantity
For example, for the default shared allocation of 500 registers
and 100 floating point registers, the ownership table would be
16,060 bytes (11, 982 + 500 + 2 x 100).
Application Programs and Function Blocks
Your application programs are stored in the main processor
RAM when you load them into the Regent. The space used for
an application program consists of a program data area (PDA)
and function blocks. The local variables for the application
program are stored in the PDA
Free Memory
Free memory is the memory area not currently used and
available for loading additional programs or reloading existing
programs. When you reload an existing program that is run-
ning in the Regent, the new version is loaded into free mem-
ory. When you switch to the new program, the Regent exe-

cutes the new program and the space occupied by the old
version becomes free memory.

Section 5
Working with Programs and

Function Blocks
The Regent is programmed just as simply as any conventional,
non-fault-tolerant, non-triple-redundant programmable
controller. Applications programming and documentation can
be done off-line in the convenience of your office, using the
Regent's Windows-based WINTERPRET application. When
downloaded, all programs are automatically triplicated by the
Regent system.
The Regent is capable of executing as many as 30 application
programs simultaneously. Multiple programs are executed
sequentially, one after the other.
Each application program is made of function blocks. Each
function block performs a part of a program. The number of
functions blocks that each program can have is limited to 50.
The number of function blocks may also be limited by the
memory available in the Regent.
The function blocks that are combined to create a program
can be of different types or all of the same type. You can
create function blocks using ladder logic (which includes
ASCII output) and analog scaling. Add-in software packages
provide additional function block types to allow you to
program using floating point math, sequence of events
recording, process historian, and continuous control (or PID).
For more information on these function blocks, please refer to
the appropriate product descriptions.

Table 18. WINTERPRET Add-In Software Packages.

Catalog No. Description Function Block Types
T3831 Communications Guarded Peer-Link (not a
function block)
T3832 Historian Sequence of events, process
historian
T3833 Math Floating point math
T3834 Continuous Control Continuous control (PID)
loops
Each type of function block has its own editing and

monitoring tools. The function block editors let you edit,
compile, and save function blocks, as well as print the
contents of each function block. The function block monitors
show you the function block's status and, in some cases, let
you change certain parameters and values within the function
block.
Where to Start
Before you begin creating application programs and function
blocks, you should follow the procedures in Section 4, Working
with Projects to create a project, define the I/O configuration,
define the shared variables, and define the serial port
configurations. You should also be familiar with the types of
variables in the Regent and certain memory allocation
considerations (see Regent Variable Types and Memory in
Section 4, Working with Projects).
This section discusses the procedures for planning and
creating application programs and function blocks. At the end
of this section you will find a discussion about the Program
Data Area (PDA). It is not important to understand the
details of the PDA in order to create application programs.
However, before you begin loading programs into the Regent
you should read the information about the PDA so that you
understand various characteristics of program local variables,
PDA allocation and expansion, and on-line programming
considerations.

Working with Programs and Function Blocks Section 5
Planning Programs
In order to plan your application program development using
WINTERPRET, you should gather information on the functional
requirements for the process interlock and control functions
that the Regent will perform. Often you will find this
information in logic diagrams, functional specifications, piping
and instrument diagrams (P&IDs) or cause and effect
diagrams. Having this information at hand will help make the
process of planning your application programs easier and
more efficient.
Programming with Function Blocks

Application programs for the Regent are made up of smaller
program parts called function blocks. Each function block
represents a particular set of program instructions which,
when combined with other function blocks, make up a
program that represents an entire set of instructions for a
particular process unit or plant. This structured
programming technique using function blocks allows you to
segment your entire set of functional requirements into
smaller sections. When you review your functional
requirements, you should identify these smaller sections and
plan to create individual function blocks for each of them.
Sometimes these smaller sections may represent a particular
piece of equipment such as a compressor or pump. Other
times these smaller sections may represent a type of function
like transmitter scaling, temperature alarming, or event
logging. Often the functional requirements documents will
already be organized in one of these ways.
WINTERPRET provides several types of function blocks you can
use to program your interlock and control actions. Ladder
logic and analog scaling are provided with the Base
WINTERPRET software package and other types are provided in
add-in software packages listed in Table 18. Keep these
function block types in mind as you review your functional
requirements.
An application program for the Regent can be developed using
any combination of function block types, arranged in any
order, with up to 50 function blocks in each application
program.

You need to pay attention to the order in which you position

the function blocks within the application program. The
function blocks are executed one after the other, in the order
in which they appear in the program editor. In some cases
changing the execution order of the function blocks can
change how certain logic functions interact with other logic
functions within the program.
Using Multiple Programs

In some cases you may want to create multiple programs, each
consisting of its own function blocks. By using more than one
program you will be able to separately load, run, stop, and
delete the programs in the Regent. This can be useful when
you want to shut down or modify a program for a particular
part of the plant without affecting other parts of the plant’s
operation.
When you use multiple programs for a single Regent, each
program has ownership of the variables that it controls.
Ownership protects controlled variables in one program from
being controlled by another program. In effect, each program
is like an individual controller, yet you have the advantage of
sharing information between programs because they are in
the same physical Regent controller. Information is shared
between programs when one program monitors the values of
variables controlled by another program. If these variables
are internal variables (instead of outputs) they need to be
defined as shared variables using the Shared Variable Editor
(see Using the Shared Variable Editor in Section 4, Working
with Projects).
An Example of Program Planning

The multiple program and function block architecture is best
illustrated by an example. In this example, the Regent
performs burner management interlocking for two boilers. In
addition to the two boilers there are other process interlocks
associated with miscellaneous process equipment in the boiler
process unit.
Separating Programs
In this example, four application programs are developed: one
for each boiler, one for the miscellaneous interlocks, and one

for sequence of events logging. The Project Editor in Figure

92 shows the names and descriptions of each of these
programs.
Figure 92. An Example of Multiple Programs.

By creating a separate program for each boiler, one boiler can
be taken off-line, its program can be modified and tested, and
it can be put back on-line without disrupting the other boiler
or process interlocks. The sequence of events program
contains three sequence of events function blocks – one for
each of the other plant areas. The sequence of events function
blocks could have been included in the individual control
programs; however, placing them in a separate program
ensures that each function block sequence of events log in the
Regent is not inadvertently cleared if the other programs are
ever modified and reloaded.
BOILER1: A Look at how Function Blocks are Organized
The functional requirements for the boiler defined various

interlock functions for burner management. Function blocks
for each of these areas were created. In addition to these
requirements, the system included fault tolerant inputs and a
variety of transmitters that need to be scaled to engineering
units. A ladder logic function block, called FTINPUTS, was
created to perform the necessary logic to resolve the input
data from the redundant digital and analog inputs. A scaling
function block, called XMTRS, was created to scale the
transmitter signals (which are midvalue selected in
FTINPUTS). Lastly, there is a printer connected to the Regent

for alarm output messages. The ladder logic function block,

called ALRMMSGS, was created and includes ASCII output
elements to drive alarm messages to the printer. The
Program Editor in Figure 93 illustrates the organization of
the function blocks for program BOILER1.
Figure 93. An Example of Function Block Programming.

Note that the two boilers are virtually identical (they both
monitor similar input sensors, control similar output
actuators, and have identical interlock requirements).
Because of this, the program BOILER1 was created and tested
first. After initial testing confirmed accurate implementation,
the program BOILER2 was created as a copy of the program
BOILER1. The program was printed (using the Cross
Reference command), and then each function block was edited
to change the names of the variables (I/O and shared) to the
appropriate names for BOILER2. This copy and modify
approach simplifies program development considerably.
Creating Programs with the Project

Editor
Using the Project Editor, programs are created in one of two
ways:
1) Create a new project from scratch using the New Project
command from the File menu [ALT,F,N]. After you create a

new project from scratch, the Program Editor window is

automatically opened.
2) Create a new program as a copy of an existing program
using the Copy Program command from the File menu
[ALT,F,C]. You can copy a program from the current
project or select a program from another project. After you
create a new program as a copy, the new program appears
in the list of programs in the Project Editor window.
The New Program and Copy Program commands are fully
described in Section 4, Working with Projects. Additional
program commands such as Delete Program and Get Program
History are also described in Section 4 (Using the Project
Editor).
To open an existing program for editing, select the program
you want to open and choose Open Program from the Project
Editor’s File menu [ALT,F,O]. This opens the Program Editor
window allowing you to create and edit function blocks.
6 Shortcut: Select the program that you want to open and double-click or
press ENTER.
Programs are always listed alphabetically in the Project
Editor. The actual execution order of multiple programs in
the Regent is determined by the order in which they are
loaded and switched to running or stopped using the
Execution Controller. For more information, see Loading
Application Programs in Section 7, Loading, Monitoring and
Testing Application Programs.
Using the Program Editor

The Program Editor is used to create, edit, and compile
function blocks, edit the program description and details,
print programs, and define program users. The Program
Editor displays the program name and version number in its
title bar and lists the function blocks used by the program
version. Each function block is listed by name, version
number, type, and description. An example of the Program
Editor is shown in Figure 94.

Figure 94. The Program Editor.

If you have created a new program from scratch, there will not
be any function blocks listed in the Program Editor until you
create them, see Creating Function Blocks below. If you have
opened an existing program for editing (or if you have just
made a copy of a program), you can select the function block
you want to edit and choose the Open Function Block
command from the Program Editor’s File menu [ALT,F,O].
The appropriate editor for the type of function block you’ve
selected will open and allow you to make changes (see page
191, Using the Function Block Editors).
Important! The order in which the function blocks appear in the Project
Editor is the order in which they are executed when the
program is loaded and running in the Regent.
Creating New Function Blocks

There are two ways to create a new function block from
scratch: either by using the Add Function Block command or
the Insert Function Block command from the Program
Editor’s Edit menu. These commands perform the same
action except that each places the new function block
differently within the list of function blocks. When you choose
Add Function Block, the function block is placed at the end of
the list. When you choose Insert Function Block the function
block is inserted just above the selected position in the list.

The Add Function Block dialog box is shown in Figure 95 (the

Insert Function Block dialog box is the same except that the
title bar is labeled “Insert Function Block”).
Figure 95. The Add Function Block Dialog Box.

The dialog box displays a list of function blocks from the
program directory (if any exist) and the phrase “(create new)”
at the top of the list. Select “(create new)” and choose OK to
define a new function block from scratch. A subsequent dialog
box shown in Figure 96 is opened where you should enter the
name and description for the function block, select the
function block type from the drop-down list and choose OK.
Figure 96. Creating a New Function Block.

After choosing OK to create a new function block, the editor
for the type of function block you selected will automatically
open and you can begin editing the new function block.
For general information about editing function blocks see
page 192, Commands Common to All Function Blocks.
Elsewhere in this section you will find details about ladder
logic (see page 197, Using the Ladder Logic Editor) and analog
scaling (see page 243, Using the Analog Scaling Editor). For

information on other types of function blocks, refer to the

product description listed in Table 18.
Copying Function Blocks

You can create a new function block that is a copy of an
existing function block by using the Copy Function Block
command from the Program Editor’s File menu. When your
application contains process equipment with similar interlock
and control requirements you can create a function block for
one set of equipment and later copy it for the other similar
equipment.
For example, if there are three compressors that have similar
interlock requirements, create a function block for the first
compressor and edit the function block to program the
interlock functions. After you have finished, create a new
function block for each of the other compressors by copying
the first compressor function block. This will reduce your
program development time because you will not have to repeat
the basic programming steps over and over; you can simply
edit the copied logic and change the names of the variables
appropriately for the other equipment.
1. Creating a copy of a function block involves two steps,
2. Making the copy,
Inserting (or adding) the copy to the desired position in the
list of function block for the program.
The source function block that you want to copy can exist in
any program of any project. The copy will be created in the
program directory of the currently open program.
To make the copy of the function block, choose Copy Function
Block from the Program Editor's File menu [ALT,F,C].

Figure 97. Copying a Function Block.

In the Copy Function Block dialog box select the source
project, the source program, the source function block you
want to copy, enter the destination name (the name of the
new function block), and select whether you want to copy just
the latest version or all previous versions of the function
block. When you are finished making your selections choose
OK.
After making the copy, the function block will not appear in
the list of function blocks until you place it in the list using
either the Add Function Block or Insert Function Block
command. Choose Add Function Block to place the copy at
the end of the list of function blocks. To place the copy in a
particular position in the list, select the position you want to
insert the function block above and choose the Insert
Function Block command. In the dialog box for Add or Insert
Function Block select the name of the copy you made and
choose OK. The function block will now appear at the desired
position in the list of function blocks. To edit the function
block, simply open it using the Open Function Block
command.
Opening a Function Block for Editing

To edit an existing function block, select the function block
that you want to edit and choose the Open Function Block
command from the Program Editor’s File menu.

6 Shortcut: Double-click on the name of the function block or select the

function block and press ENTER.
Changing the Order of Function Blocks

After you have created several function blocks you may find
that they need to be rearranged to execute in a different order
than that in which you created them. This is a simple
operation by using the Add, Insert, and Delete Function Block
commands from the Program Editor’s Edit menu.
For example, to move a function block, named FBMOVE, from
the end of the list to the beginning of the list you would
perform the following steps:
1) Select the first function block in the list.
2) Choose Insert Function Block.
3) Select the function block FBMOVE from the Insert Function
Block dialog box and choose OK. (Notice that FBMOVE is
now in the Program Editor’s list of function blocks twice,
once at the end and once at the beginning.)
4) Position the selection cursor on FBMOVE at the end of the
list.
5) Choose Delete Function Block, and answer any
confirmation prompts to confirm the delete operation.
Deleting Function Blocks

You can use the Delete Function Block command from the
Program Editor’s Edit menu to remove a function block from
the list of function blocks used by the version of the program
you are editing. However, this doesn’t delete the function
block from the disk, it still is stored in the program directory
on the disk of the PC running WINTERPRET. This allows you
to later add or insert the function block should you need it at a
later time. To completely delete a function block from the
program directory on disk, use the Unused Function Block
command from the Program Editor’s File menu (see page 185
for more details).

Program Editor Commands

File Menu
Save Program
This command is dimmed, or disabled, until changes have
been made to the program (for example, if function blocks
have been added, inserted, deleted, modified or if the program
editor was opened from the Get Program History dialog box
(by selecting an older version and choosing Open). The Save
Program command saves the program to the next highest
program version available. If repeated Save operations are
performed while in the Program Editor, only one new version
is created. Each subsequent Save replaces the previous one
until you close the Program Editor.
Using this command requires the access right “edit program
source.”
This command is dimmed unless the Program Editor’s title
bar shows the “(modified)” flag, indicating that changes have
been made to the program’s list of function blocks and that
these changes have not yet been saved. Modifications include
adding, inserting, deleting, or editing function blocks, or
changing the spare data space. If you choose Revert to Last
Saved, the function block list is returned to the state at which
you last performed a Save Program command (or returns to
the state at which you opened the Program Editor if you have
not performed a Save Program command).
Compile All
This command will compile the current version of every
function block in the program’s list of function blocks. Note
that function blocks not currently used by the program
version (not appearing in the program list) are not compiled.
source.”
Compile Changes
This command will check each function block in the current
program list to see if they need to be compiled. A function

block needs to be compiled if no successful compilation is

found, or if there have been changes to the I/O or shared
variable definitions that have affected the tag names used in
the function block.
source.”
View Error Messages
last compile operation. The error list identifies the program
name, and groups error messages by function block name.
Figure 98. Program Editor Compiler Errors.

From the View Error Messages dialog box you can print the
errors by choosing Print. The printout is useful as a guide to
where you may need to edit the function blocks and make
changes in order to successfully compile. In some cases you
may need to edit the I/O configuration or shared variables to
eliminate the errors. After viewing or printing the error
messages choose OK to return to the Program Editor.
Open Function Block
Opens the appropriate function block editor. See Using the
Function Block Editors, starting on page 191.

Get Function Block History

Use this command to open the Function Block Version
History dialog box where function block versions are listed by
Figure 99. Function Block Version History.

From this dialog box you can modify version descriptions,
delete versions you no longer need, and open any version for
Close
Closes the Function Block Version History dialog box.
Description
Using this button requires the access right “edit program
source.”
Delete
Deletes the selected version of the function block source file.
If Prompt for Delete is selected from the Options menu you
will receive a confirmation prompt.
The (IN USE) flag indicates that the version is currently in use
by one or more of the program versions. If you delete a
function block version that is used by a program version then
if you attempt to edit the associated program version you will
get an error.

It is recommend that you first delete program versions that

are no longer needed and then use this dialog to delete unused
function block versions.
Using this button requires the access right “edit program
source.”
Open
Opens the appropriate function block editor for the selected
version.
most current. Opening, saving, and compiling an older
version makes it a new version at the next highest version
number.
Copy Function Block
Use this command to create a new function block that is a
copy of an existing function block. In the Copy Function
Block dialog box select the function block that you want to
make a copy of from the drop down lists. Enter a name for
the destination (or new) function block and choose whether to
copy all versions or only the latest version.
When you have finished making your selections choose OK to
copy the function block, or choose Cancel to return to the
Program Editor without making a copy.
Choosing Latest Only will copy the latest function block
version and make it version 1 for the copy.
Copying a function block does not automatically add the
function block to the list of function blocks shown in the
Program Editor. Use the Add Function Block command to
add the function block to the end of the function block list.
Use the Insert Function Block command to insert a function
block at a particular place within the function block list.
See page 178, Copying Function Blocks for additional
suggestions on copying function blocks.
source.”
View Function Block Details
This command opens the Function Block Details dialog box.
While you can scroll up and down through the function block’s

details text box to view its contents, you are not allowed to
add or edit those details using this command. You can add or
edit a function block’s details using the Function Block
Editors (see Using the Function Block Editors, starting on
page 191).
When you have finished viewing the function block’s details,
choose Cancel.
Unused Function Blocks
Before using this command it is best to use the Program
Version History command to delete any program versions that
are no longer needed. Then use this dialog box to see what
function blocks are no longer used.
Figure 100. Unused Function Blocks.

This command does not display individual function block
versions that are not used. If at least one version of a function
block is used then it doesn't appear in this list. Use the Get
Function Block History command to identify and delete
individual function block versions. See page 183 for more
information on the Get Function Block History command.
If you have a function block that is not currently being used
by any program version but you may wish to later add it to the
program, do not delete it. Deleting a function block from this
list will completely delete all versions of the function block
from this program directory. You may want to copy function
blocks to a “library” project and program so that you can use
them later. See the Copy Function Block command on page
184 for more details.
source.”

Edit Program Description

Use this command to modify the description field for the
application program. When you have finished editing, choose
Save or Cancel.
Note that this is not the version description. See Section 4,
Using the Project Editor, Get Program History command for
information on changing an individual program version
description.
source.”
Edit Program Details
Use this dialog to enter textual information to document
particular details about the program. All program versions
share this Program Details, it is not version controlled.
Figure 101. Editing Program Details.

Use the Print Program command to print the program details.
source.”

Print Program
Use this command to generate program printouts. Use the
check the boxes to indicate what information you want to
include in the printout.
Figure 102. The Print Program Dialog Box.

Print Details Text
If checked, the program details will be included in the
printout.
Print Function Block Source
If checked, a complete print of all function blocks will be
included.
Include Comments
Pertains only to ladder logic function blocks. If checked,
ladder logic function blocks will be printed with cell comments
and rung comments.
Print Cross Reference
If checked, a program cross reference will be printed listing all
of the tag names used throughout the function blocks of the
program. If Print Function Block Source is also checked,
individual function block cross references will immediately
follow each function block source printout. The cross
references prints an alphabetical list of the tag names. For
each tag name the variable type and description are printed
followed by a one-line reference indicating where and how it is
used in the function blocks of the program.
Note that program local variables (tags used that are not I/O,
shared variables, or system variables) will show the variable

type as “????”. This makes it easy to identify local variables in

the cross reference listings
Print Setup
Use this command to configure the various options for your
Log Off
Exit
Important! This is not how to close the Program Editor, as this command
will close the entire Winterpret application. Close the
Program Editor using CTRL+F4 (or click the Program Editor
window’s Control-menu box and choose Close
[ALT,HYPHEN,C], or double click on the Control-menu box).
Edit Menu
Add Function Block
The Add Function Block command places the selected
function block at the end of the function block list for the
program. Choose Create New from the top of the list to define
a new function block. See page 176, Creating New Function
Blocks for more details.
source.”
Insert Function Block
The Insert Function Block command inserts the selected
function block before the highlighted function block in the
function block list for the program. Choose Create New from

the top of the list to define a new function block. See page
176, Creating New Function Blocks for more details.
source.”
Delete Function Block
Deletes the selected function block from the function block list
for the program. This does not delete the function block from
the program directory on disk as it may be used by other
versions of the program. Use the Unused Function Block
command to delete unused function blocks from the disk. See
page 185, for more information on the Unused Function
Blocks command.
If the Prompt for Delete option is set from the Options menu,
source.”
Definitions Menu
Spare Data Space
Spare data space refers to the amount of extra program local
data that will be allocated when the program is loaded in the
Regent. Spare data space is required in order to load a new
program version that needs more program local data than the
program version currently in the Regent.
Figure 103. Setting Spare Data Space for a Program.

Program local data is required for the local variables used in
the program and certain instructions in function blocks (for
example, timers and counters in ladder logic).
It is normal to use a value between 20 and 50 percent for
spare data space.


source.”
Program Users
System users with the access right “access all programs” do
not have to be added to the program user list, nor will their
names be shown automatically. Only the program’s creator
and names of users specifically added to the list will appear in
the program user list. System users who do not have the
access right “access all programs” must be added to each
program user list for which they should have access.
Figure 104. Program Users.

source.”
Choose from the following buttons:
Save
Saves your changes and closes the dialog box.
Cancel
Closes the dialog box without saving changes to the program
user list.
Add
Opens the Add Program User dialog box.
Use the drop-down list to select a system user to add to the
program user list. Note that only the users who are entered in
the project user list can be added to the program user list.
Choose OK to add the program user, choose Cancel if you
decide not to add the program user.

Delete
Deletes the selected user. If Prompt for Delete is selected
from the Options menu, you will have to confirm your
selection.
Tools Menu
Compare Function Blocks
Compares different versions of a function block and lists
where the function blocks are different. For more information
see Comparing Function Blocks in Section 6, Version
Tracking.
Options Menu
Prompt for Delete
Window Menu
Help Menu
Using the Function Block Editors

Function Blocks are edited by opening a project, opening a
program, and opening a function block. These steps are
outlined below. If you have already opened a function block,

you may skip to the section that describes the particular type
of function block you have opened, see Using the Ladder Logic
Editor (page 197) or Using the Analog Scaling Editor (page
243). Details on other function block types can be found in
their respective product description documents. You can also
use the on-line Help for additional information.
1. Open a Project. From the Project Selector, select the
project that you want to open and choose Open Project
from the Project Selector's File menu [ALT,F,O].
press ENTER.
2. Open a Program. From the Project Editor, select the
program that you want to open and choose Open Program
from the Project Editor's File menu [ALT,F,O].
6 Shortcut: Select the program that you want to edit and press ENTER or
double-click.
3. Open a Function Block. From the Program Editor, select
the function block that you want to edit and choose Open
Function block from the Program Editor's File menu
[ALT,F,O].
6 Shortcut: Select the function block that you want to edit and double-
click or press ENTER.
WINTERPRET will open the appropriate editor for the function
block you have selected and you can begin editing.
Commands Common to all Function Block

Editors
All of the function block editors share similar commands
accessible from the File menu. Each of these commands is
described below.
File Menu
Save Function Block
This command is dimmed, or disabled, until changes have
been made to the function block, or if the function block editor

was opened from the Get Function Block History dialog box
(by selecting an older version and choosing Open).
The Save Function Block command saves the function block,
creating a new version with an incremented version number
(the previous version remains unchanged). If repeated Save
operations are performed while in the function block editor,
only one new version is created. Each subsequent save
replaces the previous one until you close the function block
editor.
source.”
Abandons any changes made since the last Save Function
Block command was issued during the current editing session.
If you have not issued a Save Function Block command during
the current editing session this command will return to the
original version opened at the beginning of the edit session.
This command is dimmed unless the title bar of function block
editor shows the “(modified)” flag, indicating that changes
have been made to the function block that have not yet been
saved.
Compile
Compiles the current function block. If any errors are found
during the compile process, a compiler error dialog box will be
displayed. Function blocks must be compiled before they can
be loaded into the Regent. Function blocks may also be
compiled when you close the function block editor or by using
the Compile All or Compile Changes commands from the
Project Editor’s File menu.
View Error Messages
last compile operation. The error list identifies the function
block name and lists entries as either errors or warnings. An
error means that the function block was not compiled and
therefore cannot be loaded in the Regent until the error is
corrected. A warning means that an unusual use of a variable
was found that may not be what you had intended to program.
Warnings do not prevent the compile from completing, and
the function block may be loaded and run in the Regent.

Figure 105. Function Block Editor Compiler Errors.

From the View Error Messages dialog box you can print the
errors by choosing Print. The printout is useful as a guide to
where you may need to edit the function block and make
changes in order to successfully compile. In some cases you
may need to edit the I/O configuration or shared variables to
eliminate the errors. After viewing or printing the error
messages choose OK to return to the function block editor.
Edit Function Block Description
Use this command to modify the description field for the
function block. When you have finished editing, choose Save
or Cancel.
Note that this is not the version description. See the Get
Function Block History command on page 183 for information
on changing an individual function block version description.
source.”
Edit Function Block Details
Use this dialog box to enter textual information to document
particular details about the function block. All function block
versions share this Function Block Details dialog box — it is
not version controlled.

Figure 106. Editing Function Block Details.

Use the Print Function Block command to print the function
block details.
source.”
Print Function Block
Use this command to generate individual function block
printouts. Use the check boxes to indicate what information
you want to include in the printout.
Figure 107. The Print Function Block Dialog Boxes.

Print Details Text
If checked, the function block details will be included in the
printout.

Print Source/Ladder Logic

If checked, the complete contents of the function block will be
printed.
Include Comments (ladder logic only)
If checked, a ladder logic function block will be printed with
cell comments and rung comments.
Print Cross Reference
If checked, a function block cross reference will be printed
listing all of the tag names used throughout the function
block. The cross references prints an alphabetical list of the
tag names. For each tag name the variable type and
description are printed followed by a one-line reference
indicating where and how it is used in the function blocks of
the program.
Note that local variables (tags used that are not I/O, shared
variables, or system variables) will show variable type as
“????”. This makes it easy to identify local variables in the
cross reference listings
Print Setup
Use this command to configure the various options for your
Log Off
Exit
Important! This is not how to close a function block editor, as this
command will close the entire Winterpret application. Close a

function block editor using CTRL+F4 (or click the function

block editor window’s Control-menu box and choose Close
[ALT,HYPHEN,C], or double click on the Control-menu box).
Using the Ladder Logic Editor

The Ladder Logic Editor lets you create and edit ladder logic
function blocks by using predefined elements to draw graphic
representations of logic equations for a control application
using the familiar relay symbols defined in ANSI/NEMA
Standard ICS 3-304. After the function blocks have been
created, or edited, they must be compiled before they can be
loaded into the Regent.
When the ladder logic is loaded and running in the Regent the
rungs are executed from left to right and from top to bottom.
Ladder logic function blocks can be monitored using the
Ladder Logic Monitor.
The Ladder Logic Diagram

A sample ladder logic diagram is shown in Figure 108. In this
example the Ladder Logic Editor window has been maximized
to fill the entire WINTERPRET application workspace. The
status bar at the bottom of the window indicates the current
location of the selection cursor in the editor, in this case Rung
3 of 13, Row 1, Column 5. Notice that the fifth contact in the
third rung has a dashed outline surrounding it; this is the
selection cursor. Creating ladder diagrams is as simple as
placing the cursor at the desired position in the diagram and
choosing a ladder element from the drop down menus for
Relay, Coil, Logic, or Math.

Figure 108. A Sample Ladder Logic Editor Screen.
Starting a New Ladder Logic Diagram

If you have opened the Ladder Logic Editor to create a
function block a blank ladder diagram as shown in Figure 109
is displayed.
Figure 109. A Blank Ladder Logic Editor Screen.

Follow the steps described below to create ladder logic
diagrams to represent the logic functions required for your
application.

Insert a Row to Start a Rung

In the blank ladder diagram, the selection cursor fills an
entire row from left to right. Before you can draw any ladder
elements you must first choose Insert Row to create a left-
hand power rail. Repeat the Insert Row command for each
row in the rung. For example, if you want to create a rung
that has three contacts in parallel, you will have to insert
three rows.
6 Shortcut: Place the selection cursor where you want to insert a row and
press CTRL+W.
After you have inserted at least one row, the selection cursor
will shrink to the size of a single cell in the 10-column wide
ladder diagram as shown in Figure 110.
Figure 110. After Inserting a Row in the Ladder Diagram.

Position the Selection Cursor
Using the mouse or the keyboard, position the selection cursor
to where you want to add a ladder logic element. Note the
small inverted triangle on the left-hand side of the selection
cursor. This triangle indicates where a vertical connection
will be placed when you choose Vertical Connection from the
Edit menu.
Choose an Element from the Drop-down Menus
All ladder logic elements are chosen from one of the four
menus titled Relay, Coil, Logic or Math. Using the mouse or
the keyboard, select a menu and choose an element from the

drop down menu. The element will be drawn in the selected

location in the ladder diagram
Many ladder logic elements occupy only one cell in the
diagram, others may occupy multiple adjacent cells to the
right or below your current position. Each row in the diagram
is 10 columns (or cells) wide. There must be sufficient room
to place the element you selected in the diagram. Limitations
and requirements for each ladder logic element are described
individually later in this section.
Edit the Element to Enter Variable Names or Values
You must use the Edit Element command from the Edit menu
to open a dialog box for the ladder element. The dialog box
will contain fields that require entries of variable names,
numeric values, or other selections based on the type of
element. Guidelines for each element type are described
individually later in this section.
6 Shortcut: Select the ladder element that you want to edit and press
ENTER.
For example, if you draw a timer element and then choose

Edit Element, the dialog box for a timer appears on the screen
as shown in Figure 111.
Figure 111. Edit Element Sample: Timer.

In this dialog box you should enter a name for the accumulate,
a name or integer constant for the preset, and select the timer
units from the drop-down list. When finished making your
selections you would choose OK.

General Ladder Logic Drawing Guidelines

By repeating the steps above you can create ladder logic rungs
from virtually any combination of ladder elements. However,
certain limitations apply. There are only 10 columns in the
ladder diagram, and the tenth column is reserved for coil-type
elements. This allows you to create ladder logic rungs with up
to nine contacts in series energizing a coil. As you connect
rows together with vertical connections, you create parallel
logic configurations — up to eight rows maximum per ladder
logic rung. If you need to create serial or parallel logic
arrangements that exceed this limit, you will need to break
the logic into smaller segments that fit within these
constraints.
Overall, the editor has a very free-form structure — you are
not forced to follow a rigid procedure to draw, edit, or
interconnect elements in a particular fashion. Rather, you can
freely choose to first place the elements on the diagram to
form rungs, then go back and edit the elements to assign
variable names to them. In addition, the various insert,
delete, cut, copy and paste features allow you to easily change
your logic diagrams. These functions are found in the Ladder
Logic Editor’s Edit menu, and are discussed below.
Ladder Logic Editor Commands

Edit Menu
Many of the edit commands are only available when you select
a range of rows (or rungs) of the ladder diagram. To select
rows of the ladder diagram, use your mouse to click and drag
across the rows. As you drag the mouse across the rows they
will appear in reverse video as shown in Figure 112. When
you see the rows that you want to select appear highlighted,
release the mouse button. You can then proceed with the
desired Edit menu command.

Figure 112. Selecting Rows of Ladder Logic.

For more details see the commands Cut, Copy, Paste, and
Delete Selected Rows, below.
Cut
The Cut command lets you remove rungs of ladder logic from
the ladder diagram — often to be placed in some other
position using the Paste command.
Use your mouse to select the rungs that you want to cut.
When the rungs that you want to remove are selected, choose
Cut to remove them.
6 Shortcut: Select the rungs that you want to remove and press CTRL+X.
Copy
The Copy command lets you make a copy of rungs of ladder
logic that can be inserted into another position in the ladder
diagram using the Paste Command.
Use your mouse to select the rungs that you want to copy.
When the rows that you want to copy are selected, choose
Copy to place a copy of the selected rungs into an internal
buffer that you can later paste elsewhere.
6 Shortcut: Select the rungs that you want to copy and press CTRL+C.

Paste
The Paste command is used in conjunction with the Cut and
Copy commands. Use Paste in one of the two ways described
below.
To insert the selection made by Cut or Copy, place the
selection cursor anywhere on the first row of a rung before
which you want to insert the cut or copied selection. Choose
Paste to insert the selection.
To replace a range of rungs, select the rungs that you want to
replace. Choose Paste to replace the currently selected rungs
with the rungs previously cut or copied.
6 Shortcut: Select the rungs you want to replace and press CTRL+V.
Clear Element
Use the Clear Element command to remove the ladder
element currently selected. When you clear an element, the
previously occupied cells become blank.
6 Shortcut: Select the element you want to clear and press CTRL+L.
Delete Column
Use the Delete Column command to delete an entire column
of elements for a single rung. The column deleted is the
column at the current selection cursor position.
6 Shortcut: Position the selection cursor on the column you want to delete
and press DEL.
After deleting a column, the remaining elements to the right
are shifted left one column. If the rung contained a coil
instruction in column 10, there will be a blank cell in column
9. Move the cursor to the blank cell and use the Short Circuit
command to reconnect the coil to the remaining logic.
Delete Row
Use the Delete Row command to delete the row at the current
position of the selection cursor.
6 Shortcut: Position the selection cursor on the column you want to delete
and press CTRL+O.
Delete Selected Rows
Select a range of rows that you want to delete. Choose Delete
Selected Rows from the Edit menu to delete the rows. Use the

Cut command if you want to paste the rows elsewhere in the

ladder diagram.
6 Shortcut: Select a range of rows that you want to delete and press DEL.
Delete Element
Use the Delete Element command to remove the element at
the current cursor position.
6 Shortcut: Position the selection cursor on the element that you want to
delete and press CTRL+N.
After deleting an element the remaining elements to the right
are shifted left one column. If the row contained a coil
instruction in column 10, there will be a blank cell in column
9. Move the cursor to the blank cell and use the Short Circuit
command to reconnect the coil to the remaining logic.
Insert Empty Row
Use the Insert Empty Row command to insert rows between
existing rungs or to extend the left-hand power rail at the end
of the ladder diagram. When the selection cursor is on an
existing row of the ladder diagram, the current row is moved
down one and a new empty row is inserted above it.
6 Shortcut: Position the selection cursor on the row above which you want
to insert the empty row and press CTRL+W.
Insert Empty Column
Use the Insert Empty Column command to shift existing
columns of a rung to the right so that you can insert new
elements into the new position.
There must be an empty column to the right of the current
column in the rung. If there is not, you should first move the
cursor to a column to the right that has only horizontal short
circuits. From this new position use the Delete Column
command to create an empty column. Place the cursor back to
the original position and perform the Insert Empty Column
command.
6 Shortcut: Position the selection cursor in the column that you want to
move right and press INS.
Select All
Use the Select All command to select all of the rows in the
open ladder logic function block.

Edit Element
Use this command to open a dialog box where you can define
the fields of the selected ladder element. Details for each
ladder element are individually described later in this section.
6 Shortcut: Select the element you want to edit and press ENTER.
Edit Cell Comment
Use the Edit Cell Comment command to make a custom entry
for the cell comment of the selected ladder element. This
command is dimmed, or disabled, unless the option Show
Comments is selected.
Normally you do not need to edit cell comments because they
are automatically linked to the description fields for all I/O,
shared and system variables. Using the Edit Cell Command
does not change these descriptions, it only modifies the
comment for the current cell.
This command should be used if you want to enter a cell
comment for an element using a local variable. Choosing Edit
Cell Comment opens a dialog box as shown in Figure 113.
Figure 113. Editing a Cell Comment.

To create a custom cell comment select User Supplied, enter
the desired cell comment, and choose OK. If the variable type
is an I/O, shared or system variable, you can choose Use
Default to link the cell comment back to the variable’s
description (if you had previously created a custom cell
comment).
Entering a cell comment for a local variable once does not
automatically create cell comments for other elements where
that variable is used. The cell comment must be edited
individually where each element is used.

Short Circuit
Use this command to place a horizontal short at the current
position in the ladder diagram.
6 Shortcut: Press CTRL+S.
Vertical Connection
Use this command to draw a vertical connection below and to
the left of the current position in the ladder diagram (the
position of the inverted triangle in the selection cursor).
(This is not how to draw the left-hand power rail. Use the
Insert Empty Row command to insert rows and extend the
power rail.)
6 Shortcut: Press F5.
Repeat Last Element
Use this command to speed up the drawing of ladder diagrams
when you need to draw several ladder elements of the same
type. This command repeats the last element selection at the
current cursor position.
For example, to draw three normally open contacts in series,
draw the first contact by selecting from the menu, then move
the cursor right one column and press F7, move the cursor
right again, and press F7 once more.
Relay Menu
The Ladder Logic Editor’s Relay menu gives you access to the
following ladder logic elements. After creating a relay element
in a ladder logic diagram, choose the Edit Element command
(or press ENTER) to open a dialog box like the one shown in
Figure 114 for the Normally Open Contact. Enter the name of
the variable to be used for the element and choose OK to
complete the entry.

Figure 114. Relay Element (Normally Open Contact) Dialog

Box.
Normally Open Contact
The Normally Open Contact, sometimes referred to as
“examine on,” is used to examine the status of a digital value
(on or off). When executed by the Regent, power flow will be
true if the named variable’s status is on. There will be no
power flow if the named variable’s status is off.
When you define a Normally Open Contact, specify the name

of a digital input, digital output, shared control relay, system
control relay, or control relay variable.
Normally Closed Contact
The Normally Closed Contact, sometimes referred to as
“examine off,” is used to examine the status of a digital value
(on or off). When executed by the Regent, power flow will be
true if the named variable’s status is off. There will be no
power flow if the named variable’s status is on.
When you define a Normally Closed Contact, specify the name

of a digital input, digital output, shared control relay, system
Up Transitional
The Up Transitional element, some times referred to as “low-
high transitional,” is used to detect a transition from off to on
of a digital value. When executed by the Regent, power flow
will be true for the scan when the named variable’s value has
changed from off to on. There will be no power flow if the
named variable’s value remains off or on or transitions from
on to off.

When you define an Up Transitional, specify the name of a

digital input, digital output, shared control relay, system
Down Transitional
The Down Transitional element, sometimes referred to as
“high-low transitional,” is used to detect a transition from on
to off of a digital value. When executed by the Regent, power
flow will be true for the scan when the named variable’s value
has changed from on to off. There will be no power flow if the
named variable’s value remains off or on or transitions from
off to on.
When you define a Down Transitional, specify the name of a

digital input, digital output, shared control relay, system
Mux Output Contact
The Mux Output Contact element is used to detect the status
of the “flash” bit associated with a multiplexed (or “mux”)
output point. When executed by the Regent, power flow will
be if the named mux output variable’s flash bit is on.
For more information see page 212, Mux Output Coil or refer
to the product description for the multiplexed I/O module.
Inverter
The Inverter element is used to invert power flow. When
executed by the Regent, if power flow to the invert is false,
then it will be true after the invert; if power flow to the invert
is true, then it will be false after the invert.
The Inverter element does not require a name to be specified.
If there is no connection to the left side of the Invert, it

creates power flow to any element connected to the right side
of the Invert. This characteristic can be used to create a
“power rail” in the middle of the ladder diagram.

No Signal
The No Signal element tests for an out of range input signal.
Use it for analog inputs and temperature inputs only. For
details on out of range signal levels refer to the input module’s
product description.
When you define a No Signal element, enter the name of an

analog input or thermocouple input variable.
Low Alarm
The Low Alarm is true when the value of the named analog
variable is less than the low alarm limit. The low alarm limit
value is defined by a scaling entry in an analog scaling
function block. For more details see Using the Analog Scaling
Editor, Alarm Limit Values, on page 250.
When you define a Low Alarm element, enter the name of an

analog input or analog output variable.
Low Low
The Low Low Alarm is true when the value of the named
analog variable is less than the low low alarm limit. The low
low alarm limit value is defined by a scaling entry in an analog
scaling function block. For more details see Using the Analog
Scaling Editor, Alarm Limit Values, on page 250.
When you define a Low Low Alarm element, enter the name of
an analog input or analog output variable.
High Alarm
The High Alarm is true when the value of the named analog
variable is greater than the high alarm limit. The high alarm
limit value is defined by a scaling entry in an analog scaling
function block. For more details see Using the Analog Scaling
Editor, Alarm Limit Values, on page 250.
When you define a High Alarm element, enter the name of an

analog input or analog output variable.

High High
The High High Alarm is true when the value of the named
analog variable is greater than the high high alarm limit. The
high high alarm limit value is defined by a scaling entry in an
analog scaling function block. For more details see Using the
Analog Scaling Editor, Alarm Limit Values, on page 250.
When you define a High High Alarm element, enter the name
of an analog input or analog output variable.
Coil Menu
Coil elements always appear in column 10. If you define a coil
when the insertion point is not in column 10, a horizontal line
will appear connecting the insertion point to column 10. This
is a quick and useful way to define a horizontal rung. The
Ladder Logic Editor’s Coil menu gives you access to all of the
following ladder logic elements.
After creating a coil element in a ladder logic diagram,
position the selection cursor on the element and choose the
Edit Element command (or press ENTER) to open a dialog like
the one shown in Figure 115 for the Latch Coil. Enter the
name of the variable to be used for the coil element and
choose OK to complete the entry.
Figure 115. Coil Element (Latch Coil) Dialog Box.

Coil
The Coil element is used to control the value of a discrete
variable. When the rung's logic conditions are met, and power
flows to the coil, the named variable turns on. When there is
no power flow to the coil, the named variable turns off.

When you define a Coil, specify a name of a digital output,

shared control relay, system control relay, or control relay
variable.
You can also specify a digital input name to have an
application program control the value of a digital input point.
This can be useful for process simulation programs. When
you specify a digital input name for a Coil the compiler
produces a warning message.
Inverted Coil
The Inverted Coil is used to control the value of a discrete
variable. When power flows to the coil, the named variable is
turned off; when no power flows to the coil, named variable is
turned on.
When you define an Inverted Coil, specify a name of a, digital

output, shared control relay, system control relay, or control
relay variable.
You can also specify a digital input name to have an
application program control the value of a digital input point.
This can be useful for process simulation programs. When
you specify a digital input name for an Inverted Coil, the
compiler produces a warning message.
Latch Coil
The Latch Coil is used to set a discrete variable on. When
power flows to the Latch Coil, the named variable will be
turned on. When no power flows to the latch coil, the named
variable remains unchanged by this element.
When you define a Latch Coil, specify the name of a digital

relay variable. You cannot use a local control relay for a Latch
Coil.
For most applications, a Latch Coil should have a matching
Unlatch Coil, normally positioned in the ladder logic
somewhere after the Latch Coil. The compiler will produce a

warning message if a corresponding Unlatch Coil is not found

in the same function block.
Unlatch Coil
The Unlatch Coil is used to set a discrete variable off. When
power flows to the Unlatch Coil, the named variable is turned
off. When no power flows to the Unlatch Coil, the named
variable remains unchanged by this element.
When you define an Unlatch Coil, specify the name of an

output variable.
When you define an Unlatch Coil, specify the name of a digital
relay variable. You cannot use a local control relay for an
Unlatch Coil.
For most applications, an Unlatch Coil should have a
matching Latch Coil, normally positioned in the ladder logic
somewhere before the Latch Coil. The compiler will produce a
warning message if a corresponding Latch Coil is not found in
the same function block.
Mux Output Coil
The Mux Output Coil is a special coil element to control the
“flash” bit for a mux output point. Each mux output point
has two bits associated with it, an on-off bit and a flash bit.
When you define a mux output point using the I/O
Configuration Editor you specify only one name for the point.
Ladder logic elements such as Coil, Inverted Coil, Latch Coil
and Unlatch Coil control the on-off bit for the mux output.
The table below describes the state of the mux output in

relationship to the on-off and flash bits.

Table 19. Mux Output Control States.

--( )-- --(M)--
On-Off Bit Flash Bit Mux Output State
Off Off Off Steady
On Off Flash Fast
Off On Flash Slow
On On On Steady
The table shows that when the flash bit is on the mux output
will flash or be on steady, depending on the state of the on-off
bit. When the flash bit is off, the mux output will be steady off
or with flash fast, depending on the state of the on-off bit .
Jump
The Jump element is used to skip execution of certain ladder
logic rungs. Every Jump element requires a corresponding
Label element that must be located in the function block
below the Jump element. Backward jumps are not allowed.
When power flows to a Jump element, the rungs between it

and the corresponding Label element are skipped without
solving the logic of their intermediate rungs; the states of the
coils in these intermediate rungs remain unchanged. When
there is no power flow to a Jump element, the rungs between
the Jump and Label elements execute normally.
When you define a Jump element, enter the name that
corresponds to the Label element to where you wish the
program execution to skip. The Jump and its corresponding
Label have the same name.
Label
The Label element is used to indicate the destination of a
Jump element. A Label element must be located below its
corresponding Jump element. Backward jumps are not
allowed. The Label element always has power flow through it.
Unlike other coil elements, the Label element must be placed

in column one, normally on a rung of its own or on the first
row of another logic rung.

When you define a Label element, enter the name that

corresponds to the Jump element. You can have multiple
Jump elements to the same Label element. The Jump and its
corresponding Label have the same name.
MCR
MCR stands for “master control relay.” Each MCR element
must be paired with an End MCR element, to start (MCR) and
end (End MCR) the MCR field. The set of rungs between the
MCR and End MCR elements is considered the MCR field.
When power flows to an MCR element, the ladder logic within

the MCR field is normally solved. When no power flows to an
MCR element, logic elements that control (turn on or off) bit
variables (digital input, digital output, shared control relay,
system control relay, or control relay variable) are disabled
and the controlled bit variables are turned off. However, logic
elements (such as timers, counters, math elements, etc.) that
control word type variables (analog input, thermocouple
input, analog output, shared word register, system word
register, or local word register) execute normally.
Important! Latch and Unlatch Coils are unaffected by MCR control. You
should not use Latch and Unlatch Coils in the MCR field if
want them to be affected by the MCR control. Use alternate
logic elements (such as Assign) to set and reset the bit
variables instead of using the Latch and Unlatch.
The MCR element is placed in column 10. The MCR element
does not require a name identification. The MCR element
must be positioned above the End MCR element.
End MCR
The End MCR element is only a marker to identify the end of
the MCR field and should be placed below the MCR element.
Power flow to the End MCR is not important, and normally
the End MCR is place on its own rung. If you use an MCR
without an End MCR, the MCR field is automatically set to
the end of the function block.
The End MCR element does not require a name identification.

Logic Menu
The Ladder Logic Editor’s Logic menu gives you access to the
following ladder logic elements. These logic elements can be
placed anywhere in the ladder logic rung except column ten.
Some of the elements are wider than one column so they must
be placed so that they do not extend into column ten.
When you use the logic menu’s manipulation elements, define
A and B according to the following guidelines:
1. In AND, OR, and XOR elements, A and B are integer

constants between -32,768 and +32,767, inclusive, or a
register or analog I/O point; Result is a register or an
analog I/O point.
2. In Shift Left, Shift Right, Rotate Left, and Rotate Right

elements, A is an integer constant between -32,768 and
+32,767, inclusive, or a register or analog I/O point; B
is a register or integer constant between one and 16,
inclusive; and Result is a register or analog I/O point.
AND, OR and XOR
The AND, OR, and XOR (exclusive-OR) elements perform logic

operations on two variables to produce a Result. These
elements can be used for bit-type variables (digital input,
digital output, shared control relay, system control relay, or
control relay) or word-type variables (digital input word,
digital output word, analog input, thermocouple input, analog
output, shared word register, system word register, or local
word register). When word-type variables are used, the logic
AND, OR, and XOR operation is performed on all sixteen bits of
data stored in the words. You may also use integer constants
for A and B (1 or 0 for bit-type, or -32,768 and +32,767 for
word-type operations). The logic operation for AND, OR and
XOR are illustrated in Table 20.

Table 20. AND, OR and XOR Truth Table.

AND OR XOR
Value A Value B Result Result Result
0 0 0 0 0
0 1 0 1 1
1 0 0 1 1
1 1 1 1 0
When there is power flow to the element the logic operation is

performed and sets the value for the result. The power flow
out of the element will be off when the result is zero and will
be on if the result is non-zero. When there is no power flow to
the element the logic operation is not performed, the result
remains unchanged by this element, and there will no be
power flow out of the element.
Edit the element to enter the names of the variables or
constants for A, B, and Result in a dialog like the one shown
in Figure 116 for the And Element.
Figure 116. The AND Element Dialog Box.

Timer
The Timer performs timing functions within the ladder logic
function block. It times logic events and performs actions
based on the power flow to the timer input legs and the timer
value. Timers time logic events in time bases ranging from
0.01 seconds to hours.

Timer elements use two rows and can be placed anywhere

except in column 10.
Each Timer has two input legs on the left and two output legs
on the right. The upper input leg is the time leg; the lower
input leg is the enable leg. The upper output leg is the timed-
out leg; the lower output leg is the not-timed-out leg.
When power flows to the enable leg, the Timer is enabled.
While the timer is enabled, if power flows to the time leg, the
Timer accumulates time and is retentive as long as the timer
remains enabled. When the timer is not enabled or when the
accumulate is not equal to the preset, the timed-out leg is off
and the not-timed-out leg is on. When the accumulated time
reaches the specified preset value, the timed-out leg turns on
and the not-timed-out leg turns off. The output legs remain in
this state until the Timer is reset by removing power to the
enable leg.
After you define a Timer element, choose Edit Element to
define the Accumulate, Preset and Units of the timer as shown
in Figure 117.
Figure 117. The Timer Element Dialog Box.

Enter variable names or constants for,
• Accumulate. The timer accumulate should be the name of
a shared register or local register.
• Preset. The timer preset should either be an integer
between zero and 32,767, inclusive, or the name of a

shared register or local register. If you enter a variable

name, make sure that the variable has an initial value.
You can define an initial value for a shared register using
the Shared Variable Editor. To initialize a local register
you must use some type of logic element (like the Assign
element).
• Units. Select one of the following units of measurement
from the drop-down list: 0.01 S, 0.1 S, SEC, MIN, or HR.
If you specify units as HR, the maximum preset is 1,193.
Counter
The Counter performs counting functions within the ladder
logic function block. It counts logic events and performs
actions based on the counter value. Counters count logic
events with scale factors from x1 to x1,000.
Counter elements use two rows and can be placed anywhere

except in column 10.
Each Counter has two input legs and two output legs. The
upper input leg is the count leg; the lower input leg is the
enable leg. The upper output leg is the at-count leg; the lower
output leg is the not-at-count leg.
When power flows to the enable leg, the Counter is enabled.
While the counter is enabled, if power flow at the count leg
changes from off to on, the Counter accumulates one count.
The counter is retentive as long as the counter remains
enabled. When the counter is not enabled or when the
counter accumulate is not equal to the preset the at-count
output leg is off, and the not-at-count output leg is on. When
the accumulated count reaches the specified preset value, the
at-count output leg turns on and the not-at-count output leg
turns off. The output legs remain in this state until the
Counter is reset by removing power to the enable leg.
After you define a Counter element, choose Edit Element to
define the Accumulate, Preset and Scale of the Counter as
shown in Figure 118.

Figure 118. The Counter Element Dialog Box.

Enter the variable names or constants for,
• Accumulate. The counter accumulate should be the name
of a shared register or local register.
• Preset. The counter preset should either be an integer
between zero and 32,767, inclusive, or the name of a
shared register or local register. If you enter a variable
name, make sure that the variable has an initial value.
You can define an initial value for a shared register using
the Shared Variable Editor. To initialize a local register
you must use some type of logic element (like the Assign
element).
• Scale. Select one of the following counting scales: x1, x10,
x100, or x1,000. If you select a scale other than x1, the
accumulate will increment by one for each unit of the scale.
For example, with scale at x10, it will take 10 counts to
increment the accumulate by one. If the preset is five, it
will take 50 counts for the accumulate to reach the preset
(50 = 5 x 10).
Voter
The Voter element is used to vote triplicated digital inputs
configured for complete fault tolerance. This element
performs a two-out-of-three vote on three input variables and
stores the voted value in the result variable.

The voter contains additional fields for reporting errors when

one input is discrepant (not the same as the other two). A
time delay field (called Msec) is used to delay the error
reporting to filter normal input discrepancies during input
state changes. The error bit for a discrepant input is latched if
it remains in the wrong state for the configured time duration.
The error bit remains latched until the variable for reset is
turned on.
When there is power flow to the top right input leg of the
voter, the voter operation is performed. Power flow continues
out the top left output leg whenever there is power to the
input leg, allowing you to chain up to three voter instructions
together on the same rung.
After you define a Voter element, choose Edit Element to
define the variable names and values for the Voter as shown
in Figure 119.
Figure 119. The Voter Element Dialog Box.

Enter variable names and values for,
• Vote A, Vote B, and Vote C. Enter three input variable
names which must all be bit-type (digital input) or word-
type (digital input word) variables.
• Error A, Error B, and Error C. Enter three error bit
variable names which must be bit type (digital output,
shared control relay, control relay) variables.

• Result. Enter a name for the voted result which must be

either a bit-type (digital output, shared control relay,
control relay) or word-type (digital output word, shared
word register, system word register, or local word register)
variable, and must be of the same type (bit or word) as the
input variables.
• Msec. Enter a constant for the time delay preset (the time
base is in milliseconds). The default time delay preset is 0.
• Reset. Enter a name for the error reset bit which must be
a bit-type (digital input, digital output, shared control
relay, system control relay, control relay) variable. You
may want to use the name “VRESET,” which is the system
control relay that turns on after a voted reset.
Mid Value
The Mid Value element selects the middle value from three
analog inputs configured for complete fault tolerance.
The Mid Value element examines three input variable signals

and selects the middle value of the three. The selected value is
stored in the result variable
The Mid Value contains additional fields for reporting errors
when an input variable deviates from the mid value by more
than the configured limit. When such a deviation error
occurs, the error bit for the input is latched. The error bit
remains latched until the variable for reset is turned on.
After you define a Mid Value element, choose Edit Element to
define the variable names and values for the Mid Value as
shown in Figure 120.

Figure 120. The Mid Value Element Dialog Box.

Enter the variable names and values for:
• Value A, Value B, and Value C. Enter three input variable
names, normally analog inputs, temperature inputs or
shared variable registers (scaled analog input values).
• Error A, Error B, and Error C. Enter three error bit
variable names which must be bit-type (digital output,
shared control relay, control relay) variables.
• Result. Enter a name for the middle value selected result
which must be either shared register or local register.
• Limit. Enter an integer constant for the deviation limit
which must be between 0 and 4,095. The default deviation
limit is 4,095.
• Reset, Enter a name for the error reset bit which must be
a bit-type (digital input, digital output, shared control
relay, system control relay, control relay) variable. You
may want to use the name “VRESET,” which is the system
control relay that turns on after a voted reset.
Block Move
The Block Move command can be used to move the values of a
block of one or more variables to another block of one or more
variables. For the Block Move element you identify the first
variable name in the source block, the quantity of source
variables and the first variable name in the destination block.
Block move allows you to move variables from one type to
another, such as digital inputs to shared words.
Often block move is used in conjunction with the Voter

element for fault tolerant digital inputs. The voter produces
a voted result of the 16-point modules in a shared register and

block move is used to move the shared register to 16 shared

control relays, each representing one voted input point. Block
move is also commonly used to “pack” variables that need to
be read by external communications equipment (DCS, MMI,
host computers, etc.) Using block move allows you to
consolidate a variety of Regent variable types into a single
block of variables of one data type. Very often this reduces the
number of communication requests required to read the data
and subsequently increases the communications throughput.
After defining a Block Move element, choose Edit Element to
enter the variable names and values for the Block Move
element as shown in Figure 121.
Figure 121. The Block Move Element Dialog Box.

Enter the variable names and values for,
• Source. The name of the variable name in the source
block. Enter the name of any variable type except local
variables.
If the source variable type is an analog input or a
thermocouple input, the no-signal bits for these data types
are moved with the analog and temperature values. Since
the no-signal bit is normally on, this will often produce an
unexpected value in the destination register. You can use
other logic elements (like the Assign element) to
individually move analog input and thermocouple input
variables and filter out the no-signal bits.
• Count. Must be a constant. Count is expressed in
increments of the source variable type. For example if you
want to move 32 digital input points to two shared
registers count would be 32.

• Destination. The name of the first variable in the

destination block. Enter the name of any variable type
except local variables. Entering an input variable type will
cause the compiler to generate a warning message.
ASCII Output
ASCII output lets you transmit messages through the
Regent's communications ports to an external device such as a
terminal or printer. These messages consist of blocks of
ASCII characters (ASCII text to be transmitted), embedded
variable names (which are used to embed current process
values in the message), and ASCII control characters (special
control characters for the terminal or printer). In addition,
you can add non-printing comments to the ASCII messages to
make documentation notes about the message.
ASCII output is useful for displaying process information,

recording alarms, printing daily reports, prompting operators,
and assisting maintenance personnel.
From the Ladder Logic Editor's Logic menu choose ASCII
Output (ALT,L,S).
About ASCII Output Messages
Each ASCII Output element has three legs: input, done, and
error. By connecting transition elements to the input leg and
coils to the output legs you can control the ASCII output
execution and monitor the message transmission status. An
example is shown in Figure 122.
Figure 122. Example Ladder Logic Rung for ASCII Output.

When power is present at the left input leg of an ASCII
Output element, the element's message is added to the
message queue for the ASCII port. The input signal is used

only to queue the message. The messages queue is a FIFO

queue — with the oldest messages being transmitted first. To
transmit a message only once when an event occurs, you
should power the input leg with a transition element.
Power flows out of the element through the top done leg when
the message has been successfully transmitted.
If an error occurs during transmission power will flow
through the bottom error leg (instead of the done leg).
Transmission errors can include messages being sent to ports
that are not configured for ASCII output, a permanent fault
on the comm module and voted resets during message
transmission. The done and reset legs retain their last state
until the message is queued again. Each time the message is
queued, done and error are reset to off.
Using the ASCII Output Dialog Box
Each ASCII Output element has a dialog box with three fields:
Message Name, Port Number, and Contents as shown in
Figure 123.
Figure 123. The ASCII Output Element Dialog Box.

• Message Name. A unique name identifying the message.
• Port Number. The communications port through which
the message will be transmitted. You can use ports two
through six for ASCII output. Use the Project Editor's
Serial Ports command to configure the communications
port as an ASCII port and choose the data format and baud
rate for the type of device it will be transmitting to.

The Contents of an ASCII output message consist of three

types of information: text, variable names, and numerical
ASCII control characters. Non-transmitting comments can
also be added to annotate the message. An example of a
configured ASCII output message is shown in Figure 124 to
illustrate the various type of message contents.
Figure 124. An Example of an ASCII Output Message.

• ASCII Text. Message text is enclosed in double quotes
(“ ”). Quotes must be paired (in other words there must be
beginning and ending quotes, or opening and closing
quotes). Quoted text cannot continue onto the next line.
In line one of the example shown in Figure 124, the text
enclosed in quotes (“**** Boiler 100 ****”) would be
transmitted to the output device.
• Variable Names. The value of a variable can be
transmitted by enclosing the variable's name in square
brackets. Brackets must be paired (beginning with an
open “[” and ending with a close “]”). Bracketed names
cannot continue onto the next line.
Variable values can be formatted by adding a comma after
the variable name and using one of the following
formatting options:
O Replaces non-zero values with the word “on,” and zero
values with the word “off.” This is often used for bit-
type variables.
R Right justify (adds blank spaces to the left of the value,
creating a six-character field).

L Left justify (adds blank spaces to the right of the value,

creating a six-character field).
N No justify (adds no blank spaces — only the numerals
for the value are transmitted (plus a “minus” sign for
negative values).
If no formatting command is specified, the format will
default to “N.”
In line 2 of the example shown in Figure 124, the contents
[PT102,R] represents an embedded variable. The value for
variable PT102 would be inserted into the position of the
message and be right justified, in a six-character wide
space with leading spaces. Note that the name is not
embedded in text surrounded by double quotes. Each
group of text preceding and following the embedded
variable are individually surrounded by double quotes.
Also note that to have the variable name appear in the
message, it was entered in as part of the ASCII message
text.
• ASCII Control Characters. ASCII control characters
provide instructions for the receiving device. These codes
contain instructions such as carriage returns, line feeds,
form feeds, clear screen, color, and so on. They are useful
in formatting how your messages appear on the receiving
device.
Important! You must use ASCII control characters to send line feed and
carriage returns to devices like printers. Each line of the
ASCII output contents does not automatically generate a
line feed or carriage return. This allows you to print
messages that have longer character lengths than the
single lines of the ASCII dialog box. Add control
characters to the end of each line where needed (or on a
separate line following).
ASCII control character values are decimal integers and
must be between 0 and 255 (inclusive). Refer to the
documentation for the printer or monitor for specific
control characters details. Control codes should be
separated by a space (the space character is not
transmitted). Control characters cannot continue onto the
next line.

In each of the three lines of the example in Figure 124 the

ASCII character codes “13 10” are entered to transmit a
carriage return (ASCII Code 13) and a line feed (ASCII
Code 10).
• Comments. Everything after a semicolon (;) is considered
a comment. Comments can be placed on either a separate
line or at the end of a line containing text, variables or
control codes. Blank lines and comments are not
transmitted and do not affect the message. Comments
cannot continue onto the next line (the comment text on
the next line must begin with a new semicolon).
In line 1 of the example in Figure 124, the portion
appearing as “; mark message for boiler 100” represents a
comment and would not be transmitted with the message.
(Comments are excluded by the compiler and do not appear
in the compiled object that is loaded and run in the
Regent.)
For the example shown in Figure 124, the message sent to
a printer would appear as shown in Figure 125.
Previous Message
**** Boiler 100 ****
High Inlet Pressure, PT102 750 psi
Next Message
Figure 125. Appearance of an ASCII Output Message.

Shift Left and Shift Right
Shift Left and Shift Right elements manipulate the value of
word-type variable, A, by shifting the bits in the word to the
left or right by a number of bits, B. After shifting the value is
stored in the result variable.
When power flows to the right side of the shift element the
shift operation is performed.
In a Shift Left, all sixteen bits of the variable A are moved by
the amount of variable B to the left towards the most

significant bit (MSB). Bits shifted past the MSB are lost, and
zeroes are shifted into the least significant bit (LSB). If the
value of B is negative, the direction of the shift is reversed.
After the shift, if the MSB (bit 15) is equal to one, power
appears at the output leg of the shift element.
In a Shift Right, all sixteen bits of the variable A are moved by
the amount of variable B to the right towards the LSB. Bits
shifted past the LSB are lost, and zeros are shifted into the
MSB. If the value of B is negative, the direction of the shift is
reversed. After the shift, if the LSB (bit 0) is equal to one,
power appears at the output leg of the shift element.
After you have created a shift element choose Edit Element to
enter the variable names and values as shown in Figure 126.
Figure 126. The Shift Left Element Dialog Box.

In the dialog box, enter a word-type variable (digital input
word, digital output word, analog input, thermocouple input,
shared word register, system word register, or local word
register) or an integer constant for A and B. Enter the name
of a word-type variable for Result which should typically be a
shared word register or local word register variable.
Rotate Left and Rotate Right
Rotate Left and Rotate Right elements manipulate the value
of word-type variable, A, by rotating the bits in the word to
the left or right by a number of bits, B. After the rotation, the
value is in stored in the result variable.

When power flows to the right input leg of the rotate element
the rotate operation is performed.
In a Rotate Left, all sixteen bits of the variable A are moved by
the amount of variable B to the left towards the MSB (bit 15),
and bits moved past the MSB are moved into the LSB (bit 0).
If the value of B is negative, the direction of the rotate is
reversed. After the rotation, if the MSB is equal to one, power
appears at the output leg of the rotate element.
In a Rotate Right, all sixteen bits of the variable A are moved
by the amount of variable B to the right towards the LSB (bit
0), and bits moved past the LSB are moved into the MSB (bit
15). If the value of B is negative, the direction of the rotate is
reversed. After the rotation, if the LSB is equal to one, power
appears at the output leg of the rotate element.
After you have created a rotate element, choose Edit Element
to enter the variable names and values as shown in Figure
127.
Figure 127. The Rotate Right Element Dialog Box.

In the dialog box, enter a word-type variable (digital input
word, digital output word, analog input, thermocouple input,
analog output, shared word register, system word register, or
local word register) or an integer constant for A and B. Enter
the name of a word-type variable for Result which should
typically be a shared word register or local word register.

Math Menu
The Ladder Logic Editor’s Math menu gives you access to an
assign element, four integer math elements, six comparison
elements and two BCD data conversion elements. All of the
math elements are box instructions that occupy multiple
columns in one row. The elements can be placed in any
column as long as they do not extend into column ten. Each
of these elements is described below.
Assign
Assign moves data from one variable to another (source to
destination). When power flows to the input side of the
Assign element, the value of the source variable is stored in
the destination variable, and power flow appears at the
output.
After creating an Assign instruction, enter the values or

variable names in the fields shown in Figure 128.
Figure 128. The Assign Element Dialog Box.

In an Assign element dialog box, enter an integer constant
between -32,768 and +32,767, inclusive, or any bit or word-
type variable name for Source. Enter any bit or word type
variable name for Destination. If you enter an input name for
Destination, the compiler will generate a warning message.
Add
When power flows to the Add element, the values of variables
A and B are added and the sum is stored in the Result
variable. If the value of result is less than -32,768 or greater
than +32,767, an overflow condition occurs. When overflow

occurs, the result variable remains at its last calculated value

and power flow appears at the element output leg.
After creating an Add element enter the values or variable

names in the fields shown in Figure 129.
Figure 129. The Add Element Dialog Box.

In an Add element dialog box, enter an integer constant
type variable name for A and B. Enter any bit or word type
variable name for Result. If you enter an input name for
Result the compiler will generate a warning message. If you
enter a bit-type variable name for Result, it will be on if the
sum is non-zero and will be off if the sum is zero.
Subtract
When power flows to the Subtract element, the value of
variable B is subtracted from the variable A and the difference
is stored in the result variable. If the value of Result is less
than -32,768 or greater than +32,767, an overflow condition
occurs. When overflow occurs, the result variable remains at
its last calculated value and power flow appears at the element
output leg.
After creating a Subtract element enter the values or variable

names for the fields shown in Figure 130.

Figure 130. The Subtract Element Dialog Box.

In a Subtract element dialog box, enter an integer constant
variable name for Result. If you enter an input name for
Result the compiler will generate a warning message. If you
enter a bit-type variable name for Result, it will be on if the
difference is non-zero and will be off if the difference is zero.
Multiply
When power flows to the Multiply element, A and B are mul-
tiplied and the product is stored in variables Result (HI) and
Result (LO). As long as the product is between -32,767 and
+32,767, inclusive, Result (HI) is zero and the value is entirely
contained in Result (LO). If the product is a larger positive or
negative number, then portions of the Result are stored in
each of the result variables.
When the product is outside the range: -32,767 to +32,767,

inclusive, then Result (HI) is the signed integer portion of the
product divided by 32,768. Result (LO) is the remainder of the
product divided by 32,768 with the sign of the product repli-
cated in its value (that is, a negative result will produce a
negative value for Result (LO).
As shown in Table 21, the multiply instruction will produce an
overflow condition when A and B are both equal to -32,768.
When overflow occurs, the Result field variables remain at
their last calculated values and power flow appears at the
element output leg.

Table 21. Multiply Examples.

Output
Leg
A B Product Result (HI) Result Power
(LO)
-32,767 -32,767 +1,073,676,389 +32,766 +1 OFF
-32,767 +32,767 -1,073,676,389 -32,766 -1 OFF
+32,767 -32,768 -1,073,709,056 -32,767 0 OFF
-32,768 -32,768 +1,073,741,824 unchanged unchanged ON
-3 +10,923 -32,768 -1 -1 OFF
+2 +16,384 +32,768 +1 0 OFF
Results beyond the -32,767 and +32,767 range are difficult to

use in any subsequent ladder logic math elements. If you
need to multiply numbers that will create these large products
you should use floating point math function blocks.
After creating a Multiply element enter the values or variable
Figure 131. The Multiply Element Dialog Box.

In a Multiply element dialog box, enter an integer constant
variable name for Result (HI) and Result (LO). If you enter an
input name for a Result field the compiler will generate a
warning message. If you enter a bit-type variable name for a
Result field, it will be on if the result portion is non-zero and
will be off if it is zero.

Divide
When power flows to the Divide element, A is divided by B and
the result is stored in Quotient and Remainder. If the value of
B is zero, an overflow condition occurs. When overflow occurs
the values of Quotient and Remainder remain at their last
calculated values and power flow appears at the element
output leg.
After creating a Divide element enter the values or variable

Figure 132. The Divide Element Dialog Box.

In a Divide element dialog, enter an integer constant between
-32,768 and +32,767, inclusive, or any bit or word-type
variable name for A and B (B should not be zero). Enter any
bit or word type variable name for Quotient and Remainder.
If you enter an input name for a Result field the compiler will
generate a warning message. If you enter a bit-type variable
name for a Result field, it will be on if the result portion is
non-zero and will be off if it is zero.
Comparison Elements (EQ, NEQ, LT, LEQ, GT, GEQ)
Ladder logic contains the six comparison elements shown
above to compare the values of two variables. When power
flows to the element the comparison is performed. If the
result of the comparison is true, power flows at the output leg
of the element.

After creating a comparison element, choose Edit Element to

define the values or variable names for the comparison. An
example dialog is shown for the Equal To comparison in
Figure 133.
Figure 133. The Equal To Element Dialog Box.

In a comparison element dialog, enter an integer constant
type variable name for A and B.
BCD to Binary and Binary to BCD
These elements provide the numerical conversions necessary
to convert between binary coded decimal (BCD) values and
standard 16-bit binary (base 2) values.
The BCD format is often used to interface to thumbwheels

and various seven-segment display devices. The BCD variable
should range from 0 to 9,999 (in BCD format) where each
group of four bits in the 16-bit word represent numerals zero
through nine, as shown in Table 22.

Table 22. BCD Data Format.

BCD Data Pattern
Bit 3 Bit 2 Bit 1 Bit 0 Value

0 0 0 0 0
0 0 0 1 1
0 0 1 0 2
0 0 1 1 3
0 1 0 0 4
0 1 0 1 5
0 1 1 0 6
0 1 1 1 7
1 0 0 0 8
1 0 0 0 9
For example, consider the BCD value 0001 0010 0011 0100,
which represents 1,234. In a BCD to binary conversion, this
becomes the binary value for 1,234, or 0000 0100 1101 0010.
BCD to Binary elements convert the BCD bit pattern of the
Source variable to a standard binary bit pattern for the
destination variable. The source variable should range from 0
to 9,999 (in BCD format). When the source variable has an
invalid BCD bit pattern then an error condition occurs and
power flow appears at the element output. Also the
destination variable remains at the last calculated value.
Binary to BCD elements convert the standard 16-bit binary
(base 2) word pattern of the Source variable to BCD data
format for the destination variable. The source variable
should range from 0 to 9,999. When the value for source is
outside of this range an error condition occurs and power flow
appears at the element output. Also the destination variable
remains at the last calculated value.
After creating a BCD conversion element, choose Edit
Element to define the values or variable names for the
comparison. An example dialog is shown for the Binary to
BCD conversion in Figure 134.

Figure 134. The Binary to BCD Element Dialog Box.

In a BCD conversion element dialog, enter an integer constant
or word-type variable name for Source and any word-type
variable name for Destination.
Search Menu
Go to Rung
The Go to Rung command lets you quickly move to different
parts of a ladder logic function block.
From the Ladder Logic Monitor's Search menu choose Go to
Rung (ALT,S,G).
Line Number
Enter the line number that you want to go to.
Go
Choose Go to move to the line number that you entered in the
Line Number text box.
First
Go to the first rung of the function block.
Last
Go to the last rung of the function block.
Find Text
Searches for a text string. From the Ladder Logic Monitor's
Search menu choose Find Text (ALT,S,F).
Find What
Enter the text that you want to find.

Match
Choose an option button to find the text that you are
searching for anywhere in word, at the beginning of word, or
as a whole word.
Rung
Choose an option button to search for the text you specified in
all rungs or only in the current rung.
Direction
Choose an option button to indicate whether you want the
search to go up or down through the function block.
Options
Check these boxes if you want the search include comments
and description and be case sensitive.
Find Element
Searches for the next occurrence of the element you specify.
From the Ladder Logic Monitor's Search menu choose Find
Element (ALT,S,E).
Type
Use this drop-down list box to select what type of element you
want to find.
Direction
Choose an option button to indicate whether you want the
search to go up or down through the function block.
Find Next
The Find Next command searches for the next occurrence of
whatever element or character string was previously searched
for using the Find Text or Find Element commands.
From the Ladder Logic Monitor's Search menu choose Find
Next (ALT,S,N).

Options Menu
Prompt for Delete
Show Comments (Hide Comments)
The Show Comments command changes the display mode of
the ladder logic editor to show the rung comments and cell
comments. In this expanded display mode all of the normal
ladder logic editing capabilities remain normal.
You must select Show Comments in order to create a rung
comment. An example of the Ladder Logic Editor with
comments displayed is shown in Figure 135.
Figure 135. A Ladder Logic Function Block with Comments

Shown.
When you are finished viewing or editing the comments, the
Hide Comments command will return the Ladder Logic Editor
to the more standard view — with the comments hidden.

Window Menu
Help Menu
Documenting Your Ladder Logic Function

Blocks
The ladder Logic Editor lets you annotate your logic rungs by
entering rung comments. In order to enter rung comments
you must first use the Show Comments command from the
Options menu to expand the display of the ladder logic editor
to show the rung comment fields.
Entering Rung Comments

To enter a rung comment, position the cursor on the rung
comment field. When the cursor is correctly positioned on a
rung comment field the status bar displays “Rung Comment”
instead of the usual “Row m, Column n” position information.
Choose Edit Rung Comment [ALT,E,E] from the Edit menu to
open the Edit Rung Comment dialog box shown in Figure 136.
6 Shortcut: When the cursor is on a rung comment field press ENTER.

Figure 136. Editing a Rung Comment.

In the Edit Rung Comment dialog box, enter a rung comment
up to seven lines and 70 characters per line. When you have
finished entering a rung comment choose OK to close the
dialog box.
Cell Comments
In addition to rung comments each cell of the ladder diagram
has a cell comment. For I/O, shared, and system variables,
cell comments are automatically linked to the descriptions of
the variable name used in the cell. Local variables do not have
descriptions, so their cell comments are normally blank. You
can use the Edit Cell Comment command to enter a cell
comment where a local variable is used. For more details on
this command see page 205, Edit Cell Comment.
Ladder Logic Constraints and Limitations

The constraints and limitations for creating ladder logic
diagrams are shown in Table 23.

Table 23. Ladder Logic Constraints and Limitations.

Rung Size 10 columns by 8 rows
(maximum)
Rungs Per Function Block 3,600
Rung Comments 7 Lines, 70 Characters
each
Cell Comments 40 Characters each
Compiled Function Block
Size 64K bytes maximum
Using the Analog Scaling Editor

Analog scaling function blocks scale raw analog units from
analog inputs to engineering units (which can be used by the
Regent when running your programs) and scale engineering
units to analog units. Scaling engineering units to analog
units is also known as unscaling. In the Regent analog units
range from zero to 4,095.
Analog scaling function blocks let you define a list of scaling
entries, each one specifying the parameters for an individual
scaling operation. Up to 600 scaling entries can be
programmed in a single function block. The scaling function
block has optional timing parameters that let you configure
the timing interval to perform the list of scaling operations.
When you configure a scaling entry, you define a source
variable, destination variable, a high and low engineering
value, select scaling or unscaling, select linear or square root
conversion and configure optional alarm limits and alarm
variable names.
Scaling Analog Values to Engineering Values

Analog Input values in the Regent range from 0 to 4,095.
Most often you will want to convert this raw analog unit range
to a more useful engineering unit range. The scaling
algorithm in the Regent makes this easy.
The following equation represents the algorithm the Regent
uses to scale analog inputs:
Engineering value = (analog value / 4,095)N x (high - low) + low

where,
N = 1 for linear scaling conversion
N = 0.5 for square root conversion
A graphical representation of this equation is shown in Figure
137.
Figure 137. Scaling Analog Inputs to Engineering Units.

Since the result of the scaling equation is a word register, the
scaling results are 16-bit signed integer values (-32,768 to
+32,767). No fractions are used.
For example, where:
Low = 0
High = 100
The engineering value will be an integer from zero to 100. An
analog input of 2,031 would ideally yield a calculated result of
49.58. Because the result is stored as an integer, the
engineering value is truncated to 49.
The integer span between low and high values dictates the
resolution of the scaling calculation. The analog input has a
range from zero to 4,095 (one part in 4,096) due to its 12-bit

analog-to-digital converter. Scaling to engineering units with

an integer span of less than 4,095 decreases the resolution of
the engineering result. Scaling to engineering units with an
integer range greater than 4,095 does not increase the
resolution — but it does maintain it.
When considering analog input value resolution, it is often the
transmitter — not the analog input module — that dictates
the maximum resolution. A range of zero to 4,095 provides
0.025% resolution. Often transmitters may have only 0.1 to
0.5% resolution, representing only one part in 1,000 to one
part in 200. Scaling to ranges greater than the accuracy of the
transmitter or the analog input module will not increase the
resolution of the engineering result.
Analog scaling function blocks for analog inputs should be
defined at or near the beginning of your application program
— allowing other function blocks to reference the scaled
results.
Scaling Engineering Values to Analog Outputs

(Unscaling)
Analog outputs in the Regent range from 0 to 4,095. If you
program algorithms in the Regent to control an analog output
your calculations may be based on some other engineering
unit range. If this is true you can use the unscale algorithm of
the scaling function block to convert your engineering value to
analog units.
The following equation represents the algorithm the Regent
uses to unscale analog outputs:
Analog output = [(engineering value - low) / (high - low)]N x 4,095
where,
N = 1 for linear scaling conversion
N = 2 for square root conversion
A graphical representation of this equation is shown in Figure
138.

Figure 138. Scaling Engineering Units to Analog Outputs.

Frequently, we think of analog output signals in percentage
terms. For example, to provide a 50% analog output signal to
an actuator, a value of 2,048 should be sent to the analog
output module. Thinking in terms of zero to 100 percent is
often easier than thinking in terms of zero to 4,095.
When you write control equations for analog outputs you
should use a more easily recognizable number range — such
as zero to 100 percent, and then unscale to the analog output.
However, zero to 100 provides only one part in 100 resolution
using integer values. Since analog outputs use 12-bit digital-
to-analog converters, an optimal resolution of 0 to 4,095 is
best maintained by choosing a number range of at least 4,096.
If a number range of zero to 10,000 is used, your calculations
will provide both good resolution and a convenient numbering
system.
For example, if:
0 = 0%
10,000 = 100%
then,

8750 = 87.50%
If you think of the zero to 10,000 range as zero to 100 plus two
decimal places, the values are more easily recognized. You can
write a function block to calculate an output between zero and
10,000 and then write an analog scaling function block to
unscale the engineering value from zero to 10,000 to zero to
4,095.
Analog scaling function blocks for analog outputs should be
defined at the very end of your application program. By
making this the last function in your program, the
engineering values it calculates will be unscaled and sent to
the analog outputs without any scan cycle delays.
Register-to-Register Scaling
Shared or local registers are often be used to store analog unit
results that may need to be scaled or unscaled. Register-to-
register scaling lets you scale or unscale these results easily.
Here are a couple examples of when you might want to use
register-to-register scaling.
• When the mid value select of three analog inputs yields an
analog unit result stored in a register. You would want to
use scaling to convert this value to engineering units.
• Many continuous control loop fields operate on analog
units. For instance, to provide a remote setpoint to a
continuous control loop, the value must be between zero
and 4,095. If the setpoint is in engineering units in a
register you can use unscaling to convert it to raw analog
units in another register for use in the continuous control
loop.
Analog Scaling Editor Commands

After you have created a new scaling function block using the
Program Editor, the Analog Scaling Editor window is opened
as shown in Figure 139.

Figure 139. The Analog Scaling Editor Window.
Edit Menu
Using the commands from the Edit menu you can add, edit,
insert and delete scaling entries and define the timing
parameters.
Add Entry and Insert Entry
Choose Add Entry to create a new scaling entry at the end of
the list of existing entries. Choose Insert Entry to insert a
new scaling entry at the current cursor position. The scaling
entries are executed in the order that they appear in the
Analog Scaling Editor window. Normally the order of the
scaling entries is not important because they represent
independent scaling operations and do not interact with each
other.
After choosing Add or Insert Entry a dialog box will open
where you can define the parameters for the scaling entry.
The Add Entry dialog is shown in Figure 140.

Figure 140. Analog Scaling: Add Entry Dialog Box.

Follow the guidelines below to complete the scaling entry.
Source
Enter a variable name for the source variable to be scaled or
unscaled. For example enter an analog input name that you
want to scale, or enter a register name that you want to
unscale to an analog output. Source can be any word-type
variable.
Destination
Enter a variable name for the destination variable which is
the result of the scale or unscale conversion. For example if
you are scaling an analog input, the destination should be a
shared or local register. If you are unscaling to an analog
output, destination should be the name of the analog output
variable. Destination can be any word-type variable.
Low and High Value
Enter integer constants for Low Value and High Value which
represent the engineering unit range of the conversion. The
low value must always be less than the high value. Integer
constants are numeric values between -32,768 to +32,767,
inclusive.

Operation
Choose the scaling operation — either scale or unscale.
Conversion
Choose between linear or square root extraction for the
scaling conversion. Square root extraction is most often
required for differential pressure transmitters measuring flow.
Normally all unscale operations should be linear conversions
Alarm Limit Values
The built-in alarm limits for scaling operations can be used to
set alarms when the source variable exceeds configured values.
Alarm limit values are always expressed in engineering units,
regardless of the scale or unscale operation. This makes it
easier for you to define the alarm values you need.
The alarm limits are optional, you are not required to use
them. Enter integer constants for the high-high, high, low
and low-low alarm limits. The values should be in the
numeric range between the values you enter for the low and
high engineering unit values. They also must be in
descending order where,
High Engineering Value > High-High > High > Low > Low-Low > Low
Enineering Value
If you do not need to use all four of the alarm levels, you
should still enter values for each of them. For example, if you
only need a high alarm, set high-high equal to the high
engineering value and set low and low-low to the low
engineering value.
The alarm values you configure here are used internally in the
Regent for the ladder logic alarm contacts.
Alarm Limit Variable Names
If you have entered values for the Alarm Limits, you can then
enter names of bit-type variables for each of the alarms. By
entering a variable name, you can use the name in other
function blocks like ladder logic to monitor the status of the
alarms. Normally you will enter a shared control relay or
local control relay name.
After you have completed your scaling entry configuration,
choose OK to close the dialog and return to the Analog Scaling
Editor.

Edit Entry
Use the Edit Entry command to edit and modify the
configuration for a specific scaling entry.
Insert Entry
Using Insert Entry command is just like the Add Entry
command, except the new entry is inserted ahead of the
currently selected entry (The Add Entry command adds the
new entry to the end of the scaling list of entries).
Delete Entry
Use the Delete Entry command to delete a scaling entry from
the list. Select the entry you wish to delete and choose Delete
Entry from the Edit menu.
Timing Parameters
Use the Timing Parameters command to define optional
timing execution parameters for the scaling function block.
The timing parameters you define apply to all of the scaling
entries, not individual entries. If you do not specify timing
parameters, the scaling operations will be performed every
scan of the program when it is loaded and running in the
Regent.
When you select the Timing Parameters command from the
Edit menu the following dialog box is opened:
Figure 141. Scaling Timing Parameters.

You can see that the default timing parameters have the units
of scans and an interval of 1, which causes the scaling
function block to be solved every scan of the program. By
entering other values for Interval and selecting Units of
Scans, 0.01 seconds, 0.1 seconds, seconds, minutes or hours

you set the elapsed time between execution of the scaling

entries.
The fields Enable and Reset can be used to further control the
execution of the scaling function block based upon the status
of digital I/O or other bit-type variables.
If you enter a name for Enable, the named variable must be
on for the scaling function block to execute. While Enable is
on, the function block will be executed as part of the program
at the interval specified by Interval and Units.
If you enter a name for Reset, then the scaling execution is
not executed regardless of the status of Enable, and any
accumulated time since the last execution is reset to zero.
When Reset is turned off, the scaling execution resumes
normal operation determined by the status of Enable.
Search Menu
Go to Entry
The Go to Entry command lets you quickly move to different
entries in the analog scaling entries list. From the Analog
Scaling Editor's Search menu choose Go to Entry (ALT,S,G).
Entry Number
Enter the entry number that you want to go to.
Go
Choose Go to move to the entry number that you entered in
the Entry Number text box.
First
Go to the first scaling entry in the list.
Last
Go to the last scaling entry in the list.
Find
The Find command can be used to locate variables in the
analog scaling entry list. From the Analog Scaling Editor's
Search menu choose Find (ALT,S,F).
Type in the source name of the scaling entry or character
string you want to search for. The Find What text box retains
the name of the last scaling entry or character string that was

searched for. Use the Find Next command button or press F3

to repeat the search.
Match
Lets you to match character strings as they occur anywhere in
a word, only at the beginning of a word, or as a whole word.
Direction
Determines whether the search will move upward or
downward from the current function block. The search will
stop when it reaches either the top or the bottom of the
scaling list.
Options
The Options check boxes let you decide whether to search for
the character string in the entries' comments and descriptions
and whether the search should be case-sensitive.
Find Next
The Find Next command searches for the next occurrence of
whatever name (or character string) was previously searched
for using the Find command.
From the Analog Scaling Editor's Search menu choose Find
Next (ALT,S,N).
Window Menu
Help Menu

Analog Scaling Sizes and Execution

Speeds
During execution, the Regent performs a scaling calculation
for each entry in the analog scaling function block. Each
entry is scaled or unscaled in sequential order from top to
bottom of the function block, based upon the timing
parameters.
Analog scaling function block sizes and execution speeds
depend on the number of entries, the operation (scale or
unscale) and the conversion (linear or square root) as shown
in Table 24.
Table 24. Analog Scaling Sizes and Execution Speeds.
Code Data Speed
Operation Conversion (bytes) (bytes) µ sec)
(µ
Overhead N/A 2 0 N/A
Scale Linear 26 0 27.3
Scale Square Root 44 0 121.0
Unscale Linear 30 0 43.0
Unscale Square Root 36 0 61.8
Analog Scaling Summary

Define an analog scaling function block for analog inputs at
the very beginning of the application program. By making it
the first function block in the program, all analog inputs will
be scaled to engineering units at the beginning of the program
scan, and all other function blocks can then reference the new
engineering result.
Define analog scaling function blocks to unscale analog
outputs at the end of the application program. By making it
the last function block in the program, the engineering value
calculated will be unscaled and sent to the analog output
without any scan cycle delays.
When unscaling engineering units to analog outputs, make
sure that calculations for the engineering value shared
variable register result in values where the low value is less
than or equal to engineering value and the engineering value
is less than or equal to the high value.

Points to remember:
1. Maximum 600 entries per function block.
2. Engineering results are stored as integers. No fractions
are used.


Section 5, Addendum 1: Working With Programs and Function Blocks
Dual Voter
The Dual Voter element is used to perform standard 1oo2 energized to

trip, 2oo2 energized to trip, 1oo2 de-energized to trip, and 2oo2 de-
energized to trip voting. This element performs a two-out-of-two vote on
two input variables, and stores the voted value in the result variable.
The dual voter contains additional fields for reporting fault status for the
input variables when the input variables are not equal. A configurable
Msec time field delays error reporting to filter normal input discrepancies
during input state changes.
The error bit for an input variable is latched if it remains in the wrong
state for the configured time duration. It remains latched until the variable
for reset is turned on.
When there is power flow to the top left input leg of the dual voter, the
voting operation is performed. Power flow continues out the top right
output leg whenever there is power to the input leg, allowing you to chain
together up to three voter instructions on the same rung.
After you define a Dual Voter element, choose Edit Element to define the
variable names and values for the Dual Voter, as shown in Figure 1.
Figure 1. The Dual Voter Element Dialog Box
R e g e n t User's Guide, Issue 4 (Addendum added August 14, 1996) 5a-1

Enter variable names and values for:
• Input A and Input B. Enter two input variable names, both of which
must be bit type (digital input, digital output, local control relay,
shared control relay, system control relay) or word type (digital input
word, digital output word, local word register, shared word register,
system word register).
• Fault A and Fault B. Enter two input line fault variables which must
be the same type as the Input A and Input B variables.
• Result. Enter a name for the voted result which must the same type as
the Input A and Input B variables. Valid bit types are digital output,
local control relay, and shared control relay. Valid word types are
digital output word, local word register, and shared word register.
• Msec. Enter a constant or word variable for the time delay preset (the
time base is in milliseconds). The default time delay preset is 0.
• Type. Select from a pulldown list the desired type of dual voting to be
performed. Tables 1 through 4 define the truth tables for each type of
dual voting available.
Table 1. Truth Table: 1oo2 Energized to Trip

1oo2 ENERGIZED TO TRIP
Input A Input B Input A Input B Fault A Fault B Error Result Result
Healthy Healthy 0 0 0 0 0 0 Healthy
Healthy Healthy 0 0 1 1 0 1 Tripped
Healthy Tripped 0 1 0 0 1 1 Tripped
Tripped Healthy 1 0 0 0 1 1 Tripped
Tripped Tripped 1 1 0 0 0 1 Tripped
5a-2 (Addendum added August 14, 1996) Industrial Control Services

Table 2. Truth Table: 2oo2 Energized to Trip

2oo2 ENERGIZED TO TRIP
Healthy Tripped 0 1 0 0 1 0 Healthy
Tripped Healthy 1 0 0 0 1 0 Healthy
Table 3. Truth Table: 1oo2 De-energized to Trip

1oo2 DE-ENERGIZED TO TRIP
R e g e n t User's Guide, Issue 4 (Addendum added August 14, 1996) 5a-3

Table 4. Truth Table for 2oo2 De-energized to Trip

2oo2 DE-ENERGIZED TO TRIP
• Error. Enter a name for this bit-type (digital output, local control
relay, shared control relay) variable that is generated when Input A
and Input B are not equal after the Msec preset is expired.
• Reset. Enter a name for this bit-type (local control relay, shared
control relay, system control relay) variable.
Availability
The Dual Voter is available in Winterpret /TRIOS versions 3.40 and later.
Safety Considerations
The Dual Voter is TÜV certified for use in safety related systems, but the restrictions for the use of
an energized to trip system applies. It is not recommended to use energized to trip logic in a de-
energized to trip system. For more details on the requirements for energized to trip applications
please see Section 8 of this user’s guide.
5a-4 (Addendum added August 14, 1996) Industrial Control Services

Section 6
Version Tracking
WINTERPRET provides many features that let you document
and track the changes you make to your system configuration
and application programs.
Every time you open an application program, make changes,
and save your changes, you create a new version.
WINTERPRET automatically tracks these versions by giving
them version numbers, and prompting you to enter descrip-
tions for your changes. Additional features in WINTERPRET
allow you to perform automated comparisons of versions to
identify exactly where changed have been made.
Table 25 lists all of WINTERPRET’S configuration and program-
ming functions, indicating which are under version control.
Table 25. Version Controlled Files.
Configuration Version Controlled?
Yes No
I/O Configuration n
Shared Variables Definitions n
Serial Ports n
Guarded Peer-Link n
Application Program n
Function Blocks n
User Lists (System, Project, n

Program)
User Classifications n
File Details (Project, Program n

or Function Block)
WINTERPRET’S version control and source comparison features

are designed to assist the user in managing the development
of, and modifications to, the system application programs and
configuration. These tools should be used in addition to other
general practices that the user employs for managing the
configuration of safety-critical systems.

Managing Your Versions

Whenever you edit and save a version controlled file a new
version is automatically created. Over time you will inevitably
have many versions of your files that you may no longer need
and want to delete. This is most easily performed using the
associated History command for the particular file that you
want to delete the version (or versions) of. In the History dia-
log boxes you will see each version of the file listed by version
number and the description that you entered when you saved
the version.
For I/O configuration and shared variables definitions you can
simply select the versions you no longer need and choose
Delete. For more details about the I/O Configuration History
and Shared Variables History commands, see Section 4, Work-
ing with Projects.
For application programs and function blocks, you should fol-
low the steps below:
1. Use the Get Program History command to delete the pro-
gram versions you no longer need.
2. Use the Unused Function Blocks command to delete func-
tion blocks that are not used by any version of the program
3. Use the Get Function Block History command to delete the
function block versions that are no longer used. These will
be the versions that are not marked as IN USE in the Get
History dialog box.
For more details about the Get Program History and Get
Function Block History commands, see Section 5, Working
with Programs and Function Blocks.
Using the Comparison Commands

WINTERPRET’S comparison commands provide an efficient and
automated method of identifying exactly where changes have
been made to I/O, shared variables, programs and function
blocks. These commands provide comparison outputs that list
the changes that make a “baseline” file equal to a
“comparison” file. Normally the baseline file is a lower ver-
sion number than the comparison file.

Version Tracking Section 6
Comparing Versions of Your I/O Configuration

The Project Editor’s Compare I/O Configuration command
compares versions of your I/O configuration, making it easy to
track changes to your I/O configuration by comparing it with
other versions.
From the Project Editor’s Tools menu choose Compare I/O
Configuration (ALT,T,I).
Figure 142. The Compare I/O Configurations Dialog Box.

From this dialog box you can compare versions of the project’s
I/O configuration.
The I/O configuration comparison always compares the mod-
ule types and positions, tag names, initial/final values, and
other point/module configuration parameters (for example,
comm protect). The I/O configuration version descriptions are
not included in the comparison. Results of the comparison
will be reported on a module by module basis.
In the Compare I/O Configurations dialog box, select the pro-
ject name and version numbers for baseline and comparison
and choose from the following options:
Include Descriptive Text in Comparison
Check this box if you want to include the description fields for
I/O points in the comparison.
Leave this box blank if you want to exclude the I/O point de-
scriptions from the comparison. Description fields are docu-

mentation fields only and do not represent operational con-

figuration information.
Display Difference Details
Check this box if you want to see a complete listing (including
tag names, descriptions, initial/final values, etc. for all of its
points) of every I/O module where a change has been made.
Leave this box blank if you only want to see a summary list of
the module positions (assembly number, slot number) where
changes have been made. No module configuration details
will be shown.
After selecting the desired comparison options choose
Compare to perform the comparison.
The I/O Configuration Comparison Output
After WINTERPRET performs the selected comparison, the re-
sults are displayed in the I/O Configuration Comparison
Output dialog box. The output reflects what changes to the
baseline would create the comparison on a module-by-module
basis. This means that if there is anything different within a
module (for example, a point name was changed, an initial
value was changed, etc.) the associated module is identified,
but not the specific details of the change within the module
(that is, the changed module would be identified but not the
point number whose name was changed).
The I/O Configuration Comparison Output will list,
• The project name and I/O configuration version number
selections for Baseline and Comparison
• Whether descriptive text was included in the comparison or
not.
• The result of the compare as “... are the same,” or “... are
different.”
The changes that will make the Baseline equal to the Com-
parison. The list of these changes is simple or detailed de-
pending on the Display Difference Details option.
These changes are typically,
• Inserted before (or after) baseline (assembly number, slot
number) comparison (assembly number, slot number).

• Replaced baseline (assembly number, slot number) with

comparison (assembly number, slot number).
• Deleted baseline (assembly number, slot number).
• Deleted comparison (assembly number, slot number).
In some cases, items in the comparison output are wider than
the dialog box can display. Use the Print button to get a hard
copy to see the entire contents in the comparison output.
If the I/O configurations have different number of I/O modules
you will often see in the difference listing that empty modules
at the end of the I/O configuration were deleted. This is a
normal function of the comparison.
From the comparison output dialog choose Print to print the
comparison output. Choose OK to return to the Compare I/O
Configurations dialog box.
Comparing Versions of Your Shared Variables

The Project Editor’s Compare Shared Variables command
compares versions of your shared variables, making it easy to
track changes to your shared variables definitions by compar-
ing them with other versions.
From the Project Editor’s Tools menu choose Compare Shared
Variables (ALT,T,S).
Figure 143. The Compare Shared Variable Definitions

Dialog Box.

shared variables.
The shared variable definitions comparison always includes
address numbers, tag names, initial/final values, and comm
protection configuration information. Since address numbers
are included in the comparison, if you insert a shared variable
all the variables after the insertion point will show up as
changed because their addresses are different. This is impor-
tant to identify as external communications equipment like
MMI and DCS devices will communicate to the Regent by ad-
dress numbers, not tag names.
The shared allocation sizes are not included in the compari-
son. However, if the word register amount is modified, all of
the floating point register addresses change.
The shared variable definition version description is not in-
cluded in the comparison. Results of the comparison are re-
ported on a point-by-point basis.
In the Compare Shared Variable Definitions dialog box, select
the project name and version numbers for baseline and com-
parison and choose from the following options:
Check this box if you want to include the description fields for
the shared variables in the comparison.
Leave this box blank if you want to exclude the shared vari-
able descriptions from the comparison. Description fields are
documentation fields only and do not represent operational
configuration information.
Check this box if you want each changed variable’s complete
definition listed (including tag name, description, initial/final
values, and comm protect). Each change listing for a variable
is listed by address number and followed by a complete defini-
tion of the point configuration.
Leave this box blank if you only want a summary list of
shared variable addresses where changes have been made. No
point configuration details are shown.

The Shared Variable Comparison Output

sults are displayed in the Shared Variable Comparison Output
dialog box. The output reflects what changes to the baseline
would create the comparison on a point-by-point basis. This
means that if there is anything different for a shared variable
point definition (for example, a point name was changed, an
initial value was changed, etc.) the shared variable is identi-
fied, not specifically the detail of change to the shared variable
(such as a change to an initial value).
The Shared Variable Comparison Output will list,
• The project’s name and shared variable definitions version
numbers for baseline and compare
not.
different.”
• The changes that will make the baseline equal to the com-
parison. The list of these changes is simple or detailed de-
These changes are grouped by shared variable type (control
relays, word registers, floating point registers) and are
typically,
• Inserted before (after) baseline address number compari-
son address number.
• Replaced baseline address number with comparison ad-
dress number.
• Deleted baseline address number.
• Deleted comparison address number.
copy to see the entire contents in the comparison output.
comparison output. Choose OK to return to the Compare
Shared Variable Definitions dialog.

Comparing Versions of Your Programs

The Project Editor’s Compare Programs command compares
versions of your programs, making it easy to track changes to
your programs by comparing them with other versions.
From the Project Editor’s Tools menu choose Compare
Programs (ALT,T,P).
Figure 144. The Compare Programs Dialog Box.

programs.
The program comparison always compares the function blocks
and their execution order and identifies the changes on a func-
tion block basis. The comparison does not include the func-
tion block details or descriptions.
In the Compare Programs dialog box, select the project name,
program name and program versions for baseline and com-
parison and choose from the following options:
Check this box if you want to include program details, the
program description and function block comment fields (for
example, ladder logic rung comments, cell comments, etc.) in
the program comparison.
Leave this box blank if you want to exclude the program de-
tails, program description and function block comment fields

from the program comparison. Note that floating point math

function blocks can have comments entered on lines after a
semicolon. These comments are not distinguishable from real
operation instructions so they are always compared.
Check this box if you want to see each function block that has
changed listed by function block name, version number,
function block type, and version description. The actual con-
tents of the function blocks will not be shown.
Leave this box blank if you only want to see the function block
changes referred to by function block number only.
The Program Comparison Output
sults are displayed in the Program Comparison Output dialog
box. The output reflects what changes to the baseline would
create the comparison on a function block by function block
basis. This means that if there is any difference in the func-
tion block contents, or function block execution order the as-
sociated function block will be identified. Specific contents of
the function block(s) that may make them different will not be
listed. Use the Compare Function Blocks command to identify
the specific programming changes for the function blocks re-
ported in the comparison output.
The Program Comparison Output will list,
• The project name, program name and version numbers for
baseline and comparison
not.
different.”
• The function block changes that will make the baseline
equal to the comparison. The list of the function blocks is
simple or detailed depending on the Display Difference
Details option.

• Inserted before (or after) baseline function block number

comparison function block number.
• Replaced baseline function block number with comparison
function block number.
• Deleted baseline function block number.
• Deleted comparison function block number.
copy if you need to see the entire contents of the comparison
output.
Programs dialog box.
Comparing Versions of Your Function Blocks

The Program Editor provides a Compare Function Blocks
command that helps you track changes to you function blocks
by comparing them with other versions.
From the Program Editor’s Tools menu choose Compare
Function Blocks (ALT,T,C).
Figure 145. The Compare Function Blocks Dialog Box.

From this dialog box you can compare versions of the pro-
gram’s function blocks.

In the Compare Function Blocks dialog box, select the project

name, program name, function block name and version num-
ber for baseline and comparison and choose from the following
options:
Check this box if you want to include the function block de-
tails, description and comment fields within the function block
(for example, ladder logic rung comments, cell comments, etc.)
in the comparison.
Leave this box blank if you want to exclude the function block
details, description and comment fields from the comparison.
Note that floating point math function blocks can have com-
ments entered on lines after a semicolon. These comments
are not distinguishable from real operation instructions so
they are always compared.
Check this box if you want to list the actual contents of each
item in the function block where changes have been made.
For example, comparison of a ladder logic function block
would show the actual ladder logic rungs that are different.
Leave this box blank if you only want a summary list of the
items in the function block that have changed. For example,
comparison of a ladder logic function block would only list the
rung numbers where changes were made, but not show the
actual ladder logic rungs.
The Function Block Source Comparison Output
sults are displayed in the Function Block Source Comparison
Output dialog box. The output reflects what changes to the
Baseline function block would create the Comparison function
block on an item by item basis. The “item” depends on the
type of function block compared. Item types are shown in
Table 26, Function Block and Item Types.

Table 26. Function Block and Item Types.

Function Block Type Item
Ladder logic Rung number.
Scaling Timing parameters, entry (line) number
Floating point math Error variables, line number
Sequence of events Control parameters, entry (line) number
Process historian Control parameters, entry (line) number
Continuous control PID loop number
The Function Block Source Comparison Output will list,

• The project name, program name, function block name
and version numbers for Baseline and Comparison.
• Whether descriptive text was included in the compari-
son or not.
• The result of the compare as “... are the same,” or “...
are different.”
• The changes that will make the baseline equal to the
comparison. The itemized list is simple or detailed de-
• Inserted before (or after) baseline “item” number(s)
…comparison “item” numbers(s).
• Replaced baseline “item” number(s) … with compari-
son “item” numbers(s).
• Deleted baseline “item” number(s).
• Deleted comparison “item” numbers(s).
In some cases, items in the comparison report are wider than
copy to see the entire contents of the comparison report.
Function Blocks dialog box.

Section 7
Loading, Monitoring and

Testing Application Programs
WINTERPRET provides all of the capabilities to load, monitor
and test application programs in the Regent controller. Most
of these features are performed from the Execution Controller
window and subsequent windows you open from it.
To access the Execution Controller, you must open a project.
To open a project, select the project that you want to open and
choose Open Project from the Project Selector's File menu
[ALT,F,O].
press ENTER.
From the Project Editor's Controller menu choose Execution
[ALT,C,E] to open the Execution Controller.
The commands available from the Execution Controller will
allow you to:
• Initialize the Regent Controller;
• Validate the configuration and operational status of the
Regent hardware;
• Validate the connections to field devices and the functional
operations of the application programs;
• Place the validated Regent system on-line.
The steps required to perform each of these procedures are
summarized below. For each step in the procedure, the ap-
propriate Winterpret commands are indicated. Later in this
section each of the WINTERPRET commands are described in
greater detail and organized by the associated menu in which
they are found.
For applications that require TÜV certification to Risk Class
5, the application programs must be uploaded and verified for
consistency with respect to the application source files. This is
done using the WINTERPRET software validation package
(catalog number T3835). The procedures for performing this

validation are described in the software validation package’s

product description (PD-6045). Refer to page 280, Placing the
Validated Regent System On-Line, for specific information on
when to perform the validation procedure during the
commissioning of your system.
Connecting your PC to the Regent

Before the Regent can be initialized, you must first connect it
to the computer running WINTERPRET. Connect one end of a
serial communications cable to port 1 of the Regent (the top
communications port of the left-most communications mod-
ule). Connect the other end to the serial port of the PC that
you set using the Set PC Comm Port command from the Proj-
ect Editor’s Options menu (see Section 4, Working with Proj-
ects for more details).
Important! Your PC must be connected to port 1 of the Regent in order to
initialize the Regent. When the Regent cold starts (first time
power-up) only port 1 is active. After you have initialized the
Regent you can load the Regent’s serial port configurations
and use other Regent communications ports for subsequent
loading, monitoring and testing functions.
Refer to Figure 146 for the serial cable pin-outs that match the
serial port connector type for your PC.

Loading, Monitoring and Testing Application Programs Section 7
Figure 146. Regent Communications Cable Pin-Outs.
Initializing the Regent with W INTERPRET

Initializing the Regent with WINTERPRET includes performing
the steps listed in Table 27. It is recommended that you per-
form the steps in the order that they are listed. All of the
commands are performed from the Execution Controller —
except loading the Regent serial ports configuration and
setting the real-time clock commands which are performed
from the Project Editor.
Important! Before you perform the initialization steps below you should
power-up the Regent equipment. When powering up the
Regent, first apply power to the I/O power supply units before
applying power to the Regent controller unit. This will allow
the Regent processors to read what type of I/O modules that
you have installed in your system. This will make it possible

for you to compare your physical I/O module configuration

with the I/O configuration you have created using
WINTERPRET.
Table 27. Steps to Initialize the Regent.
Step Description Command
1 Load RAMcode into the Choose Load RAMcode from the
Regent Execution Controller’s Initialize menu.
2 Load the I/O Choose Load I/O Configuration from
Configuration into the the Execution Controller’s Initialize
Regent menu.
3 Load the Shared Variable Choose Load Shared Allocation from
Definitions into the the Execution Controller’s Initialize
Regent menu.
4 Start Input processing Choose Start Inputs from the Execution
Controller’s Initialize menu.
5 Start Output processing Choose Start Outputs from the
Execution Controller’s Initialize menu.
6 Load the Regent Serial Choose Serial Ports from the Project
ports configuration Editor’s Definitions menu (choose Save
to Disk and Regent).
7 Set the Regent real-time Choose Set Real-Time Clock from the
clock Project Editor’s Controller menu.
Validating the Regent Equipment

After you have initialized the Regent you should validate the
equipment for proper connectivity, installation and configu-
ration.
Important! To perform this procedure you should have an application
program that you can load into the Regent system. This does
not have to be the actual program for your system, it can be a
simple test program that may be just one ladder logic function
block with one rung of ladder logic. It does not have to control
any actual I/O points.
Validate the Regent equipment by performing the steps de-
scribed in Table 28. These steps should be performed in the
order listed in the table.

Table 28. Steps to Validate the Regent Equipment

1 Validate the Regent I/O Choose Compare to Regent from the
Configuration I/O Configuration Editor’s Options
menu, see Section 4, Working with
Projects for details.
2 Load an application Choose Load Program from the
program Execution Controller’s Program menu.
3 Stop the application Choose Stop from the Execution
program Controller’s Program menu.
4 Perform the Faulted See Section 2, Installing the Regent
Status Check Hardware, for details. During this
check you will use the Fault Status
command from the Project Editor’s
Controller menu.
Step 1 validates the match between the installed I/O modules

and the configuration you have created using WINTERPRET. If
you perform this step and the I/O configuration you read from
the Regent is completely empty, you probably powered-up the
controller unit before the I/O assemblies were powered-up or
connected. Also, you may have forgotten to configure the I/O
chassis ID switches, to assign an individual ID number to each
I/O chassis.
Step 2 and 3 are used to load an application program into the
Regent before you perform the faulted status check. Unless
you load and stop (or run) an application program, several of
the tests you perform in the faulted status check will result in
a cold start of the Regent, instead of a warm start. The
Regent will only warm start if it has at least one application
program loaded.
Step 4 is used to validate the proper installation and connec-
tion of the Regent modules and chassis. In addition, the tests
you perform during the faulted status check verify the status
indicators of the various modules, and test the functionality of
various recovery and power failure circuits.

Validating the Functional Operations of

Your System
After you have validated the Regent equipment, you are pre-
pared to validate the functional operations of your system.
This includes validating the connections to your inputs and
outputs, the functional operations of your application pro-
grams, and the connections to external communications
equipment.
Follow the steps summarized in Tables 29 through 32 to
validate the functional operations of your system. The
appropriate WINTERPRET commands useful in performing the
validation tests are listed for each step.
Table 29. Steps to Validate the Regent’s Inputs.
1 Load the application program Choose Load Program from the Execution Controller’s
for the Regent Program menu.
2 Stop the application program Choose Stop from the Execution Controller’s Program menu.
3 Monitor the application Choose Monitor from the Execution Controller’s Program
program menu.
4 Open the Data Monitor Choose Data Monitor from the Program Monitor’s Control
menu.
5 Add the input(s) to the list of Use the Add button of the Data Monitor dialog and enter the
variables in the Data Monitor name for each input.
dialog box
6 Validate the input signal In the field, vary the state of the input device and validate the
correct input status. If the input status shown does not agree
with the field device status, check the field wiring and power
connections, the module status indicators, and check that you
are monitoring the correct tag name.
7 Repeat for each input
8 Completed Close the Data Monitor dialog box.

Table 30. Steps to Validate the Regent’s Outputs.

for the Regent that owns Program menu.
(controls) the output
2 Stop the application program Choose Stop from the Execution Controller’s Program menu.
program menu. This opens the Program Monitor.
4 Open the Forcing dialog Choose Force from the Program Monitor’s Control menu.
5 Verify that it is safe to Responsibility of Project Engineer or Commissioner.
operate the load device in
field
6 Make sure you have the Select Outputs from View options of the Forcing dialog. The
Forcing Outputs dialog open Forcing dialog title should read “Forcing Outputs.”
7 Add the output to the list of Use the Add button and enter the name and desired forced
variables of the Forcing state for the output.
Outputs dialog Note: You must have opened the Forcing dialog from the
Program Monitor of the application program that owns
(controls) the output.
8 Enable output forcing Select Enabled from Forcing options of the Force dialog. The
forced value is now in effect (until you choose disable, delete
the point from the list, or place the Regent memory lock key
switches in the on position).
9 Verify the status of the load Confirm that the output signal is properly controlling the load
device in the field device. If the load does not operate correctly, check the field
wiring and power connections, the module status indicators,
and check that you are forcing the correct tag name.
10 Change the value of the Use the Change button and enter the safe value for the
output back to the safe state. output. In most cases the safe state is off (0).
11 Remove the output from the Use the Delete button to delete the output name from the list
force list of forced variables. Make sure you first change the output
back to the safe operational state before deleting the output
from the forced variables list.
12 Repeat for each output Repeat steps 7 through 11 for each output to be tested.
13 Completed Select Disabled from the Forcing option of the dialog, close
the Forcing dialog box.

Table 31. Steps to Validate the Connections to MMI Equipment.

1 Check the configuration of Choose Set Serial Ports from the Project Editor’s Options
the Regent’s serial ports menu. Select Get from Regent to read the configuration of
the Regent’s serial ports.
2 Enable the MMI Responsibility of the MMI system operator. Most MMI
communications equipment will poll the Regent at regular intervals for points
configured to be read from a controller.
3 Validate the communications Examine the transmit and receive LEDs on the
connectivity communications module for proper activity. Verify that the
MMI equipment does not report communications errors.
4 Validate the configuration of Follow steps in Table 30 for output validation to load and stop
the Regent variables that are the program that controls the variables, and use the Forcing
read by the MMI dialog to change the state of the variables in the Regent. For
each point, validate that the correct data value is read by the
MMI.
5 Validate the configuration of Follow steps in Table 29 for input validation to use Data
Regent variables that the Monitor to monitor the state of the variables in the Regent.
MMI writes to the Regent For each point, validate that the data value the MMI writes to
the Regent is received correctly and modifies the properly
configured point.
Note: Systems that require TÜV safety certification must
follow strict guidelines when a MMI is configured to write data
to a safety system. Refer to Section 8, Safety Considerations
for additional requirements.
6 Completed All communication variable values changed during validation
should be returned to their safe state upon completion of the
test.

Table 32. Steps to Validate the Functional Operations of Application Programs.

into the Regent. Program menu.
2 Switch the application Choose Run or Stop from the Execution Controller’s Program
program to the running or menu.
stopped mode
When the program is in the Running mode, the Regent
executes the application program once each scan. When the
program is in the stopped mode the application program
execution is suspended. You can also single scan a stopped
program to manually initiate a single execution of the
program.
program menu. This opens the Program Monitor.
From the Program Monitor you can select function blocks to
monitor, change the running mode of the application program,
open the Data Monitor to monitor the status of particular
variables, and open the Forcing dialog to force inputs (if no
real inputs are connected to the Regent input modules).
4 Monitor the function blocks of Select the desired function block and choose Monitor from the
the application program Program Monitor’s Control menu.
By monitoring function blocks you can monitor the execution
of particular sections of your application program to validate
the correct operations of the process control and interlock
functions of the system.
5 Monitor groups of variables Choose Data Monitor from the Program Monitor’s Control
associated with an interlock menu. Use the Add button to add the name of each variable
function that cannot be to the variable list.
viewed in a single function
block monitor window
6 Stimulate the process inputs Use the function block monitors or Data Monitor as described
and validate the correct above to validate the status of the controlled variables of the
functional operations of the Regent.
application program If actual process inputs are not connected to the Regent, you
can use the Force dialog from the Program Monitor’s Control
menu to force inputs.
7 Repeat for each application
program
8 Completed After you have completed validating the application program’s
functional operations, make sure you restore any forced
variables back to their safe operating states.

Placing the Validated Regent System On-

Line
After you have completed the validation of the functional
operations of the Regent’s inputs and outputs, application
programs, and communications interfaces you will be ready to
place the Regent system on-line. The steps in Table 33 list the
complete steps necessary to ensure a fully operational and se-
cure Regent system. While most of the steps may have already
been performed in the previous initialization and validation
procedures, they are listed together in the table to represent a
single comprehensive list. All of the WINTERPRET commands
listed are performed from the Execution Controller unless
otherwise noted.
Important! Before you place a validated system on-line make sure that
you have planned for future expansion to your configuration
and programs by properly configuring the shared allocation in
the Shared Variable Editor and spare data space in the
Program Editor for each application program. You should
verify these settings before you put the system on-line if you
ever anticipate making application program and configuration
changes on-line.
The shared allocation defines the amount of memory allocated
in the Regent for storing shared variables. Check that your
allocation settings for shared variables meets your needs for
future expansion. See Using the Shared Variable Editor in
Section 4, Working with Projects for further information.
The spare data space defines the amount of spare program lo-
cal data space that will be allocated when the program is
loaded into the Regent. If you do not define the spare data
space before you load the programs and put the system on-
line, you may not be able to load a new version of the appli-
cation program with-out stopping and deleting the version
loaded and running in the Regent. See Using the Program
Editor in Section 5, Working with Programs and Function
Blocks for further information.
For applications that require TÜV certification to Risk Class
5, the application programs must be uploaded and verified
with respect to the application source files. This is done using
the WINTERPRET software validation package (catalog number

T3835). The procedures for performing this validation are

described in the software validation package’s product
description (PD-6045), which is provided as part of the
software validation package. Specifically, you must,
1. Use WINTERPRET to print out the application programs for
comparison to the application specification.
2. Run the checker and validator to verify the application
program’s compilation and loading integrity. This should
be performed after you have loaded and stopped the
application program (see Table 33, steps 10 and 11). The
integrity check must pass before you switch the application
program to the run mode.
3. Run GPLPRINT and GPLCHECK for applications using
the Guarded Peer-Link communications. This should be
done after you have loaded the Guarded Peer-Link
configuration (Table 33, step 13) and before you choose
Connect the GPL Network (step 14).

Table 33. Steps For Placing a Validated Regent System On-Line.

1 Cold start the Regent With no programs loaded in the Regent, cycle power on the
Regent controller unit.
2 Unlock the Regent Place the Regent memory lock keyswitches in the Off
position.
3 Load RAMcode Choose Load RAMcode from the Initialize menu.
4 Load the I/O configuration
and initial values Choose Load I/O Configuration from the Initialize menu.
5 Load the shared variable Choose Load Shared Allocation from the Initialize menu.
definitions and initial values
6 Start input processing Choose Start Inputs from the Initialize menu.
7 Start output processing Choose Start Outputs from the Initialize menu.
8 Load the Regent’s serial ports Choose Serial Ports from the Project Editor’s Definitions
configuration menu (Choose Save to Disk and Regent).
9 Set the Regent’s real-time Choose Set Real-Time Clock from the Project Editor’s
clock Controller menu.
10 Load the application program Choose Load Program from the Program menu. In the Load
for the Regent Program dialog box, check Load Initial Values. If you have
multiple application programs to load, make sure you load
them in the order that you want them to execute.
11 Switch the application Choose Run or Stop from the Program menu. If you only
program into the running or have one application program, choose Run and skip to step
stopped mode 13. If you have multiple application programs to load into the
Regent and want them all to start running at the same time,
choose Stop (run them after loading them all).
12 Repeat steps 10 and 11 for After all application programs are loaded and are in the
each additional application correct execution order, choose Select All and Run to place
program all of them in the running mode.
13 Load the Guarded Peer-Link Choose Load Network from the Network menu (skip to step 16
configuration. if no GPL communications are required).
14 Connect the Regent to the
Guarded Peer-Link network Choose Connect Network from the Network menu.
15 Start the Guarded Peer-Link Choose Start Network from the Network menu. Before you
Network (only for Regents start the GPL master, you should first load and connect each
that have a Net Master port) of the Regents on the GPL network.
16 Load the communications
protection configuration Choose Load Comm Protect from the Initialize menu.
17 Enable comm protection Choose Enable Comm Protect from the Initialize menu.
18 Memory lock the Regent Place the Regent memory lock keyswitches in the on position.

Using the Execution Controller

The Execution Controller is used to perform the various ini-
tialization, loading and monitoring operations on Regent con-
figuration, programs and data. The Execution Controller
displays the list of programs that are loaded in the Regent.
Each program in the list is described by name, version num-
ber, execution status, and program description.
Figure 147. The Execution Controller.
Application Program Execution

Application programs must be loaded from WINTERPRET into
the Regent. Loading an application program into the Regent
automatically loads it into all three to the Regent’s triplicated
processors. After loading an application program, it must be
switched to the running or stopped mode before loading an-
other program.
Application programs are executed in the Regent once each
scan cycle. The programs are executed sequentially, in the or-
der in which they are loaded (and switched to the running or

stopped mode). The function blocks within each program are

also executed sequentially, in the order in which they are de-
fined in the program.
Each program can be individually selected to run, stop, or
single-scan. A running program is executed once each scan. A
stopped program's execution is suspended until it is selected
to run. A program can be selected to scan once and stop, us-
ing a single keystroke from WINTERPRET. You can also select
multiple or all programs in the Execution Controller and
command them to run, stop, or single-scan.
In the Execution Controller, the programs are listed in their
order of execution. The execution status of each program is
displayed in the window. Further details about the execution
status of programs are described in Table 34.

Table 34. Program Execution Status.

Execution
Status Explanation Allowable Operations Remarks
Loaded - Pend Program has been Run: Switches this program to the Cannot load another pro-
loaded but not yet running mode. gram until this program is
switched to the run- switched (run or stop) or
Stop: Switches this program to
ning or stopped removed (cancel program
the stopped mode.
mode load).
Cancel program load: Removes Cannot perform a reset
this program from the Regent. local variables for this
program (unnecessary,
included with load) or
Note: You can stop, run, scan, other programs until this
delete or monitor other programs program is switched.
that are currently in the Regent. Cannot monitor this pro-
gram until it is switched to
running or stopped.
Stopped Program is stopped Run, scan, stop, delete and You may also reset local
and is not monitor are available for this variables provided that no
executing. program. other program switch is
pending.
Running Program is running Run, stop, monitor are available You cannot scan, delete,
and is executed for this program or reset local variables for
once each scan this program until it is
cycle. stopped.
Loaded - Mod 1) Program is Run: Switches to the new loaded Cannot load another pro-
stopped and a new program (or local data); execution gram until this program is
version has been status will switch to running. switched (run or stop) or
loaded but not yet Stop: Switches to the new loaded removed (cancel program
switched. program (or local data); execution load).
2) Program is status will switch to stopped. Cannot perform a reset
stopped and a reset Cancel Program Load: Removes local variables for this
local variables has the new loaded program (or local program or other pro-
been performed but data), existing program in the grams until this program is
not yet switched. Regent will remain stopped. switched.
Running - Mod Program is running Run: Switches to the new loaded Cannot load another pro-
and a new version program, execution status will gram until this program is
is loaded but not switch to running. switched (run or stop) or
yet switched. Stop: Switches to the new loaded removed (cancel program
program, execution status will load).
switch to stopped. Cannot perform a reset
Cancel Program Load: Removes local variables for this
the new loaded program, existing program or other
program in the Regent will remain programs until this
running. program is switched.

File Menu
Log Off
Exit
Program Menu
Load Program
From the Execution Controller's Program menu choose Load
Program [ALT,P,L] to load a program into the Regent. The
Execution Controller will display the Load Program dialog box
with a list of the project's available programs.
Figure 148. The Load Program Dialog Box.

Before you select a program to load, select whether or not to
load the initial values for I/O and shared variables controlled
by the program using the Load Initial Values check box in the
upper right corner of the Load Program dialog box. See Load
Initial Values, below, for details on making this selection.

After you have made your Load Initial Value choice, highlight
the program that you want to load and choose OK.
6 Shortcut: In the Load Program dialog box highlight the program that
you want to load and double-click or press ENTER.
Using this command requires the access right “load pro-
grams.”
Load Initial Values
This is check box is used to load the initial values of all the
variables “owned” by the application program.
Use Load Initial Values for the initial load of the application
program into the Regent, so that all of the “owned” variables
start at their defined initial values. Note that initial values
are defined in the I/O Configuration and Shared Variable Edi-
tors. If you check this box when you are loading a new ver-
sion to replace a version in the Regent, the “owned” variables
will be set to their initial values upon switching (run/stop) to
the new version. This may not be bumpless!
Do not check this box if you are reloading a new or same ver-
sion if you want the “owned” variables to retain their values
on switching (run/stop) to the new loaded version. This is the
preferred method for bumpless transfer to a new program ver-
sion.
Note: Load Initial Values has no bearing on the initialization of local
data to the program. Local data is automatically initialized
the first time that a program is loaded into the Regent. When
a program is reloaded, previously used local data remains in
its last state for bumpless transfer. New local data that the
modified program requires are automatically initialized. All
local data can be reinitialized if desired by using the Reset
Local Variables command (see page 289).
Program Loading Considerations
If there is more than one program to be loaded into the Re-
gent, and the programs need to be executed in a specific order,
then you should load the programs in the order in which they
are to be executed. After loading each program you must
switch the loaded program to the run or stop mode before you
can load the next program. Until a loaded program is
switched, no other programs can be loaded. If a program is in

the loaded state waiting to be switched, the Load Program

command is changed to “Cancel Program Load.”
If you want to load a program that is not the highest version
number you must edit, save, and compile the program to make
the older version the highest version. For more information
see Get Program History in Section 5, Working with Programs
and Function Blocks.
A lot of things occur as a program is loaded; and a variety of
status messages appear in the status bar (at the bottom of the
WINTERPRET window) during loading to keep you apprised of
the progress and activity during the program load operation.
Many of the operations done during the load process ensure
that the following things have been done:
1. All of the function blocks must be compiled.
2. All of the compiled function blocks must have consistent
references to the I/O, shared variable definitions.
3. These references must be consistent to those used by other
programs already loaded in the Regent.
4. The current I/O configuration (I/O module layout) for the
WINTERPRET project must be the same as that loaded in
the Regent.
5. The program must not require “ownership” of a variable
that is currently “owned” by another program in the
Regent. Ownership means that the program writes to the
variable (for example, a coil instruction in ladder logic, the
destination field of a scaling entry, the result of a floating
point equation, and so on). A variable can only be owned
by one program.
6. References to program local tag names must be consistent
(that is, all references must consistently use the tag as a
control relay, word register, or floating point register).
7. There must be memory available in the Regent to load the
program.
8. The program local data size must not be greater than 64K.
9. At least two of the Regent’s three memory lock keyswitches
must be off.

If Load Program is selected to load a program while a version

of that same program is currently in the Regent, then further
checks on the program local data are made.
1. The program local data references must be consistent to
those used by the program version in the Regent.
2. New program local data required by the program to be
loaded must be able to fit in spare data space within the
existing program local data in the Regent (see the Spare
Data Space command in Section 5, Working with Programs
and Function Blocks).
Cancel Program Load
This command appears in the Program menu instead of Load
Program when a program in the Regent is waiting to be
switched. A program should be switched after a Program
Load or Reset Local Variables command is executed. If you
want to cancel one of these operations instead of switching the
program to running or stopped use the Cancel Program Load
command.
This command does not prompt for confirmation.
At least two of the Regent’s three memory lock keyswitches
must be off to use this command.
Using this command requires the access right “load pro-
grams.”
View Error Messages
Use this command to display a list of errors generated during
the program load operation. From the View Error Messages
dialog box you can print the errors by choosing Print. The
printout is useful as a guide to where you must edit programs
and make changes in order to successfully load them. After
viewing or printing the error messages choose OK to return to
the Execution Controller.
Errors
This field lists the errors that occurred during the program
load attempt. Errors that occur during the program load
abort the load process. Follow the recommendations listed in
the error messages to correct the problem before attempting to
reload the program. Common loading problems include,
ownership violation, inconsistent references to I/O or shared

variables, or insufficient program local data area for the new

program version.
Run
Choose Run to place a program in the run mode. Used to
place a new “loaded” program in the run mode. Also used to
switch to a new program version after loading a new version
to replace an existing version in the Regent. The new version
will be in the run mode.
Programs cannot be run until inputs have been started (see
page 292, Start Inputs).
Using this command requires the access right “run pro-
grams.”
Stop
Choose Stop to place a program in the stop mode. Used to
place a new “loaded” program in the stop mode. Also used to
switch to a new program version after loading a new version
to replace an existing version in the Regent. The new version
will be in the stop mode.
Using this command requires the access right “stop pro-
grams.”
Scan
Choose Scan to solve the application program only once. A
program must be in the stop mode before it can be com-
manded to scan.
Using this command requires the access right “scan pro-
grams.”
Delete
Choose Delete to delete the application program from the
Regent. A program must be in the stopped mode before it can
be deleted.

Use Cancel Program Load to delete a new loaded program (see

page 287).
When the program is deleted, any “owned” variables that are
forced are automatically unforced.
When the program is deleted, the “owned” variables are
automatically set to their final values (as configured in the I/O
Configuration and Shared Variable Editors).
Using this command requires the access right “delete loaded
programs.”
Reset Local Variables
Reset Local Variables is used to reinitialize all program local
data for a program. Program local data contains the status of
all variables used by the program that are not I/O points or
shared variables. Additional information is contained in the
program local data for specific ladder logic function block in-
structions (low-high transitional, high-low transitional, timer,
counter, voter and mid value) and scaling function blocks
(timing parameters). After executing a Reset Local Variables
command you should use the Run or Stop command to switch
to the reinitialized local data. Choose Run or Stop depending
on the operational state you want the program to have after
reinitializing the local data.
Use the Cancel Program Load command to cancel the Reset
Local Variables command without switching the program.
Using this command requires the access right “force and date
change.”
Monitor
Use this command to open the Program Monitor for the se-
lected program. From the Program Monitor window you can
select function blocks to monitor and access the Data Monitor
and Force dialogs. See Using the Program Monitor for further
information.
A program cannot be monitored if it is waiting to be switched.
Switch the program to running or stopped before monitoring.

Select All
Use this command to select all of the programs in the
Execution Controller list. Normally used to select all of the
programs before executing Run, Stop, Delete, or Scan com-
mands (does not apply to Reset Local Variables). The selected
programs are shown highlighted (reverse video) on the
Execution Controller list. You can select individual programs
by clicking on the program name.
You can also select multiple programs using SHIFT+click and
CTRL+click methods.
When you select multiple programs using Select All (or

SHIFT+click, CTRL+click methods) to run, scan, stop or delete,
the command selected is performed one program at a time
until all programs have been commanded as requested. For
example, if you select two of four programs in the Regent, and
choose run, one program will be placed in running mode, and
then the other program is placed in running mode. They are
not both placed in the running mode on the same scan cycle.
The delay between execution of the command for each pro-
gram selected is dependent on the operational speed of the PC
and communications delays to the Regent. This may range
from fractions of a second to a couple seconds.
This may not be so important to Run and Stop commands, but
it may be confusing if you are trying to single-scan multiple
programs. If multiple programs are commanded to single-
scan, they will each single-scan — but not at the same time.
Initialize Menu
Load RAMcode
Used to initialize the Regent system after a cold start. This
loads the RAMcode portion of the TRIOS operating system
into the Regent. The RAMcode must be loaded from the com-
puter running WINTERPRET into the Regent before any other
initialization or load operation. Until RAMcode is loaded, the
Regent is cannot run application programs or perform most
communications functions. You cannot load RAMcode if there
are programs in the Regent or if the inputs or outputs are
started.

Using this command requires the access right “load

RAMcode.”
Load I/O Configuration
The I/O configuration that you developed using WINTERPRET
must be loaded into the Regent. The Regent will use this in-
formation to map its memory for the type of I/O modules that
you configured, and use this configuration for scanning the
inputs and outputs. The loaded I/O configuration will be used
by the Regent, regardless of the actual I/O modules installed
in the Regent I/O assemblies.
This command loads the I/O configuration (I/O module layout)
into the Regent and initializes the I/O memory area. The
Regent, by default, will initialize all digital-type I/O to off, and
all analog-type I/O to zero. Specific initial values that you
configure using the I/O Configuration Editor will subse-
quently be loaded by this command (replacing the defaults
initialized by the Regent).
You cannot use the Load I/O Configuration command unless
all programs are deleted from the Regent and inputs and out-
puts are stopped.
Using this command requires the access right “edit I/O lay-
out” or “edit I/O definitions.”
Load Shared Allocation
Loads the allocation size for shared variables (as configured
using the Shared Variable Editor’s Allocate Register Space
command — see Section 4, Working with Projects). The
Regent, by default, will initialize the entire allocation space for
control relays to off, and all word registers and floating point
registers to zero. Specific initial values that you configured in
the Shared Variable Editor will subsequently be loaded by this
command (replacing the defaults initialized by the Regent).
You cannot use the Load Shared Allocation command unless
all programs are deleted from the Regent and inputs and out-
puts are stopped.


Load Comm Protection
Loads the communication protection information for all I/O
and shared variables. You configure comm protection in the
I/O Configuration and Shared Variable Editors on a per point
basis. Variables that are comm protected cannot be changed
via communications functions when Comm Protect is enabled.
Disable/Enable Comm Protect
This menu item toggles based upon the status of the comm
protect status system variable “COMPROTECTED” in the
Regent. Variables that are comm protected cannot be changed
via communications functions when Comm Protect is enabled.
Comm protection must be loaded to use this command.
Voted Reset
Commands the Regent to execute a voted reset, which resets
the fault status bits in memory and re-initializes a new re-
placement processor module.
Depending on the Regent’s application scan time, a voted re-
set may take from a few seconds to a couple minutes to exe-
cute. During this time programs are running normally. At
the end of the voted reset the Regent clears its communica-
tions buffers, sometimes causing a momentary interruption in
a communications message transmission or reception. This
sometimes causes a communications error on WINTERPRET
and a dialog box appears. If this happens choose the Retry
button in the dialog box to return to the Execution Controller.
Using this command requires the access right “perform voted
reset.”

Start Inputs
Causes the Regent to begin input processing. When input
processing is started the Regent reads input data from all of
the input modules once each scan cycle.
After inputs are started, background testing of I/O modules is
also started and faults will begin to be reported for both input
and output modules.
RAMcode.”
Start Outputs
Causes the Regent to begin output processing. When output
processing is started the Regent sends output data to all of the
output modules once each scan cycle.
Outputs cannot be started unless inputs are started.
RAMcode.”
Stop Inputs
This command causes the Regent to Stop input processing.
Inputs cannot be stopped if programs are running.
Inputs cannot be stopped unless outputs are stopped.
RAMcode.”
Stop Outputs
This command causes the Regent to stop output processing.
When output processing is stopped, output modules will com-
mand the outputs to either turn off or hold their last state de-
pending on the fault mode jumper setting on each I/O chassis.
Outputs cannot be stopped if programs are running.


RAMcode.”
Network Menu
The commands available from the Network menu are used to
load and control the Guarded Peer-Link (GPL) communica-
tions functions for the Regent. Guarded Peer-Link is used for
peer-to-peer communications between two or more Regent
systems. Guarded Peer-Link communications is included in
the Communications add-in software package for
WINTERPRET. Detailed guidelines on how to configure, con-
nect and perform Guarded Peer-Link communications can be
found in the product description for the T3831 communica-
tions add-in software package.
Before using any of the Network menu commands you must
configure and successfully compile the Guarded Peer-Link
configuration. You must also configure the Regent’s serial
ports for Guarded Peer-Link and load the serial port configu-
ration in the Regent (see Section 4, Working with Projects,
Serial Ports command).
Load Network
Loads the configuration for Guarded Peer-Link communica-
tions into the Regent. After loading the network the Regent
system variables “GPLINTEMP” and “GPLOUTTEMP” should be
on, reflecting that the Guarded Peer-Link input templates and
output templates are loaded. You should execute the Load
Network command before using the Connect Network or Start
Network commands.
Using this command requires the access right “configure
Unload Network
Deletes the configuration for Guarded Peer-Link communica-
tions from the Regent. Before you use the Unload Network
command you should use the Stop Network and Disconnect
Network commands.

Connect Network
Activates the Guarded Peer-Link communications functions
for the Regent. For Regents that are Guarded Peer-Link
slaves (for example, they only have Net Slave and no Net Mas-
ter ports configured), this fully activates the Guarded Peer-
Link communications. You should perform Connect Network
on Guarded Peer-Link slave Regents before you perform Start
Network on the Guarded Peer-Link Master Regent(s). If the
Regent is a Guarded Peer-Link Master (has one port config-
ured for Net Master), you should execute the Connect Net-
work command before using the Start Network command.
Disconnect Network
De-activates the Guarded Peer-Link communications func-
tions for the Regent. If this is a Guarded Peer-Link Master
Regent (contains a port configured for Net Master) you should
execute a Stop Network command before using the Disconnect
Network command. For Guarded Peer-Link slave Regents
(those that have Net Slave but no Net Master ports config-
ured), this fully de-activates the Guarded Peer-Link communi-
cations.
Start Network
Required only for Guarded Peer-Link Master Regents. If this
is a Guarded Peer-Link Master, this command activates the
leg of the Guarded Peer-Link network for which this Regent
has the Guarded Peer-Link Master role.
Stop Network
Required only for Guarded Peer-Link Master Regents. If this
is a Guarded Peer-Link Master, this command de-activates the
leg of the Guarded Peer-Link network for which this Regent
has the Guarded Peer-Link Master role.

Options Menu
Prompt for Delete
Set Confirmation Level
Used this command to set the level of confirmation response
required for most commands that change or load information
in the Regent. In the Set Confirmation Level dialog box
choose the desired confirmation level. Each confirmation level
selection is described below.
Figure 149. The Set Confirmation Level Dialog Box.

When a system user logs on to WINTERPRET, the confirmation
level automatically switches to the last confirmation level set
the last time that user was logged on.
Using this command requires the access right “bypass confir-
mation prompts.” Users who do not have this access right al-
ways receive confirmation codes.
None
Commands requested are immediately performed, without
confirmation prompts.
Yes-No Confirmations
A dialog box will prompt you about the command selected.
You must choose Yes to execute the command.

Confirmation Codes
Choosing this option causes a dialog box to prompt you to
confirm the command selected and repeat a one-character
confirmation code. You must enter the indicated confirmation
character and choose OK to perform the command.
If you enter the wrong confirmation code, choose OK in the
Incorrect Confirmation Code dialog box, re-enter the correct
confirmation code as prompted.
Commands that require confirmations are shown in Table 35.
Table 35. Commands Requiring Confirmation Codes.
Clear Fault History in Regent Reset Local Variables
Connect Network Run Program
Data Monitor - Change Value Scan Program
Delete Fault History File Set Real Time Clock (Save)
Delete Program Set the Serial Ports (Save to
Regent and Disk)
Disable Comm Protection Start Inputs
Disconnect Network Start Network
Enable Comm Protection Start Outputs
Forcing Stop Inputs
Load Comm Protection Stop Network
Load I/O Configuration Stop Outputs
Load Network Stop Program
Load Program Unload Network
Load RAMcode Voted Reset
Load Shared Allocation
Window Menu

Help Menu
Using the Program Monitor

Choosing the Monitor command from the Execution
Controller’s Program menu opens the Program Monitor. An
example is shown in Figure 150. The Program Monitor lists
the function blocks of the application program by name,
version and description.
Figure 150. An Example of the Program Monitor.

From the Program Monitor you can select a particular func-
tion block to monitor, change the program’s execution status
and open the Forcing and Data Monitor dialog boxes using

commands from the Program Monitor’s menus. Each of these

commands are described below.
File Menu
Open Function Block
In the Program Monitor window, select the function block you
want to Monitor and choose Monitor from the File menu.
This will open a monitor window for the particular type of
function block selected, allowing you to monitor specific exe-
cution status of the application program logic. See Monitoring
Function Blocks on page 306 for details associated with
monitoring function blocks.
edit a function block’s details using the function block editors
(see Using the Function Block Editors in Section 5, Working
with Programs and Function Blocks).
Cancel.
View Program Description
This command opens the Program Description dialog box to
let you view the program’s description. To add or edit a pro-
gram’s description use the Program Editor (see Using the
Program Editor in Section 5, Working with Programs and
Function Blocks).
When you have finished viewing the program’s description,
choose Cancel.
View Program Details
This command opens the Program Details dialog box. While
you can scroll up and down through the program’s details text
box to view its contents, you are not allowed to add or edit the
details using this command. You can add or edit a program’s
details using the Program Editor (see Using the Program Edi-
tor in Section 5, Working with Programs and Function
Blocks).


choose Cancel.
Print Program
This is a standard program printing function. For more in-
formation see the Program Editor’s Print Program command
in Section 5, Working with Programs and Function Blocks.
Print Setup
Log Off
Exit
Control Menu
Data Monitor
Opens the Data Monitor dialog box allowing you to enter a list
of tag names and view their status. Also lets you change val-
ues to variables that are “owned” by the program or are local
to the program.

Figure 151. Example of the Data Monitor.

The variable list is an alphabetically-sorted list of the entered
variables. Each variable is listed by tag name, flags (C for
comm protect, F for forcing), data type, and value (for discrete
data types, 1 for on and 0 for off).
Choose from the following buttons:
Close
Closes the Data Monitor dialog box. When you close the dia-
log box the list of variables to display is not saved. Each time
you open the Data Monitor dialog box you must re-enter the
variables that you want to monitor.
Add
Lets you to add a variable to the list. Enter the variable name
and choose OK to add the variable, choose Cancel if you decide
not to add the variable.
Change Value
Lets you to change the value of a variable selected from the
monitor list. Select the variable whose value you want to
change and choose Change Value (or double-click on the se-
lected variable).
You can only change the value of variables that are “owned”
by this program or are local data in this program.
Changing values requires the access right “force and data
change.”

Delete
Deletes the selected variable from the data monitor list.
Forcing
Opens the Forcing dialog box allowing you to force inputs and
outputs. Forcing an input overrides the input value read from
the input module. Forcing an output overrides that applica-
tion program’s logic solution for the output value and the
forced value is sent to the output module to control the con-
nected load device. Two separate dialog boxes are used for in-
put forcing and output forcing. From either dialog box you
can switch to the other.
Forcing Inputs is the dialog box normally displayed when you
choose Forcing. Use the View option buttons (Inputs,
Outputs) to choose between the Force Inputs and Force
Outputs dialog boxes.
From the Forcing Outputs dialog box you can enter forcing for
digital outputs, analog outputs, shared variable control relays,
shared variable word registers (you cannot force shared vari-
able floating point registers or program local data types).
Forcing can only be done while at least two of the Regent’s
three memory lock keyswitches are in the off position. When
the keyswitch is in the on position all input and all output
forcing is disabled. If two of the three keyswitches are
switched back to the off position, forcing will not be automati-
cally re-enabled; to re-enable forcing you must open the force
dialog boxes and enable forcing.
Forcing is meant to be used for system start-up testing and
commissioning only. It is not intended to be used as a main-
tenance override or bypass facility for safety-critical devices
during normal system operations. Refer to Section 8, Safety
Considerations, for recommended practices for implementing
bypass and overrides for safety critical devices during normal
system operations.
Use the Inputs and Outputs option buttons to switch between
the Forcing Inputs and Forcing Outputs dialog boxes.

Figure 152. The Forcing Inputs Dialog Box.

In both dialog boxes a scrolling list box shows the variables
that are in the Regent's force table. Use the Enabled option
button to activate forcing for the variables in the force list.
The variable list is an alphabetically sorted list of the vari-
ables. Each variable is listed by tag name, data type, and
value (for discrete data types, 1 for on and 0 for off).
When input forcing is enabled for any program the system
variable control relay, “IFORCE,” is on. When output forcing
is enabled for any program the system control relay,
“OFORCE,” is on. In addition, the system variable word regis-
ters “INPFRC,” and “OUTFRC” contain the quantity of input
variables and output variables currently entered in the Regent
force tables (whether enabled or disabled). These system vari-
ables can be monitored using external communications
equipment (DCS and MMI) to inform operators regarding the
presence of forced data in the Regent.
Forcing variables requires three basic steps:
1. Two of the Regent’s three memory lock keyswitches must
be off.
2. Add the variable to the force list.
3. Enable the force list.

Variables in the force list are not actually forced until the
force table is enabled. Once the force table is enabled, if a
variable is added to the table it immediately becomes forced.
While a forcing dialog is open choose from the following option
buttons:
Close
Closes the Forcing Inputs and Forcing Outputs dialog boxes
(closing one dialog box also closes the other). When you close
the dialog boxes, the force lists and the forced status of vari-
ables remain in the Regent. When you are through with
forcing you should normally disable and delete the variables
from the list so that safety-critical devices are not inadver-
tently left in a forced state. For added protection, always
switch the Regent’s memory lock key switches to on after you
have finished forcing. This automatically disables all input
and output forcing in the Regent. Because the force tables are
stored in the Regent, each time you open the Force dialog
boxes you will be able to see if there are any variables in the
force lists before you add new forced variables or enable forc-
ing.
Add
Choose Add to add a variable to the force list. In the dialog
box enter the name of the variable and the forced value. In
the Forcing Outputs dialog box you can only add variables
that are owned by this program.
For discrete digital inputs, digital outputs and control relays
enter 1 for on, 0 for off. For analog inputs and outputs you
must enter a value within the range of 0 and 4,095. For ther-
mocouple and RTD inputs you must enter a value in the tem-
perature range configured for the input point (that is, in
either degrees Fahrenheit or degrees Celsius, and in a resolu-
tion of units or tenths of a degree).
Change Value
Lets you change the forced value of the selected variable from
the force list. Select the variable from the list and choose
Change Value (or double-click on the variable name).
Changing values requires the access right “force and data
change.”

Delete
Deletes the selected variable from the force list, allowing the
variable to return to normal control operations.
If there is only one variable in the force list and you delete it,
the force list is automatically disabled.
Run
Places the selected program in the running mode.
This command is disabled (dimmed) when the status bar indi-
cates Off-Line. See the Put Monitor On-Line command, be-
low.
Using this command requires the access right “run pro-
grams.”
Stop
Places the program in the stopped mode.
cates “Off-Line.” See the Put Monitor On-Line command,
below.
Using this command requires the access right “stop
programs.”
Scan
Executes the application program once. Programs must be
stopped before they can be single-scanned.
below.
Using this command requires the access right “single-scan
programs.”
Put Monitor On-Line/Take Monitor Off-Line
This menu command toggles between Put Monitor On-Line
and Take Monitor Off-Line. The Put Monitor On-Line com-
mand causes WINTERPRET to communicate to the Regent and
display the execution state of the program in the status bar
(which will be either running or stopped). When you open the
Program Monitor the window is automatically on-line. The
Take Monitor Off-Line command disables the run, stop, and

scan commands and displays the message “Off-Line” in the

status bar.
Window Menu
Help Menu
Monitoring Function Blocks

Each type of function block has a separate monitor. By using
the various function block monitors you can perform a num-
ber of different functions. These functions include data
change, loop tuning, etc.
Use the following procedure to open the Execution Controller
and begin monitoring function blocks.
From the Project Selector, open the project containing the
program whose function blocks you want to monitor. To open
a project, select the project that you want to open and choose
Open Project from the Project Selector's File menu [ALT,F,O].
press ENTER.
Open the Execution Controller by choosing Execution from
the Project Editor's Controller menu [ALT,C,E].
If the program that you want to monitor has not already been
loaded into the Regent, choose Load Program from the
Execution Controller's Program menu [ALT,P,L] to load the
program.

If the program has already been loaded, choose Monitor from

the Execution Controller's Program menu [ALT,P,M].
Commands Common to all Function Block

Monitors
The function block monitor windows share may common
commands from the their File and Control menus. These
commands are described below.
File Menu
edit a function block’s details using the function block editor
(see Section 5, Working with Programs and Function Blocks).
Cancel.
View Function Block Description
This command opens the Function Block Description dialog
box to view the function block description.
choose Cancel.
Log Off
Exit

Control Menu
Run
Places the program in the running mode.
This command is disabled (dimmed) when the status bar
indicates “Off-Line.” See the Put Monitor On-Line command,
below.
Using this command requires the access right “run
programs.”
Stop
Places the program in the stopped mode.
below.
Using this command requires the access right “stop
programs.”
Scan
Using this command requires the access right “single-scan
programs.”
Executes the application program once. The program must be
stopped in order to single-scan.
below.
Put Monitor On-Line/Take Monitor Off-Line
This command toggles between Put Monitor On-Line and
Take Monitor Off-Line. The Put Monitor On-Line command
causes WINTERPRET to communicate to the Regent to monitor
and display values for the application logic displayed in the
window. The program execution state is shown in the status
bar (as either Running or Stopped). The Take Monitor Off-
Line command disables the run, stop and scan commands,
displays the message “Off-Line” in the status bar, and stops
displaying values for application logic in the window.

Window Menu
Help Menu
Using the Ladder Logic Monitor

When you select a ladder logic function block to monitor, the
ladder logic elements of the function block are displayed on
the screen, showing their current status. An example of the
Ladder Logic Monitor is shown in Figure 153.

Figure 153. Example of the Ladder Logic Monitor.

The current program mode (whether running or stopped) is
shown in the status bar of the monitor screen.
If you like you can display rung and cell comments during
monitoring by choosing Show Comments from the Options
menu [ALT,O,C].
File Menu
From the File menu you can view the function block details,
view the function block description, log off and exit the
WINTERPRET application. For more details see page 307, Com-
mands Common to Function Block Monitors.
Control Menu
From the Control menu you can run, stop and single-scan the
application program. For more details see page 307,
Commands Common to Function Block Monitors.

Search Menu
Using the commands from the Search menu you can search
for particular rungs, elements or tag names in the ladder logic
function block. These search commands are identical to those
used in the Ladder Logic Editor. For further information see
Using the Ladder Logic Editor, Search Menu in Section 5,
Working with Programs and Function Blocks.
Options Menu
Show Comments/Hide Comments
Displays or hides the ladder logic rung and cell comments with
the ladder logic rungs.
Using the Analog Scaling Monitor

The Analog Scaling Monitor is used to display the on-line
status of the scaling function block execution. The monitor
lists each of the scaling entries line by line. To monitor the
status of the variables used in the scaling entries see the
Control menu command Examine Entry (page 312).

Figure 154. An Example of the Analog Scaling Monitor.
File Menu
From the file menu you can view the function block details,
view the function block description, log off and exit the
WINTERPRET application. For more details see page 307,
Commands Common to Function Block Monitors.
Control Menu
From the Control menu you can run, stop and single-scan the
application program. For more details on these commands see
page 307, Commands Common to Function Block Monitors.
Examine Entry
This dialog box is used to monitor the status of individual
scaling operations within the scaling function block. It dis-
plays the status of all the variables associated with the scaling
entry selected, including the function block timing parame-
ters.

Figure 155. Monitoring an Analog Scaling Entry.

From the Analog Scaling Monitor you can double-click or
press enter on the selected entry to open the Examine Entry
dialog box.
Search Menu
Using the commands from the Search menu you can search
for an analog scaling entry number, or tag names in the ana-
log scaling function block. These search commands are identi-
cal to those used in the Analog Scaling Editor. For further in-
formation see Using the Analog Scaling Editor, Search Menu
in Section 5, Working with Programs and Function Blocks.
Regent System Operating States

As you use the WINTERPRET commands to initialize and load
your system configuration and programs you place the Regent
system into various operating states. Other actions such as
applying or removing power to the Regent system or the fail-
ure of one or more modules in the system also affect the oper-
ating state of the Regent. These operating states are docu-
mented here for your reference.
The Regent's operating states have been designed to provide
predictable control: the system will either continue to function
properly or, if continued proper functioning is impossible, it
will transition to a pre-determined safe shutdown condition —
with outputs in a known state. After such a shutdown, the

system can then be recovered without false outputs into the

process.
To better understand the Regent's different operating modes,
it is helpful to know the states that the system can assume.
Figure 156 is a state diagram showing the various operating
modes of the Regent. Table 36 summarizes the processor and
I/O indications of each state.
Figure 156. Regent State Diagram.
State 0, Shipped from Factory

State 0 is the original state of the Regent, this is the state the
system is in when it is removed from its shipping container.
In this state, the Regent is fully functional; however, it has no
power applied, has no installed application programs, and a

major portion of its operating system, the RAMcode, is miss-

ing.
State 1, Cold Start

State 1 is the cold-start state. When the Regent is first pow-
ered up, it executes a cold-start. This procedure causes the
Regent to access the I/O system, determine what types of I/O
are in which racks and in which slots in those racks, and then
to idle — waiting for the RAMcode to be loaded. While the
system is idling, it performs background self-tests of all the
controller assembly circuits.
The cold-start state also can be entered from the operating
state under certain multiple failure conditions (such as simul-
taneous processor failures, or the loss of all three copies of the
operating system). When the cold-start state is entered as a
result of such multiple failure conditions, all outputs shut
down to the safe state programmed by the fault mode jumper
selection on the I/O chassis (see Installing the I/O Chassis in
Section 2, Installing the Regent Hardware, for information on
setting the fault mode jumper).
State 2, TRIOS Loaded

State 2 is the state the system assumes immediately after the
RAMcode portion of the TRIOS operating system has been
downloaded from the computer running WINTERPRET, but be-
fore any other configuration information or application pro-
grams have been downloaded.
State 3, Initialize, Load and Run

State three is actually a combination of initialization, loading
and running operations that must be performed on the Regent
system. After certain operations in this state, the status indi-
cations of the processor modules and I/O modules will change.
After all of the operations are completed the Regent will tran-
sition to State 4, the Operational state.
State 4, Operational
State 4 is the system's operating state. This is the normal,
real-time operating condition of the Regent. In this state, all

modules are active, selected programs are running, and the

system is controlling outputs.
When the system is in State 4, three things can occur that will
cause it to transition to another state.
1. Power Interruption. Loss of input power to the controller
assembly will cause the Regent to transition to State 6, the
stand-by state (see State 6, below). After power is restored,
the Regent will return to State 4 if the restart self-check in
State 7 is successful. All programs previously running in
the Regent will re-start (warm start). Please note that
during the warm start process temporary user data such as
timer and counter accumulates may not be correct since
timing and counting cannot occur if power has been lost or
if power has been removed and restored to all three proces-
sors simultaneously.
2. Software Time-Out. The Regent's floating point math
software permits users to program a WHILE statement.
While this function is useful for certain applications, it can
create an infinite loop in the software if used improperly.
For example, the WHILE condition may never occur 
causing the software to hang on that instruction indefi-
nitely. If this, or another failure of the application soft-
ware, should occur, preventing the system from completing
a scan cycle within a given amount of time (195 millisec-
onds for 128K processors, 395 milliseconds for 512K proc-
essors), the Regent's operating system will cause the
Regent to transition to State 5, the time-out state, in order
to break the infinite loop and take the system to a safe
state.
3. Cold Start. Should the controller assembly ever suffer a
catastrophic failure (such as simultaneous processor fail-
ures, or the loss of all three copies of the operating system),
the Regent will transition from any state to State 1, the
cold-start state. All outputs will transition to the shut
down state to which the fault mode jumper has been set. If
the processors are still functional, the RAMcode and pro-
grams can be re-loaded and the system can be re-started.
State 5, Time-Out
State 5 is the time-out state. This state is called the time-out
state since it is reached if a software watchdog time-out occurs

(see State 4, above). When this state is reached as a result of a

software watchdog time-out, all outputs shut down to the safe
state programmed by the fault mode jumper selection on the
I/O chassis (see Installing the I/O Chassis in Section 2,
Installing the Regent Hardware, for information on setting
the fault mode jumper).
You must start outputs and run programs to return the sys-
tem to State 4, to resume normal operations.
State 6, Stand-By
State 6 is the stand-by state. The system will transition to
this state if it loses power while in States 3, 4 or 5. While the
power is off, all of the programs (if loaded) are maintained in
battery-backed memory. When power is reapplied, the system
will transition to State 7, where an automatic restart self-
check will be performed
State 7, Restart Self Check

State 7 is entered when power has been applied to a Regent in
State 6, the stand-by state. In State 7, the Regent’s processor
modules perform a complete validation and vote of the system
configuration and any loaded application programs. In this
voted self check is successful, and there were programs in the
Regent, then the system returns to the last power-on state
(State 3, 4 or 5).
When the Regent returns to one of these previous states, the
application programs resume the running or stopped execu-
tion mode that they were in when power was removed. It is
important to note that while programs are retained through
power loss and warm start, data and fault history information
may be reset to zero.
If there were no programs loaded in the Regent, or if the pro-
grams or configuration information has been lost or cor-
rupted, the Regent will transition to State 1, Cold Start.

Table 36. Processor States and Indications.

System Processor and
State Name Description I/O Indication
0 Shipped from Not yet installed or powered No indication; no power

factory
1 Cold-start The system is powered up Processor run lights: Off
Transceiver fault lights: Red
I/O module fault lights: Red
Output module shutdown lights: Red
2 TRIOS loaded The TRIOS RAMcode has Processor run lights: Slow blink
been loaded to complete the Transceiver fault lights: Red
operating system I/O module fault lights: Red
Output module shutdown lights: Red
3 Initialize. Load As you perform the Transceiver active/fault lights: Red

and run following operations, the I/O module active/fault lights: Red
status indications change as Output module shutdown lights: Red
noted:
Load the I/O configuration No changes, same as State 2
Load the shared allocation No changes, same as State 2
Start inputs Transceiver active lights: Turn green
Input module active lights: Turn green
Load programs No changes

Start outputs Output module active lights: Turn green
Output module shutdown lights: Turn off
Run programs Processor run lights: Fast blink

4 Operational Normal operational state Processor module run lights: Fast blink
Transceiver active lights: Green
I/O module active lights: Green
output shutdown lights: Off
5 Time-out Run light: Slow blink Transceiver active lights: Green

input module active lights: Green
output module fault lights Turn red
output shutdown lights: Turn red
(unless Hold
mode)
6 Stand-by Regent was powered down No indication; no power

from State 3, 4 or 5
7 Restart self- Regent votes all programs During this brief state, most fault
check and configuration data lights will be on, then the system
will either warm start (to States
3, 4 or 5) or cold start (State 1)

Section 8
Safety Considerations
The Regent control system has been independently certified
by the German government's Technischer Überwachungs-
Verein (TÜV) to meet the requirements of Risk Class 5.
Conditions and configurations that must be adhered to if the
system is to remain in compliance with the requirements of
Risk Class 5 certification are clearly marked with a TÜV
symbol.
Second Fault Occurrence Time

Several of the TÜV application conditions require diagnostic
testing to be scheduled within a time period referred to as the
“second fault occurrence time.” To ensure that the
probability of an undetected second failure is sufficiently low,
and to thus help provide for continued safe operation, such
diagnostic testing must be performed within a period that is
significantly shorter than the second fault occurrence time.
The second fault occurrence time is established by assuming
that a first fault has occurred, and then considering the
system to be vulnerable to a second fault. The time that the
system is allowed to operate in such a vulnerable state after
the first fault state depends on the expected demand rate on
the system, the hazard rate of the process, and the reliability
of the function under consideration.
For the Regent modules, the second fault occurrence time is
approximately two orders of magnitude less than the
particular module’s mean time between failures (MTBF).
Environmental Considerations
The Regent has been designed to withstand industrial
environmental conditions, including variations in temperature
and humidity, shock, vibration, electromagnetic interference,
electrostatic discharge, and input power line fluctuations.

Table 37. Environmental Requirements.

DIN IEC 68 Environmental Testing -14° F (-25° C), 16 hours
Part 2-1 Test Aa: Cold System not operating
Functional test after exposure
DIN IEC 68 Environmental Testing 32° F (0° C), 16 hours

Part 2-1 Test Ad: Cold System operating
Reduced supply voltage
(-15%)

Part 2-2 Test Bc: Dry Heat System not operating

Part 2-2 Test Bd: Dry Heat System operating
Increased supply voltage
(+25%)

Part 2-3 Damp Dry Heat, cycle 95% relative humidity
System not operating
DIN IEC 68 Environmental Testing Frequency Range: 10-55 10 Hz

Part 2-6 Test Fc: Vibration Amplitude: ±0.15 mm
(sinusoidal) Sweep: 1 oct/min
1 hour per axis
System not operating
IEC 801 (01.91) Electromagnetic Compatibility for Industrial-process

Measurement and Control Equipment:
Part 2 Electrostatic Discharge Level 3

Requirements Contact discharge up to 6 KV
Part 3 Radiated Electromagnetic Level 3

Field Requirements f = 0.1 ... 1000 MHz
10 V/m
Part 4 Electrical Fast Transient/ Level 4

Burst Requirements t ≥ 60s
F = 2.5 KHz
U = 2 kV
No permanent faults
Part 5 Surge Immunity Level 2
6 KV
The standards shown in Table 37 were selected because they

represent conditions beyond those that are expected to be seen
in most industrial installations. However, each installation
must be designed to ensure that the control equipment is not

Safety Considerations Section 8
operated in environments that are beyond its design

tolerances. Therefore, considerations must be given to proper
temperature control, humidity control, control of vibration
and shock, as well as shielding and proper grounding to
ensure that exposure to electromagnetic interference and
electrostatic discharge sources are minimized.
In particular, the following installation recommendations
apply to the Regent.
Temperature
The ambient temperature of the Regent must be kept below
140° F (60° C) under all conditions. Since 140° F (60° C) is
the absolute maximum guaranteed operating temperature, it
is recommended that actual installations be kept substantially
below this to prolong equipment life under normal conditions.
In addition, extreme temperature changes (greater than ±1° F
[±0.5° C] per minute) should be avoided as much as possible
since such temperature fluctuations can produce thermal
shock that can degrade the quality of electrical connections.
With respect to low temperature, the Regent has been
designed and tested to operate down to 32° F (0° C) ambient
temperature environment.
Humidity
The Regent has been designed and tested to operate in the
range of five to 95 percent relative humidity (non-condensing).
It is important to avoid combined changes in temperature and
humidity that could produce condensation, since the effects of
condensation on any type of electronic equipment can result
in equipment failures or improper operation.
Contaminants
The Regent is constructed with ventilated housings allowing
free circulation of air to provide maximum cooling efficiency.
Since the electronics are exposed to the ambient air
conditions, protection must be provided to guard against
exposure to the following conditions:
• Caustic chemicals (such as high concentrations of H2S);

• Particulate contaminants (including dust or conductive

materials);
• Liquids (through direct contact or condensation).
Vibration and Shock

The Regent has been tested to international standard levels
for vibration (as shown in Table 37, above). When installing
the Regent, be careful to isolate it from any sources of extreme
vibration or mechanical shock.
Electromagnetic Interference and Electrostatic

Discharge
The Regent has been designed and tested to withstand normal
levels of conducted and radiated electromagnetic interference
and electrostatic discharge. To help control sources of EMI
and ESD in industrial installations the following
considerations should be taken into account.
Power Line Conditioning
To suppress transient conditions up to 2.5 kilovolt spikes on
input power lines, the Regent includes metal oxide varistor
(MOV), surge suppression devices, and LC filters on all input
power lines. While the Regent's power supplies are designed
to operate over a wide power tolerance range, care must be
taken to ensure that the quality of input power to the Regent
is maintained within the specified tolerance levels.
If the quality of power in your plant is not within the specified
tolerance levels, it may be necessary to employ external power
line conditioning equipment such as commercial line filters
and surge suppression devices.
Grounding
Grounding is important for providing a path for electrostatic
discharge and for safe conduction of current should a short
occur within the Regent system or its wiring. For these
reasons, it is particularly important that the safety ground
wires be attached on the input power terminals and properly
grounded to earth. In addition, ground terminal studs are
provided on each Regent chassis for grounding the Regent.
All internal Regent module assemblies and cable assemblies

(including I/O Safetybus cables and I/O power supply cables)

are designed and constructed to minimize the effects of
electrical noise coupling to withstand normal sources of
electromagnetic interference that are found in industrial
environments. Please note, however, that the quality of field
wiring to the I/O module field connector termination
connectors can greatly affect I/O signal quality and result in
effects on the overall performance of the system.
Wherever possible, all field wiring should be run in twisted
pair conductors and, on sensitive analog signals, shielding
with shield drain wire connection, as shown in Figure 157, is
also recommended. In addition, sensitive signal lines, such as
low voltage DC and analog signals, should be run in separate
conduits than high voltage AC signals that might otherwise
couple onto the lower voltage lines.
Figure 157. Shielding Sensitive Analog Signals.

The thermocouple serial cable, from the thermocouple
multiplex panel to the thermocouple input module, as well as
the thermocouple wires themselves, are all connected to
sensitive circuitry and do not meet the electromagnetic
interference rejection requirements (as shown in Table 37,
above). Thermocouple wire connections and the thermocouple
serial cable connections should be routed in special conduit
that is isolated from potential noise sources.

Power Supply Requirements

The Regent's power system provides triply redundant
internally regulated voltages to all of the logic circuits within
the Regent. The controller assembly power supply system is
separate from the I/O assembly power supply system.
Important! Because the inter-chassis communications signals are ground-
referenced, the two chassis must share a common ground
reference. To limit ground differentials between the chassis,
the ground reference points of the controller chassis and the
I/O chassis must be tied to the same electrical reference.
Figure 158 shows a block diagram of the Regent's power
system.

Figure 158. The Regent's Power System
Controller Assembly Power Supplies

Each processor module contains its own power supply. Each
power supply converts input power to the logic power levels
that are used by the internal processor circuits. The failure of

one power supply failure will only effect one processor module
— allowing the other two modules to continue operating —
thus keeping the Regent on-line by virtue of its majority two-
out-of-three voting architecture.
Three processor power supplies provide power to each of the
Regent's three communications modules. A power sharing
circuit on each of the communications modules receives the
power from the three processor modules and combines it
through a diode OR circuit. This ensures that if one power
supply fails, the communications module will continue
operating by drawing power from the two remaining power
supplies, and the system's communications functions will be
maintained.
I/O Power Supply System

One I/O power supply assembly can provide power for as
many as four fully-loaded I/O assemblies.
Each of the triply redundant I/O power supply modules within
the I/O power supply assembly provides power for one slice of
the three redundant slices of the I/O Safetybus transceivers,
and provides power to each of the I/O modules within its
associated I/O chassis. As with processor communications
modules, each I/O module contains a diode OR power-sharing
circuit that receives power from all three I/O power supply
modules. Should any I/O power supply module fail, only one
slice of the transceiver modules will lose power: the two
remaining slices will maintain proper operation of the Regent,
by virtue of the two-out-of-three majority voting architecture.
In addition, each I/O module will continue to operate properly
by drawing its current from the two remaining power supplies
within the I/O power supply assembly.
Using Multiple Input Power Sources

The Regent can be operated from one, two, or three separate,
independent primary power sources
The Regent can operate with either 24 VDC, 110 VAC, or 220
VAC primary I/O power sources (the 220 VAC configuration is
not certified to VDE 0110 for electrical safety). Each of these
three primary input power source configurations allows the

Regent to operate using either one, two, or three separate,

independent primary power sources.
Using Three Independent Input Power Sources
If three independent input power sources are available, each
power source can be independently wired to one set of primary
input power contacts on the controller assembly and the I/O
power supply assembly. With this configuration, a separate
primary input power source powers each of the triply
redundant power supplies in the controller and the I/O
assemblies. This configuration provides a high degree of fault
tolerance, since a failure of any one of the primary input
power sources would result in the loss power to only one of the
three processor power supplies and only one of the three I/O
power supplies. In this case, the Regent's two-out-of-three
majority voting circuitry will allow the system to continue
operating until primary input power on the failed slice can be
restored.

Figure 159 Using Three Independent Power Sources

Using Two Independent Input Power Sources
This approach employs a static switch that provides one of the
primary power sources for the Regent's input power under
normal circumstances. Should a fault occur in the primary
input power source, the static switch will automatically switch
to the back-up source. In this configuration, a fully tested,
fault-tolerant static switch is recommended (such as the ICS
AC Changeover Switch [p/n 698421]).
Figure 160 shows the recommended configuration for
operating with two independent input power sources.

Figure 160. Using Two Independent Power Sources.

Using a Single Input Power Source
To operate with a single input power source, the power source
should be tied to all three primary power input terminals on
both the processor module chassis and the I/O power supply
chassis. In this configuration, if the primary input power
source fails, the Regent will shut down. In this case, output
power for driving the output switches on all modules will be
lost; therefore, all loads will be de-energized. If the Regent
application is a properly designed de-energize to trip system,
this will result in a safe shutdown.

Figure 161. Using a Single Power Source.
Using an Uninterruptable Power Supply

The Regent has been designed to operate with most
commercially available industrial uninterruptable power
supply systems.
To select the proper uninterruptable power supply (UPS), the
overall system load, including the Regent control system and
any other devices that are to be powered by the UPS, should
be calculated. After calculating the actual load, a significant
margin should be added (a margin of 25 to 50 percent is
recommended) when specifying the UPS load capability.
Power System Isolation

All of the Regent's internal circuits must use the same
potential ground reference. To ensure that there is a uniform
potential ground reference, all of the chassis within the
Regent must be tied to the same ground reference point.

The input power terminals are isolated from the Regent's

internal circuitry by the primary transformer insulation,
specified to provide isolation up to 2,500 volts. All of the field
I/O circuitry is also isolated from the internal Regent logic
circuits by 2,500 volts of electrical isolation. Therefore, the
Regent can be connected to “floating” field power systems.
When connecting the Regent's communications module to an
external operator interface or a DCS system, two options are
available. The first option is to use a non-isolated
communications module (T3150 or T3151), requiring the
external equipment to be referenced to the same ground point
as the Regent. The second option is using a T3150A
communications module, which provides 1,000 volts of
electrical isolation, so that the external device may “float”
with respect to the Regent.
Requirements for Energize-to-Trip Applications

General requirements for programmable systems used in Risk
Class 5 safety-related applications where one or more inputs
are used in an energize-to-trip configuration require the
following conditions to be met:
1. At least two independent power sources must be used. The
power sources must provide emergency power for a safe
process shutdown.
2. Each power source must be provided with power integrity
monitoring with safety-critical input read back into the
Regent. Any power failure shall lead to an alarm. Note
that this is automatically provided when Monitored input
modules (T3411, T3411F, or T3418F) and Guarded output
modules (T3481, T3484, or T3488) are used.
3. All safety-critical inputs and outputs must be fitted with
external line and load integrity monitoring and safety-
critical read back of the line status signals. Any line or
load failure shall lead to an alarm. Note that this is
automatically provided when Monitored input modules
(T3411, T3411F, or T3418F) and Guarded output modules
(T3481, T3484, or T3488) are used.

Figure 162. Electrical Isolation Boundaries.

I/O Module Application

The Regent offers a wide range of input and output modules
to meet the safety needs of an equally wide range of
applications. All input and output modules are TÜV certified
as non-interfering; most modules, when properly configured,
are also certified for Risk Class 5.
Table 38. Input Configurations.
TÜV Certified
Configuration
Risk Class 5 Remarks
Digital Inputs
T3401, 24 VDC 2oo3 or De-energize to trip: Approved
T3402, 48 VDC 1oo2 only if the inputs are
T3404, 110 VAC dynamically transitioned at a
T3408, 120 VDC period not greater than the
second fault occurrence time.
Monitored Inputs
T3411, 24 VDC 2oo3 or Approved for de-energize to
T3411F, 24 VDC, 2oo2 trip.
field powered Energize to trip inputs must
T3418F, 120 include line monitor devices
VAC/VDC, field monitored at field switch.
powered
T3419, fire detector MooN Fire detector sensors should
be redundant or cross-zoned
and evaluated in the
application program using “M-
out-of-N” techniques
Analog Inputs
T3420A, standard Triplicated with Approved only if the inputs
T3420AF, fast Midvalue are dynamically ranged over
response Select or Dual full scale at a period not
T3431A, T/C with High/Low greater than the second fault
T3432, RTD Select occurrence time.
Other Inputs
T3491, Mux N/A Approved as non-interfering
and can be used for non-
safety-critical input devices.

Table 39. Output Configurations.

TÜV Certified
Configuration
Risk Class 5 Remarks
Guarded Digital Outputs
T3461A, 24 VDC Fail-Safe De-energize to trip:
T3462A, 48 VDC Single Module Approved.
T3468A, 120 VDC or Fault Energize to trip: Approved
Tolerant Dual only if the outputs are
Modules dynamically transitioned at a
period not greater than the
Monitored Guarded
Outputs
T3481A, 24 VDC Fail-Safe De-energize to trip: Approved
T3482A, 48 VDC Single Module Energize to trip: Approved.
T3488A, 120 VDC or Fault
Tolerant Dual
Modules
Isolated Guarded
Outputs
T3485, 24-120 Fail-Safe De-energize to trip:
VAC/VDC Single Module Approved.
or Fault Energize to trip: Approved
Tolerant Dual only if the outputs are
Modules dynamically transitioned at a
period not greater than the
Other Outputs
T3441A, 24 VDC N/A Approved as non-interfering
T3444, 100 VAC and can be used for non-
T3446H, Relay safety-critical output devices.
T3446L, Relay
T3454, 110 VAC,
Isolated
T3464, 110 VAC,
Guarded
T3470A, Analog
T3480, Guarded
Analog
T3491, Mux

Configuring I/O for Safety-Critical

Applications
To ensure continuous and safe operation, even in the presence
of internal faults, the Regent is designed with internal triple-
redundant architecture with majority two-out-of-three voting.
The Regent can be configured to extend varying levels of
redundancy into the system's I/O.
When interfacing the Regent to process equipment, many
decisions must be made regarding extending the fault
tolerance features to include process sensors and actuators.
These decisions allow the Regent to accommodate the
individual safety needs of a wide variety of process
applications.
The Regent system can support a wide variety of redundant
input configurations. In order to achieve safety in a solid
state electronic system, it is important that two key criteria be
met:
1. There should be no single, untestable point of failure that
could cause the system to fail to function safely when
required.
2. When using redundancy, the redundant elements also
must be fully testable, so that failures do not accumulate
and result in improper operation.
With this in mind, each process parameter that is sensed
by the Regent should be evaluated to determine:
a. How critical it is to the safety of the process.
b. Its potential failure modes and the probability of
occurrence of each failure mode.
c. The testability of the process sensors and actuators.
After evaluating these parameters, the proper architecture
and implementation scheme for that process I/O can be
selected. The following sections provide examples of I/O
architectures that can be used with the Regent for safety-
critical I/O, as well as some important notes about their
application.

For safety-critical applications, the Regent's I/O system can

support a wide variety of redundant and fault tolerant
configurations. These configurations include, but are not
limited to,
• Triplicated sensors with triplicated input circuits;
• Single sensors with triplicated input circuits;
• Dual sensors with dual input circuits;
• Single sensor with dual input circuits;
• Guarded output with a single actuator;
• Dual Guarded outputs with single actuator;
• Dual Guarded output circuits/dual actuator configurations.
For non-safety-critical applications, the Regent’s I/O
configurations can include,
• Single sensor with a single input circuit (TÜV not
recommended for safety);
• Single output with a single actuator (TÜV not
recommended for safety).
Safety-Critical Input Configurations

Single Sensor, Multiple Input Modules
The multiple input module configuration eliminates single
points of failure in the input module circuitry. However, the
sensor itself and a portion of the field wiring is still potentially
a single point of failure.
The single-sensor, multiple input module configuration can be
used for safety critical inputs. It is important that the failure
modes for the sensor must be predictable and well understood,
so there is little probability of the sensor failing so that it
would not respond to a critical process condition. In such a
configuration, it is important that the sensor be tested
frequently, either by dynamic process conditions that are
verified in the Regent or by manual intervention testing.

Figure 163 shows an example of how the Regent can be

configured to operate with a single sensor and multiple
(typically three) input modules.
Figure 163. Single Sensor and Multiple Input Modules.
Redundant Sensors with Redundant Input Modules

Redundant sensors can be used with redundant input modules
to eliminate any single points of failure and extend fault
tolerance to include the sensors.
In a multiple-sensor, multiple input module configuration the
sensors must sense similar process variables from
independent sensors. In this way, if any single sensor fails,
that failure can be differentiated from an out-of-tolerance
condition in the process itself.
Like configurations using a single sensor with multiple input
modules, this configuration can use any of the redundant
input configurations described above.
Figure 164 shows how each redundant sensor connects to one
of the input modules in the redundant configuration.

Figure 164. Redundant Sensors and Input Modules.
2oo3
Application: Triple Redundant Digital and Monitored
Digital Inputs
When using this architecture for digital input circuits, the
Regent's application software can be programmed using two-
out-of-three (2oo3) majority voting with input circuit testing.
The two-out-of-three control law states that at least two out of
the three input modules must indicate a fault condition for the
Regent to respond with a shutdown. Thus, a single input
module could fail and the Regent would continue to operate
safely.
To use this control law for safety critical inputs, it is
important that the input be tested regularly to detect if any of
the single element components on the input module have
failed, or if the sensor itself has failed and must be replaced.
The frequency of testing depends on the overall reliability of
the input sensor; however, each input should be tested at least
once every six months (see page 346, Input/Output Testing).
For this configuration and control law, the ladder logic voter
function should be used. This ladder logic element provides

both objectives of providing the control algorithm and

detecting which, if any, of the inputs is discrepant.
The voter element is used to vote triplicated inputs configured
for complete fault tolerance. This instruction performs a two-
out-of-three vote on the three input variables and stores the
result in a predefined location.
Figure 165. Voter Element.

Power flow to the first row of the box determines whether the
application is performed.
An error bit is latched when an input variable is not in
agreement with the other two input variables after a preset
time elapses. After the first error, the bit of the voted result is
on only if both the two remaining input variable bits are also
on, otherwise the bit is off.
In the first column of the box, above VOTEA, VOTEB, and
VOTEC, enter the three input variable names (these must all
be discrete or non-discrete variables).
In the second column of the box, above ERRORA, ERRORB, and
ERRORC, enter the three error bits (these must be discrete
variable names).
Above RESULT enter a name for the voted result (this must be
either a discrete or a non-discrete variable and must be of the
same type as the variable input).
Above MSEC enter a time delay preset (the time base is in
milliseconds). The default time delay preset is 0.
Above RESET enter a tag for the error reset bit (this must be a
discrete variable name). You may wish to use the tag VRESET,
which turns on after a voted reset.

2oo2
Application: Dual Redundant Monitored Digital Inputs
The Monitored digital input modules can be used in dual
configurations for fault tolerant inputs. These input modules
(T3411, T3411F and T3418F) are automatically tested for
their ability to sense both the on and off state of a connected
input. When the field sensor is fitted with an optional line
monitor device, the input modules can also detect open and
short circuit field wiring faults. When the automatic testing
on the input modules detects a module failure, the system
control relay fault bit associated with the I/O module slot
position is energized. Using this fault bit, you can implement
logic to normally vote the dual inputs 2oo2, and revert to 1oo2
when a module has failed. The failed module can be removed
and replaced while the remaining module continues to operate
and respond to any trip condition that may occur.
Use the logic in the following figure to implement 2oo2 voting
of Monitored digital input modules. This example assumes
that the inputs and output are normally energized, and de-
energize to trip.
Figure 166. 2oo2 Voting for Dual Monitored Digital Inputs.
1oo2
Application: Dual Redundant Digital Inputs
Digital inputs used in 1oo2 configurations are implemented
with the following ladder logic:
Figure 167. Duplicated Inputs.

This example assumes that the inputs and output are
normally energized, and de-energize to trip. In this example,

if either input changes state, the output will also change its
state.
The discrepancy detection is implemented as shown in the
following diagram.
Figure 168. Discrepancy Detection.

If A and B disagree, the discrepancy coil will be set for that
scan. A timer filter can be implemented to filter the
discrepancy coil, then set an alarm or otherwise report the
condition.
Midvalue Select
Application: Triple Redundant Analog, Thermocouple,
and RTD Inputs
The midvalue select control law states that the system will act
on the value of the analog input that has the middle, or
median, value. To use this control law for safety critical
inputs, it is important that the input be tested regularly to
detect whether any one of the single element components on
the input module has failed, or if the sensor itself has failed
and must be replaced. The frequency of testing depends on
the overall reliability of the input sensor, however each input
should be tested at least once every six months (see page 346,
Input/Output Testing).
To support midvalue select, the Regent’s ladder logic language
provides a midvalue element that can be used to automatically
compare three input tags and select the midvalue. This
element also compares the difference between the other two
inputs and the midvalue input, and can detect if either of
these exceed the permissible tolerance range. If either one is
out of range by more than the specified tolerance band, it will
set a control relay error flag that should then be used to warn
an operator to perform a maintenance operation (i.e. check or
replace the erroneous module).

Figure 169. The Midvalue Element

For more information on the midvalue element, please see
Using the Ladder Logic Editor in Section 5, Working with
Programs and Function Blocks.
Midvalue Limit Considerations
The allowable tolerances between any two analog input
modules is a function of the slew rate of the input signal. If
the input signal is a step-function, the modules may disagree
by the amount of the step for up to one scan.
For the T3420A module, if the signal is constant (that is, if the
slew rate is less than ±4% of full scale per second) the
maximum variance between any two analog inputs will be ±5
counts.
For the T3420AF module, if the signal slew rate is less than
±6,000% of full scale per second the maximum variance
between any two analog inputs will be ±5 counts.
If the analog input occasionally transitions faster than the
rates stated above, the comparison of the inputs may be
varying by more than the amount stated during the transition
period. If this is the case, a ladder logic timer can be
programmed to filter the comparison error flag. This scheme
is not recommended for signals that continuously vary at rates
faster than the slew rates stated above.
Safety-Critical Outputs
Guarded outputs are used safety-critical applications.
Guarded output modules have the following characteristics:

Fail-Safe Configurations
Redundant circuitry ensures that if a failure occurs in the
module, the module will either continue to operate properly
and notify the Regent that it has sustained a failure and must
be replaced, or it will fail to an open high impedance state,
thus removing power from the output device it is driving.
Figure 170 shows a block diagram of a single fail-safe Guarded
digital output module configuration.
Figure 170. Fail-Safe Guarded Output Module.
Fault Tolerant Configurations

Two Guarded output modules may be wired in parallel to
control the same output. This configuration ensures that if
one module fails it can be replaced while the other module
continues proper control, thus never interrupting the process.
Figure 171 and 172 show block diagrams of fault tolerant
configurations using two Guarded output modules for single
and redundant actuators.

Figure 171. Fault Tolerant Guarded Output Modules.
Figure 172. Fault Tolerant Guarded Output Modules and

Redundant Actuators.
Maintenance and Repair Requirements

When properly configured and installed, the Regent is
designed to operate continuously and correctly even if one of
its modules should fail. When a module does fail, it must be
promptly replaced to ensure that faults do not accumulate,
causing multiple failure conditions that could cause the
Regent to operate improperly.

Because the safety integrity of the system is reduced

proportionately to the time it takes to replace failed modules,
failed modules must be replaced as promptly as possible. Only
by promptly replacing failed modules is it possible to ensure
predictable and continuous operation of the Regent.
Failed modules should be replaced as promptly as possible.
Modules that have been diagnosed as having failed should
always be replaced within eight hours.
Caution! Under no circumstances should a Regent used for safety-
critical functions be allowed to operate for extended periods
with a failed module.
Periodic Testing Requirements

The Regent contains some circuits that are not fully tested
during normal system operation. To ensure continuous and
predictable operation, it is important to periodically test these
circuits. These circuits fall into the following categories:
1. Indicator circuits (self-revealing);
2. Shutdown/hold circuits (on standard output modules only);
3. Processor recovery circuits;
4. Power fail circuits.
While these circuits are not required for fault tolerant
operation, undetected failures in these circuits can result in
longer repair times due to failed indicators, failure of output
shutdown upon loss of processor module communications (on
standard outputs only), the inability to recover a failed
processor module, or the loss of memory during a warm-start.
These potential failures can be avoided through periodic
testing of the Regent. It is recommended that the system be
taken off-line and the Faulted Status Check, described in
Section 2, be executed on a yearly basis. If the application
does not permit a yearly shutdown of the equipment, periodic
testing should be conducted at convenient intervals whenever
possible.

Input/Output Testing
In performing sensor and input module testing to meet the
requirements for the single-sensor, multiple input module and
multiple-sensor, multiple input module configurations, it is
important to have a test scheme that fully and dynamically
exercises the input circuitry of the module as well as the
sensor.
For digital input modules, it is important to test both the
sensor and input modules to verify that they all respond
correctly to both of the binary states that the process variable
can assume.
For analog input modules, it is important that the sensor be
operated over the entire dynamic range that is required by the
process and that the input circuitry be exercised over this
range to ensure that it responds correctly.
Guarded DC output modules are automatically tested to
ensure their ability to de-energize to trip; however, they must
be exercised and verified in both binary states to ensure
operability for energize to trip.
Such testing may be implemented either automatically or
manually, or by using some combination of both automatic or
manual, provided that the testing includes the application of
the proper stimulus condition and a verification of the
Regent's response. This is often accomplished by including
bypass switches on other inputs that can be applied, allowing
the input being tested to be logically bypassed while the actual
input sensor and signal path of the parameter being tested are
exercised throughout their entire dynamic range. Test results
can be verified visually by monitoring the Regent's response
(see page 348, Using Software Overrides).
Application Software Requirements

WINTERPRET offers many application language programming
tools to develop control algorithms to meet the needs of
virtually any real-time process control application.
The configuration and programming languages approved for
use in Risk Class 5 safety-related applications are shown in

Table . In addition, the software validation package (catalog

number T3835) must be used to verify the compilation and
loading of application programs and Guarded Peer-Link
communications configurations.
WINTERPRET’s version control and source comparison tools
are recommended to assist you in managing the development
of, and modifications to, the system’s application programs
and configuration. These tools should be used in addition to
other general practices that the user employs for configuration
management of safety-critical systems. Refer to Version
Tracking in Section 6 for more information about these tools.
Table 40. Approved Configuration and Programming
Languages.
Type Approval
Ladder logic TÜV approved for safety.
Analog scaling
Guarded Peer-Link
Floating point math TÜV approved, non-
Sequence of events interfering.
Process historian
Continuous control Not approved.
Section 5 provides additional information on ladder logic

function blocks and analog scaling function blocks.
For information about using other types of function blocks,
Guarded Peer-Link communications, and the software
validation package, please refer to the product description for
that particular add-in package.
Internal Watchdog Timers

The Regent includes three levels of internal watchdog timers
to detect and protect against potentially dangerous (fail-to-
function) system errors:
1. The controller assembly contains the TRIOS software
watchdog timer that times out if the application software
should hang or loop too long,
2. A Regent hardware watchdog timer that will time out if
TRIOS would hang or loop too long,
3. Each I/O module also contains at least one independent
hardware watchdog timer.

The maximum allowable loop time for the watchdog timers is

195 milliseconds for 128K processors and 395 milliseconds for
512K processors. If the software watchdog times out, the
system will transition into the time-out state and place
outputs in the shutdown state and wait to be re-started (see
Section 7, for more information about system states). If the
hardware watchdog times out, the Regent will cold-start and
set all outputs to the shutdown state.
Each I/O module also contains at least one independent
hardware watchdog timer that times out if, for any reason,
two or more communications channels are lost between the
I/O module and the controller assembly (this could occur due
to a complete failure of the controller assembly, loss of two or
more I/O Safetybus cables or complete loss of non-redundant
power to the controller assembly).
Using Software Overrides

The Regent offers programming features for implementing
software overrides and bypasses.
Forcing The forcing utility is provided only as a test and integration
tool and is not to be used as an on-line bypass mechanism
during normal, safe operation of the Regent (safe operation
must be guaranteed by appropriate maintenance procedures to
be defined by the operating company). For added protection,
the forcing function is limited to one logical point. In the
Regent system this may include up to three separate forced
input tags to allow forcing of triplicated inputs (the triple
forcing feature should only be used to force a set of triplicated
inputs or dual outputs).
Section 7 covers the use of WINTERPRET’s forcing function
that allows on-line forcing of input/output and internal
variables within the Regent.
If, during normal operation of the Regent, it will be necessary
to provide bypassing of input or output points or internal
variables for testing or other logic functions, such
functionality should be included in the application program.
The bypass switch is simply run into a separate input in the
Regent and the bypass function is implemented in ladder

logic. This is one example of a possible implementation of

software bypasses.
Another suggested implementation would use the same ladder
logic implementation, but down-load the bypass information
from a DCS or operator terminal (as opposed to using bypass
switches wired to input modules). When doing this, it is
important that the download data scheme be implemented in
the application program according to the guidelines
established in Regent Application Requirements (page 351),
and Maintenance Override (page 353).
Figure 173 shows a typical input switch and bypass switch
that has been implemented to allow the input to be bypassed
for testing.
Figure 173. Typical Implementation of an Input Bypass

Switch.
Figure 174 shows the bypass function implemented in ladder
logic.

Figure 174. Bypass Function Implemented in Ladder Logic.
Protecting External Communications

The Regent is capable of communicating with various types of
external devices, including distributed control systems (DCSs),
operator interface terminals, etc. Three communications
protocols are supported by the Regent: the Regent command
protocol, ASCII, and Modbus (via the Modbus translator in
Regent versions prior 3.0). Port 1 must use the Regent’s
command protocol; however, the remaining serial ports may
be configured to handle any of these protocols (see the Project
Editor’s Serial Ports command in Section 4, Working with
Projects).
Read-only operations using Regent command 120 (return
data) or Modbus commands
01 (read coil status)
02 (read input status)
03 (read holding registers)
04 (read input registers)
are permissible without further qualification in safety-related
applications, provided the host system (such as a DCS) is a
well-designed, reliable system that is not capable of issuing
incorrect commands and inadvertently corrupting the
Regent's application data.
If the host system is intended to perform on-line writing of
data to the Regent, special care must be taken to protect
against inadvertent corruption of the Regent's application
data.
Important! Standards for safe operation of programmable electronics
systems are currently being developed by several standards
bodies. It is possible that one or all of these standards may

greatly restrict, or even disallow, the use of on-line data

writing from a source that is less reliable than the target
system.
If on-line data writing is to be performed, the method
explained in the following section, or another method that
provides an equivalent degree of protection, should be used.
The method described in Maintenance Overrides, or a similar
method providing an equivalent degree of protection, is
required to maintain TÜV Risk Class 5 certification.
Regent Application Requirements

All safety-related variables that are to be written should be
configured as comm protected, and an equivalent size non-
protected “image space” should be configured. The external
data should write values into the non-protected “image space.”
The “image space” should be of equal size and data type (ie
control relays or registers) to the total number of application
variables to be written. This will allow a one-to-one mapping
of the safety-related variables and the “image” variables to be
written. In this way, the “image” variables can be written
from an external device and checked prior to being transferred
(by the application program) from the “image” variable space
to the safety-related variables used in safety interlock logic.
The “image” variable area should include one additional
status coil, or messenger, for each program that has “image”
variables to be written. This messenger is set by the external
source device after it has confirmed proper downloading of
data (see page 352, Host [Data Source] Application
Requirements).
At the beginning of each program containing safety-related
data to be written, the ladder logic must contain a test of the
messenger variable corresponding to that program. If the
messenger variable is set, the data in the “image” variables for
that program can be transferred to the safety-related data area
(using block move or assign elements) and used. The
application program should perform a set of tests to ensure
that the “image” data is valid before transferring it into the
safety-related variables. This set of tests will be application-
dependent, but may include:

1. Boundary testing to ensure the data is within expected

range (register type data).
2. Rate testing to insure that the data does not vary beyond
acceptable limits with respect to previous values.
3. Quantity testing in the case of bypass overrides to test that
no more than the allowable quantity of overrides are
performed at once.
The external host should be configured to read the safety-
related variables, to close the loop to operators and other plant
personnel. In this way plant personnel are always aware of
the actual safety-related variables in use, an not just the
loaded “image” variables, which may be rejected by the testing
and validation logic that transfers the “image” variables to the
safety-related variables.
Host (Data Source) Application Requirements

The source of downloaded data must perform the following:
Read the messenger register associated with the data to be
downloaded. If the messenger register is reset, then proceed;
otherwise wait.
Once a program has cleared the messenger register, the host
can then download the data associated with that program.
Downloading data can be done using either the Regent
command 119 (set data) or the following Modbus commands:
05 (force single coil)
06 (preset single register)
15 (force multiple coils)
16 (preset multiple registers)
Using one of these commands, data is transferred to the
shared variable registers that are images of the destination
local variables.
After downloading is completed, the host must then read back
the data that was just written. This can be done using either
the Regent command 120 (return data) or Modbus commands
01 (read coil status)
03 (read holding registers)

The host must next verify that the data sent was the same as
the data that was read back.
If the data sent was the same as the data read back, the host
must send a command to set the messenger register associated
with that data. This can be done using either the Regent
command 119 (set data) or the following Modbus commands:
05 (force single coil)
06 (preset single register)
This completes the data transfer from the host.
Maintenance Override
“Maintenance override” means to set inputs or outputs to a
definite state which can be different from the real state during
safety operations. It is used, as its name implies, for the
purpose of maintenance — usually to override an input or
output condition in order to perform a periodic test,
calibration, or repair of a sensor or actuator.
To properly implement a maintenance scheme that
accommodates maintenance overrides within the Regent
controller, the override, or “bypass,” logic must be
programmed into the application program with a separate set
of safety-related input points or internal variables designated
for enabling the bypass logic. In order to accommodate
maintenance overrides safely, TÜV has documented a set of
principles that must be followed. These principles are
published in the document “Maintenance Override” of TÜV
Bavaria and TÜV Rheinland.
There are basically two methods now used to check safety-
related peripherals connected to Regent,
1. Special switches connected to inputs on the Regent. These
inputs are used to deactivate sensors and actuators during
maintenance. The maintenance condition is handled as
part of the Regent's application program.
2. Sensors and actuators are electrically switched off during
maintenance and are checked manually.
In some installations (for example, where space is limited), the
maintenance console may be integrated with the operator
display, or maintenance may be covered by other strategies.

In such installations, there is a third alternative for the

maintenance override:
3. Maintenance overrides caused by serial communications to
the Regent.
Serial communications to the Regent must be handled with
care, and can be done in either of two ways:
A) The serial link is made via Modbus protocol or other
approved serial protocols. Plant operations personnel
are responsible for writing the safety related data from
an external host (DCS or MMI).
B) The PC running WINTERPRET is connected to the
Regent to perform the maintenance override. The user
must log on to WINTERPRET using a classification that
is configured without any programming access rights.
Using such a classification provides additional safety
measures to prevent a program change during
maintenance intervals.
The following table shows common requirements. The
differences between solutions A and B are shown in italics.

Table 41. Maintenance Override Requirements.

Requirements Responsibility
During software configuration, Project engineer and commissioner

determine (in a table or application responsible for correct configuration
program) whether overriding the
signal is allowed.
The configuration may also specify A: Project engineer

(in a table) whether simultaneous B: Project engineer, Type approval
overriding in independent parts of
the application is acceptable.
Maintenance overrides are enabled A: Operator or maintenance engineer

for the whole Regent system or a B: Type approval
subsystem by the DCS or a key
switch.
A: The override is activated via A: Operator, maintenance engineer

DCS.
B: The maintenance engineer B: Type approval, maintenance engineer
activates the override via the
programming environment.
Note: As an organizational
measure, the operator should
confirm the override condition.
Multiple overrides of inputs and A: Project engineer

outputs are allowed as long as only B: Project engineer, Type approval
one override is used in a given
safety-related group (process unit).
The Regent alerts the operator and Project engineer, commissioner

indicates the override condition.
The operator will be warned when
the override is removed.
A: The override is removed via A: Operator, maintenance engineer

DCS.
B: The maintenance engineer B: Maintenance engineer
removes the override via the
programming environment.
A: There should be a second way A: Project engineer

to remove the maintenance
override condition.
B: If urgent, the maintenance B: Maintenance engineer, Type approval
engineer can remove the override
using the keyswitch.
The time span for overriding shall Project engineer, commissioner, DCS
be limited to one shift (typically no program, Regent program
longer than eight hours).

The following recommendations are provided to improve the

primary safety of the requirements described in Table 41.
1. The maintenance override shall be documented on the DCS
and in the programming environment if connected. The
printout should include a beginning and ending time
stamp, the ID of the maintenance engineer or operator
activating the override, and the tag name of the signal
being overridden.
2. The communications packages should include CRC,
address checking, and checking of the communications
time-frame.
3. Lost communications should lead to a warning to the
operator and the maintenance engineer, and to a (delayed)
removal of the override.

Section 9
Troubleshooting
The Regent control system is designed to provide continuous,
uninterrupted real-time process control. To achieve this goal,
maintenance actions are required from time to time to replace
faulty modules and keep the system “whole.” For the most
part, maintenance is straightforward — faulty modules are
automatically identified by the system, and maintenance
operators simply replace the failed module with a new one,
reset the fault indicators, and return the failed module to ICS
for repair. In certain very rare instances some slightly more
involved troubleshooting is required.
Important! Please note that fault tolerant systems are designed to
continue to operate properly in the presence of any single
fault; multiple faults can cause the system to fail — although
the Regent is designed to fail to a safe state. Any time the
system is operating with one or more failed modules still
installed, it is vulnerable to subsequent failures that could
cause a shutdown (even though the system is still controlling
the process correctly with the failed module installed). For
this reason, it is important to replace failed modules soon after
they fail — the sooner failed modules are replaced, the higher
the reliability of the system will be.
Other than occasionally replacing failed modules, two types of
periodic maintenance are recommended,
1. Yearly calibration of all analog modules;
2. Periodic system reverification.
The procedures for calibrating analog modules are provided as
part of each module's product description.
For information on additional maintenance needed to meet
TÜV Risk Class 5 requirements, please see Section 8, Safety
Considerations.

Maintenance
The Regent is designed to need very little maintenance;
however, it is anticipated that some periodic testing and
calibration will be needed to ensure that the system will
continue to operate as specified. In addition, certain parts
(such as batteries and fuses) can reasonably be expected to
need occasional replacement.
Procedures for periodic testing, calibration, and fuse
replacement can be found in the product descriptions for each
module.
Troubleshooting
The Regent is capable of detecting and isolating faults to the
module level, while its two-out-of-three voting architecture
prevents faults from propagating to the system outputs.
Various means are provided for directing maintenance
personnel to the faulty module. All system modules are hot-
replaceable, providing continuous system operation.
The following sections describe how faults are detected,
annunciated, and cleared in the Regent. They also describe
some of the basic procedures that you should follow when
troubleshooting and repairing the Regent.
Important! System repair must be done promptly to ensure continued
fault-tolerant operation of the Regent system.
Fault Detection
There are four levels of fault detection used in the Regent:
1. Discrepancy logic in each processor module compares the
output data on each bus cycle. A fault is recorded anytime
the data disagrees with the other two modules.
2. Loopback logic on communications modules, I/O
transceiver modules, and I/O modules, is exercised by the
processor modules on a background basis to detect output
data faults.
3. Self-test circuitry on Guarded output modules is used to
extend the detection boundary out to the screw terminals.

Troubleshooting Section 9
Also, power supplies contain circuits for checking their

output voltages.
4. Voter and mid value elements in function blocks detect
discrepancies on signals received from input modules.
The processor modules are responsible for sorting out the
fault information received from the various levels and alerting
the operator when system repair is required. Faults are
categorized as transient or permanent based on the rate at
which they occur. A separate filtering algorithm is applied to
each fault type, preventing nuisance alarms from occurring on
a transient fault. Figure 175 illustrates how this filtering
algorithm works.
Latched Until Reset
Permanent
Permanent Error Threshold
Transient
Transient
Transient Transient
Transient Reset
Test Cycle
Figure 175. Fault Filtering.

The system checks its fault status on a cyclic basis and if a
fault was detected during that cycle, it increments a fault
counter and records a transient fault. If a fault was not
detected, then the counter is decremented. If the counter
value exceeds a threshold, then a permanent fault is recorded
and the counter state is held until the operator executes a
reset. While in the permanent state, the operator is alerted to
the failure by various system annunciators. If the counter
value does not reach the threshold, a transient reset is
recorded as the counter returns to zero. The Regent allows
approximately four faults in succession before a permanent
fault is recorded. If a fault is detected on a processor module,
then a recovery process is automatically initiated to
resynchronize the module and update its memory. If the

recovery process fails after the fourth try no further attempts

are made and the fault is annunciated.
Fault Annunciation
The Regent has several different ways of annunciating faults.
These include,
• Fault contact closure;
• Module status indicators (LEDs);
• WINTERPRET's Fault Status Viewer and Fault History
dialog box;
• ASCII messages.
Fault Contact Closure
Each processor module contains a fault relay that changes
state when a permanent fault is detected anywhere in the
system. The fault relay has a set of form-c contacts that can
be wired to a discrete alarm device. The terminations for the
fault contacts are located on the controller assembly chassis,
directly beneath each processor module. The layout of the
fault contacts is shown in Figure 176.
Fault Contacts Fault Contacts Fault Contacts

(Class II connections only) (Class II connections only) (Class II connections only)
Figure 176. Fault Contact Layout.

Each processor acts on voted fault information to energize or
de-energize the fault contacts. All three fault contacts will be
in the same state unless a fault occurs in one of the processor
modules, then its contact position may be discrepant with the
other two. The contacts would normally be wired in a series
or parallel arrangement for redundancy. Table 42 presents a
truth table for the fault contact.

Table 42. Fault Contact Truth Table.

Processor Module State
Power On
Module
Power Off No Fault Fault Removed
N.O. Contact 0 1 0 0
N.C. Contact 1 0 1 0
0 = Contact is open.
1 = Contact is closed.
Module Status Indicator Lights (LEDs)

Important! A fault indication does not necessarily mean that a module is
not operational. Some faults within a module have no
immediate consequence. The failure can be masked or it can
be located in the test circuitry. Nevertheless, the module
should be repaired or replaced.
Most module faults, with the exception of the I/O power
supplies, are indicated with a red-green LED pair.
On the processor modules, the PROC light is red when a
processor module is faulty. The COMM and I/O indicators are
red when a fault is detected on one of the communications
modules or somewhere in the I/O system. If only one COMM
light is red then one of the triplicated data paths on a
communications module is faulty, whereas, if all COMM
indicators are red, the fault is more general and affects all
three data paths on a communications module. If only one I/O
light is red then an I/O transceiver associated with that
processor module is faulty, whereas, if all I/O indicators are
red, the fault is associated with an I/O module.
Each communications module has a COMM light pair that is
normally green when the module is operating correctly and
red when the processor modules have determined that the
module is faulty.
Each I/O transceiver has an ACTIVE-FAULT indicator pair that
is red when the processor modules have determined that the
module is faulty or when a data time-out occurs on the I/O
cable. Note that a failed processor module will cause all I/O
transceivers in the associated cable section to have red fault
indications.

Each I/O module has an ACTIVE-FAULT indicator pair that is

normally green when the module is operating correctly and
red when the processor modules have determined that the
module is faulty or when a data time-out occurs on two or
more of the triplicated data paths. Note that removing two
I/O transceivers will cause all I/O modules in that chassis to
have red fault indications.
Each I/O power supply has a single POWER indicator that is
normally green whenever the input and output voltages are
within tolerance. Note that removing an I/O power supply
will turn-off the indicators on up to four I/O transceivers that
are driven by that supply.
Additional indicators are used to report the status of specific
circuits within the modules, such as fuses, batteries, power
supplies, memory lock keyswitches, etc.
For more information about troubleshooting with fault
indicators see page 366, Troubleshooting with the Fault
Indicators.
WINTERPRET
The Regent memory contains fault status information for
every system module (except I/O power supplies). It also
contains a fault history log that records up to 80 transient
fault events and 80 permanent fault events. WINTERPRET can
request this data for use on its fault displays.
The fault data are presented in the following formats:
• Fault Status dialog box (a map of Regent modules showing
their current status - no fault, transient fault, or
permanent fault);
• Fault History Viewer (a continuous disk log containing all
the fault events that were recorded by the Regent. This
data can also be printed).
ASCII Messages
The Regent can be programmed to annunciate faults using
pre-stored ASCII messages. This provides a customized user
friendly interface to Regent status information. The ASCII
messages can be directed to a printer, message display, or
numerous other devices.

Clearing Faults
The Regent's faults are cleared by pressing the reset buttons
on the processor modules or by pressing the reset function key
from one of the WINTERPRET screens. The reset buttons must
be pressed on at least two working processor modules before it
will be acted upon. As each button is pressed, the PROC,
COMM, and I/O indicators are disabled (off) to indicate that the
button was pressed. When the reset operation is completed by
the processors, these indicators are re-enabled to indicate the
completion.
The following events take place during the reset cycle:
1. The three processors re-synchronize their machine cycles.
This allows a new processor module to be “educated” and
then synchronized with the other two modules. Note that
the RUN light immediately starts blinking on the new
module, indicating that it is executing in lock-step with its
neighbors.
2. A recovery task is started that re-votes the entire memory
on a background basis. At the conclusion of the task, all
processors will contain the same data in their memory.
3. All non-intelligent communications modules are re-
initialized and tested (serial port loopback).
4. All internal fault status information, all fault status
indicators, and all fault contacts are cleared to a “no fault”
state.
5. The PROC, COMM, and I/O indicators on the processor
modules are re-enabled to indicate that the reset operation
is complete.
During the reset operation, all application programs continue
to run at their normal scan rate. There is no noticeable
change in system performance and no additional vulnerability
to faults. There will, however, be an interruption to
WINTERPRET communications on non-intelligent
communications modules.
The time required to complete the reset is directly related to
the processor scan time. For example, a scan time of 100 msec
will result in a reset time of approximately one minute.

The reset function can also be invoked from WINTERPRET. It

will operate exactly the same but there will be no disabling of
the PROC, COMM, and I/O indicators.
The Regent can also invoke the reset operation automatically
as it tries to clear transient faults within the processor
modules. If after four reset attempts the fault is still present,
then that module is shut down and no further attempts are
made. Note that if a healthy processor module is removed and
immediately re-inserted , an automatic reset will return it to
normal operation without you having to press the reset
buttons.
The reset buttons will not be recognized while an automatic
recovery is in process.
Troubleshooting Techniques
Troubleshooting should always start at the processor modules
since they contain the first level of information regarding the
operational status of the Regent. The proper order for
viewing system status indicators is shown in Figure 177.
Processor Modules
POWER Primary Power Faults
PROC
COMM Communications Module Faults
I/O COMM
RUN TX/RX
BATT OK
MEMLK
I/O Power Supplies

POWER Primary Power Faults
I/O Transceivers
ACTIVE/FAULT
I/O Modules
SHUTDOWN
BLOWN FUSE
ACTIVE/FAULT
Field Terminations
Figure 177. Status Indicator Viewing Order

After scanning the Regent's fault indicators to locate the
affected modules, it is good practice to examine modules and

connectors for proper seating, then do a reset to determine if

the fault is permanent.
If the fault persists then module replacement is usually the
next action to take. Transient faults should be examined
using WINTERPRET’s history screen to determine the
frequency of occurrence and whether any corrective action is
warranted.
Regent troubleshooting is described in more detail in the
following sections. Before proceeding, please note the
following cautions.
Caution! Do not remove more than one module at a time unless a
system shutdown is planned. Removing any of the following
module combinations removals will cause a complete or partial
shutdown of the system:
• Two processor modules;
• Two power supply modules in the same chassis;
• Two I/O transceiver modules in the same chassis;
• Two I/O Safetybus cables in different paths;
• Two input or output modules in a fault-tolerant
configuration.
The following actions will also cause a complete or partial
shutdown of the system:
• Disconnecting an I/O power cable;
• Removing the wrong module or cable in a failed set.
Always do a reset after replacing a module. Wait for the reset
task to complete (PROC, COMM, and I/O indicators are re-
enabled) before proceeding with troubleshooting.
When removing a module from an I/O assembly, always be
careful to ensure that neighboring modules are not
accidentally unlatched.
When removing a processor or communications module, make
sure that the retaining screw is backed out before moving the
release levers.

Troubleshooting with the Fault Indicators

This section describes how to use the Regent's status
indicators to locate and repair faulty modules, components, or
cables.
Begin by examining each possible fault condition, in the order
in which they are listed, until one of the conditions is met.
When the conditions match your fault, use the procedure
associated with that fault condition to correct the fault. A
possible cause is listed for each fault to help you better
understand the procedures. Some of the procedures involve
checking for installation errors and may not be possible if the
system has been in operation for some time. Still, it may be
useful to re-check some of these items.
Processor Module Faults
Begin by examining the processor modules' status indicators
in the order shown below.
All Indicators are off for two or more processor modules
Probable Cause:
• Two or more primary power circuits have failed.
Procedure:
• Proceed to Primary Power Faults on page 373.
All indicators are off for one processor module
Probable Causes:
• The processor power supply detected an overvoltage and
shut itself down. This sometimes happens when the
module is inserted.
• One primary power circuit has failed.
• The processor power supply has failed.
Procedure:
• Remove the processor module and re-insert (this will reset
the power supply crowbar circuit). If the POWER light is
on, reset to return the processor module to normal
operation, otherwise proceed to Primary Power Faults on
page 373.

POWER lights are off for two or more processor modules
Probable Cause:
• Two or more primary power circuits are out of tolerance
(brownout).
Procedure:
Power light is off on one processor module
Probable Causes:
• One primary power circuit is out of tolerance (brownout).
• The processor power supply has detected an undervoltage
condition in one of its outputs.
Procedure:
PROC, COMM, and I/O lights are all off for one processor module
Probable Causes:
• The reset button on that module (and only that module)
has recently been pressed.
Procedure:
• Press the reset buttons on the on that module and one
other module (this does a voted reset).
PROC, COMM, and I/O lights are all off for two or more processor modules
Probable Causes:
• The reset buttons were recently pressed on two or more
modules.
• One or more processor modules are not fully seated.
• One or more processor modules has failed.
Procedure:
• Wait for the reset operation to complete (this can take
several minutes for long scan times). Verify that all
modules are fully seated. If the indicators are still off, but
only on two modules, then press the reset button on the
third module and wait again. If the second procedure was
successful, then the reset circuit on one of the modules is

faulty. To find the faulty module, press the reset buttons

two at a time (three possible combinations) to find out
which pair is working, then replace the other module. If
all combinations fail, replace each processor module, one at
a time, until operation returns to normal.
Both the red and green lights are on for any red-green light pair
Probable Cause:
• The indicator circuit is faulty.
Procedure:
• Replace the associated processor module.
PROC light is red for two or more processor modules
Probable Causes:
• Two or more processor modules are not fully seated.
• Two or more processor modules have failed.
Procedure:
• Verify that all modules are fully seated. Reset the system.
If the indicators are still red, replace each module one at a
time until operation returns to normal.
PROC light is red for one processor module
Probable Causes:
• The processor module software version is not the same as
the other two modules.
• The processor module is not fully seated.
• The processor module had a transient fault.
• The processor module has failed.
• The I/O Safetybus is stuck due to a faulty I/O transceiver,
I/O cable, I/O assembly backplane, or terminator plug.
• The controller assembly Safetybus is stuck due to a faulty
communications module, a fault in one of the remaining
processor modules, or controller assembly backplane.
Procedure:
• If this module is being used for the first time, check the
EPROM version number printed on the side label and make
sure that it agrees with the other two modules. Verify that

the module is fully seated. Reset the system. If the light is

still red, replace the module.
• If this module was previously running without faults, reset
the system. If the light is now green then there may have
been a transient error. It is a good idea to check the fault
history using WINTERPRET. If the transient has occurred
often then the module should be replaced. If the light is
still red, re-seat the module and do another reset. If the
light is still red, replace the module.
• If module replacement does not work, the fault may be in
the I/O Safetybus. Temporarily disconnect the associated
I/O cable at the controller assembly. If this clears the
problem then one of the I/O transceivers may be faulty.
Re-connect the cable and remove each I/O transceiver
associated with that cable, one at a time, to locate the
faulty module. If removing I/O transceivers has no effect,
there may be a short in one of the I/O cables or I/O
assembly backplanes. This type of problem can be isolated
by temporarily disconnecting one end of an I/O cable
starting at the entry to the first I/O assembly and ending
at the terminator plugs. If removing the entry cable to the
next I/O assembly does not clear the fault, the preceding
cable section may have a short, whereas, if removing the
exit cable from the next I/O assembly does not clear the
fault, the preceding I/O assembly may have a backplane
short. If removing the terminator plug clears the fault,
replace the terminator plug. This procedure must be done
in exact wiring sequence or the conclusion will be
incorrect.
• If disconnecting the I/O cable at the controller assembly
had no effect, the fault may be in one of the
communications modules. Remove each communications
module, one at a time, to locate the faulty module.
• If removing the communications modules does not clear
the fault, the fault could be in one of the remaining
processor modules. This will require a system shutdown to
verify. Remove and replace the processor modules one at a
time until the fault has cleared.
• If replacing the remaining processor modules does not
clear the fault, the controller assembly backplane may be
faulty.

COMM light is red for any processor module
Probable Cause:
• Communications fault.
Procedure:
• Proceed to Communications Module Faults on page 375.
I/O light is red for one or more processor modules and RUN lights are
normal (blinking)
Probable Causes:
• Outputs are not started.
• I/O system fault
Procedure:
• Start outputs using WINTERPRET, otherwise proceed to I/O
System Faults, on page 378.
I/O lights are red for two or more processor modules and RUN lights are
on continuously for two or more processor modules
Probable Cause:
• Program scan time is excessive (128K system: scan time
greater than 200 msec; 512K system: scan time greater
than 400 msec). All programs are stopped and output
scanning is halted.
Procedure:
• Troubleshoot the application programs (possible infinite
loop).
RUN lights are off continuously for two or more processor modules
Probable Causes:
• The operating system has not been downloaded from
WINTERPRET (initial system start up only).
• A low-battery condition caused loss of memory when
primary power went down.
• Two or more processor modules were removed while
primary power was valid.
• One or more processor modules are faulty.
Procedure:

• If this is the initial system start up, or if two or more

processor modules were removed while primary power was
valid, load the RAMcode using WINTERPRET. If any of the
BATT OK lights remain off, skip to BATT OK light is off on
one or more processor modules, below.
• If all BATT OK lights are on, one or more of the processor
modules may have a fault. To isolate the problem,
transition primary power using four different module
combinations – three modules present, and any one module
removed. Reload the RAMcode before each power-down
transition and observe the RUN light after each power-up
transition. Replace any processor module that fails in two
or more combinations (failures being when the RUN light
remains off).
RUN light is off continuously for one processor module
Probable Cause:
• The RUN light circuit has failed.
Procedure:
• Replace the associated processor module.
BATT OK light is off for one or more processor modules
Probable Causes:
• Battery is missing or not connected.
• Battery voltage is low (less than 2.5 volts).
• Processor module is faulty (bad detector circuit or
excessive battery current drain).
Procedure:
• Remove each faulted processor module one at a time.
Check for a missing, unconnected, or incorrectly connected
battery. Measure the in-circuit battery voltage with a
DVM. If the voltage is less than 2.5 volts, replace the
battery (refer to the processor module product description
for complete instructions on replacing the batteries);
otherwise the detector circuit is faulty and the processor
module should be replaced. After replacing the battery, the
current drain should be checked as follows. With the
battery completely installed, use a DVM to measure the
voltage across resistor R3 (100 ohms) on the processor

module display board. If the voltage exceeds 20 mV, the

leakage is excessive and the processor module should be
replaced.
The memory lock keyswitch has no effect on the MEMLK light
Probable Causes:
• Keyswitch or indicator failure.
• Keyswitch circuit fault on one module.
Procedure:
• Replace the processor module.
• To find the faulty module, determine the pass-fail status of
all keyswitch combinations involving two on or two off.
Replace the processor module that is in agreement for all
failed combinations.
Important! Two out of three of the keyswitches must be in the same
position to lock or unlock the memory.
PROC, COMM, and I/O lights are not disabled when the reset button is
pressed
Probable Cause:
• The pushbutton circuit is faulty.
Procedure:
• Replace the processor module.
Any alarm contact is stuck on or off
Probable Causes:
• One or more of the processor modules are not fully seated.
• The alarm circuit wiring is faulty.
• The alarm relay is faulty.
Procedure:
• Verify that all modules are fully seated.
• Check the alarm circuit wiring. If wiring is correct, locate
the failed alarm terminals and replace the associated
processor module.

The processor modules appear to be operating normally but a fault

exists with either the communications or I/O circuits
Probable Cause:
• An indicator circuit is faulty or the fault is beyond the
detection capabilities of the processor modules.
Procedure:
• Proceed to Communications Module Faults (page 375), or
I/O System Faults (page 378), whichever is applicable.
The fault is indicated by WINTERPRET only
Probable Cause:
• An indicator circuit has failed.
Procedure:
• Replace the module
Primary Power Faults
Important! This section assumes that one or more of the Regent POWER
lights are off.
These procedures should be followed in the exact order shown
below. A DVM may be required to measure primary voltages.
Danger! Hazardous voltages may be present at terminal blocks and
exposed connectors.
POWER lights are off for two or more modules
Probable Causes:
• The primary power source has failed (blackout or
brownout).
• An MOV is shorted at the filter assembly.
• There is a short in the power wiring (field-side).
Procedure:
• Measure primary voltages at the filter assembly of the
affected units. If primary voltage is zero and a breaker has
tripped, attempt to reset the breaker. If the breaker trips a
second time, check for shorts between terminals at the
filter assembly. If a short exists, disconnect the power
wiring from the affected terminals to isolate between the

MOVs and the field wiring. If necessary, replace the

shorted MOV assembly; otherwise troubleshoot the field
wiring.
• If the primary voltage is zero, but no breakers have
tripped, troubleshoot the primary power source.
• If primary voltage is low, troubleshoot the primary power
source.
POWER light is off for only one module
Probable Causes:
• There is a blown fuse at the filter assembly.
• The module has failed.
• The primary power source has failed (blackout or
brownout).
• There is a short in the primary power circuit (MOV, filter
assembly, chassis wiring, or field-side wiring).
• There is an open in the primary power circuit (filter
assembly, chassis wiring, or field-side wiring).
Procedure:
• Check the fuse at the filter assembly of the affected
assembly.
• If the fuse is faulty, replace it with an equivalent type. If
the new fuse fails, replace the affected module.
• If the new fuse fails with the module removed, there may
be a short in the chassis wiring or filter assembly.
Replacing the filter assembly is not recommended;
however, new filter assemblies can be ordered from ICS
(replacement instructions are included with the assembly).
• If the fuse is okay, replace the affected module.
• If replacing the module does not clear the fault, measure
the primary voltage at the filter assembly of the affected
assembly.
• If the primary voltage is zero and a breaker has tripped,
attempt to reset the breaker. If the breaker trips a second
time, check for shorts between terminals at the filter
assembly. If a short exists, disconnect the power wiring
from the affected terminals to isolate the MOVs from the

field wiring. If necessary, replace the shorted MOV

assembly; otherwise troubleshoot the field wiring.
• If the primary voltage is zero but no breakers have tripped,
troubleshoot the primary power source.
• If the primary voltage is low, troubleshoot the primary
power source.
• If primary voltage is okay, there may be an open circuit in
the chassis wiring or filter assembly. Replacing filter
assembly is not recommended; however, new filter
assemblies can be ordered from ICS (replacement
instructions are included with the assembly).
Communications Module Faults

Important! This section assumes that all PROC lights are green. It also
assumes that there is a communications problem or that one
or more of the COMM lights are red.
below.
COMM light is red for two or more of the processor modules
Probable Causes:
• A communications module is in the wrong slot.
• A communications module is not fully seated.
• A communications module had a transient error.
• A communications module has failed.
Procedure:
• Verify that each communications module is in the correct
slot (slots are configured during system startup).
• If a communications module's COMM light is off (neither
red nor green), verify that the module is fully seated (the
top lever must be fully closed to engage the module
interlock switch). If the COMM light remains off, replace
the communications module.
• Reset the system. If all FAULT lights are green, there may
have been a transient error. It is a good idea to use
WINTERPRET to check the fault history. If the transient
error has occurred often, or if the error indication cannot

be cleared, the communications module should be

replaced. The Fault History Viewer shows which
communications module had the error (there may not have
been a fault indication in the module itself).
COMM light is red for only one processor module
Probable Causes:
• A transient error occurred.
• A communications module has a fault on the Safetybus
circuit associated with the processor module.
• The processor module is faulty.
• The controller assembly backplane has an open circuit on
the Safetybus associated with the processor module.
Procedure:
• Reset the system. If all FAULT lights are green, there may
have been a transient error. It is a good idea to use
WINTERPRET to check the fault history. If the transient
has occurred often, or if the error indication cannot be
cleared, the communications module should be replaced.
The Fault History Viewer shows which communications
module had the error (there may not have been a fault
indication on the module itself).
• If the error persists, or if the errors are not reported to
WINTERPRET, replace the processor module with the red
COMM light, otherwise the controller assembly backplane
may be faulty.
Both the red and green lights are on for any red-green indicator pair
on a communications module
Probable Cause:
• The indicator circuit is faulty.
Procedure:
• Replace the associated communications module.

COMM light is red for one or more of the communications modules
Probable Causes:
• One or more of the communications modules was not
included in the system configuration at startup.
• A transient error occurred.
• One or more communications modules has failed.
Procedure:
• If the module was not included in the system
configuration, delete all programs and transition primary
power at the controller assembly. Reload the RAMcode
from WINTERPRET and return the system to normal
operation.
• Reset the system. If the COMM light is green, there may
have been a transient error. There is no way to determine
how often this error has occurred because it will not be
reported to WINTERPRET (no error indication on the
processor modules). If the COMM light is still red or if the
transient error recurs, replace the module.
Communications error detected by WINTERPRET
Probable Causes:
• WINTERPRET communications were interrupted by a
system reset.
• The communications module had a transient error.
• The communications module has failed.
• The PC to Regent cable is faulty.
• WINTERPRET files have become corrupted.
Procedure:
• Executing a reset causes re-initialization and testing of all
non-intelligent communications modules. This can
interrupt communications and cause WINTERPRET to time
out. If this happens, press SPACE to restart
communications.
• If the error was not caused by a reset, do a reset at the
processor modules and press SPACE to restart
communications. If communications errors are still
detected, check for loose cable connections.

• If the error persists, replace the communications module.

• If replacing the module does not correct the fault, the fault
is probably in WINTERPRET or PC-to-Regent cable. Try
rebooting WINTERPRET to initialize its ports and use the
TX/RX lights to help isolate the fault to the transmit or
receive path.
I/O System Faults

Important! This section assumes that all PROC lights are green. It also
assumes that there is an I/O problem or that one or more of
the processor module's I/O lights are red.
below.
POWER lights are off for two or more modules in an I/O power assembly
Probable Causes:
• The I/O power supply is overloaded (more than 56 load
units).
• Two or more primary power circuits have failed.
Procedure:
• If a squealing noise can be heard coming from any of the
associated I/O units, then the supplies may be overloaded.
Check I/O loading. See Section 2, Installing the Regent
Hardware.
• If the supplies are not overloaded, proceed to Primary
Power Faults on page 373.
POWER light is off for one module in an I/O power assembly
Probable Causes:
• The remaining two supplies are not installed.
• The I/O power supply has detected an overvoltage and shut
itself down. This sometimes happens when the module is
inserted.
• A primary power circuit has failed.
• The I/O power supply has failed.
Procedure:

• Verify that at least two I/O power supplies are installed

(two are required to prevent an overload).
• Remove the I/O power supply module and re-insert (this
will reset the power supply crowbar circuit). If the POWER
light is on, do a reset to return the Regent to normal
operation, otherwise proceed to Primary Power Faults,
above.
ACTIVE and FAULT lights are both off for an I/O transceiver
Probable Causes:
• The I/O transceiver is not fully seated.
• The I/O transceiver has failed.
• The I/O power supply has failed.
• The I/O power cable is faulty.
• The I/O power supply backplane is faulty
• The I/O assembly backplane is faulty.
Procedure:
• Verify that the I/O transceiver is fully seated (release
latches firmly in place). If the FAULT light is on, reset the
system. If the FAULT light is still on then proceed to the
next applicable symptom (below).
• If the indicators are off, replace the I/O transceiver.
• If the indicators are still off, replace the associated I/O
power supply.
• If replacing the module has no effect, the I/O power cable
may be faulty. This cannot be replaced without shutting
down the I/O assembly.
• If replacing the I/O power cable has no effect, either the
I/O power supply or I/O assembly backplanes may be
faulty.
ACTIVE and FAULT lights are both on for any I/O transceiver
Probable Cause:
Procedure:
• Replace the module.

FAULT lights are on for two or more I/O transceivers in the same I/O unit
Probable Causes:
• The I/O assembly is not logged in the system configuration.
• The I/O assembly is incorrectly addressed.
• Incorrect I/O cable installation.
• Two or more I/O transceivers are not fully seated.
• Two or more I/O transceivers had a transient error.
• Two or more I/O transceivers are faulty.
Procedure:
• If the I/O system's primary power was not present during
startup of the controller assembly, delete all programs and
transition controller assembly primary power. Re-load the
RAMcode from WINTERPRET.
• Verify that the I/O assembly address switch is set correctly.
Refer to Installing the I/O Chassis, in Section 2, Installing
the Regent Hardware.
• Verify that all I/O cables are securely fastened to their
mating connectors. Verify that the I/O cables are correctly
installed. Refer to Installing the I/O Safetybus and I/O
Power Cables in Section 2, Installing the Regent
Hardware.
• Verify that the I/O transceivers are fully seated (latches
snapped in place).
• Reset the system. If the ACTIVE lights remain on (FAULT
lights off), there may have been a transient error. It is a
good idea to use WINTERPRET to check the fault history to
determine how frequently this transient has occurred.
• If the FAULT lights are still on, replace each I/O transceiver
one at a time until operation returns to normal.

FAULT lights are on for two or more I/O transceivers having the same
slot position
Probable Causes:
• The I/O transceiver(s) is incorrectly addressed.
• An I/O cable connector is not fully seated.
• Two or more I/O transceivers are not fully seated.
• Two or more I/O transceivers had a transient error.
• Two or more I/O transceivers are faulty.
• An I/O cable is faulty.
• The processor module is faulty.
• The controller assembly backplane or an I/O assembly
backplane is faulty.
Procedure:
Refer to Installing the I/O Chassis in Section 2, Installing
the Regent Hardware. Two I/O transceivers may have
been assigned the same address.
• Verify that all I/O cables associated with this I/O
transceiver slot are securely fastened to their mating
connectors.
• Verify that the I/O transceivers are fully seated (latches
snapped in place).
• Reset the system. If the ACTIVE lights remain on (FAULT
lights off), there may have been a transient error. It is a
good idea to use WINTERPRET's Fault History Viewer to
determine how frequently this transient has occurred. For
instructions on how to use the Fault History Viewer see
page 387.
• If the FAULT lights are still on, replace each I/O transceiver
one at a time until operation is normal.
• If replacing the I/O transceiver modules has no effect, one
of the I/O cables may have an open circuit. To locate the
faulty cable, bypass each cable section one at a time until
the fault is cleared. Alternately, if a system shutdown can
be tolerated, the suspected cable section can be swapped

with an adjacent cable to see if the fault moves with the

cable.
• If the fault persists, try replacing the processor module
that drives the affected cable section.
• If replacing the processor module has no effect, there may
be an open circuit in one of the I/O assembly backplanes or
the controller assembly backplane.
FAULT light is on for one I/O transceiver (ACTIVE light is off)
Probable Causes:
• The I/O transceiver is not fully seated.
• The I/O transceiver had a transient error.
• The I/O transceiver has failed.
• The I/O transceiver is mis-addressed.
• An I/O cable connector is not fully seated.
• An I/O module has failed such that the I/O assembly
backplane is stuck.
• An I/O cable is faulty.
• The I/O power wiring is faulty.
• An I/O assembly backplane is faulty.
Procedure:
• Verify that the I/O transceiver is fully seated (and release
latches are firmly in place).
• Reset the system. If the ACTIVE light remains on (FAULT
light off), then there may have been a transient error. It is
a good idea to use WINTERPRET to check the fault history
to determine how frequently this transient has occurred.
• If the FAULT light is still on, replace the I/O transceiver.
• If the fault persists, check that the I/O assembly address
switch is set correctly. Refer to Section 2, Installing the
Regent Hardware, for more information about installing
the I/O chassis.
• Verify that all I/O cables associated with this slot position
are securely fastened to their mating connectors.

• Temporarily remove each I/O module in the affected

chassis one at a time to see if it is hanging up the
backplane section associated with the I/O transceiver.
• If replacing the I/O module has no effect, one of the I/O
cables may have an open circuit. To locate the faulty cable,
bypass each cable section one at a time until the fault is
cleared. Alternately, if a system shutdown can be
tolerated, the suspected cable section can be swapped with
an adjacent cable to see if the fault moves with the cable.
• The I/O power wiring can be checked by swapping the I/O
power cable with another I/O assembly to see if the fault
follows the cable. This will cause a temporary shutdown of
the two I/O units.
• If the fault persists, one of the I/O assembly backplanes
may be faulty.
SHUTDOWN light on for any output module
Probable Causes:
• The module is not fully seated.
• The module is not logged in the system configuration.
• The module type is incorrect for this slot position.
• Field power has failed (analog outputs only).
Procedure:
• Verify that the module is fully seated (and that the release
levers are firmly in place).
• If there was no module in this slot during start up of the
controller assembly, or if WINTERPRET’s Fault Status
Viewer does not show a fault for this module, delete all
programs and transition controller unit's primary power.
Reload the RAMcode from WINTERPRET.
• Verify that the module is the correct type for this slot. The
I/O configuration can be checked by entering
WINTERPRET's I/O Configuration Editor and asking for a
new configuration. WINTERPRET will request new
configuration data from the Regent. Use the Cancel
button when exiting the editor, otherwise the new
configuration will be saved without I/O point labels.

• If this is an analog output module, verify that field power

is present.
• Replace the output module.
BLOWN FUSE light is on for any output module
Probable Causes:
• The output circuit is overloaded (possible short).
• The output circuit fuse has failed (possible wrong fuse
type).
• The load surge current at turn-on exceeds the module
specifications.
Procedure:
• Refer to the module’s product description for more
information on replacing fuses.
• If a fuse is blown, replace it with an equivalent type. If the
fuse blows again, check the load and its wiring for a
possible short circuit. Verify that the output surge rating
is not being exceeded. Refer to the system specifications in
Section 2, Installing the Regent Hardware.
• If all the fuses are good, replace the output module.
ACTIVE and FAULT lights are both on for any I/O module
Probable Cause:
Procedure:
• Replace the module. (Note: some earlier versions of the 24
VDC digital input and 24 VDC digital output will have both
lights on if two I/O transceivers or two I/O power supplies
are removed.)
FAULT light is on for any I/O module (ACTIVE light is off)
Probable Causes:
• The module is not logged in the system configuration.
• The module type is incorrect for this slot position.

• Field power has failed (digital Guarded outputs only).

• The load circuit is open (analog Guarded outputs and AC
Guarded outputs only).
• The module had a transient error.
Procedure:
• Verify that the module is fully seated (and release latches
are firmly in place).
• If there was no module in this slot during startup of the
controller assembly, or if WINTERPRET’s Fault Status
dialog box does not show a fault for this module, delete all
programs and transition controller assembly's primary
power. Reload the RAMcode from WINTERPRET.
• Verify that the module is the correct type for this slot. The
I/O configuration can be checked by entering
WINTERPRET's I/O Configuration Editor and asking for a
new configuration. WINTERPRET will request new
configuration data from the Regent. Use the Cancel
button when exiting the editor, otherwise the new
configuration will be saved without I/O point labels.
• If this is a Guarded digital output module, verify that field
power is present (Guarded AC modules display a fault
message for field power).
• If this is a Guarded analog output module, make sure that
an appropriate load is present on all outputs (all unused
outputs should be shorted).
• If this is a Guarded AC output module, make sure that an
appropriate load is present on all activated outputs. The
AC Guarded output module displays a fault message for
open load.
• Reset the system. If the ACTIVE light stays on (FAULT light
off), there may have been a transient error. It is a good
idea to use WINTERPRET to check the fault history to
determine how frequently this transient has occurred.
• If the FAULT light remains on, replace the I/O module.

ACTIVE and FAULT lights are both off for any I/O module
Probable Causes:
Procedure:
• Verify that the module is fully seated (and release latches
are firmly in place).
• If the condition is unchanged, replace the module.
The fault is indicated only at WINTERPRET
Probable Causes:
• An indicator circuit has failed.
• An I/O assembly is mis-addressed.
Procedure:
Refer to Installing the I/O Chassis, in Section 2, Installing
the Regent Hardware.
• Reset the system. If the fault indication returns, replace
the associated I/O module.
The fault is indicated only in the application program
Probable Causes:
• The fault is on a standard I/O module.
• The fault is in the field wiring or field devices.
• The fault is in the application program.
Procedure:
• If the fault is detected by a voter or mid value select
element in a function block, replace the module associated
with the detected fault. If module replacement has no
effect, check the field circuits.
• If a standard I/O module is used in a simplex
configuration, use the module point status indicators to
help isolate the fault between module and field circuit.
• WINTERPRET's forcing tools are useful for troubleshooting
application programs.

Using the Fault History Viewer

The Regent keeps a fault history log containing the last 80
transient faults and the last 80 permanent faults that have
occurred in your system. The fault history log lists the I/O
system faults (I/O processor and background tests) and
processor faults (main processor background tests).
The Fault History Viewer lets you view, print, and save the
contents of the fault history log.
The Fault History Viewer is an excellent tool for diagnosing
transient errors. The first time an error occurs, it is reported
as transient. If the error does not occur again for some time
then a transient reset is reported, indicating that the error has
expired. If the error recurs after it has expired and been reset,
it will be reported again as transient. If the error recurs
frequently, without having had time to expire and be reset, it
will be reported as permanent. At this point, the permanent
fault indication is latched in the Regent and no new errors for
that fault will be recorded in the history file until the operator
executes a reset.
Opening the Fault History Viewer

To open the Fault History Viewer, open the project containing
the program whose fault history you want to view. To open a
project, select the project that you want to open and choose
Open Project from the Project Selector's File menu [ALT,F,O].
press ENTER.
From the Project Editor's Controller menu choose Fault
History [ALT,C,H] to open the Fault History Viewer.
From the Fault History Viewer's Controller menu choose
Upload History [ALT,C,U] to view the most recent faults in the
Regent's fault history log.
You can clear, or reset, the contents of the Regent's fault
history log by choosing Clear History from the Fault History
Viewer's Controller menu [ALT,C,C].

Figure 178. Fault History Viewer.

From the Fault History Viewer's File menu you can print,
save, or delete the contents of the viewer.
Important! If a real-time clock communications module is installed, the
time stamps in the fault history log will be from that module's
clock. If the communications module's real-time clock fails, or
if no real-time clock communications modules are installed,
the times and dates shown in the fault history log will be
based on calculations made by WINTERPRET using millisecond
counter values supplied by the Regent representing the time
since the fault occurred.
Fault History View Commands

File Menu
Save History File
Used after gathering history from the Regent (see page 390,
Get History from Regent command) to save the history to a
log file on the PC’s hard disk.
Using this command requires the access right “clear fault
history.”

Delete History File

Use this command to delete the fault history file that is saved
in the project directory. Normally you should not delete the
fault history file, as it provides an historical archive of faults
that have occurred on the Regent and is useful for
documenting system problems and repairs and aides in
troubleshooting. However, it is sometimes useful to delete a
file that has become full of old fault information that is no
longer necessary. For example, during system assembly and
testing the user may install and remove modules for system
checkout and troubleshooting. Before commissioning it is
convenient to delete the history file so that all of these older
faults are removed from the file and only new faults
(occurring after commissioning) are saved.
This command only clears the faults saved in the fault history
file on the PC. Use the Clear History in Regent command to
delete the fault history log inside the Regent.
The Delete History File command is not available unless a
history file exists (see page 388, Save History File command).
This command displays a dialog box only if the confirmation
level is set to Yes - No or Codes.
Using this command requires the access right “clear the fault
history.”
Print Fault History
Used to print the fault history (no dialog appears with this
command). You must first have used the Get History from
Regent and Save History File commands before you can print
a history file.
Print Setup
Consult your printer’s documentation for details.
Log Off

Exit
Note: This is not how to close the Shared Variable Editor, as this
page 391, Closing the Fault History Viewer.
Controller Menu
Get History from Regent
Use this command to communicate to the Regent and read all
fault history information and display it for viewing in the
Fault History Viewer. This command causes the fault history
to be read once. If subsequent faults occur in the Regent, you
must execute another Get History from Regent to read the
new faults.
Clear History in Regent
This command clears the fault history in the Regent
controller. To prevent clearing faults that have not been read
and saved you should first use the Get History from Regent
and Print Fault History commands and then close the Fault
History Viewer to ensure that you do not loose any historical
fault information.
Like the Delete History File command, this command is useful
for clearing the fault history from the Regent after the system
has been commissioned. This allows the system faults to be
cleared out, so that old faults that occurred during system
assembly are cleared and only new (occurring after
commissioning) faults are recorded.
This command displays a dialog box only if the confirmation
level is set to Yes - No or Codes.
Window Menu


Help Menu
Closing the Fault History Viewer

Close the Fault History using the Fault History Viewer’s
Control-menu box.
A dialog box appears if you have used the Get History from
Regent command and have not saved the history with the
Save History File command.
You will be prompted, “Fault History has been modified. Save
changes?” Choose from the following options:
Yes
Saves the fault history to disk.
No
Closes the Fault History Viewer without saving any new fault
history information gathered from the Regent during this
session.
Cancel
Returns you to the Fault History Viewer.
If you do not have the access right “clear fault history” you
cannot save the fault history and the Fault History Viewer is
closed without prompting you to save.
Using the Fault History Viewer to

Diagnose Faults
If the fault history contains many entries, it is best to print it
out before attempting to diagnose any failures.

Some entries in the fault history log are directly the result of
operator actions or events external to the Regent, for example,
• Voted resets (operator-executed reset at the processor
modules or from WINTERPRET);
• Warm start (power transition at the controller unit).
Other entries in the fault history log may also reflect
maintenance activities related to field circuits, for example,
• If field power is temporarily interrupted, faults will be
reported on any Guarded outputs or analog outputs that
use this power;
• If a load is temporarily disconnected and bypassed, faults
will be reported on analog Guarded outputs or AC Guarded
outputs that drive this load.
The fault history log's time stamps will help isolate those
entries that are the result of events external to the Regent.
The remaining entries can be categorized as shown in Table
43.
Table 43. Error Occurrence Categories.
Rare (less than once a month): No action required.
Frequent (less than once a day): Replace and monitor.
Continuous (permanent): Replace.
These categories are presented only as a baseline. Other

factors such as the module type, your application, and
environment should be considered in any maintenance plan.
Using the Fault Status Dialog Box

The Fault Status dialog box provides you with an ongoing,
constantly updated, representation of each of your system's
major components.
A Print command button in the Fault Status dialog box lets
you print the contents of the box. A Reset command button
lets you reset your system after correcting faults.
Opening the Fault Status Dialog Box

To view you system's fault status, open the project whose fault
status you want to view. To open a project, select the project

that you want to open and choose Open Project from the
Project Selector's File menu [ALT,F,O].
6 Shortcut: Select the project that you want to open and press ENTER or
double-click.
From the Project Editor's Controller menu choose Fault
Status [ALT,C,F] to open the Fault Status dialog box.
Figure 179. Fault Status Dialog Box.

Permanent faults in modules and components are indicated in
red; transient faults are indicated in yellow.
The Fault Status dialog box is continuously refreshed to show
the current system status.
Diagnosing Faults with the Fault Status Dialog Box

Scan through the dialog box to determine the location of all
transient and permanent fault conditions. Transient faults
will eventually be cleared or become permanent faults,
depending on the frequency of their occurrence. Permanent
faults are displayed continuously and can only be cleared by
choosing reset.

Regent hardware indicators, however, show fault indications

due to communications time-out on the I/O cable.
If no faults are reported in the controller status box, scan the
I/O transceiver columns for faults. Multiple faults in an I/O
transceiver column generally indicate one of the following:
• I/O power supply failure;
• I/O cable failure;
• I/O transceiver address conflict.
If no I/O transceiver faults are reported, scan the I/O module
slots for faults. Multiple faults in the I/O module slots
generally indicate one of the following:
• Outputs are not started;
• Field power has failed (analog outputs or Guarded
outputs);
• A load circuit is open (analog Guarded outputs or AC
Guarded outputs).
Use the Program Monitor to determine whether outputs are
started. Examine the I/O configuration to determine which
module types have failed. This will help determine if the fault
is caused by a field problem.
After an initial determination is made of the probable fault
location, do a reset and wait for the fault indications to return.
If the system is free of faults then use the Fault History
Viewer to determine when and how often these faults have
occurred. Otherwise proceed with system repair. See
Troubleshooting with the Fault Indicators, on page 366, if
system repair cannot be accomplished.
Important! A system reset will temporarily interrupt WINTERPRET
communications while the communications module ports are
reinitialized and tested. This may cause WINTERPRET to time-
out and display the message “Can't Read Fault Status.”
Returning Failed Modules

To return failed modules to the factory for repair, a Return
Material Authorization number is required. To obtain an
RMA number please contact ICS.

Before calling, please have the following information available

to assist the ICS in processing your return material request:
1. Shipping address.
2. Billing address.
3. Contact name.
4. Phone number.
5. Catalog number of items being returned.
6. Serial number of items being returned.
7. Description of observed failure mode or other problems.
In addition, the following information may be helpful in
expediting your repair and return of the equipment.
1. Original purchase date.
2. Date of installation.
3. Any special shipping instructions for shipping the product
after repairs are completed.
4. If the equipment being returned is out of warranty, a
purchase order number will be required before actual
repair work begins.
Repacking Modules for Shipping

If available, modules should be repacked in their original
shipping containers.
Static Electricity Cautions
Avoid touching module connectors during handling.
Modules contain static sensitive components and should be
sealed in antistatic plastic bags to avoid electrostatic buildup.
Shipping Label
Please include your Return Material Authorization (RMA)
number on the shipping label.
Ordering Information
To order replacement parts, please contact,

Industrial Control Services, Inc.

Customer Service Department
16400-A Park Row
Houston, TX 77084-5015
U.S.A.
Telephone: (281) 492-0604

Fax: (281) 647-4336

Section 10
Additional Resources
Additional information about both the Regent’s modules and
the WINTERPRET application is available from a number of dif-
ferent sources.
The Readme File

The file README.WRI on the WINTERPRET distribution disk
contains information that was not available when this User’s
Guide was printed. To view the README.WRI file, follow
these steps:
1. After installing WINTERPRET, open the File Manager and
locate the WINTERP program group.
2. Double-click on the README.WRI file.
You can also view the README.WRI file before installing
WINTERPRET by pulling down the Program Manager’s File
menu and choosing Run. In the Run dialog box type,
a:\readme.wri
Choose OK or press ENTER. (If you inserted the WINTERPRET
distribution disk in drive B: type b:\readme.wri and choose
OK or press ENTER.)
On-Line Help
WINTERPRET’s on-line Help provides information on using the
application. If you have a question about a WINTERPRET com-
mand or other feature, you should first try using Help before
consulting other sources. Most of the common operations and
commands are fully explained in Help topics (including the
add-in features described below).

Add-In W INTERPRET Capabilities

When you purchase WINTERPRET you receive a base package
that includes all of the features you need to configure and pro-
gram a Regent controller. The function blocks available for
programming include ladder logic and analog scaling. Other
function block types, Guarded Peer-Link communications, and
conversion utilities are sold as add-in software packages and
are purchased separately. Each add-in package contains
documentation describing the operations of the additional de-
velopment resources. The add-in packages are briefly de-
scribed below.
Communications Package, T3831

The communications package provides you with Guarded
Peer-Link communications functions. If you plan on installing
multiple Regent systems that need to communicate with each
other on a peer-to-peer level you need this package. The
communication package includes the resources for configur-
ing, loading, connecting, and starting the Guarded Peer-Link.
Software Validation Package, T3835

The software validation package is required for Risk Class 5
safety-related applications. This package provides utilities to
upload and verify the application programs for consistency
with respect to the application source files developed using
WINTERPRET . By applying the Checker, Validator,
GPLPRINT, and GPLCHECK tools and procedures, the
application developer assures to a high degree that the
application programs and Guarded Peer-Link configuration
have been compiled and loaded into the Regent controller and
are an accurate implementation of the specified application
functions.
Historian Package, T3832

The historian package contains sequence of events and process
historian function blocks. If your application requires the
Regent to perform internal time stamping and logging of digi-
tal or analog process data you need this package. The histo-
rian package includes the resources for editing, compiling, and
monitoring sequence of events and process historian function

Additional Resources Section 10
blocks. The monitoring functions provide the means of col-

lecting the historical logs from the Regent controller to the
PC.
Math Package, T3833

The math package contains the floating point math function
blocks. In the base package you have ladder logic function
blocks that contain integer math instructions for add, sub-
tract, multiply, and divide. If your application requires more
advanced math functions — or higher numerical precision
using floating point registers — you need this package. The
math package includes the resources for editing, compiling,
and monitoring floating point math function blocks.
Continuous Control Package, T3834

The continuous control package contains the continuous con-
trol function blocks. Continuous control function blocks allow
you to configure process control loops for the Regent. If you
require PID closed-loop control functions you need this pack-
age The continuous control package includes the resources for
editing, compiling, and monitoring continuous control func-
tion blocks.
Conversion Utilities Package, T3836

The conversion utilities package converts Regent application
programs and configurations developed using the DOS-based
Program Development System (PDS) to the format used in
WINTERPRET. The conversion utilities convert all types of
function blocks, programs, I/O configuration, and shared vari-
ables. If you are upgrading a system that was originally con-
figured using PDS you need this package.
Hardware Product Descriptions

Product descriptions are available for each of the Regent’s
hardware modules. These product descriptions contain de-
tailed information about the module’s operation, installation,
configuration, and maintenance — as well as detailed
specifications.


ICS TRIPLEX Regent User&#39;s Guide

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

ICS TRIPLEX Regent User&#39;s Guide

Hochgeladen von

Copyright:

Verfügbare Formate

User's Guide

Regent® Fault Tolerant Programmable Controller

ii Industrial Control Services

Important Grounding Notice:

R e g e n t User's Guide, Issue 4 iii

R e g e n t User's Guide, Issue 4 v

Installing the I/O Chassis............................................62

vi Industrial Control Services

R e g e n t User's Guide, Issue 4 vii

Closing the Shared Variable Editor .......................................155

viii Industrial Control Services

R e g e n t User's Guide, Issue 4 ix

Using the Execution Controller .............................................281

x Industrial Control Services

Section 8 Safety Considerations

R e g e n t User's Guide, Issue 4 xi

xii Industrial Control Services

Conversion Utilities Package, T3836 ..........................399

R e g e n t User's Guide, Issue 4 xiii

xiv Industrial Control Services

Fault Tolerance, HIFT and TMR

HIFT stands for “hardware-implemented fault tolerance” —

2 Industrial Control Services

Figure 1. Key Elements in the Regent TMR System.

Regent User’s Guide, Issue 4 3

The Regent operates in the following sequence:

Process state information (transducer readings, switch posi-

Process state information is buffered by the input modules

The I/O transceiver modules relay the process state informa-

4 Industrial Control Services

Synchronous I/O processors read state information and two-

The main processors synchronously execute application pro-

Regent User’s Guide, Issue 4 5

The output modules receive the output commands from the

Output circuits are driven by the majority-voted command.

6 Industrial Control Services

out-votes failures, preventing them from being propagated

Regent User’s Guide, Issue 4 7

Figure 2. The Regent's Predictable Fail-Operational /

8 Industrial Control Services

Figure 3. The Regent.

Regent User’s Guide, Issue 4 9

The Controller Assembly

Figure 4. The Controller Assembly.

10 Industrial Control Services

Figure 5. Block Diagram of the Controller Assembly.

Regent User’s Guide, Issue 4 11

12 Industrial Control Services

Each processor module contains its own power supply that

Figure 6. Block Diagram of a Processor Module.

Regent User’s Guide, Issue 4 13

then interrupts the main processor, signaling that data is

14 Industrial Control Services

Standard communications modules have,

Regent User’s Guide, Issue 4 15

There can be up to three communications modules of any type

Figure 7. Typical Communications Module.

16 Industrial Control Services

The I/O Power Supply Assembly

Figure 8. The I/O Power Supply Assembly.

Figure 9. Block Diagram of the I/O Power Supply Assembly.

Regent User’s Guide, Issue 4 17

I/O power supply assemblies and I/O power supply modules

I/O Power Supply Chassis

ICS TRIPLEX Regent User's Guide

ICS TRIPLEX Regent User's Guide