Fundamentals Guide

FactoryLink
Version 8.0
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Fundamentals Guide
•
•
•
•
Disclaimer of Liability
The information contained in this document (and other media provided
herewith) constitutes confidential information of Siemens AG and is
protected by copyright laws and international copyright treaties, as well
as other intellectual property laws and treaties. Such information is not to
be disclosed, used or copied by, or transferred to, any individual,
corporation, company or other entity, in any form, by any means or for
any purpose, without the express written permission of Siemens AG.
The information contained in this document and related media
constitutes documentation relating to a software product and is being
provided solely for use with such software product. The software product
was provided pursuant to a separate license or other agreement and
such information is subject to the restrictions and other terms and
conditions of such license or other agreement.
The information contained in this document and related media is subject
to change without notice and does not represent a commitment and does
not constitute any warranty on the part of Siemens AG. Except for
warranties, if any, set forth in the separate license or other agreement
relating to the applicable software product, Siemens AG makes no
warranty, express or implied, with respect to such information or such
software product.
Trademarks
Siemens AG and FactoryLink are trademarks or registered trademarks of
Siemens AG in the United States and/or other countries. All other brand
or product names are trademarks or registered trademarks of their
respective holders.
Siemens AG Copyright © Siemens AG 2007.

Automation and Drives 0829/2007 Technical data subject to change
Postfach 48 48
90327 NÜRNBERG
GERMANY
Contents
Chapter 1 Introducing FactoryLink ............................................................................. 1

How FactoryLink Can Help You .......................................................................................... 1
How FactoryLink Works ...................................................................................................... 2
Object-Oriented Development ..................................................................................... 2
Redundancy .................................................................................................................. 2
Graphics Development ................................................................................................. 2
Chapter 2 Distributed Architecture............................................................................... 5

Three-Tier Model .................................................................................................................. 5
Development and Run-Time Systems .................................................................................. 7
Scalable System Sizes .......................................................................................................... 8
Developer-Defined Maximum Tags (Total Tags) ........................................................ 8
Input/Output Maximum Tag (I/O Tags) ....................................................................... 8
Chapter 3 Features, Tasks, and Tools .......................................................................... 9

FactoryLink Tasks ................................................................................................................ 9
Graphical User Interface ............................................................................................. 9
Device Interfaces ....................................................................................................... 10
Dynamic Data Exchange ........................................................................................... 11
OPC Data eXchange (ODX) ...................................................................................... 11
Enhanced Communication Interface (ECI) ............................................................... 11
XML Adapter .............................................................................................................. 11
General Tasks ............................................................................................................ 12
Utilities ....................................................................................................................... 13
Logging and Retrieving Data ..................................................................................... 13
Communicating Across a Network ............................................................................. 17
Multilingual Systems .......................................................................................................... 18
Configuration Tools ............................................................................................................ 19
Configuration Explorer .............................................................................................. 19
Client Builder ............................................................................................................. 26
Custom Development Tools ............................................................................................... 30
FactoryLink Fundamentals Guide / iii

•
•
•
•
Chapter 4 Historical Reports....................................................................................... 31
Overview ............................................................................................................................ 31
Generating Reports ............................................................................................................. 32
Chapter 5 Internal Architecture.................................................................................. 37

Open Software Bus ............................................................................................................. 38
Real-Time Database ........................................................................................................... 39
FactoryLink Tags ................................................................................................................ 41
Tag Naming Guidelines ............................................................................................. 41
Defining Tags ............................................................................................................. 43
Tag Properties ........................................................................................................... 44
Predefined System Tags ............................................................................................. 47
Triggers ............................................................................................................................... 48
Tag Arrays .......................................................................................................................... 49
Defining One-Dimensional Arrays ............................................................................ 49
Defining Multi-Dimensional Arrays .......................................................................... 50
Branching ........................................................................................................................... 51
Designing Tag Names for Branching ........................................................................ 54
Branching Views in Client Builder ............................................................................ 55
Reusing Graphics with Branching ............................................................................. 56
Branching Shortcuts .................................................................................................. 61
Tag Arrays Used with Branching .............................................................................. 62
Redundant Licensing .......................................................................................................... 64
Client Operation ........................................................................................................ 64
License Server Operation .......................................................................................... 65
Licensing Scenarios ................................................................................................... 66
Operating Guidelines ................................................................................................. 69
Data Logging ...................................................................................................................... 71
Database Browsing ............................................................................................................. 73
Database Browser Control ........................................................................................ 73
PowerSQL .................................................................................................................. 74
Database Browser Task ............................................................................................. 74
Browser Differences .................................................................................................. 75
Environment Variables ....................................................................................................... 80
Run-Time Manager ............................................................................................................ 81
Multiuser Architecture ....................................................................................................... 82
Shared and User Domains ......................................................................................... 82
iv / FactoryLink Fundamentals Guide

Domain Structure ....................................................................................................... 84
Domain Tables ........................................................................................................... 84
Domain Associations ................................................................................................. 84
Domains for Run-time Tasks ..................................................................................... 85
FactoryLink Kernel ............................................................................................................ 86
Kernel Multi-User Capabilities ................................................................................. 86
Application Instances and Identification ................................................................... 86
Chapter 6 Planning Your Application ....................................................................... 87

Planning Your Application Process .................................................................................... 87
Minimum Hardware and Software Requirements .............................................................. 88
System Design and Maintenance Guidelines ..................................................................... 89
Tag Naming Recommendations ......................................................................................... 90
Message Types .................................................................................................................... 90
Application Objects and Symbols ...................................................................................... 90
Standard Interface ............................................................................................................... 91
Chapter 7 Examples Application................................................................................ 93

Installation .......................................................................................................................... 93
Typical ....................................................................................................................... 93
Changing Computer Location ................................................................................... 94
Running the Examples Application .................................................................................... 94
Server Application .............................................................................................................. 95
Client Project ...................................................................................................................... 96
Mimics and Examples ........................................................................................................ 97
ActiveX Controls ........................................................................................................ 97
Standard Animation Features .................................................................................... 98
Features and Concepts .............................................................................................. 99
Application Objects .......................................................................................................... 100
Chapter 8 Application Setup Wizard........................................................................ 103

Application Setup Wizard Templates ............................................................................... 104
Application Objects in Server Templates ......................................................................... 105
General Objects ....................................................................................................... 105
VRN Setup Object .................................................................................................... 107
Driver Objects ......................................................................................................... 108
FactoryLink Fundamentals Guide / v

•
•
•
•
Chapter 9 Getting Help.............................................................................................. 109
FactoryLink Documentation ............................................................................................. 109
Customer Support Services .............................................................................................. 110
Appendix A FactoryLink Directory Organization....................................................... 111
Appendix B Real-Time Database and Tag Structure .................................................. 115

Real-Time Database Structure .......................................................................................... 115
Tag Structure ........................................................................................................... 117
Change-Status Bits ................................................................................................... 117
Real-Time Database Access – Reads and Writes ............................................................. 120
Normal (Conditional) Write .................................................................................... 120
Forced (Unconditional) Write ................................................................................. 121
Change (Conditional) Read ..................................................................................... 122
Normal (Unconditional) Read ................................................................................. 122
Tag Structure .................................................................................................................... 123
Basic Tag Structure ................................................................................................. 123
Change-Status Bits ................................................................................................... 123
Digital Tag Structure ............................................................................................... 124
Analog Tag Structure ............................................................................................... 125
Longana Tag Structure ............................................................................................ 125
Float Tag Structure .................................................................................................. 126
Message Tag Structure ............................................................................................ 126
Mailbox Tag Structure ............................................................................................. 127
vi / FactoryLink Fundamentals Guide

Chapter 1
•
•
•
•
Introducing FactoryLink
The FactoryLink software provides the process knowledge and control needed to perfect the
products companies make and the processes they manage. FactoryLink monitors, supervises,
and controls processes in a variety of industries around the world. FactoryLink is highly
scalable and can be used to build from the simplest Human-Machine Interface (HMI) systems
to the most complex and demanding Supervisory Control and Data Acquisition (SCADA)
systems.
FactoryLink allows data to be collected from a wide variety of plant floor devices and valuable
information to be distributed easily throughout the entire organization.
H OW F ACTORY L INK C AN H ELP YOU

FactoryLink can help you in the following ways:
• FactoryLink provides visibility into the entire process, giving the right information to the
right people when they need it.
• A graphical user interface lets operators monitor and control pumps, tanks, valves, motors,
switches, and other key process equipment.
• An alarm system alerts operators to problems and keeps a history for later analysis.
• Real-time and historical trend charts help operators and managers improve efficiency and
resolve problems.
• Reports and historical data help satisfy management and regulatory requirements.
• FactoryLink supports both local and remote monitoring to provide secure access to critical
information at the plant or even at a manager’s home.
• FactoryLink provides unparalleled connectivity by connecting remote terminal units
(RTUs), programmable logic controllers (PLCs), production and test equipment, business
systems, and other supporting systems using OLE for Process Control (OPC), Extensible
Markup Language (XML), proprietary, or custom protocols.
• A rich set of artwork, developed specifically for industrial automation systems and
equipment, is included to ease the configuration process.
FactoryLink Fundamentals Guide / 1

• 1 | INTRODUCING FACTORYLINK
How FactoryLink Works
•
•
•
H OW F ACTORY L INK W ORKS
Based on open industry standards, the FactoryLink 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.
FactoryLink 8.0 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++
• Microsoft Visual Basic for Applications
• Microsoft SQL Server 2005
Object-Oriented Development
FactoryLink 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
FactoryLink’s virtual real-time networking capability facilitates the creation of redundant
FactoryLink applications. It allows two identical FactoryLink applications to operate in a
master/slave configuration and supports master/slave arbitration, real-time data
synchronization, and alarm system redundancy. FactoryLink also supports several methods of
handling redundancy of historical data.
Graphics Development
Each FactoryLink client contains two types of graphics technology: multiplatform graphics
(FactoryLink ECS) and Windows technology (Client Builder graphics) for FactoryLink 7.x or
later. Both types can be used in the same application.
2 / FactoryLink Fundamentals Guide

INTRODUCING FACTORYLINK | 1
Two Types of Graphics Technology
Multiplatform graphics FactoryLink ECS (Pre 7.0)
Windows Technology Client Builder

Graphics (7.x and later)
Client Builder, FactoryLink’s 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.

• 1 | INTRODUCING FACTORYLINK
•
•
•

Chapter 2
•
•
•
•
Distributed Architecture
The fundamental architecture of FactoryLink is based on the latest Microsoft Windows

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

The three-tier model of distributed client/server processing includes a client services tier,
business services tier, and data services tier.
Tier Description In FactoryLink

Client Also known as the user Consists of the graphical user interface for operators
Services interface, this tier is and/or developers. If a client connects to multiple
positioned closest to servers, information is displayed as if it were coming
the user. from a single server.
Business Processes data and Consists of the FactoryLink server that supports the
Services provides information to collection, processing, and logging of data. The
the client services tier. FactoryLink server includes application configuration
data, run-time tasks, and a real-time database.
Data Stores and manages an Consists of a Microsoft SQL Server 2005 database
Services organization’s (Express Edition shipped with FactoryLink), which
historical data. provides advanced storage functionality and
management of historical data. FactoryLink supports
ODBC-compliant databases as well as provides native
interfaces to Oracle and Sybase.

• 2 | DISTRIBUTED ARCHITECTURE
Three-Tier Model
•
•
•
Due to its architecture, FactoryLink 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 FactoryLink 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

FactoryLink 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.
FactoryLink development/run-time systems are used to develop applications locally or
remotely. They can be used to run a FactoryLink application. Development, Run-time, or
Historical Database CALs are available. Additional CALs may be purchased for distributed
applications or 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 FactoryLink 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 FactoryLink systems (with ECS Graphics) and only supports development on the local
system. Development systems come bundled with one development CAL.
Run-time CALS can be used to access server applications locally, but do not have
configuration capability. FactoryLink 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. Only run-time CALs can be added to run-time systems.
Historical Database CALs allow a stand-alone reporting node on the network to connect to
SQL Server, Microsoft Access, or other database. A Client Builder node already has a built-in
Historical Database CAL. This node can run the Historical Reports, or it can use a custom
application designed by the integrator or end user to retrieve FactoryLink logged data from
SQL Server.
A client can reserve a CAL for a machine dedicated to viewing FactoryLink screens, such as
the control room computers. To ensure the development CAL is available for application
maintenance, the development CAL can be reserved for computers where the development
tools are located.

• 2 | DISTRIBUTED ARCHITECTURE
Scalable System Sizes
•
•
•
S CALABLE S YSTEM S IZES
FactoryLink is designed to run FactoryLink applications of various sizes, with limits defined
for the number of external inputs and outputs (I/O Tags) to the system and total number of tags
defined in the system (Total Tags). Versions with smaller tag counts offer all of the same
features as the unlimited version, as long as the same options are purchased. Check with your
FactoryLink for available sizes.
Developer-Defined Maximum Tags (Total Tags)

Except for the unlimited version, FactoryLink is designed to process a limited number of
developer-defined, real-time database tags per application. A licensing agreement determines
the total number of tags available. This total is in addition to the predefined tags provided with
a new, blank application.
All tags of tag arrays are counted towards this total. Each time you configure a tag during
configuration, FactoryLink adds it to the total count of tags defined for that application. At run
time, FactoryLink checks the application to determine the number of developer-defined tags. If
the application has more than the licensed number of tags defined, the application will not run.
With a conversion fee, the FactoryLink system can be converted to a larger size FactoryLink
system.
Input/Output Maximum Tag (I/O Tags)

FactoryLink contains tasks for connecting to external devices. An I/O tag is any tag that is the
source or target of any FactoryLink I/O task. An I/O task is any task that communicates
directly with an external device, such as a computer, a PLC, or nodes on a network. These I/O
tasks and their associated tags are a subset of the maximum number of tags you can configure
for an application. FactoryLink is designed to process up to the maximum number of I/O tags
in any of the I/O tasks provided or sold as options.

Chapter 3
•
•
•
•
Features, Tasks, and Tools
F ACTORY L INK TASKS

FactoryLink 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, FactoryLink 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
FactoryLink system at no additional charge. Some important tasks are described in this section.
Graphical User Interface
Client Builder
Client Builder is FactoryLink’s graphical user interface. Client Builder communicates with the
FactoryLink Server via the Client/Server gateway service and is also an OPC Client that
communicates with other OPC servers. For supervisory control, instructions can be sent from
Client Builder to the FactoryLink Server’s 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 FactoryLink 7.0, the graphical user
interface for FactoryLink was called ECS graphics. Screens in this format are compatible with
FactoryLink 7.2 and later and may be used inside of Client Builder graphics. Client Builder is
discussed in more detail later in this chapter.

• 3 | FEATURES, TASKS, AND TOOLS
FactoryLink Tasks
•
•
•
Application Editor
Application Editor, a pre-7.0 FactoryLink tool, is used to draw and animate graphical screens
for the FactoryLink 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
FactoryLink 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), FactoryLink provides an OPC interface
that can be used to collect information without requiring device-specific drivers. Additional
interfaces are available, if desired. Consult your authorized reseller or representative for the
most recent list of available interfaces.

FEATURES, TASKS, AND TOOLS | 3
FactoryLink Tasks
Dynamic Data Exchange

Dynamic Data Exchange (DDE) updates data automatically and regulates how and when data
is passed between programs such as Microsoft Word or Excel.
OPC Data eXchange (ODX)

ODX is an enhanced OPC Client used to communicate with PLCs and other OPC-compliant
devices. ODX eliminates the need to purchase a proprietary device interface in many systems.
Not only does this reduce the cost of the software, it ensures the use of a standard protocol,
making the system easier to maintain and upgrade. ODX is included as a standard part of each
FactoryLink system.
Enhanced Communication Interface (ECI)

An Enhanced Communications Interface (ECI) supports scaling, data conversion, and a variety
of statistical calculations. ECI is essentially an I/O translator that provides an interface
between various device interfaces and the FactoryLink real-time database. The ECI task
supports various types of FactoryLink device interfaces, including OPC, RAPD, and EDI. ECI
is included as a standard part of each FactoryLink system.
XML Adapter
The XML Adapter enables web-based applications to read and write FactoryLink real-time
data using an XML document. This option is a separate program that can be installed on the
FactoryLink server machine. The XMLAdapterInstall.exe program is located in the C:\Program
Files\ \FactoryLink\Installs directory.
This program installs a new COM component that can be used from applications that support
COM, including ASP pages on an IIS web server, VB/VBA applications, Active Scripting
hosts, and C/C++ applications. It also installs example web pages. To run the demonstration,
you must start the Examples Application, open an Internet Explorer window, and navigate to
the examples at http://localhost/XMLAdapter.

FactoryLink Tasks
•
•
•
General Tasks
Timed Events and Intervals
The Event and Interval Timer task defines timed events and time intervals that can be used to
initiate and control any system function. Timed events occur at a specific time not more than
once every 24 hours, whereas time intervals occur at least once every 24 hours at regular
intervals. Timed events and intervals link to real-time database tags that are used as triggers to
other FactoryLink processes.
Programmable Counters
The Programmable Counters task provides totalizers and event delays. Outputs from counters
can be used to provide inputs to other FactoryLink 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 FactoryLink 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 FactoryLink application at predetermined
times so if FactoryLink 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.
Scaling and Deadbanding
The Scaling and Deadbanding task converts or scales incoming raw data to a different value
range and indicates a dead or non-recalculating band around a scaled value. (New applications
use IOXlater or ECI.)

FactoryLink Tasks
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
FactoryLink 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 FactoryLink utilities.
Logging and Retrieving Data
Alarms and Events
System-wide event logging capability is supported to ensure the logging of three primary event
types:
• Events from within the FactoryLink system, such as a network problem or a software task
error
• Events from the PLC or other control system, such as a circuit breaker tripping, a pump
stopping, or a cycle finishing
• Operator interactions, such as when an operator logs in, starts a pump, or acknowledges an
alarm

FactoryLink Tasks
•
•
•
Distributed Alarm Logger
The Distributed Alarm Logger checks real-time data for permitted limits, generates alarms if
limits are exceeded, and copies the alarms to a historical disk-based relational database.
Alarms represent a subset of events and are configured based on any event within the system.
Alarms are specifically intended to alert operators to situations that may require their action.
Client Builder includes an Alarm Viewer that provides for viewing and acknowledging alarms
or events in the system. It has filtering and sorting capabilities to make the information more
useful to the operator. Events and states of various objects can also be viewed from the alarm
viewer.
Alarm E-mail Notification
An alarm or event defined in the alarm logger can be configured to use the e-mail notification
agent to acknowledge an alarm by using an e-mail reply from contact recipients in a
notification group. If a contact fails to be notified within a specified amount of time, the alarm
notification can be escalated to an alternate contact. Other contacts who are not required to
acknowledge the alarm can be designated to receive an alarm notification.
Operator Event Logging
Operator Event Logging allows FactoryLink 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.

FactoryLink Tasks
Historical Reports
The FactoryLink 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 31.
Historian
The Historian task communicates with external databases to create, write to, read from, and
update database tables. It processes data requests from other FactoryLink tasks and sends them
to the external database. The Historian acts like an interface between FactoryLink and the
database. The Historian is specific for a particular database product. The supported databases
are:
• SQL Server 2005
• 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)
Native Oracle Historian Interface
The Oracle Historian task provides a native interface to an Oracle 10 relational database. It
processes data requests from other FactoryLink tasks to write data to or retrieve data from the
relational database.
Native Sybase Historian
The Sybase Historian task provides a native interface to a Sybase System 12 relational
database. It processes data requests from other FactoryLink 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.

FactoryLink Tasks
•
•
•
Compressed Logging
The logger tasks include algorithms for limiting the data saved to the database. This feature
can be added to existing systems by defining points to be saved on change with a simple
absolute deadband value.
Process values are commonly “flat” during a large percentage of the day. The compressed
logging algorithm allows users to be specific in the amount of change the system will
recognize before it begins to log points to the database. Reducing the amount of logged data
improves database performance and ultimately trend responsiveness.
Real-Time and Historical Trend Controls
The Trend controls provided in Client Builder allow users to view the real-time or historical
evolution of any tags previously configured for logging. Tag values are displayed graphically
using either a line graph or a bar graph. Trending handles multiple points (up to 8 trends per
viewer) and supports panning and zooming. A wide variety of pen styles and colors can be
configured easily and property changes can be customized on-line.
Database Browser Control
The Database Browser control provided in Client Builder connects to a relational database,
such as SQL Server, and allows operators to view, sort, and filter data in a tabular fashion from
the database.
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 FactoryLink
message tag.
PowerSPC (optional)
The PowerSPC (Statistical Process Control) task contains many standard statistical
calculations and charts. It works in conjunction with the FactoryLink 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.

FactoryLink Tasks
UTC Logging
Universal Time Constant logging allows the server to log data in UTC (Coordinated Universal
Time). This capability prevents the overwriting of data due to daylight savings time transitions.
It is also critical for SCADA systems that cross time zones.
Many of the logging systems in the server can be configured to log in UTC time, including
database and data point logging, alarms, and operator audit trail.
Client Builder ActiveX controls have features that automatically translate the historical data
time stamps into the locally configured time zone, including daylight savings time changes.
The client makes the time conversion so that operators see data in their time zone. Even
trending displays the daylight savings time data with special handling of duplicate time data.
Communicating Across a Network
VRN and Redundancy
The Virtual Real-time Network and Redundancy (VRN) task provides networking and
redundancy functionality for FactoryLink.
VRN facilitates the creation of redundant FactoryLink applications. It does this by mirroring a
selectable portion of the FactoryLink real-time database. It allows two identical FactoryLink
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.
FLOCX
FLOCX is an ActiveX control designed to interface with the OLE Server task to allow a
connection to non-FactoryLink 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.

Multilingual Systems
•
•
•
M ULTILINGUAL S YSTEMS
FactoryLink was built with global companies in mind. FactoryLink 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.
FactoryLink 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. Developers
building multilingual applications can export all of the static and animated text elements in
selected mimics to a user-selected file format. These files can be sent to non-technical
translation contractors or vendors to enter the translation for the text strings from the mimics.
Upon return of the files, developers can import the files into the Client Builder mimics. This
feature allows the developer to create a new mimic for a project and send just the one mimic
for translation or send the entire project for translation.
For detailed information about how FactoryLink manages languages and roles and how you
can add additional languages and roles to a FactoryLink system, see the Client Builder Help.

Configuration Tools
C ONFIGURATION TOOLS
FactoryLink 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 FactoryLink 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 FactoryLink system
servers and OPC servers. Users can navigate to these servers to configure them. Beneath the
FactoryLink 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.

Configuration Tools
•
•
•
Grid Editor
When a table icon is double-clicked, the Grid Editor opens. The Grid Editor is used to edit
the configuration tables as well as provide a traditional grid view of the task (records listed
down the page in a table).

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

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

Configuration Tools
Application Objects
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
FactoryLink Server. Application objects automate the configuration of FactoryLink tables.
They replace the need to manually enter information into multiple configuration tables.
Application objects offer the following advantages:
Increased • Simultaneous development by users with different FactoryLink skill

development levels
productivity • Reusability of common variables and objects
• Structured configuration methodology
Easier • Organized view of records grouped by function
application • Ability to add, insert, and remove instances per changing
maintenance specifications
• Ability to recalculate all the instances of an application object from
revised data source files
Configuration Explorer provides the capability to define “models” or “classes” called

application objects. Each replication of an application object class is called an “instantiated”
object. If an application object class is modified, all instances derived from that class would be
modified automatically. Additionally, a class can be configured to obtain its parameters from a
variety of places including an Excel spreadsheet, text file, any ODBC data source, or manual
input.
Application object examples are part of the Examples Application or FLNEW template
applications in Configuration Explorer. Application objects use the example input source files
located in the {FLAPP}\AppObj directory to dynamically populate one or more FactoryLink task
configuration tables. As an application object is copied to an application, each application
object’s instance is written to the Instances database file (AOInstance.mdb). After successful
completion of each instance, the configuration table’s database record is written to that table’s
database (*.cdb) file.
Application objects permit preconfigured system configuration for specific types of
applications. While software developers concentrate on software objects, and domain experts
configure application-oriented classes (domain layer), an application team uses application
objects to quickly construct and tailor the system for a specific application.
An application object is constructed by aggregating built-in objects and other existing
application objects into a new class. The subobjects and their connections define the
functionality of the application object. Using application objects in development can greatly
reduce the total cost of ownership of the system, especially for large projects.

Configuration Tools
•
•
•
The graphic at the end of this section illustrates how data flows from the developer’s raw
information to the configuration tables. This process has the following sections:
Where the Data Comes • Raw configuration data can be a user input or a source file.
From • 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.
How the Classes are • Template variables define the input or source parameters.
Defined • Template variables can be used in configuration objects, file
objects, and application objects.
• Configuration objects define the template variables or
constants used in the configuration forms.
• File objects define the template variables or text used in the
text forms.
• Application objects define the collection of template
variables and objects used to represent a functional
equipment object.
How the Application • Application objects are instantiated using a copy-and-paste
Objects are Instantiated method from the Classes tables to the Instances tables
into Configuration Tables within the application objects database.
• Tables of application object instances within the database
are used to record and maintain the location of the
instantiated objects within the FactoryLink application.
• Each successful instantiation is then written as a record to
the FactoryLink application configuration tables and files.

Configuration Tools
{FLAPP}\Appobj default directory User Input or Source File

- source files (gen,txt,csv,xls,mdb) Source - Keyboard
- property page files (htm) (configuration raw data) - Generated
- Text File
- Excel spreadsheet
- ODBC Database
Application Object Classes Tables

- created in AOInstances.mdb Template Variables
(input source definitions)
Configuration Objects File Objects

(configuration table forms) (configuration text forms)
Application Objects
(collection of variables and objects)
Application Object Instances Tables

({FLAPP}\Appobj\AOInstances.mdb)
FactoryLink On instantiation, the objects

Application Directory Configuration Tables are written to the Instances
({FLAPP}\*.cdb files) tables and then to the
Configuration tables

Configuration Tools
•
•
•
Client Builder
Client Builder is the tool to create and configure the graphical user interface for FactoryLink
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.
FactoryLink ECS graphics screens (in FactoryLink 6.6 or earlier) can be used inside Client
Builder, so it is easy to upgrade from an older version of FactoryLink. Both of these graphical
interfaces are provided with FactoryLink development systems.
Customization is supported in Client Builder through Microsoft VBA scripting. All animations
and functions available at run time are accessible programmatically.
Client Builder supports online configuration by providing the capability to develop and test
graphics within the same environment.

Configuration Tools
Client Builder’s main characteristics include:

• Client Builder elements can be edited, combined, and stored in libraries for reuse in multiple
projects. This applies to graphical symbols, configured mimics, control panels, templates,
and scripts.
• Client Builder includes a comprehensive library of graphical images that can be used to
create symbols to represent anything from a simple button to a complex piece of equipment
that includes numerous animations.
• Drawings and symbols can be rotated, mirrored, aligned, grouped, ungrouped, locked,
unlocked, dragged and dropped, and animated. Access to undesired keystrokes can be
locked to prevent access to the underlying operating system.
• Symbols are class-based and object-oriented. Each time a symbol is modified, all
replications or instances are automatically updated graphically as well as in database links.
Symbols and libraries can be predefined or user-defined.
Communication Connections
Client Builder exchanges data with the server through its network socket or OPC connection.
Animation is possible during run time using links between graphical objects and real-time tags
on the FactoryLink 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.
The following graphic illustrates communication connections between the major components
of the Client Builder client project, the FactoryLink Server, and the Database Server.

Configuration Tools
•
•
•
Client Builder
VB Script
Animation
Variables
Alarms FL Tags Real-time Trend Historical Trend Browse OPC

ActiveX CSComm Mgr ActiveX ActiveX ActiveX fvComm Mgr
Failover and
Communication To 3rd-Party
Cluster Monitor OPC Cluster OPC Servers
OCX CS Client Mgr Mgr
Client Computer
FactoryLink Server
Computer CS Service
Alarm Server Tag Server OPC Server Trend Server FL Data Server
To 3rd-Party OPC Clients

Alarm Logger
FactoryLink Application
Real-Time Database OPC Client
(RTDB) or ODX/ECI
Historian
Data Logger
(ODBC or Native)
3rd-Party OPC
Database on Server on Local
Local or Remote Computer, Remote
Computer Computer, or PLC

Configuration Tools
Animation Real-Time Display
In the client project, the mimic’s animated objects connect to the real-time database using the
Communication Manager’s client connection to the FactoryLink Tag Server. With the server
application running, this communication allows the tag values to be read to and written from
the animated objects. The animation features use those tag values, as well as the graphics local
register variables, for real-time display and control of the FactoryLink Server. In addition to
the animation features and functions, the internal VBA script editor can be used to write
custom code using a graphic object’s exposed properties, methods, and events.
The client can also use its OPC Communication Manager to connect to third-party OPC
Servers and use OPC tags in the same way.
ActiveX Controls
Client Builder contains the following FactoryLink-supplied ActiveX controls:

• Alarm Viewer
• Real-Time Trend
• Historical and Real-time Trend
• Database Browser
• Cluster Monitor
Alarms The Alarm Viewer control is used to configure, display, sort, filter, and
acknowledge the active alarms from the FactoryLink 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 a Historian task to write the alarm data to a
SQL Server or dBase IV database selected during installation.
Trend The Historical and Real-time Trend control is used 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 resides on the FactoryLink Server and accepts connections
from multiple clients. The Trend Server makes a direct connection to the
databases using an ODBC or native data source configuration.
The Real-time Trend control plots charts directly from Client Builder
variables obtained from the Tag Server, OPC Server, or local variables.

Custom Development Tools
•
•
•
Database The Database Browser control is used to configure, display, and select data
Browser 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 communicates with the FLDataServer, which makes a
direct connection to a database using an ODBC data source configuration.
Cluster The Cluster Monitor control is used to monitor the status of the servers within
Monitor server clusters, determine which servers in a cluster are being used by the
client, and manually switch clients from one server to another.
For more information about ActiveX controls, see the Client Builder Help.
C USTOM D EVELOPMENT TOOLS

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

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.
FactoryLink 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 FactoryLink
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 FactoryLink historical data.
The Historical Reports reside in the Applications shared folder on the FactoryLink 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 FactoryLink system, click Start > Programs >
FactoryLink > Historical Reports.
• If running the historical reports on a system where a FactoryLink Client is not installed, use
Windows Explorer to browse to the Applications shared folder on the machine where
FactoryLink is installed. Open the Historical Reports folder and double-click Historical
Reports.adp.
Note: You need to have access to a Historical Database CAL if running the reports on
a system where a FactoryLink Client is not installed.
3 When the Security Warning appears, click Open. (This security warning appears each time you
run the Historical Reports.)
4 At the Logon screen, type the username and password for a SQL Server user that has read
access to your historical data and then click OK.
The Reports Data Linking dialog box appears and automatically starts to connect the project to
the FLINK database at the (local) SQL Server.

HISTORICAL REPORTS | 4
Generating Reports
5 When the connection status is successful, click Continue to connect to the default FLINK
database. The Historical Reports window appears (see Figure 4-1).
You can connect to a different database by clicking Advanced Data Source Configuration and
entering the desired database name and associated login information. Click OK and then click
Continue to connect to this database.
6 Click a report to open a dialog box similar to the one in Figure 4-2. Select the criteria you want
to use to query the electronic document for user activity for a specified time period. (You can
type the start/end dates, click the arrow and select a date from a calendar, or click a time period
quick button.)
Figure 4-2 Operator Audit Trail Report Query
The process data reports have an option on the query screen that allows you to add statistics to
the bottom of the report. If the Show Max/Min/Avg Values check box is selected, the column for
the specified time period displays the minimum, maximum, and average values reports as well
as the logged data.
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.

Generating Reports
•
•
•
Figure 4-3 Customizing Reports
Specify the column Select to have the item

width for the item appear on a separate line
Specify your
own SQL
WHERE clause
Either select to have the item Use arrows to set the order
appear in the report or clear to the items are to display
not display the item in the report
8 After setting the criteria for the report, either click Preview to view the report immediately or
click Print to send the report to a configured default printer.
Note: To select a printer different from the default printer or to specify a range of pages
in the report to print, click File > Print in preview mode.
Figure 4-4 shows a sample report for the activities done by the MyAdministrator user.

HISTORICAL REPORTS | 4
Generating Reports
Figure 4-4 Operator Action Sample Report

Generating Reports
•
•
•

Chapter 5
•
•
•
•
Internal Architecture
FactoryLink 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 FactoryLink 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
FactoryLink’s internal architecture is based on Siemens’s Open Software Bus architecture. The
Open Software Bus is a key factor in the success of the FactoryLink 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 FactoryLink tasks. Custom tasks developed with the PAK
can be plugged in just like Siemens-developed tasks.

INTERNAL ARCHITECTURE | 5
Real-Time Database
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 FactoryLink 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.
FactoryLink 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.
R EAL -T IME D ATABASE

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

a tag in database)

Real-Time Database
•
•
•
The database contains data that is:
• Collected from a remote device
• Computed by a FactoryLink task
• Manually entered by a user
When data is collected and updated in the database, other tasks can access and manipulate the
data. A task can write information to a tag in the real-time database using one of two types of
writes: a normal write or a forced write.
Normal writes only write to a tag in the real-time database if the new value is different from the
existing value. In this way, system resources are not used unnecessarily.
Forced writes write to a tag whether or not it has changed. You use this type of write to make a
tag appear to have changed value even if the data has not changed.
A task gets the value of a tag in the real-time database using a read operation. Once the task has
this value, it can perform functions on the value, such as displaying the value on a mimic,
transmitting the value to an external device, or sending the value to a relational database for
archiving.
Read or write operations can be triggered by an event (such as when a product passes an
electronic eye) or can occur only if the tag changes. A read or write operation that occurs only
when the data changes is referred to as exception processing. Because large blocks of data can
be transferred between tasks, and because only the changed values are processed, exception
processing significantly optimizes performance.
Exception processing is possible because of the structure of the FactoryLink real-time database
tags. A real-time database tag consists of two parts, the tag’s value and the tag’s change status.
When a tag in the database is written, its change status is automatically set by FactoryLink and
each FactoryLink task has a mechanism to determine the tag’s change status.
For more details about the structure of the real-time database and how FactoryLink does
exception processing, see “Real-Time Database and Tag Structure” on page 115. It is
especially important to understand these concepts if you plan to develop applications that
include Interpreted or Compiled Math and Logic programs.

FactoryLink Tags
F ACTORY L INK TAGS

Tags contained in the real-time database are assigned a logical tag name. FactoryLink tasks use
this tag name to reference the tag in the real-time database during configuration. Once a tag is
defined, you can make unlimited references to it. Any object in a Client Builder screen or any
task can reference the tag. Any FactoryLink task containing a reference to a tag can read and
write data to and from the tag at run time.
During development, FactoryLink 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
Syntax
Valid tag names conform to the following syntax:

<name>[<dims>][.<ext>]
<name> Name of tag. Maximum 32 characters, including dimensions, extensions, and

separators (: and .).
If using Scaling and Deadbanding, the character count is reduced to 25.
<dims> Array dimensions. Maximum16 characters. See “Tag Arrays” on page 49.
<ext> FactoryLink-created extension added when Scaling and Deadbanding is applied
to a tag. Maximum 6 characters. Additional characters reduce the maximum
length of the tag name by up to 7, because of the period delimiter.
Legal characters for the <name> and <ext> strings are as follows. The strings cannot begin
with a number or contain spaces.
{A-Z} {a-z} {0-9} {@$_}

FactoryLink Tags
•
•
•
As a best practice, you should name tags using a hierarchical data structure to support
branching, which significantly improves system performance. For detailed information about
branching, see page 51.
Hierarchial Data Area_Device_Function_SubFunction

Structure Examples Line_Equipment_Function_SubFunction
Building_Area_Machine_Function_SubFunction
Tag Name Examples Brew_Pump05_Speed_SP
Sta09_Vlv03_Status
Speed_SP[4][5]
General Recommendations
When naming your tags, follow these general recommendations:
3 Recommendation
Use a consistent naming system throughout the plant.
Have a hierarchical structure so that you can support branching (discussed on page 51).
Begin related tags with the same first-level branch name (the name before the first “_”
delimiter) if you want the tags grouped together for listing and linking purposes. This
makes testing and troubleshooting much easier.
Incorporate the type of process, unit, and location in the name, but not in addresses or
references that may change during the lifetime of an item.
Have a way to distinguish user-defined tags from internal system tags.
Distinguish between process-related and system-related objects. For example, a motor
including all of its I/O signals may be part of the process, whereas the I/O card that takes
the signals may be part of a PLC system.
Define virtual objects including all I/O signals and interface borders.
Plant-related hardware inputs/outputs (such as pushbuttons and feedback signals) should
use the same tag naming concept to indicate the devices (such as machine, switch, or
source within the plant) to which it belongs.
Do not start the name with a number.
Try to name each tag in a way that describes its purpose.

FactoryLink Tags
Defining Tags
Anytime you save a configuration that contains an undefined tag, the Tag Editor appears for
you to complete the tag definition.
The type of data that can be stored in the tag depends on where the tag is specified.
FactoryLink uses the following data types:
Data Type Description

Analog A 16-bit, signed integer between –32,768 and +32,767
Digital A one-bit binary number that can be a value of 0 (off) or 1 (on)
Float An IEEE double-precision number with 31 places to the right of the decimal,
with a value range from +/– 10 raised to the power of +/– 308
Longana A 32-bit, signed integer between –2,147,483,648 and +2,147,483,647
Message Any combination of alphanumeric characters (the length limit is set in the tag
definition Message Length field)
Mailbox A unique data type that specific tasks use to communicate with each other (The
only data type that can queue data rather than overwrite the previous value. The
content of this data type varies in length.)
The Tag Editor has an area that defines tag persistence. With tag persistence activated, the
value of the tag is periodically saved to a disk file. If a value exists in this file for a tag, it is
written to the tag when the task is restarted. This way, you do not lose important information
by exiting the task.

FactoryLink Tags
•
•
•
Tag Properties
Tag Properties are an extension of the tag data structure. They allow a user to define additional
information related to the tag. These read-only properties are exposed to Client Builder and to
your project using the Tag Server task.
Tags are defined on the FactoryLink Server. The Tag Server provides not only the tag value as
it changes to Client Builder, but also includes a structure of properties that allows the tag to be
treated as an object on the client. This object includes information like the tag value, tag
description, security level, and other properties unique to the data type of the tag.
Tag properties are exposed to users in many of the standard animations in Client Builder. Tag
properties, like minimum value and maximum value, automatically limit the input range for
register values. Other tag properties for digital tags provide the prompt message for labeled
animations so users can get a clear message for the action that is to execute, such as “Start
Recovery Pump?”
The tag property fields in the Tag Editor accept both literal values and other tags as a source of
the property information. To use a tag in a property field, prefix the tag name with the equal
sign. For information about acceptable tag data types for a specific property, see the Property
description in the Tag Server chapter of the Task Configuration and Reference Guide.
Tags defined in
property fields
Note: Changes to tag properties when the system is running may not display on the
clients until they are restarted. Variables that are cached are not updated.

FactoryLink Tags
The following information explains the correlation between the tag properties usage in
Configuration Explorer and Client Builder.
Configuration Explorer Client Builder

Applicable to Base Tag Editor Tag Properties Tag Suffix in VBA and
Tag Type Fields Table Text Display Animation
All Description N/A _DESC
All Security ALL_SECURITY _SCTY
All N/A ALL_INVALIDLBL _NVLD
Digital Label 0 BIT_LABEL_0 _LBL0
Digital Label 1 BIT_LABLEL_1 _LBL1
Digital Send 0 BIT_SETLBL_0 _SET0
Digital Send 1 BIT_SETLBL_1 _SET1
Analog, Longana, Float Minimum REG_MINVAL _VMIN
Analog, Longana, Float Maximum REG_MAXVAL _VMAX
Analog, Longana, Float Engineering Units REG_ENGUNITS _UNIT
Analog, Longana, Float Display Format REG_FORMAT _FMRT
Use of Tag Properties in Other Animations:
Animation Property Tag Property Animation Property Tag Property

Bargraph Bounds Minimum REG_MINVAL Scaling Range Min Value REG_MINVAL
Bounds Maximum REG_MAXVAL Range Max Value REG_MAXVAL
Legend Bounds Minimum REG_MINVAL Bit Send Command Level ALL_SECURITY
Bounds Maximum REG_MAXVAL Labels when BIT_LABEL_0 (If Sending
forcing To 0 Mode = Label)
Format REG_FORMAT Labels when BIT_LABEL_1 (If Sending
forcing To 1 Mode = Label)

FactoryLink Tags
•
•
•
Animation Property Tag Property Animation Property Tag Property
Label Description Tags description Double Bit Command Level ALL_SECURITY
Display Send Bit 1
Associated Label BIT_LABEL_0/1 Command Level ALL_SECURITY
Bit 2
Display Format REG_FORMAT Labels when Prompts:
Register forcing To 1 Bit 1 BIT_SETLBL_1, Sends:
BIT_LABEL_1
Single Axis Scaling Start Point REG_MINVAL Labels when Prompts:
Positioning Value forcing To 1 Bit 2 BIT_SETLBL_1, Sends:
BIT_LABEL_1
Scaling End Point REG_MAXVAL Register Format REG_FORMAT
Value Send
Command Level ALL_SECURITY Command Level ALL_SECURITY
Path Scaling Start Point REG_MINVAL Minimum Value REG_MINVAL
Positioning Value
Scaling End Point REG_MAXVAL Maximum Value REG_MAXVAL
Value
Command Level ALL_SECURITY Text Send Command Level ALL_SECURITY
2 Axes Scaling Start Point REG_MINVAL Mouse Command Level ALL_SECURITY
Positioning Value Imitate
Scaling End Point REG_MAXVAL Execute Command Right ALL_SECURITY
Value Procedure Level
Command Level ALL_SECURITY Run Command Right ALL_SECURITY
Register X Application Level
Command Level ALL_SECURITY
Register Y
Rotation Rotation Scale - REG_MINVAL
Minimum Value
Rotation Scale - REG_MAXVAL
Maximum Value
• Tag Property values are substituted when the animations property field choice is set to
AUTO.
• There are no specific uses of the REG_ENGUNITS or ALL_INVALIDLBL tag properties
in animations. However, when defined, the REG_ENGUNITS properties value is
automatically shown to the right of a Display or Send Registers value when the animations
Format field is also set to AUTO.

FactoryLink Tags
• ALL_INVALIDLBL is a text string displayed instead of the normal yellow triangle with a
question mark when the connection to the Tag Server tag is lost. For this property to work,
the base tag must have had a valid connection at one time in order to retrieve this property
value and store it locally. This property can only be defined in the Tag Properties table.
• The Tag Property fields in the single point Tag Editor accept both literal values and other
tags as a source of the property information. To use a tag in a property field, prefix the tags
name with the equal sign. See the Tag Properties table Property columns field help in
Configuration Explorer for acceptable tag data types for a specific property.
Important Notes:
• When a base tags description property is defined using the value from another tag, this
other tag must be used somewhere else in the application for its value to be visible in
Client Builder. A good place to add this tag if it is not used elsewhere in the application is
the Math and Logic Variables table.
• The Format choice in the Label Display animation refers to Client Builder substitution
strings, and not the REG_FORMAT tag property. See the “Using Substitutions in
Animations” topic in the Client Builder Help for information about the use of
substitution strings in this Format field.
Predefined System Tags

Some tags are already defined in FactoryLink when it is shipped. Many of them are
time-related system tags that provide system-wide time information to all FactoryLink tasks.
Such tags exist for date, time, number of minutes past the hour, and current month. These tags
are updated at FactoryLink startup and are continuously updated as the system runs.
In Configuration Explorer, you can view the tags in an application by right-clicking your
server application and selecting Browse Tags. The tags are grouped by domain and data types.
The Configuration Explorer Help provides a list of all predefined system tags available in the
FactoryLink applications.

Triggers
•
•
•
TRIGGERS
A trigger refers to a tag whose change in value causes another event to occur in the application.
Many FactoryLink 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 FactoryLink 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.

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 FactoryLink tasks, such as Math and Logic and
Database Browser, can perform operations on an entire tag array using only one reference to
the array, rather than using separate references to each tag in the array.
You specify an array by entering a value in the Array Dimensions field of the Tag Editor. This
value defines the number of tags to include in the array. Each array can have up to 65,534 tags.
If a value is specified, multiple tags are created in the real-time database. Once created, each
tag can be referenced individually. The specified value determines whether the array is
single-dimensional or multi-dimensional.
one-dimensional array – a list of tags indexed in sequence
multi-dimensional array – a matrix or table containing a fixed number of rows and
columns, with more than one index. Each tag in a two-dimensional array has a pair of
indices. The first index indicates the row and the second indicates the column of the array
where the tag is located. A three-dimensional array has three indices.
Defining One-Dimensional Arrays

In the Array Dimensions field, specify a single number in the following format:
tagname[n]
where
tagname is the name defined in the Tag field of the Tag Editor.
[n] is a unique number assigned to each tag in the array starting with 0. Each
number is surrounded with brackets [ ].
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

Tag Arrays
•
•
•
Defining Multi-Dimensional Arrays
In the Array Dimensions field, specify multiple numbers separated by a comma in the
following format:
tagname[n1][n2]...
where
tagname is the name defined in the Tag field of the Tag Editor.
[n1] is a number representing the first dimension in the array, assigned to each
tag starting with 0. Each number is surrounded by brackets [ ].
[n2] is a number representing the second dimension in the array assigned to each
tag starting with 0. Each number is surrounded by brackets [ ].
For example, if you specify 7,3 in the Array Dimensions field when you create a tag in the Tag
Dictionary named Super_93, 21 tags are created in the real-time database. (If you enter
Super_93[6][2] in a Tag Name field in a configuration table, the same 21 tags are created.)
The array numbering starts counting at 0.
Multi-Dimensional Array
Region 1 Region 2 Region 3
Super_93[0][0]
Jan 1.45 1.80 1.23
Super_93[3][1] Feb 1.56 1.77 1.25
Mar 1.63 1.74 1.27
Super_93[4][2] Apr 1.67 1.69 1.33
Super_93[6][0] May 1.79 1.64 1.38 Super_93[6][2]
June 1.82 1.70 1.31
July 1.73 1.76 1.28

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 FactoryLink database. Instead, only the tags
that belong to the branch are accessed and displayed. This feature significantly improves
system performance and lowers development time, because it is much easier to find tags that
are organized in this fashion.
A simple example of a hierarchical data structure is shown in the following graphic.
The branches in this example are Area1, Pump1, Pump2, and Pump3. The actual tags in this
system are the Upstream Pressure, Downstream Pressure, and Speed. To represent this
hierarchy in a database, the following naming convention is used, with each of the following
names representing a single tag:
Area1_Pump1_UpstreamPressure
Area1_Pump1_DownstreamPressure
Area1_Pump1_Speed
Area1_Pump2_Speed
Area1_Pump3_Speed

Branching
•
•
•
To configure the first symbol in the example, you create the graphical representation of the
object and then animate the graphical representation by referencing tags contained in a single
branch. The symbol may not reference tags from multiple branches.
For subsequent instances of this symbol, you are only required to specify the name of the
branch to identify which set of tags is 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 FactoryLink tag name (32 alphanumeric characters).
The mimic shown in Figure 5-1 can be built quickly using branching functionality.

Branching
Figure 5-1 Branched Mimic
With scripting, you can change the name of the branch at run time. For example, the pump
symbol and buttons can be combined and can be used to show the data for various pumps on
one mimic. The difference is that the operator must press the Previous and Next buttons to
view the data from the other sets (branches) of pump tags. The name of the branch can be
specified on a mimic open action so the same mimic can be opened from different buttons and
the data displayed would be from the branch specified in the mimic open action.
Combining the above functionality with application objects provides a powerful configuration
environment. Application objects provide the ability to define a set of tags as a class (class and
branch are synonymous) and instantiate this set of tags many times.
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.

Branching
•
•
•
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 tag name examples that are ready for branching:
PmpStation1_Pump_Speed PmpStation1_Pump_Speed_SP PmpStation1_Pump_Fault

Swiss5_Cutter3_Pressure Swiss5_Cutter3_CyclePerSec Swiss5_Cutter3_ErrorNo
Pressure[5][3] CyclePerSec[5][3] ErrorNo[5][3]
One of the most powerful functions of this feature is for applications that use application
objects to generate their tags. The application objects can be configured to generate tag names
that reflect the object hierarchy, which can then be seen easily from the Variable Browser.
You can group all the symbols on a mimic into a complex symbol that also supports this
functionality.

Branching
Branching Views in Client Builder

Client Builder understands branching. You can see this in the way that it displays tags in the
Variable Browser. Figure 5-2 shows a branched, hierarchical view. The left pane shows
branches, while the right pane shows any “leaves” on the selected branch. When you click a
specific leaf, the full item string displays in the Selection field. Note, the underscores in the tag
name designate branches in the tree.
Figure 5-2 Branched View One Level
In this view, notice that the tag selected is PmpStation1_Pump_Speed, as shown in the
Selection field. As you open each branch, you see the next level. In Figure 5-3, the branch is
expanded so that you can also see PmpStation1_Pump_Speed_SP.
Figure 5-3 Branched View Next Level
Branching makes finding tag names much faster because they are organized your way. You are
presented with a structured view rather than a large flat list of all tags in the system.

Branching
•
•
•
Reusing Graphics with Branching
Another reason for branching tag names is the capability to reuse graphics at the symbol and/or
mimic level. At the symbol level, the idea is to build a pump object (most symbols are
branched at the device level) that contains three or more parts, for example:
_Speed _Speed_SP _Fault

When designing 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 tag name will be:
PmpStation1_Pump_Speed for the animation. Here, 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.
When combining branching with Tag Properties, animations can be made that inherit
information from the tag definition and act according to the properties of the tag. The same
animated objects can be used for many different situations.
Figure 5-4 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.

Branching
Figure 5-4 Object with Multiple Animations

Branching
•
•
•
After animation, combine the objects, create a symbol, and give it a name. When you paste this
symbol, the dialog box (Figure 5-5) appears with the previous animations displayed.
Figure 5-5 Using a Branched Symbol
To attach the symbol to the branch, just select a branch in the Local list. The Branch Browser
(Figure 5-6) appears. 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.
Figure 5-6 Branch Browser

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 the application. For example, if later you find out that yellow for fault is a bad
choice and you change it to red, everywhere this symbol is used gets corrected automatically.
The Examples Application contains an example of branching on a mimic. The Link/Run mimic
contains three branch buttons that open the same mimic with different tags using the Link
Open animation. Figure 5-7 shows the branch name specified in the branch field.
Figure 5-7 Branching in Examples Application
In this case, all of the animations on the pop-up mimic have the Branch1 branch specified. For
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, as shown in Figure 5-8.

Branching
•
•
•
Figure 5-8 Branched and Non-Branched Animation
Remember that each branched mimic is a unique copy, so when you close the mimic, you must
specify the branch. If you want the system to use the current branch, you can use the *
character to use the current branch for this operation. You can also use the * to specify
branches when passing the mimic branch to a symbol in a branched mimic.
Figure 5-9 Using Shortcuts in Branching

Branching
Branching Shortcuts
This table contains useful shortcuts for branching.
Shortcut Description Where Used

* Name of the current window or Link Open/Close, Send Program
branch (depending on the context)
#W Name of the current window Link Open/Close, Send Program
#WB Current window branch Symbols
#B, #B1 to #B6 Elements of the current window Symbols, Label format
#S, #S1 to #S6 Elements of the object branch Symbols, Label format
#P Name of previous window Link Open/Close
#M1 to #M10 Window names in window chaining Defined in the Window Properties
choices Links tab. Used in Link Open/Close.
#2 Tag Name only Send Animation Comment field
(Bit, Register, Text)
#D Tag Description Send Animation Comment field
(Bit, Register, Text)
This example uses #2 and #D as a tooltip in a send bit animation. This Start/Stoptext object has
a button style aspect and a Bit Send animation for the digital tag PUMP_NZ804. In the
Comment field, the @ symbol is used so that the text and substitutions that follows will show
on the object at run time as a tooltip.

Branching
•
•
•
Tag Arrays Used with Branching
Array branching is different from branching with just tags. You need to specify an Array
Branch option in the Tag Server Options table so that Client Builder is presented with the tag
arrays in the proper order.
The Array Branch field controls how the Tag Server handles tag arrays for use with branching.
In this field, you can specify a comma-separated list of one or more of the following options:
Std: Allows browsing of tag arrays in standard FactoryLink format.
Positive number: Presents tag arrays with array indexes after the Nth underscore counting
from the front of the tag name.
Negative number: Presents tag arrays with array indexes after the Nth underscore counting
from the end of the tag name.
Zero: Presents array notations in front of the tag names with underscores in
between.
You can present the Tag Server task with two options to get both formats by using a comma
between the options. Most applications would benefit from the Std,0 option in the Array
Branch field.
Traditional FactoryLink Tag Name: Area1_Pump2_Flow[4][3][2]
<Option> Tag Browsing Alias
Std Area1_Pump2_Flow[4][3][2]
0 [4]_[3]_[2]_Area1_Pump2_Flow
1 Area1_[4]_[3]_[2]_Pump2_Flow
2 Area1_Pump2_[4]_[3]_[2]_Flow
3 Area1_Pump2_Flow_[4]_[3]_[2]
4 or more Area1_Pump2_Flow_[4]_[3]_[2]
-1 Area1_Pump2_[4]_[3]_[2]_Flow
-2 Area1_[4]_[3]_[2]_Pump2_Flow
-3 [4]_[3]_[2]_Area1_Pump2_Flow
-4 or more [4]_[3]_[2]_Area1_Pump2_Flow
FactoryLink auto-generates a second tag name for each tag array 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 tag
name conflicting with another tag.

Branching
The examples in the following table show how various array tag naming conventions are
presented in Client Builder’s Variable Browser. In non-branched tag names like PumpSpeed[x]
and ValveState[x], properties are grouped in the same leaf.
Array Branch Current Name Second Name View in Variable Browser

Field
Std,1 Pump_Speed[x] Pump_[x]_Speed Speed
Pump_Pressure[x] Pump_[x]_Pressure Pressure
Valve_FlowRate[x] Valve_[x]_FlowRate
Valve_State[x] Valve_[x]_State
Std,0 PumpSpeed[x] [x]_PumpSpeed
(recommended) PumpPressure[x] [x]_PumpPressure
ValveFlowRate[x] [x]_ValveFlowRate
ValveState[x] [x]_ValveState
Std,1 Pump_Speed[x][y] Pump_[x]_[y]_Speed
Pump_Pressure[x][y] Pump_[x]_[y]_Pressure
Valve_FlowRate[x] Valve_[x]_FlowRate
Valve_State[x] Valve_[x]_State

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 FactoryLink version. Likewise, clients using the license
server must have the same FactoryLink 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 FactoryLink is
installed. Thereafter, a user can start the utility any time from the Start menu.
Client Operation
For a FactoryLink client to run, it must either obtain a license from a FactoryLink 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 FactoryLink clients on a common PC to automatically obtain a license
from a list of FactoryLink 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.
Once a license is obtained, it is stored in the client’s 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.

Redundant Licensing
License Server Operation

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

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

Redundant Licensing
Multiple Application Servers without Redundant Licensing
This scenario explains multiple application servers operating in non-redundant mode. Two or
more FactoryLink application servers are on the network. The applications are stand-alone and
not redundant (not using VRN). The license servers are also not redundant. Each server system
was purchased individually and CALs were purchased as needed.
The users began to create larger applications, where multiple users (remote clients) may need
to access the data. Additional CALs may be purchased per server as the need arises to allow
the clients access.
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 Alternate
License License Server
Server if Server1 fails
FactoryLink
FactoryLinkServer1
Server1
FactoryLink
FactoryLinkServer2
Server2

Redundant Licensing
•
•
•
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.
If one of the FactoryLink license servers fails, its redundant partner will still support a
maximum total of 10 client connections.
FactoryLink Server1
FactoryLink Server1
CAL synchronization
FactoryLink Server2
FactoryLink Server2
Complex Servers
This scenario is a combination of the Multiple Application Servers without Redundant

Licensing scenario and the Redundant System scenario. A plant has redundant pairs and
stand-alone servers. Some clients are configured to connect to just a redundant pair. Other
clients simply use a straight list of servers. The client automatically selects alternate servers
from a list if a license cannot be obtained from a previous server in the same list.

Redundant Licensing
Operating Guidelines
License Server The maximum number of client licenses that can be granted is no more
Running in than the amount purchased for that specific server. For example, if a
Redundant Mode system was purchased with 3 CALs, no more than 3 distinct clients (each
from a separate PC or third-party clients) can be running. Multiple clients
from the same PC are counted as 1 consumed CAL.
Redundant A redundant license server may define a partner, but the partner cannot
License Server refer to it in return. In this case, one license server will attempt to send
Configured for the synchronization messages to its supposed partner, but the supposed
Wrong Partner partner will ignore the synchronization messages.
Redundant If a redundant license server loses the connection to its partner, the server
License Server will continue to grant up to the combined CALs that the two servers
Loses its Partner established during the last synchronization.
For example, if the combined CALs equal 3, the surviving partner will
grant no more than 3 CALs for the duration of its operational lifetime.
This includes the fact that the surviving partner may restart repeatedly.
After 10 days of server operation any attached clients will get an
informational pop-up message indicating the situation. The user only
needs to acknowledge the message. The user's client application is not
hindered in any way. The pop-up message will appear when a client first
connects, and while connected, at 12 noon every day thereafter.
Redundant If a redundant license server starts and its partner is not operational, the
License Server license server will use the combined CALs that are stored in the local
Starts With No registry.
Partner After 10 days of server operation any attached clients will get an
informational pop-up message indicating the situation. The user only
needs to acknowledge the message. The user's client application is not
hindered in any way. The pop-up message will appear when a client first
connects, and while connected, at 12 noon every day thereafter.

Redundant Licensing
•
•
•
Redundant A situation may arise where both license servers, although still configured
License Server as redundant, maintain licenses to clients but cannot communicate
Pair Loses Then between themselves. In this case, each license server is authorized to grant
Regains the total number of CALs.
Communications When the redundant pair finally communicates, each server possibly can
be granted the maximum number of CALs possible. The total number of
CALs granted could essentially be doubled. For example, S1 and S2
represent two redundant servers. S1 is authorized with 3 run-time CALs
and S2 is authorized with 2 run-time CALs. Collectively, S1 and S2 may
not grant more than 5 CALs in total between the two while they are
connected to one another. When the two license servers lose contact with
one another, each server may possibly grant up to 5 CALs. This situation
results in a combined total of 10 CALs, which exceeds the maximum
number of authorized CALs (5). The plan of action in this case is to do
nothing and let both servers run independent of one another with each
granting a maximum of up to 5 CALs each.
When the two license servers regain communications, they will
synchronize their licenses and discover that the combined total of granted
CALs equals 10 (5 each from S1 and S2). Nothing will happen to the
connected clients.
Once a connected client releases its license (terminates), no new clients
may come in to consume the license that was just returned, nor can any
new client licenses be granted as long as the CALs consumed is greater
than 5.
If clients are still connected after 10 days and the total CALs consumed
between the two servers is still more than 5, each connected client will get
a pop-up message at 12 o'clock noon each day when a heartbeat message
is sent to the server. The pop-up message indicates the server
administering the license has exceeded its authorized CALs. The user can
simply dismiss the message and not be adversely affected by the
condition.
The 10-day count down starts when the servers first determine that the
combined CALs that are consumed exceed 5. When the combined CALs
consumed equals 5 or less, the pop-up messages will cease.

Data Logging
D ATA L OGGING
As data is collected or computed by FactoryLink, 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 Relational databases are configured in a table format consisting of rows and
columns. The structure of a table (the number, size, and content of the rows and
columns) is defined by its schema. When configuring a database you must
specify which tags are to collect values and where to place the values: which
database, table, row, and column.
Historian Serves as an interface between the FactoryLink real-time database and the
external relational database to which information is sent or retrieved.
Logger FactoryLink has two logging tasks that can read data from the real-time
database and send it to the relational database using a historian.
Data Point • Simplifies the task of logging data by providing
Logging preconfigured tables. Multiple shared numeric-value
tags can be stored in the same database and sorted later
if necessary.
• Allows the addition or removal of tags from the list of
tags being logged during run time.
• Builds a database that will capture date/time, tag name,
and tag value for the specified tag.
• Best suited for situations in which the tags that are to be
logged do not need to be grouped together.
Database • Allows you to create a table and specify which tags to
Logging capture in that table. When the value of any tag
changes, the values of all tags in the table are logged.
• Provides the ability to group tags in a database table.
• Event-based data can be logged using a sequence key
rather than a time key.

Data Logging
•
•
•
Prior to configuring the logging function, use these guidelines to determine which logging task
to use for a particular situation.
Use Data Point Logging Use Database Logging

when you want to when you want to
• Log a tag only when its value changes • Log all tags when any tag changes or is
• Use preconfigured tables and eliminate triggered
the time spent setting up tables • Simultaneously log a group of like
• Be able to index on log time or tag name (logically associated) tags
or both • Group data logged based on some
• Sort all logs of a tag in order of criteria
occurrence • Configure a table column to be a
• Configure a tag to be a dynamic pen on dynamic pen on a trend chart
a trend chart
• Dynamically change the list of tags
being logged during run time
For example, if you had a tank in which you were monitoring the process temperature and had
a single probe in the tank, you would probably use Data Point Logging to track the tag value. If
you had six probes in the same tank, and you wanted to see the value returned form each probe
at a given point in time, you would probably use the Database Logging task.

Database Browsing
D ATABASE B ROWSING
FactoryLink provides several ways to browse relational databases at run time:
• Database Browser Control in Client Builder
• PowerSQL task running on the FactoryLink server
• Database Browser Task running on the FactoryLink 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 FactoryLink and/or other programs
• Refresh the browser to show updated values
• Modify and save data values from database records (if allowed)
• Search the database using modified SQL commands (requires additional customizing)
For detailed information and procedures to use the Database Browser Control, see the Client
Builder Help.

Database Browsing
•
•
•
PowerSQL
The FactoryLink 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
FactoryLink 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 FactoryLink
• 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 FactoryLink
• Supports the execution of database-stored procedures for database servers with this
functionality
• Allows you to define tags referenced by PowerSQL in arrays as well as individually
For detailed information and procedures to use PowerSQL, see the Task Configuration
Reference Guide.
Database Browser Task

The Database Browser task works in conjunction with the historian tasks to allow a server
application to access data in a relational database through a browse window. This method of
browsing is more flexible and powerful than using the Database Browser control, but requires
more configuration effort.
Note: If you need more flexibility than the Database Browser control offers and you
are starting a new application, it is better to use PowerSQL than the Database Browser
task. PowerSQL has all the functionality of the Database Browser task and offers even
more power and flexibility with the same configuration effort.
Database Browser offers the following features:
• Allows relational data in a relational database to be manipulated from within FactoryLink
• Allows an application to send and retrieve data to and from all external database tables,
including those created outside of FactoryLink
• Allows you to define tags referenced by Browser in arrays as well as individually
For detailed information and procedures to configure and use the Database Browser task, see
the Task Configuration Reference Guide.

Database Browsing
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 FactoryLink tags for additional processing.
Method At Design Time At Run Time

Database Add a Database Browser control to a You cannot do a precise selection of a
Browser mimic and define the properties for the row by Absolute or Relative Move;
Control
control. however, you can scroll up or down in
The typical time required is a few the table. The data from the relational
minutes. database is not passed through
FactoryLink tags.
Database Use Configuration Explorer to create You can do a precise selection of a row
Browser Database Browser control and by Absolute or Relative Move. The
Task
Database Browser information tables. data from the relational database is
Associate tags to specific columns in passed through FactoryLink tags.
the database. Configure Move and
Position Triggers to scroll a specific
row using a relative or absolute move.
Create a mimic to display the tags and
link the animated objects to the
associated tags.
The typical time required is several
hours.
PowerSQL Same as Database Browser task Same as Database Browser task

Database Browsing
•
•
•
Case 2: Selection Criteria Are Entered
The user enters some parameters. A Select is processed and data is returned to the user in a
format suitable for further processing by FactoryLink tasks. The example in Figure 5-1 and the
corresponding sample code helps to explain this process. This example shows selecting an
alarm by Alarm ID or getting a row in the Alarm Log. The Select and the Get Row buttons
have codes associated with them.

Database Add a Database Browser control to a You can do select data based on the
Browser mimic and define the properties for the entered criteria. The data from the
Control
control. Create and label data entry relational database is not passed
fields using the Date and UnitName through FactoryLink tags.
boxes to enter parameters. Create an
OK button. Associate the button to a
script to tell the Browser Control
where to get the data.
The typical time required is a few
minutes.
Database Use Configuration Explorer to create You can select data based on the
Browser Database Browser control and entered criteria. The data from the
Task
Database Browser information tables. relational database is passed through
Associate tags to specific columns in FactoryLink tags.
the database. Create a mimic to display
the tags and associate the data entry
fields to columns being used for
Select. Associate a Select Trigger to an
animation object.
hours.

Database Browsing
Figure 5-10 Example Mimic for Case 2
Sample VBA Script in Client Builder for Case 2:
Private Sub AIDQuery_Click()

Dim SQLQuery As String
SQLQuery = "SELECT * FROM ALARMS WHERE aid = "
DbBrowserCtl1.RecordSource = SQLQuery + CStr([aid%])
DbBrowserCtl1.Refresh
End Sub
Private Sub GetRow_Click()
AlarmName.Text = Trim(DbBrowserCtl1.GetCellText(DbBrowserCtl1.
ActiveRow, 2))
Message.Text = Trim(DbBrowserCtl1.GetCellText(DbBrowserCtl1.
ActiveRow, 10))
itime.Text = Trim(DbBrowserCtl1.GetCellText(DbBrowserCtl1.
ActiveRow, 6))
End Sub

Database Browsing
•
•
•
Case 3: Selection Criteria By Group
The user enters the name of the field upon which to base the select query. The example in
Figure 5-11 browses the alarm history and shows information from a specific group of alarms.

Database Add a Database Browser control to a You can do a precise selection of data
Browser mimic and define the properties for the based on the entered criteria. The data
Control
control. Create and label data entry from the relational database is passed
fields using the Date and UnitName through FactoryLink tags.
boxes to enter parameters. Create an OK
button. Associate the button to a script
to tell the Browser Control where to get
the data. Associate the text fields to PLC
write tags. Move the selected row into a
set of editable text fields.
Typical time required is a few minutes.
Database Use Configuration Explorer to create You can select a row by the selection
Browser Database Browser control and Database criteria and move the data from the
Task
Browser information tables. Associate relational database into a set of text
tags to specific columns in the database. fields, into the FactoryLink real-time
Define another set of data input tags to database, and then write the tags to a
get the selected row. Create a mimic to PLC.
display the tags and associate the data
entry fields to columns being used for
Select. Associate a Select Trigger to an
animation object. Implement some logic
to move the tags to a set of PLC write
tags, and force a write to the PLC.
(Where possible, you can use the same
Database Browser tags as PLC write
tags.)
hours.

Database Browsing
Figure 5-11 Example Screen for Case 3
Sample VBA Script in Client Builder for Case 3:
Private Sub SelectAll_Click()

DbBrowserCtl1.RecordSource = SelectAll.Text
End Sub
Private Sub GrpNameQuery_Click()
Dim SQLQuery As String
SQLQuery = "SELECT aid, name, grp, msg, itime FROM ALARMS WHERE
grp = " DbBrowserCtl1.RecordSource = SQLQuery + "'" +
[groupname%] + "'"
End Sub

Environment Variables
•
•
•
E NVIRONMENT VARIABLES
FactoryLink uniquely identifies an application by a combination of its application name,
domain name, and user name. These names are defined as environment variables, so they are
supplied when you start the application.
If you use the Application Setup Wizard with one of the FLNEW templates, these environment
variables are set automatically for you. When using environment variables in path names, you
can enter the name of the environment variable surrounded by braces { } and FactoryLink
extends the pathname using the default setting.
You may set environment variables in the Windows Control Panel. Open System Properties,
click the Advanced tab, and then the Environment Variables button. You can set the following
environment variables.
Variable Description
FLINK = flink_dir Where flink_dir defines the full path of the directory containing
the FactoryLink program files.
FLAPP = flapp_dir Where flapp_dir defines the full path, including the drive
name, of the directory containing your application files.
FLDOMAIN = domain Where domain defines the domain you are starting. This can
either be Shared or User.
On single-user platforms, domain is User, which starts both
domains. On multiuser platforms, domain is the domain you
want started in the window. You must specify two windows,
one for each domain.
FLNAME = app_name Where app_name defines the name of the application to start,
which points to the real-time database.
FLUSER = user_name Where user_name defines the logical user name.
FLOPT = opt_dir Where opt_dir defines the full path, including the drive name,
of the directory containing the FactoryLink’s license
information.
SELECT_TIME=xx Where xx is the number of seconds. Used with WebClient and
FLLAN to set the time-out duration for the transmission of a
data packet.
RedundServer=name If using VRN, name specifies the redundant node name
(remote node).

Run-Time Manager
R UN -T IME M ANAGER
The Run-Time Manager orchestrates the run-time environment. It is a FactoryLink task that
runs concurrently with other tasks to start, monitor, control, and shut down the concurrent
execution of all FactoryLink 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
FactoryLink application program interface (API) and the real-time database.
Run-Time Manager Data Flow Diagram
Run-Time
SYS.CT Manager
Read Write
FactoryLink
Real-time
Databases
Read Write
FactoryLink
*.CT Application
Tasks

Multiuser Architecture
•
•
•
M ULTIUSER A RCHITECTURE
FactoryLink supports the concept of shared and private data areas by the separation of data
access into domains. There are two run-time environments in FactoryLink 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 FactoryLink application to suit your needs. FactoryLink’s multiuser architecture
has the following benefits:
• You can give a group of users independent access to the same FactoryLink 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 user’s 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 FactoryLink 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 FactoryLink runs, the entire real-time database is created, including the Shared portion
and all real-time database User instances. Next, the Shared Run-Time Manager initializes the
Shared Run-Time Database and starts the Shared processes. As User instances start, each User
Run-Time Manager initializes its instance of the User real-time database and starts an instance
of all User processes.
FactoryLink tasks use real-time database tags to control tasks. User database tags are
duplicated for each FactoryLink 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 FactoryLink tasks monitor and control processes, such as a PLC driver task, that require
the process data values be the same for all users. The subset of the real-time database shared by
all users is known as the Shared domain.
Domain Characteristics
A Shared domain has the following characteristics:

• Accessibility – All operators within a User domain can access data existing in a Shared
domain.
• Frequent use – Frequently used items need only be defined once in the shared area. This
characteristic eliminates duplication of effort and reduces configuration time.
• Automatic data changes – Data changes are passed immediately to all users who are
accessing the modified data in a User domain.
• Global data processing – Processing activities, such as computations, data accessing, and
data logging are performed once and then are available to all users accessing the shared
area.
A User domain has the following characteristics:
• Private copies of data – You can configure a single application and then specify the number
of instances (copies) of that domain to be executed at run time. The number of instances
allowed is the number of users that can simultaneously interact with the run-time system.
• Task Independence – Each user has access to the same FactoryLink run-time tasks such as
Graphics, Math and Logic, and Statistical Process Control, but is able to run these tasks
independently from the tasks other users are running. Users can share data to perform
different real-time tasks within the same application.
In the following example, you have created an application that allows multiple operators to run
separate user instances of the same application in which each operator has his own User
domain tasks and real-time database.

•
•
•
Domain Structure
Domains exist in a parent/child hierarchy. The following illustration shows that the Shared
domain is like a parent upon which a child domain (User) is based.
Domain Tables
The domain table in Configuration Explorer contains the definition of the Shared and User
domains in the application. The definition of these domains includes the number of allowed
instances as well as domain-wide persistence attributes.
Configuration Explorer has a domain selection feature that must be set before tasks are
configured. The default is Shared. If the run-time domain associations do not match the
configuration domain associations, the application will not run as intended.
Domain Associations
In the Examples Application, default domain associations are made in the System
Configuration Table. These defaults determine which domain (Shared, User, or both) a task is
associated with at run time. 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. This table lists the defaults that provide the best
performance for most applications.
Domain Type Run-Time Tasks
Shared • Timer
• Report Generator
• Batch Recipe
• File Manager Server
• External Device Interface (EDI)
• LAN
• Historian
• Logger
• SPC Logger
User • Graphics
• File Manager
• Trending
• Browser
• SPC View
• SPR
Both domains • Run Manager
• Math and Logic
• Counter
• Persistence
• RTMON
• DALOG
During application planning, review these domain defaults to verify compatibility with a
specific application’s needs. When an application has special requirements, you can run the
task in a different domain, except for the EDI task which must be run in the Shared domain.
If the domain chosen during configuration does not match the default set for the domain at run
time, the application will not run as intended. You must configure trending in the User domain
if it is going to run in the User domain.

FactoryLink Kernel
•
•
•
F ACTORY L INK K ERNEL
The FactoryLink Kernel is a program that creates the real-time database in memory so tasks
can communicate with each other. When you start the FactoryLink 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 FactoryLink Kernel allows multiple independent users of a FactoryLink 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 FactoryLink 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 FactoryLink task may be running concurrently, a task
must identify itself to the Kernel by specifying the application, domain, and user instance as
well as the task name.
Each application instance is specified by its invocation name, which is a character string of up
to 16 characters. The invocation identifies an instance of the real-time database and is used to
locate the memory segment the kernel is stored in. The Run-Time Manager refers to the
invocation name stored in the environment variable {FLNAME} and stores it in the tags
FLNAME_U or FLNAME_S, depending upon the domain.
The domain is specified by a character string of up to 16 characters and is used to determine
which portion of the real-time database the task has access to: either the tags in the Shared
domain or tags in one of the duplicate User domains. The Run-Time Manager refers to the
domain in the environment variable {FLDOMAIN} and stores it in the tag FLDOMAIN_U or
FLDOMAIN_S.
The user instance is a character string of up to 16 characters and is used to determine which
instance of the duplicate User portions of the real-time database the task has access to. The
Run-Time Manager refers to the environment variable FLUSER and stores it in the tag
FLUSER_U or FLUSER_S. The FLUSER environment variable must be unique for each user
of the application.

Chapter 6
•
•
•
•
Planning Your Application
A well-planned application can make the task of building and maintaining your FactoryLink
application much simpler. This chapter provides some of the basic things you need to consider
when planning your application.
P LANNING YOUR A PPLICATION P ROCESS

1 Analyze your processes and determine the requirements for your FactoryLink application
based on the following areas:
• Architecture and topology
• Redundancy
• OPC or other proprietary drivers
• Security and levels of users
• Custom tasks
• Tags and tag types
• Tag naming conventions
• Scripted procedures
• Message types
• Historical data requirements
• Organization and navigation of mimics
• Symbols needed for mimics
• Application objects
• Branching
• VBA scripting
• Alarming
• Trending
2 Create a complete FactoryLink application (both server application and client project) using
the Application Setup Wizard, as discussed on page 103.
3 Configure the server application component using Configuration Explorer.
• Create and define necessary tags.
• Create and define necessary application objects classes. Instantiate the number of
application objects that you will need for your application.

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

Minimum hardware and software requirements should be taken into consideration when
planning your application. While the software will run on the minimum requirements, they
may not be adequate for satisfactory performance for some systems, especially larger, complex
systems with multiple clients.
It is impossible to define the exact requirements for each system due to the flexibility and
scalability of FactoryLink and other layered software involved; however, the minimum
hardware and software guidelines contained in the Installation Guide should help you select
the best estimate of your system requirements. If your exact requirements are somewhat more
or less than what is stated in the guidelines, contact your authorized Siemens reseller or
representative for additional hardware and software recommendations.

PLANNING YOUR APPLICATION | 6
System Design and Maintenance Guidelines
S YSTEM D ESIGN AND M AINTENANCE G UIDELINES

Although individual system resources vary, here are some general guidelines for designing and
maintaining your FactoryLink 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 FactoryLink.
• 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 and
color configuration.
• Make the step parameter as large as possible. The drawing performance depends directly
on the size of the step. (A step of 4 will render twice as fast as a step of 2.)
• The angles 0, 90, 180, and 270 are the most efficient when using a linear gradient.
• The radial gradient is more time consuming than linear, particularly if the X and Y
coordinates are not close to the object’s center (50 percent, 50 percent).
• The number of colors has no impact on the drawing performance.
• Make backups often.
• Test often while configuring. Make a few changes, test, and save. It is easier to find
problems if you use this approach.

Tag Naming Recommendations
•
•
•
TAG N AMING R ECOMMENDATIONS
One of the most important parts of planning an application is to define a tag naming
convention before you start developing. Perhaps your plant already has a well-defined
standard, but if not, following some general recommendations for tag names will help you save
time and has the following advantages:
• Configuration requires minimum work since an object or a group of objects including all its
properties can be specified by a single entry.
• Objects can be automatically generated. This applies especially to application objects that
create object properties and their configuration table entries. You can then instantiate as
many application objects as you wish for one or more objects using a single entry.
When you are naming your tags, follow the general tag naming guidelines on page 41.
M ESSAGE TYPES
As part of developing your application, you should consider the types of messages that the
users will see. For example, you may want to distinguish between two types of alarm
messages:
• Those that need immediate attention, such as failure and warning alarms
• Those that can be taken care of later, such as diagnostics and status information messages
A PPLICATION O BJECTS AND S YMBOLS

An important part of building an application that is easy to expand and maintain is to define
application objects in Configuration Explorer (server side) and symbols in Client Builder
(client side) to represent various classes of objects to be controlled.
An example is configuring a standard pumping station. In Configuration Explorer, you would
configure objects that represent a pumping station with all the components required to operate
the pump. In Client Builder, you would configure the graphical symbols for a user interface
that represents the pumping station.
If the server configuration is saved as an application object, then, each time you need a new
pumping station, you could use the application object to create another instance.
Using application objects improves the quality of a FactoryLink application by encouraging
structured development, reducing errors, and improving maintainability.

PLANNING YOUR APPLICATION | 6
Standard Interface
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 FactoryLink serves as a demonstration and practice
application to help users learn about FactoryLink’s 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 FactoryLink 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
• Basic timers
• Multilingual support
You have a choice with FactoryLink: 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 plant’s 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.

Standard Interface
•
•
•

Chapter 7
•
•
•
•
Examples Application
The Examples Application is a demonstration and practice application. It provides sample

mimics that demonstrate many of the animation types that you can configure in Client Builder.
It includes screen navigation, application objects, basic timers, and multilingual support. With
the Examples Application, you can examine how the sample mimics were built and practice
configuring the components of a FactoryLink application.
Because the Examples Application contains extra configuration for its sample mimics, it is not
recommended that you use it as the basis for building your FactoryLink application. Instead, it
is recommended that you use the Application Setup Wizard to create your FactoryLink
application. The Application Setup Wizard lets you select from three versions of the FLNEW
template to build your application. FLNEW is essentially the Examples Application with the
sample mimics removed.
I NSTALLATION
Typical
The Examples Application is installed as part of the typical FactoryLink system installation
and is an optional, selectable component in a custom installation. If the Examples Application
is not installed, it can be installed by rerunning the installation program and selecting only the
Examples Application option. See the Installation Guide for more information.
The Examples Application installs two components:
• A Server Application with an application object database and source file examples
accessed with Configuration Explorer.
Server Application files are installed in this directory:
Program Files\Siemens\FactoryLink\Applications\Examples App
• A Client Project that is opened in Client Builder.
Client Project files are installed in this directory:
Program Files\Siemens\FactoryLink\Applications\Examples App\CBPROJ

• 7 | EXAMPLES APPLICATION
Running the Examples Application
•
•
•
Changing Computer Location
The Examples Application is designed to run on a computer where both the server and the
client are installed. However, if you want the Examples Application files to work with a server
installed on the local machine and the client installed on a remote machine, you must change
the information regarding the computer location. Perform the following steps to change the
computer location information.
1 Double-click the Examples Application Client Project icon on your desktop.
2 When client project opens in Client Builder, click Tools > Servers to open the Servers Editor.
3 Expand Clusters and FLCluster. Then, click Primary.

4 In the Machine Name field, either browse to or type the real server host name. Then, click OK.
R UNNING THE E XAMPLES A PPLICATION

To open the Examples Application client project, double-click the Examples Application Client
Project icon on your desktop. The Help button opens a text file that describes the basic
requirements for configuring and running the Examples Application. Click the Start Server
button to start the local server application.

EXAMPLES APPLICATION | 7
Server Application
S ERVER A PPLICATION
The Server Application runs the server tasks. The Server Application consists of a set of
preconfigured tasks that are commonly used in an industry, such as Alarm Logger, Database
Logger, Historian, Tag Server, and Math and Logic. These tasks provide examples of logging
data for alarm, trend, and browse, as well as generate real-time data for graphic animation
display. This data is accessed by the Client Builder graphics using the Alarm Server and the
Tag Server running within the FactoryLink application, and the Trend Server and Database
Browser Control running from Client Builder.
It is recommended that you periodically save your server application. You can save
FactoryLink applications by one of two methods: platform specific (native) and multiplatform
(compressed). Compressed saves are recommended.
If you need to restore a server application that you saved, you can do it two ways:
• A “compressed restore” is decompressing a single .mps file into a set of server application
files and placing those files in a selected directory.
• A “native restore” is restoring a set of native server application files from one directory to
another directory.
You can restore any server application previously saved as an .mps file. FactoryLink also
provides three sample server applications (in German, English, and French) that you can
restore. These applications reside in the C:\Program Files\Siemens\FactoryLink\Server\MPS
directory.
flnew.mps 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 103), you
will choose from three versions of the FLNEW template.
flblank.mps Contains minimal configuration, such as the FactoryLink global system tags.
This file is appropriate for a user who does not want any of the configuration
in the flnew.mps application.
fltest.mps Useful for testing purposes of most FactoryLink common tasks.
You can restore a server application using Configuration Explorer or the FLREST utility. The
FLREST utility can be accessed from Windows Explorer or a command prompt. The utility
restores the application and then adds it to Configuration Explorer’s namespace so that
Configuration Explorer can recognize the application.
Note: When restoring a server application in the same directory with an existing
application of the same name, the restore deletes and replaces the existing application.
Be sure to archive any server applications that you want to keep.

Client Project
•
•
•
C LIENT P ROJECT
The Client Project includes several sample mimic screens that demonstrate the major functions
available in the graphical development software:
• real-time data display for alarming, trending, and browsing, using the developed ActiveX
components.
• standard animation features commonly used for color control, value input and output, and
image display.
• advanced features used to add movement, visibility, scripting, and objects to the graphics.
Note: The FactoryLink client installation installs a set of clip art images (if you select
them) in the FactoryLink\Common\Client Builder\Shared Libraries directory. To use these
clip art graphics, you copy them into your new Client Builder project.
The FactoryLink installation placed two Client Builder icons on your desktop: Client Builder
and Examples Application Client Project. The Examples Application Client Project icon
immediately opens the Examples Application’s client project. The Client Builder icon allows
you to select the project you want to open.
Client Builder opens the client project at the logo screen, which contains buttons that allow
you to start and stop the local server without having to go to Configuration Explorer. If Client
Builder is pointed to a server other than the local server, these buttons will not start and stop
that server.
It is recommended that you periodically save your client project. When a client project is
saved, it is automatically compressed into a single file with a .cba extension.
You can restore any client project previously saved as a .cba file. FactoryLink also provides
sample client projects that you can restore. These projects reside in the C:\Program
Files\Siemens\FactoryLink\Applications\Compressed directory.
ExamplesApp.cba A reference application that contains sample mimics where you can
learn about techniques and best practices.
CBPROJx.cba Applications typically used by the Application Setup Wizard
templates.It does not contain sample mimics.
CBPROJA – shows a menu at the top of the Client Builder screen.
CBPROJB – shows a menu at the left side of the Client Builder screen.
CBPROJC – shows a menu as a square in the upper left corner of the
Client Builder screen.
When a client project is restored, it is uncompressed from the .cba format into a multiple files
project. A client project must be restored from its compressed .cba format before it can be
opened.

Mimics and Examples
M IMICS AND E XAMPLES

The Examples Application contains default mimics and examples of animated objects that you
can use to learn about ActiveX controls, animations, features, and concepts. You can also use
the examples for building your own custom project.
ActiveX Controls
The following examples use the FactoryLink-supplied ActiveX controls.
Control Example
Trend • Pen Groups – Displays a trend chart of historical and real-time data. The
pens (lines on the chart) are plotted for three pen groups.
• Scripted Pens – Displays a trend chart with a tag configured as a dynamic
pen.
• Compressed Logging – Shows four ways of using compressed logging.
The structure of the pens appears the same, but the amount of data logged
to the database is significantly different.
• Real-time Trending Only – Displays a trend chart of real-time data
Alarms The Alarm Viewer provides a visual display of run-time alarms in active states,
but not yet acknowledged. The Alarm Viewer is configured from the same
ActiveX control. It can display up to three alarms and is often used to show the
most critical or newest alarms. 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.
Browse • Data Point Logging – Shows a historical database where one point is
logged at a time to preserve data for historical purposes.
• Database Logging – Shows a historical database where blocks of data is
written to preserve data for historical purposes.
• Operator Log – Displays a log of all changes (events) made by an operator
of a FactoryLink application.
• Recipe Management – Creates and edits recipes (a collection of tags
grouped together) for some purpose.

Mimics and Examples
•
•
•
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.
Animation Description
Color Color fills any drawn object, bargraph, or legend by using a bit or numeric
register value
Text Displays messages, labels, or numeric values
Symbols Selects predrawn objects from a library by using a bit or numeric register value
Position • One-axis – Moves an object relative to its original position in X- and/or
Y-weighted directions using one register value linked to both axes
• Two-axis – Moves an object relative to its original position in X- and
Y-weighted directions using a separate register value for each axis
• Free – Moves an object to absolute coordinates in X and Y directions using
a separate register value for each axis
• Path – Moves an object along a path defined by a line or polyline
• Rotation – Rotates an object through an angle range relative to a register
value range
• Scaling – Scales an object through a percentage range relative to a register
value range
Send Writes values to bit, numeric, or text registers
Link/Run Link – Opens or closes graphics, connects to an external document (like a Word
file) or URL, and views or edits a text file as a note
Run – Launches an external program
Task Starts and stops tasks and indicates status

Mimics and Examples
Features and Concepts

The following examples use animations, ActiveX controls, and other functions to show and
explain features and concepts.
Feature Description
Layers Different sheets on the same graphic used to group objects that can be seen
when the Layer toolbar is used to select a layer number or the Layers value
is set by script
Decluttering A template that allows layer visibility based on zoom levels
Visibility bound An object property that defines object visibility based on zoom range
VBA scripting A single object or a grouped object script file that executes event-based
subroutines
Function objects Examples of library symbols that can be created with local register
variables for substitution with tags after inserting the symbol
Waveforms Uses function generators (such as sawtooth, triangle, square, sine, and
random) to simulate factory floor data. This mimic provides a snapshot of
the waveform as if it were generated from a real device connected to a
PLC.
Tag Properties Shows how to use tag properties in animations
Branching Shows how to use branching with symbols and animations and to open
mimics

Application Objects
•
•
•
A PPLICATION O BJECTS
Application objects automate the configuration of FactoryLink tables. They replace the need to
manually enter information into multiple configuration tables. The Examples Application
contains application object examples of typical functions used in a FactoryLink development
project. Table 7-1 explains the objects in the Examples Application.
Table 7-1 Objects in the Examples Application

Object Description
Analog2 Analog Input with Two/Four Alarm States – configures an analog
Analog4 input from an Excel spreadsheet in these task functions:
• Read from another FactoryLink server or 3rd-Party OPC server
• Scale to engineering units
• Log to a database
• Alarm on high and low limits
AnalogKB Analog Input with Scaling from Keyboard Entry – configures an
analog input from a keyboard manual entry in these task functions:
• Scale to engineering units
AnalogOut Analog Output for Write – configures an analog output from an
Excel spreadsheet for a write to another FactoryLink server or
3rd-Party OPC server.
Block Example for Instance and Offset – configures a block of related tags
from an Excel spreadsheet for Math and Logic variables.
Digital1 Digital Input with One Alarm State – configures a digital input from
an Excel spreadsheet in these task functions
• Alarm for an ON condition
Digital4 Digital Inputs with Four Alarm States – configures two digital inputs
from an Excel spreadsheet in these task functions
• Calculate the four analog states of two digital inputs using
Math and Logic
• Alarm for the four analog conditions
DigitalKB Digital Input from Keyboard Entry – configures a digital input from
a keyboard manual entry for read from another FactoryLink server or
3rd-Party OPC server.

Application Objects
Table 7-1 Objects in the Examples Application (continued)

Object Description
DigitalOut Digital Output for Write – configures a digital output from an Excel
spreadsheet for a write to another FactoryLink server or 3rd-Party
OPC server.
Equipment Equipment Example Collection of Application Objects – an example
configuration that makes an application object from a collection of
other application objects
FL_S7D Siemens S7D ECI Driver – an example configuration for this
communication driver
FLABRAPD Allen-Bradley RAPD Driver – an example configuration for this
FLDBLogAddPoint Add New Log Point – adds data points to the trend database table for
a specified logging duration
FLDBLogSetup Setup Trend Logger – sets the log rate for the points to log for the
database table
FLModbus Modbus Serial Driver – an example configuration for this
FLModbusPlus Modbus Plus RAPD Driver – an example configuration for this
FLModbusTCP Modbus TCP RAPD Driver – an example configuration for this
FLODXExample ODX Client to RSLinx and OFS Servers – an example configuration
for this communication driver
FLSinecH1 Sinec H1 RAPD Driver – an example configuration for this
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.

Application Objects
•
•
•
Table 7-1 Objects in the Examples Application (continued)
Object Description
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.

Chapter 8
•
•
•
•
Application Setup Wizard
The Application Setup Wizard provides a quick and easy way to create a FactoryLink
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 FactoryLink 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 Tag Servers including update
rate, sets up the FactoryLink NameSpace database, adds the FactoryLink 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 FactoryLink Server name and select the Application
Setup Wizard. The Configuration Explorer Help provides detailed information about using this
wizard. The FactoryLink Tutorial contains an exercise that lets you practice using the wizard.

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

APPLICATION SETUP WIZARD | 8
Application Objects in Server Templates
A PPLICATION O BJECTS IN S ERVER TEMPLATES

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

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

APPLICATION SETUP WIZARD | 8
VRN Setup Object

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

•
•
•
Driver Objects
Some application objects provide example configurations for common communication drivers.
These include the following:
• Allen-Bradley RAPD
• Modbus Serial
• Modbus Plus
• Modbus TCP
• ODX Client to RSLinx and OFS Servers
• Siemens Sinec H1 RAPD
If you choose the ODX example, be sure to run the VRN setup and choose the ODX/ECI
choice for proper redundancy and mailbox setup. Make this choice even if you are not going to
use redundancy.

Chapter 9
•
•
•
•
Getting Help
F ACTORY L INK D OCUMENTATION

The FactoryLink product has helpful information available in two formats: Help files and PDF
documents. You must have a Adobe Reader installed to view the PDF files. A version of
Adobe Reader is available on the FactoryLink CD or from the Adobe web site
(http://www.adobe.com).
The FactoryLink documentation is located in the Siemens\FactoryLink\Documentation
directory. You can access the documents quickly by double-clicking the FactoryLink
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 button to open an index that links to various topics in
the PDF files.
Document Name Purpose

Client Builder Help Explains how to use the Client Builder, the tool used to
design user interfaces for a FactoryLink application by
creating a graphical representation of an industrial process
and linking the graphics to real-time OPC data.
Configuration Explorer Help Explains how to use the Configuration Explorer, the tool
used to create a FactoryLink Server application. With
Configuration Explorer, you can define and configure tags,
logic, and reusable application objects.
Conversion Guide Provides information about converting from earlier
versions of FactoryLink to the current version.
Device Interfaces - EDI Guide Provides detailed information about configuring
FactoryLink to communicate with remote devices that use
EDI technology.
Device Interfaces - RAPD Provides detailed information about configuring
Guide FactoryLink to communicate with remote devices that use
RAPD technology.
Device Interfaces - OPC and Provides detailed information about configuring
Other Guide FactoryLink to communicate with remote devices that use
OPC and other technologies.

• 9 | GETTING HELP
Customer Support Services
•
•
•
Document Name Purpose
ECS Graphics and WebClient Provides information about the tools used to build
Reference Guide FactoryLink applications prior to version 7.0. This
document includes information about the Application
Editor, WebClient, and PowerVB Animation.
External Connectivity Guide Provides information about standards used to bridge data
between the FactoryLink real-time database and other
systems.
Fundamentals Guide Provides a getting started overview of FactoryLink,
including concepts and architecture, the planning process,
restoring and using the Examples Application, upgrade
considerations, and reference information.
Glossary List of terms used with the FactoryLink product.
Installation Guide Provides hardware and software requirements and
instructions to install the FactoryLink software. Included
are instructions to install Microsoft SQL Server.
PowerSPC Configuration Provides detailed information to use the FactoryLink
Guide PowerSPC quality management tool, which monitors the
quality level of a manufacturing process.
Programmer’s Access Kit Provides a collection of software tools for use in the design
and development of FactoryLink-compatible tasks.
Release Notes Provides information on the new features of FactoryLink
8.0, miscellaneous issues, and known software problems.
Task Configuration Reference Provides detailed information about configuring
Guide FactoryLink tasks for your application.
Tutorial Guides you step-by-step through the process of using
FactoryLink configuration tools to create a simple
FactoryLink application.
Unity Pro Browser Help Explains how to use the Unity Pro Browser, a configuration
tool that provides an easy way of configuring FactoryLink
tags based on the Schneider Electric Unity Pro variables.
Utilities Guide Provides information about the FactoryLink utilities used
for general maintenance and troubleshooting.
C USTOMER S UPPORT S ERVICES

For information about support services or if you have questions, contact your authorized
Siemens representative. For more information, go to http://www.siemens.com/factorylink.

Appendix A
•
•
•
•
FactoryLink Directory
Organization
FactoryLink applications can be installed on any appropriate drive. However, for the purposes
of this document, installations are assumed to be on a C:\ drive.
When you install FactoryLink, the installation program creates six directories under Program
Files\Siemens\FactoryLink. The directories are Applications, Client, Common, Documentation,
Installs, and Server.
Directory Subdirectory Contents

FactoryLink\Applications Compressed Contains compressed client (.cba) and server (.mps)
applications. If the Examples Application is installed,
this folder contains the dBASE IV and SQL versions of
the Examples Application in German, English, and
French.
Note: New applications can be stored in any
location; however, if you find it convenient, you can
store them in this directory.
Examples App If the Examples Application is installed, this directory
contains the application files, which include the server
application files and the client project files.
Server Application: The server application files and
folders are restored at the root of the Examples App
directory. The server application is configured in
Configuration Explorer.
Client Project: The client project files are restored in the
CBPROJ folder in the Examples App directory. The
client project is configured in Client Builder.
admin Administration files for ECS graphics
appobj Source and build files for application objects
asc ASCII database tables that store information about the
elements. Used to import/export configuration data
from one application directory to another
CBPROJ Client project files. The client project is launched by
opening the EXAMPLES.FVP file in Client Builder
cml Compiled Math and Logic files
ct Binary configuration tables. Each FactoryLink program
employs one or more configuration files

• A | FACTORYLINK DIRECTORY ORGANIZATION
•
•
•
FactoryLink\Applications Examples App dbt Files for the real-time database on-line browser
(continued) (continued) dct External device interface ct files
drw Graphics and PowerVB files used by run-time graphics
files
etm Files for the Event Time Manager (ETM) task
flapp1 Persistence and log files specific to the running
application
log Error files produced by FactoryLink processes at run
time containing debug information
mmi Files for the MMI task, if MMI is used
msg Message files for all tasks for the running application
net Groups on this node
procs Math and Logic procedures
rcp Files created by the Batch Recipe task
rpt Report files generated by the Report Generator task
shared Shared domain-specific files
spool Subdirectory used by the FactoryLink Print Spooler
task
user User domain-specific files
Historical Reports Contains the Microsoft Office Access Project for the
FactoryLink Historical Reports (Historical Reports.adp)
NameSpace Contains the database that holds the locations of
remote FactoryLink servers used by Configuration
Explorer
Templates Templates containing Application Objects for
generating common configurations used with the
Application Setup Wizard
FactoryLink\Client Configuration Explorer If Configuration Explorer is installed, this directory
contains the application files.
WebClient If the FactoryLink WebClient ActiveX control is
installed, this directory contains the application files.
FactoryLink\Common Client Builder Program Contains Client Builder application files
Shared Contains clip art libraries
Libraries
Template Contains the template project that Client Builder copies
Project and renames to create new Client Builder projects

FACTORYLINK DIRECTORY ORGANIZATION | A

FactoryLink\Documentation ReleaseNotes.htm Provides installation tips, updates, miscellaneous
issues, and other important information
Deutsch FactoryLink documentation in German for the installed
components
English FactoryLink documentation in English for the installed
components
Francais FactoryLink documentation in French for the installed
components
FactoryLink\Installs CBSetup.msi The program installer for the One-Click Client. If moved
to a different location, this file must appear in the same
directory as the OneClick.exe file.
OneClick.exe The installation for the One-Click Client used to install a
client on a remote system. If moved to a different
location, this file must appear in the same directory as
the CBSetup.msi file.
FLOCX.exe A backward-compatible installation for COM protocol
access to FactoryLink tags
Microsoft Access 2003 Runtime Contains the Microsoft Access RunTime Viewer
(ACCESSRT.MSI) installer used to view the
FactoryLink Historical Reports
IsoTsp2000 The installation for the OSI protocol stack used with the
Siemens Sinec H1 driver
LicenseServerInstall.exe The installation for the License Utility that defines the
client license servers and designates a license server
for redundancy
MECOM If MECOM is selected during installation, this directory
contains an installation for the MECOM driver.
S7D If S7D is selected during installation, this directory
contains an installation for the S7D driver.
S7TCP If S7TCP is selected during installation, this directory
contains an installation for the S7TCP driver.
WebClientInstall.exe A backward-compatible installation for the WebClient
ActiveX control. After installed, the files reside in the
FactoryLink\Client\WebClient directory.
XMLAdapterInstall.exe Installation for the XML Adapter that allows easy
integration of FactoryLink with leading XML-based
products

• A | FACTORYLINK DIRECTORY ORGANIZATION
•
•
•
FactoryLink\Server FLBuild.Id A file that determines the FactoryLink version.
AC Text files that function as attribute catalogs to inform
the main menu of the format of the configuration tables.
They also control entry criteria.
BIN FactoryLink command files, executable program files,
and related support files for each task, including the
task executables.
Blank Files used by FactoryLink utilities that manage
applications, such as FLNEW, FLSAVE, FLREST, and
FLCONV
CML Default make file for the Compiled Math & Logic task
CTGEN Configuration database conversion script files
DLL FactoryLink multilingual system files
DRW System files used by the Graphics task and by Client
Builder
Edi Subdirectory for External Device Interface protocol
modules
HELP Text files for the field-level Help
INC C-language include files for options such as Compiled
Math & Logic and the Programmer’s Access Kit (PAK)
Install Current language of the FactoryLink installation
KEY Text files used to translate text table entries into binary
values to be placed in configuration tables
LIB Library files and objects used with the PAK
MPS Demo application, new application, and test application
files
MSG Status message and error message files for
FactoryLink tasks
OBJ Library files for PAK
OPT Licensing files
Plc Sample program files for Siemens PLCs
src External Device Interface PAK C-source files, libraries,
and sample protocol module and sample PAK source
and make files

Appendix B
•
•
•
•
Real-Time Database and Tag
Structure
The real-time database is the area of the Kernel’s shared memory used to store the current
value of the application tags. It exists only in memory and does not persist between subsequent
invocations of the FactoryLink system.
R EAL -T IME D ATABASE S TRUCTURE

The real-time database is made up of arrays and pointers. Each array consists of up to 65,534
tags of a single data type. When you define a tag, the system prompts you to identify the tag
data type by choosing one of FactoryLink predefined data types. The following table shows the
storage capacities, ranges, and accuracies of each data type.
Storage in User Storage in Kernel Value Range and

Data Type Value Area Area Accuracy
Digital 1 bit 2 bytes 12 bytes 1 (ON) or 0 (OFF)
(Boolean)
Analog 2 bytes 2 bytes 14 bytes -32,768 to 32,767
(Short integer) (signed)
Longana 4 bytes 4 bytes 16 bytes -231 to 231 -1

(Long integer)
Floating point 8 bytes 8 bytes 20 bytes +/-10-308 to
(IEEE +/-10308
standard/double
precision)
Message 0 to 65534 0 to 65534 bytes 20 bytes per ASCII or arbitrary
(String) bytes message + storage binary data
of data
Mailbox 0 to 65534 0 to 65534 bytes 20 bytes per Arbitrary binary
(Variable length bytes message + storage data
data organized as of data
a queue)

• B | REAL-TIME DATABASE AND TAG STRUCTURE
Real-Time Database Structure
•
•
•
Use the following formulas to determine memory requirements:
Formula = storage requirement for a tag defined for the Shared domain:
(N - 4) + (4 x I)
where:
N – the storage in Kernel area from the table above.
I – the number of instances (shared + user).
Example:
A Shared domain long analog tag in a system with a maximum of two User instances:
[20 bytes (from table) - 8] + {8 x [1(shared) + 2 (user)]} = 40 bytes
Formula = storage requirement for a tag in the User domain:
(N x I)
where:
N – the storage in Kernel area from the table above.
I – the number of instances (shared + user).
Example:
A User domain float tag in a system with a maximum of two User instances:
24 bytes (from table) x [1 (shared) + 2(user)] = 72 bytes
The FactoryLink Kernel uses data types and tag numbers to read from or write to tags in the
real-time database.

REAL-TIME DATABASE AND TAG STRUCTURE | B
Tag Structure
A tag consists of the following items:
• One or more bits containing the value
• Set of change-status bits (change-status word)
• Set of wait bits (wait-status word)
• Set of reserved bits
FactoryLink 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 FactoryLink Kernel to indicate
changes in a tag value. The value of the change-status bit can be either ON (1) or OFF (0).
FactoryLink tasks write information to tags through either:

• Write call
• Forced-write call
Tasks use the Kernel Service’s write-call function to update a value of a tag. This function first
determines whether the tag value changed. If the new value differs from the old, the write-call
function sets each of the tag change-status bits to 1 (ON) and stores the new value in the tag;
however, if the comparison determines the new value for the tag is identical to the old, nothing
changes. This method saves processing time because tasks watching the tag will not waken to
process unchanged values.
Alternatively, the writing task can also use the Kernel service’s 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.
FactoryLink 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 routine’s 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 tag’s 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.

FactoryLink tasks use change-status bits as exception flags and the Kernel acts as an exception
processor.
Exception processor terminology is uniform across all FactoryLink 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 FactoryLink tasks to perform functions on an exception-only basis or only on
those tags whose values have changed rather than continuously reprocessing unchanged
information. This method results in increased software performance.
Wait bits: For each tag, one wait bit exists for each possible client process. When the client is
currently waiting to read the specified tag, the value of the bit is 1 (ON); otherwise, the value is
0 (OFF).

Real-Time Database Access – Reads and Writes
•
•
•
R EAL -T IME D ATABASE A CCESS – R EADS AND W RITES
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 FactoryLink Kernel. The
Kernel is the part of the real-time database that manages the reads and writes. The Kernel’s
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 tag’s 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
tag’s status, its change-status bits are forced to 1.
Using the previous example:

• A tag is named Tank1.
• Its current value is 10.
• The Interpreted Math and Logic task (IML) is configured to perform a calculation and
assign the result to Tank1.

•
•
•
IML performs its calculation and the result is 10. IML makes the forced-write call to the
database. The Kernel writes the new value of 10 to Tank1. Because the Kernel performed the
write, it sets the change-status bits for Tank1 to 1. Therefore, the Kernel notifies any tasks
waiting for a change on Tank1 that they should read this new value.
Change (Conditional) Read

A change-read call returns the value only if the data has changed. The condition asks: “Are the
change-status bits for the tag set to 1?” If the change-status bits are 1, then the value must
differ from the last read, so the Kernel notifies waiting tasks to read the value again. This type
of read significantly optimizes performance.
Normal (Unconditional) Read

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

Tag Structure
TAG S TRUCTURE
If you could see a tag, you would see that it consists of a number of bits. Excluding the bits
required for the tag’s 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 FactoryLink system.
Change-Status Bits
Change-status bits enable FactoryLink to operate based on exception processing. Exception
processing means that tasks do not access the database to read a tag’s value unless the tag’s
value has changed since the last time it was read.
Each FactoryLink 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 tag’s value has changed.
The bit is set to either 1 (ON) or 0 (OFF).

Tag Structure
•
•
•
• One (1) indicates to a task that the value of the tag has changed since the last time it was
read, so the task will access the database again to read the tag’s new value.
• Zero (0) indicates that the tag value has not changed since the last time it was read, so the
task will not access the database unnecessarily to read a value that did not change.
When a task writes a value to a tag, FactoryLink automatically sets all change-status bits to 1.
When a task reads a tag, it sets only that task’s individual change-status bit to 0. The
change-status bits for tasks not configured to read a tag always have a value of 1; they do not
affect other tasks or the application.
Unless you define a default value for a tag, the start value of all change-status bits is zero (0),
indicating that no activity has taken place.
Digital Tag Structure

A digital tag contains 16 bytes:
• The first bit stores the tag value (either 0 or 1).
• The second bit through the thirty-second bit store the value for the change status of each
task (a total of 31 tasks).
• The next four bytes are change-wait bits used to allow a task to sleep until a tag’s value
changes.
• The final eight bytes are reserved for future use.

Tag Structure
Analog Tag Structure

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

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

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

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

Tag Structure
Mailbox Tag Structure

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

Tag Structure
•
•
•

Fundamentals Guide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Fundamentals Guide

Uploaded by

Copyright:

Available Formats

FactoryLink

Siemens AG Copyright © Siemens AG 2007.

Chapter 1 Introducing FactoryLink ............................................................................. 1

Chapter 2 Distributed Architecture............................................................................... 5

Chapter 3 Features, Tasks, and Tools .......................................................................... 9

FactoryLink Fundamentals Guide / iii

Chapter 5 Internal Architecture.................................................................................. 37

iv / FactoryLink Fundamentals Guide

Chapter 6 Planning Your Application ....................................................................... 87

Chapter 7 Examples Application................................................................................ 93

Chapter 8 Application Setup Wizard........................................................................ 103

FactoryLink Fundamentals Guide / v

Appendix A FactoryLink Directory Organization....................................................... 111

Appendix B Real-Time Database and Tag Structure .................................................. 115

vi / FactoryLink Fundamentals Guide

H OW F ACTORY L INK C AN H ELP YOU

FactoryLink Fundamentals Guide / 1

2 / FactoryLink Fundamentals Guide

Two Types of Graphics Technology

Multiplatform graphics FactoryLink ECS (Pre 7.0)

Windows Technology Client Builder

FactoryLink Fundamentals Guide / 3

4 / FactoryLink Fundamentals Guide

The fundamental architecture of FactoryLink is based on the latest Microsoft Windows

T HREE -T IER M ODEL

Tier Description In FactoryLink

FactoryLink Fundamentals Guide / 5

6 / FactoryLink Fundamentals Guide

D EVELOPMENT AND R UN -T IME S YSTEMS

FactoryLink Fundamentals Guide / 7

Developer-Defined Maximum Tags (Total Tags)

Input/Output Maximum Tag (I/O Tags)

8 / FactoryLink Fundamentals Guide

F ACTORY L INK TASKS

Graphical User Interface

FactoryLink Fundamentals Guide / 9

10 / FactoryLink Fundamentals Guide

Dynamic Data Exchange

OPC Data eXchange (ODX)

Enhanced Communication Interface (ECI)

FactoryLink Fundamentals Guide / 11

Timed Events and Intervals

Real-time Database Browser and Debugger Tool

Scaling and Deadbanding

12 / FactoryLink Fundamentals Guide

Interpreted Math and Logic Operations

Compiled Math and Logic Operations (Optional)

Event Time Manager

Logging and Retrieving Data

Alarms and Events

FactoryLink Fundamentals Guide / 13

Alarm E-mail Notification

Operator Event Logging

14 / FactoryLink Fundamentals Guide

Native Oracle Historian Interface

Native Sybase Historian

Data Point and Database Logging

FactoryLink Fundamentals Guide / 15

Real-Time and Historical Trend Controls

Database Browser Control

16 / FactoryLink Fundamentals Guide

Communicating Across a Network

VRN and Redundancy