Professional Documents
Culture Documents
Monitor Pro
Monitor Pro
Fundamentals Guide
Version 7.6
Contents
Chapter 1
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
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 .........................................................................................
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
Chapter 6
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
Chapter 8
Chapter 9
116
117
117
119
120
129
131
131
134
134
135
136
137
138
138
138
139
140
140
141
141
142
Chapter 1
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.
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++
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.
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
Description
In Monitor Pro
Client
Also known as the
Services user interface, this
tier is positioned
closest to the user.
2 | DISTRIBUTED ARCHITECTURE
Three-Tier Model
Tier
Description
Data
Stores and manages
Services an organizations
historical data.
In Monitor Pro
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
Chapter 3
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.
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.
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.
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.
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.
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
Other relational databases with ODBC support, such as Informix and DB2/2
dBASE IV (for support of pre-7.x applications)
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
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.
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
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.
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.
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).
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.
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.
Application Objects
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.
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 >
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
HISTORICAL REPORTS | 4
Generating Reports
4 At the Logon screen, type the username and password for a SQL Server user that has
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.
4 | HISTORICAL REPORTS
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
Specify your
own SQL
WHERE clause
8 After setting the criteria for the report, either click Preview to view the report
Figure 4-4 shows a sample report for the activities done by the MyAdministrator user.
HISTORICAL REPORTS | 4
Generating Reports
4 | HISTORICAL REPORTS
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.
5 | INTERNAL ARCHITECTURE
Real-Time Database
Tag Names
pump1_tmp
pump2_tmp
pump3_tmp
(Logically represents
a tag in database)
Real-time database
Tags
INTERNAL ARCHITECTURE | 5
Real-Time Database
5 | INTERNAL ARCHITECTURE
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>
Legal characters for the <node>, <name>, and <ext> strings are:
{A-Z}
{a-z}
{0-9}
{@$_}
INTERNAL ARCHITECTURE | 5
Monitor Pro Tags
5 | INTERNAL ARCHITECTURE
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
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.
INTERNAL ARCHITECTURE | 5
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.
5 | INTERNAL ARCHITECTURE
Predefined System Tags
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
INTERNAL ARCHITECTURE | 5
Predefined System Tags
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
5 | INTERNAL ARCHITECTURE
Predefined System Tags
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
INTERNAL ARCHITECTURE | 5
Predefined System Tags
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
5 | INTERNAL ARCHITECTURE
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
multi-dimensional
array
INTERNAL ARCHITECTURE | 5
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
[n1]
[n2]
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]
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]
5 | INTERNAL ARCHITECTURE
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_UpstreamPressure
Area1_Pump2_DownstreamPressure
Area1_Pump2_Speed
Area1_Pump3_UpstreamPressure
Area1_Pump3_DownstreamPressure
Area1_Pump3_Speed
INTERNAL ARCHITECTURE | 5
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).
5 | INTERNAL ARCHITECTURE
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.
INTERNAL ARCHITECTURE | 5
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.
5 | INTERNAL ARCHITECTURE
Branching
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.
INTERNAL ARCHITECTURE | 5
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.
5 | INTERNAL ARCHITECTURE
Branching
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.
INTERNAL ARCHITECTURE | 5
Branching
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.
5 | INTERNAL ARCHITECTURE
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.
INTERNAL ARCHITECTURE | 5
Branching
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
5 | INTERNAL ARCHITECTURE
Branching
Branching Shortcuts
The table below contains some useful shortcuts for branching.
Shortcut
Description
Where Used
link-open, link-close
link-open, link-close
symbols
symbols, label format
symbols, label format
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:
INTERNAL ARCHITECTURE | 5
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>
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]_[3]_[2]_Area1_Pump2_Flow
-4 or more
[4]_[3]_[2]_Area1_Pump2_Flow
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.
5 | INTERNAL ARCHITECTURE
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
Speed
Pressure
INTERNAL ARCHITECTURE | 5
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.
5 | INTERNAL ARCHITECTURE
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
See the Utilities Guide for instructions to configure redundant licensing for license
server operation.
INTERNAL ARCHITECTURE | 5
Redundant Licensing
Licensing Scenarios
Single System without Redundant Licensing
Remote Client
Builder
Local Client
Builder
Monitor
Pro Server
Server
FactoryLink
Serverwith
withLicense
License
Server
5 | INTERNAL ARCHITECTURE
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.
INTERNAL ARCHITECTURE | 5
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
5 | INTERNAL ARCHITECTURE
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
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.
INTERNAL ARCHITECTURE | 5
Redundant Licensing
Redundant
License Server
Pair Loses Then
Regains
Communications
5 | INTERNAL ARCHITECTURE
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
table.
Event-based data can be logged using a sequence
INTERNAL ARCHITECTURE | 5
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
changes
Use preconfigured tables and
name or both
Sort all logs of a tag in order of
or is triggered
Simultaneously log a group of like
criteria
Configure a table column to be a
occurrence
Configure a tag to be a dynamic pen
on a trend chart
Dynamically change the list of tags
5 | INTERNAL ARCHITECTURE
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
Database Browser Control
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.
INTERNAL ARCHITECTURE | 5
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.
5 | INTERNAL ARCHITECTURE
Database Browsing
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
At Run Time
INTERNAL ARCHITECTURE | 5
Database Browsing
At Design Time
At Run Time
5 | INTERNAL ARCHITECTURE
Database Browsing
INTERNAL ARCHITECTURE | 5
Database Browsing
At Design Time
At Run Time
5 | INTERNAL ARCHITECTURE
Database Browsing
INTERNAL ARCHITECTURE | 5
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
FLAPP = flapp_dir
FLDOMAIN = domain
FLNAME = app_name
FLUSER = user_name
FLOPT = opt_dir
SELECT_TIME=xx
RedundServer=name
5 | INTERNAL ARCHITECTURE
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
INTERNAL ARCHITECTURE | 5
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
5 | INTERNAL ARCHITECTURE
Multiuser Architecture
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
INTERNAL ARCHITECTURE | 5
Multiuser Architecture
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.
5 | INTERNAL ARCHITECTURE
Multiuser Architecture
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.
INTERNAL ARCHITECTURE | 5
Multiuser Architecture
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
5 | INTERNAL ARCHITECTURE
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
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.
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.
M INIMUM H ARDWARE
AND
S OFTWARE R EQUIREMENTS
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:
The speed at which colors are rendered depends on the choice of graphic adapter
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
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.
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
7 | EXAMPLES APPLICATION
Running the Examples Application
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.
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
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
7 | EXAMPLES APPLICATION
Server Application Overview
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.
EXAMPLES APPLICATION | 7
Server Application Overview
button.
7 When the Browse for Folder dialog box opens, browse to the drive and directory
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,
7 | EXAMPLES APPLICATION
Server Application Overview
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
application.
4 Do not change the source file format. The Compressed (Saved as single file) option is
Application.
6 When the Add Monitor Pro Application dialog box opens, type the name that you
OK.
8 At the Confirm Action dialog box, click Yes.
EXAMPLES APPLICATION | 7
Server Application Overview
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
Existing Application.
7 At the Add Monitor Pro Application dialog box, enter a name for the restored server
where you restored the compressed server application files. Click OK.
9 At the Confirm Action dialog box, click Yes.
Configuration Explorer, right-click the new server application and select Properties.
2 On the Application Properties dialog box, remove -nshared from the FLRunArgs property
7 | EXAMPLES APPLICATION
Client Project Overview
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
EXAMPLES APPLICATION | 7
Client Project Overview
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
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.
7 | EXAMPLES APPLICATION
Client Project Overview
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
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
EXAMPLES APPLICATION | 7
Client Builder Client Project
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
7 | EXAMPLES APPLICATION
Client Builder Client Project
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.
EXAMPLES APPLICATION | 7
Client Builder Client Project
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.
7 | EXAMPLES APPLICATION
Client Builder Client Project
EXAMPLES APPLICATION | 7
Server Application Components
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
skill levels
Reusability of common variables and objects
Structured configuration methodology
Easier
application
maintenance
specifications
Ability to recalculate all the instances of an application object
7 | EXAMPLES APPLICATION
Server Application Components
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
EXAMPLES APPLICATION | 7
Server Application Components
Description
Digital4
Digital Inputs with Four Alarm States configures two digital inputs
from an Excel spreadsheet in these task functions
Read from an OPC server
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.
7 | EXAMPLES APPLICATION
Server Application Components
file.
User input can be entered by keyboard or by record
generator panel.
Source file data types can be a text file, a spreadsheet,
or a database.
Template variables define the input or source
parameters.
Template variables can be used in configuration
EXAMPLES APPLICATION | 7
Server Application Components
Source
(configuration raw data)
Template Variables
(input source definitions)
Configuration Objects
(configuration table forms)
File Objects
(configuration text forms)
Application Objects
(collection of variables and objects)
Monitor Pro
Application Directory
Configuration Tables
({FLAPP}\*.cdb files)
7 | EXAMPLES APPLICATION
Changing Computer Location
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,
setting fields.
Note: Both the Run Time and Design Time are currently pointing to the local
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.
EXAMPLES APPLICATION | 7
Changing Computer Location
8 Repeat Steps 5 and 6 to select the OPC servers to be used for run time
setting fields.
10 Repeat Steps 5 and 6 to select the Trend servers to be used for run time
7 | EXAMPLES APPLICATION
Changing Computer Location
Chapter 8
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.
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:
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
Configuration Explorer
Help
Conversion Guide
9 | GETTING HELP
Monitor Pro Documentation
Document Name
Purpose
Fundamentals Guide
Glossary
Installation Guide
Task Configuration
Reference Guide
Tutorial
Utilities Guide
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
FactoryLink\Applications
Subdirectory
Client Builder
Contents
Program
Shared
Libraries
Template
Project
Compressed
appobj
asc
Directory
FactoryLink\Applications
(continued)
FactoryLink\Client
Subdirectory
Examples App
(continued)
Contents
CBPROJ
cml
ct
dbt
dct
drw
etm
flapp1
log
mmi
msg
net
procs
rcp
rpt
shared
spool
user
Historical Reports
NameSpace
Templates
Configuration Explorer
WebClient
Directory
Subdirectory
FactoryLink\Documentation ReleaseNotes.htm
FactoryLink\Installs
Contents
Provides installation tips, updates, miscellaneous
issues, and other important information
Deutsch
English
Francais
CBSetup.msi
OneClick.exe
FLOCX.exe
IsoTsp2000
The installation for the OSI protocol stack used with the
Siemens Sinec H1 driver
LicenseServerInstall.exe
MECOM
S7D
WebClientInstall.exe
XMLAdapterInstall.exe
Directory
FactoryLink\Server
Subdirectory
Contents
FLBuild.Id
AC
BIN
AddOns
Blank
CML
Default make file for the Compiled Math & Logic task
CTGEN
DLL
DRW
Edi
HELP
INC
Install
KEY
Legacy
LIB
MPS
MSG
OBJ
OPT
Licensing files
Plc
src
Telemecanique\ofs
Appendix B
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)
4 bytes
4 bytes
16 bytes
-231 to 231 -1
8 bytes
8 bytes
20 bytes
+/-10-308 to
+/-10308
Message (String)
0 to 65534
bytes
ASCII or
arbitrary binary
data
0 to 65534
Mailbox (Variable
length data organized bytes
as a queue)
Arbitrary binary
data
The Monitor Pro Kernel uses data types and tag numbers to read from or write to tags
in the real-time database.
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).
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).
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.
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.