Monitor Pro

Monitor Pro
Fundamentals Guide
Version 7.6
Copyright Schneider Automation SAS 2005.

All rights reserved. This document may not be reproduced or copied in whole or in
part, in any form or by any means, either graphic, electronic, or mechanical, including
photocopying, recording, or storage in a retrieval system.
This document and related media constitutes documentation relating to a software
product and is being provided solely for use with such software product. The software
product was provided pursuant to a separate license or other agreement and such
information is subject to the restrictions and other terms and conditions of such
license or other agreement. Except for warranties, if any, set forth in the separate
license or other agreement relating to the applicable software product, Schneider
Automation SAS makes no warranty, express or implied, with respect to such
information or such software product.
All examples in this manual are given for information only. Before being used in an
industrial application, they must be suitably adapted to the specific functions and
safety requirements of the application concerned.
Monitor Pro Software Schneider Automation SAS 2005. This software is the
property of Schneider Automation SAS or its third party providers. Each sale of a
stored unit of this software grants the purchaser a nonexclusive licence that is strictly
limited to the use of the specific unit in a compatible Telemecanique/Square D
programming terminal.
Apart from the creation of a back-up copy for the exclusive use of the purchaser, this
software may not be duplicated, reproduced, or copied in any form or by any means
whatsoever. Modification or adaptation of the software is forbidden.
Schneider Automation SAS's warranty is limited to the conformity of the products of
Modicon, Square D, and Telemecanique with their functional characteristics.
Schneider Automation SAS assumes no liability for the use that is made of its
products, nor for any damages or other consequences that may result from their use.
The software products are designed for use in a wide variety of applications. Although
thoroughly tested, it is impossible for the tests to cover all the various applications for
which the software could be used.
Monitor Pro is a registered trademark of Schneider Automation SAS. Windows is a
registered trademark of Microsoft Corporation. Tecnomatix and FactoryLink are
registered trademarks of UGS Corp.
Contents
Chapter 1
Introducing Monitor Pro.............................................................................. 1

How Monitor Pro Can Help You ..........................................................................................
How Monitor Pro Works ......................................................................................................
Object-Oriented Development .....................................................................................
Redundancy ..................................................................................................................
Graphics Development .................................................................................................
Chapter 2
Distributed Architecture............................................................................... 5
Three-Tier Model ..................................................................................................................
Development and Run-Time Systems ..................................................................................
Scalable System Sizes ..........................................................................................................
Developer-Defined Maximum Tags (Total Tags) ........................................................
Input/Output Maximum Tag (I/O Tags) .......................................................................
Chapter 3
2
2
3
3
3
5
7
8
8
8
Features, Tasks, and Tools .......................................................................... 9

Monitor Pro Tasks ................................................................................................................ 9
Graphical User Interface ............................................................................................. 9
Device Interfaces ....................................................................................................... 10
Dynamic Data Exchange ........................................................................................... 11
OPC Data eXchange (ODX) ...................................................................................... 11
Enhanced Communication Interface (ECI) ............................................................... 11
XML Adapter .............................................................................................................. 11
General Tasks ............................................................................................................ 12
Utilities ....................................................................................................................... 13
Logging and Retrieving Data ..................................................................................... 14
Communicating Across a Network ............................................................................. 17
Monitor Pro Add-Ons ......................................................................................................... 18
Multilingual Systems .......................................................................................................... 19
Configuration Tools ............................................................................................................ 20
Configuration Explorer .............................................................................................. 20
Client Builder ............................................................................................................. 25
Custom Development Tools ............................................................................................... 27
Monitor Pro Fundamentals Guide / iii
Chapter 4
Historical Reports....................................................................................... 29
Overview ............................................................................................................................ 29
Generating Reports ............................................................................................................. 30
Chapter 5
Internal Architecture.................................................................................. 35
Open Software Bus .............................................................................................................
Real-Time Database ...........................................................................................................
Monitor Pro Tags ................................................................................................................
Tag Naming Guidelines .............................................................................................
Tag Naming Recommendations .................................................................................
Defining Tags in Configuration Explorer ..................................................................
Triggers ...............................................................................................................................
Predefined System Tags .....................................................................................................
Tag Arrays ..........................................................................................................................
Defining One-Dimensional Arrays ............................................................................
Defining Multi-Dimensional Arrays ..........................................................................
Branching ...........................................................................................................................
Designing Tag Names for Branching ........................................................................
Branching Views in Client Builder ............................................................................
Reusing Graphics with Branching .............................................................................
Branching Shortcuts ..................................................................................................
Tag Arrays Used with Branching ..............................................................................
Redundant Licensing ..........................................................................................................
Client Operation ........................................................................................................
License Server Operation ..........................................................................................
Licensing Scenarios ...................................................................................................
Operating Guidelines .................................................................................................
Data Logging ......................................................................................................................
Database Browsing .............................................................................................................
Database Browser Control ........................................................................................
PowerSQL ..................................................................................................................
Database Browser Task .............................................................................................
Browser Differences ..................................................................................................
Environment Variables .......................................................................................................
Run-Time Manager ............................................................................................................
Multiuser Architecture .......................................................................................................
Shared and User Domains .........................................................................................
iv / Monitor Pro Fundamentals Guide
36
38
40
40
41
41
43
44
48
48
49
50
53
54
55
60
60
63
63
64
65
68
70
72
72
73
73
74
79
80
81
81
Domain Structure .......................................................................................................

Domain Tables ...........................................................................................................
Domain Associations .................................................................................................
Domains for Run-time Tasks .....................................................................................
Monitor Pro Kernel ............................................................................................................
Kernel Multi-User Capabilities .................................................................................
Application Instances and Identification ...................................................................
Chapter 6
Planning Your Application ....................................................................... 87

Planning Your Application Process ....................................................................................
Minimum Hardware and Software Requirements ..............................................................
Guidelines for System Design and Maintenance ...............................................................
Tag Naming Recommendations .........................................................................................
Message Types ....................................................................................................................
Application Objects and Symbols ......................................................................................
Standard Interface ...............................................................................................................
Chapter 7
83
84
84
84
86
86
86
87
89
89
90
91
91
91
Examples Application................................................................................ 93
Examples Application Installation ..................................................................................... 93
Running the Examples Application .................................................................................... 94
Server Application Overview ............................................................................................. 94
Starting a Server Application .................................................................................... 94
Saving a Server Application ...................................................................................... 95
Restoring a Server Application .................................................................................. 96
FLREST Domain Considerations .............................................................................. 99
Client Project Overview ................................................................................................... 100
Opening a Client Project ......................................................................................... 100
Saving a Client Project ............................................................................................ 101
Restoring a Client Project ....................................................................................... 101
Client Builder Client Project ............................................................................................ 103
Animation Real-Time Display .................................................................................. 104
ActiveX Controls ...................................................................................................... 104
Standard Animation Features .................................................................................. 105
Advanced Animation Features ................................................................................. 106
Server Application Components ...................................................................................... 107
Viewing Tag Descriptions ........................................................................................ 107
Application Objects ................................................................................................. 107
Monitor Pro Fundamentals Guide / v
Examples of Application Objects ............................................................................. 108

Application Object Overview Diagram ................................................................... 110
Changing Computer Location .......................................................................................... 112
Chapter 8
Application Setup Wizard......................................................................... 115

Application Setup Wizard Templates ...............................................................................
Application Objects in Server Templates .........................................................................
General Objects .......................................................................................................
VRN Setup Object ....................................................................................................
Driver Objects .........................................................................................................
Chapter 9
116
117
117
119
120
Getting Help.............................................................................................. 121

Monitor Pro Documentation ............................................................................................. 121
Customer Support ............................................................................................................. 123
Appendix A Monitor Pro Directory Organization ....................................................... 125

Appendix B Real-Time Database and Tag Structure .................................................. 129
Real-Time Database Structure ..........................................................................................
Tag Structure ...........................................................................................................
Change-Status Bits ...................................................................................................
Real-Time Database Access Reads and Writes .............................................................
Normal (Conditional) Write ....................................................................................
Forced (Unconditional) Write .................................................................................
Change (Conditional) Read .....................................................................................
Normal (Unconditional) Read .................................................................................
Tag Structure ....................................................................................................................
Basic Tag Structure .................................................................................................
Change-Status Bits ...................................................................................................
Digital Tag Structure ...............................................................................................
Analog Tag Structure ...............................................................................................
Longana Tag Structure ............................................................................................
Float Tag Structure ..................................................................................................
Message Tag Structure ............................................................................................
Mailbox Tag Structure .............................................................................................
vi / Monitor Pro Fundamentals Guide
129
131
131
134
134
135
136
137
138
138
138
139
140
140
141
141
142
Chapter 1
Introducing Monitor Pro
Schneider Electric is pleased to announce the release of Monitor Pro 7.6, the latest
version of its multi-user, real-time Supervisory Control and Data Acquisition
(SCADA) software product. The Monitor Pro software provides the process
knowledge and control needed to perfect the products companies make and the
processes they manage.
Monitor Pro monitors, supervises, and controls processes in a variety of industries
around the world. Monitor Pro is highly scalable and can be used to build from the
simplest Human-Machine Interface (HMI) systems to the most complex and
demanding SCADA systems. Monitor Pro allows data to be collected from a wide
variety of plant floor devices and valuable information to be distributed easily
throughout the entire organization.
Schneider Electric has offered a SCADA solution and the Monitor Pro family of
products for over 10 years, providing customers with the latest in technology to meet
the ever-changing demand in the automation arena.
To continue providing cutting edge technology to our customers, Schneider Electric
formed a long-term partnership with UGS Tecnomatix of Richardson, Texas, USA, to
provide the Monitor Pro product, the core of which is based on the FactoryLink
product. This partnership offers a proven SCADA solution with a team of dedicated
engineers focused solely on automation technologies associated with supervisory
control and data acquisition applications.
As you work with and use the product, you will see references to the core FactoryLink
product in both the documentation and Help files. This is not to be considered an error
or misprint. Monitor Pro is distinctly different from the core FactoryLink product in
the Add-On modules provided. The add-on modules provide a tight integration with
the Schneider Electric family of controllers as well as added benefits to users when
configuring applications.
Monitor Pro Fundamentals Guide / 1
1 | INTRODUCING MONITOR PRO

How Monitor Pro Can Help You
H OW M ONITOR P RO C AN H ELP YOU

Monitor Pro can help you in the following ways:
Monitor Pro provides visibility into the entire process, giving the right information
to the right people when they need it.
A graphical user interface lets operators monitor and control pumps, tanks, valves,
motors, switches, and other key process equipment.
An alarm system alerts operators to problems and keeps a history for later analysis.
Real-time and historical trend charts help operators and managers improve
efficiency and resolve problems.
Reports and historical data help satisfy management and regulatory requirements.
Monitor Pro supports both local and remote monitoring to provide secure access to
critical information at the plant or even at a managers home.
Monitor Pro provides unparalleled connectivity by connecting remote terminal
units (RTUs), programmable logic controllers (PLCs), production and test
equipment, business systems, and other supporting systems using OLE for Process
Control (OPC), Extensible Markup Language (XML), proprietary, or custom
protocols.
A rich set of artwork, developed specifically for industrial automation systems and
equipment, is included to ease the configuration process.
H OW M ONITOR P RO WORKS
Based on open industry standards, the Monitor Pro system is designed to take full
advantage of the Microsoft Windows operating system, enabling users to leverage
other software products available on the market and to lower training and maintenance
costs.
Monitor Pro 7.6 runs on Microsoft Windows 2003, XP, and 2000. Other standards
include:
Windows Terminal Services support for remote access by thin clients
OPC (client and server)
ActiveX
ODBC
Microsoft Visual Studio .NET or Visual C++
2 / Monitor Pro Fundamentals Guide
INTRODUCING MONITOR PRO | 1

How Monitor Pro Works
Microsoft Visual Basic for Applications

Microsoft SQL Server 2000
Licenses for Microsoft SQL Server 2000 and Microsoft VBA are included in the
product at no additional charge. Telemecanique is a Microsoft Certified Partner.
Object-Oriented Development
Monitor Pro has object-oriented development tools that you can use to create
application objects to represent real-world devices, such as pumps, valves, switches,
tanks, or other equipment. Application objects are reusable and have inheritance, so if
one is modified, all instances of the object are modified accordingly, without the
need to find and update each instance individually. Application objects save valuable
time and reduce risks during system configuration or maintenance efforts.
Redundancy
Monitor Pros virtual real-time networking capability facilitates the creation of
redundant Monitor Pro applications. It allows two identical Monitor Pro applications
to operate in a master/slave configuration and supports master/slave arbitration,
real-time data synchronization, and alarm system redundancy. Monitor Pro also
supports several methods of handling redundancy of historical data.
Graphics Development
Each Monitor Pro client contains two types of graphics technology: multiplatform
graphics (Monitor Pro ECS) and Windows technology (Client Builder graphics) for
Monitor Pro 7.x or later. Both types can be used in the same application.
1 | INTRODUCING MONITOR PRO

How Monitor Pro Works
Two Types of Graphics Technology
Multiplatform graphics Monitor Pro ECS (Pre 7.0)
Windows Technology Client Builder

Graphics (7.x and later)
Client Builder, Monitor Pros graphical development tool, provides a rich set of
artwork for use in building graphical displays. Included are standard user interfaces
for alarm viewing, trending, and historical data browsing. These interfaces require
minimal configuration and allow you to present the right information to the right
person in an easy-to-understand format.
Chapter 2
Distributed Architecture
The fundamental architecture of Monitor Pro is based on the latest Microsoft

Windows technology and three-tier model of distributed client/server processing. In
this model, a clear separation exists among client services, business services, and data
services, which facilitate the efficient design of applications.
The Monitor Pro applications are stored on the Monitor Pro server, but can be
developed and maintained from any client in the system with a development license.
Any application modifications are immediately available to all clients, significantly
reducing the cost and effort associated with developing and maintaining Monitor Pro
applications.
Connectivity between clients and servers is provided using LAN, WAN, dial-up
connection, or through the Internet. Systems can be set up to allow remote users to
access the system on their pocket PCs through Windows Terminal Services, so they
are always aware of the latest information. Application servers are responsible for all
data processing.
T HREE -TIER M ODEL

The three-tier model of distributed client/server processing includes a client services
tier, business services tier, and data services tier.
Tier
Description
In Monitor Pro
Client
Also known as the
Services user interface, this
tier is positioned
closest to the user.
Consists of the graphical user interface for

operators and/or developers. If a client connects to
multiple servers, information is displayed as if it
were coming from a single server.
Business Processes data and

Services provides information
to the client services
tier.
Consists of the Monitor Pro server that supports

the collection, processing, and logging of data. The
Monitor Pro server includes application
configuration data, run-time tasks, and a real-time
database.
2 | DISTRIBUTED ARCHITECTURE
Three-Tier Model
Tier
Description
Data
Stores and manages
Services an organizations
historical data.
In Monitor Pro
Consists of a Standard Edition Microsoft SQL

Server 2000 database (shipped with Monitor Pro),
which provides advanced storage functionality and
management of historical data. Monitor Pro
supports ODBC-compliant databases as well as
provides native interfaces to Oracle and Sybase.
Due to its architecture, Monitor Pro is inherently scalable. The client, business, and
data services tiers can be distributed among computers in any manner, which provide
incredible flexibility to the organization. Small applications can exist with all three
tiers residing on a single computer. Larger applications can be distributed to separate
computing resources.
Typical topologies for Monitor Pro include:
Single-station architecture for small applications
Multi-station architecture for medium and large-sized applications
Distributed architecture for communication between separate applications
Redundant architecture for high availability and fault-tolerant applications
DISTRIBUTED ARCHITECTURE | 2
Development and Run-Time Systems
D EVELOPMENT
AND
R UN -T IME S YSTEMS
Monitor Pro Client Access Licenses (CALs) are required for any user who configures
or accesses run-time data (using OPC or any other means) from a server. Clients have
the capability to access one or multiple servers over the network, or clients may be
installed on the same computer as the server that holds their license.
Monitor Pro development/run-time systems are used to develop applications locally or
remotely. They can be used to run a Monitor Pro application. Additional CALs may be
purchased for distributed applications. Development CALs and Run-time CALs are
available. Development systems come bundled with one development CAL.
Development CALs and Run-time CALS may be added to development/run-time
systems.
Development CALs contain configuration tools to develop server applications and
client projects and can be used for concurrent development. Each Monitor Pro
development CAL includes the Configuration Explorer for building the server
application and Client Builder for building the client project. The Application Editor
is included for backward compatibility with pre-7.0 Monitor Pro systems (with ECS
Graphics) and only supports development on the local system.
Run-time CALS can be used to access server applications locally, but do not have
configuration capability. Monitor Pro run-time only systems are used to run a
completed application and cannot be used for development purposes. Run-time only
systems come bundled with one run-time CAL. Additional CALs may be purchased
for distributed applications, but only run-time CALS can be added to run-time
systems.
2 | DISTRIBUTED ARCHITECTURE
Scalable System Sizes
S CALABLE S YSTEM S IZES

Monitor Pro is designed to run Monitor Pro applications of various sizes, with limits
defined for the number of external inputs and outputs (I/O Tags) to the system and
total number of tags defined in the system (Total Tags). Versions with smaller tag
counts offer all of the same features as the unlimited version, as long as the same
options are purchased. Check with your Monitor Pro for available sizes.
Developer-Defined Maximum Tags (Total Tags)
Except for the unlimited version, Monitor Pro is designed to process a limited number
of developer-defined, real-time database tags per application. A licensing agreement
determines the total number of tags available. This total is in addition to the
predefined tags provided with a new, blank application.
All tags of tag arrays are counted towards this total. Each time you configure a tag
during configuration, Monitor Pro adds it to the total count of tags defined for that
application. At run time, Monitor Pro checks the application to determine the number
of developer-defined tags. If the application has more than the licensed number of tags
defined, the application will not run. With a conversion fee, the Monitor Pro system
can be converted to a larger size Monitor Pro system.
Input/Output Maximum Tag (I/O Tags)
Monitor Pro contains tasks for connecting to external devices. An I/O tag is any tag
that is the source or target of any Monitor Pro I/O task. An I/O task is any task that
communicates directly with an external device, such as a computer, a PLC, or nodes
on a network. These I/O tasks and their associated tags are a subset of the maximum
number of tags you can configure for an application. Monitor Pro is designed to
process up to the maximum number of I/O tags in any of the I/O tasks provided or sold
as options.
Chapter 3
Features, Tasks, and Tools
M ONITOR P RO TASKS
Monitor Pro is a set of programs that perform specific activities in the automation
process. Some activities are:
Reading and writing data to or from external devices, such as programmable logic
controllers (PLCs) and remote terminal units (RTUs)
Collecting, manipulating, and storing data
Alarming
Generating reports
These programs are referred to as tasks because they are independent programs that do
only one specific job or task alone, but together make an application fully functional.
At run time, Monitor Pro tasks gather, process, communicate, and present data
through the real-time database using a group of user-selectable options. Most tasks are
included in the base Monitor Pro system at no additional charge. Some important tasks
are described in this section.
Graphical User Interface
Client Builder
Client Builder, Monitor Pros graphical user interface, is an OPC client that
communicates with the Monitor Pro Server and other OPC servers. For supervisory
control, instructions can be sent from Client Builder to the Monitor Pro Servers
real-time database and from there to the plant floor.
Client Builder supports alarming, trending, and historical data browsing functionality
using ActiveX controls. Each of these functions has an ActiveX control that requires
minimal configuration to achieve a fully functional system. Prior to Monitor Pro 7.0,
the graphical user interface for Monitor Pro was called ECS graphics. Screens in this
format are compatible with Monitor Pro 7.2 and later and may be used inside of Client
Builder graphics. Client Builder is discussed in more detail later in this chapter.
3 | FEATURES, TASKS, AND TOOLS

Monitor Pro Tasks
Application Editor
Application Editor, a pre-7.0 Monitor Pro tool, is used to draw and animate graphical
screens for the Monitor Pro application. Application Editor is used to build and edit
ECS graphics only and is included for support of pre-existing applications. Typically,
Application Editor is not used for a new application.
Device Interfaces
Monitor Pro uses device interfaces to gather data from devices such as PLCs and
RTUs. In addition to vendor-specific interfaces (for equipment from companies such
as Schneider Electric, Omron, Rockwell, Siemens, and GE Fanuc), Monitor Pro
provides an OPC interface that can be used to collect information without requiring
device-specific drivers. Additional interfaces are available, if desired. Consult your
authorized reseller or representative for the most recent list of available interfaces.
FEATURES, TASKS, AND TOOLS | 3

Monitor Pro Tasks
Dynamic Data Exchange

Dynamic Data Exchange (DDE) updates data automatically and regulates how and
when data is passed between programs such as Microsoft Word or Excel.
OPC Data eXchange (ODX)
ODX is an enhanced OPC Client used to communicate with PLCs and other
OPC-compliant devices. ODX eliminates the need to purchase a proprietary device
interface in many systems. Not only does this reduce the cost of the software, it
ensures the use of a standard protocol, making the system easier to maintain and
upgrade. ODX is included as a standard part of each Monitor Pro system.
Enhanced Communication Interface (ECI)
An Enhanced Communications Interface (ECI) supports scaling, data conversion, and
a variety of statistical calculations. ECI is essentially an I/O translator that provides an
interface between various device interfaces and the Monitor Pro real-time database.
The ECI task supports various types of Monitor Pro device interfaces, including OPC,
RAPD, and EDI. ECI is included as a standard part of each Monitor Pro system.
XML Adapter
The XML Adapter enables web-based applications to read and write Monitor Pro
real-time data using an XML document. This option is a separate program that can be
installed on the Monitor Pro server machine. The XMLAdapterInstall.exe program is
located in the C:\Program Files\Telemecanique\FactoryLink\Installs directory.
This program installs a new COM component that can be used from applications that
support COM, including ASP pages on an IIS web server, VB/VBA applications,
Active Scripting hosts, and C/C++ applications. It also installs example web pages. To
run the demonstration, you must start the Examples Application, open an Internet
Explorer window, and navigate to the examples at http://localhost/XMLAdapter.

Monitor Pro Tasks
General Tasks
Timed Events and Intervals
The Event and Interval Timer task defines timed events and time intervals that can be
used to initiate and control any system function. Timed events occur at a specific time
not more than once every 24 hours, whereas time intervals occur at least once every 24
hours at regular intervals. Timed events and intervals link to real-time database tags
that are used as triggers to other Monitor Pro processes.
Programmable Counters
The Programmable Counters task provides totalizers and event delays. Outputs from
counters can be used to provide inputs to other Monitor Pro processes or to trigger
events.
Real-time Database Browser and Debugger Tool
The Database Terminal (DBT) is an on-line real-time browser that supports read/write
access to a Monitor Pro application to provide enhanced debugging capabilities.
Advanced functionality is provided for viewing data including filters, wildcards,
spreadsheet style display, change counters, and data format selection (ASCII, binary,
hex, octal, decimal, exponential). Remote browsing is also supported.
Batch Recipe
The Batch Recipe task stores recipes on disk for manufacturing a product. These
recipes can be sent to an external device at a given time to control the product
manufactured.
Persistence
The Persistence task saves the values of an active Monitor Pro application at
predetermined times so if Monitor Pro shuts down unexpectedly, useful data is not
lost.
Print Spooler
The Print Spooler task directs data to printers or other devices with parallel interfaces
and also to disk files.

Monitor Pro Tasks
Scaling and Deadbanding
The Scaling and Deadbanding task converts or scales incoming raw data to a different
value range and indicates a dead or non-recalculating band around a scaled value.
(New applications use IOXlater or ECI.)
Interpreted Math and Logic Operations
The Interpreted Math and Logic task uses a programming language to perform
operations of a mathematical or logical nature on combinations of tags in the real-time
database. Each math and logic operation, controlled by a procedure resembling
BASIC, is based on user-defined variables, and is triggered by events in the real-time
database.
Compiled Math and Logic Operations (Optional)
The Compiled Math and Logic task is used for applications that have a large number
of calculations in the server application. It is used in conjunction with a C compiler
and provides more flexibility and performance than Interpreted Math and Logic.
Event Time Manager
The Event Time Manager (ETM) task allows the configuration of objects, functions,
and parameters for a specific schedule. Users simply build an event list and schedule
the actions based on selected criteria for the objects. Event information is stored and
retrieved from any formatted flat file allowing for rapid event scheduling of multiple
points.
Utilities
Monitor Pro provides utilities for general maintenance and troubleshooting. All
utilities can be started from a Command Prompt window and many can be started
from the Configuration Explorer.
In Configuration Explorer, the utilities are accessed from a menu that appears when
you right-click your server computer name or your application name. The output
window in the Configuration Explorer displays the system processing messages when
utilities are started. The Utilities Guide provides detailed information about each of
the Monitor Pro utilities.

Monitor Pro Tasks
Logging and Retrieving Data

Alarms and Events
System-wide event logging capability is supported to ensure the logging of three

primary event types:
Events from within the Monitor Pro system, such as a network problem or a
software task error
Events from the PLC or other control system, such as a circuit breaker tripping, a
pump stopping, or a cycle finishing
Operator interactions, such as when an operator logs in, starts a pump, or
acknowledges an alarm
Distributed Alarm Logger
The Distributed Alarm Logger checks real-time data for permitted limits, generates
alarms if limits are exceeded, and copies the alarms to a historical disk-based
relational database. Alarms represent a subset of events and are configured based on
any event within the system. Alarms are specifically intended to alert operators to
situations that may require their action.
Client Builder includes an Alarm Viewer that provides for viewing and
acknowledging alarms or events in the system. It has filtering and sorting capabilities
to make the information more useful to the operator. Events and states of various
objects can also be viewed from the alarm viewer.
Alarm E-mail Notification
An alarm or event defined in the alarm logger can be configured to use the e-mail
notification agent to acknowledge an alarm by using an e-mail reply from contact
recipients in a notification group. If a contact fails to be notified within a specified
amount of time, the alarm notification can be escalated to an alternate contact. Other
contacts who are not required to acknowledge the alarm can be designated to receive
an alarm notification.
Operator Event Logging
Operator Event Logging allows Monitor Pro to track and users to analyze all operator
actions and client events to provide the information necessary to comply with
company requirements or industry and government standards.

Monitor Pro Tasks
Logged events include tag value changes from the client, operator login/logout, and
client connection/disconnection.
Operator Logbook
The operator logbook allows operators or other users to enter notes about alarms or
events. The information is saved in a relational database for later reporting and
analysis. The logbook is useful for applications that must comply with regulatory
requirements.
Report Generator
The Report Generator task can create reports based on data in the real-time database.
Reports are flexible in format and can be generated as files or printed reports. The
Report Generator can also generate reports in XML format. These reports can be used
to interchange information over the Internet with other applications that understand
XML or can be formatted as HTML-viewable web pages.
Note: Reports can be also be created using third-party software such as
Microsoft Access and Crystal Reports to access historical data logged to an
external database, such as SQL Server, Oracle, or Sybase.
Historical Reports
The Monitor Pro Historical Reports are pre-configured reports that provide secure
access to electronic data through standard reports to match the most stringent
requirements of regulatory applications. The included reports cover the basic
requirements of 21 CFR Part 11, the FDA guidelines for trustworthy electronic
records. The reports are developed in Microsoft Access and the source is provided for
customization if desired. For more information, see Historical Reports on page 29.
Historian
The Historian task communicates with external databases to create, write to, read
from, and update database tables. It processes data requests from other Monitor Pro
tasks and sends them to the external database. The Historian acts like an interface
between Monitor Pro and the database. The Historian is specific for a particular
database product. The supported databases are:
SQL Server 2000
Oracle 10
Sybase System 12

Monitor Pro Tasks
Other relational databases with ODBC support, such as Informix and DB2/2
dBASE IV (for support of pre-7.x applications)
Native Oracle Historian Interface
The Oracle Historian task provides a native interface to an Oracle 10 relational

database. It processes data requests from other Monitor Pro tasks to write data to or
retrieve data from the relational database.
Native Sybase Historian
The Sybase Historian task provides a native interface to a Sybase System 12 relational
database. It processes data requests from other Monitor Pro tasks to write data to or
retrieve data from the relational database.
Data Point and Database Logging
Data Point Logging simplifies the task of logging data using preconfigured tables.
Multiple shared numeric-value tags can be stored in the same database and sorted later
if necessary. Data Point Logging captures the time, the tag name, and the tag value for
the tags specified.
Database Logging allows users to create a table and specify which tags to capture in
that table. When the value of any tag in the table changes, the values of all tags in the
table are logged. Database Logging provides the ability to group tags in a database
table.
Real-Time and Historical Trend Controls
The Trend controls provided in Client Builder allow users to view the real-time or
historical evolution of any tags previously configured for logging. Tag values are
displayed graphically using either a line graph or a bar graph. Trending handles
multiple points (up to 8 trends per viewer) and supports panning and zooming. A wide
variety of pen styles and colors can be configured easily and property changes can be
customized on-line.
Database Browser Control
The Database Browser control provided in Client Builder connects to a relational

database, such as SQL Server, and allows operators to view, sort, and filter data in a
tabular fashion from the database.

Monitor Pro Tasks
PowerSQL
The PowerSQL (Structured Query Language) task works in conjunction with the
Historian tasks to allow an application to access data in an external relational database
through a result window. In addition, PowerSQL processes SQL statements that are
entered in a Monitor Pro message tag.
PowerSPC (Optional)
The PowerSPC (Statistical Process Control) task contains many standard statistical
calculations and charts. It works in conjunction with the Monitor Pro Historian task to
allow an application to store and access real-time statistical data in an external
relational database. The PowerSPC task is supported for ECS graphics only.
Communicating Across a Network
VRN and Redundancy
The Virtual Real-time Network and Redundancy (VRN) task provides networking and
redundancy functionality for Monitor Pro.
VRN facilitates the creation of redundant Monitor Pro applications. It does this by
mirroring a selectable portion of the Monitor Pro real-time database. It allows two
identical Monitor Pro applications to operate in a master/slave configuration. In this
capacity VRN supports master/slave arbitration, real-time data synchronization, and
alarm system redundancy. VRN requires virtually no configuration work. Tag
selection is done by a simple list that allows for the use of wildcards. A typical setup is
shown below.
FLOCX
FLOCX is an ActiveX control designed to interface with the OLE Server task to allow
a connection to non-Monitor Pro programs that also support OLE communication.
File Manager
The File Manager task manages files on local drives or remote servers and transfers
files from one station to the next.

Monitor Pro Add-Ons
M ONITOR P RO A DD -O NS
The Monitor Pro Add-On modules provide a tight integration with the Schneider
Electric family of controllers as well as added benefits to users when configuring
applications. The base Monitor Pro system includes the following add-on modules.
PLC Diagnostic Viewer
This module adds the ability to retrieve, view, and acknowledge PLC diagnostic
messages in a Monitor Pro system. PLC diagnostics are integrated into the system just
like any other Monitor Pro alarm, and therefore can use the standard alarm logger,
viewer, and archival tools. The Diagnostic Viewer supports Premium TSX57 PLCs
using XWAY protocols (via the TECOM driver). The Diagnostic Viewer can also obtain
PLC diagnostic data by interfacing with the OFS Server (v3.20 or later)
Unity Pro Browser
This configuration tool gives the user an easy way of configuring Monitor Pro tags
based on Unity Pro variables. This is done by directly connecting to a Unity Pro
project or by importing a Data Exchange export file.
Starter Application Customizer
This module allows the user to easily and quickly add support into an application for
any of the XWAY, S1000, or Modicon PLC types. Pre-defined sets of tags and other
configuration information can be added to any user application, including the starter
application.
The customizer adds tags and populates tables with most of the information required
to begin communicating with the selected PLCs almost immediately. Some additional
settings are usually required to define the specific PLC addresses and communication
channels to be used.
Symbol Databases Linker
This module allows the user to automatically configure the communication

configuration tables of an application using the symbol definitions provided in a PLC
application. The Symbol Databases Linker also checks and maintains the consistency
of the Monitor Pro configuration with the variable definition in the PLC.

Multilingual Systems
OFSLinker
This module allows users to set up the OPC Factory Server using connectivity to a
concept database.
Telemecanique File Transfer
This tool allows users to transfer an application program or data in the form of Wi
words from a TSX Series 7 PLC or a TSX 37/57 PLC to a logical device accessible by
Monitor Pro and vice-versa (hard disk, diskette, server disk). This tool can also
compare the contents of two accessible devices (programs or Wi data) and start/stop a
TSX Series 7 PLC. The Telemecanique File Transfer function does not allow the user
to display or modify the program or the data transferred.
M ULTILINGUAL S YSTEMS
Monitor Pro was built with global companies in mind. Monitor Pro can be installed in
English, French, or German. Client Builder supports other languages as well, with
system menus and dialog boxes in English, French, German, and Spanish. Client
project screens can be built to display any language desired.
Monitor Pro provides the ability to display the same application data on one client in
one language and on another client or clients in a second or third language. For
example, an application for the Channel Tunnel might display data in French at the
French side of the tunnel and in English at the other side.
Client Builder provides a default file with several languages and roles predefined. For
detailed information about how Monitor Pro manages languages and roles and how
you can add additional languages and roles to a Monitor Pro system, see the Client
Builder Help.

Configuration Tools
C ONFIGURATION TOOLS
Monitor Pro provides both development and operational functionality. You configure
and maintain the system using two application development tools: Configuration
Explorer for configuring the server component and Client Builder for configuring the
graphical user interface on the client tier.
Configuration Explorer
Configuration Explorer supports a multi-user, client/server configuration environment
where multiple users can configure multiple servers concurrently from any machine
on the network. Configuration Explorer presents an environment that is highly
intuitive to those with experience using Microsoft products. It provides access to the
Monitor Pro tasks in a tree view, much like Windows Explorer.
Menu Bar
Toolbar
Namespace
entries in the
Navigation
window
Workspace
area
Output Window
Status Bar
The tree-view navigation window on the left-hand side of the Configuration Explorer
main window is the key navigation window that provides a hierarchical view of
Monitor Pro system servers and OPC servers. Users can navigate to these servers to
configure them. Beneath the Monitor Pro servers, the tree view shows the associated
server applications and their related tasks in a hierarchical fashion.

Configuration Tools
A task must be configured to make it part of the application. Every task has at least
one configuration table, depending on the job the task performs in an application. A
task is configured by completing its associated configuration tables.
Double-clicking a task item in the tree will open the appropriate editor for that item.
Grid Editor
When a table icon is double-clicked, the Grid Editor opens. The Grid Editor is used
to edit the configuration tables as well as provide a traditional grid view of the task
(records listed down the page in a table).

Configuration Tools
Form Editor
When a record icon is double-clicked, the Form Editor opens. The Form Editor
displays the fields for one single configuration record. Navigation buttons at the
bottom of the form allow the viewing of previous and next records.

Configuration Tools
Math and Logic Editor
Double-clicking a Math and Logic procedure from the tree opens the Math and Logic
Editor, which provides an intuitive and user-friendly method for creating Math and
Logic procedures. The Math and Logic Editor includes features such as chromacoding
(text colored based on syntax) and automatic update of the trigger and variable tables
directly from the editor.

Configuration Tools
Application Objects
Application objects automate the configuration of Monitor Pro tables. Application

objects replace the need to manually enter information into multiple configuration
tables. Configuration Explorer provides the capability to define models or classes
called application objects. Application objects have the following features:
They are used to represent real-world items or devices found in the process.
They are reusable and have inheritance.
Each replication of an application object class is called an instantiated object.
If an application object class is modified, all instances derived from that class
would be modified automatically. Additionally, a class can be configured to obtain
its parameters from a variety of places including an Excel spreadsheet, text file, any
ODBC data source, or manual input.
Application objects permit preconfigured system configuration for specific types of
applications. While software developers concentrate on software objects, and domain
experts configure application-oriented classes (domain layer), an application team
uses application objects to quickly construct and tailor the system for a specific
application.
An application object is constructed by aggregating built-in objects and other existing
application objects into a new class. The subobjects and their connections define the
functionality of the application object. Using application objects in development can
greatly reduce the total cost of ownership of the system, especially for large projects.

Configuration Tools
Client Builder
Client Builder is the tool to create and configure the graphical user interface for
Monitor Pro applications. Client Builder allows the development of graphical screens
(called mimics) that display when the application is run. The following graphic shows
a sample application mimic in design mode.
The Examples Application (discussed on page 93) provides many sample screens that
demonstrate the features in Client Builder, as well as many libraries of images that can
be used in applications.
Client Builder exchanges data with the server through its OPC connection. Animation
is possible during run time using links between graphical objects and real-time tags on
the Monitor Pro server. In addition to mimics, Client Builder allows standard viewers
such as the Alarm, Trend, and Database Browser controls to be embedded within
displays. These controls are configured in the Client Builder environment. It is also
possible to embed third-party ActiveX controls within Client Builder mimics.
Monitor Pro ECS graphics screens (in Monitor Pro 2.1 or earlier) can be used inside
Client Builder, so it is easy to upgrade from an older version of Monitor Pro. Both of
these graphical interfaces are provided with Monitor Pro development systems.

Configuration Tools
Customization is supported in Client Builder through Microsoft VBA scripting. All

animations and functions available at run time are accessible programmatically.
Client Builder supports online configuration by providing the capability to develop
and test graphics within the same environment.
Client Builders main characteristics include:
Client Builder elements can be edited, combined, and stored in libraries for reuse in
multiple projects. This applies to graphical symbols, configured mimics, control
panels, templates, and scripts.
Client Builder includes a comprehensive library of graphical images that can be
used to create symbols to represent anything from a simple button to a complex
piece of equipment that includes numerous animations.
Drawings and symbols can be rotated, mirrored, aligned, grouped, ungrouped,
locked, unlocked, dragged and dropped, and animated.Access to undesired

keystrokes can be locked to prevent access to the underlying operating system.
Symbols are class-based and object-oriented. Each time a symbol is modified, all
replications or instances are automatically updated graphically as well as in data
base links. Symbols and libraries can be predefined or user-defined.
Client Builder supports Java Bean functionality.

Custom Development Tools
C USTOM D EVELOPMENT TOOLS

The optional Programmers Access Kit (PAK) is a collection of Monitor Pro software
tools and related documentation that allows developers to design and construct
Monitor Pro-compatible tasks. Tasks developed with the PAK are completely
integrated into the Monitor Pro system and are configured the same as
Telemecanique-developed Monitor Pro tasks.
Unlike any other open architecture system, Monitor Pro fully integrates a
customer-written task into the Monitor Pro environment. The Configuration Explorer
fully supports new tasks with full-screen editing, context-sensitive help, and
documentation utilities.
The PAK option contains a Configuration PAK (CFGPAK) that allows users to access
configuration data. The CFGPAK is a collection of software libraries, C-language
source tasks, and related documentation used to design and construct tasks that
directly manipulate the configuration databases of a Monitor Pro application.
Tasks created with CFGPAK can automate many of the operations found in
Configuration Explorer, saving users from manually importing and exporting
configuration data. For example, a PLC software package can scan the active PLC
addresses and enter corresponding read/write records into that drivers configuration
databases.
This option is particularly useful for companies that use Monitor Pro as a platform to
integrate with other products that they sell.

Custom Development Tools
Chapter 4
Historical Reports
O VERVIEW
The Historical Reports tool produces reports about the activities requiring electronic
signatures that occurred during a process cycle. A manager or regulations auditor can
generate reports for specific users, computers, IO points, and start/end dates.
Monitor Pro has four data sources for electronic records:
Operator Audit Trail
Alarm History and Associated Logbook Entries
Process Data Logged by the Database Logger
Process Data Logged by the Data Point Logger
Each of these data sources produces various preconfigured reports. Some reports
combine information from two or more of the data sources to present a full picture of
the process for a given time period. Figure 4-1 shows the historical reports window.
Figure 4-1 Historical Reports Window
4 | HISTORICAL REPORTS
Generating Reports
The Historical Reports were developed using Microsoft Access and are designed to
work with the Examples Application. Having Microsoft Access is not a requirement
for running the reports. A Microsoft Access Runtime application is provided as part of
your Monitor Pro Server installation. This application allows you to only run the
reports.
Although the reports were designed for SQL Server, the source code is provided so the
reports can be customized for either a different database or unique database and table
names. You can view the historical reports using Microsoft Access or the Access
RunTime Viewer, or you can create custom reports using Microsoft Access. You must
have a full version of Microsoft Access to customize the reports. If you want to use the
reports in a Web-based system, Microsoft has tools you can use to migrate Access
projects to Reporting Services and to single Web pages.
Historical reports can be run from any location on your LAN or WAN, providing that
the location has network access to the database server that stores your Monitor Pro
historical data.
The Historical Reports reside in the Applications shared folder on the Monitor Pro
server so that all people in the plant have access to the reports.
G ENERATING R EPORTS
1 If Microsoft Access or the Access RunTime Viewer is not installed, see the
Installation Guide to install the viewer. For proper reporting, the user language needs
to match the language of the operating system, as explained in the Installation Guide.
2 Choose one of these methods to start the Historical Reports:
If running the historical reports on a Monitor Pro system, click Start > Programs >
Monitor Pro > Historical Reports.

If running the historical reports on a system where a Monitor Pro Client is not
installed, use Windows Explorer to browse to the Applications shared folder on the
machine where Monitor Pro is installed. Open the Historical Reports folder and
double-click Historical Reports.adp.
3 When the Security Warning appears, click Open. (This security warning appears each
time you run the Historical Reports.)
HISTORICAL REPORTS | 4
Generating Reports
4 At the Logon screen, type the username and password for a SQL Server user that has
read access to your historical data and then click OK.

The Reports Data Linking dialog box appears and automatically starts to connect the
project to the FLINK database at the (local) SQL Server.
5 When the connection status is successful, click Continue to connect to the default
FLINK database. The Historical Reports window appears (see Figure 4-1).
You can connect to a different database by clicking Advanced Data Source Configuration
and entering the desired database name and associated login information. Click OK
and then click Continue to connect to this database.
6 Click a report to open a dialog box similar to the one in Figure 4-2. Select the criteria
you want to use to query the electronic document for user activity for a specified time
period. (You can type the start/end dates, click the arrow and select a date from a
calendar, or click a time period quick button.)
Figure 4-2 Operator Audit Trail Report Query
The process data reports have an option on the query screen that allows you to add
statistics to the bottom of the report. If the Show Max/Min/Avg Values check box is
selected, the column for the specified time period displays the minimum, maximum,
and average values reports as well as the logged data.
Generating Reports
7 To select the columns to display and change the width and order of the data in the
selected report, click Advanced. A dialog box similar to the example in Figure 4-3
opens.
Note: The number of columns you select to display along with the width of the
columns specified may exceed the available space for the report. If this
condition occurs, a message appears instructing you to adjust the field widths.
Figure 4-3 Customizing Reports
Specify the column
width for the item
Select to have the item

appear on a separate line
Specify your
own SQL
WHERE clause
Either select to have the item

appear in the report or clear to
not display the item in the report
Use arrows to set the order

the items are to display
8 After setting the criteria for the report, either click Preview to view the report
immediately or click Print to send the report to a configured default printer.

Note: To select a printer different from the default printer or to specify a range
of pages in the report to print, click File > Print in preview mode.
Figure 4-4 shows a sample report for the activities done by the MyAdministrator user.
HISTORICAL REPORTS | 4
Generating Reports
Figure 4-4 Operator Action Sample Report
Generating Reports
Chapter 5
Internal Architecture
Monitor Pro is a modular system of individual tasks that perform separate functions.
These tasks communicate and share data with one another through the real-time
database.
The Monitor Pro system provides the following advantages over systems that rely on
real-time Inter-Process Communications (IPC) through passing buffers or sharing
files:
Tasks maintain their independence and inherent compatibility with one another.
Data formats for interfaces will not change unpredictably
Tasks can hand off the inter-process communication to the database function, which
acts as an intermediary, meaning less time is spent waiting for another task to
acknowledge error-free receipt of data.
Functions, conditions, or events that can be related through the use of a common tag
allow you to create custom applications without programming. Instead, you select,
configure, and link different programs to exchange information freely in real time.
5 | INTERNAL ARCHITECTURE
Open Software Bus
O PEN S OFTWARE B US
Monitor Pros internal architecture is based on Telemecaniques Open Software Bus
architecture. The patented design of industrys only Open Software Bus (U.S. Patent #
4,908,746) is a key factor in the success of the Monitor Pro product line.
The Open Software Bus architecture permits commonly used system functions to be
modularized into independent tasks (programs) that run concurrently in a multitasking
operating system environment. The tasks interact with each other by communicating
with and sharing a global, real-time database in which all programs have access to all
real-time data.
The architecture provides a flexible development platform. It is extensible and
completely open. Tasks can be added or removed without affecting other tasks or
existing applications. The application program interface (API) to the global, real-time
database is standardized and published along with utilities in a Programmers Access
Kit (PAK), enabling users to add their own tasks that operate like standard Monitor
INTERNAL ARCHITECTURE | 5
Open Software Bus
Pro tasks. Custom tasks developed with the PAK can be plugged in just like
Telemecanique-developed tasks.
The Open Software Bus architecture provides superior speed and performance:
The real-time database is resident in high-speed random access memory.
Exception processing is performed by the real-time database. Tasks only access and
process changes when needed. This eliminates unnecessary activity by the
computer and on networks.
CPU resources are dynamically allocated between Monitor Pro tasks that have
changes to process.
High-speed, bidirectional block transfers between tasks and the real-time database,
triggered either by changes or events, assure maximum performance and
communication.
Block transfers of data to and from PLCs and other equipment can be triggered by
any system event, calculation, previous reading, operator command, or time.
Monitor Pro tasks communicate through the software bus in real time using tags. For
example, a bar graph in the client interface can be linked to a value read from a PLC
by referencing the name of the tag containing the value.
Real-Time Database
R EAL -T IME D ATABASE

Monitor Pro tasks communicate and share data with one another through the real-time
database. Tasks share information by reading from or writing to the real-time
database. Data is never passed directly between two tasks.
The real-time database contains all the data values to be shared between the
application tasks. When configuring the Monitor Pro application, the developer
defines which values are to be held within the real-time database. These values are
given a unique tag name and a unique location within the real-time database.
Tag Names
pump1_tmp
pump2_tmp
pump3_tmp
(Logically represents
a tag in database)
Real-time database
Tags
The database contains data that is:

Collected from a remote device
Computed by a Monitor Pro task
Manually entered by a user
When data is collected and updated in the database, other tasks can access and
manipulate the data. A task can write information to a tag in the real-time database
using one of two types of writes: a normal write or a forced write.
Normal writes only write to a tag in the real-time database if the new value is different
from the existing value. In this way, system resources are not used unnecessarily.
Forced writes write to a tag whether or not it has changed. You use this type of write to
make a tag appear to have changed value even if the data has not changed.
A task gets the value of a tag in the real-time database using a read operation. Once the
task has this value, it can perform functions on the value, such as displaying the value
Real-Time Database
on a mimic, transmitting the value to an external device, or sending the value to a

relational database for archiving.
Read or write operations can be triggered by an event (such as when a product passes
an electronic eye) or can occur only if the tag changes. A read or write operation that
occurs only when the data changes is referred to as exception processing. Because
large blocks of data can be transferred between tasks, and because only the changed
values are processed, exception processing significantly optimizes performance.
Exception processing is possible because of the structure of the Monitor Pro real-time
database tags. A real-time database tag consists of two parts, the tags value and the
tags change status. When a tag in the database is written, its change status is
automatically set by Monitor Pro and each Monitor Pro task has a mechanism to
determine the tags change status.
For more details about the structure of the real-time database and how Monitor Pro
does exception processing, see Real-Time Database and Tag Structure on page 129.
It is especially important to understand these concepts if you plan to develop
applications that include Interpreted or Compiled Math and Logic programs.
Monitor Pro Tags
M ONITOR P RO TAGS
Tags contained in the real-time database are assigned a logical tag name. This tag
name is used by Monitor Pro tasks to reference the tag in the real-time database during
configuration. Once a tag is defined, you can make unlimited references to it. Any
Monitor Pro task containing a reference to a tag can read and write data to and from
the tag at run time.
During development, Monitor Pro stores tag names in the FLAPP directory in the
object database table. This information is updated in the Configuration Table (.CT)
files when the run-time application is started.
Tag Naming Guidelines
Valid tag names conform to the following syntax:
[<node>:]<name>[<dims>][.<ext>]
<node>
<name>
<dims>
<ext>
Optional node name used by PowerNet, which can be a variable.

Maximum 8 characters.
Name of tag. Maximum 32 characters, including node, dimensions, and
extensions, and separators (: and .).
If using Scaling and Deadbanding, the character count is reduced to 25.
If using PowerNet, the character count is reduced to 23.
If using Scaling and Deadbanding with PowerNet, the character count is
reduced to 16.
If you are not sure if you will use PowerNet or Scaling and Deadbanding,
it is recommended you define tag names using only 16 characters.
Array dimensions. Maximum16 characters. See Tag Arrays on page 48.
Monitor Pro-created extension added when Scaling and Deadbanding is
applied to a tag. Maximum 6 characters. Additional characters reduce the
maximum length of the tag name by up to 7, because of the period
delimiter.
Legal characters for the <node>, <name>, and <ext> strings are:
{A-Z}
{a-z}
{0-9}
{@$_}
These strings cannot begin with a number or contain spaces.
Monitor Pro Tags
Tag Naming Recommendations

When naming your tags, follow these general recommendations:
Use a consistent naming system throughout the plant.
Have a hierarchical structure so that you can support branching. For more
information on branching, see page 50.
Begin related tags with the same first-level branch name (the name before the first
_ delimiter) if you want the tags grouped together for listing and linking purposes.
This makes testing and troubleshooting much easier.
Incorporate the type of process, unit, and location in the name, but not in addresses
or references that may change during the lifetime of an item.
Have a way to distinguish user-defined tags from internal system tags.
Distinguish between process-related and system-related objects; for example, a
motor including all of its I/O signals may be part of the process, whereas the I/O
card that takes the signals may be part of a PLC system.
Define virtual objects including all I/O signals and interface borders.
Plant-related hardware inputs/outputs (such as push buttons and feedback signals)
should use the same tag-naming concept to indicate the devices (such as machine,
switch, or source within the plant) to which it belongs.
Do not start the name with a number.
Try to name each tag in a way that describes its purpose.
Defining Tags in Configuration Explorer
To create a tag, enter a new tag name into any Tag Name field in Configuration
Explorer. When you save the configuration, the Tag Editor will appear for you to
complete the tag definition.
Monitor Pro Tags
The type of data that can be stored in the tag depends on where the tag is specified.
Monitor Pro uses the following data types:
Data Type
Analog
Digital
Float
Longana
Message
Mailbox
Description
A 16-bit, signed integer between 32,768 and +32,767

A one-bit binary number that can be a value of 0 (off) or 1 (on)
An IEEE double-precision number with 31 places to the right of the
decimal, with a value range from +/ 10 raised to the power of +/ 308
A 32-bit, signed integer between 2,147,483,648 and +2,147,483,647
Any combination of alphanumeric characters (the length limit is set in
the tag definition Message Length field)
A unique data type that specific tasks use to communicate with each
other (The only data type that can queue data rather than overwrite the
previous value. The contents of this data type varies in length.)
The Tag Editor has an area that defines tag persistence. With tag persistence activated,
the value of the tag is periodically saved to a disk file. If a value exists in this file for a
tag, it is written to the tag when the task is restarted. This way, you do not lose
important information by exiting the task. After a tag is defined, any object in a Client
Builder screen or any task can reference the tag. See the Configuration Explorer Help
for detailed information.
Triggers
TRIGGERS
A trigger refers to a tag whose change in value causes another event to occur in the
application. Many Monitor Pro tasks use tags to trigger certain actions. Events, such
as read or write operations, can be configured to occur as the result of a trigger. A tag
can be used as a trigger by more than one task.
When a task reads a trigger tag, the reading task resets its change status and begins the
operation designated by the trigger.
Force writing a 1 to a digital tag causes its change status to appear changed even if it
does not change the actual value of the tag. This causes the events tied to that trigger
to be triggered during the next read operation. If multiple tasks are to use the same tag
as a trigger, using the forced-write technique simplifies inter-task handshaking
requirements, since each task keeps track of changes individually and automatically.
See Appendix B, Real-Time Database and Tag Structure for more details on how
Monitor Pro handles triggers and exception processing.
You can use trigger tags in many ways:
Use the complete status tag in a logger operation to initiate a different logging
operation.
Use the same tag to trigger multiple operations. For example, you can define a
single tag that triggers multiple operations at the start of each hour.
Define Interval Timer and Event Timer digital tags in the real-time database for use
as triggers.
Configure function keys as triggers.
Read and write recipes.
Execute another program.
Initiate a network transfer.
You can cause a new setpoint to be downloaded to a programmable controller.
Trigger separate polled read functions used by a programmable controller task.
Use the Math and Logic task to set triggers to start an operation.
Predefined System Tags
P REDEFINED S YSTEM TAGS

Some tags are already defined in Monitor Pro when it is shipped. Many of them are
time-related system tags that provide system-wide time information to all Monitor Pro
tasks. For example, there are tags for date, time, number of minutes past the hour, and
current month. These tags are updated at Monitor Pro startup and are continuously
updated as the system runs.
The following predefined system tags are available in all Monitor Pro applications.
Tag Name
ALARMSRV_POLL
ALARMSRV_RCVMBX
ALARMSRV_SNDMBX
ALLOG_ACTIVE_COUNT
ALLOG_AUDIBLE_COUNT
ALLOG_HIST_MBX
ALLOG_PRINT_TRIGGER
ALLOG_RCVMBX
ALLOG_SNDMBX
ALLOG_UNACK_COUNT
ALVIEW_AREA
ALVIEW_BANNER
ALVIEW_BANNER_ACK
ALVIEW_BANNER_BG
ALVIEW_BANNER_BL
ALVIEW_BANNER_FG
ALVIEW_GROUP
ALVIEW_GROUP_ACK
ALVIEW_LOGBOOK
ALVIEW_LOGBOOK_TRIGGER
ALVIEW_ROW_SELECT
ALVIEW_SCROLL
ALVIEW_SELECT_ACK
ALVIEW_SORT
ALVIEW_TEXT
ALVIEW_TEXT_BG
ALVIEW_TEXT_BL
ALVIEW_TEXT_FG
APPLICATION_DRW
A_DAY
A_DOW
A_DOY
Type
DIGITAL
MAILBOX
MAILBOX
ANALOG
ANALOG
MAILBOX
DIGITAL
MAILBOX
MAILBOX
ANALOG
MESSAGE
MESSAGE
DIGITAL
ANALOG
ANALOG
ANALOG
MESSAGE
DIGITAL
MESSAGE
DIGITAL
ANALOG
ANALOG
DIGITAL
MESSAGE
MESSAGE
ANALOG
ANALOG
ANALOG
MESSAGE
ANALOG
ANALOG
ANALOG
Domain
SHARED
SHARED
SHARED
SHARED
SHARED
SHARED
SHARED
SHARED
SHARED
SHARED
USER
USER
USER
USER
USER
USER
USER
USER
USER
USER
USER
USER
USER
USER
USER
USER
USER
USER
USER
SHARED
SHARED
SHARED
Description
Alarm Server poll trigger
Alarm Server receive mailbox
Alarm Server send mailbox
Alarm Logger active alarm count
Alarm Logger audible alarm count
Alarm Logger historian mailbox
Alarm Logger print active alarms trigger
Alarm Logger receive mailbox
Alarm Logger send mailbox
Alarm Logger unacknowledged alarm count
Alarm Viewer area filter (default = ALL)
Alarm Viewer banner message
Alarm Viewer banner acknowledge
Alarm Viewer banner background attribute
Alarm Viewer banner blink attribute
Alarm Viewer banner foreground attribute
Alarm Viewer group filter (default = ALL)
Alarm Viewer current group acknowledge
Alarm Viewer logbook entry
Alarm Viewer logbook archive trigger
Alarm Viewer selected row number
Alarm Viewer scroll value
Alarm Viewer selection acknowledge
Alarm Viewer sort method (default = ITIME)
Alarm Viewer text
Alarm Viewer text background attribute
Alarm Viewer text blink attribute
Alarm Viewer text foreground attribute
Application window current loaded drawing
Day of the month
Day of the week
Day of the year
Tag Name
A_HOUR
A_MIN
A_MONTH
A_SEC
A_YEAR
BROWSEHISTMBX
BROWSEHISTMBX_U
CONNSRVACTIVE
CONNSRVINIT
CONNSRVMBX
CONNSRVTOTAL
DALOGACKMBX
Type
ANALOG
ANALOG
ANALOG
ANALOG
ANALOG
MAILBOX
MAILBOX
ANALOG
DIGITAL
MAILBOX
ANALOG
MAILBOX
Domain
SHARED
SHARED
SHARED
SHARED
SHARED
SHARED
USER
SHARED
SHARED
SHARED
SHARED
SHARED
DALOGRCVMBX
MAILBOX
SHARED
DALOGRCVMBX_U
MAILBOX
USER
DALOGVIEWMBX
MAILBOX
SHARED
DALOGVIEWMBX_U
MAILBOX
USER
DATASRVMBX
DATE
DATE0
DATETIME
DB4HISTMBX
DBLCHISTMBX
DBLOGHISTMBX
MAILBOX
MESSAGE
MESSAGE
MESSAGE
MAILBOX
MAILBOX
MAILBOX
USER
SHARED
SHARED
SHARED
SHARED
SHARED
SHARED
DBLOGHISTMBX_U
MAILBOX
USER
DPLCHISTMBX
DPLOGHISTMBX
MAILBOX
MAILBOX
SHARED
SHARED
DYNLOGCOMMAND
MESSAGE
SHARED
DYNLOGFILE
MESSAGE
SHARED
DYNLOGFILEREAD
DIGITAL
SHARED
DYNLOGFILEWRITE
DIGITAL
SHARED
DYNLOGSTATUS
ENDOFDAY
FLAPP_S
FLAPP_U
ANALOG
DIGITAL
MESSAGE
MESSAGE
SHARED
SHARED
SHARED
USER
Description
Number of hours past midnight
Number of minutes past the hour
Month of the year
Number of seconds past the minute
Current year
Mailbox for BROWSER process
Mailbox for BROWSER process
Number of brokered services that are active
Connection server initialization flare
Connection server receive mailbox
Total number of services being brokered
Distributed AL_LOG mailbox for acknowledged
alarms
Distributed AL_LOG receive mailbox for Historian
communications
Distributed AL_LOG receive mailbox for Historian
communications
Distributed AL_VIEW mailbox for alarm
communications
Distributed AL_VIEW mailbox for alarm
communications
Data server receive mailbox
Date (day MM/DD/YYYY)
Date (day MM/DD/YYYY)
Date and Time (day MM/DD/YYYY HH:MM:SS)
dBASE IV Historian mailbox
DBLog task historian mailbox
Database Logger receive mailbox for Historian
communications
Database Logger receive mailbox for Historian
communication
Datapoint Logger historian mailbox
Data Point Logger receive mailbox for Historian
communications
Dynamic Logging command message tag for Data
Point Logger
Dynamic Logging save point file for Data Point
Logger
Read trigger to load a data point save file for Data
Point Logger
Write trigger to generate a Data Point Save File for
Data Point Logger
Dynamic Logging status tag for Data Point Logger
End of Day (23:59:50)
Application directory
Application directory
Tag Name
FLDOMAIN_S
FLDOMAIN_U
FLHOST
FLINK_S
FLINK_U
FLLANSIG
FLLANSNDMBX
FLNAME_S
FLNAME_U
FLOPERATOR_S
FLOPERATOR_U
FLSECEVENTUSER_S
FLSECEVENTUSER_U
FLSECEVENT_S
FLSECEVENT_U
FLUSER_S
FLUSER_U
GRAPHCONNTYPE
GRAPHMBX
GRAPHMBX_U
OPCSRVMBX
RTMARG
RTMARG_U
RTMCMD
RTMCMD_U
RTMPWD
RTMPWD_U
SECDAY
SECTIME
SECURITYMBX
SECYEAR
SHUTDOWN
SHUTDOWN_U
SPCDATAMBX_S
SPCDATATRIG_S
SPCGMBX
SPCGMBX_U
SPCGRPHMBX_S
SPCGRPHMBX_U
SPCRCVMBX
SPCRCVMBX_U
SPOOLREQ
SPOOLRPLY
Type
MESSAGE
MESSAGE
MESSAGE
MESSAGE
MESSAGE
DIGITAL
MAILBOX
MESSAGE
MESSAGE
MESSAGE
MESSAGE
MESSAGE
MESSAGE
MESSAGE
MESSAGE
MESSAGE
MESSAGE
ANALOG
MAILBOX
MAILBOX
MAILBOX
ANALOG
ANALOG
ANALOG
ANALOG
MESSAGE
MESSAGE
LONGANA
LONGANA
MAILBOX
LONGANA
DIGITAL
DIGITAL
MAILBOX
DIGITAL
MAILBOX
MAILBOX
MAILBOX
MAILBOX
MAILBOX
MAILBOX
MESSAGE
MESSAGE
Domain
SHARED
USER
SHARED
SHARED
USER
SHARED
SHARED
SHARED
USER
SHARED
USER
SHARED
USER
SHARED
USER
SHARED
USER
USER
SHARED
USER
SHARED
SHARED
USER
SHARED
USER
SHARED
USER
SHARED
SHARED
SHARED
SHARED
SHARED
USER
SHARED
SHARED
SHARED
USER
SHARED
USER
SHARED
USER
SHARED
SHARED
Description
Domain name
Domain name
Monitor Pro Host Name
Directory for application programs
Directory for application programs
FLLANSND system interval trigger
Mailbox for FLLANSND process
Application name
Application name
Application operator
Application operator
User name for application security event
User name for application security event
Application security event
Application security event
Application user
Application user
Graph connection and security type
Graphics input mailbox
Graphics input mailbox
OPC Server Mailbox
Run-Time Manager argument
Run-Time Manager argument
Run-Time Manager system command
Run-Time Manager system Command
Run-Time Manger password
Run-Time Manger password
Number of seconds past midnight
Number of seconds since Start of Time
Mailbox tag to log information collected by security
Number of seconds past January 1, 00:00:00
Run-Time Manager shutdown flag
Run-Time Manager shutdown flag
PowerSPC Data task receive mailbox
PowerSPC Data task initialization indicator
SPC Graphics input mailbox
SPC Graphics input mailbox
PowerSPC Graphics task receive mailbox
PowerSPC Graphics task receive mailbox
SPC receive mailbox for database access
SPC receive mailbox for database access
Print Spooler request
Print Spooler reply
Tag Name
SPRGMBX
SPRGMBX_U
SPRRCVMBX
SPRRCVMBX_U
SPVRCVMBX
SPVRCVMBX_U
STARTUP
STARTUP_U
TASKDESC_S
TASKDESC_U
TASKDSTATUS_S
TASKDSTATUS_U
TASKMESSAGE_S
TASKMESSAGE_U
TASKNAME_S
TASKNAME_U
TASKSTART_S
TASKSTART_U
TASKSTATUS_S
TASKSTATUS_U
TIME
TIME0
TOPWINDOW_U
TRENDHISTMBX
Type
MAILBOX
MAILBOX
MAILBOX
MAILBOX
MAILBOX
MAILBOX
DIGITAL
DIGITAL
MESSAGE
MESSAGE
MESSAGE
MESSAGE
MESSAGE
MESSAGE
MESSAGE
MESSAGE
DIGITAL
DIGITAL
ANALOG
ANALOG
MESSAGE
MESSAGE
MESSAGE
MAILBOX
Domain
SHARED
USER
SHARED
USER
SHARED
USER
SHARED
USER
SHARED
USER
SHARED
USER
SHARED
USER
SHARED
USER
SHARED
USER
SHARED
USER
SHARED
SHARED
USER
SHARED
TRENDHISTMBX_U
MAILBOX
USER
TRENDMBX
TRENDMBX_U
VBLOGDISABLE_S
VBLOGDISABLE_U
YYMMDD
hour1
s1process_button_action
sec1
sec10
MAILBOX
MAILBOX
DIGITAL
DIGITAL
MESSAGE
DIGITAL
DIGITAL
DIGITAL
DIGITAL
SHARED
USER
SHARED
USER
SHARED
SHARED
USER
SHARED
SHARED
Description
SPR graphics input mailbox
SPR graphics input mailbox
SPR receive mailbox for database access
SPR receive mailbox for database access
SPC View mailbox for database access
SPC View mailbox for database access
Run-Time Manager startup flag
Run-Time Manager startup flag
Shared Task Description
User Task Description
Shared Task Status Word
User Task Display Status Message
Shared Task Display Message
User Task Message
Shared Task Name
User Task Name
Shared Task Start Trigger (default = 0)
User Task Start Trigger (default = 0)
Shared Task Status Value
User Task Status Value
Time (HH:MM:SS)
Time (HH:MM:SS)
Current top window name
TREND receive mailbox for historian
communications
TREND receive mailbox for historian
communication
Trend input mailbox
Trend input mailbox
PowerVB debug logging disable
PowerVB debug logging disable
Date (YYMMDD)
One hour interval timer trigger
Style 1 process button tag used for VB events
One second interval timer trigger
Ten second interval timer trigger
Tag Arrays
TAG A RRAYS
A tag name can be assigned to a single tag or a group of tags (called an array). This
assignment creates multiple tags with a single operation. All the tags receive the same
tag definition.
One advantage of using arrays is that certain Monitor Pro tasks, such as Math and
Logic and Database Browser, can perform operations on an entire tag array using only
one reference to the array, rather than using separate references to each tag in the
array.
You specify an array by entering a value in the Array Dimensions field of the Tag
Editor. This value defines the number of tags to include in the array. Each array can
have up to 65,534 tags.
If a value is specified, multiple tags are created in the real-time database. Once
created, each tag can be referenced individually. The specified value determines
whether the array is single-dimensional or multi-dimensional.
one-dimensional
array
a list of tags indexed in sequence
multi-dimensional
array
a matrix or table containing a fixed number of rows and

columns, with more than one index.
Each tag in a two-dimensional array has a pair of indices. The
first index indicates the row and the second indicates the
column of the array where the tag is located. A
three-dimensional array has three indices.
Defining One-Dimensional Arrays

In the Array Dimensions field, specify a single number in the following format:
tagname[n]
where
tagname
[n]
is the name defined in the Tag field of the Tag Editor.

is a unique number assigned to each tag in the array starting with 0. Each
number is surrounded with brackets [ ].
Tag Arrays
For example, if you specify 4 in the Array Dimensions field for a tag named Fuel, four
tags are created in the real-time database. The array numbering starts counting at 0.
Single-Dimensional Array
Fuel[0]
Super_93
Fuel[1]
Extra_89
Fuel[2]
Regular_93
Fuel[3]
Diesel
Defining Multi-Dimensional Arrays

In the Array Dimensions field, specify multiple numbers separated by a comma in the
following format:
tagname[n1][n2]...
where
tagname
is the name defined in the Tag field of the Tag Editor.
[n1]
is a number representing the first dimension in the array, assigned to each

tag starting with 0. Each number is surrounded by brackets [ ].
[n2]
is a number representing the second dimension in the array assigned to each

tag starting with 0. Each number is surrounded by brackets [ ].
For example, if you specify 7,3 in the Array Dimensions field when you create a tag in
the Tag Dictionary named Super_93, 21 tags are created in the real-time database. (If
you enter Super_93[6][2] in a Tag Name field in a configuration table, the same 21
tags are created.) The array numbering starts counting at 0.
Multi-Dimensional Array
Super_93[0][0]
Super_93[3][1]
Super_93[4][2]
Super_93[6][0]
Region 1 Region 2 Region 3

Jan
Feb
Mar
Apr
May
June
July
1.45
1.56
1.63
1.67
1.79
1.82
1.73
1.80
1.77
1.74
1.69
1.64
1.70
1.76
1.23
1.25
1.27
1.33
1.38
1.31
1.28
Super_93[6][2]
Branching
B RANCHING
A branch is a group of tags in a hierarchical data structure. With branching, the
Variable Browser does not access and display all tags in the Monitor Pro database.
Instead, only the tags that belong to the branch are accessed and displayed. This
feature significantly improves system performance and lowers development time,
because it is much easier to find tags that are organized in this fashion.
A simple example of a hierarchical data structure is shown in the following graphic.
The branches in this example are Area1, Pump1, Pump2, and Pump3. The actual tags
in this system are the Upstream Pressure, Downstream Pressure, and Speed. To
represent this hierarchy in a database, the following naming convention is used, with
each of the following names representing a single tag:
Area1_Pump1_UpstreamPressure
Area1_Pump1_DownstreamPressure
Area1_Pump1_Speed
Area1_Pump2_Speed
Area1_Pump3_Speed
Branching
To configure the first symbol in the example, you create the graphical representation
of the object and then animate the graphical representation by referencing tags
contained in a single branch. The symbol may not reference tags from multiple
branches.
For subsequent instances of this symbol, you are only required to specify the name of
the branch to identify which set of tags are used for the animation. The symbol
automatically provides the references to the tags beneath this branch.
For symbols with large amounts of animation, this is a large productivity gain. With
this functionality, you can quickly create the mimic shown in the following graphic.
All the work is put into the first symbol. You cut and paste this symbol multiple times
and then change the name of the branch to identify a different set of tags for the
symbol to reference.
The number of hierarchy levels that can be defined is limited only by the maximum
length of the Monitor Pro tag name (32 alphanumeric characters).
Branching
The mimic shown in Figure 5-1 can be built quickly using branching functionality.
Figure 5-1 Branched Mimic.
With scripting, you can change the name of the branch at run time. For example, the
pump symbol and buttons can be combined and can be used to show the data for
various pumps on one mimic. The difference is that the operator must press the
Previous and Next buttons to view the data from the other sets (branches) of pump
tags. The name of the branch can be specified on a mimic open action so the same
mimic can be opened from different buttons and the data displayed would be from the
branch specified in the mimic open action.
Combining the above functionality with application objects provides a powerful

configuration environment. Application objects provide the ability to define a set of
tags as a class (class and branch are synonymous) and instantiate this set of tags many
times.
Branching
To maintain the system, the user changes the class definition, and all instances are
updated automatically. The same is done for symbols. Any change made to the symbol
automatically takes effect the next time the user opens the mimic.
Designing Tag Names for Branching
Branching starts with a good tag naming convention. Tag names are driven by the
server configuration, but are actually used by Client Builder. You can create a symbol
in Client Builder using several tags that represent a frequently repeating part of the
process. Subsequent instances of the symbol can then be configured by changing only
the name of the branch. You can open this same symbol using a specific branch; the
attributes of that branch display without having to manually copy and modify separate
instances.
The best structure is for symbols and associated tag names to have the grouping first
and the function last. The function being last is the key to making reusable symbols.
Here are some useful examples of a branched tag structure:
Process example: Area_Device_Function_SubFunction (Line optional)
Discrete example: Line_Device_Function_SubFunction (Area optional)
The key to branching is the underscore character "_" which is the default branch
separator. Even when you use scaling, .eumin becomes _eumin in Client Builder.
(Arrays are handled differently.)
Here are some examples of tag names that are ready for branching:
PmpStation1_Pump_Speed
PmpStation1_Pump_Speed_SP
PmpStation1_Pump_Fault
Swiss5_Cutter3_Pressure
Swiss5_Cutter3_CyclePerSec
Swiss5_Cutter3_ErrorNo
Pressure[5][3]
CyclePerSec[5][3]
ErrorNo[5][3]
One of the most powerful functions of this feature is for applications that use
application objects to generate their tags. The application objects can be configured to
generate tag names that reflect the object hierarchy, which can then be seen easily
from the Variable Browser.
You can group all the symbols on a mimic into a complex symbol that also supports
this functionality.
Branching
Branching Views in Client Builder

Client Builder understands branching. You can see this in the way that it displays tags
in the Variable Browser. Figure 5-2 shows a branched, hierarchical view. The left pane
shows branches, while the right pane shows any leaves on the selected branch.
When you click a specific leaf, the full item string displays in the Selection field.
Note, the underscores in the tag name designate branches in the tree.
Figure 5-2 Branched View One Level
In this view, notice that the tag selected is PmpStation1_Pump_Speed, as shown in the
Selection field. As you open each branch, you see the next level. In Figure 5-3, the
branch is expanded so that you can also see PmpStation1_Pump_Speed_SP.
Figure 5-3 Branched View Next Level
Branching makes finding tag names much faster because they are organized your way.
You are presented with a structured view rather than a large flat list of all tags in the
system.
Branching
The hierarchical feature can be turned off in the Client Builder Servers Editor, by
setting the Force Flat Browsing flag for the OPCCluster. (It is necessary to reconnect
to the OPC Server for the change to take effect.)
Figure 5-4 shows the flat namespace view in the Variable Browser in Client Builder.
Figure 5-4 Flat View
As you can see, it would take much longer to scroll through the list to find a specific
tag, especially in a large system.
Reusing Graphics with Branching
Another reason for branching tag names is the capability to reuse graphics at the
symbol and/or mimic level. First, consider the symbol level. The idea is to build a
pump object (most symbols are branched at the device level) that contains 3 or more
parts, for example:
_Speed
_Speed_SP
_Fault
When you design the pump object, you can assume that the system will include the
"_" when it puts the tag together. Branching concatenates the branch with the
animation by adding the default branch specifier between them. To animate the speed,
just specify Speed in the animation. When you specify the branch, PmpStation1_Pump,
the final tag name will be: PmpStation1_Pump_Speed for the animation. In this case, the
device name is part of the branch, so you can reuse the same symbol for pumps,
motors, or anything else that has these three functions.
Branching
Figure 5-5 Object with Multiple Animations
Figure 5-6 shows a simple text object with multiple animations. It displays the current
speed. If you click on the object, you can enter a new set point. If a fault occurs, the
background turns yellow.
After animation, combine the objects, create a symbol, and give it a name. When you
paste this symbol, the dialog shown in Figure 5-6 appears.
Branching
Figure 5-6 Using a Branched Symbol
The previous animations display. To attach the symbol to the branch, just select a
branch in the Local list.
Figure 5-7 Branch Browser
The Branch Browser is shown in Figure 5-7. Notice that there is no leaf pane in the
Branch Browser. Just select the branch to complete the animation. After the branch
substitution, re-open the symbol and you will see that the concatenation is finished
and the object is finished.
Branching
You can now reuse this symbol everywhere in your application without animating the
details each time. This provides a method to ensure a common look-and-feel for your
graphics. Also remember that if you change the symbol, every reference to that
symbol will change throughout your application. For example, if later you find out
that yellow for fault is a bad choice and you want to change it to red, everywhere this
symbol is used the issue is corrected automatically.
The Examples Application contains a good example of branching on a mimic. Look at
the Area2 > Link mimic. You will see 3 branch buttons. The branching is in the mimic
open animation. Figure 5-8 shows the branch name specified in the branch field.
Figure 5-8 Branching in Examples Application
In this case, all of the animations on the pop-up mimic have the Branch1 branch
specified. If you have animations that you do not want to use this branch, specify the
entire Cluster:@TagName. The @ character tells Client Builder to not branch this
animation.
Branching
Figure 5-9 Branched and Non-Branched Animation
Remember that each branched mimic is a unique copy, so when you close the mimic,
you must specify the branch. If you want the system to use the current branch, you can
use the * character to use the current branch for this operation. You can also use the *
to specify branches when passing the mimic branch to a symbol in a branched mimic.
Figure 5-10 Using Shortcuts in Branching
Branching
Branching Shortcuts
The table below contains some useful shortcuts for branching.
Shortcut
Description
Name of the current window or branch

(depending on the context)
#W
Name of the current window
#WB
the current window branch
#B1 to #B6 Elements of the current window
#S1 to #S6 Elements of the object branch
Where Used
link-open, link-close
link-open, link-close
symbols
symbols, label format
symbols, label format
Tag Arrays Used with Branching

Array branching is different from branching with just tags. First, you need to specify a
switch on the OPCServer so that Client Builder is presented with the array tags in
proper order, as shown in Figure 5-11.
Figure 5-11 Setting Program Arguments for Array Branching
Using array tags in the OPC Client makes it easier for new Monitor Pro applications to
use Monitor Pro array tags with OPC Servers that contain OPC array items. The
command line option controls how the OPC Server handles array tags for use with
branching.
/ArrayBranch=<options> or -ArrayBranch=<options>
<options> is a comma-separated list of one or more of the following:
Std:
Positive number:
Allows browsing of array tags in standard Monitor Pro format.

Presents array tags with array indexes after the Nth underscore counting
from the front of the tag name.
Branching
Negative number:
Zero:
Presents array tags with array indexes after the Nth underscore counting
from the end of the tag name.
Presents array notations in front of the tag names with underscores in
between.
You can present the OPC_Server task with two options to get both formats by using a
comma between the options. Most applications would benefit from the following
command: /ArrayBranch=Std,0
Traditional Monitor Pro Tag Name: Area1_Pump2_Flow[4][3][2]
<Option>
OPC Browsing Alias
Std
0
Area1_Pump2_Flow[4][3][2]
[4]_[3]_[2]_Area1_Pump2_Flow
1
2
Area1_[4]_[3]_[2]_Pump2_Flow
Area1_Pump2_[4]_[3]_[2]_Flow
3
4 or more
Area1_Pump2_Flow_[4]_[3]_[2]
Area1_Pump2_Flow_[4]_[3]_[2]
-1
Area1_Pump2_[4]_[3]_[2]_Flow
-2
-3
Area1_[4]_[3]_[2]_Pump2_Flow
-4 or more
Monitor Pro auto-generates a second OPC name for each array tag by moving the
array index before the last branch in the tag name or to the front of a non-branched tag.
Branch separators are inserted before and after each dimension. Since array braces are
only allowed at the end of valid tag names when they are being defined, there is no
risk of this second auto-generated OPC item name conflicting with another tag.
The examples in the following table show how various array tag naming conventions
are presented in Client Builders OPC browser. In non-branched tag names like
PumpSpeed[x] and ValveState[x], properties are grouped in the same leaf.
Branching
Switch
Current Name
Second Name
/ArrayBranch=Std,1
(default)
Pump_Speed[x]
Pump_[x]_Speed
Pump_Pressure[x]
Pump_[x]_Pressure
Valve_FlowRate[x]
Valve_[x]_FlowRate
Valve_State[x]
Valve_[x]_State
PumpSpeed[x]
[x]_PumpSpeed
PumpPressure[x]
[x]_PumpPressure
ValveFlowRate[x]
[x]_ValveFlowRate
ValveState[x]
[x]_ValveState
Pump_Speed[x][y]
Pump_[x]_[y]_Speed
/ArrayBranch=Std,0
/ArrayBranch=Std,1
Pump_Pressure[x][y] Pump_[x]_[y]_Pressure
Valve_FlowRate[x]
Valve_[x]_FlowRate
Valve_State[x]
Valve_[x]_State
View in OPC Browser
Speed
Pressure
Redundant Licensing
R EDUNDANT L ICENSING
Redundant Licensing provides an automatic means for clients to fail over to backup
license servers if the primary license server fails. This feature also provides the
synchronization of Client Access Licenses (CALs) between a pair of redundant
license servers. Users can purchase various systems and consolidate their licenses to
obtain a more effective client-server use of their systems.
Redundant licensing is not related to the VRN task. Both are independent of each
other and configured separately. The redundant license server is intended to be used
only with another license server installed from the same Monitor Pro version.
Likewise, clients using the license server must have the same Monitor Pro version as
the server.
Redundant licensing can be configured for client operation and license server
operation. The License Utility defines the client license server(s) and designates the
license server to use redundancy. This utility initially appears the first time the client is
started after Monitor Pro is installed. Thereafter, a user can start the utility any time
from the Start menu.
Client Operation
For a Monitor Pro client to run, it must either obtain a license from a Monitor Pro
license server or consume a valid stored license. You can define multiple license
servers. Having multiple license servers ensures against the possibility that a license
server may:
Not be operational (not installed or started)
Deny a client a license
Lose communications with a client after granting a license
Users can configure all Monitor Pro clients on a common PC to automatically obtain a
license from a list of Monitor Pro license servers. Under this configuration, if a license
is not granted because no CALs are available or a communications problem exists, the
next server in the list is used. This process repeats itself until a license is obtained. If
all license servers are in use and no license was granted, the client resorts to using a
stored license. If the stored license is unavailable or expired, the client will not run.
Whenever a client starts, it always attempts to obtain a license from the top of the
license server list. The license servers in the list must not be redundant partners. If the
servers have a redundant partner, the list will reflect the appropriate pairings in
consecutive order.
Redundant Licensing
Once a license is obtained, it is stored in the clients local registry. The client
periodically sends a heartbeat message to the license server. If the heartbeat fails due
to the loss of contact with the license server, the client will attempt to get a license
from the next license server in the list. See the Utilities Guide for instructions to
configure redundant licensing for client operation.
License Server Operation
The Monitor Pro license server operates in two possible modes:
Non-Redundant
Mode
Redundant
Mode
A license server grants licenses based solely on the number of

CALs authorized for that Monitor Pro server. No modifications to
the original authorized CAL counts (run time or design time) are
performed. A license server operates as it always has prior to any
redundancy modifications.
A non-redundant license server ignores any messages from another
license server that attempts to send any synchronization messages.
For example, one license server configured for redundancy refers to
a partner that is not configured for redundancy.
A license server can compute CALs and grant CALs based on
redundancy guidelines. The license server can also perform
check-out and check-in operations and inform its partner of a
change in its license inventory.
Each partner in a redundant pair will compute a new maximum
amount of CALs for both run time and design time. The
computation is made when both license servers start up and begin
to communicate with one another for the first time and when
synchronized messages are exchanged. The CALs on each server
are synchronized after each operation. After a successful
synchronization is performed, a license server stores its partners
CAL information in the local registry.
The redundant operation is configured using the License Utility.
Redundant licensing is limited to a pair (two servers) of license
servers. Each of the servers must designate each other as a partner.
See the Utilities Guide for instructions to configure redundant licensing for license
server operation.
Redundant Licensing
Licensing Scenarios
Single System without Redundant Licensing
This scenario explains a single system operating in non-redundant mode. A single

system is the simplest system available. On a single PC, a user initiates a Monitor Pro
System install. One or more Monitor Pro clients can be attached to the server PC.
Clients (local or remote) configure their licensing source to be the same PC as the
Monitor Pro server. No redundant licensing is involved because only one license
server exists.
Remote Client
Builder
Local Client
Builder
Monitor
Pro Server
Server
FactoryLink
Serverwith
withLicense
License
Server
Multiple Application Servers without Redundant Licensing
This scenario explains multiple application servers operating in non-redundant mode.

Two or more Monitor Pro application servers are on the network. The applications are
stand-alone and not redundant (not using VRN). The license servers are also not
redundant. Each server system was purchased individually and CALs were purchased
as needed.
The users began to create larger applications, where multiple users (remote clients)
may need to access the data. Additional CALs may be purchased per server as the
need arises to allow the clients access.
Redundant Licensing
In this scenario, redundant licensing is not applied but a subfeature of it applies. That
subfeature permits the client to maintain an ordered list of license servers. A client
will contact each license server in the list until it can obtain a CAL. If no server in the
list can grant a CAL, the client will start using its stored license (provided one exists
or is not expired).
Server
List
Server1
Server2
Client
Primary
License
Server
Alternate
License Server
if Server1 fails
Monitor
Pro Server1
FactoryLink
Server1
Monitor
Pro Server2
FactoryLink
Server2
Redundant System
Two redundant application servers and redundant license servers are on the network.
A total of 10 CALs were purchased. The user has split the licenses on the two servers
(for example, five CALs on each or a combination). Up to 10 (and no more) separate
clients may attach themselves to one or both of the servers. Because the license
servers are running in redundant mode, they share knowledge of the CALs each can
support and each server will make sure that a maximum combined total of 10 CALs
will be consumed.
Redundant Licensing
If one of the Monitor Pro license servers fails, its redundant partner will still support a
maximum total of 10 client connections.
Monitor
ProServer1
Server1
FactoryLink
CAL synchronization
Monitor
ProServer2
Server2
FactoryLink
Complex Servers
This scenario is a combination of the Multiple Application Servers without Redundant

Licensing scenario and the Redundant System scenario. A plant has redundant pairs
and stand-alone servers. Some clients are configured to connect to just a redundant
pair. Other clients simply use a straight list of servers. The client automatically selects
alternate servers from a list if a license cannot be obtained from a previous server in
the same list.
Redundant Licensing
Operating Guidelines
License Server The maximum number of client licenses that can be granted is
Running in
no more than the amount purchased for that specific server.
Redundant Mode For example, if a system was purchased with 3 CALs, no
more than 3 distinct clients (each from a separate PC or 3rd

party clients) can be running. Multiple clients from the same
PC are counted as 1 consumed CAL.
A redundant license server may define a partner, but the
partner cannot refer to it in return. In this case, one license
server will attempt to send synchronization messages to its
supposed partner, but the supposed partner will ignore the
synchronization messages.
Redundant
License Server
Configured for
the Wrong
Partner
Redundant
If a redundant license server loses the connection to its partner, the
License Server server will continue to grant up to the combined CALs that the two
Loses its Partner servers established during the last synchronization.
For example, if the combined CALs equal 3, the surviving partner
will grant no more than 3 CALs for the duration of its operational
lifetime. This includes the fact that the surviving partner may
restart repeatedly.
After 10 days of server operation any attached clients will get

an informational pop-up message indicating the situation. The
user only needs to acknowledge the message. The user's client
application is not hindered in any way. The pop-up message
will appear when a client first connects, and while connected,
at 12 noon every day thereafter.
Redundant
License Server
Starts With No
Partner
If a redundant license server starts and its partner is not operational,

the license server will use the combined CALs that are stored in the
local registry.
After 10 days of server operation any attached clients will get

an informational pop-up message indicating the situation. The
user only needs to acknowledge the message. The user's client
application is not hindered in any way. The pop-up message
will appear when a client first connects, and while connected,
at 12 noon every day thereafter.
Redundant Licensing
Redundant
License Server
Pair Loses Then
Regains
Communications
A situation may arise where both license servers, although still

configured as redundant, maintain licenses to clients but cannot
communicate between themselves. In this case, each license server
is authorized to grant the total number of CALs.
When the redundant pair finally communicates, each server
possibly can be granted the maximum number of CALs possible.
The total number of CALs granted could essentially be doubled.
For example, S1 and S2 represent two redundant servers. S1 is
authorized with 3 run-time CALs and S2 is authorized with 2
run-time CALs. Collectively, S1 and S2 may not grant more than 5
CALs in total between the two while they are connected to one
another. When the two license servers lose contact with one
another, each server may possibly grant up to 5 CALs. This
situation results in a combined total of 10 CALs, which exceeds the
maximum number of authorized CALs (5). The plan of action in
this case is to do nothing and let both servers run independent of
one another with each granting a maximum of up to 5 CALs each.
When the two license servers regain communications, they will
synchronize their licenses and discover that the combined total of
granted CALs equals 10 (5 each from S1 and S2). Nothing will
happen to the connected clients.
Once a connected client releases its license (terminates), no new
clients may come in to consume the license that was just returned,
nor can any new client licenses be granted as long as the CALs
consumed is greater than 5.
If clients are still connected after 10 days and the total CALs
consumed between the two servers is still more than 5, each
connected client will get a pop-up message at 12 o'clock noon each
day when a heartbeat message is sent to the server. The pop-up
message indicates the server administering the license has exceeded
its authorized CALs. The user can simply dismiss the message and
not be adversely affected by the condition.
The 10-day count down starts when the servers first determine that
the combined CALs that are consumed exceed 5. When the
combined CALs consumed equals 5 or less, the pop-up messages
will cease.
Data Logging
D ATA L OGGING
As data is collected or computed by Monitor Pro, it is stored as a tag with a unique tag
name in the real-time database. Each time data for a tag is collected or computed, the
new value is updated in the real-time database, overwriting the old data. This data can
be retained by logging it to a historical database so that it can be reviewed, compared,
or analyzed.
The major aspects of the data logging function are described as follows:
Schema
Historian
Logger
Relational databases are configured in a table format consisting of rows

and columns. The structure of a table (the number, size, and content of
the rows and columns) is defined by its schema. When configuring a
database you must specify which tags are to collect values and where to
place the values: which database, table, row, and column.
Serves as an interface between the Monitor Pro real-time database and
the external relational database to which information is sent or retrieved.
Monitor Pro has two logging tasks that can read data from the real-time
database and send it to the relational database using a historian.
Data Point
Simplifies the task of logging data by providing
Logging
preconfigured tables. Multiple shared
numeric-value tags can be stored in the same
database and sorted later if necessary.
Allows the addition or removal of tags from the
list of tags being logged during run time.

Builds a database that will capture date/time, tag
name, and tag value for the specified tag.

Best suited for situations in which the tags that are
Database
Logging
to be logged do not need to be grouped together.

Allows you to create a table and specify which
tags to capture in that table. When the value of any
tag changes, the values of all tags in the table are
logged.
Provides the ability to group tags in a database
table.
Event-based data can be logged using a sequence
key rather than a time key.
Data Logging
Prior to configuring the logging function, use these guidelines to determine which
logging task to use for a particular situation.
Use Data Point Logging
when you want to
Log a tag only when its value
changes
Use preconfigured tables and
eliminate the time spent setting up

tables
Be able to index on log time or tag
name or both
Sort all logs of a tag in order of
Use Database Logging

when you want to
Log all tags when any tag changes
or is triggered
Simultaneously log a group of like
(logically associated) tags

Group data logged based on some
criteria
Configure a table column to be a
dynamic pen on a trend chart
occurrence
Configure a tag to be a dynamic pen
on a trend chart
Dynamically change the list of tags
being logged during run time

For example, if you had a tank in which you were monitoring the process temperature
and had a single probe in the tank, you would probably use Data Point Logging to
track the tag value. If you had six probes in the same tank, and you wanted to see the
value returned form each probe at a given point in time, you would probably use the
Database Logging task.
Database Browsing
D ATABASE B ROWSING
Monitor Pro provides several ways to browse relational databases at run time:
Database Browser Control in Client Builder
PowerSQL task running on the Monitor Pro server
Database Browser Task running on the Monitor Pro server
The Database Browser control in Client Builder allows you to create a browse
window in a mimic that you can use to view and modify database records from any
ODBC-compatible relational database or SQL Server. It is easy to configure and is
suitable for most simple browsing needs.
With the Database Browser control, you can:
View relational database information logged by Monitor Pro and/or other programs
Refresh the browser to show updated values
Modify and save data values from database records (if allowed)
Search the database using modified SQL commands (requires additional
customizing)
For detailed information and procedures to use the Database Browser Control, see the
Client Builder Help.
Database Browsing
PowerSQL
The Monitor Pro PowerSQL (Structured Query Language) task works in conjunction
with the historian tasks to allow an application to access data in an external relational
database through a result window. In addition, PowerSQL processes SQL statements
that are entered in a Monitor Pro message tag. PowerSQL is the most powerful of the
three methods of browsing data. Some of the features of PowerSQL are:
Works with a variety of historians, such as SQL Server, Oracle, or Sybase
Allows data in an external relational database to be manipulated from within
Monitor Pro
Allows execution of SQL statements generated in Math & Logic
Allows an application to send and retrieve data to and from external database tables,
including those created outside Monitor Pro
Supports the execution of database-stored procedures for database servers with this
functionality
Allows you to define tags referenced by PowerSQL in arrays as well as individually
For detailed information and procedures to use PowerSQL, see the Task Configuration
Reference Guide.
Database Browser Task
The Database Browser task works in conjunction with the historian tasks to allow a
server application to access data in a relational database through a browse window.
This method of browsing is more flexible and powerful than using the Database
Browser control, but requires more configuration effort.
Note: If you need more flexibility than the Database Browser control offers
and you are starting a new application, it is better to use PowerSQL than the
Database Browser task. PowerSQL has all the functionality of the Database
Browser task and offers even more power and flexibility with the same
configuration effort.
Database Browser offers the following features:

Allows relational data in a relational database to be manipulated from within
Monitor Pro
Allows an application to send and retrieve data to and from all external database
tables, including those created outside of Monitor Pro
Database Browsing
Allows you to define tags referenced by Browser in arrays as well as individually
For detailed information and procedures to configure and use the Database Browser
task, see the Task Configuration Reference Guide.
Browser Differences
The following three cases demonstrate the differences between using the Database
Browser control and the Database Browser task.
Case 1: View and Scroll Through Data Only
The user looks only at data on the screen and scrolls through a data set. The data does
not need to be returned in Monitor Pro tags for additional processing.
Method
Database
Browser
Control
At Design Time
Add a Database Browser control to

a mimic and define the properties
for the control.
The typical time required is a few
minutes.
At Run Time
You cannot do a precise selection

of a row by Absolute or Relative
Move; however, you can scroll up
or down in the table. The data from
the relational database is not passed
through Monitor Pro tags.
Database
Use Configuration Explorer to
You can do a precise selection of a
Browser
create
Database
Browser
control
row by Absolute or Relative Move.
Task
and Database Browser information The data from the relational
tables. Associate tags to specific
database is passed through Monitor
columns in the database. Configure Pro tags.
Move and Position Triggers to
scroll a specific row using a
relative or absolute move. Create a
mimic to display the tags and link
the animated objects to the
associated tags.
The typical time required is several
hours.
PowerSQL Same as Database Browser task
Same as Database Browser task
Database Browsing
Case 2: Selection Criteria Are Entered

The user enters some parameters. A Select is processed and data is returned to the user in a
format suitable for further processing by Monitor Pro tasks. The example in Figure 5-1 and the
corresponding sample code helps to explain this process. This example shows selecting an
alarm by Alarm ID or getting a row in the Alarm Log. The Select and the Get Row buttons
have codes associated with them.
Method
Database
Browser
Control
At Design Time
Add a Database Browser control to

a mimic and define the properties
for the control. Create and label
data entry fields using the Date and
UnitName boxes to enter
parameters. Create an OK button.
Associate the button to a script to
tell the Browser Control where to
get the data.
The typical time required is a few
minutes.
Database
Browser
create Database Browser control
Task
and Database Browser information
columns in the database. Create a
mimic to display the tags and
associate the data entry fields to
columns being used for Select.
Associate a Select Trigger to an
animation object.
hours.
At Run Time
You can do select data based on the

entered criteria. The data from the
relational database is not passed
You can select data based on the

entered criteria. The data from the
relational database is passed
Database Browsing
Figure 5-12 Example Mimic for Case 2
Sample VBA Script in Client Builder for Case 2:

Private Sub AIDQuery_Click()
Dim SQLQuery As String
SQLQuery = "SELECT * FROM ALARMS WHERE aid = "
DbBrowserCtl1.RecordSource = SQLQuery + CStr([aid%])
DbBrowserCtl1.Refresh
End Sub
Private Sub GetRow_Click()
AlarmName.Text = Trim(DbBrowserCtl1.GetCellText(DbBrowserCtl1.
ActiveRow, 2))
Message.Text = Trim(DbBrowserCtl1.GetCellText(DbBrowserCtl1.
ActiveRow, 10))
itime.Text = Trim(DbBrowserCtl1.GetCellText(DbBrowserCtl1.
ActiveRow, 6))
End Sub
Database Browsing
Case 3: Selection Criteria By Group

The user enters the name of the field upon which to base the select query. The example in
Figure 5-13 browses the alarm history and shows information from a specific group of alarms.
Method
Database
Browser
Control
At Design Time
Add a Database Browser control to a

mimic and define the properties for
the control. Create and label data
entry fields using the Date and
UnitName boxes to enter
parameters. Create an OK button.
Associate the button to a script to
tell the Browser Control where to
get the data. Associate the text fields
to PLC write tags. Move the selected
row into a set of editable text fields.
Typical time required is a few
minutes.
Database
Browser
create Database Browser control and
Task
Database Browser information
columns in the database. Define
another set of data input tags to get
the selected row. Create a mimic to
display the tags and associate the
data entry fields to columns being
used for Select. Associate a Select
Trigger to an animation object.
Implement some logic to move the
tags to a set of PLC write tags, and
force a write to the PLC. (Where
possible, you can use the same
Database Browser tags as PLC write
tags.)
hours.
At Run Time
You can do a precise selection of

data based on the entered criteria.
The data from the relational
database is passed through
Monitor Pro tags.
You can select a row by the

selection criteria and move the
data from the relational database
into a set of text fields, into the
Monitor Pro real-time database,
and then write the tags to a PLC.
Database Browsing
Figure 5-13 Example Screen for Case 3
Sample VBA Script in Client Builder for Case 3:

Private Sub SelectAll_Click()
DbBrowserCtl1.RecordSource = SelectAll.Text
End Sub
Private Sub GrpNameQuery_Click()
Dim SQLQuery As String
SQLQuery = "SELECT aid, name, grp, msg, itime FROM ALARMS WHERE
grp = " DbBrowserCtl1.RecordSource = SQLQuery + "'" +
[groupname%] + "'"
End Sub
Environment Variables
E NVIRONMENT VARIABLES
Monitor Pro uniquely identifies an application by a combination of its application
name, domain name, and user name. These names are defined as environment
variables. You typically set these environment variables in a system configuration file
so they are automatically supplied when you start the application.
If you use the Application Setup Wizard with one of the FLNEW templates, these
environment variables will be set up for you automatically. When using environment
variables in path names, you can enter the name of the environment variable
surrounded by braces { } and Monitor Pro extends the pathname using the default
setting. The environment variables you can set are listed in the following table.
Variable
Description
FLINK = flink_dir
Where flink_dir defines the full path of the directory

containing the Monitor Pro program files.
FLAPP = flapp_dir
Where flapp_dir defines the full path, including the drive

name, of the directory containing your application files.
FLDOMAIN = domain
Where domain defines the domain you are starting. This

can either be Shared or User.
On single-user platforms, domain is User, which starts
both domains. On multiuser platforms, domain is the
domain you want started in the window. You must specify
two windows, one for each domain.
FLNAME = app_name
Where app_name defines the name of the application to

start, which points to the real-time database.
FLUSER = user_name
Where user_name defines the logical user name.
FLOPT = opt_dir
Where opt_dir defines the full path, including the drive

name, of the directory containing the Monitor Pros
license information.
SELECT_TIME=xx
Where xx is the number of seconds. Used with WebClient

and FLLAN to set the time-out duration for the
transmission of a data packet.
RedundServer=name
If using VRN, name specifies the redundant node name

(remote node).
Run-Time Manager
R UN -TIME M ANAGER
The Run-Time Manager orchestrates the run-time environment. It is a Monitor Pro
task that runs concurrently with other tasks to start, monitor, control, and shut down
the concurrent execution of all Monitor Pro tasks.
The Run-Time Manager reads the System Configuration table to determine the startup
criteria for each task. The Run-Time Manager communicates with each task by
sending commands to and reading status information from the real-time database.
Each task must monitor the command objects so the task shuts down when instructed
to by the Run-Time Manager.
The Run-Time Manager interacts with the other tasks within a specific domain
through the Monitor Pro application program interface (API) and the real-time
database.
Run-Time Manager Data Flow Diagram
Run-Time
Manager
SYS.CT
Read
Write
Monitor Pro
Real-time
Databases
Read
*.CT
Write
Monitor Pro
Application
Tasks
Multiuser Architecture
M ULTIUSER A RCHITECTURE
Monitor Pro supports the concept of shared and private data areas by the separation of
data access into domains. There are two run-time environments in Monitor Pro called
the Shared domain and the User domain.
Note: If you are building a new application using Client Builder graphics, you
should configure all of your application in the Shared domain.
During configuration, you associate tasks, tables, and tags with a specific domain so
you can configure a Monitor Pro application to suit your needs. Monitor Pros
multiuser architecture has the following benefits:
You can give a group of users independent access to the same Monitor Pro run-time
tasks such as Graphics, Math and Logic, and Statistical Process Control. This lets
users access the same data at the same time with different tasks.
You can create an application that lets multiple users of a single run-time system
use the tasks independently without the users sharing data; that is, users can
simultaneously run the same tasks, but each users data is unique. For example, one
user can employ the Statistical Process Control task to evaluate the consistency of
an assembly sequence while another uses it to report anomalies in a packaging
process elsewhere in the factory.
You can set up multiple Monitor Pro applications to run on one operating system.
For example, applications for development, testing, and production can all run on
one machine.
Shared and User Domains
In a multiuser application, users execute in their own User domain. Each User domain
has its own copy of user data but shares data from the Shared domain.
The Shared domain is the shared portion of the real-time database and the collection
of shared processes that have access to that data. The User domain is an instance of the
user real-time database and the set of all the user processes having access to that
real-time database. Multiple User domains each have their own set of user processes.
Each can access both the Shared real-time database and the User instance of the
real-time database.
When Monitor Pro runs, the entire real-time database is created, including the Shared
portion and all real-time database User instances. Next, the Shared Run-Time
Manager initializes the Shared Run-Time Database and starts the Shared processes. As
User instances start, each User Run-Time Manager initializes its instance of the User
real-time database and starts an instance of all User processes.
Monitor Pro tasks use real-time database tags to control tasks. User database tags are
duplicated for each Monitor Pro user. The subset of the real-time database duplicated
on a per-user basis is known as the User domain.
The multi-user architecture allows duplicate User domains by allocating an array of
pointers to database segments for each user. This allows the tag numbers (indices into
the pointer array) themselves to remain the same for each user while referencing a
private data area for each user.
Some Monitor Pro tasks monitor and control processes, such as a PLC driver task, that
require the process data values be the same for all users. The subset of the real-time
database shared by all users is known as the Shared domain.
Domain Characteristics
A Shared domain has the following characteristics:

AccessibilityAll operators within a User domain can access data existing in a
Shared domain.
Frequent useFrequently used items need only be defined once in the shared area.
This characteristic eliminates duplication of effort and reduces configuration time.
Automatic data changesData changes are passed immediately to all users who are
accessing the modified data in a User domain.
Global data processingProcessing activities, such as computations, data
accessing, and data logging are performed once and then are available to all users
accessing the shared area.
A User domain has the following characteristics:
Private copies of dataYou can configure a single application and then specify the
number of instances (copies) of that domain to be executed at run time. The number
of instances allowed is the number of users that can simultaneously interact with the
run-time system.
Task IndependenceEach user has access to the same Monitor Pro run-time tasks
such as Graphics, Math and Logic, and Statistical Process Control, but is able to run
these tasks independently from the tasks other users are running. Users can share
data to perform different real-time tasks within the same application.
In the following example, you have created an application that allows multiple
operators to run separate user instances of the same application in which each operator
has his own User domain tasks and real-time database.
Domain Structure
Domains exist in a parent/child hierarchy. The following illustration shows that the
Shared domain is like a parent upon which a child domain (User) is based.
Domain Tables
The domain table in Configuration Explorer contains the definition of the Shared and
User domains in the application. The definition of these domains includes the number
of allowed instances as well as domain-wide persistence attributes.
Configuration Explorer has a domain selection feature that must be set before tasks
are configured. The default is Shared. If the run-time domain associations do not
match the configuration domain associations, the application will not run as intended.
Domain Associations
Within the Examples Application, default domain associations are made in the System
Configuration Table. These defaults determine which domain a task is associated with
at run time. Some tasks are associated with both Shared and User domains. You
should review the default domain associations during application planning to verify
that they are compatible with current needs. These default associations may be
changed if an application has special requirements.
Domain designations are critically important. Before each task begins to run, the
associated domain is defined as an environment variable. Typically, the task inherits
the environment from the Run-Time Manager when the Run-Time Manager starts the
task. This variable must match one of the previously defined domain values. Two
types of domain relationships are possible:
A task may be designed to run as Shared. All tables and database tags are associated
with the Shared domain. At run time the task runs as a shared entity with one set of
tags for all users.
A task may be designed to run as User. You have a private copy (domain instance)
of the task for every user. The tasks may use both the Shared and User Run-Time
Database tags. At run time all user domain instances are identical when generated;
however, individual user actions are independent, and the resulting data is stored in
a real-time database unique to each operator.
Domains for Run-time Tasks
Run-time tasks are associated with a domain. The domain controls whether the
run-time task can share data and which task uses data unique to a user. Choosing the
appropriate domain for a task in a multiuser application is critical.
The defaults that provide the best performance for most applications are listed in the
following table.
Domain Type
Run-Time Tasks
Shared
Timer
Report Generator
Batch Recipe
File Manager Server
External Device Interface (EDI)
LAN
Historian
Logger
SPC Logger
User
Graphics
File Manager
Trending
Browser
SPC View
SPR
Both domains
Run Manager
Math and Logic
Counter
Persistence
RTMON
DALOG
During application planning, review these domain defaults to verify compatibility

with a specific applications needs. When an application has special requirements, you
can run the task in a different domain, except for the EDI task which must be run in
the Shared domain.
If the domain chosen during configuration does not match the default set for the
domain at run time, the application will not run as intended. You must configure
trending in the User domain if it is going to run in the User domain.
Monitor Pro Kernel
M ONITOR P RO K ERNEL
The Monitor Pro Kernel is a program that creates the real-time database in memory so
tasks can communicate with each other. When you start the Monitor Pro Run-Time
system, the Run-Time Manager creates the shared memory using the Kernel Services.
Other tasks also use the Kernel Services to access the shared memory as they start.
Kernel Multi-User Capabilities
The Monitor Pro Kernel allows multiple independent users of a Monitor Pro
application and provides private, per-user memory areas for real-time data (an
instance of the User domain). It allows up to 31 tasks for each user instances and also
allows multiple applications to run simultaneously.
Application Instances and Identification
When a Monitor Pro application is started, the Run-Time Manager must be supplied
with the invocation name, domain name, and user name on the command line or
through environment variables. All subprocesses created by the Run-Time Manager
inherit these environment variables. Because multiple copies of a Monitor Pro task
may be running concurrently, a task must identify itself to the Kernel by specifying the
application, domain, and user instance as well as the task name.
Each application instance is specified by its invocation name, which is a character
string of up to 16 characters. The invocation identifies an instance of the real-time
database and is used to locate the memory segment the kernel is stored in. The
Run-Time Manager refers to the invocation name stored in the environment variable
{FLNAME} and stores it in the tags FLNAME_U or FLNAME_S, depending upon
the domain.
The domain is specified by a character string of up to 16 characters and is used to
determine which portion of the real-time database the task has access to: either the
tags in the Shared domain or tags in one of the duplicate User domains. The Run-Time
Manager refers to the domain in the environment variable {FLDOMAIN} and stores it
in the tag FLDOMAIN_U or FLDOMAIN_S.
The user instance is a character string of up to 16 characters and is used to determine
which instance of the duplicate User portions of the real-time database the task has
access to. The Run-Time Manager refers to the environment variable FLUSER and
stores it in the tag FLUSER_U or FLUSER_S. The FLUSER environment variable
must be unique for each user of the application.
Chapter 6
Planning Your Application
A well-planned application can make the task of building and maintaining your
Monitor Pro application much simpler. This chapter provides some of the basic things
you need to consider when planning your application.
P LANNING YOUR A PPLICATION P ROCESS

1 Analyze your processes and determine the requirements for your Monitor Pro
application based on the following areas:

Architecture and topology
Redundancy
OPC or other proprietary drivers
Security and levels of users
Custom tasks
Tags and tag types
Tag naming conventions
Scripted procedures
Message types
Historical data requirements
Organization and navigation of mimics
Symbols needed for mimics
Application objects
Branching
VBA scripting
Alarming
Trending
2 Create a complete Monitor Pro application (both server application and client project)
using the Application Setup Wizard, as discussed on page 115.
6 | PLANNING YOUR APPLICATION

Planning Your Application Process
3 Configure the server application component using Configuration Explorer.

Create and define necessary tags.
Create and define necessary application objects classes. Instantiate the number of
application objects that you will need for your application.

Write Math and Logic procedures if needed.
Test to see that the tags are updated in the real-time database from external devices.
Configure tables to define the connections to external devices (such as OPC or
proprietary device protocols).
4 Configure the client project graphical user interface using Client Builder.
Make sure that the client is connected to the correct server.
Define roles and languages as required for multilingual applications. It is important
to assign the appropriate presentation, project, and role languages for each class of
user.
Create any symbols needed for the mimics.
Define mimic functionality and navigation.
Create mimics by drawing desired graphical representation of process.
Insert images and symbols into the mimic and create animations if needed.
Link symbols and animations to server tags or application objects on the server
side.
Test the application frequently as you build the mimics to quickly identify
problems.
PLANNING YOUR APPLICATION | 6

Minimum Hardware and Software Requirements
M INIMUM H ARDWARE
AND
S OFTWARE R EQUIREMENTS
Minimum hardware and software requirements should be taken into consideration

when planning your application. While the software will run on the minimum
requirements, they may not be adequate for satisfactory performance for some
systems, especially larger, complex systems with multiple clients.
It is impossible to define the exact requirements for each system due to the flexibility
and scalability of Monitor Pro and other layered software involved; however, the
minimum hardware and software guidelines contained in the Installation Guide
should help you select the best estimate of your system requirements. If your exact
requirements are somewhat more or less than what is stated in the guidelines, contact
your authorized Schneider Electric reseller or representative for additional hardware
and software recommendations.
G UIDELINES
FOR
S YSTEM D ESIGN
AND
M AINTENANCE
Although individual system resources vary, here are some general guidelines for
designing and maintaining your Monitor Pro system:
Use branching and application objects wherever possible to reduce development
time.
Do not use VBA to do things that you can do with the standard functions and
animation in Client Builder. This saves time on maintenance, and Client Builder
runs faster.
Be conservative with the amount of VBA you use in the MimicOpen() event. Too
much VBA slows down mimic loading.
The more drawing files that you add to your mimics, the slower your screens will
render and read values.
When you need drawing files in your mimics, even though bitmaps consume more
memory, they draw much faster than metafiles. You can create bitmaps from the
metafiles shipped with Monitor Pro.
Do not put more than 500 animated fields on a single mimic unless you are willing
to wait for the registration time required.
Use event processing with trigger and complete trigger tags. Do not control each
task with Math and Logic. (However, you may want Math and Logic to control the
sequence of events.)
Use gradient colors carefully, using the following considerations:

Tag Naming Recommendations
The speed at which colors are rendered depends on the choice of graphic adapter
and color configuration.

Make the step parameter as large as possible. The drawing performance depends
directly on the size of the step. (A step of 4 will render twice as fast as a step of
2.)
The angles 0, 90, 180, and 270 are the most efficient when using a linear
gradient.
The radial gradient is more time consuming than linear, particularly if the X and
Y coordinates are not close to the objects center (50 percent, 50 percent).
The number of colors has no impact on the drawing performance.
Make backups often.
Test often while configuring. Make a few changes, test, and save. It is easier to find
problems if you use this approach.
TAG N AMING R ECOMMENDATIONS

One of the most important parts of planning an application is to define a tag naming
convention before you start developing. Perhaps your plant already has a well-defined
standard, but if not, following some general recommendations for tag names will help
you save time and has the following advantages:
Configuration requires minimum work since an object or a group of objects
including all its properties can be specified by a single entry.
Objects can be automatically generated. This applies especially to application
objects that create object properties and their configuration table entries. You can
then instantiate as many application objects as you wish for one or more objects
using a single entry.
When you are naming your tags, follow the general tag naming recommendations and
guidelines discussed on page 41.
PLANNING YOUR APPLICATION | 6

Message Types
M ESSAGE TYPES
As part of developing your application, you should consider the types of messages that
will be presented to users. For example, you may want to distinguish between two
types of alarm messages:
Those that need immediate attention, such as failure and warning alarms
Those that can be taken care of later, such as diagnostics and status information
messages
A PPLICATION O BJECTS
AND
S YMBOLS
An important part of building an application that is easy to expand and maintain is to

define application objects in Configuration Explorer (server side) and symbols in
Client Builder (client side) to represent various classes of objects to be controlled.
An example is configuring a standard pumping station. In Configuration Explorer, you
would configure objects that represent a pumping station with all the components
required to operate the pump. In Client Builder, you would configure the graphical
symbols for a user interface that represents the pumping station.
If the server configuration is saved as an application object, then, each time you need a
new pumping station, you could use the application object to create another instance.
Using application objects improves the quality of a Monitor Pro application by
encouraging structured development, reducing errors, and improving maintainability.
S TANDARD I NTERFACE
One standard that often is not considered when designing an application is the concept
of having a standard interface for operators. By taking the time to define a standard
interface you can improve system performance, minimize operator errors, and lower
training and maintenance costs.
The Examples Application provided with Monitor Pro serves as a demonstration and
practice application to help users learn about Monitor Pros capabilities and features.
This application contains a suggested framework for an application, but is fully
configurable for those who want to practice customizing the application. It contains a
number of predefined application objects for standard OPC inputs and outputs.

Standard Interface
When you use the Application Setup Wizard to create your Monitor Pro application,
you choose from three templates that are variations on the FLNEW template. The
FLNEW template is essentially the Examples Application without the sample mimics.
When you use the Application Setup Wizard, your application will already have basic
configuration, which will have a dramatic effect on the total cost of building and
maintaining the application. You can think of it as a jump start for application
development.
The FLNEW templates are preconfigured with the following functionality:
Screen navigation
Redundancy
OPC Data eXchange
Application objects
Basic timers
Multilanguage support
You have a choice with Monitor Pro: you can start with a completely blank application
or you can start developing on top of an FLNEW template. By using the FLNEW
template as the basis for your plants standard application, not only do you shorten
development time, but you make an application that is easy to maintain and build upon
for future plant expansions. It also has the advantage of having a standardized operator
interface, so it is easier to move operators between systems and reduces training
requirements.
Chapter 7
Examples Application
The Examples Application is as a demonstration and practice application. It provides

sample mimics that demonstrate many of the animation types that you can configure
in Client Builder. With the Examples Application, you can examine how the sample
mimics were built and practice configuring the components of a Monitor Pro
application.
Because the Examples Application contains extra configuration for its sample mimics,
it not recommended that you use it as the basis for building your Monitor Pro
application. Instead, it is recommended that you use the Application Setup Wizard to
create your Monitor Pro application. Using the Application Setup Wizard, you can
select from three versions of the FLNEW template to build your application. FLNEW
is essentially the Examples Application with the sample mimics removed.
The Examples Application includes the following functionality:
Screen navigation
Application objects
Basic timers
E XAMPLES A PPLICATION I NSTALLATION

The Examples Application is installed as part of the typical Monitor Pro system
installation and is an optional, selectable component in a custom installation. To open
the Examples Application client project, double-click the Examples Application
Client Project icon on your desktop.
If the Examples Application is not installed, it can be installed by rerunning the
installation program and selecting only the Examples Application option. See the
Installation Guide for more information.
The Examples Application installs two components:
A Server Application with an application object database and source file examples
accessed with Configuration Explorer
A Client Project that is opened in Client Builder
7 | EXAMPLES APPLICATION
Running the Examples Application
Server Application files are installed in this directory:

Program Files\Telemecanique\FactoryLink\Applications\Examples App
Client Project files are installed in this directory:

Program Files\Telemecanique\FactoryLink\Applications\Examples App\CBPROJ
R UNNING
THE
E XAMPLES A PPLICATION
To run the Examples Application, you must perform two main actions:
1 Start the Server Application (MyExamplesApp) in Configuration Explorer.
2 Open the Client Project (Examples.fvp) in Client Builder.
A text help file, named Starter.txt, found at C:\Program Files\Telemecanique\FactoryLink\

Applications\Examples App\CBPROJ\Config Files, describes the basic requirements for
configuring and running the Examples Application.
S ERVER A PPLICATION O VERVIEW

The Server Application runs the server tasks. The Server Application consists of a set
of preconfigured tasks that are commonly used in industry, such as Alarm Logger,
Database Logger, Historian, OPC Server, and Math and Logic. These tasks provide
examples of logging data for alarm, trend, and browse, as well as generate real-time
data for graphic animation display. This data is accessed by the Client Builder
graphics using the Alarm Server and the OPC Server running within the Monitor Pro
application, and the Trend Server and Database Browser Control running from Client
Builder.
Starting a Server Application
1 In Configuration Explorer, under Enterprise View, expand FactoryLink Servers.
2 Expand the server computer name to display associated server applications.
Server computer name refers to the name of the computer where the Monitor Pro
server is installed; therefore, the name varies with each user.
3 Right-click the MyExamplesApp server application. Click Start/Stop and then click
Start.
EXAMPLES APPLICATION | 7
Server Application Overview
Configuration Explorer starts the MyExamplesApp server application.

Note: The Run-Time Monitor (RTMON) is also started and can be used for
debugging using the tag input, the watch list, or the command input windows.
Saving a Server Application

It is recommended that you periodically save your server application with the
following considerations:
Do not save to a directory that contains working files to avoid accidently copying
over files.
Choose an independent directory for saves, preferably on a separate disk or
partition.
You can save Monitor Pro applications by one of two methods: platform specific
(native) and multiplatform (compressed). Compressed saves are recommended.
1 In Configuration Explorer, under Enterprise View, expand FactoryLink Servers.
2 Expand the server computer name to display the server application.
3 Right-click MyExamplesApp and click Save.
4 When the Backup Application dialog box opens, click the Compressed (Saved as
single file) file type to save the system files as a single compressed file with an .mps
extension.
Note: The Native (Saved as multi-file image) file type is not recommended for
most applications.
5 Select the Save application data files check box if you want to save miscellaneous
files that were created, such as trending log files or log messages.
6 Click the Destination browse button
and browse to the destination drive and

directory where you want to save the server application.
7 Click OK to save the server application.
Restoring a Server Application

If you need to restore a server application that you saved, you can do it two ways:
A compressed restore is decompressing a single .mps file into a set of server
application files and placing those files in a selected directory.
A native restore is restoring a set of native server application files from one
directory to another directory.
You can restore a server application from Configuration Explorer or from Windows
Explorer.
Note: When restoring a server application in the same directory with an existing
application of the same name, the restore deletes and replaces the existing
application. Be sure to archive any server applications that you want to keep.
Types of Server Applications You Can Restore
You can restore any server application that you previously saved as an .mps file.
Monitor Pro also provides three sample server applications that you can restore. These
applications are in German, English, and French and can be found in the C:\Program
Files\Telemecanique\FactoryLink\Server\MPS directory.
The flnew.mps application is suitable for most users. It contains more configuration
than the flblank.mps application and is a typical starter application. It does not
contain demonstration mimics.
When running the Application Setup Wizard (discussed on page 115), you will
choose from three versions of the FLNEW template.
The flblank.mps application contains minimal configuration, such as the Monitor
Pro global system tags. This file is appropriate for a user who does not want any of
the configuration in the flnew.mps application.
The fltest.mps application is useful for the purposes of testing most of Monitor
Pros common tasks.
The following procedures explain how to perform a compressed restore in three
different ways:
Compressed Restore in Configuration Explorer
Compressed Restore in Windows Explorer
Compressed Restore Using FLREST.
Compressed Restore in Configuration Explorer
Perform the following steps to perform a compressed restore of a server application in

Configuration Explorer.
1 Open Configuration Explorer and expand FactoryLink Servers.
2 Right-click server computer name and select Restore Application.
3 When the Restore Application dialog box opens, select Compressed (Saved as single file).
4 Click the Source browse button and browse to the drive and directory that contains the
server application .mps file that you want to restore.

5 Select the .mps file that you want to restore and click Open.
6 At the Restore Application dialog box, click the Application Directory field browse
button.
7 When the Browse for Folder dialog box opens, browse to the drive and directory
where you want to restore the server application. Click OK.

Note: You can place the application in a drive other than C drive.
8 At the Restore Application dialog box, click OK.
9 At the Add Monitor Pro Application dialog box, enter a name for the restored server
application in the Name field and click OK.

10 At the Confirm Action dialog box, click Yes.
The message states that your application directory is not a UNC path; therefore,
Configuration Explorer will not be able to remotely configure the application. (UNC
path refers to a Window-based Universal Naming Convention standard that allows a
distributed system to have remote access.)
The compressed server application is restored.
Note: If you plan to run a local ECS Graph task in addition to Client Builder,
see FLREST Domain Considerations on page 99.
Compressed Restore from Windows Explorer
You can restore a server application .mps file from Windows Explorer; however, you
will still need to add the application to Configuration Explorers namespace so that
Configuration Explorer recognizes the application.
1 Using Windows Explorer, browse to the .mps file that you want to restore.
2 Double-click the server application .mps file to open the Monitor Pro Application
Restore dialog box.

3 In the Destination field, enter the path of the directory where you want to restore the
application.
4 Do not change the source file format. The Compressed (Saved as single file) option is
already selected. Click OK.

5 Next, to make Configuration Explorer aware of this file, open Configuration Explorer,
expand Servers, right-click the server computer name, and select Add Existing
Application.
6 When the Add Monitor Pro Application dialog box opens, type the name that you
want to call the application in the Name field.

7 Browse to the directory where you restored the server application in Step 3 and click
OK.
The compressed server application files are restored.

refer to FLREST Domain Considerations on page 99.
Compressed Restore Using FLREST
You can restore a compressed server application using FLREST. Be sure to write
down the complete drive and directory path of the source directory and the destination
directory before you begin.
1 From the Windows Start menu, click Run.
2 Type flrest in the Open field and click OK.
3 When the Monitor Pro Application Restore dialog box opens, type the complete drive
and directory source path in the Source field.

4 Type the complete drive and directory destination path in the Destination field.
5 Select Compressed (Saved as single file). Click OK.
6 Next, in Configuration Explorer, right-click the server computer name and select Add
Existing Application.
7 At the Add Monitor Pro Application dialog box, enter a name for the restored server
application in the Name field.

8 Click the Application Directory browse button and browse to the drive and directory
where you restored the compressed server application files. Click OK.
The server application is restored.

see FLREST Domain Considerations below.

FLREST Domain Considerations
1 After the restored application appears under your server computer name in
Configuration Explorer, right-click the new server application and select Properties.
2 On the Application Properties dialog box, remove -nshared from the FLRunArgs property
value. Click OK.

The removal of -nshared allows the Run-Time Manager to run in the User domain.
Client Project Overview
C LIENT P ROJECT O VERVIEW

The Client Project includes several sets of sample mimic screens that demonstrate the
major functions available in the graphical development software.
The first set (Area 1) demonstrates real-time data display for alarming, trending,
and browsing, using the developed ActiveX components.
The second set (Area 2) demonstrates standard animation features commonly used
for color control, value input and output, and image display.
The third set (Area 3) demonstrates advanced features used to add movement,
visibility, scripting, and objects to the graphics.
Note: The Monitor Pro client installation installs a set of clip art images (if you
select them) in the Telemecanique\Common\Client Builder\Shared Libraries directory.

To use these clip art graphics, you copy them into your new Client Builder
project.
When a client project is saved, it is automatically compressed into a single file with a
.cba extension. When a client project is restored, it is uncompressed from the .cba
format into a multiple files project. A client project must be restored from its
compressed .cba format before it can be opened.
Opening a Client Project
The Monitor Pro installation places two Client Builder icons on your desktop: Client
Builder and Examples Application Client Project. The Examples Application
Client Project icon immediately opens the Examples Applications client project. The
Client Builder icon allows you to select the project you want to open.
1 Double-click the Client Builder icon on the desktop.
The Open Project dialog box always opens with a default path to the last client project
that you opened.
2 Browse to the C:\Program Files\Telemecanique\FactoryLink\Applications\Examples App\
CBPROJ directory.
3 Double-click Examples.fvp.
Client Builder opens the client project at the logo screen, which contains buttons that
allow you to start and stop the local server without having to go to Configuration
Explorer. If Client Builder is pointed to a server other than the local server, these
buttons will not start and stop that server.
Saving a Client Project
It is recommended that you periodically save your client project. When you save a
client project, the project is compressed into a single file with a .cba extension.
1 In Client Builder, click Tools > Application > Save/Restore Project.
2 When the Client Builder Archive Utility dialog box opens, click the Project File browse
button and select the source drive and directory that contains the project you want to
save.
3 Click the Archive File browse button and select the destination drive and directory
where you want to save the project.

4 Click OK. (The client project is saved with a .cba extension.)
Restoring a Client Project

You can restore any client project that you previously saved or any of the compressed
client projects that come with Monitor Pro.
Types of Client Projects You Can Restore
Monitor Pro provides two sample client projects that you can restore. These projects
can be found in the C:\Program Files\Telemecanique\FactoryLink\ Applications\Compressed
directory.
The ExamplesApp.cba application contains a fully configurable baseline
application with global tab functionality common to all Monitor Pro applications, as
well as additional system tags that support screen navigation, application objects,
basic timers, and multilanguages. It also contains sample mimics. This file is
appropriate for users who want to get started quickly, economically, and efficiently.
The cbnew.cba application is suitable for most users and is a typical examples
application with Monitor Pro global system tags. It does not contain sample mimics.
Restoring a Client Project from Windows Explorer

1 From Windows Explorer, browse to the directory that contains the client project .cba
file that you want to restore. Double-click the .cba file.

The Client Builder Archive Utility dialog box opens. Note that Restore Client Builder
Project is already selected, and the Archive File field already contains the path to the
.cba file that you are restoring.
2 Click the Project Directory browse button and find the drive and directory where you
want to restore the archived project. Click OK.

3 At the Client Builder Archive Utility dialog box, click OK.
4 When the restoring process is complete, a message asks you to confirm the restore.
Click OK.
Restoring a Client Project in Client Builder
1 Double-click the Client Builder icon on your desktop.
2 At the Open Project dialog box, click New.
3 At the New Project dialog box, enter the new project name in the Project Name field.
4 Click the Location browse button and browse to the destination directory path where
the new project will reside. Click OK.

5 In Client Builder, click Tools > Application > Save/Restore Project.
6 At the Client Builder Archive Utility dialog box, select Restore Client Builder Project.
7 Click the Archive File browse button and find the drive and directory that contain the
compressed .cba project you want to restore. Select the .cba project.
8 Click the Project Directory browse button and find the drive and directory where you
want to restore the archived project. Click OK.

9 When the restoring process finishes, the Client Builder Archive Utility dialog box
opens. Click OK.
Client Builder Client Project
C LIENT B UILDER C LIENT P ROJECT

The following graphic illustrates communication connections between the major
components of the Client Builder client project, the Monitor Pro Server, and the
Database Server.
Client Builder
VB Script
Animation
Alarms
ActiveX
OPC
Comm Mgr
Browse
ActiveX
Trend Server
Local or Remote
Client
Computer
Monitor Pro
Server
Computer
Trend
ActiveX
OPC Server
RTMON
Alarm Server
Monitor Pro Application
Real-Time Database
(RTDB)
Alarm Logger
OPC Client
Historian
(ODBC or Native)
Third-Party OPC
Server on Local
Computer, Remote
Computer, or PLC
Data Logger
Database on
Local or Remote
Computer
Animation Real-Time Display

In the client project, the mimics animated objects connect to the real-time database
using the OPC Communication Managers client connection to the Monitor Pro OPC
Server. With the server application running, this communication allows the tag values
to be read to and written from the animated objects. The animation features use those
tag values, as well as the graphics local register variables, for real-time display and
control of the Monitor Pro Server. In addition to the animation features and functions,
the internal VBA script editor can be used to write custom code using a graphic
objects exposed properties, methods, and events.
ActiveX Controls
The following ActiveX controls are available in Client Builder using the Insert menu:
Real-Time Trend Control
Alarm Viewer Control
Historical and Real-time Trend Control
Cluster Monitor Control
For more information about the these ActiveX controls, see the Client Builder Help.
Alarms
You can use the Alarm Viewer control to configure, display, sort, filter, and
acknowledge the active alarms from the Monitor Pro Server as communicated through
the Alarm Server. Alarm Viewer properties can be accessed for configuring the
parameters for general control, colors and fonts, groups, and fields. The Alarm Logger
uses an ODBC Historian task to write the alarm data to a SQL Server or dBase IV
database selected during installation.
Below the Alarm Viewer is the Alarm Banner Viewer, which is configured from the
same ActiveX control. The Alarm Banner, which can display up to three alarms, is
often used to show the most critical or newest alarms. In the Examples Application,
clicking the Alarm Banner takes you to the screen name in the Area Name field. You
can copy this configuration into your project and it works automatically.
Trend
You can use the Real-time Trend control or the Historical and Real-time Trend control
to configure, display, and select data as communicated through the Trend Server from
values logged to a database using the Data Logger tasks. Using this database method,
the trend controls can display the data in either a real-time or historical mode. The
trend control properties can be accessed for configuring the parameters for graphs,
pens, and fonts. Within the properties panel, a trend editor is accessed for pen
assignments to the database tables and columns.
The Trend Server is used so a single trend control can connect to multiple databases or
tables simultaneously. The Trend Server makes a direct connection to the databases
using an ODBC data source configuration.
Database Browser
You can use the Database Browser to configure, display, and select data from values
logged to the database using the Data Logger tasks. The Browse Control properties
can be accessed for configuring the parameters for general control, database sources,
columns, select statement, and sort order. The Database Browser makes a direct
connection to a database using an ODBC data source configuration.
Cluster Monitor
You can use the Cluster Monitor control to monitor the status of the servers within
server clusters, determine which servers in a cluster are being used by the client, and
manually switch clients from one server to another.
Standard Animation Features
Many graphic functions use the animation types. Certain animation combinations can
be applied on a single object so that the object can serve multiple purposes.
Color animation color fills any drawn object, bargraph, or legend by using a bit or
numeric register value.
Text animation displays messages, labels, or numeric values.
Symbol animation selects predrawn objects from a library by using a bit or
numeric register value.
Send animation writes values to bit, numeric, or text registers.
Run animation launches an external program.
Link animation opens or closes graphics, connects to an external document (like a
Word file) or URL, and views or edits a text file as a note.

Advanced Animation Features
The following advanced animation features can be used to add movement, visibility,
script, and symbols to the graphics:
Layers are different sheets on the same graphic used to group objects that can be
seen when the Layer Toolbar is used to select a layer number or the Layers value is
set by script.
Decluttering is a template that allows layer visibility based on zoom levels.
Visibility bound is an object property that defines object visibility based on zoom
range.
Rotation is an animation function that rotates an object through an angle range
relative to a register value range.
Scaling is an animation function that scales an object through a percentage range
relative to a register value range.
One-axis positioning is an animation function that moves an object relative to its
original position in X- and/or Y-weighted directions using one register value linked
to both axes.
Two-axis positioning is an animation function that moves an object relative to its
original position in X- and Y-weighted directions using a separate register value for
each axis.
Free positioning is an animation function that moves an object to absolute
coordinates in X and Y directions using a separate register value for each axis.
Path positioning is animation that moves an object along a path defined by a line
or polyline.
VB script is a single object or a grouped object script file that executes event-based
subroutines.
Function objects are examples of library symbols that can be created with local
register variables for substitution with tags after inserting the symbol.
Server Application Components
S ERVER A PPLICATION C OMPONENTS

Viewing Tag Descriptions
The following steps explain where to find descriptions of the tags in the Examples
Application or any other application.
1 In Configuration Explorer, expand FactoryLink Servers > your server name.
2 Right-click MyExamplesApp (or other application) and then click Browse Tags.
Tag name, description, and data type information appear in a table in the workspace on
the right. (You may need to adjust the table to view all columns.) This table contains
the tag descriptions, but does not indicate whether a tag is a global tag.
3 To see which tags are global tags, right-click MyExamplesApp, click View, and then click
View Xref Table. The CT Name/Anim Type column identifies whether a tag is a global tag.
4 Click Window > Close All to close all grid views.
Application Objects
Application object examples are part of the Examples Application or FLNEW
template applications in Configuration Explorer. An application object is a collection
of template variables, configuration objects, and file objects that is specifically
configured to populate one or more configuration tables in the Monitor Pro Server.
There are two main advantages for using application objects:
Increased
development
productivity
Simultaneous development by users with different Monitor Pro
skill levels
Reusability of common variables and objects
Structured configuration methodology
Easier
application
maintenance
Organized view of records grouped by function

Ability to add, insert, and remove instances per changing
specifications
Ability to recalculate all the instances of an application object
from revised data source files
Application objects use the example input source files located in the
{FLAPP}\AppObj directory to dynamically populate one or more Monitor Pro task
configuration tables.
As an application object is copied to an application, each application objects instance
is written to the Instances database file (AOInstance.mdb). After successful
completion of each instance, the configuration tables database record is written to that
tables database (*.cdb) file.
Examples of Application Objects
The application objects in the Application Object Classes directory are configured as
examples of typical functions that are required in a Monitor Pro development project.
Table 7-1 explains the objects in the Examples Application.
Note: Several useful application objects are available in the FLNEW templates.
Table 7-1 Objects in the Examples Application
Object
Analog2
Analog4
AnalogKB
AnalogOut
Block
Digital1
Description
Analog Input with Two/Four Alarm States configures an analog

input from an Excel spreadsheet in these task functions:
Read from an OPC server
Scale to engineering units
Log to a database
Alarm on high and low limits
Analog Input with Scaling from Keyboard Entry configures an
analog input from a keyboard manual entry in these task functions:
Scale to engineering units
Analog Output for Write configures an analog output from an Excel
spreadsheet for a write to an OPC server.
Example for Instance and Offset configures a block of related tags
from an Excel spreadsheet for Math and Logic variables.
Digital Input with One Alarm State configures a digital input from
an Excel spreadsheet in these task functions
Alarm for an ON condition
Table 7-1 Objects in the Examples Application (continued)

Object
Description
Digital4
Digital Inputs with Four Alarm States configures two digital inputs
from an Excel spreadsheet in these task functions
Calculate the four analog states of two digital inputs using Math
and Logic
Alarm for the four analog conditions
DigitalKB
Digital Input from Keyboard Entry configures a digital input from a
keyboard manual entry for read from an OPC server.
DigitalOut
Digital Output for Write configures a digital output from an Excel
spreadsheet for a write to an OPC server.
FLVRNSetup VRN Setup configures an application for redundancy using the
VRN task.
MLDPSim
Math and Logic Simulator for Analog2 configures tags from an
Excel spreadsheet for Math and Logic trigger, variables, and program
for simulation of the analog inputs for the prior Analog2 object.
PCAlarms
Alarms for Parent Child Example configures tags from an ODBC
database for alarming with a parent-child dependency relationship.
RGAnalog
Report Generator for Analog2 configures tags from an Excel
spreadsheet for a report generation of the analog inputs for the prior
Analog2 object.
TagArray1
Tag Array Example 1 configures tag arrays using one column for
tags[index] from an Excel spreadsheet for Math and Logic
variables.
TagArray2
Tag Array Example 2 configures tag arrays using two columns for
tags and index from an Excel spreadsheet for Math and Logic
variables.
TextTest
Tag Test for Text Source File configures tags from two types of text
file extensions (.txt and .csv) for Math and Logic variables.
XLMaster
Master Excel Spreadsheet for IO an example of using an Excel
Spreadsheet to define the I/O for the application.
Application Object Overview Diagram

The graphic at the end of this section illustrates how data flows from the developers
raw information to the configuration tables. This process has the following sections:
Where the Data Comes
From
Raw configuration data can be a user input or a source
file.
User input can be entered by keyboard or by record
generator panel.
Source file data types can be a text file, a spreadsheet,
How the Classes are

Defined
or a database.
Template variables define the input or source
parameters.
Template variables can be used in configuration
objects, file objects, and application objects.

Configuration objects define the template variables or
constants used in the configuration forms.

File objects define the template variables or text used
in the text forms.

Application objects define the collection of template
How the Application

Objects are Instantiated
into Configuration
Tables
variables and objects used to represent a functional

equipment object.
Application objects are instantiated using a
copy-and-paste method from the Classes tables to the
Instances tables within the application objects
database.
Tables of application object instances within the
database are used to record and maintain the location

of the instantiated objects within the Monitor Pro
application.
Each successful instantiation is then written as a
record to the Monitor Pro application configuration

tables and files.
{FLAPP}\Appobj default directory

- source files (gen,txt,csv,xls,mdb)
- property page files (htm)
Source
(configuration raw data)
Application Object Classes Tables

- created in AOInstances.mdb
User Input or Source File

- Keyboard
- Generated
- Text File
- Excel spreadsheet
- ODBC Database
Template Variables
(input source definitions)
Configuration Objects
(configuration table forms)
File Objects
(configuration text forms)
Application Objects
(collection of variables and objects)
Application Object Instances Tables

({FLAPP}\Appobj\AOInstances.mdb)
Monitor Pro
Application Directory
Configuration Tables
({FLAPP}\*.cdb files)
On instantiation, the objects

are written to the Instances
tables and then to the
Configuration tables
Changing Computer Location
C HANGING C OMPUTER L OCATION

The Examples Application is designed to run on a computer where both the server and
the client are installed. However, if you want the Examples Application files to work
with a server installed on the local machine and the client installed on a remote
machine, you must change the information regarding the computer location.
Perform the following steps to change the computer location information for both run
time and design time.
1 Double-click the Examples Application Client Project icon from your desktop.
Client Builder opens the Examples.fvp file from the Program Files\Telemecanique\
FactoryLink\Applications\Examples App\CBPROJ directory.
2 When Client project opens in Client Builder, select Tools > Servers from the menu.
3 At the Servers Editor dialog box, expand ServerTypes to display the AlarmServers,
OPCServers, and TrendServers.

Note: If you click each of the server types, the corresponding Communication
Manager information is displayed on the right. You will want to keep the
settings as they are with the computer pointing to the local host, MyComputer.
4 Expand AlarmServers and click Alarm_a to display the Run Time and Design Time
setting fields.
Note: Both the Run Time and Design Time are currently pointing to the local
computer, MyComputer. The Prog ID related to the local computer is displayed

in the Prog ID field under each section.
5 In the Run Time section, click the Computer field drop-down arrow and browse to the
server node name to be used for run time. Expand the server node name to display the
related Prog IDs. Double-click FLAlarmServer.AlarmServer.1 to select it to be displayed
in the Prog ID field on the Servers Editor.
6 In the Design Time section, click the Computer field drop-down arrow and browse to
the server node name to be used for design time. Expand the server node name to
display the related Prog IDs. Double-click FLAlarmSrvDesign.AlarmServerDesign.1 to
select it to be displayed in the Prog ID field on the Servers Editor.
7 Expand OPCServers and click OPC_a to display the Run Time and Design Time setting
fields.
8 Repeat Steps 5 and 6 to select the OPC servers to be used for run time
(Tecnomatix.Server) and design time (Tecnomatix.DevServer).

9 Expand TrendServers and click Trend_a to display the Run Time and Design Time
setting fields.
10 Repeat Steps 5 and 6 to select the Trend servers to be used for run time
(TrendDSServer.TrendServer.1) and design time (TrendDSServer.TrendServer.1).

11 Click OK to close the Servers Editor dialog box.
Note: For a redundant system, set Alarm_b, OPC_b, and Trend_b to your
second machine.
Chapter 8
Application Setup Wizard
The Application Setup Wizard provides a quick and easy way to create a Monitor Pro
application that contains basic configuration. This wizard steps through choices such
as database setup, and allows the selection for one of three templates to create both the
server application and client project.
Available in Configuration Explorer, the Application Setup Wizard has the following
functionality:
The wizard prompts for the name and location of the combined project (server and
client), the type and location of the historical database, the template project to be
restored, and the primary and secondary node servers.
The wizard creates both the client project and the server application at the same
time using a template that can be modified. (The wizard lets you choose from three
templates that are variations of the FLNEW template, each with a different interface
format.)
The client project is restored to a subdirectory under the server application
directory, thus more closely associating the client and server components of the
Monitor Pro application as one project in a single directory.
The client project automatically connects to the server created in the same project.
The wizard automatically sets up the run-time and design-time OPC servers
including update rate, sets up the Monitor Pro NameSpace database, adds the
Monitor Pro application to the NameSpace database, and associates the client
project with the server application.
The feature is extensible so companies can use their own applications to create
custom templates that can be added to the wizard.
To access this wizard, right-click your Monitor Pro Server name and select the
Application Setup Wizard. The Configuration Explorer Help provides detailed
information about using this wizard. The Monitor Pro Tutorial contains an exercise
that lets you practice using the wizard.
8 | APPLICATION SETUP WIZARD

Application Setup Wizard Templates
A PPLICATION S ETUP W IZARD TEMPLATES

The three templates that you can select from the Application Setup Wizard have the
same server application, but different client project presentation formats:
FLNEW_TopMenu.zip contains a FLNEW server application and a FLNEW
client project that shows a menu at the top of the Client Builder screen and uses
menus for selecting different mimics drawings. (This template is the default
template.)
FLNEW_SideMenu.zip contains a FLNEW server application and a FLNEW
client project that show a menu at the left side of the Client Builder screen. The
drawings are selected directly from the menu.
FLNEW_CornerMenu.zip contains a FLNEW server application and a FLNEW
client project that show a menu as a square in the upper left corner of the Client
Builder screen. This project uses only icons with no text. Some other features
appear in this template include a screen print button and animated alarm icon. These
features can be adapted to any project.
All three templates contain application objects for generating a few common
configurations as well as some Communications Drivers examples. All of the
templates use a bitmap logo file that can be replaced by your companys logo. This file
is in the Bitmap Files folder and is named logo.bmp.
The FLNEW template applications are fully configurable baseline applications with
functionality common to most Monitor Pro applications. Using any of these template
applications as a foundation, you can modify the existing components to meet your
industry-specific needs, therefore reducing the time and effort required to configure a
new application.
They contain predefined application objects for standard OPC inputs and outputs.
When used as the basis for an application, they can have a positive effect on the cost
of building and maintaining the application. The FLNEW templates provide a jump
start for application development with the following functionality:
Screen navigation
Application objects
Basic timers
APPLICATION SETUP WIZARD | 8

Application Objects in Server Templates
A PPLICATION O BJECTS
IN
S ERVER TEMPLATES
The Server Application, which is used in all three templates, has minimal
configuration so that you can add things without conflicting with existing tags or
configuration.
Several application objects are included to assist new users on some of the common
configurations. The application objects can be found in the Application Object Classes
folder in Configuration Explorer.
These application objects can be used to configure a few of the common subsystems.
The most common subsystem is probably the configuration for database logging that
is used for a trend chart. This configuration generates the Database Logger and
Database Schema tables required for logging trend points to a database.
General Objects
To use one of the application objects, just drag the object from the Application Objects
folder to the Application Object Instances folder. This generates the configuration
tables included in that object.
For example, drag the FLDBLogSetup object to the Application Object Instances
folder. The FLDBLogSetup object displays the following dialog box:
In this dialog box, you choose the log rate for the database points that you will log for
this table. Choose either seconds or minutes, but not both. This creates an instance of
this object.

To log points at different rates, add instances to this object by right-clicking the object
in the Application Object Instances folder and selecting Add Instances.
You can add one or more instances and choose other log rates. Each instance displays
in the tree and in the Database Logger and Database Schema configuration. This will
set up the general structure of the database indexed by time.
To add data points to the logger, use the FLDBLogAddPoint object. Dragging this
object to the Application Object Instances folder displays the following dialog box:
Be sure to choose the same time interval as the logger setup.
APPLICATION SETUP WIZARD | 8

VRN Setup Object

Another very useful application object included in the FLNEW template applications
is the FLVRNSetup object. When you instantiate this object, you are prompted for the
following information:
What is the remote node name for redundancy?
Will you be using the ODX/ECI task for OPC communication?
Will you be using the IOXlator/RAPD tasks for driver communication?
Will you be transferring all tags between servers?
It is much easier to use this application object than to fill out all the tables manually.

Driver Objects
Some application objects provide example configurations for common
communication drivers. These include the following:
Allen-Bradley RAPD
Modbus Serial
Modbus Plus
Modbus TCP
ODX Client to RSLinx and OFS Servers
Siemens Sinec H1 RAPD
If you choose the ODX example, be sure to run the VRN setup and choose the
ODX/ECI choice for proper redundancy and mailbox setup. Make this choice even if
you are not going to use redundancy.
Chapter 9
Getting Help
M ONITOR P RO D OCUMENTATION
The Monitor Pro product has helpful information available in two formats: Help files
and PDF documents. You must have a PDF Reader installed to view the PDF files. A
version of Adobe Reader is available on the Monitor Pro CD or from the Adobe web
site (http://www.adobe.com).
The Monitor Pro documentation is located in the
Telemecanique\FactoryLink\Documentation directory. You can access the documents
quickly by double-clicking the Monitor Pro Documents icon on your desktop and
clicking a link to the document you want to view. You can also click the View Index by
Topics link to open an index that links to various topics in the PDF files.
Document Name
Purpose
Add-On User Guide
Provides information about the add-on modules

included with the base Monitor Pro system.
Client Builder Help
Explains how to use the Client Builder, the tool used

to design user interfaces for a Monitor Pro application
by creating a graphical representation of an industrial
process and linking the graphics to real-time OPC
data.
Help
Explains how to use the Configuration Explorer, the

tool used to create a Monitor Pro Server application.
With Configuration Explorer, you can define and
configure tags, logic, and reusable application objects.
Conversion Guide
Provides information about converting from earlier

versions of Monitor Pro to the current version.
Device Interfaces Using

EDI Technology
Provides detailed information about configuring

Monitor Pro to communicate with remote devices that
use EDI technology.

RAPD Technology

use RAPD technology.
9 | GETTING HELP
Monitor Pro Documentation
Document Name

OPC and Other
Technologies
Purpose

use OPC and other technologies.
ECS Graphics and

Provides information about the tools used to build
WebClient Reference Guide Monitor Pro applications prior to version 7.0. This
document includes information about the Application
Editor, WebClient, PowerSPC, and PowerVB
Animation.
External Connectivity
Guide
Provides information about standards used to bridge

data between the Monitor Pro real-time database and
other systems.
Fundamentals Guide
Provides a getting started overview of Monitor Pro,

including concepts and architecture, the planning
process, restoring and using the Examples
Application, upgrade considerations, and reference
information.
Glossary
List of terms used with the Monitor Pro product.
Installation Guide
Provides hardware and software requirements and

instructions about how to install the Monitor Pro
software. Also included are instructions for installing
Microsoft SQL Server.
Programmers Access Kit
Provides a collection of software tools for use in the

design and development of Monitor Pro-compatible
tasks.
Task Configuration
Reference Guide

Monitor Pro tasks for your application.
Tutorial
Guides you step-by-step through the process of using

Monitor Pro configuration tools to create a simple
Monitor Pro application.
Unity Pro Browser Help
Explains how to use the Unity Pro Browser, a

configuration tool that reads a project from Unity Pro
and adds the variables in the project to the Monitor
Pro application.
Utilities Guide
Provides information about the Monitor Pro utilities

used for general maintenance and troubleshooting.
GETTING HELP | 9
Customer Support
C USTOMER S UPPORT
If you have any questions about the use or application of the Monitor Pro product,
contact your Schneider Electric local country representative.
Free Subscription Period
The free subscription period is provided at no charge with the purchase of each
Monitor Pro 7.6 software package. It is good for a period of ninety (90) days only.
9 | GETTING HELP
Customer Support
Appendix A
Monitor Pro Directory

Organization
Monitor Pro applications can be installed on any appropriate drive. However, for the
purposes of this document, installations are assumed to be on a C:\ drive.
When you install Monitor Pro, the installation program creates five directories under
Program Files\Telemecanique\FactoryLink. The five directories are Applications, Client,
Documentation, Installs, and Server. The shared files common among Telemecanique
products are installed in the Telemecanique\Common directory.
Directory
Telemecanique\Common
FactoryLink\Applications
Subdirectory
Client Builder
Contents
Program
Contains Client Builder application files
Shared
Libraries
Contains clip art libraries
Template
Project
Contains the template project that Client Builder copies

and renames to create new Client Builder projects
Compressed
Contains compressed client (.cba) and server (.mps)

applications. If the Examples Application is installed,
this folder contains the dBASE IV and SQL versions of
the Examples Application in German, English, and
French.
Note: New applications can be stored in any

location; however, if you find it convenient, you can
store them in this directory.
Examples App
If the Examples Application is installed, this directory

contains the application files, which include the server
application files and the client project files.
Server Application: The server application files and
folders are restored at the root of the Examples App
directory. The server application is configured in
Configuration Explorer.
Client Project: The client project files are restored in the
CBPROJ folder in the Examples App directory. The
client project is configured in Client Builder.
admin
Administration files for ECS graphics
appobj
Source and build files for application objects
asc
ASCII database tables that store information about the

elements. Used to import/export configuration data
from one application directory to another
A | MONITOR PRO DIRECTORY ORGANIZATION
Directory
FactoryLink\Applications
(continued)
FactoryLink\Client
Subdirectory
Examples App
(continued)
Contents
CBPROJ
Client project files. The client project is launched by

opening the EXAMPLES.FVP file in Client Builder
cml
Compiled Math and Logic files
ct
Binary configuration tables. Each Monitor Pro program

employs one or more configuration files
dbt
Files for the real-time database on-line browser
dct
External device interface ct files
drw
Graphics and PowerVB files used by run-time graphics

files
etm
Files for the Event Time Manager (ETM) task
flapp1
Persistence and log files specific to the running

application
log
Error files produced by Monitor Pro processes at run

time containing debug information
mmi
Files for the MMI task, if MMI is used
msg
Message files for all tasks for the running application
net
Groups on this node
procs
Math and Logic procedures
rcp
Files created by the Batch Recipe task
rpt
Report files generated by the Report Generator task
shared
Shared domain-specific files
spool
Subdirectory used by the Monitor Pro Print Spooler task
user
User domain-specific files
Historical Reports
Contains the Microsoft Office Access Project for the

Monitor Pro Historical Reports (Historical Reports.adp)
NameSpace
Contains the database that holds the locations of

remote Monitor Pro servers used by Configuration
Explorer
Templates
Templates containing Application Objects for

generating common configurations used with the
Application Setup Wizard
If Configuration Explorer is installed, this directory

contains the application files.
WebClient
If the Monitor Pro WebClient ActiveX control is

installed, this directory contains the application files.
MONITOR PRO DIRECTORY ORGANIZATION | A
Directory
Subdirectory
FactoryLink\Documentation ReleaseNotes.htm
FactoryLink\Installs
Contents
Provides installation tips, updates, miscellaneous
issues, and other important information
Deutsch
Monitor Pro documentation in German for the installed

components
English
Monitor Pro documentation in English for the installed

components
Francais
Monitor Pro documentation in French for the installed

components
CBSetup.msi
The program installer for the One-Click Client. If moved

to a different location, this file must appear in the same
directory as the OneClick.exe file.
OneClick.exe
The installation for the One-Click Client used to install a

client on a remote system. If moved to a different
location, this file must appear in the same directory as
the CBSetup.msi file.
FLOCX.exe
A backward-compatible installation for COM protocol

access to Monitor Pro tags
Microsoft Access 2003 Runtime
Contains the Microsoft Access RunTime Viewer

(ACCESSRT.MSI) installer used to view the Monitor
Pro Historical Reports
IsoTsp2000
The installation for the OSI protocol stack used with the
Siemens Sinec H1 driver
LicenseServerInstall.exe
The installation for the License Utility that defines the

client license servers and designates a license server
for redundancy
MECOM
If MECOM is selected during installation, this directory

contains an installation for the MECOM driver.
S7D
If S7D is selected during installation, this directory

contains an installation for the S7D driver.
WebClientInstall.exe
A backward-compatible installation for the WebClient

ActiveX control. After installed, the files reside in the
FactoryLink\Client\WebClient directory.
XMLAdapterInstall.exe
Installation for the XML Adapter that allows easy

integration of Monitor Pro with leading XML-based
products
A | MONITOR PRO DIRECTORY ORGANIZATION
Directory
FactoryLink\Server
Subdirectory
Contents
FLBuild.Id
A file that determines the Monitor Pro version.
AC
Text files that function as attribute catalogs to inform

the main menu of the format of the configuration tables.
They also control entry criteria.
BIN
Monitor Pro command files, executable program files,

and related support files for each task, including the
task executables.
AddOns
Files for the Monitor Pro add-ons
Blank
Files used by Monitor Pro utilities that manage

applications, such as FLNEW, FLSAVE, FLREST, and
FLCONV
CML
Default make file for the Compiled Math & Logic task
CTGEN
Configuration database conversion script files
DLL
Monitor Pro multilingual system files
DRW
System files used by the Graphics task and by Client

Builder
Edi
Subdirectory for External Device Interface protocol

modules
HELP
Text files for the field-level Help
INC
C-language include files for options such as Compiled

Math & Logic and the Programmers Access Kit (PAK)
Install
Current language of the Monitor Pro installation
KEY
Text files used to translate text table entries into binary

values to be placed in configuration tables
Legacy
Backward-compatible files used with Monitor Pro. To

use a legacy file, you must copy it to the BIN directory.
LIB
Library files and objects used with the PAK
MPS
Demo application, new application, and test application

files
MSG
Status message and error message files for Monitor

Pro tasks
OBJ
Library files for PAK
OPT
Licensing files
Plc
Sample program files for Siemens PLCs
src
External Device Interface PAK C-source files, libraries,

and sample protocol module and sample PAK source
and make files
Telemecanique\ofs
Installation, application, and documentation files for the

OPC Factory Server (OPS) product
Appendix B
Real-Time Database and Tag

Structure
The real-time database is the area of the Kernels shared memory used to store the
current value of the application tags. It exists only in memory and does not persist
between subsequent invocations of the Monitor Pro system.
R EAL -T IME D ATABASE STRUCTURE

The real-time database is made up of arrays and pointers. Each array consists of up to
65,534 tags of a single data type. When you define a tag, the system prompts you to
identify the tag data type by choosing one of Monitor Pro predefined data types. The
following table shows the storage capacities, ranges, and accuracies of each data type.
Data Type
Value
Storage in User
Area
Storage in
Kernel Area
Value Range
and Accuracy
Digital (Boolean)
1 bit
2 bytes
12 bytes
1 (ON) or 0
(OFF)
Analog (Short
integer)
2 bytes
2 bytes
14 bytes
-32,768 to
32,767 (signed)
Long Analog (Long

integer)
4 bytes
4 bytes
16 bytes
-231 to 231 -1
Floating point (IEEE

standard/double
precision)
8 bytes
8 bytes
20 bytes
+/-10-308 to
+/-10308
Message (String)
0 to 65534
bytes
0 to 65534 bytes 20 bytes per

message +
storage of data
ASCII or
arbitrary binary
data
0 to 65534
Mailbox (Variable
length data organized bytes
as a queue)
0 to 65534 bytes 20 bytes per

message +
storage of data
Arbitrary binary
data
B | REAL-TIME DATABASE AND TAG STRUCTURE

Real-Time Database Structure
Use the following formulas to determine memory requirements:

Formula = storage requirement for a tag defined for the Shared domain:
(N - 4) + (4 x I)
where:
N Is the storage in Kernel area from the table above.
I Is the number of instances (shared + user).
Example:
A Shared domain long analog tag in a system with a maximum of two User instances:
[20 bytes (from table) - 8] + {8 x [1(shared) + 2 (user)]} = 40
bytes
Formula = storage requirement for a tag in the User domain:

(N x I)
where:
N Is the storage in Kernel area from the table above.
I Is the number of instances (shared + user).
Example:
A User domain float tag in a system with a maximum of two User instances:
24 bytes (from table) x [1 (shared) + 2(user)] = 72 bytes
The Monitor Pro Kernel uses data types and tag numbers to read from or write to tags
in the real-time database.
REAL-TIME DATABASE AND TAG STRUCTURE | B

Tag Structure
A tag consists of the following items:
One or more bits containing the value
Set of change-status bits (change-status word)
Set of wait bits (wait-status word)
Set of reserved bits
Monitor Pro preallocates a single bit to each potential client task in each of these
status words. Each domain instance has potentially 31 possible processes. The 32nd
bit is a digital tag value or unused.
Change-Status Bits
For each tag, one change-status bit exists for each potential client process. The
read-call and write-call functions use the change-status bits within the Monitor Pro
Kernel to indicate changes in a tag value. The value of the change-status bit can be
either ON (1) or OFF (0).
Monitor Pro tasks write information to tags through either:

Write call
Forced-write call
Tasks use the Kernel Services write-call function to update a value of a tag. This
function first determines whether the tag value changed. If the new value differs from
the old, the write-call function sets each of the tag change-status bits to 1 (ON) and
stores the new value in the tag; however, if the comparison determines the new value
for the tag is identical to the old, nothing changes. This method saves processing time
because tasks watching the tag will not waken to process unchanged values.

Alternatively, the writing task can also use the Kernel services forced-write function.
This function does not compare old and new values. Instead, the forced-write call
function assumes the tag has changed and sets all of the tag change-status bits to ON
as it stores the new value, even if the updated value being assigned to the tag is the
same as the old. Forced writes are useful when you need to trigger processes setting
the tag change bit but do not wish to change the actual content of the tag or when a tag
needs to be processed a second time, even if its value has not changed.
Use write calls except when the forced-write call is specifically needed.
Monitor Pro tasks read information from tags through:
Read calls
Change-read calls
Change-wait calls
The read-call function always returns the current value of the tag to the calling process
regardless of the value of the tag change-status bit assigned to that process.
When a task makes a change-read call, the reading task requests change-status
information about specific tags. If the function finds that the change-status bit of a tag
has been set since it was last read, the function informs the calling task it has found a
changed tag and returns the value of the first changed tag found. If the change-status
bits have not been set since the last read for any of the specified tags, the change-read
call function returns a code indicating this to the calling task. This method blocks the
calling routines processing for less time than reading and comparing the values of all
the tags.
When a task makes a change-wait call, the reading task uses the change-wait call
function within the Kernel to request change-status information about specific tags.
Once a task makes its call, the task then hibernates while waiting for a tag to change.
When a task is asleep, it uses no CPU cycles. The task wakes when any one of the
specified tags have changed and/or have had their change-status bits set to 1 (ON) by
another task since the last reading. In other words, this call blocks the calling process
until at least one of the specified tags change-status bits are toggled.
Regardless of the method used to read a tag, the act of reading a tag resets the tag
change-status bit associated with the reading task to OFF by writing a 0 to the task
change-status bit in the tag. As successive tasks read a tag, they toggle the
change-status bits in the tag, one by one, to OFF.

The Kernel maintains the change-status bits in a manner transparent to the tasks;
however, you can use these bits in the Math and Logic task.
For example, you can write a Math and Logic procedure that uses the operator to
determine whether the value of a tag has changed and then take an action.
Change-status bits optimize system performance in the multi-tasking environment.
Monitor Pro tasks use change-status bits as exception flags and the Kernel acts as an
exception processor.
Exception processor terminology is uniform across all Monitor Pro documentation
and should not be confused with the traditional use within the industry of the term
exception processing to mean error handling or CPU exception recovery.
This allows Monitor Pro tasks to perform functions on an exception-only basis or only
on those tags whose values have changed rather than continuously reprocessing
unchanged information. This method results in increased software performance.
Wait bits: For each tag, one wait bit exists for each possible client process. When the
client is currently waiting to read the specified tag, the value of the bit is 1 (ON);
otherwise, the value is 0 (OFF).

Real-Time Database Access Reads and Writes
R EAL -T IME D ATABASE A CCESS R EADS
AND
WRITES
Although knowledge about how tasks access the real-time database is not required to
develop an application, this knowledge can help you understand what occurs as an
application runs and can also help with troubleshooting.
Tasks access the real-time database to read values from tags and to write values to
tags. When a task accesses the database, that tag actually is making a call to the
Monitor Pro Kernel. The Kernel is the part of the real-time database that manages the
reads and writes. The Kernels function is transparent to you.
The following are the types of read and write calls:
Normal (conditional) write
Forced (unconditional) write
Change (conditional) read
Normal (unconditional) read
You do not have to configure which write or read call a task makes. The type of call a
task makes to the real-time database is programmed into the task as part of its code.
The task makes the appropriate calls, depending on its particular purpose.
Normal (Conditional) Write
A normal write occurs only if the new value being written to the tag is different from
its current value. Therefore, this type of write action is conditional. Is the new value
different from the current value? The Kernel checks this condition. If true, the Kernel
performs the write and sets the tags change-status bits to 1. If false, the Kernel does
not perform the write, and the change-status bits remain 0.
For example, given the following information:
A tag is named Tank1.
Its current value is 10.
The Interpreted Math and Logic task (IML) is configured to perform a calculation
and assign the result to Tank1.
Example 1
IML performs its calculation and the result is 10. IML makes the normal write call to
the database and the Kernel compares the current value of Tank1 with the new value

from IML. The current value is 10 and the new value is also 10. Because the old and
new values are the same, the Kernel does not continue with the write, and the current
value remains in Tank1. Because the Kernel does not perform the write, the
change-status bits for Tank1 remain zero. Therefore, no tasks are notified to perform a
read of Tank1.
Example 2
IML performs its calculation and the result is 20. IML makes the normal write call to
the database, and the Kernel compares the current value of Tank1 (10) with the new
value from IML (20). Because the old and new values are different, the Kernel writes
20 to Tank1. Because the Kernel performed the write, it sets the change-status bits for
Tank1 to 1. Therefore, the Kernel notifies any tasks waiting for a change on Tank1 that
they should read the new value.
Forced (Unconditional) Write
Unlike the normal write, the forced write updates the value whether or not that value
differs from the previous value. Therefore, this type of write action is unconditional.
Regardless of the tags status, its change-status bits are forced to 1.

Using the previous example:

A tag is named Tank1.
Its current value is 10.
The Interpreted Math and Logic task (IML) is configured to perform a calculation
and assign the result to Tank1.
IML performs its calculation and the result is 10. IML makes the forced-write call to
the database. The Kernel writes the new value of 10 to Tank1. Because the Kernel
performed the write, it sets the change-status bits for Tank1 to 1. Therefore, the Kernel
notifies any tasks waiting for a change on Tank1 that they should read this new value.
Change (Conditional) Read
A change-read call returns the value only if the data has changed. The condition asks:
Are the change-status bits for the tag set to 1? If the change-status bits are 1, then
the value must differ from the last read, so the Kernel notifies waiting tasks to read the
value again. This type of read significantly optimizes performance.

Normal (Unconditional) Read

An unconditional-read call returns the value regardless of whether the value has
changed since the last read. This is a forced read.

Tag Structure
TAG S TRUCTURE
If you could see a tag, you would see that it consists of a number of bits. Excluding the
bits required for the tags value, each tag, regardless of its data type, has the same
basic bit structure.
Basic Tag Structure
All tags require 16 bytes just for the structure of the tag. The 16 bytes are designated
in the following way:
4 bytes that function as change-status bits
4 bytes that function as change-wait bits
8 bytes that are reserved for future use.
This illustration shows the basic bit structure for each tag in the real-time database.
4 Bytes--Change-Status Bits
The change-status bits are very important to the Monitor Pro system.
Change-Status Bits
Change-status bits enable Monitor Pro to operate based on exception processing.
Exception processing means that tasks do not access the database to read a tags value
unless the tags value has changed since the last time it was read.
Each Monitor Pro task is assigned to a change-status bit. The task looks at the same bit
in each tag you define. (The diagram above is only an example. The order in which the
tasks are assigned is irrelevant.) The value of the bit determines whether the tags
value has changed.

Tag Structure
The bit is set to either 1 (ON) or 0 (OFF).

One (1) indicates to a task that the value of the tag has changed since the last time it
was read, so the task will access the database again to read the tags new value.
Zero (0) indicates that the tag value has not changed since the last time it was read,
so the task will not access the database unnecessarily to read a value that did not
change.
When a task writes a value to a tag, Monitor Pro automatically sets all change-status
bits to 1. When a task reads a tag, it sets only that tasks individual change-status bit to
0. The change-status bits for tasks not configured to read a tag always have a value of
1; they do not affect other tasks or the application.
Unless you define a default value for a tag, the start value of all change-status bits is
zero (0), indicating that no activity has taken place.
Digital Tag Structure
A digital tag contains 16 bytes:
The first bit stores the tag value (either 0 or 1).
The second bit through the thirty-second bit store the value for the change status of
each task (a total of 31 tasks).
The next four bytes are change-wait bits used to allow a task to sleep until a tags
value changes.
The final eight bytes are reserved for future use.

Tag Structure
Analog Tag Structure

An analog tag contains 18 bytes. The structure of an analog tag is the same as that of a
digital tag, but with two additional bytes to contain the tag value.
Longana Tag Structure

A longana tag contains 20 bytes. The structure of a longana tag is the same as that of a
digital tag, but with four additional bytes to contain the value of the tag.

Tag Structure
Float Tag Structure

A float tag is 24 bytes. The structure of a float tag is the same as that of a digital tag,
but with eight additional bytes to contain the tag value.
Message Tag Structure

A message tag is 24 bytes plus the bytes needed to store the message.
The structure of a message tag is the same as that of a digital tag, but with 8 additional
bytes:
4 bytes to point to the memory location where the actual message is stored
2 bytes to specify the maximum message length
2 bytes to specify the current length of the message with the additional bytes
required to store the message.

Tag Structure
Mailbox Tag Structure

Mailbox tags are different from other data types. Their values do not get overwritten,
because new values are appended (queued) to current values already stored.
A mailbox tag contains 24 bytes plus bytes for storing the length of the value and the
number of values.
The 24 byte-structure of a mailbox tag is the same as the 24-byte structure of a
message tag:
The basic 16-byte tag structure
4 bytes to point to the memory location where the actual message is stored
2 bytes to specify the maximum message length
2 bytes to specify the current length of the message
Additional bytes are required to store the mailbox messages and the number of
messages.

Monitor Pro

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Monitor Pro

Transféré par

Droits d'auteur :

Formats disponibles

Monitor Pro

Copyright Schneider Automation SAS 2005.

Introducing Monitor Pro.............................................................................. 1

Features, Tasks, and Tools .......................................................................... 9

Monitor Pro Fundamentals Guide / iii

iv / Monitor Pro Fundamentals Guide

Domain Structure .......................................................................................................

Planning Your Application ....................................................................... 87

Monitor Pro Fundamentals Guide / v

Examples of Application Objects ............................................................................. 108

Application Setup Wizard......................................................................... 115

Getting Help.............................................................................................. 121

Appendix A Monitor Pro Directory Organization ....................................................... 125

vi / Monitor Pro Fundamentals Guide

Introducing Monitor Pro

Monitor Pro Fundamentals Guide / 1

1 | INTRODUCING MONITOR PRO

H OW M ONITOR P RO C AN H ELP YOU

2 / Monitor Pro Fundamentals Guide

INTRODUCING MONITOR PRO | 1

Microsoft Visual Basic for Applications

Monitor Pro Fundamentals Guide / 3

1 | INTRODUCING MONITOR PRO

Two Types of Graphics Technology

Multiplatform graphics Monitor Pro ECS (Pre 7.0)

Windows Technology Client Builder

4 / Monitor Pro Fundamentals Guide

The fundamental architecture of Monitor Pro is based on the latest Microsoft

T HREE -TIER M ODEL

Consists of the graphical user interface for

Business Processes data and

Consists of the Monitor Pro server that supports

Monitor Pro Fundamentals Guide / 5

Consists of a Standard Edition Microsoft SQL

6 / Monitor Pro Fundamentals Guide

Monitor Pro Fundamentals Guide / 7

S CALABLE S YSTEM S IZES

8 / Monitor Pro Fundamentals Guide

Features, Tasks, and Tools

Monitor Pro Fundamentals Guide / 9

3 | FEATURES, TASKS, AND TOOLS

10 / Monitor Pro Fundamentals Guide

FEATURES, TASKS, AND TOOLS | 3

Dynamic Data Exchange

Monitor Pro Fundamentals Guide / 11

3 | FEATURES, TASKS, AND TOOLS

12 / Monitor Pro Fundamentals Guide

FEATURES, TASKS, AND TOOLS | 3

Scaling and Deadbanding

Monitor Pro Fundamentals Guide / 13

3 | FEATURES, TASKS, AND TOOLS

Logging and Retrieving Data

System-wide event logging capability is supported to ensure the logging of three

14 / Monitor Pro Fundamentals Guide

FEATURES, TASKS, AND TOOLS | 3

Monitor Pro Fundamentals Guide / 15

3 | FEATURES, TASKS, AND TOOLS

Native Oracle Historian Interface

The Oracle Historian task provides a native interface to an Oracle 10 relational

The Database Browser control provided in Client Builder connects to a relational

16 / Monitor Pro Fundamentals Guide

FEATURES, TASKS, AND TOOLS | 3

Monitor Pro Fundamentals Guide / 17