C For WinCC
C For WinCC
Configuration Manual
Manual Volume 1
The other names used in this manual may be trademarks; their owners’ rights may be violated if they are
used by third parties for their own purposes.
(The transmission and reproduction of this document, and (We have checked the contents of this manual for agreement
utilization and disclosure of its contents are not permitted with the hardware and software described. Since deviations
unless expressly authorized. cannot be precluded entirely, we cannot guarantee full
Offenders will be liable for damages. All rights, including rights agreement. However, the data in this manual are reviewed
created by patent grant or registration of a utility model or regularly and any necessary corrections included in subsequent
design, are reserved.) editions. Suggestions for improvements are welcomed.)
Siemens AG 1994 - 1999 All rights reserved Technical data subject to change
C79000-G8276-C157
Printed in the Federal Republic of Germany Siemens Aktiengesellschaft
Table of contents
1 Configuration Manual ................................................................ 1-1
1.1 Configuration Manual - Notes regarding Structure and
Application ...................................................................................... 1-2
3.3.9 Reuse - Transfer of Project Parts to a New or Existing Project ..... 3-59
3.3.9.1 Transfer of Pictures ........................................................................ 3-60
3.3.9.2 Transfer of Symbols and Bitmaps .................................................. 3-62
3.3.9.3 Transferring a Project Library (with preconfigured Symbols and
Customized Objects) ...................................................................... 3-63
3.3.9.4 Transfer of Actions ......................................................................... 3-65
3.3.9.5 Transfer of Tags ............................................................................. 3-66
3.3.9.6 Transfer of Multilingual Texts (from Pictures, in Messages) .......... 3-73
3.3.9.7 Transfer of Messages..................................................................... 3-74
3.3.9.8 Transfer of Measured Values ......................................................... 3-77
3.3.9.9 Transfer of Print Layouts ................................................................ 3-77
3.3.9.10 Transfer of Global Actions .............................................................. 3-77
3.3.9.11 Transfer of Project Functions ......................................................... 3-77
3.3.9.12 Application of Standard Functions.................................................. 3-77
3.3.9.13 Transfer of the User Administrator ................................................. 3-77
5.3 Format DLL Interface to Alarm Logging and Tag Logging ............. 5-60
5.3.1 Shared Interface to Alarm Logging and Tag Logging .................... 5-61
5.3.2 Tag Logging-specific Additions ...................................................... 5-63
5.3.3 API Functions of a WinCC Format DLL.......................................... 5-64
5.3.3.1 Initialization of the Format DLL....................................................... 5-64
5.3.3.2 Query of the Properties of a Format DLL ....................................... 5-65
5.3.3.3 Query of the Name of the Format DLL ........................................... 5-67
Preface
The table of contents or the index will quickly point you to the information desired. The
online document also offers an expanded search function.
Additional Support
For technical questions, please contact your Siemens representative at your local Siemens
branch.
http://www.ad.siemens.de/ca01online/
In addition, the Siemens Customer Support provides you with current information and
downloads. A compilation of frequently asked questions is available at the following
Internet address:
http://www.ad.siemens.de/support/html_00/index.shtml
1 Configuration Manual
The Configuration Manual is part of the WinCC documentation and is mainly concerned
with the practical application of WinCC in projects.
Introduction
In recent years, the demands made on systems for monitoring and controlling production
processes as well as for archiving and further processing of production data have risen
greatly. In order to meet these new demands, new HMI systems have been developed over
the past years.
One of these new systems is WinCC. With respect to functionality, openness and being
state of the art, WinCC is without a doubt unique.
Older generation HMI systems often provided only one route to solving a specified task.
With WinCC, you almost always have a number of different options available to implement
tasks. This Configuration Manual has been written to ensure that you always apply the best
solution with respect to performance and the amount of configuration work required.
This description is intended to provide you with suggested solutions for achieving the most
effective use of WinCC in plant projects.
We have implemented these suggested solutions in WinCC sample projects. These sample
projects are supplied together with the WinCC CD-ROM. You can use these suggested
solutions directly in your own projects and save valuable time in the process.
Requirements
Before starting work with this Configuration Manual, you should already have some
practical experience using WinCC. Newcomers to WinCC will find the Getting Started
manual an ideal starting point to learn and become familiar with WinCC. The Getting
Started explains the main subjects and functions by means of a small demonstration sample.
This Configuration Manual is a supplement to the WinCC Help system (online and
documentation). If not explained in this Configuration Manual, you can look up the special
features of objects, properties and other subjects in the Help system.
• Distributed Servers
This section describes the creation of a WinCC project distributed across multiple
servers by means of sample projects.
• Redundancy
This section describes the configuration of a redundant server pair by means of a sample
project.
• Appendix
This section deals with various additional topics. These topics originate from, among
other things, WinCC Solutions and WinCC Tips Tricks.
Conventions
The Configuration Manual uses the following conventions:
Convention Description
Denotes an operation using the left mouse button.
Denotes an operation using the right mouse button.
R
Denotes an operation using a double-click of the left mouse button.
D
Italic Denotes terms of the WinCC environment and terms referring to the
elements of the program’s interface.
Italic, Green Denotes an operating sequence or entry to be followed by the user
(color visible only in the online document).
Blue Cross references (links) are in blue (color visible only in the online
document).
Finding Information
In the printed version of the configuration manual, information can be found in the
following ways:
• The table of contents lists information organized by topic.
• The index lists information organized by key word.
The sample projects described in this manual can directly be copied from the online
document to your hard disk drive.
For some, WinCC is the HMI system for inexpensive and quick configurations, while for
others it is an infinitely expandable system platform. Thanks to the modularity and
flexibility of WinCC, totally new possibilities are opened up for planning and implementing
automation tasks.
WinCC offers system modules for visualizing, reporting, acquiring and archiving process
data as well as for the coordinated integration of freely formulated user routines.
In addition, you can also incorporate your own modules.
In the following chart, WinCC comprises the entire central section. The graphic shows that
the default database Sybase SQL Anywhere is subordinate to WinCC. It is used to file
(transaction-protected) all list-oriented configuration data such as tag lists and message
texts, but also current process data such as messages, measured values and user data
records. This database functions as a server. WinCC can access the database via ODBC, but
also via the open programming interface (C-API) as a client.
The same rights are, of course, also granted to other programs. For this reason, a Windows
spreadsheet or a Windows database has direct access to the data resources of the WinCC
database, irrespective of whether the application is run on the same computer or on a
networked workstation. With the aid of the database query language SQL and
corresponding connectivity tools (e.g. ODBC drivers), other clients (e.g. UNIX databases
such as Oracle, Informix, Ingres) also enjoy access to WinCC’s data resources. And, of
course, vice versa too. All in all, there is nothing that stands in the way of WinCC being
integrated into a factory-wide or corporate concept.
Before you begin with the configuration, you should lay down a number of specifications
and conduct some structuring work. This
• simplifies the configuration
• improves the clarity of the project
• simplifies working as a team
• improves stability and performance
• simplifies project maintenance
Clear specifications of the structural guidelines are basic prerequisites for setting up or
expanding a corporate standard.
Note:
In our sample projects, the names of projects, screens, tags, variables and comments in the
scripts are in English.
Note:
An example of this are the options that can be set at Graphics Designer - Tools - Settings.
A detailed description of this topic can be found in the Online Help of the Graphics
Designer.
General Information
The project name is also suggested as the default name for the folder in which all the data
belonging to the WinCC project is stored. You can change the folder name during the initial
creation of the project or at a later time (form the Windows Explorer).
Parameters / Limits
All characters, except for some special characters (e.g. \ ? ’ . ; : / ), are permitted. Numerical
values from 0 - 9 are also permissible.
Specification
For the sample projects, described in the second part of the configuration manual, the
following applies to the project name:
a...a_nn
where:
Note:
When updating documentation, the WinCC project name can be included in the printouts.
This makes it easier to associate and find information.
General Information
Tag names are no longer restricted to a maximum of 8 characters. Despite this, you should
avoid making them too long. If you adhere to strict rules when allocating tag names, you
will find this to be tremendously advantageous during configuration.
When creating WinCC projects, the structure of Tag Management is one of the key tasks
necessary to ensure quick and effective configuration and high-performance processing
during runtime (in scripts).
Before defining the tag names, you must take a number of special characteristics relating to
the structuring of tag management in WinCC into consideration. Creating groups only
affects the way in which tags are displayed in the tag management during configuration.
Group names in now affect the uniqueness of the tag names. The tag names used in a
WinCC project must be unique. Their uniqueness is verified by the system.
WinCC helps you select tags in many different ways, e.g. through sorting according to
columns (names, creation date, etc.) or through the use of filters. However, you may find it
useful if the tag name contains additional information.
Specification
The following applies to the tag names of the sample projects dealt with in this manual:
xxxy_z...z_a...a_nn
where:
x Abbr. Type
BIN Binary Tag
U08 Unsigned 8-Bit Value (unsigned)
S08 Signed 8-Bit Value (signed)
U16 Unsigned 16-Bit Value
S16 Signed 16-Bit Value
U32 Unsigned 32-Bit Value
S32 Signed 32-Bit Value
G32 Floating-Point Number 32-Bit IEEE 754
G64 Floating-Point Number 64-Bit IEEE 754
T08 Text Tag 8-Bit Character Set
T16 Text Tag 16-Bit Character Set
RAW Raw Data Type
TER Text Reference
STU Structure Types
Y Abbr. Origin
r Pure read tag from the PLC (read)
w Write and read tag from the PLC (write)
i Internal WinCC tag without link to the PLC
x Tag with indirect addressing (a text tag whose content is a tag name)
_z Group (corresponds to a plant section or building)
_Paint ... e.g. name of a plant section
Parameters / Limits
• For the assignment of tag names, the following limitations should be observed:
• The special character @ should be reserved for WinCC system tags (however, the use
of this character elsewhere is not prohibited).
• The special characters ’ and % must not be used.
• The special character " and the character string // should not be used, since they have a
special meaning in C-Scripts (introduction/ conclusion of a character string as well as
the introduction of a comment).
• No spaces.
• No distinction is made between upper case and lower case letters in tag names.
General Information
If you want to address pictures in scripts or external programs, you will find it very helpful
to use a fixed structure when assigning the picture names. You should also put some
thought into deciding on the length of the picture names. Names (file names) that are too
long are more likely to hinder clarity (making selections in list boxes, calls in scripts, etc.).
Experience has shown that a maximum length of 40 characters is advisable.
Parameters / Limits
• For the assignment of picture names, the following limitations should be observed:
• Maximum length of 255 characters
• Any character with the exception of certain special characters
• No distinction is made between upper case and lower case letters in picture names
Specification
The following specifications apply to picture names used in the projects dealt with in this
manual:
aaaaa_k_x...x_nn
where:
a Picture identification (a-z, A-Z, no special characters) for grouping the pictures
course... e.g. name of the pictures of the C-Course
_x Name for the description of the picture function (a-z, A-Z, no special characters),
maximum of 30 characters.
_chapter ... e.g. name of the chapters of the C-Course
General Information
You can create your own scripts and actions in WinCC projects. The names you assign
should be of an expressive nature. This makes things a lot easier when using scripts later.
Using a proportional font tends to be a nuisance when configuring in the Global Script
editor. For this reason, choose a font with a constant character width (e.g. Courier) to make
things more readable.
The scripts should always be accompanied by appropriate and adequate comments. The
amount of time spent writing comments is out of all proportion compared with the amount
of time you need to comprehend a badly commented program. Although this fact is well
appreciated by all, it is still often ignored.
Specification
The following specifications apply to the scripts used in the projects dealt with in this
manual:
We use the proportional font Courier New, font size 8
All variable names and comments are in English
General Information
It is essential that you take the greatest of care when setting up the user interface. All
objects created in the Graphics Designer are displayed on screen in the user workspace.
The pictures created are the only interface between the machine and the user. For this
reason, you must take great care when creating them since they play a vital role in ensuring
the success of a project. It goes without saying that operation of the plant is more important
than the appearance of the screen, but in the long term, sloppily created pictures can mar
the impression made by and possibly even increase the costs of maintaining a plant that has
otherwise been well thought out.
These are the screens viewed daily by the operator (customer).
In a screen display system, information about the current status of the plant is presented to
the users solely by means of the pictures displayed. This interface must therefore provide
information in a manner as comprehensive and understandable as possible.
WinCC allows you to configure the user interface precisely as needed. How you lay out the
user interface of your own particular system depends on the hardware used, on the demands
during processing and on already existing specifications.
The Users
When configuring the user interface, the attention should be focused on the users, for whom
the configuration is after all being performed.
If you succeed in giving the users the information they need and do so in a clear manner,
the result will be a higher level of quality in production and fewer failures. The amount
of maintenance work necessary will also be reduced.
The users need as much information as possible. Using this data as the foundation, the users
make the decisions that are essential to keeping the process running and at high level of
quality. The main job of the users is not to respond to alarms (the process has then already
been thrown off balance), but to use their experience and knowledge of the process and the
information provided by the operating system to predict the direction in which the process
is developing. The users should be able to counteract irregularities before they arise.
WinCC gives you the ability to edit and display this information to the users effectively.
Studies have shown that experienced users want as much information as possible in
every picture, so that they do not have to change pictures as frequently.
In contrast, beginners become confused and uncertain of what to do when a lot of
information is packed into one picture. They either cannot find the right information or
cannot find it in time.
But experience has taught us one thing: A beginner soon becomes experienced, but an
experienced user will never become inexperienced again.
Hiding Information
The information displayed should be important and easily understood. Certain information
can remain hidden (e.g. measurement point identifiers) until they are needed.
Displaying Information
When displaying analog values, combine them with pointer instruments with digital values.
Graphical representation of values (e.g. pointer instruments, bar graphs ...) makes it far
easier and quicker for users to identify and grasp information.
In order to avoid problems arising from the unlikely but possible event of a user being
colorblind, important changes to an object (status) should not only be indicated by using a
different color but also by a different format.
Important information must always be immediately recognizable as such in a picture. This
means the good use of contrasting colors is essential.
Color Coding
The human eye picks up colors quicker than, for example, text. Working with color coding
can make you far quicker at establishing the current status of the various objects, but it is
important that you set up and at all times observe a consistent color coding scheme.
Uniform color specifications for displaying stati in a project (e.g. red for error/fault) have
already become standard. Corporate standards already in force at the customer must also be
taken into account.
Displaying Text
To make text easier to read, you should adhere to a number of simple rules.
• The size of the text must be matched to the importance of the information contained in
the text, but also to the distance the user will probably sit away from the screen.
• Lowercase letters should be preferred. They require less space and are easier to read
than uppercase letters, even if the latter are easier to read from a distance.
• Horizontal text is easier to read than vertical or diagonal text.
• Use different fonts for different types of information (e.g. measurement point names,
notes, etc.).
Screen Layout
If standard PC monitors are being used, experience has shown that it makes sense to split
the screen into three sections: the overview section, the workspace section and the button
section.
If, however, your application runs on a special industry PC or operator panel with integral
function keys, this method of separating the screen contents does not always make sense.
Parameters / Limits
The size of the individual pictures can be set as needed within fixed boundaries (min. 1 x 1,
max. 4096 x 4096 pixels). In the case of a single-user system with a 17" monitor, we
recommend a maximum resolution of 1024 x 768 pixels. With multi-user systems (multi-
VGA), you may find a higher resolution useful.
In the case of operator panels, the technology used usually restricts the resolution available
(TFT from 640 x 480 through 1024 x 768 pixels).
Specification
The following specifications apply to pictures used in the projects dealt with in this manual:
Resolution
In our sample projects, we use a resolution of 1024 x 768 and 800 x 600 pixels (for
exceptional cases). The color depth of your PC must be set to a minimum of 65536 colors
in order for our sample projects to be displayed correctly.
Texts
The names of measurement points are written in Courier, pure descriptions, all other texts
and text displays in Arial. For message boxes following the Windows style, the fonts MS
Sans Serif and System are used.
The font size is adjusted as necessary.
Screen Layout
We will configure the basic options for laying out the screen. In the remaining projects,
however, we will apply the method of sectioning the screen into a header, workspace and
footer.
General Information
You control your process application under WinCC using the usual input devices such as a
keyboard, mouse, touch screen or industrial joystick. If your computer is located in an
industrial setting with extreme conditions where it would be impossible to use a mouse, you
can configure tab orders and the alpha cursor. The tab orders move you through
controllable fields, while the alpha cursor moves you to the input fields.
Each control action can be locked against unauthorized access.
Opening Pictures
The concept for the selection of the screens depends on several factors. Of utmost
importance is the number of pictures and the structure of the process which is to be
displayed.
In small applications, the pictures can be arranged as a ring or FIFO buffer.
If you are working with a large number of pictures, a hierarchical arrangement for opening
the pictures is imperative. Select a simple and permanent structure so that the operators can
quickly learn how to open the pictures.
Of course, it goes without saying that pictures can be opened directly, and this may well
make good sense for very small applications (e.g. a cold-storage depot).
Hierarchy
A hierarchical structure makes the process easily comprehensible, simple to handle and
provides, if necessary, rapid access to detailed information.
A common and frequently used hierarchical structure consists of three layers.
Layer 1
Categorized under layer 1 are the overview pictures.
This layer mainly contains information about the different system sections present in the
system and about how these system sections work together.
This layer also indicates whether an event (message) has occurred in lower layers.
Layer 2
Categorized under layer 2 are the process pictures.
This layer contains detailed information about a specific process section and shows which
plant objects belong to this process section.
This layer also indicates which plant object the alarm refers to.
Layer 3
Categorized under layer 3 are the detail pictures.
This layer provides you with information about individual plant objects, e.g. controllers,
valves, motors etc. It displays messages, states and process values. If appropriate, it also
contains information concerned with the interaction with other plant objects.
Specification
The following specifications apply to projects developed in the course of creating this
manual:
We will be using a number of different control concepts in our projects and will point out
the differences among them.
Note:
The optional WinCC package Basic Process Control offers a ready-made control concept.
This optional package also contains other useful and powerful functions (e.g. storage).
General Information
The subject of colors is a very popular point of discussion with respect to HMI systems.
WinCC allows you to freely select the colors used for lines, borders, backgrounds, shading
and fonts. You have the choice of all those colors supported by Windows. Naturally, the
colors, and the other graphic elements too, can be changed during runtime in WinCC.
Color definition is particularly important in ensuring that the configuration is inexpensive
and that the processes are represented clearly.
• Colors should always be defined for the following areas. The colors can be defined in
accordance with DIN EN 60073 , which corresponds to VDE 0199, but must always be
agreed on together with the user:
• Colors for messages (activated / cleared / acknowledged)
• Colors for stati (on / off / faulty)
• Colors for character objects (circuits / fill levels)
• Colors for warning and limit values
Specification
The following specifications apply to the colors used in the projects dealt with in this
manual:
The color setting of your PC must be set to greater than 256 colors for the sample projects
to be displayed correctly.
To make it easier for you to get oriented, we will use a different background color for the
separate topics (tags, C-Course, picture configuration) dealt with in the sample projects.
The background color in the overview and button sections is darker.
For the alarm system, each message class and message type assigned to a message class is
given a certain color code.
General Information
When determining the update cycles, always consider the system as a whole: What is
updated and how often updating is carried out. Choosing the incorrect update cycles can
have negative effects on the performance of the HMI system.
When looking at an overall system (PLC - communication - HMI), changes should be
detected where they occur, namely in the process (PLC). In many cases, it is the bus system
that poses the bottleneck for data transmission.
When specifying the mode of updating measured values, you must pay attention to how
quickly the measured value actually changes. For the temperature control of a boiler with a
volume of 5,000 liters, the update of the actual value in 500 ms intervals makes no sense.
The following specifications apply to updating in the projects dealt with in this manual:
Insofar as the task definition permits, updating is performed driven by events. Since we
predominantly work with internal tags, we often trigger upon the change of the tag. When
using external tags, this can lead to increased system loads depending on the process driver
connection. If the communication permits an event-driven transfer, it should be selected for
time-critical data. Uncritical data can then be retrieved by the HMI in appropriate cycles
(polling procedure).
General Information
When operating plant, it is necessary to protect certain operator functions against
unauthorized access. A further requirement is that only certain persons have access to the
configuration system.
You can specify users and user groups and define various authorization levels in the User
Administrator. These authorization levels can be linked to the control elements in the
pictures.
The user groups and users can be assigned different authorization levels on an individual
basis.
Specification
In the sample projects Project_C-Course and Project_TagHandling, each user is authorized
to control the operation of the project.
In the sample project Project_CreatePicture, users can only control the operation of the
project after logging in. The password is the same as the project name
(Project_CreatePicture).
The buttons used for selecting the individual topics are linked to the authorization level
known as Project Control.
General Information
In general, WinCC supports two alarming procedures:
• The bit message procedure is a universal procedure which permits messages to be
reported from any automation system. WinCC monitors the signal edge change of
selected binary tags itself and derives message events from it.
• Sequenced reporting requires that the automation systems generate the messages
themselves and send them in a predefined format to WinCC with a time stamp and
possibly with process values. It is this message procedure which makes sequenced
ordering of messages from different automation systems possible. See chapter
Documentation of the S5 Alarm System.
What is to be reported?
When specifying which events and stati are to be reported, many people follow what they
see as the safest route and set the software to report all events and changes in status. This
leaves it up to the users to decide which messages they look at first.
If too many events are reported in a plant, experience shows us that important messages are
only picked once it is too late.´
General Information
It makes particularly good sense if you use a fixed structure for storing data when
implementing a project. The specification begins by deciding on which drive the WinCC
project is to be created. The next step involves the folder structure, etc.
Experience has shown us that it makes sense to store all the data of a project under one
folder which contains corresponding subfolders. You will find this method advantageous
when processing a project, but even more so when backing up data.
Note:
PC configurations differ greatly. To avoid any problems this may cause when assigning the
drive on which a project is to be processed, we suggest you use virtual drives. Assignment
of a folder to a virtual drive can be changed at any time.
Specifying Folders
In addition to the folders that are created by WinCC, create additional folders for Word,
Excel and temporary files if required.
Data Manager
The current tag values are requested by the data manager - the main administrator of tag
management - in accordance with the update cycles set. See chapter Adding Dynamics in
WinCC.
The data manager acquires the new process data via the communication channels and
supplies these values to the applications. The request of data therefore means a switch
between different tasks (Graphics Designer, data manager, etc.). Depending on the
configuration, this can lead to very different system loads.
Picture Update
Updating the individual object properties in the picture refers to the objects that have been
made dynamic after the picture is opened. The task of the updating cycle is to establish the
current status of the particular object in the picture. The update cycle of objects that have
been made dynamic can be set by the configurator or by the system for the following types
of dynamics:
Dynamic Wizard • You can choose from the Customization of the time
following depending on cycles, events or tags
the type of dynamic:
• Event trigger
• Time cycle
• Tag trigger
Direct Connection Event trigger
The update cycles to be selected are specified by WinCC and can be supplemented by user-
defined time cycles.
User Cycle
Up to 5 project-related user cycles can be defined. If the project name is selected in the
left tree structure of the WinCC Explorer, clicking on the toolbar button displayed below
will open the Project Properties dialog box.
In the Update Cycles tab of the Project Properties dialog box, the user-defined cycles 1 - 5
are offered for the project-related definition at the end of the default update cycles list. Only
these user cycles can be parameterized.
These user cycles enable you to define time cycles other than the ones already available
(e.g. 200 ms).
You can define user cycles for any length of time between 100 ms and 10 hours. You can
give user cycles any name you wish.
These project-related units of time can be used for selected objects whose update cycle
must be modified at a later time. Once reason for changing the time cycles could be to
effect an optimization. The user-defined update cycles also make it possible for you to
subsequently modify the set time cycle from a single central location. In this case, the
individual objects of the pictures no longer have to be adjusted as well. This is why this
method of defining user cycles should be preferred if you want your projects to be
maintenance-friendly.
Before you begin putting the possible update cycles to use, we must first take a look at what
the various update cycles mean.
For the update cycles, the following differentiations are made:
Type Meaning
Default Cycle Time Cycle
Time Cycle According to the time set, the property or action of the
individual objects will be updated. This means that each of
the tags is requested individually by the data manager.
Tag Trigger In accordance with the cycle time set and once the time
interval has elapsed, the tags are determined by the system
and checked for value changes.
If the value of at least one selected tag changes during the
time frame set, this acts as a trigger for the properties or
actions dependent on this.
All tag values are requested together by the data
manager.
Picture Cycle Updating of the properties of the current picture object and
all objects that are triggered by means of the Picture Cycle
update cycle.
Window Cycle Updating of the properties of the window object and all
objects that are triggered by means of the Window Cycle
update cycle.
User-Defined Time Cycles Time units that can be defined specifically for a project.
C-Action for direct Reading Values can be read directly from the PLC by means of
from the PLC internal functions in the C-Actions. Further editing of the
subsequent instructions in the C-Action is only continued
after the process values have been read (synchronous
reading).
Note:
Requesting of the current tag value by the data manager leads in each case to a change of
task and to a data exchange between the individual tasks. In addition, the tag values must be
requested by the data manager via the communication channel of the programmable
controllers connected. Depending on the type of communication, this is done by means of
request telegrams sent to the communication interface (FETCH) and data telegrams sent
back from the programmable controller to WinCC.
For the application of the update cycles, the following settings are recommended depending
on the type of cycle selected:
Configuration Dialog
This dialog is displayed if a Smart Object I/O Field is configured. This dialog can also
be initiated via R on the corresponding object.
Dynamic Wizard
This page is displayed by D on the entry Make Property Dynamic in the Standard
Dynamicstab of the Dynamic Wizard.
Dynamic Dialog
If you select the trigger button when in a dynamic dialog box, the dialog box for changing
the update cycle is selected.
Picture Cycle
Change of the picture cycle.
Window Cycle
Change of the window cycle.
or only once
Time Cycle
• The configured time factor of the global action defines when the defined sequence of
actions must be processed. In addition to already described default cycle and the
associated time settings of 250 ms to 1 h (or user-defined cycle 1 - 5), the time triggers :
• Hourly (minutes and seconds)
• Daily (hours, minutes, seconds)
• Weekly (day of the week, hours, minutes, seconds)
• Monthly (days, hours, minutes, seconds)
• Yearly (months, days, hours, minutes, seconds)
can be selected.
Tag Trigger
If the action is activated dependent on one or more tags, the event trigger must be set as a
tag trigger. You do this in same way as for the tag trigger for object properties.
The 2 second cycle is set by default. The configurator, however, can set the following time
factors instead of the default value:
At the start and at the end of the set time frame, the values of the tags selected are
determined. If the value of at least one of the tags has changed, the trigger for the global
action is tripped.
Note the high system loads when triggering upon change. This setting is not always
appropriate. The same advice applies here as does for the Update object.
All actions defined as global actions are not checked and activated object-linked, i.e. only
dependent on the time cycles or event triggers set. For this reason, only use the global
actions selectively and avoid unnecessary action steps, in order not to put too heavy a load
on the system. Neither use too many nor too many short time cycles for executing your
actions.
Definitions
The term adding dynamics means the changing of stati (e.g. position, color, text, etc.) and
the reaction to events (e.g. mouse click, keyboard operation, value change, etc.) during
runtime.
Each element in the graphics window is viewed as an independent object. The graphics
window itself is likewise an object of the object type known as Picture Object.
Each object in the WinCC Graphics System has Properties and Events. With just a few
exceptions, these properties and events can be made dynamic. The small number of
exceptions mainly concerns Properties and Events that have no effect during runtime. They
do not have a symbol which indicates that they can be made dynamic.
The properties of an object (position, color, text, etc.) can be set statically and be changed
dynamically in runtime.
All properties with a light bulb in the Dynamic column can be made dynamic. Once a
property has been made dynamic, a colored symbol, which depends on the type of dynamic,
is displayed instead of the white light bulb. Topics (e.g. Geometry) that have been made
dynamic are shown in bold type.
The events of an object (e.g. mouse click, keyboard operation, value change, etc.) can be
retrieved in runtime and be dynamically evaluated.
All events with a lightning bolt symbol in the Action column can be made dynamic. Once
an event has been made dynamic, a colored lightning bolt, which depends on the type of
dynamic, is displayed instead of the white lightning bolt. Topics (e.g. Miscellaneous) that
have been made dynamic are shown in bold type.
The objects of a plant picture can be dynamized in a number of different ways. The separate
standard dialog boxes in which dynamization is performed are oriented to different target
areas and to some extent lead to different results.
Overview
Type of A B Advantage Disadvantage
Dynamic
Dynamic Wizard x x Standard prompted Only for certain types of
method when dynamization. Always generates a C-
configuring Action!
Direct x The fastest method Restricted to one connection and
Connection for making a picture can only be used in a picture.
dynamic, greatest
performance in
runtime
Tag Connection x Easy to configure Limited options for dynamization
Dynamic Dialog x Quick and clear; for Cannot be used for all types of
value ranges or a dynamization.
number of alternatives;
high performance in
runtime
C-Action x x Almost unlimited Possibility of errors due to wrong C-
possibilities for instructions
dynamization thanks to slower performance compared with
the powerful script other types of dynamization,
language (ANSI-C) therefore always check whether or
not you can achieve your aim
through a different type of
dynamization.
Legend:
A: Dynamization of the Object Property
B: Dynamization of the Object Event
The folder structure of WinCC - without options and examples - looks as follows:
License.bak The log file with the license information from the
last startup.
WinCC_Op_01.log Operator messages generated by WinCC during
runtime.
WinCC_Sstart_01.log System messages generated by WinCC on
startup. An important file when troubleshooting.
The file contains messages about missing tags
and wrongly executed scripts.
WinCC_Sys_01.log System messages generated by WinCC during
runtime. An important file when troubleshooting.
The file contains messages about missing tags
and wrongly executed scripts.
Folder\File Comment
\sqlany\isql.exe Interactive program used for looking at the data in the
database of a WinCC project.
\bin\Wunload.exe Wizard used for emptying the online tables in the
database of the WinCC project, e.g. removing the
messages and measured value data stored.
The wizard automatically provides the runtime tables for
unloading; additional tables can be added or removed
from the list by the user at any time.
This tool must be used in the offline status of a WinCC
project. It cannot be used in runtime mode. Messages
and measured values can be exported during runtime via
the optional STORAGE package.
\bin\Wrebuild.exe Wizard for reconstructing the database; it cannot be used
in runtime mode!
\SmartTools\CC_GraficTools\ Viewer for graphics files (e.g. print jobs, exported
metaVw.exe symbols) in EMF format (extended meta file).
\SmartTools\CC_GraficTools\w Viewer for graphics files in WMF format (windows
mfdcode.exe meta file).
\SmartTools\CC_OCX_REG\oc For registering or canceling the registration of additional
xreg.exe OLE Control components (OCX).
\SmartTools\CC_OCX_REG\R Is called by ocxreg.exe.
egsvr32.exe
Note:
Create a special project folder for WinCC projects, e.g. WinCC_Projects. In this way, you
keep the WinCC system and the configured data totally separate from each other,
simplifying the task of backing up data. You also avoid the danger of losing data (due to
operator errors) if you need to deinstall WinCC.
.mcp (master control Main file of the WinCC project. The project
program) is opened with this file.
.pin Project.pin
GraCS .pdl (picture design The configured pictures.
language)
.sav Backup files of the picture files with the last
configuration state.
.gif (bitmap), Picture files
.wmf (windows meta file),
.emf (extended meta file)
.act (action) Exported C-Actions
.pdd Default.pdd Setting parameters for the
graphic editor (default settings of the
individual objects in the Object Palette)
Requirement
The HMI system (WinCC) in the plant should start automatically when Windows is started.
The HMI station operator does not need to know anything about using Windows (e.g.
activating WinCC under Windows NT).
Solution
WinCC is started automatically during the PCs startup routine. This function is set in the
Startup folder of Windows.
Create a Connection
As a result, WinCC will automatically be started. WinCC itself starts automatically with the
project that was processed or activated last.
To start a system in runtime mode, the project must therefore be exited while active.
Note:
If the key combination CTRL + SHIFT is not locked and it is pressed during startup of
WinCC, WinCC starts in the configuration mode even if the project was exited in active
mode.
The operator now sees the familiar start screen of the system. To prevent an accidental or
intentional switch to the configuration (running in the background) or Windows
applications by the operator, appropriate measures must be taken. Operators must also not
be able to open the database runtime window, since they can close the WinCC database
connection from there.
No Selection of:
Operators should have no way of switching from WinCC runtime to:
• the WinCC Explorer of WinCC (configuration environment)
• the runtime window of the SQL database of WinCC (Sybase SQL Anywhere), since
they could use this route to terminate the WinCC database connection. WinCC can then
no longer operate
• the task bar of Windows, since it can be used to start all installed programs
• the current task window, since the application can be closed from there
Key combinations are locked in the WinCC Explorer from the Computer Properties dialog
box.
The exact definition of the individual key combinations can be obtained from the WinCC
help or from the operating system help.
The locks are set in the WinCC Explorer from the Computer Properties dialog box.
The exact definition of the individual key combinations can be obtained from the WinCC
help or from the operating system help.
• If Resize and Minimize are not deactivated, access can be gained to the user interface of
the operating system.
• Close (not shown in the figure above) must also be deactivated, otherwise users can exit
runtime and access the configuration system.
Note:
If the keys mentioned above are all or partly locked, access to the configuration must be
provided for the configurator or service personal using a key especially configured for this
purpose. This also applies to the proper shut down of the system.
These functions must not be readily accessible. Also add access protection to the button by
setting the password property.
Controlled Exit
A WinCC station must never be switched off without shutting down the operating system.
The use of an EMERGENCY SHUTDOWN switch is not suitable for an HMI system. For
this reason, an appropriate button must be configured to enable operators to exit the system
correctly without requiring any additional knowledge.
Power Failure
To avoid data losses due to fluctuating currents or a power failure, a detailed data backup
concept for the HMI system should be devised and put into place.
In any case, a UPS (uninterruptible power supply) should be provided for the WinCC
station. This can be implemented by connecting the station to the plant’s own UPS or by
connecting a separate UPS to the server of WinCC. This applies to both single-user and
multi-user systems, regardless of the operating system being used (Windows NT).
The UPS used must also include special shutdown software for Windows NT, which - in
the event of a power failure and shutdown after a specified time interval - automatically
exits the operating system and all active applications without the loss of data; e.g. APC
UPS 600 with power shutdown software for Windows NT.
The WinCC station must have a serial interface to which a UPS with appropriate test
software can be connected. If there is no a serial interface free on the station (e.g. they are
all occupied by a printer or PLC), you must install an additional interface card.
Serial interfaces that are used for connecting two or more peripherals (e.g. via switches) are
not supported by the majority of UPS systems and are certainly not recommended, since the
system needs to be monitored constantly.
An appropriate monitoring service is installed in the operating system. This monitoring
service then has to be assigned shutdown parameters, so that coordinated and orderly
exiting of the system is guaranteed. The shutdown process for application software must be
activated under all circumstances, so that WinCC is closed without any loss of data in the
event of a shutdown. You must choose a Save Time before shutdown, that is sufficiently
long in order for all active applications to be exited properly.
Most software packages for UPS systems also offer a time-controlled Shutdown, e.g. for the
weekend or night time. This function can be used to achieve a deliberate shut down of the
WinCC system without any operator input.
Supplements
If your project uses additional packages (e.g. option packages or add-ons), special
communication interfaces or interfaces to other Windows programs (e.g. WORD, EXCEL,
etc.), these packages must also be installed on the destination computer. The associated
authorizations for options packages, add-ons or communication interfaces (channel DLLs)
must also be installed on the destination computer. Note that all the necessary
authorizations (for all channel DLLs used) must be imported on the new computer to enable
you to work with the WinCC project.
Windows Software
If OLE links to other Windows programs - e.g. to WORD, ClipArts or EXCEL - are used in
the WinCC pictures, the corresponding software package, depending on the type of the
OLE link, must likewise be installed on the destination computer, i.e. entered in the
Windows registry.
OCX, ActiveX
If other OCX components (OLE Control, ActiveX) from third-party software packages are
used, they must also be stored in the Windows registry. Register or check the registration
entries of these OCX components, e.g. via the tool SmartTools\CC_OCX_REG\ocxreg.exe
supplied on the WinCC CD-ROM. If a registration to OLE objects or to OCX objects is not
found on startup of the WinCC project in the runtime mode (as well as during the
configuration using the Graphics Designer), this object is displayed in the picture with the
remark Unknown Object.
Network
If the project has been configured for a multi-user system, the network must be fully
installed on the WinCC destination computer before the WinCC data is copied. Make a note
of the necessary computer names in the configured computer environment, since you will
need them when assigning the parameters of the project copied. The computer name is also
required as a parameter for a single-user system. Therefore, you must know the name of the
destination computer or determine its name via the Windows Control Panel.
Project Team
Similar tasks are specified in this regard for a configuration team, since a WinCC project
must in the end be merged again to form one project.
A WinCC project consists of individual files (e.g. pictures) and the configuration data in the
database (Alarm Logging, Tag Management).
Note:
Note that every change made in the database influences the structure and the access of the
database. Lots of unnecessary changes (possibly with deletions) can lead to the WinCC
database no longer being optimally configured and consequently to a loss of performance.
Single-User System
While the next configuration step, e.g. at Alarm Logging, is being carried out on the basic
project, you must never make a change to the database at some other point (e.g. archiving
Tag Logging) in a WinCC single-user system.
Configured pictures can be transferred at any time. You can copy the picture files (*.pdl)
directly from the source folder to the target folder of the WinCC project path \GraCS using
the Windows Explorer (useful if you have to copy several picture files).
Below is an extract from the project for the picture configuration:
You can also transfer pictures by opening a picture file (picture.pdl) in the Graphics
Designer via the menus File Open. Afterwards, the picture is saved in the current
picture folder (\GraCS) via the menus File Save As. This procedure is suitable if the
picture files are being used as a basis and will be customized immediately.
References in Pictures
Definition of the access rights to be used in the User Administrator editor. The access rights
used (e.g. for control buttons) must be defined for the group specifications.
Copying
Symbols for status displays or graphic objects in picture files are stored as separate files in
the picture folder of the project. This is done by copying the desired symbol files (*.emf or
*.gif) into the target folder \GraCS of the new project. These pictures are now immediately
available in the selection lists for status displays or graphic objects (see the Object Palette
in the Graphics Designer). Here is a section of the configuration dialog for the status
display:
Importing
Symbols can either be integrated into a picture using the method just described or can be
copied directly into the graphic picture being edited via the Insert Import menus. In
the latter case, you do not have to copy a file, instead you import the symbol you want
directly by accessing the path of the source project (\GraCS) and then selecting the desired
symbol file (*.bmp, *.emf, *.wmf). After being imported, the symbol is then immediately
displayed as an object in the picture (top left).
If symbols are stored in a project library, the project library can be used in another project
by being transferred completely. How this is done is described in the following chapter.
Global Library
If symbols are stored in a project library, this library can be used in another project by
copying the file library.pxl into the \Library path.
The preconfigured blocks can now continue to be used at any time in the new project:
Note:
Please take into account the fact that linked symbols may refer you to unavailable
references (or tags) that you must define first. Depending on the configuration of these
symbols, the actions or links associated may have to be adjusted. For this reason, after
using symbols from the library, check which properties/event links are already present and
whether these may have to be adjusted.
Individual Symbols
If only a few specific symbols from the project library are used in the new project, these
symbols are exported individually (symbol file *.emf).
Actions that are frequently required in a project or that are to be copied from one object
action to another object action are stored as separate files. These files are stored in the
\GraCS folder with the extension .act. They can be transferred at any time by being copied
from the source folder to the target folder.
An action file is stored into the target file named by the user (with the extension .act for
action) via the toolbar button Export Action from the C-Actions editor.
A stored action file is transferred to an object action in the picture of the new project via the
Import Action toolbar button. Please also note the description in the chapter Development
Environment for C-Scripts.
Note:
More often used actions can also be defined as project or standard functions.
Also specify the logical connection, in which the tag descriptions of the
assignment list are to be placed.
The data is now entered into the WinCC tag management. The tag names used in
a WinCC project must be unique. The tags are added to the (possibly) already
existing WinCC Tag Management. The tag name is the key to this.
Note:
To achieve the automatic generation of connections and data entries in the WinCC
database, you could compile a special program which would carry out such definitions
automatically via the WinCC API interface. In this way, existing plant data can be added to
automatically. This program must be written by a WinCC API programming or SQL
programming specialist.
The tags defined in Tag Management can be exported at any time as a text file to
supplement the list of tags. Afterwards, this data generated must be imported back into the
tag management of the project. The files created are in CSV (comma separated values)
format and can be read and further processed using any editing program.
• For this purpose, a separate application program is available on the WinCC CD-ROM in
the \SmartTools\CC_VariablenImportExport folder. This Windows program is provided
as a help application for:
• the export of the Tag Management data
• the import of tag data that has already been generated externally
• the mass data configuration
The following steps have to be performed now to export or import the data:
Import - Export
For the export or import, the following steps have to be performed:
Tag Lists
The following table describes the structure of the tag lists.
Connection List
Field Type Description
ConName char Logical connection name
Unit char Channel unit
Common char General
Specific char Specific connection parameters
Flag DWORD
In order to continue processing text lists in EXCEL (Version 7.0 or 8.0), you must open the
exported files of the file type text files [*.prn; *.txt; *.csv].
Instructions
The tag data in the text list is adapted using the following special instructions:
Before you initiate the import of the edited or new tags, first perform a data backup of
your project, since changes will be made to the database. These database changes cannot be
reversed in WinCC.
Note:
If message data is transferred from a WinCC V 1.10 project, you must pay attention to the
column headers in the message text file!
Since the specifications for measurement points and the definitions of the process value
archives and user archives together with their properties are integrated directly into the
database structure, it is not possible to transfer measured values (without direct accessing of
the database, which requires a sound knowledge of the database). This means that either
these archives and measurement points must be reconfigured or the data is transferred
automatically at the start of the configuration by copying an entire basic project.
Copy the desired print layouts, *.rpl for page layouts or *.rp1 for line layouts, from the
source folder to the \PRT folder of the new project.
Copy the desired global actions or background actions *.pas from the source folder to the
\Pas folder of the new project.
Copy the desired project functions *.fct from the source folder to the \Library folder of the
new project. These functions are made known to the project via the Options ´ Regenerate
Header menus in the Global Script editor. A detailed description about this topic can be
found in the chapter Development Environment for C-Scripts.
Since the specification of user groups, users and access rights together with their properties
are integrated directly into the database structure, it is not possible to transfer the User
Administrator. This means that a reconfiguration is required.
There is only one way around this: an automatic data transfer is initiated at the
configuration start by through copying an entire basic project.
Configuration of the control actions without a mouse must looked at separately for the
following areas of configuration:
• Control buttons in the plant picture (e.g. for changing pictures)
• by means of function keys
• by means of special keys
• by means of standard keys
• Any key control
• Moving around by means of control objects
• Input fields in the plant picture
• Input/output fields
• special input objects (check-box, ...)
• Alarm Logging (message windows)
• control actions by means of function keys
• control actions by means of specially configured keys
• Tag Logging (trend or table windows)
• control actions by means of function keys
• control actions by means of specially configured keys
• Starting a print job by means of a key
• Logging on or off by means of the keyboard
Control buttons are configured in the typical Windows Style. This is why you will find the
standard Windows control button in the Object Palette. You can add other graphical
elements to this button at any time.
Control Buttons
Hotkeys can be assigned, for example, to the functions keys mentioned. These keys are
already displayed in the configuration dialog box as selection buttons.
If you need to combine a key with, for example, the SHIFT key or CTRL key, then simply
enter the desired key sequence (e.g. SHIFT+F2) directly into the input field by pressing the
respective keys. There is no need to enter any special codes.
The key combination you have selected is displayed in the input field.
This key selection is stored in the properties of the object and can be modified either via the
configuration dialog box or directly via the property Miscellaneous
Hotkey.
Standard Keys
If the action is not assigned to a function key input but to a key on the standard keyboard,
e.g. the letter m, this key is stored as a hotkey at the Windows Button object.
This button event must be available to enable configuration of keyboard control actions.
When using predefined buttons from the user library, you must therefore first check
whether or not this button is suitable for working with only a keyboard and without a
mouse. The shift buttons of the user objects, for example, are not always enabled for
keyboard control actions. This means you may have to make adjustments.
Preconfigured button controls (e.g. scrolling through the picture hierarchy) can be found in
the optional packages (e.g. Basic Process Control - Picture Tree Manager, etc.).
If one of these objects is used as a control element, the button which triggers the action is
configured to respond to either the Keyboard - Press or Keyboard - Release event. Either a
Direct Connection or a C-Action can be configured as the action.
The triggering button event is either
• an any key action or
• a selected key on the standard keyboard
If the event is an any key event, a Direct Connection can be used. In contrast, if a specific
key input has to be checked, a C-Action must be used. The C-Action checks the key code
entered, character for character, before continuing the actual sequence of the action:
3.3.10.2 Movement over Control Objects (Input Fields and Control Fields)
The mouse can be used to click directly onto every controllable object. Whether or not
objects can be controlled is indicated by the mouse pointer changing. How can these objects
be operated without a mouse?
Alpha Cursor
You can move between the controllable objects in runtime mode by means of the
"movement keys". A distinction is made between:
• alpha cursor objects (I/O objects) and
• tab order objects
Input/output objects are selected via the alpha cursor (the Tab key or SHIFT+Tab key
combination).
All control elements (whether controllable by mouse, keyboard or both) can be integrated
into control by means of the tab order. The I/O fields can be integrated into control by
means of both the alpha cursor and the tab order.
TAB Sequence
The TAB Sequence (can be set via the Edit TAB Sequence Alpha Cursor or
Tab Order) enables you to influence the sequence in which controllable objects are
jumped to in runtime mode. The currently selected object can be visualized in runtime. This
is the runtime cursor, which can also be turned off (Computer Properties Graphics
Runtime). Buttons configured in the Windows Style are always displayed with a dashed
rectangle within the button when selected.
The movement above the controllable elements depends on the settings of the Graphics
runtime (Computer Properties Graphics Runtime).
Input/Output Fields
Configured input/output fields can be written in directly after being selected via the
keyboard, i.e. you can enter your new data immediately. A pure output field (Properties
Output/Input Field Type Output) cannot be operated.
The input is acknowledged - depending on the configured property (Properties
Output/Input Apply on Exit) - via the ENTER key. In contrast, the ESCAPE key
(ESC) exits input without saving the changes (if any) made.
In the message windows, different control buttons are set in the toolbar, which are
controlled by means of the mouse (standard).
The most frequent control actions in a message window are
• selecting a message for acknowledgment
• moving up/down through the message list
scrolling in the message list
When opening the message window or through a further control action, the control must lie
in the message window and not in the main window. Depending on the current
controllability, the button controls (or function keys) effect the function key bar of the main
window or the stored button controls of the message window. This can be achieved, for
example, by setting the current focus of control in this section of the window. The focus of
control is normally set by clicking with the mouse.
Using the keyboard, the focus can be set in message windows by means of the following
configurable routes:
• changing the window by means of a hot key
• setting the focus by means of a control button or
setting the focus directly to a defined element in the message window on opening the
picture.
Changing (switching) to the message window by means of a quick control action (hot key)
which can be used in the same way for all window changes, i.e. in trend windows too, is
defined in the startup parameters of the Graphics Runtime. The key combination (e.g.
CTRL+W) is entered under Computer Properties Graphics Runtime Hotkeys
Window On Top.
Once the message window has been opened, the buttons in the toolbar can be activated
directly by means of this key sequence.
Direct setting of the focus of control in the message window is, however, achieved by
means of the internal function Set_Focus. A C-Action for a button control or open picture
command (Picture Object Events Miscellaneous Open Picture) can
therefore influence the activation of the message window control.
The functions pertaining to the picture focus are available from Internal Functions
graphics set focus. For example, for setting the control focus, the
following function is called:
As the parameters, the name of the main window (picture name) as well as the Alarm
Control (object name) must be specified.
A message in the message window is selected by choosing the message line. When the
message window is opened, the cursor is positioned in the youngest message (the last
message in the message picture). Selecting a message or scrolling in the message window
depends on the activation of the scroll mechanism.
The picture scroll mechanism can be turned on/off either via a button in the toolbar or be
set directly in the configuration of the WinCC Alarm Control.
If scrolling and the control focus are active in the message window, movements can be
performed as follows:
Movement Standard Keys Key Settings
Up, Down in the Message Arrow Keys Individual message lines
List
Beginning, End in the Pos1 Key, End Key To the beginning or end of
Message List the message list
Scrolling Scroll keys (Page Up/Page Several message lines
Down)
In addition to being able to activate the buttons on the toolbar (such as acknowledgment of
the selected message) by means of standard mouse action, you can also define control
actions by means of function keys.
For each button displayed in the toolbar, a corresponding keyboard control can be
configured in the properties.
For Example:
These configuration steps enable you to assign a key combination to each and every one of
the buttons used for the message window.
All the toolbar buttons are specified by WinCC and they cannot be changed. If a given
button layout is specified for the plant to be configured, you must deactivate the WinCC
toolbar (i.e. no toolbar) and design the relevant buttons yourself. All of these new button
objects can be designed to satisfy the wishes of the customer, e.g. given icons.
The functionality assigned to a particular button must, however, still be configured as an
associated action. In the C-Action of the associated event (e.g. Press button), the
corresponding Standard Function must be selected from the function tree.
The functions provided for the button control are located at Standard Functions
alarm. For each button in the toolbar, the list contains a function which corresponds to it.
For example, the Single Acknowledgment button is called by means of the following
function:
As the parameter, the window title of the Alarm Logging Control must be entered.
These actions can also be used for buttons you have designed yourself by means of mouse
control.
A number of examples of such buttons can be found in the optional packages for the alarm
system (e.g. Basic Process Control - Horn acknowledgment, etc.).
In the Tag Logging trend or table controls (trend and table windows) used for displaying
measured values, various control buttons are configured for the toolbar, which can be
operated by mouse.
When opening the trend window, the control must lie in the trend window and not in the
main window. Depending on the current controllability, the button controls (or function
keys) effect the function key bar of the main window or the stored button controls of the
trend or table window. This can be achieved, for example, by setting the current focus of
control in this section of the window. The focus of control is normally set by clicking with
the mouse.
Using the keyboard, the focus can be set in trend or table window using the following
configuration approaches:
• changing the window by means of a hot key
• setting the focus by means of a control button or
setting the focus directly to a defined element in the trend window upon opening the picture
Implementation of these different variants can be found in this chapter under the description
of Alarm Logging.
In addition to being able to activate the buttons on the toolbar (such as selection of a time
frame) by means of standard mouse action, you can also define control actions by means of
function keys. By default, the individual buttons are occupied by the function keys F1
through F10.
For each button displayed in the toolbar, a corresponding keyboard control can be
configured in the properties. For example:
These configuration steps enable you to assign a key combination to each and every one of
the buttons used for the trend or table window. A button control for the trend or table
windows must therefore be defined in addition.
The following standard keys can be used in the trend window once the respective function
key has been activated:
As the parameter, the window title of the Tag Logging Control must be entered.
These actions can also be used for buttons you have designed yourself by means of mouse
control.
A print job can be started in a number of different ways. For example, in the WinCC
Explorer, the print job is activated directly by selecting a print job from the selection list.
You can, however, also create a Print button in the plant window itself, which you can used
to start the print job.This button already exists in the toolbar for the message lists and can,
as described on the previous pages, be activated by a function key or a key you have
designed yourself.
A printout of the screen contents - a "hardcopy" - can be activated in every picture by
means of a hotkey. This hotkey is set globally in the project properties. To do this, select -
from the WinCC Explorer - Project Properties Hotkey Hardcopy and define the
hotkey by directly entering the key combination (by pressing the respective key(s) on the
keyboard).
If you configure your own button for printing a defined print job in the plant picture, the
action must be triggered by a C-Action. As described at the beginning of the chapter, the
button is activated by, for example, a function key (see hotkey) or a keyboard action (e.g.
the D key). The C-Action must be configured correspondingly at the event in question (e.g.
Mouse Action or Keyboard - Press). WinCC provides this functionality through the
functions located at Standard Functions Report ReportJob .
This function receives the name of the print job as the first parameter. As the second
parameter, "PRINT" is transferred, if the print job is to be started immediately, or
"PREVIEW", if the print preview is to be displayed.
In addition to the configurable hotkeys for the log on or log off procedure, a key can also be
configured that will display the log on dialog box. You can also log off via a key action.
For this purpose, you have to configure a separate button, which can, for example, be
activated both by a mouse action and via the keyboard. You can also set a function key
control action by means of the hotkey property of the button. The various variations of
button controls are described in detail at the beginning of this chapter. The function that is
used for logging on or off is a WinCC application function. This function must be
configured as a C-Action. Store the C-Action, for example, at the Mouse Action or Press
Button event.
The following function is used for logging off:
The dialog box that pops up can be controlled by means of the standard keys:
If only a few simple picture modules are used in the project, one of the first variants is
adequate enough to satisfy the person configuring the system. These variants can be
implemented without any great training being required. The user object is particularly
suitable for simple objects of low to medium complexity and tag link. If you foresee that
the object will require a number of changes, you will find it makes sense to get to grips with
the concept of prototype pictures. If the graphical blocks are complex or a more
comprehensive processing performance is needed, the OCX technology should be
preferred. The OCX objects available will in the future grow stronger and stronger in this
field. In the following chapters, we will show you the various types of picture module
configuration and how they are put to use in the plant pictures. This will enable you to form
you own picture of the different variants and their applications in your projects.
To display the current stati of an object (controller, valves, motors, etc.) or to assign set
point values, specific information boxes are displayed in the plant pictures. These process
boxes typically contain both current states (actual values) and set values, which can be
entered by the privileged operator.
This picture window object, the picture window contents and the corresponding call of the
picture window (button) can be reused in a similar form for further devices. All you have to
do is copy the picture window object, the picture module and the button. The references
must be adapted each time. The picture window object and the button can both be copied by
being dragged to and dropped in the graphics library (e.g. project library).
In this way, the individual picture windows and their contents can be created for each
device and reused by being copied. As can already been seen, the work this necessitates is
that of adjusting the permanently stored references for the picture window contents. For this
reason, there is a more simple method of achieving reusability through indirect addressing.
The amount of adaptation work required should be kept to a minimum.
An alternative solution to this is to configure the picture module without a connection to the
picture window. This means that the picture module itself is configured as a non-displayed
object in the plant picture. The great disadvantage of this, however, when changing the
picture module is that a change must be made in all the pictures in which this picture
module is used.
So far, the individual components of the picture module have been permanently connected
to the corresponding (process) tags. If the connection is not made by means of a permanent
configuration but dynamically during runtime, the picture module created can be used with
far greater flexibility. This dynamic connection of (process) tags is implemented by means
of indirect addressing of the individual components in the picture module. This means that
no direct connection is made to the (process) tags; the connection is made only to the
Container, which will carry the current names of the corresponding (process) tags during
runtime.
The adaptation and reusability characteristics of a picture module can in this way be
simplified considerably.
Configuration is carried out in a similar way to that explained in the steps described above.
Here are the actually steps to be carried out:
Customized objects and the corresponding dynamic wizards can be used to create picture
modules which are easy to reuse. The copy made of the picture module can be connected to
the corresponding current (process) tags by means of simple configuration using the wizard.
A customized object is a graphic object designed by the person configuring the system (e.g.
a combination of several objects), whose large number of properties and events are reduced
to the essential properties and events by means of a configuration dialog. This customized
object is dynamized by being defined as a prototype by means of the corresponding wizard.
The following steps must be taken
customized object is formed from a group of WinCC objects. Initially, these objects are not
configured with dynamics. All the objects that are to be combined to form the customized
object are selected and the configuration dialog of the customized object is called:
In this dialog box, all the properties of the objects are now declared to be the properties of
the customized object, which are later to be dynamized. The basic properties for an object
(e.g. the position and size) have already been stored for the customized object.
Each individual property of the grouped objects can be selected in the dialog box and be
added to the new customized object per drag and drop as a user-defined property or event.
Each of these properties can be assigned a new (language-independent) attribute name by
the user and also the language-dependent property name (e.g. for configuration in English).
Properties which should not be visibly displayed in the properties dialog, but which are
used for example in scripts, can be hidden by using the @ character. This means that only a
few properties and events (to be dynamized) can be displayed. All the others are hidden.
The customized object you have designed must now be dynamized. To do this, a Wizard is
provided:
The prototype customized object is copied to the graphics library so that it can, for
example, be reused again and again. One example of a dynamic object are the pointer
instruments in the WinCC library (user library, customized objects, pointer instruments).
The prototype object is inserted into the destination plant picture as a copy of the prototype.
This copy now has to be linked to the real (process) tags from the tag management.
In addition to the Dynamic Wizard Link a prototype to a structure, there is also a Wizard
named Make a prototype dynamic. How does it differ from linking to a structure and which
steps have to be modified?
In contrast to permanent linking of an object to tags, the picture modules can also be linked
dynamically. This means that the instance to the runtime is set first depending on the
current contents of a tag. For example, the above picture module is not linked permanently
to the tag; the name of the tag is kept dynamic. The current name of the tag must then be
determined by means of a text tag. This text tag, which contains the current name of the tag,
must be linked to the picture module.
In contrast to permanent instantiation, i.e. linking to a structure, the following steps must be
modified when configuring:
Ten the dynamic customized objects and prototypes are used, the person configuring the
system must make sure that the necessary C actions have already been stored on the
objects. They must not be deleted, since otherwise the entire functionality of the module is
lost.
The technology of the prototype pictures goes one step further. When prototypes are used,
the concept can be structured so flexibly that a change made to the prototype is
automatically followed by an adjustment to the objects created. This flexibility requires the
linking of very flexible C scripts.
The technology of the prototype pictures operates using template pictures which can be
repeatedly integrated into one or more parent pictures. A template picture is only a
template, which is "brought to life" only once integrated into a real object. An object based
on a template (= prototype picture) is brought into being by what it known as an
"instantiation". A number of instances (i.e. real objects) can be created for one template.
Subsequent changes are made at a central point (in the template) and affect all applications
(instances). This makes this a very efficient program which does away with the laborious
task of dragging changes to many different places.
In a parent picture, up to 30 instances (i.e. objects) of a particular template type can be
displayed. If different prototypes are used, it is possible to use more than 30 objects.
The prototype pictures are picture modules which are copied to the library after being
created, so they can be reused. The picture modules used are used in the plant pictures as
instances of the template. These copies show the current data, e.g. of controllers or motors,
which is visualized in the module. The corresponding controller or motor components are
displayed automatically.
Not only simple picture modules, but complex ones too can be created. A picture module
can consist of several components that overlap each other either partially or fully, but that
make up a single common unit. For example, all the data that relates to a motor, such as a
view of the current status, progress data, maintenance data, etc., can be combined in one
object and updated as and when required. If you have a number of motors of the same type,
all you have to do is create the picture module once and then make copies of it. Everything
else is automatic.
The following steps must be followed to create the picture module:
The picture module can now be used in the plant pictures by being retrieved from the
graphics library.
Let’s first take a look at how the template picture is created.
Step Configuration
1 Creating a tag structure (structure data type) in the data manager; this is where
the number of tags that make up the structure is defined (member tags), the
names of the tags and their data type (BIT, SHORT, etc.). For example, PID with
the structure components set point value, actual value and temperature.
2 Creating a picture which is to be used as a picture module. This is usually smaller
than the size of the monitor screen and can be dimensioned accordingly. Each
picture that has been created in its own right can be used to create a template.
The picture is created using the graphics editing functions, and graphics tags such
as I/O fields, bars etc. are positioned in it but not linked to tags.
Internal relationships (direct links) between graphic objects, such as change-
controlled transfer of the output value of an I/O field to a bar, are configured in
this picture.
Step Configuration
3 The graphic fields are now linked to the structural components of the
corresponding tag structure. This link configuration links the tags at type level
(template only), but not yet with concrete process objects.
For this purpose, you will find a pre-prepared sample project on the WinCC CD
(\Samples).
In the project library (\Template) of this project is a customized object called
TemplateInit, which performs this connection. This is located in the graphics
library and can be dragged and dropped from here into a picture that is to be
standardized.
TemplateInit already has a complete script logic. This logic uses what is known
as a ConnectionTable, which during the configuration is filled in as a table and
contains precisely the underscored entries quoted above. This is method used to
define the link between the properties and the structural components.
The buildup of these links can be set within a template or also from outside. To
this end, the special project graphics library contains customized objects which to
the naked eye look like simple buttons, but which in fact contain parameterizable
information about the template to be called up.
All of the scripts for implementing this already prepared generation of the
prototype must be copied to the destination project. See the final steps described
at the end of the chapter under steps 8 - 10. Without these project functions, these
prototypes cannot be implemented.
4 This picture is to be used as a process box.
To do this, create a picture window object in a temporary picture (i.e. it is only
required for this intermediate step) and connect the Picture Name property of this
object to the picture that contains the picture module.
5 Copy this picture window object to the graphics library by dragging and dropping
it.
This template can now be used repeatedly in the plant pictures. The link to the process tags
is made automatically when the name is entered.
hen the picture module is positioned in the picture, it is given the name of a structured
(process) tag whose values contain the status data of a process object. During runtime, then,
the picture module retrieves the status data automatically.
A number of C-Scripts are used for these prototype pictures, which are or have been stored
as project functions. To be able to use the C scripts that have already been prepared, you
have to adopt the following scripts from the sample project. Proceed as follows:
icture modules (standardized picture segments or templates) offer a very large savings
effect. They are modeled as objects with tag references and are, for example, stored in the
graphics library. They are taken from this graphics library, positioned in the plant picture
and automatically supplied with data during runtime. There is no longer any need to
configure links for individual tags with graphic segments such as I/O fields, bars etc.
• When using these prototype pictures, there are different ways in which the picture
module components are supplied with the current names. This is done by means of the
following variations, which we will briefly name here:
• The instance name is determined upon the selection of the picture window: for this, a
predefined project function (EnableTemplateInstance) is stored at the open picture event
in the picture window.
• The instance name is defined via an input/output tag, which is automatically read in
the picture window via a script that determines the instance name: this is done by using
the prepared customized object InstanceCallButton+Template.
• A button transfers the instance name directly to the called picture window: this is done
by using the prepared customized object InstanceCallButtons+Template.
You can find detailed examples of these variations in the sample project on the WinCC CD-
ROM (\Samples).
OCX or ActiveX objects are picture modules which are available as loadable components.
WinCC offers a number of them, e.g. the WinCC Digital/Analog Clock Control.
These modules can be very easily incorporated into the plant pictures.
Creation
The OCX picture modules must be created using a separate development environment. This
can be Microsoft Visual C++ 5 or Microsoft Visual Basic 5.
This method is used to modify and improve the picture modules. The OCX modules are
very powerful, but they cannot be created with WinCC configuration resources. In this
case, you will always have to resort to an external method of creating or modifying.
In contrast with change-friendly and powerful OCX programming, the technology of the
prototype pictures can get by with pure WinCC resources. This means that you do not need
to have any knowledge of OCX programming.
There are already a large number of such modules available today. Among other things,
complete modules are available as PCS7 faceplates in connection with the integration of the
two worlds of Operation and Observation and PLC programming (PCS7) in the plant
sector.
Registration
The OCX modules created or purchased in must be registered on the respective WinCC
station. You can see which OCX objects are available on the WinCC station by looking in
the selection dialog of the Graphics Designer (see description above). All the OCX
elements registered on the computer are listed in the dialog box. An OCX element is stored
on the computer in the form of a file with the extension .OCX or .dll.
If a module has not yet been registered, you can do so in the WinCC OLE Control dialog
box. The dialog box contains a button for registering as well as removing the registration of
the currently selected component.
The relevant file must be on the WinCC station for registration to be carried out.
The compatibility and functionality of the OCX components must be tested by the
configurator himself. Only those OCX modules marked using WinCC have been used and
tested in the WinCC environment.
WinCC Explorer
• The following changes are not adopted:
• changing the type of a computer in the computer list
During runtime, the following configuration steps are not possible:
• deleting/renaming tags
• changing the data type of a tag
Alarm Logging
The following changes are not adopted:
• changing the archives/reports
• changing the group messages
• every message after a total of 500 single messages while runtime is active
During runtime, the following configuration steps are not possible:
• no limitations
Tag Logging
The following changes are not adopted:
• no limitations.
• During runtime, the following configuration steps are not possible:
• tables of user archives can be created but not changed
• deleting data in Tag Logging and from user archives
Exceptions for the configuration during runtime:
the runtime API of Tag Logging can be used to edit and delete the tables of the user
archives
Global Script
The following changes are not adopted:
• changes made to a Wizard script are only adopted after restarting the Graphics Designer
modified Wizard scripts
During runtime, the following configuration steps are not possible:
• no limitations
Report Designer
The following changes are not adopted:
• changes made to the message sequence report, since once started, it always remains
active in runtime and does not reload the layout information
During runtime, the following configuration steps are not possible:
• no limitations
Redundancy
The following changes are not adopted:
• the computer name of the partner cannot be transferred to a third computer
• the AutoSwitcher cannot be changed, i.e. you must configure at the beginning to where
the AutoSwitcher is to switch. It does, however, also switch back if the other one fails
During runtime, the following configuration steps are not possible:
• no limitations
Text Library
The following changes are not adopted:
• no limitations.
• In the Text Library, the changed texts are adopted via File Send Changes to
Active Project
• In Alarm Logging, the changes are copied to the Text Library via File Save
During runtime, the following configuration steps are not possible:
• no limitations
User Administrator
The following changes are not adopted:
changes to the user authorizations only become effective after logging off/on again
• During runtime, the following configuration steps are not possible:
• no limitations
4 WinCC C-Course
To make objects dynamic, various options are available in WinCC. Among others, these are
tag connections, dynamic dialogs and direct connections. With these aids, the
implementation of complex dynamics is possible. Nevertheless, they reach their limits with
growing demands. A much broader range of possibilities is available to users through the
configuration of C-Actions, project functions or actions. They are created in the WinCC
script language C. For many applications it is not necessary to have a very comprehensive
knowledge of C. It is sufficient to supply existing functions with parameters. However, to
use all capabilities of C as the WinCC script language, a basic knowledge of this
programming language is needed. This course can provide you with this knowledge.
Target Group
This course is intended to provide basic knowledge about the general application of the
programming language C to everybody who is not familiar with it. Experienced C
programmers can learn the special features of C when applied to WinCC.
The sample project for this course can be copied directly from the online document to your
hard drive. By default, it will be stored to the C:\Configuration_Manual folder.
Project_C_Course
Sample Project
The interface of the sample project is divided into several sections. They are listed below:
• Navigation Bar (1): The navigation bar allows the selection of the pictures pertaining to
the various chapters.
• Chapter Window (2): The chapter window displays the pictures assigned to the
individual chapters. These pictures contain all samples described in the particular
chapter. Most of these samples are created at buttons.
• Script Window (3): The script window displays the code of the sample currently
selected in the chapter window. The currently selected sample is marked red in the
chapter window.
• Diagnostics Window (4): The diagnostics window displays all outputs of the various
samples initiated by the printf() function.
Action Editor
For the configuration of a C-Action, the action editor is available. This editor is opened
from the Object Properties dialog box via a
R on the desired property or event and then selecting C-Action from the displayed pop-up
menu. Already existing C-Actions are marked by a green arrow at the property or event.
In the action editor, the C-Action can be programmed. For C-Actions at properties, a trigger
must be defined. For C-Actions at events, this is not necessary since the event itself is the
trigger. The completed C-Action must be compiled. If no errors are detected by the
compiler, the action editor can be exited by clicking on OK.
Structure of a C-Action
In general, a C-Action corresponds to a function in C. There are two different types of C-
Actions: Actions that are created at Properties and actions that are created at Events.
Generally, a C-Action at a property is used to control the value of this property with respect
to different environmental conditions (e.g. the value of a tag). For this type of C-Action, a
trigger must be defined which controls its execution. A C-Action at an event is used to react
to this event.
C-Action at a Property
The sample code above represents a typical C-Action at a property. The meaning of the
individual sections is described below.
• Header (gray): The first three lines shaded gray form the header of the C-Action. This
header is generated automatically and cannot be changed. Except for the return value
type (long in the sample code), the function header is identical for all properties. Three
parameters are transferred to the C-Action. These are the Picture Name
(lpszPictureName), the Object Name (lpszObjectName) and the Property Name
(lpszPropertyName).
• Variable Declaration (1): In this first code section that can be edited, the variables
used are declared. In the sample code this is one variable of the long type.
• Value Computation (2): In this section, the computation of the property value is
performed. In the sample code, only the value of one WinCC tag is read in.
• Value Return (3): The computed property value is assigned to the property. This is
done via the return command.
C-Action at an Event
The sample code above represents a typical C-Action at an event. The meaning of the
individual sections is described below.
• Header (gray): The first three lines shaded gray form the header of the C-Action. This
header is generated automatically and cannot be changed. The function header differs
for the various types of events. The parameters lpszPictureName (Picture Name),
lpszObjectName (Object Name) and lpszPropertyName (Property Name) are transferred
to the C-Action. The lpszPropertyName parameter only contains relevant information
for events that react to the change of a property. Additional event-specific parameters
can be transferred.
• Variable Declaration (1): In this first code section that can be edited, the variables
used are declared. In the sample code this is one variable of the long type.
• Event Processing (2): In this section, the actions reacting to the corresponding event
are performed. In the sample code, the value of one WinCC tag is read in. This value is
assigned as position X to the own object. The return value of a C-Action at an event is
of the void type, i.e. no return value is expected.
Creation of a C-Action
The following table describes the individual steps required to create a C-Action.
6 Another aid is the function selection in the left window of the action editor.
Using the function selection, all available project functions, standard functions
and internal functions can be inserted automatically at the current cursor position
in the C-Action.
For this, the desired function is selected via a D. This will display the
Assigning Parameters dialog, which contains a list of all parameters that must be
fed and their data types. The function can be parameterized in the Value column.
In addition to the plain text input, the options Select Tag, Graphic Objects and
Pictures are available. To insert the function at the current cursor position in the
C-Action, confirm the dialog by clicking on OK.
The result of the compiling process is displayed in the lower left corner of the
action editor. This includes the number of errors found and the number of
warnings. Errors always cause a C-Action to be not executable. Warnings on the
other hand are notes pointing out possible errors that can occur during the
execution of the C-Action. Good programming style precludes the creation of C-
Actions with the output result other than 0 Error(s), 0 Warning(s).
If errors occur during the compiling process, they will be displayed in the output
window. Via a D on an error message in the output window, you can jump
directly to the corresponding code line.
8 For C-Actions that have been created at an object property, a trigger must be
defined. For C-Actions at events, this is not necessary since the event itself form
the trigger.
The definition of the trigger is carried out via the toolbar button displayed below.
You have the option to use time or tag triggers.
9 By clicking on the OK button of the action editor, the programmed C-Action will
be placed at the desired property or event. A property or event made dynamic
through a C-Action will be marked by a green arrow.
If a new C-Action is created, the automatically generated code will include two comment
blocks. These comment blocks are necessary to give the CrossReference editor access to
the internal information of a C-Action. They are also needed to enable the rewiring within a
C-Action.
• Variable Definition: The first comment block is used for the definition of the WinCC
tags used in the C-Action. This comment block begins with the line // WINCC:
TAGNAME_SECTION_START and ends with the line // WINCC:
TAGNAME_SECTION_END. In between these two lines, the names of all WinCC tags
used in the C-Action are defined. A definition takes place through the preprocessor
command #define followed by the defined name (in the sample code this is
S32I_COURSE_TEST_1) followed by the name of the WinCC tag (in the sample code
this is S32i_course_test_1).
• Picture Definition: The second comment block is used for the definition of the WinCC
pictures used in the C-Action. This comment block begins with the line // WINCC:
PICNAME_SECTION_START and ends with the line // WINCC:
PICNAME_SECTION_END. In between these two lines, the names of all WinCC
pictures used in the C-Action are defined. This follows the same convention as
described above for the definition of tag names.
• Application: In the actual program code, the defined values must be used instead of the
real tag and picture names. Before compiling the C-Action, the preprocessor will replace
all defined names with the real names.
Project Functions
If the same functionality is frequently required in C-Actions, this functionality can be
formulated in a project function. Project functions can be called in all C-Actions of a
WinCC project, in the same manner as all other functions. The following lists the
advantages of using project functions as opposed to creating the entire program code in C-
Actions:
• Central place for editing: A change of a project function affects all C-Actions in which
this function is being used. If no project functions are used, all concerned C-Actions
must be changed manually. This not only simplifies the configuration, but also
maintenance and troubleshooting.
• Reusability: Once a project function has been programmed and extensively tested, it
can be used again at any time without requiring additional configurations or new tests.
• Reduced Picture Volume: If not the entire program code is placed directly in the C-
Action at the object, the picture volume is reduced. This results in faster picture opening
times and a higher performance in runtime.
• Password Protection: Project functions can be protected against changes by assigning
a password. This protects the configuration data as well as your know-how.
Project functions are only available project-internal. They are stored in the
WinCCProjectFolder\LIBRARY folder and defined in the ap_pbib.h file located in the
same folder.
A number of standard functions are available. Contrary to the project functions, the
standard functions are available to all WinCC projects. Existing standard functions can be
changed. New standard functions can also be created.
Standard functions only differ from project functions with regard to their availability:
standard functions are available across projects, whereas project functions are only
available project-internal. Standard functions are stored in the
WinCCInstallationFolder\APLIB folder and defined in the ap_glob.h file located in the
same folder.
Internal Functions
In addition to the project functions and the standard functions, there are also internal
functions. Among others, these are standard C functions. They cannot be changed by the
user and new internal functions can also not be created.
Actions
Actions are - contrary to the previously described functions - not called from a C-Action or
other function. A trigger must be assigned to the action controlling its execution. It is
executed independently of the currently selected picture in runtime.
Actions can be configured globally, i.e. across projects. In this case, they are stored in the
WinCCProjectFolder\PAS folder. You can also configure local actions (computer-specific
actions), which will be stored in the WinCCProjectFolder\ComputerName\PAS folder.
If Global Script Runtime is checked in the startup list of the computer, all global actions
and all local actions belonging to the computer will activated upon project start.
The result of the compiling process is displayed in the output window. Errors
occurred and warnings will be listed and their quantity displayed. Via a D on
an error message in the output window, you can jump directly to the
corresponding code line.
6 Via the toolbar button displayed below, a description can be added to the project
function. Together with the description, a password can be defined to protect the
project function from unauthorized access.
3 The header of the action will be generated automatically and cannot be changed.
In addition, two comment blocks for the definition of the WinCC tags and
WinCC pictures are inserted.
The meaning of these two comment blocks has already been described in the
previous C-Actions section.
Test Output
The execution of a program can be followed through test outputs. This facilitates
troubleshooting and error diagnostics during development. Test outputs can be initiated via
the printf() functions. Through this function, simple texts, but also current tag values, can
be output. To make the output texts visible, a Global Script Diagnostics Window must be
configured.
The printf() function requires at least one parameter. This parameter is a character string.
The type and quantity of additional parameters to be transferred depends on this character
string.
The % character is used by the printf() function as an identifier that the value of a variable
is to be inserted at this position. The character following the % character determines the
data type of this variable. The character combination %d used in the sample above signals
the output of a decimal number. Additional possible combinations and their descriptions
can be found in the following table:
Parameter Description
%d Output of a decimal number (int or char)
%ld Output of a variable of the type long as a decimal number
%c Output of a character (char)
%x Output of a number in hexadecimal format (with lower case a...f)
%X Output of a number in hexadecimal format (with upper case A...F)
%o Output of a number in octal format
%u Output of a decimal number (only for unsigned types)
%f Output of a float value in floating point notation, e.g. 3.43234
%e Output of a float value in exponential notation, e.g. 23e+432
%E Like %e, but with upper case E, e.g. 23E+432
%s Output of a character string (char*)
%le Output of a double value
%% Output of a % character
\n Output of a line change (carriage return)
\r Output of a line feed
\t Output of a tab
\\ Output of a \ character
4.2 Variables
In the WinCC project Project_C_Course, samples pertaining to the topic variables can be
accessed by clicking on the navigation bar icon displayed below. The samples are
configured in the cc_9_example_00.PDL picture.
Variables
Variables are data objects manipulated by a program. A variable can only be used after it
has been defined. All variables used in a program must be defined before the first
instruction can be carried out.
Variables can be compared to a container. Through a variable name, we give the container a
unique name. The type of the content of the container is specified by its data type. The start
content of the container is specified by its initialization value. In most cases, this content
will be manipulated during program execution.
The variables described here should not be mistaken for WinCC tags. They are only
available within the program code.
A sample for the definition of a variable is illustrated by the following program code. In
this case, a variable of the int data type is defined with the name iNumber. The code line is
concluded with a semicolon. In front of the variable name is a prefix describing the data
type. This is not mandatory, but it makes the data type of the variable immediately
recognizable during program creation.
Constants
In addition to variables, a program also works with constants. This is simply the direct
application of a number value. To clarify the meaning of such a number value, a symbolic
constant can be defined for it using the #define command.
A sample for the definition of a symbolic constant is shown by the program code below. In
this case, the symbolic constant MAX_INT_VALUE is defined with the number value
2147483647. Note that the code line must not be concluded by a semicolon. It is a common
programming guideline that symbolic constants are written in upper case letters to easier
differentiate them from variables.
Data Types
C recognizes the basic data types listed in the table below.
A variable of the char data type has a memory requirement of one Byte. Its content can be
interpreted as a character or as a number.
The int data type can be preceded by the signed or unsigned keyword. The keyword signed
stands for a signed value, the keyword unsigned for an unsigned value.
The int data type can also be preceded by the long or short keywords. These keywords can
also be used without int - and still have the same meaning. A variable of the short (or short
int) data type has a memory requirement of 2 Bytes, a variable of the long (or long int) data
type has - just as the variable of the int data type - a memory requirement of 4 Bytes.
The double data type only differs from the float data type by its value range. Numbers can
be represented with greater accuracy by the double data type. A variable of the float data
type has a memory requirement of 4 Bytes, whereas a variable of the double data type has a
memory requirement of 8 Bytes.
C-Action at Button1
• The first three lines are the header of the C-Action. This header cannot be changed.
• In the next section, the variables are defined. One variable each of the char, long, short
and int data type and their unsigned counterparts are defined. The names of the
variables are preceded by a prefix describing the data type. This is not mandatory, but it
makes the data type of a variable immediately recognizable during program creation. As
the comment, each line includes the memory space required by the variable (comments
begin with the character string // are marked in green).
• In the next section, values are assigned to the variables. This is done using the
assignment operator =. The number values used in the sample exactly hit the limits of
the value ranges that can be displayed for the various data types.
• The number values are output in the diagnostics window through the function printf().
This output is displayed in the next section.
C-Action at Button2
• In the first section, the variables are defined. One variable each of the CHAR, SHORT,
LONG and INT defined data type and their unsigned counterparts BYTE, WORD,
DWORD and UINT are defined. In addition, a variable of the BOOL data type is
defined. Variables of the BOOL data type can be assigned the defined values TRUE or
FALSE. The names of the variables are preceded by a prefix describing the data type as
in the previous example.
• In the next section, values are assigned to the variables. The number values used in the
sample again exactly hit the limits of the value ranges that can be displayed for the
various data types.
• The number values are output in the diagnostics window through the function printf().
This output is displayed in the next section.
Type Definition
Data types used in this section have been assigned using the typedef command. The
following program code illustrates how the BYTE data type has been defined. BYTE is
simply the alias name for the default data type unsigned char available in C. You can also
define your own alias names.
The following table contains the defined data types pertaining to the default data types
available in C:
C-Action at Button3
• In the first section, the variables are defined. The data types of the variables were
selected according to the data types available for WinCC tags.
• In the next section, values are assigned to the variables. The number values used in the
sample again exactly hit the limits of the value ranges that can be displayed for the
various data types.
• The variable values are assigned to the various WinCC tags using the corresponding
functions. The function names consist of the text SetTag and the data type designation
of the WinCC tag to which the function is applied. Corresponding to the SetTag
functions for writing to WinCC tags, there are also GetTag functions for reading
WinCC tags.
• If a variable of the of the BOOL data type (alias name for int) is transferred to the
SetTagBit() function, the compiler will issue a warning. This is done, because the
SetTagBit() function expects SHORT as the data type of the transferred variable.
Therefore, the content of the bNumber variable is converted to SHORT in this sample
code before it is transferred to the SetTagBit() function. This process is also called
Typecast (type conversion).
Type Conversion
The content of a variable can be converted to a different data type before it is transferred to
a function or assigned to another variable. The data type of the variable itself remains
unchanged, however. The following program code illustrates how a variable of the float
data type can be converted to the int data type.
C-Action at Button4
• In the first section, the variables are defined. One variable each of the float and double
data type is defined.
• In the next section, values are assigned to the variables. In this sample, the same number
value is assigned to both variables.
• The accuracy of a variable of the float type goes approximately to the seventh decimal
place. A variable of the double type can display numbers twice as accurate. This can be
seen in the output of the number values - using the printf() function - in the diagnostics
window. In addition to the value of the variable, its memory requirement is also output.
The memory requirement of a variable is determined via the sizeof() command. The
memory requirement is indicated in Bytes.
C-Action at Button5
• In the first section, the variables are defined. One variable each of the float and double
data type is defined.
• In the next section, values are assigned to the variables. In this sample, the same number
value is again assigned to both variables.
• The variable values are assigned to the various WinCC tags using the corresponding
functions. Corresponding to the SetTag functions used here for writing to WinCC tags,
GetTag functions for reading WinCC tags are also available.
The sample has been configured at the Button6 object displayed below at Event
Mouse Mouse Action.
Static Variables
A C variable is valid in a function after its definition. It becomes invalid again after the
function terminates. If the function is called again, the C variable will be generated again.
However, if the keyword static precedes the variable, the variable will be maintained in
between two function calls. It will therefore keep its value. For C-Actions however, this is
only valid as long as the WinCC picture is selected. The static variables become invalid if
the picture is deselected. The static variable will be generated again after the picture is
opened again during the initial execution of the C-Action.
External Variables
A C variable can only be accessed within the function in which it has been defined.
However, if the variable is defined outside of any function, it becomes a global (external)
variable. This variable can then be declared in any function using the keyword extern and
be accessed.
• The CreateExternalTags() function only serves the purpose of defining and initializing
an external variable of the int type. At the start of the project, the function is called once
(at Events
• Miscellaneous
• Open Picture of the start picture cc_0_startpicture_00.PDL). From this time on, the
ext_iNumber variable is defined and can be used in any C-Action and any other
function.
C-Action at Button6
• In the first section, the external variable ext_iNumber is declared in order to be able to
use the variable in the C-Action.
• In the second section, the static variable stat_iNumber is defined and initialized. This
will be performed at the first execution of the C-Action after the WinCC picture has
been selected. For further executions of the C-Action, the value of the variable will be
maintained. If the picture is deselected and then selected again, the variable will be
generated again.
• The number values of the variables are incremented by one through the increment
operator ++ and output in the diagnostics window via the printf() function. The variable
ext_iNumber will therefore indicate the number of clicks on the button since the project
start and the variable stat_iNumber the number of clicks since the opening of the
picture. This output is displayed in the next section.
Operators
In a program, operators control what happens to variables and constants. Variables and
constants are connected to operators - this results in new variable values.
Operators can be divided into various categories. This includes mathematical operators, bit-
by-bit operators and assignment operators.
Mathematical Operators
Operator Description
+ (unary) Positive sign (actually has no effect)
- (unary) Negative sign
+ (binary) Addition
- (binary) Subtraction
* Multiplication
/ Division
% Modulo (returns the remainder of a division)
++ Increment
-- Decrement
Bit-by-Bit Operators
These operators make it possible to set, query or reset individual bits in variables.
Operator Description
& Bit-by-Bit AND
| Bit-by-Bit OR
^ Bit-by-Bit exclusive OR
~ Bit-by-Bit inversion
<< Move bits to the left
>> Move bits to the right
Logical Operators
All logical operators follow the same rule: 0 is FALSE, all other numbers are TRUE. These
operators either generate a 0 (FALSE) or a 1 (TRUE).
Operator Description
> Greater than
>= Greater than or equal to
== Equal to
!= Not equal to
<= Less than or equal to
< Less than
&& Logical AND
|| Logical OR
! Logical inversion
C-Action at Button1
• In the first section, two variables of the float data type are defined and initialized. The
mathematical operators are applied to these two variables.
• In the next section, four additional variables of the float data type are defined. These
variables store the results of the mathematical operations to be performed.
• In the next section, the mathematical operators are used to add, subtract, multiply and
divide.
• The results of these calculations are output through the printf() function in the
diagnostics window. This output is displayed in the next section.
C-Action at Button2
• In the first section, two variables of the int data type are defined and initialized.
• The increment operator in the prefix or postfix version are applied to these two
variables. The return values of these operators are output through the printf() function in
the diagnostics window. Afterwards, the variable contents are also output by the printf()
function in the diagnostics window. This output is displayed in the next section.
Description
In this sample, the bit-by-bit operators are applied to the content of two WinCC tags
(unsigned 16-Bit values). The result of the operation is stored in another WinCC tag of the
same type. The operator applied is controlled and simultaneously displayed by the Button6
object. The bit-by-bit connections AND, OR, NAND, NOR and EXOR are available. A
number value is assigned to each selection option, which is stored in another WinCC tag
(unsigned 8-Bit value).
C-Action at Button3
• In the first section, one variable of the BYTE data type and three variables of the
DWORD data type are defined. These variables are used to temporarily store the WinCC
tags.
• In the next section, the two WinCC tags to be connected are read into the dwValue1 and
dwValue2 variables. Additionally, the WinCC tag determining the type of the bit-by-bit
connection operator will be read into the byOperation variable.
• In the next section, the dwValue1 and dwValue2 variables are connected bit-by-bit
depending on the content of the byOperation variable. The connection result is stored in
the dwResult variable. The connection operation to be performed is selected by a switch-
case construction. This construction is described in greater detail in the Loops chapter.
• In the next section, the connection result contained in the dwResult variable is written to
the corresponding WinCC tag.
C-Action at Button4
• In the first section, a variable of the DWORD data type is defined. This variable is used
to temporarily store the WinCC tag. In addition, two help variables of the DWORD type
are defined.
• In the next section, the WinCC tag to be processed is written to the dwValue variable.
• In the next section, the individual bits of the dwValue variable are moved to the left by
eight positions (one byte) and stored in the dwtempValue1 variable. Afterwards, the
individual bits of the dwValue variable are moved to the right by eight positions and
stored in the dwtempValue2 variable. Both values determined in this section are
connected bit-by-bit (OR) and the result stored in the dwValue variable.
• In the next section, the rotated variable value contained in the dwValue variable is
written to the corresponding WinCC tag.
C-Action at Button5
4.4 Pointers
In the WinCC project Project_C_Course, samples pertaining to the topic pointers can be
accessed by clicking on the navigation bar icon displayed below. The samples are
configured in the cc_9_example_02.PDL picture.
The content of the pointer is not defined. It is still pointing to an invalid variable of the int
data type. To clarify this, a pointer should be initialized with the value NULL while it is
being defined. Before its application, the pointer can then be checked for validity.
To have the pointer point to a variable of the int data type, it must be assigned the address
of the variable. This is done via the unary operator , the so-called address operator. This
operator returns the address of the variable instead of its value. In the following program
code, the address of a variable with the int data type is assigned to the pointer.
The access to the value of the variable to which the pointer is pointing is realized via the
unary operator *, which is also called the content operator. In the following program code,
the value of the variable to which the pointer is pointing is assigned to a variable of the int
data type.
The individual elements of the vectors can be accessed via its index. In the following
program code, the content of the last vector element is accessed. This is done via the index
operator [ ].
The vector name can also be used as a pointer pointing to the first vector element. A certain
vector element can also be accessed by moving this pointer by a certain number of
elements. This is done as illustrated in the program code below by adding a int value to the
pointer. The content of the resulting pointer is accessed via the content operator *. As
shown previously, the last value of the vector is accessed.
Character Strings
Below, the internal display of both string variables is shown. In the first case, exactly as
much memory space has been reserved for the string variable as is needed for accepting the
string indicated for the initialization. In the second case, as much memory space has been
reserved as was specified during the definition of the vector.
S t r i n g 1 \0
S t r i n g 2 \0 ? ?
C-Action at Button1
• In the first section, two variables of the int data type are defined and initialized.
• Next, a pointer pointing to a variable of the int data type is defined and initialized with
NULL.
• Next, the address contained in the pointer is output via the printf() function. The
content, to which the pointer is currently pointing, is not defined. Accessing the content
of the pointer via the content operator * would cause a general access violation at this
time.
• Next, the address of the iValue1 variable is assigned to the pointer. Its address and
content is again output via the printf() function.
• Next, the address of the iValue2 variable is assigned to the pointer and the result output
again. The output of this program is displayed in the next section.
C-Action at Button2
• In the first section, a vector consisting of 5 variables of the int data type is defined. The
vector is already initialized with number values while it is being defined.
• Next, the iIndex counter variable of the int data type is defined.
• The individual elements of the vector are output via the printf() function. The access to
the individual elements is achieved in a for loop via the index operator [ ]. Dealing with
loops is described in the next chapter Loops. This output is displayed in the next section.
C-Action at Button3
• In the first section, a vector consisting of 5 variables of the int data type is defined. The
vector is already initialized with number values while it is being defined. In this case,
the size specification can also be omitted during while defining the vector.
• Next, the iIndex counter variable of the int data type is defined.
• Next, a piElement pointer is defined for a variable of the int data type and initialized
with NULL.
• Next, the address of the first vector element is assigned to the piElement pointer. This
address is output via the printf() function.
• Next, the individual elements of the vector are accessed by the piElement pointer. The
access is carried out in a for loop by advancing the pointer to the individual elements
and the content operator *.
• Next, the individual elements of the vector are accessed again. This time, however, the
name of the vector itself is used as the pointer. The output of the program is displayed
in the next section.
C-Action at Button4
• In the first section, a character string (vector consisting of 13 characters) is defined. This
length of the character string is one character more than the length of the assigned
initialization string to make room for the closing null character.
• Next, the i counter variable of the int data type is defined.
• Next, the individual characters of the character string are output via the printf()
function. The access to these characters is carried out in a for loop via the index
operator [ ].
• Next, the entire character string is output via the printf() function. The output of the
program is displayed in the next section.
C-Action at Button5
• In the first section, a character string (pointer pointing to the first character) is defined.
This string is initialized with NULL.
• Next, the content of a WinCC text tag is read in via the GetTagChar() function. The
function reserves the memory space required for the character string as returns its
starting address.
• Next, the entire character string is output via the printf() function. In addition, the length
of the character string is determined by the strlen() function and output together with the
starting address of the character string. The output of the program is displayed in the
next section.
Loops
Loops can be used to repeatedly perform a code section as long as a condition is satisfied.
In general, there are two types of loops: pre-check and post-check loops. The pre-check
loops check before the loop body, if this loop is to be performed. The post-check loops
check after the loop body, if this loop is to be performed. Therefore, post-check loops are
performed at least once.
The following types of loops can be differentiated.
while
A sample of a while loop is displayed below. The loop is repeated as long as the condition
is satisfied. In this sample, the loop is performed as long as the value of the i variable is less
than 5.
do - while
A sample of a do-while loop is displayed below. The loop is performed at least once and
then repeated as long as the condition is satisfied. In this sample, the loop is performed as
long as the value of the i variable is less than 5.
for
A sample of a for loop is displayed below. The loop is repeated as long as the condition is
satisfied. The initialization of the loop counter as well as the processing of the loop counter
can be formulated within the loop.
Conditional Statements
In loops, the body of the loop is processed for as long as a condition is true. In conditional
statements, a statement is processed exactly once if a condition is true.
if-else
If the condition is true, the statement in the if branch is processed. If the condition does not
apply, the alternative statement in the else branch will be processed. The else branch can
also be omitted, if no alternative statement is to be performed.
switch-case
In this case, a variable is checked for a match. Switch specifies the variable to be checked.
It is checked, which of the case branches agrees with the value of the variable. This case
branch is then performed. Any number of case branches can be defined. Each case branch
must end with a break. Optionally, a default branch can be inserted. This branch will be
performed, if the value of the variable to be checked agrees with none of the case branches.
C-Action at Button1
• In the first section, a iCount counter variable of the int data type is defined and
initialized.
• Next, the while loop is programmed. This loop will be executed as long as the content
of the iCount counter variable is less than 5. Each time the loop is performed, an output
is made by the printf() function. At the end of the loop, the iCount counter variable is
increased by one. The output of the program is displayed in the next section.
C-Action at Button2
• In the first section, a iCount counter variable of the int data type is defined and
initialized.
• Next, the do-while loop is programmed. This loop will be executed as long as the
content of the iCount counter variable is less than 5. However, the loop is performed at
least once, since this condition is only checked for after the loop has been performed.
Each time the loop is performed, an output is made by the printf() function. At the end
of the loop, the iCount counter variable is increased by one. The output of the program
is displayed in the next section.
C-Action at Button3
• In the first section, a iCount counter variable of the int data type is defined and
initialized.
• Next, a for loop is programmed. This loop will be executed as long as the content of the
iCount counter variable is less than 5. The initialization of the counter variable is
programmed directly in the call of the loop just as the action for incrementing the
counter variable. Each time the loop is performed, an output is made by the printf()
function. The output of the program is displayed in the next section.
C-Action at Button4
• In the first section, the symbolic constant MAX_COUNT is defined. This constant
represents the maximum number of executions for the following endless loop.
• In the next section, a iCount counter variable of the int data type is defined and
initialized.
• The current number of loop executions is to be displayed by a progress display. The
display consists of a bar, whose length contains the iProgressBar variable and a static
text, whose content contains the szProgressText string variable.
• Next, the endless loop is programmed. This loop could also be formulated using the
while (TRUE) statement.
• In the loop, the iCount counter variable is checked. If this variable exceeds the value of
MAX_COUNT, the loop is exited via the break statement.
• The iCount counter variable will be incremented.
• The progress display shows the loops already performed in percent. For every new
percent reached, the value of the progress display is set again. If no new percent has
been reached, the loop is immediately performed again via the continue statement and
the remaining lines skipped.
• The values of the progress display are set by setting the width of the ProgressBar bar
with the SetWidth() function and by setting the text of the ProgressText static text with
the SetText() function. The text used is configured with the sprintf() function. This
function follows the principle of printf(). The text, however, is not output by the Global
Script Diagnostics Window, but written to a string variable. This string variable must be
defined as the first parameter of the function.
C-Action at Button5
• In the first section, a byValue variable of the BYTE data type is defined. In this variable,
the content of a WinCC tag is stored.
• In the next section, the content of a WinCC tag is read into the byValue variable using
the GetTagByte() function.
• Next, a if-else statement is programmed. This statement makes - depending on the
content of the byValue variable - an output via the printf() function.
C-Action at Button6
• In the first section, a byValue variable of the BYTE data type is defined. In this variable,
the content of a WinCC tag is stored.
• In the next section, the content of a WinCC tag is read into the byValue variable using
the GetTagByte() function.
• Next, a switch-case statement is programmed. This statement makes - depending on the
content of the byValue variable - an output via the printf() function. To perform the
same statements for several different number values of the variable to be checked, the
corresponding case branches must be arranged among one another. The statements to be
performed are programmed in the last case branch.
4.6 Functions
In the WinCC project Project_C_Course, samples pertaining to the topic functions can be
accessed by clicking on the navigation bar icon displayed below. The samples are
configured in the cc_9_example_05.PDL picture.
Functions
Functions make it possible to better structure a program code. Instead of programming
often repeated statements over and over again, they can be shifted into a function. This also
results in a central location for editing the program code and easier maintenance.
In WinCC, functions can be created as project functions or standard functions.
Transfer Parameters
Values can be transferred to functions, depending on which the function executes
statements. These values can be transferred in various ways.
• A constant value can be transferred.
• A variable can be transferred. Only the value of the variable is transferred to the
function. The functions has no access to the variable itself.
• A pointer can be transferred. This gives the function access to the variable to which the
pointer is pointing. Vectors and structures can only be assigned to a function via
pointers.
Return Value
A function can simply execute statements without returning a value. In this case, the return
value is of the void data type. If, however, for example a calculation is performed, the value
determined can be returned to the caller of the function via the return value. In this case,
values or other addresses can be returned.
Another option to return values to the caller is to write to a transferred address area. Vectors
or structures can only be returned in this manner.
• In the function header, the name of the function is specified as MeanValue(). Three
variables of the double data type are transferred to the function. A variable also of the
double data type will be returned.
• Next, a variable of the double data type, in which the return value will be stored, is
defined. This return value is calculated by adding the three transferred values and
dividing the resulting sum by three.
• Via the return statement, the result is returned to the caller of the function.
C-Action at Button1
• In the first section, three variables of the double data type are defined and initialized.
The mean value of these three tags is to be calculated. An additional variable of the
double data type is defined which will store the result of the calculation.
• Using the previously created function MeanValue(), the mean value of the variables
transferred is calculated.
• The result of the calculation is output via the printf() function. This output is displayed
in the next section.
C-Action at Button2
• In the first section, a vector consisting of three variables of the double data type is
defined and initialized. The mean value of these three tags is to be calculated. An
additional variable of the double data type is defined which will store the result of the
calculation.
• Using the previously created function MeanValueVector(), the mean value of the
transferred vector elements is calculated.
• The result of the calculation is output via the printf() function. This output is displayed
in the next section.
• In the function header, the name of the function is specified as FillVector(). A pointer
pointing to a variable of the int data type is transferred to the function. This pointer
points to the first element of the vector expected. Additionally, the length of the vector
is transferred to the function. A variable of the BOOL data type is returned indicating
whether the function has been performed successfully or not.
• Next, a counter variable of the int data type is defined.
• Next, the transferred pointer is checked. The caller is responsible for the transfer of the
correct vector length. If an incorrect value is transferred, this might lead to a general
access violation.
• Using a for loop, the elements of the vector transferred are filled by the rand() function
with random numbers.
C-Action at Button3
• In the first section, a symbolic constant VECTOR_SIZE for the number of vector
elements is defined.
• Next, a vector iVector consisting of VECTOR_SIZE variables of the int data type is
defined.
• Next, a i counter variable of the int data type is defined.
• Using the previously created FillVector() function, the elements of the iVector vector
transferred are filled with random numbers. The return value of the FillVector()
function is checked while it is being called with the help of an if statement.
• The individual elements of the iVector vector are output via the printf() function. This
output is displayed in the next section.
• In the function header, the name of the function is specified as GetFilledVector(). The
number of elements of the vector created is transferred to the function. The pointer
pointing to the first vector element of the int* data type is returned.
• Next, a piVector pointer is defined for a variable of the int data type and initialized with
NULL.
• Next, a i counter variable of the int data type is defined.
• Sufficient memory space must be reserved for the vector. This is ensured by the internal
function SysMalloc(). To this function, the size of the desired memory block is
transferred which is calculated by multiplying the memory requirement of a variable of
the int data type by the desired number of vector elements. The function will return the
address of the reserved memory block or NULL, if the memory space available is
insufficient.
• Next, the address received from the SysMalloc() function will be checked. If not enough
memory space was available, the function is terminated and NULL returned.
• Using a for loop, the elements of the vector are filled by the rand() function with
random numbers.
• The address of the vector created is returned to the caller via the return statement.
C-Action at Button4
• In the first section, a symbolic constant VECTOR_SIZE for the number of vector
elements is defined.
• Next, a piVector pointer is defined for a variable of the int data type and initialized with
NULL.
• Next, a i counter variable of the int data type is defined.
• Using the previously created function GetFilledVector(), a vector filled with random
numbers is created, whose address is then stored in the piVector pointer. The return
value of the GetFilledVector() function is then checked for validity.
• The individual elements of the vector created are output via the printf() function. This
output is displayed in the next section.
Note:
The procedure for transferring structures to functions and the procedure for the return of
structures are described in the next chapter.
4.7 Structures
In the WinCC project Project_C_Course, samples pertaining to the topic structures can be
accessed by clicking on the navigation bar icon displayed below. The samples are
configured in the cc_9_example_04.PDL picture.
• In the first section, a CC_POINT structure type consisting of two int elements is
defined. The structure type will accept the coordinates of a mouse click.
• Next, a posObject structure variable of the struct CC_POINT data type is defined.
• Next, values are assigned to the elements of the posObject structure variable. The values
assigned are the coordinates of the mouse click. These coordinates are supplied by a C-
Action at Event
• Mouse
• Mouse Press Left as the x and y transfer parameters.
• Next, the coordinates of an object are set with the values contained in the structure
variable via the SetLeft() and SetTop() functions.
In this sample, the definition and application of a simple structure type is explained. As
opposed to the previous sample, this structure type will be available in the entire project
and not only for one C-Action. The sample has been configured at the Button2 object
displayed below at Event Mouse Mouse Action.
• A tagCC_RECT structure type consisting of four int elements is defined. The structure
type will accept the position and dimensions of a rectangular area. A variable of this
structure type must be defined as a variable of the struct tagCC_RECT data type. To
avoid this sometimes tedious notation, an alias name is defined using the typedef
statement. If you now want to define a variable of this data type, it is sufficient to use
the CC_RECT notation to specify the data type. If a pointer should point to a variable of
this data type, the notation PCC_RECT can be used.
C-Action at Button2
• In the first section, a rect variable of the CC_RECT data type is defined and initialized.
• Next, a prect variable of the PCC_RECT data type is defined and initialized with NULL.
This data type is a pointer pointing to a variable of the CC_RECT data type.
• Next, via the operator . , the elements of the rect structure variable are accessed. Its
content is output via the printf() function.
• Next, the address of the rect variable is assigned to the prect pointer. Next, via the
operator ->, the elements of the structure variable - to which the prect pointer is
pointing - are accesed. The content of the structure variable is again output via the
printf() function. The output of the program is displayed in the next section.
In this sample, the definition and application of a WinCC structure type is explained. Its
structure will be identical to the CC_RECT data type defined in the previous sample. The
sample has been configured at the Button3 object displayed below at Event Mouse
Mouse Action.
The name of the new structure type must be specified. This is done via a R on
the default name NewStructure and then selecting Rename from the pop-up
menu. This sample uses the name Rect.
C-Action at Button3
• In the first section, a rect variable of the CC_RECT data type is defined. The CC_RECT
data type has been defined in the previous sample.
• Next, the values contained in a WinCC structure tag are written to the elements of the
rect variable. In this sample, the values contained in the WinCC structure tag are
displayed via four I/O Fields and can also be edited in them.
• Next, the elements of the rect structure variable are output via the printf() function. The
output of the program is displayed in the next section.
The sample described in this section generates the following output in the diagnostics
window:
In this sample, a function for reading the WinCC structure type defined in the previous
sample is created. This function can then be used similarly like the internal GetTag
functions. The sample has been configured at the Button4 object displayed below at Event
Mouse Mouse Action.
• In the first section, the apdefap.h file is integrated, which contains the definition of the
tagCC_RECT structure type.
• In the function header, the name of the function is specified as GetTagRect. A string
variable is transferred to the function containing the name of the WinCC structure tag to
be read. A pointer pointing to a memory block of an undefined data type (void*) is
returned.
• In the next section, a prect variable of the PCC_RECT data type is defined and
initialized with NULL. This data type is a pointer pointing to a variable of the
CC_RECT data type.
• Next, a string variable for accepting the element names of the WinCC structure tag is
created.
• Next, enough memory space must be reserved to accept a variable of the CC_RECT
data type. This is ensured by the internal function SysMalloc(). The size of the desired
memory block, which can be determined via the sizeof() statement, is transferred to this
function. The function will return the address of the reserved memory block or NULL, if
the memory space available is insufficient.
• Next, the address received from the SysMalloc() function will be checked. If not enough
memory space was available, the function is terminated and NULL returned.
• Next, the names of each element of the WinCC structure tag are composed and the
content of the corresponding element read into the reserved memory area.
• The address of the reserved memory block, in which the content of the WinCC structure
tag has been stored, is returned. This memory block will remain reserved and keep its
data even after the function has bee exited.
Note:
If, instead of the procedure presented here, simply a local variable of the CC_RECT data
type had been created - whose elements contain the content of the WinCC structure tag and
returns its address - the caller of the function would receive an invalid pointer. This can be
explained by the fact that the variable of the CC_RECT data type would become invalid at
the end of the function and consequently an address of an invalid object would be returned.
C-Action at Button4
• In the first section, a prect variable of the PCC_RECT data type is defined and
initialized with NULL.
• Next, a WinCC structure tag is read via the previously created GetTagRect() function.
The GetTagRect() function returns a pointer pointing to the memory block containing
the desired data. This pointer is converted to a pointer of the PCC_RECT type.
• Next, the pointer received from the GetTagRect() function is checked. If not enough
memory space is available, the function will return the value NULL.
• Next, the names of each element of the WinCC structure tag are composed and the
content of the corresponding element read into the reserved memory area.
• The address of the reserved memory block, in which the content of the WinCC structure
tag has been stored, is returned. This memory block will remain reserved and keep its
data even after the function has bee exited.
• Next, the elements of the structure tag, to which prect is pointing, are output via the
printf() function. The output of the program is displayed in the next section.
Function Libraries
Each (major) application of WinCC (Graphics Designer, Tag Logging, Alarm Logging,
etc.) provides its own API, which is located in one or multiple DLLs. A DLL (Dynamic
Load Library) is a dynamically loaded function library. The declarations of the functions
contained in a DLL are provided in an associated header file.
The integration of a DLL into a C-Action or other function is shown in the following
program code sample. In the first line, the name of the DLL to be loaded is specified. In the
sample, this is the DLL which contains the CS functions of the Graphics Designers. In the
second line, the header file with the function declarations is integrated. If only one or two
functions are required, the declaration of the function can also be made directly at this
point. The closing line is formed by #pragma code(). In the above sample, the names of the
DLL and header files agree, which appears to make sense. This, however, is not always the
case.
Sample Project
In the sample project, no detailed description of every WinCC application API is provided.
However, the general principles of working with the WinCC API are explained, using the
Graphics Designers API as an example. The samples work with objects in the
cc_9_example_10x.PDL picture, especially configured for this purpose. It is displayed via a
Picture Window in the picture assigned to this chapter.
C-Action at Button1
• In the first section, a bRet variable of the BOOL data type is defined and initialized. This
variable will accept the return value of the API functions called.
• Next, two string variables are defined. Their content - the picture name and object name
- specifies the object to be edited. Make sure that the picture name does not include the
file extension PDL.
• To define the type of the properties to be set, a variable is created. For this, a separate
data type is available. This is the VARTYPE data type. For each existing property type, a
symbolic constant is defined. The properties to be set for this sample are of the VT_I4
data type (int with a length of 4 Bytes).
• For the Position X and Position Y properties to be set, a variable each of the int type is
defined, which includes the new value of the property.
• Next, a variable of the CMN_ERROR data type is defined. If a function call fails, this
structure will contain information about the error occurred.
• Via the PDLRTSetPropEx() API function, the Position X and Position Y properties of
the specified object are set. The first parameter of the API function denotes the
addressing mode of the object. The next three parameters denote the desired picture
name, object name and property name. To specify the desired property, the English
name, not the German one, must be used. For the previous example, these are Left and
Top. The next parameter denotes the property type. In the following parameter, the
address of the variable is specified, which contains the new value of the property. The
next four parameters are not relevant for the desired functionality. In the last parameter,
the address of the error structure is specified.
• The return value of every API function is checked in an if statement after it has been
called. If the call fails, this is indicated by an output. Part of this output includes the
information contained in the szErrorText structure element of the error structure.
Note:
In this sample, the return value of the API function is assigned to a variable of the BOOL
data type. This variable is then checked. The call of the API function and the check of the
return value can also be combined into one line. This procedure will be used in the
subsequent samples of this chapter.
C-Action at Button2
• In the first section, the trigger.h file is integrated. This file contains the definition of a
symbolic constant used in this sample.
• Next, two string variables are defined. Their content - the picture name and object name
- specifies the object to be edited.
• To specify the properties of a tag connection, a separate data type is available. This is
the LINKINFO structure type. A link variable of the LINKINO data type is defined.
• Next, a variable of the CMN_ERROR data type is defined.
• The structure elements of the link variable are filled with the information of the desired
tag connection. The LinkType element is assigned the BUBRT_LT_VARIABLE_DIRECT
symbolic constant. This constant stands for a direct tag connection. The dwCycle
element is assigned the value 0, which corresponds to the Upon Change trigger. The
szLinkName element specifies the variable to be used.
• Via the PDLRTSetLink() API function, a Tag Connection at the specified object is
created. The first parameter of the API function denotes the addressing mode of the
object. The next three parameters denote the desired picture name, object name and
property name. In the following parameter, the address of the link variable is specified,
which determines the tag connection to be created. The next two parameters are not
relevant for the desired functionality. In the last parameter, the address of the error
structure is specified. If the call of the API function fails, this is indicated by an output.
Note:
The first two samples of this chapter refer to the I/OField1 object of the
cc_9_example_10x.PDL picture. The first sample changes the position of the object in the
picture, the second creates a tag connection at it. After a picture change, the modifications
made are lost. Ensure that after the execution of the CS functions described in the
subsequent samples, a picture change must always be performed. This means that changes
in the picture achieved by using on of the first two button will be lost after clicking on one
of the other buttons.
C-Action at Button3
• In the first section, the DLL of the Graphics Designer API is loaded. In addition, the
pdl_guid.h file is integrated, which contains the definition of a symbolic constant used
in this sample.
• Next, a szProjectName string variable for accepting the project name is defined.
• Next, a string variable for accepting the picture name is defined. Note that the picture
name must include the file extension PDL (which differs from the RT functions).
• Next, the additional variables required are defined. This includes a variable of the GUID
data type, which determines the object type to be created.
• In the next section, the project name is determined via the DMGetRuntimeProject() API
function. The project name will be stored in the szProjectName variable. If the
determination of the project name fails, this will will be indicated by an output. In this
case, the C-Action is exited via the return statement.
• In the next section, the Graphics Designer API is initialized by the
PDLCSGetOleAppPtr() API function. If the initialization of the Graphics Designer API
fails, this will be indicated by an output. In this case, the C-Action is exited via the
return statement as well.
• In the next section, the picture to be edited is opened via the PDLCSOpenEx() API
function. As the next to last parameter, the dwFlags variable set to the value 1 is
transferred to the API function. This causes the picture not to be displayed on the
screen. If the opening of the picture fails, this will will be indicated by an output. Via
the goto statement, a jump is made to the code position where the connection to the
Graphics Designer API is terminated.
• In the next section, a new object named I/OField2 will be created via the
PDLCSNewObjectEx() API function. If the creation of the new object fails, this will
will be indicated by an output. Via the goto statement, a jump is made to the code
position where the previously opened picture is closed.
• In the next section, the picture is saved via the PDLCSSave() API function. If saving the
picture fails, this will will be indicated by an output. Via the goto statement, a jump is
made to the code position - just as in the section above - where the previously opened
picture is closed.
• Next, the picture to be edited is selected again via the project function
ActualizeObjects().
• Next, the previously opened picture is closed again via the PDLCSClose() API function.
Before this statement, a mark is inserted, which is the jump target for previous goto
statements.
• Next, the connection to the Graphics Designer API is terminated again via the
PDLCSDelOleAppPtr() API function. Before this statement, a mark is inserted as well,
which is the jump target for a previous goto statement.
Note:
The C-Actions, which will be created in the subsequent samples are very similar to the C-
Action created in the present sample. We will therefore omit detailed explanations, which
have been provided in the present sample. The code descriptions will be limited to an
overview of the program’s execution.
C-Action at Button4
• In the first section, the DLL of the Graphics Designer API is loaded.
• In the second section, the required variables are defined. The names of the properties
and the property values to be set are stored in vectors, as opposed to following the
procedure described in sample 1.
• The project name is determined via the DMGetRuntimeProject() API function.
• The Graphics Designer API is initialized by the PDLCSGetOleAppPtr() API function.
• The picture to be edited is opened via the PDLCSOpenEx() API function.
• Within a for loop, the properties of the object are set via the PDLCSSetPropertyEx()
API function. If properties of different types are to be set in this way, a vector must be
defined instead of the vt variable. This vector will determine the property type of each
property to be set.
• The picture is saved via the PDLCSSave() API function.
• The picture to be edited is selected again via the project function ActualizeObjects().
• The picture is closed again via the PDLCSClose() API function.
• The connection to the Graphics Designer API is terminated again via the
PDLCSDelOleAppPtr() API function.
C-Action at Button5
• In the first section, the DLL of the Graphics Designer API is loaded.
• In the second section, the required variables are defined.
• The project name is determined via the DMGetRuntimeProject() API function.
• The Graphics Designer API is initialized by the PDLCSGetOleAppPtr() API function.
• The picture to be edited is opened via the PDLCSOpenEx() API function.
• In the next section, the structure elements of the link variable are filled with the
information of the desired tag connection.
• The tag connection at the object is created via the PDLCSSetLink() function.
• The picture is saved via the PDLCSSave() API function.
• The picture to be edited is selected again via the project function ActualizeObjects().
• The picture is closed again via the PDLCSClose() API function.
• The connection to the Graphics Designer API is terminated again via the
PDLCSDelOleAppPtr() API function.
• In the first section, the pdlcsapi.h file is integrated, which contains the definition of the
OBJECT_INFO_STRUCT structure type.
• The data type of the return value as well as the data types and the quantity of transfer
parameters are specified for this function and can be obtained from the WinCC ODK.
• Next, a pointer pointing to a variable of the OBJECT_INFO_STRUCT data type is
defined. To this pointer, the address contained in the first transfer parameter is assigned.
The pointer is then checked for validity.
• The name of the object, whose OBJECT_INFO_STRUCT was received, will be output.
C-Action at Button6
• In the first section, the DLL of the Graphics Designer API is loaded.
• In the second section, the required variables are defined.
• The project name is determined via the DMGetRuntimeProject() API function.
• The Graphics Designer API is initialized by the PDLCSGetOleAppPtr() API function.
• The picture to be edited is opened via the PDLCSOpenEx() API function.
• All objects contained in the picture will be listed by the PDLCSEnumObjList() API
function. For this purpose, the address of the previously created ObjectCallback()
project function is transferred to the API function. This type of function is also know as
a Callback function. It will be called once for every object contained in the picture, at
which point the data of one object will be transferred.
• The picture is closed again via the PDLCSClose() API function.
• The connection to the Graphics Designer API is terminated again via the
PDLCSDelOleAppPtr() API function.
General Information
Many times the programming of a C-Action or other function requires the specification of a
file path, the name of the local computer and such. These values can then be specified -
according to the current conditions - as absolute values. This can cause problems if a
project is transferred to another computer. The conditions encountered there are in all
likelihood different from those of the creation system. It is therefore recommended to
refrain from using absolute path specifications and such when creating a project. Instead
such information should be determined while in runtime. This chapter contains samples,
which illustrate how information about conditions on the local computer are accessed. For
this purpose, the WinCC API as well as the Windows API are used.
C-Action at Button1
• In the first section, a bRet variable of the BOOL data type is defined.
• Next, a szProjectFile string variable for accepting the project name is defined. The
length of this tag is set to accommodate (store) the longest possible path specification.
• Next, a variable of the CMN_ERROR data type is defined.
• Next, the project name is determined via the DMGetRuntimeProject() API function. The
project name will be stored in the szProjectFile variable. As the second parameter, the
size of the memory space reserved for the project name is specified. As the third
parameter, the address of the error structure is specified. If no error information is
needed, NULL can be transferred.
• Next, the return value of the DMGetRuntimeProject() API function is checked.
• Next, the determined name of the project file is output. This output is displayed in the
next section.
C-Action at Button2
• In the first section, a bRet variable of the BOOL data type is defined and initialized.
• Next, a szProjectFile string variable for accepting the project name is defined. In
addition, a string variable is defined as char* and initialized with NULL.
• Next, a variable of the CMN_ERROR data type is defined.
• The project name is determined via the DMGetRuntimeProject() API function.
• Next, the return value of the DMGetRuntimeProject() API function is checked.
• Next, the strrchr() function searches for the last position of the \ character in the
determined name of the project file. One position after the found character, a 0 is
inserted. Only the path specification of the project file - without the name of the project
file itself - will remain.
• Next, the determined project path is output. This output is displayed in the next section.
The sample described in this section generates the following output in the diagnostics
window:
• A string variable is transferred to the project function, in which the determined project
path is written. The caller of the function must ensure that enough memory space has
been reserved for the string variable. If the function has been executed successfully can
be seen by its return value.
• The procedure for determining the project path follows the same principle shown in the
previous sample.
• The project path determined is copied to the transferred string variable via the strcpy()
function.
C-Action at Button3
• In the first section, a bRet variable of the BOOL data type is defined and initialized.
• Next, a szProjectPath string variable for accepting the project path is defined.
• Using the previously created GetProjectPath() project function, the project path is
determined. Afterwards, the return value of the project function is checked.
• Next, the determined project path is output.
C-Action at Button4
• In the first section, a szProjectFile string variable for accepting the name of the project
file is defined.
• Next, a dmDirInfo variable for accepting the path information is defined. This is a
variable of the DM_DIRECTORY_INFO structure type.
• Next, a variable of the CMN_ERROR data type is defined.
• Next, a char* string variable is defined and initialized with NULL.
• The project name is determined via the DMGetRuntimeProject() API function.
• Via the DMGetProjectDirectory() API function, the dmDirInfo variable is filled with
the path information. One of the paths contained in the variable is the path to the Global
Library folder. This path is stored in the szGlobalLibDir structure element. The Global
Library folder is a subfolder of the WinCC installation folder.
• With the first strrchr() function, the last \ character is searched for in the determined
path and replaced by a 0. With the second strrchr() function, the last \ character in the
remaining path is searched for. One position after, a 0 is inserted.
• Next, the determined installation folder is output. This output is displayed in the next
section.
C-Action at Button5
• In the first section, the Windows DLL Kernel32 is integrated. Since only one function
of the DLL is required, this function is declared directly. In addition, a symbolic
constant for the maximum length of the computer name is defined.
• Next, a bRet variable of the BOOL data type is defined and initialized.
• Next, a szComputerName string variable for accepting the computer name is defined. In
addition, a variable of the DWORD data type is defined, which is initialized with the
length of the previously defined string variable.
• The name of the local computer is determined by the GetComputerNameA() Windows
function. This name is written to the szComputerName string variable transferred.
• Next, the return value of the GetComputerNameA() Windows function is checked.
• Next, the determined computer name is output.
C-Action at Button6
• In the first section, the Windows DLL advapi32 integrated. Since only one function of
the DLL is required, this function is declared directly. In addition, a symbolic constant
for the maximum length of the user name is defined.
• Next, a bRet variable of the BOOL data type is defined and initialized.
• Next, a szUserName string variable for accepting the user name is defined. In addition,
a variable of the DWORD data type is defined, which is initialized with the length of the
previously defined string variable.
• Via the GetUserNameA() Windows function, the name of the user currently logged on
to Windows NT is determined. This name is written to the szUserName string variable
transferred.
• Next, the return value of the GetComputerNameA() Windows function is checked.
• Next, the determined user name is output.
• The Windows functions used in this sample are already known to the WinCC project.
Therefore no Windows DLL needs to be loaded.
• In the first section, a variable of the HWND type is defined and initialized with NULL.
This variable is a so-called window handle - a pointer pointing to a Windows window.
• Via the FindWindow() Windows function, the window handle of a Windows window
can be determined by specifying its window title. If the default title of the runtime
window is indicated, its window handle can be determined.
• Via the SetWindowText() Windows function, the title of the runtime window can be
changed. In this sample, the title is changed to WinCC C-Course.
• Via the SetWindowPos() Windows function, the position and dimensions of the runtime
window displayed on the screen can be specified. In this sample, the runtime window is
positioned at the top left corner (position 0/0) of the screen and is sized to 1024 by 768.
• The remaining statements of the above program code perform initializations that are not
relevant for this sample.
• In the first section, the Windows DLL Kernel32 is integrated. Since only one function
of the DLL is required, this function is declared directly.
• Next, the sysTime variable of the SYSTEMTIME data type is defined. This is a structure
type, which stores the system time.
• Next, a szTime string variable for accepting the current time in the hh:mm format
defined.
• Via the GetLocalTime() Windows function, the current system time is written to the
sysTime variable.
• Next, the current system time is set to the hh:mm format and returned as a return value
via the sprintf() function. At Property Miscellaneous Tooltip Text, another
C-Action following the steps described is created. This C-Action delivers the current
date.
• The function is executed in 1s cycles.
• In the first section, the apdefap.h file is integrated. With this, other project functions can
also be called from the present project function.
• The function header defines a string variable as the transfer parameter. With this
variable, the name of the sound file to be played is transferred.
• In the next section, the Windows DLL winmm is integrated. Since only one function of
the DLL is required, this function is declared directly. In addition, two symbolic
constants are defined.
• The project function assumes that a sound subfolder exists in the project folder. In this
folder, the sound files used in the project are stored. The path to the desired sound file is
composed of the project path, the name of the sound folder and the transferred name of
the sound file. It will be stored in the szSoundPath variable.
• The sound is played via the PlaySound() Windows function. If the sound file cannot be
played, a brief beep sound is generated instead by the MessageBeep() Windows
function.
• Via the standard function ProgramExecute(), the program calc.exe is started. This is the
Windows calculator program. No path needs to be specified, since this is not necessary
for programs located in the Windows folder.
General Information
The regular procedure for creating a dialog in WinCC consists of creating a WinCC picture
and then have this picture displayed using a Picture Window. There is also the possibility to
create standard dialogs in C-Actions or other functions. In this case, WinCC standard
dialogs as well as Windows dialogs can be used.
In this chapter, the application of some of the available standard dialogs is shown. There a
number of available standard dialogs that will not be mentioned here. Information about
these dialogs can be found in the WinCC ODK and the Windows API documentation.
C-Action at Button1
• In the first section, the variables used are defined. Among others, a vector consisting of
the IDs of the three desired languages is defined.
• Via the FindWindow() Windows function, the window handle of the runtime window is
determined using its window title. Note that the window title specified in this code
sample is not the default title of the runtime window.
• Via the DMShowLanguageDialog() API function, the standard dialog for the language
switch is displayed. A vector with the IDs of the languages to be displayed in the dialog
is transferred to this function. The function writes the ID of the language selected by the
user to the dwGetLocaleID variable transferred.
If the C-Action detailed above is executed, the following dialog will be displayed:
C-Action at Button2
• In the first section, the trigger.h file is integrated. This file contains the definition of a
symbolic constant used in this sample.
• In the next section, the variables used are defined. Among others, a dmVarKey variable
for accepting information about the WinCC tag selected in the dialog and a link variable
for accepting information about the tag connection are defined.
• The project name is determined via the DMGetRuntimeProject() API function.
• Via the FindWindow() Windows function, the window handle of the runtime window is
determined using its window title.
• Via the DMShowVarDatabase() API function, the tag selection dialog is opened.
Information about the WinCC tag selected in the dialog is stored in the dmVarName
variable transferred.
• If a tag has been selected, its name will be displayed in a Static Text field and its content
in an I/O Field.
C-Action at Button3
• In the first section, a hWnd variable of the HWND data type is defined. Via the
FindWindow() Windows function, the window handle of the runtime window is
assigned to this variable.
• Via the MessageBox() Windows function, an error box is opened. As the second
parameter, the error text and as the third parameter, the title of the error box are
specified. The fourth parameter specifies the appearance and behavior of the error box.
The error box only contains an OK button (MB_OK), displays the error symbol
(MB_ICONSTOP) and is modal (MB_APPLMODAL). In this way, the user must
acknowledge the error box first, before he or she can proceed.
• If a tag has been selected, its name will be displayed in a Static Text field and its content
in an I/O Field.
Error Box
If the C-Action detailed above is executed, the following error box will be displayed:
C-Action at Button4
• In the first section, a hWnd variable of the HWND data type is defined. In addition, a
iRet variable of the int type is defined.
• Via the FindWindow() Windows function, the window handle of the runtime window is
determined using its window title.
• Via the MessageBox() Windows function, a question box is opened. The fourth
parameter specifies the appearance and behavior of the question box. The question box
only contains a Yes and No button (MB_YESNO), displays a question mark
(MB_ICONQUESTION) and is modal (MB_APPLMODAL). The return value of the
function is stored in the iRet variable.
• In the last section, the return value of the function is analyzed. If the dialog was ended
with Yes, the return value is IDYES, if the dialog was ended with No, the return value is
IDNO.
Question Box
If the C-Action detailed above is executed, the following question box will be displayed:
C-Action at Button5
Additional Samples
The subsequent samples in this chapter deal - just like sample 5 - with the standard file
dialogs.
In sample 6, the Save As dialog is used.
In sample 7, the project function GetFileName() is created, which facilitates dealing with
the standard file dialogs. This function can, depending on the symbolic constant transferred,
display an Open or a Save As dialog. Symbolic constants available are GFN_OPEN and
GFN_SAVE.
4.12 Files
In the WinCC project Project_C_Course, samples pertaining to the topic Files can be
accessed by clicking on the navigation bar icon displayed below. The samples are
configured in the cc_9_example_13.PDL picture.
Open FiIe
In C, a file is viewed - independent of its content - as a collection of characters. Before a
file can be used in a C-Action or another function, it must be openend. If the work with a
file is complete, the file should be closed.
A file is opened using the fopen() function. In the program code displayed below, the
application of the fopen() function is shown.
In order to be able to work with the file, a pointer pointing to it must be defined. For this
purpose, the FILE* data type is available. The fopen() function returns a pointer pointing to
the opened file or NULL, if opening the file has failed. As the first parameter, the name of
the file to be opened with path specification must be transferred to the fopen() function. As
the second parameter, the mode with which the file is opened (e.g. for reading) is
transferred to the function. The values that can be specified for the mode are listed in the
table below.
Mode Description
r Opens a file for reading. The return value is NULL if the file does not exist or
there is no read authorization.
w Opens a file for writing. The return value is NULL if the file does not exist or
there is no write authorization.
a Opens a file for being attached to the end. If the file does not exist, it is created.
The return value is NULL if no file can be created or the file cannot be written to.
r+ Opens a file for being read and written to alternately. The return value is NULL if
the file does not exist or there are no read and write authorizations for the file.
w+ Creates a file for being read and written to alternately. If the file already exists, it
will be deleted. The return value is NULL if no rights for these actions are
available.
a+ Opens a file for being read or attached to the end. The file is created if it does not
exist. The return value is NULL if no read and write rights for the file are
available.
Close File
After completing the work with the file, the file should be closed. A file is closed using the
fclose() function. In the program code displayed below, the application of the fclose()
function is shown. The pointer pointing to the file to be closed is transferred to the function.
For reading a file, the fscanf() function is available. The fscanf() function is structured
identically to the fprintf() function. However, instead of specifying the variables whose
values are written to the file, the addresses of the variables are specified to which the
contents of the file are written to.
C-Action at Button1
• In the first section, the variables required are defined. Among others, a variable of the
FILE* type is defined and initialized.
• Via the project function GetProjectPath(), the project path is determined.
• Next, the path to the file to be created is compiled by the strcat() function. This path is
transferred to the fopen() function. With this function, the desired file is opened or
created.
• In the next section, the data to be written is read from the WinCC tags.
• Via the fprintf() function, the data is written to the file. Afterwards, the file is closed
again.
C-Action at Button2
• In the first section, the variables required are defined. Among others, a variable of the
FILE* type is defined and initialized.
• Via the project function GetProjectPath(), the project path is determined.
• Next, the path to the file to be opened is compiled by the strcat() function. This path is
transferred to the fopen() function. With this function, the desired file to be read is
opened.
• Via the fscanf() function, the data is read from the file. Afterwards, the file is closed
again.
• In the next section, the data read is written to the WinCC tags.
• A string variable is assigned to the function, which will be attached to the end of the
report file.
• In the first section, the variables required are defined. Among others, a variable of the
FILE* type is defined and initialized.
• Via the project function GetProjectPath(), the project path is determined.
• Next, the path to the file to be opened is compiled by the strcat() function. This path is
transferred to the fopen() function. With this function, the desired file to be attached is
opened.
• Via the fprintf() function, the report text transferred is entered into the file. Before each
report entry, the current system time is entered via the standard function
GetLocalTimeString(). Afterwards, the file is closed again.
C-Action at Button3
• In the C-Action, the content of a WinCC text tag is read and transferred to the
previously created project function LogText(). Consequently, the content of the WinCC
text tag is entered into the report file.
General Information
The Dynamic Wizard is available in the Graphics Designer as an additional function. It can
support the user with often repeated configuration processes. This reduces the configuration
efforts and decreases possible configuration errors.
The Dynamic Wizard is made up of various Dynamic Wizard functions. A large number of
Dynamic Wizard functions are already available. They can be complemented by used-
defined functions.
A Dynamic Wizard function consists of multiple pages that must be filled out by the user.
These pages include a start page, a trigger page, various option pages and a final page,
which summarizes the settings made in the previous pages.
Demo Wizard
In the Demo.wnf script file, a Dynamic Wizard named Demo Wizard has been created. This
Wizard displays basic functions which enable the user to enter data comfortably. However,
this Dynamic Wizard does not perform any actions.
Language-Dependent Definitions
If the Dynamic Wizard function is to be available in several languages, a separate script file
must be created for each language. Therefore, language-dependent texts should be defined
before the program code. Then, a script file created for a certain language can simply be
copied. Only the section with the language-dependent definitions must then be adapted.
Properties List
There is the option to specify, if a Dynamic Wizard function can only be used for certain
object types. This is done by specifying a list of object properties. If an object has one or
more of the properties listed, the Dynamic Wizard function can be used for this object. This
option has been applied to the Dynamic Wizard Making a Motor Dynamic to only make this
Wizard functional for customized objects of the Motor type. This object type only has the
properties Manual and Selection. If a blank properties list is used, a Dynamic Wizard
function can be applied to all object types. In any case, a properties list must exist, even if it
is blank.
Processing Function
The processing function is the function which performs the actual work of the Dynamic
Wizard function after the Finish button is pressed. The name of this function must be
specified in the system interface. An extensive processing function is presented in the
Dynamic Wizard Making a Motor Dynamic.
Info Function
The info function summarizes the settings made by the user and displays them in summary
form on the last page of the Dynamic Wizard function. The name of this function must be
specified in the system interface.
System Interface
Via the system interface, various properties of the new Dynamic Wizard function are
specified. The meaning of the individual parameters are explained following the code
sample.
• The first parameter specifies in which tab the Dynamic Wizard function is displayed.
• The second parameter specifies under which name the Dynamic Wizard function is
displayed.
• As the third parameter, NULL is always transferred.
• The fourth parameter contains the name of the icon used for the Dynamic Wizard
function.
• As the fifth parameter, a help text describing the functionality of the Dynamic Wizard
function in more detail can be transferred.
• As the sixth parameter, a list containing the names of the individual option pages of the
function created is specified. This list must conclude with a NULL entry. A maximum
of five option pages can be created.
• As the seventh parameter, the name of the processing function is specified, which is
called after the Finish button is pressed.
• As the eighth parameter, the name of the function is specified, which summarizes the
settings made in the option pages and displays them before the user presses the Finish
button.
• As the ninth parameter, a list of triggers to be displayed on the trigger page is specified.
For the most frequently occurring application cases, macros are available which will fill
out this trigger list.
Global Variables
For each parameter to be set in the option pages, a global variable must be defined. This
ensures that the parameters set are known to all functions created and can be worked with.
Option Pages
For each option page required, a separate function must be created. The names of these
functions must be specified in the system interface.
5 Appendix
The appendix contains a collection of topics that have not been incorporated directly in the
Configuration Manual.
Action at the Input Value event of an I/O field (tag Var1 is an unsigned 16-Bit value):
This, however, has the disadvantages that the action has to act on objects in the picture and
thus the object names have to be specified fixed in the action. The objects can no longer be
handled freely. This solution is not object-oriented.
There is an option to circumvent this problem:
• Define an internal tag (e.g. dummy) that is never updated or deliberately set. Set the
trigger of the action at the object to upon change of this tag. At the opening of the
picture in runtime, the action is activated once and would then only react again upon the
change of the dummy tag, which cannot happen since this tag never changes.
General Information
WinCC Scope is a tool that supports you with the diagnosis of WinCC projects. It provides
information about the activated project and the particular computer system. To work with
Scope, a Web Browser such as the Internet Explorer is required. Additionally, the network
protocol TCP/IP must be installed.
The following description for the access to the WinCC database refers to the application of
Microsoft® Excel 97 with SR-1.
In the Databases tab, the New Data Source entry is selected. With the OK button,
a new data source is created.
The following description for the access to the WinCC database refers to the application of
Microsoft® Access 97 with SR-1.
The newly created data source is selected in the Select Data Source dialog and
the dialog is closed with OK.
3 In the following Import Objects dialog displayed, the desired database tables can
be selected. By clicking on OK, they will be inserted into the Access database.
Direct access to the WinCC database is possible using ISQL. This, however, is performed
at your own risk, since the configuration data may become inconsistent as a result of editing
or deleting tables.
2 On the first page, a general description about the operation of WinCC Scope can
be accessed via the How to use the new Diagnostics Interface link.
Click on the link http://localhost to start Scope.
3 On the left side, various functions can be selected from the list.
• Via the Database entry, general information about the WinCC database is
displayed.
• Via the Database Query entry, individual tables of a database can be
displayed. The CS database of the currently opened WinCC project is preset
as the Data Source. The name of this data source starts with CC_ followed by
the project name. The name of the data source representing the runtime
database ends with the character R. Other data sources can also be displayed.
• Via the SQL Query entry, SQL statements can be applied to a selected data
source. However, it is recommended to edit the WinCC database with SQL
statements only if you have extensive knowledge about the system. Examples
of SQL statements can be found in the previous section Access to the
Database from ISQL.
The data export can also be activated from a WinCC runtime picture. For this purpose, it is
possible to start an interactive SQL with a command line via ProgramExcecute. The action
to be executed is stored in a command file (in this sample: archive.sql).
• The path variable contains the path to the ISQL.exe program with its call parameters.
• The parameters variable contains the entries for the database connection made in the
Interactive SQL Logon dialog. These are:
• UID (User ID): DBA
• PWD (Password): SQL
• DBN (Database Name): Name of the ODBC data source. The name of this data source
starts with CC_ followed by the project name and the date/time of the project creation.
The name of the data source representing the runtime database ends with the character
R. This name can be determined while the project is active from the Windows Control
Panel ODBC User DSN Tab.
• The action variable indicates that the SQL statements listed in the archive.sql file are to
be executed.
• The statements are summarized in ExportArchives and carried out with the
ProgramExecute() function.
Note:
If an export is to be performed from a database other than the two project databases, the
DBF parameter (the database file including the path to the database) should be specified
instead of the DBN parameter. However, this approach does not work for the currently
activated project database.
The previously described select command in the command file selects tables. Subsets of
these tables can be selected with additional parameters and then be exported using the
output command. Below are some examples pertaining to this topic.
CP525 Settings:
Message: Parameter CP525 Name: P3964R
Procedure: Component: RK Version: 01
Baud Rate: 9600 Character Length: 8
Number of Stop Bits: 1 Priority: Low
Parity: Even
In the PLC, SYNCHRONOUS is required in the startup circuit for the CP525 and
SEND/RECEIVE ALL in the cyclic program.
WinCC Settings:
For optimization purposes, one of the two partners should have the priority high, preferably
WinCC.
The software is used to ensure the sequenced acquisition of binary messages and to process
and buffer them. The program package provides the required software functionality within
SIMATIC S5 to implement the sequenced message acquisition function of the WinCC
system.
The principal operation of the software can be illustrated as follows: The software monitors
the binary signal status of the messages that the user makes available in a message interface
to the S5 alarm system. If a signal condition changes, the message is identified by its
message number and date/time stamped. A 32-Bit process tag and an alphanumeric
job/batch identifier are added to this data (if so configured by the user). The message block
configured in this manner is, if required, buffered in a FIFO buffer. Buffering message data
becomes necessary whenever more messages are issued per time unit than can be
transferred to the WinCC system using the present bus connection. This functionality
achieves a separation with respect to time between the sequenced message acquisition in
the SIMATIC S5 and the higher-level WinCC alarm system and makes real-time capable
message processing possible.
The message blocks generated by the S5 alarm system are made available to the S5
application program in a data block interface. By using S5 communication software, which
has to be implemented by the user, this data is transferred via a bus connection (e.g. SINEC
H1) to the higher-level WinCC alarm system. In WinCC, comprehensive message
processing functions, such as visualization, archiving, reporting, etc., are available.
The configuration of the S5 alarm system is carried out by the user through a data block
interface (System DB 80). At this point, the user determines the system requirements,
within which the alarm system is working. Specified here are the memory areas used by the
S5 alarm system, the type and scope of the messages to be processed and the allocation of
the assigned address areas.
This section describes the application and handling of the S5 alarm system in the SIMATIC
S5 environment. An overview of the function and data blocks used by the software as well
as the storage space required is provided. This is followed by an in-depth interface
description of all the existing data interfaces between the S5 alarm system and the S5
application program. To facilitate the start with the S5 alarm system, a configuration
sample is included.
The minimum storage space requirement depends on the configuration of the S5 alarm
system. The following data blocks are always required in addition.
For each offset or parameter data block, an additional 512 Bytes must be included.
The exact calculation of the size of the offset and parameter data blocks is shown in the
chapters Structure of the Offset Data Block and Structure of the Parameter Data Block.
PLC CPU
PLC 115U CPU 944 * , CPU 945
PLC 135U CPU 928B
PLC 155U CPU 946/ 947, CPU 948
Table 2
* Only the CPU 944 with two PG interfaces has a system clock.
These CPUs have an internal clock which allows them to provide the current date/time for
the generation of the message blocks.
For every WinCC channel set up, a current date/time message is cyclically written to the
SIMATIC S5 CPU. The internal clock of the SIMATIC S5 is synchronized with the system
clock of WinCC through the function block FB 86 : MESS:CLOCK.
Figure 1
Figure 2
Before the message acquisition system can monitor and acquire messages, the messages
have to be configured in the corresponding data blocks. There are four different message
categories:
For the alarm system, a date/time stamp can be specified globally for the message block
generation. If the date/time stamp is missing, the corresponding information is added to the
message blocks by the WinCC system.
The offset data block has the same structure for all four all message categories. The
corresponding data block address is specified for every required message category in the
system data block DB 80.
Offset data block for the corresponding message category:
DW Content Assignment
DW 0 Not assigned Header
DW 1 Basic Message Number
DW 2 Address of the last Signal Status Block
DW 3 Not assigned
Every message is assigned a certain message number by which it can be recognized from
the messages issued. The message number consists of the basic message number and an
offset message number.
A different basic message number has to be specified for every message category used.
Continuously from this basic message number, messages of this category are differentiated
through the offset message number.
The basic message number for the corresponding message category is specified in the DW
1 of the associated offset data block.
Special Case
If the message category 1 is being used, it is possible to use two offset data blocks. To
achieve a continuous message numbering for this message category, the basic message
number of the second offset data block has to be entered as the basic message number of
the first offset data block plus its message capacity (1008 messages).
Calculating the message number:
Message Number = Basic Message Number + Offset Message Number
Example:
Calculation: Description:
Given: Message category 1, continuous message numbering starting at:
message number 10000
Required: Basic message number of the two offset data blocks
10000 Basic message number of the first offset data block
10000 + 1008 = 11008 Basic message number of the second offset data block
The signal states of the messages are contained in the offset data blocks of the
corresponding message category at the respective bit position of the offset message number.
The offset message number of the corresponding message arises starting with the 16 Bits
(Bits 0-15) of DW 4. The continuous numbering is performed in increments of four (DW8,
DW12, etc.).
Signal Status Block Signal Status Block starts at Bit Number 0 - 15 corresponds
Data Word to the Offset Message Number
1 4 0 - 15
2 8 16 - 31
3 12 32 - 47
4 16 48 - 63
... ...
62 248 976 - 991
63 252 992 - 1007
Table 6
Calculating the DB, DW, Bit No. from the offset message number:
In the case of message category 1, the Length of a data word may be greater than 252. Then
the following applies:
Example 1:
Given: DW 248, Bit 7, Basic Message Number = 10000
Required: Message Number
Example 2:
Given: Message Category 1 with two Offset Data Blocks, Message Number = 12000, Basic
Message Number = 10000
The message number 12000 can be found in the second offset data block of Message
Category 1, Data Word 252, Bit No. 0.
The first signal status block starts at the data word address 4, the next signal status blocks
follow in intervals of 4 data words (DW 8, DW 12, etc.).
See also Table 5 or Table 6.
For each offset data block, 63 signal status blocks are possible (signal status blocks 1 to
63).
A signal status block contains 16 signal states. This results in 63 * 16 = 1008 possible
messages in an offset data block.
Additional information about these four bit states can be found in this chapter.
Calculating the corresponding signal status block:
Calculating the data word with which the corresponding signal status block starts:
First Data Word of the Signal Status Block = Signal Status Block * 4
By specifying the DW address of the last signal status block occupied with messages, the
number of possible messages of the corresponding message category is specified.
Calculating the last signal status block:
Last Signal Status Block = Required Messages of this Message Category / 16
With message category 1, a message volume of more than 1008 messages may occur, in
which case the following applies:
DW Address of the last Signal Status Block = Last Signal Status Block * 4
Example:
Given: 1030 Messages of Message Category 1
Position: 1st data word of the signal status block (refer to Table 5).
The user must ensure that the signal states of the corresponding messages are entered in the
data words provided by the offset data blocks of the corresponding message category. This
can be performed by the control program through continuous process-accompanying signal
updates.
Position: 2nd data word of the signal status block (refer to Table 5).
Under idle status of a signal we mean the signal level during the passive operating status. It
defines whether a signal (message) is active low or high. This information is required to
find out whether a message is coming in or going out.
If a change of event has the negated status with regard to the idle status, then a message is
coming in. In the case of a message going out, the status of the change of event is identical
to that of the associated idle status.
The idle states of the messages must be specified by the user at the corresponding positions.
Position: 3rd data word of the signal status block (refer to Table 5).
Acknowledgment bits are not configured but evaluated within the running program. Here,
the messages are acknowledged directly by the higher-level PC in accordance with the
corresponding acknowledgment philosophy. These message-related acknowledgments are
sent by the PC to the corresponding PLC together with the configured messages of the
integrated message acquisition system.
The corresponding acknowledgment bit is set one PLC cycle long by the S5 alarm system.
The application program has to evaluate this information accordingly.
Position: 4th data word of the signal status block (refer to Table 5).
The edge-triggered flags are used to determine change of events that may have occurred
(change of message). They are not configured but evaluated within the S5 alarm system.
Figure 3
Category Max. Number Size of the No. of Blocks per Max. No. of
Parameter Block Parameter DB Parameter DBs
1 1008 / 2016 - - -
2 1008 2 DWs 128 8
3 1008 5 DWs 51 20
4 1008 7 DWs 36 28
Table 8
When configuring, care must be taken to ensure that addresses do not overlap with the data
blocks of another message category and that the number of parameter data blocks can cope
with any future upgrades.
A parameter data block contains parameter blocks which are assigned to the different
messages. The parameter blocks are stored continuously in the parameter data block,
starting with the parameter block for the first message of that message category. The
parameter blocks are incremented continuously beyond the limits of the parameter DB.
Upon reaching the end of the parameter DB, the parameter block is continued with the next
number of the following parameter DB from DW 0 onwards. Only whole parameter blocks
are stored in the parameter data block.
Calculating the start address of a parameter block:
The user must ensure that the corresponding data (process tags, job number, batch
identifier) is available at the corresponding address.
A message block that is sent to the higher-level WinCC system consists of several
consecutive data words. The data words contain message-specific information. The sum of
the data words result in one message block. The size of the message blocks differs among
the individual message categories.
Regardless of the message category, a message block always consists of at least two data
words. These are the message number and the message status data words. Depending on
whether the messages are date/time stamped (3 data words) and have been furnished with
the appropriate parameters, a message block may be as long as 12 data words.
DW Description:
1st DW Message Number
2nd DW Message Status
3rd DW Time
4th DW Time
5th DW Date
6th DW Process Tag
7th DW Process Tag
8th DW Job Number
9th DW Job Number
10th DW Batch Identifier
11th DW Reserve
12th DW Reserve
Table 9
If messages are not date/time stamped, the three data words required for them at the
provided third to fifth position of the block are omitted. The parameter data words are then
attached without a gap to the status data word. The particular size of a message block
(number of DWs) differs depending on the message category and desired date/time stamp
and can be taken from table 10.
Determining the message block length as a function of the message category:
Every message is assigned a certain message number by which it can be clearly identified.
Table 11
The date and the time are made available by the function block FB 86 : MESS:CLOCK in
binary code.
Two data words by which process tags can be recorded and forwarded to the process
system, if a message comes in.
Depending on the configuration, the first two data words have to be interpreted either as a
signed 32-Bit binary number or as a total of four ASCII characters. The third data word has
to be interpreted as two ASCII characters.
Through these three data words, the current job number or batch identifier can be
transferred to the WinCC system, if a message comes in.
5.2.3.17 Reserve
The two reserve data words of the message category 4 are intended for future expansions,
but are currently not yet implemented in the WinCC system.
After a message has been detected, the currently checked Bit position is used to determine
the corresponding message number, which is stored as the first data word of the message
block in the FIFO buffer. Depending on whether the message is coming in or going out, the
category and the requirement for a date/time stamp, the corresponding status mask is
selected and stored as the second data word of the message block in the FIFO buffer. If the
parameters have been assigned to the corresponding Bit in the system data block for a
date/time stamp, the three data words that are available in system data block 80 - starting
from address DW 190 - will follow in the requested PC format. Depending on the message
category, the associated parameter block is read, if required, from the corresponding data
archive (parameter data block) and added to the last input in the FIFO buffer to complete
the message block.
Then, the next status Bit of the message that follows is examined. This is continued until all
messages to which parameters have been assigned have been processed.
A FIFO buffer is a type of storage that is shaped like a ring, i.e. the end of the storage ring
is followed by its beginning. This results in the storage being limited in size on the one
hand, but not being finite on the other due to its continuous restarting once the storage is
filled.
In the message acquisition system this means that the oldest data is going to be overwritten
by the most recent data once the virtual storage end is reached (buffer is full) - if the
previous data is not removed - therefore resulting in the information being lost.
The FIFO buffer in RAM acts, as its name suggests, as a buffer for the acquired messages
before they are forwarded to the PC. In RAM, the FIFO buffer consists of a memory area of
at least two data blocks and can, depending on the parameter assignment, be configured to
any size as long as it is within the maximum number of permissible data blocks in a PLC or
the remaining number available DBs of the application program. The user communicates to
the alarm system the number of data blocks available to it for archiving.
With more than one data block, it is imperative to use data blocks with continuous DB
numbers. Consequently, the user specifies the start DB number and the end DB number of
the buffer as parameters in the system DB. All data blocks whose values lie between the
start data block and the end data block (including the two data blocks themselves) belong to
the buffer as storage space.
5.2.3.20 The Send Mailbox - Data Transfer to the Higher-Level WinCC System
Generally, all message entries of a current cycle are written to the internal FIFO buffer of
the S5 alarm system at first.
The message entries (up to a maximum of the content of one data block) are transferred to
the message interface (send mailbox) upon the completion of the acquisition, providing the
send mailbox is ready. The message interface, in the form of a data block, acts as a data
source for the transfer function blocks (STEP 5 - data handling blocks). The data handling
blocks form an interface to the corresponding communication processor for the process bus
being used (e.g. for the SINEC-H1 bus).
DW Content
DW 0 Length of the Data Block
DW 1 KY = [ PLC No. ] , [ CPU No. ]
DW 2 KY = [ 0 ] , [ Number of Messages ]
DW 3 Start of the User Data (Message Blocks)
Table 12
DW 0:
Table 13
DW 0 of the send mailbox is determines first by the Bit number 14 - the activation edge
trigger of a requested job - and secondly by the Bit numbers 0 - 8 - the source data length.
Since the data block to be transferred can have a maximum length of 256 data words, but
one Byte can only represent a number up to 255, a separate query of the Bytes using the DL
or DR commands is not possible. It is therefore recommended to transfer the DW 0 be in an
auxiliary flag. This also has the advantage that the Enable Bit can be evaluated separately
and directly. This operation cannot be used for the application of data words.
If the condition is met, the Bit used as an edge for the one-time triggering of a send job
should be reset. The remaining set Bits then correspond to the transferred source data length
and can be written to the data area of the indirect parameter assignment as QLAE.
Following a successfully completed WRITE request (SINEC-H1) to the WinCC system
(free of faults (FOF)), the DW 0 of the send mailbox must be overwritten with the value 0.
This re-enables the send mailbox and additional message blocks, if present, can be
transferred from the internal FIFO buffer to the send mailbox.
The WRITE request (SINEC-H1) has to be implemented using the SEND direct function.
Information about this function can be found in the corresponding PLC manual.
By using the system data block DB 80, it is possible to configure independent data areas for
four message categories, a FIFO storage and a send mailbox. For the configuration, the data
words 0 to 20 in the DB 80 are provided.
The S5 alarm system evaluates the signal states of the corresponding messages and forms
the corresponding message blocks from them, if required.
The user has to ensure that...
• the individual messages are specified during configuration of the idles states.
• the message states are written to the corresponding Signal Status Bits during the runtime
of the S5 application program.
• the corresponding Acknowledgment Bits are read and evaluated, if required.
For the message categories 2 to 4, additional information about the current status of the
system can be transferred by the message block.
The user has to ensure that...
• upon the arrival of a message, the valid process tags (process value, job and batch
numbers) are located in the corresponding parameter blocks.
As soon as it contains message blocks, the send mailbox is transferred directly to the
WinCC system through a WRITE job (SINEC-H1).
The user has to ensure that...
• the corresponding data handling blocks of the respective CPU are available.
• appropriate communication channels for a process bus connection are specified during
the configuration of the WinCC system.
• a WRITE job is triggered.
DW Description
0 DB Address: internal FIFO start
1 DB Address: internal FIFO end
2 0: without date and time, 1: with date and time
3 DB offset for category 1 messages
4 1: one DB offset of category 1, 2: two DB offsets of category 1
5 DB offset for category 2 messages
6 DB offset for category 3 messages
7 DB offset for category 4 messages
8 Reserve
9 Reserve
10 DB Address: send mailbox CPU -> PC
11 1: acquisition optimized (ACOP)
12 ACOP starting from n messages
13 PLC type (115/135/155)
14 Reserve (must be 1)
15 PLC No.: 1 to 255; CPU No.: 1 to 4
16 Reserve
17 Reserve
18 Reserve
19 Reserve
20 Parity error of the plausibility check
Table 14
See Table 10
For ACOP operation of the message acquisition system, it is recommended to add one or
two more data blocks.
DW 2: Date and Time Identifier
The option of date/time stamping messages refers to all parameterized messages. Either all
the messages which have to be acquired are date/time stamped (DW2 = 1) or none (DW2 =
0). If DW2 = 0 is set, the WinCC system adds a date/time stamp to message blocks coming
in.
DW 3, DW 4: Offset DB of the Message Category 1
If category 1 messages (messages without parameters and batch identifier) have to be to
configured, the address of the offset data block has to be specified in data word 3. The
signal states of these messages have to be written continuously by the control program into
the data blocks specified.
If more than 1008 messages (not more than 2016 messages) of category 1 are planned, an
additional data block is enabled for category 1 messages by entering 2 in the data word 4.
The second data block automatically receives the next higher address in relation to the
address in DW 3. If a maximum of 1008 category 1 messages suffices, a 1 is entered in DW
4.
DW 5, DW 6, DW 7: Offset DB of the Message Categories 2, 3, 4
Similar to DW 3, data words 5 - 7 contain the data block addresses where the signals of the
messages are stored.
DW 5 contains the address of the data block for message category 2, whereas DWs 6 and 7
contain the addresses for the message categories 3 and 4, respectively.
If a message category is not used, a 0 has to be entered in the corresponding DW.
The addresses specified in DWs 5 - 7 are so-called offset DBs. Depending on the message
category and the number of messages per category, they are assigned a corresponding
number of secondary DBs. The secondary DBs contain the parameters of the messages. For
this reason, it must be ensured that - when assigning the offset DB addresses - there is
sufficient space (data blocks) allocated for the parameter DBs between the previous offset
DB and the one to be specified.
Up to 1008 messages can be configured for message categories 2 to 4. When fully utilized,
a different number of secondary DBs (parameter DBs) to offset DBs arises for the different
categories (see Table 8).
DW 10: Message Interface to the Higher-Level WinCC System
Parameters must always be assigned to the data word 10 - the operating mode used by the
message acquisition system has no bearing on this. The DB address of the transfer mailbox
is assigned in DW 10. The transfer mailbox acts as an interface between the SIMATIC S5
and the higher-level WinCC system.
DW 11, DW 12: Mode Selection for optimum Acquisition and corresponding Number of
Messages
Two operating modes are available:
• 0 in DW 11 -> Normal mode of the message acquisition system
• 1 in DW 11 -> optimum acquisition mode of the message acquisition system
Normal Mode:
All messages that have been acquired and stored in the internal buffer within a cycle are
sent to the WinCC station by the message interface (which has a limited capacity), provided
that the message interface is ready to accept data.
This course of action results in a relatively long cycle time if a large number of messages
come in within a cycle or within several consecutive cycles. The cycle time also increases
with the message block size of the message categories involved. In this case, the acquisition
of the message blocks involves more effort and takes longer.
Optimized Acquisition:
The chronological acquisition of the messages issued has priority over the sending to the
WinCC station. Attention is focused on the relative time between the issuance of the system
messages. The fact that messages might be displayed on the WinCC station a few
milliseconds later is of secondary importance. The sluggishness of the human eye and the
receptiveness of the observer in the control room are decisive factors.
In order to reduce the cycle time of the message acquisition system in such time-critical
cases, the option of running the system in the optimized acquisition mode has been
introduced. The minimum number of messages issued within an OB1 cycle is specified in
DW 12. If the number of messages exceeds this minimum number during the current OB1
cycle, the messages are only acquired and buffered. They are not paged out or subsequently
sent to a communication partner in this OB1 cycle.
DW 15: PLC/CPU Number
This data word is required for generating the message header and needs the specification of
the project-related PLC number and its CPU number. The CPU number is particularly
important if several CPUs are operating within a single PLC. Only in conjunction with the
data word containing the ID for the messages can the higher-level WinCC system interpret
sent data as a message, assign message-specific message texts and evaluate them
accordingly.
The DW 15 is the only data word to receive the S5 data format KY during the
configuration, i.e. two Bytes can be represented separately (separated by a comma). The left
Byte contains the PLC number, which may be between 1 and 255. In the right Byte, the
CPU number is specified, which may be between 1 and 4.
Example:
KY = 10,2
PLC Number = 10
CPU Number = 2
DW 20: Parameter Assignment Errors
All data words parameterized in the system DB are checked for their plausibility at the
startup of the S5 alarm system. In this case, distinctions are made between exceeding
possible value ranges, overlappings or multiple assignment of parameterized data blocks
and missing specifications.
As the output parameter in the format of a data word, this function block uses a so-called
PAFE word (Parameter Error word); it is similar to the system-specific data handling
blocks. The status of the PAFE word can be taken from DW 20 in the system DB 80. The
PAFE word can be examined for errors which may have occurred after the program return
from FB 81. Following that, appropriate actions can be taken.
It is recommended to have the PLC jump to the stop status in the event of a PAFE word
other than zero. If the PAFE word is ignored, no guarantee can be given for an error-free
execution of the program.
Evaluation of the PAFE Word
If the program or PLC is brought to its stop status - as recommended - following the
occurrence of an error (PAFE word unequal to 0), the error can be analyzed and corrected
specifically by means of the error number. The following table provides information about
the type of error caused during the parameterization.
Example:
KY = 9,1
Description
The S5 alarm system is to be configured for the following message categories:
5.2.6.1 DB 80 Parameterization
Category Max. Number Size of the No. of Blocks per Max. No. of
Parameter Block Parameter DB Parameter DBs
1 1008 / 2016 - - -
2 1008 2 DWs 128 8
3 1008 5 DWs 51 20
4 1008 7 DWs 36 28
This results in four data blocks for the FIFO buffer, since one or two more data blocks have
to be added for the optimized acquisition mode.
The FIFO buffer starts at the data block address 82, which results in an end address of DB
85 for the FIFO buffer.
To provide a reserve for any future expansions of the FIFO buffer, the offset data block of
category 1 is in DB 88 and DB 89 (for more than 1008 category 1 messages).
The DB 90 becomes the offset data block of the message category 3. A parameter DB of
the message category 3 can accommodate up to 51 parameter blocks; if the 11 blocks used
are subtracted, this results in an expandability by 40 category 3 messages with only one
parameter data block (DB 91).
DW Description Value
0 DB Address: internal FIFO start 82
1 DB Address: internal FIFO end 85
2 0: without date and time 1
1: with date and time
3 DB offset for category 1 messages 88
4 1: one DB offset of category 1 2
2: two DB offsets of category 1
5 DB offset for category 2 messages 0
6 DB offset for category 3 messages 90
7 DB offset for category 4 messages 0
8 Reserve 0
9 Reserve 0
10 DB Address: send mailbox CPU -> PC 81
11 1: acquisition optimized (ACOP) 1
12 ACOP starting from n messages 30
13 PLC type (115/135/155) 135
14 Reserve 1
15 PLC No.: 1 to 255; CPU No.: 1 to 4 1, 1
16 Reserve 0
17 Reserve 0
18 Reserve 0
19 Reserve 0
20 Parity error of the plausibility check 0
Message Category 1
DB 88 and DB 89 are provided for the message category 1. The DB 88 contains the
messages numbered 10000 to 11007 and the DB 89 the messages numbered 11008 to
11199.
A total of 1200 category 1 messages are to be configured.
See the chapter Address of the last Signal Status Block
Offset Message Number = Message Number - Basic Message Number = 0 to 1199
192 / 16 = 12
192 % 16 = 0
DB 88:
DW Description Value
DW 0 Not assigned
DW 1 Basic Message Number 10000
DW 2 Address of last DW 252
DW 3 Not assigned
DB 89:
DW Description Value
DW 0 Not assigned
DW 1 Basic Message Number 11018
DW 2 Address of last DW 48
DW 3 Not assigned
DB 88:
DW 253: set data Bits 8 through 15 to 1
DB 89:
DW 5, DW 9, DW 13 through DW 49: set data bits 0 through 15 to 1
Message Category 3
For the message category 3, DB 90 is provided as the offset data block with the messages
30000 to 30010 and DB 91 as the parameter data block.
A total of 11 category 3 messages are to be configured.
See the chapter Structure of the Parameter Data Block
Offset Message Number = Message Number - Basic Message Number = 0 to 10
Offset DB:
Address of the last signal status 11 / 16 = 0
block 11 % 16 = 11
Address of the last signal status = (0+1) * 4 = 4
block
DB 89:
DW Description Value
DW 0 Not assigned
DW 1 Basic Message Number 30000
DW 2 Address of last DW 4
DW 3 Not assigned
Parameter DB
The program package provides the required software functionality within the SIMATIC S5
to implement the following operations of the WinCC system via the given process bus:
The desired changes in the SIMATIC S5 are made available by the WinCC Control Center
as a raw data tag via a data interface. The commands have to be sent to the S5 via this raw
data tag. These commands are evaluated and executed directly in the S5 through the
command interpreter FB 87 : EXECUTE.
This manual describes the application and handling of the S5 command blocks in the
SIMATIC S5 environment. The user receives an overview of the function and data blocks
used by the software, and the storage space required. This is followed by a detailed
interface description of the existing data interface. A configuration sample is presented to
provide additional help.
The S5 Command Blocks of the SIMATIC S5 software are located on the WinCC CD-
ROM in the file named WINCC1ST.S5D.
This file contains the following function blocks for the S5 command blocks:
FB Name Size in Bytes Function
FB 87 EXECUTE 152 Enables Bit, Byte, word and double word
manipulation via the process bus
FB 88 OPCODE 399 Called by FB 87
Total 551
Table 16
The function blocks specified in table 16 require the following hardware in order to be
executed correctly:
PLC CPU
PLC 115U CPU 943, CPU 944, CPU 945
PLC 135U CPU 928A, CPU 928B
PLC 155U CPU 946/947, CPU 948
The following describes the call parameters of the function block FB 87: EXECUTE.
In the SIMATIC S5, the command interpreter (FB 87: EXECUTE) is called cyclically in
the OB 1. The type and address of the command DB are transferred as parameters. When a
command is pending, the Op code and four parameters are forwarded to the FB 88:
OPCODE and executed directly. After a command has been executed, the command
counter (DW 1) is decremented by one. The process of transferring the command and
decrementing the command counter is repeated until all pending commands have been
processed.
Details about the type and address of the data block have to agree in both the WinCC
Control Center and the S5 program, and the data block has to be present in the S5.
Available for selection is a DB or DX data block and its address (e.g. DX 234). The data
block has to be opened by the user up to data word 255, since the data words 0 - 255 can be
addressed in the data block specified.
The following syntax has been defined for commands stored in the command data block:
DW Description
0 Not used
1 Number of commands to be executed
2 Op code of the first command
3 Parameter 1 (Op code 1)
4 Parameter 2 (Op code 1)
5 Parameter 3 (Op code 1)
6 Parameter 4 (Op code 1)
7 Op code of the second command
8 Parameter 1 (Op code 2)
9 Parameter 1 (Op code 2)
10 Parameter 2 (Op code 2)
11 Parameter 3 (Op code 2)
12 Parameter 4 (Op code 2)
13 Op code of the third command
14 Parameter 1 (Op code 3)
......
Excerpt from OB 1:
S5 Time Synchronization
The software is used to synchronize the SIMATIC S5 system clock. In addition, it supplies
the proper date/time data format for the generation of the message blocks to the
chronological message acquisition of the S5 alarm system.
The function block FB 86: MESS:CLOCK also provides the current S5 time in a format
required by the chronological message acquisition. The data is located in the system data
block 80 from DW 190 onward.
If a change in a message signal status occurs, the message is identified by the function
block FB 80: SYSTEMFB via its message number and stamped with the current date/time
from system data block 80.
This manual describes in detail the application and handling of the S5 time synchronization
in the SIMATIC S5 environment. The user receives an overview of the function and data
blocks used by the software, and the storage space required. A configuration sample is
presented to provide additional help.
The SIMATIC S5 software (S5 time synchronization) is located on the WinCC CD-ROM
in the file named WINCC1ST.S5D.
The function blocks specified for the S5 alarm system require the following
hardware in order to be executed correctly:
PLC CPU
PLC 115U CPU 944 *, CPU 945
PLC 135U CPU 928B
PLC 155U CPU 946/947, CPU 948
* Only the CPU 944 with two PG interfaces has a system clock.
CPUT:
No. of the CPU Type
1 CPU 943 / CPU 944
2 CPU 945
3 CPU 928B
4 CPU 946 / 947
5 CPU 948
DCF7:
Operating mode
0 = operation with S5 system clock
1 = operation with DCF77 radio clock
QTYPE:
Type of data source for the time synchronization message
0 = data source is a data block (DB)
1 = data source is an extended data block (DX)
QSYN:
Data source of the time data
UDAT:
Address of the clock data area
UDAT = DB number, DW number
ZINT:
Time interval in minutes for the sending of the synchronization message (DCF7 = 1)
ZCLOCK:
Target data area for the time data in the alarm system format
ZCLOCK = DB number, DW number
ZSYN:
Target data area for the time synchronization message (DCF7 = 1)
If the chronological message acquisition functionality is to be used with the S5 alarm
system, a special time data format is expected in DB 80 from DW 190 onward.
This time data format is derived from the S5 system time and is written to the
corresponding ZCLOCK data area (DB 80, DW 190 - 192).
Relationship between chronological reporting and FB 86: MESS:CLOCK:
Figure 4
The data word numbers are relative specifications. The actual position of the area is
determined by the call parameters: UDAT = DB No., DW No. of FB 86: MESS:CLOCK.
Table 19
Current time in the clock data area:
DW Word/Left Word/Right
4 --- Day of Week
6 Day Month
7 Year AM/PM (Bit, No. 7), Hour
8 Minute Second
Figure 5
DW Word/Left Word/Right
9 Leap Year Day of Week
10 Day Month
11 Year AM/PM (Bit, No. 7), Hour
12 Minute Second
Figure 6
The data word numbers are relative specifications. The actual position of the area is
determined by the call parameters: UDAT = DB No., DW No. of FB 86: MESS:CLOCK.
Figure 7
DW Word/Left Word/Right
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
4 Seconds 0
5 Format Hours Minutes
6 Day of Month Day of Week 0
7 Year Second
Figure 8
DW Word/Left Word/Right
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
8 Seconds 0
9 Format Hours Minuten
10 Day of Month Day of Week 0
Figure 9
The data word numbers are relative specifications. The actual position of the area is
determined by the call parameters: UDAT = DB No., DW No. of FB 86: MESS:CLOCK.
Figure 10
DW Word/Left Word/Right
4 10 sec. 1 sec. 1/10 sec. 1/100 sec.
6 10 h 1h 10 min. 1 min.
7 10 Days 1 Day Day of Week 0
8 10 Years 1 Year 10 Months 1 Month
Figure 11
DW Word/Left Word/Right
9 10 sec. 1 sec. 1/10 sec. 1/100 sec.
10 10 h 1h 10 min. 1 min.
11 10 Days 1 Day Day of Week 0
12 10 Years 1 Year 10 Months 1 Month
Figure 12
The data word numbers are relative specifications. The actual position of the area is
determined by the parameters ZCLOCK = DB No., DW No. of FB 86: MESS:CLOCK.
If the chronological message acquisition functionality is to be used with the S5 alarm
system, the data DB 80, DW 190 has to be entered into the parameter ZCLOCK.
The date and time are made available in binary code by the function block FB 86:
MESS:CLOCK for the message processing:
Current time in the setting area:
DW3: Time
DW4: Time
DW4: Date
Figure 14
Configuration Sample
Let us assume a CPU 944 with two PG interfaces. On this CPU, the S5 time
synchronization for the S5 alarm system without the DCF77 clock is to be set up.
Data Areas:
During the configuration of the channel parameters (e.g. Industrial Ethernet) in the system,
the desired data block (DB 100, DW20 - DW 30) must be entered for the time
synchronization entry.
Ensure that DB 80 of DW 0 to DW 255 and DB 100 of DW 0 to DW 47 are opened.
Excerpt from OB 1:
Basic Process
The S7PMC format DLL is a passive group of programs, which exclusively has interfaces
to the Alarm Logging and Tag Logging applications. The S7PMC format DLL processes
S7PMC-specific functions for Alarm Logging and Tag Logging.
Alarm Logging and Tag Logging log on to the format DLL using a start call. In this case,
certain parameters are transferred in a start structure to the format DLL and their properties
are received via IDs.
Two data transfer directions are required to process the S7PMC functions in runtime:
• OS to PLC: (sending of logon/logoff jobs, acknowledgments)
• PLC to OS: (receipt of messages and archive data)
Alarm Logging and Tag Logging log on to the relevant format DLL via the call
NormDLLStart. It is intended for the exchange of information between the format DLL and
the application.
NormDLLStart
Parameter Description
lpUser Pointer pointing to the application data, forwarded unchanged to
callback
bModeRuntime TRUE if the format DLL is started in runtime mode, FALSE if it is
started in configuration mode; is currently not evaluated by the format
DLL
pcis Pointer pointing to the start structure
lpError Pointer pointing to the default WinCC error structure
Return Description
TRUE No error
FALSE Error in the API function, description of the error cause via the pointer
lpError
NORM_STARTSTRUCT
The callback function for sending raw data tags to the WinCC Data Manager is supplied as
follows:
Parameter Description
lpDmVarUpdate Pointer pointing to the raw data tag
dwWait Identification of whether the application should wait until
completion of the write call or not:
WAIT_ID_NO with SET_VALUE
WAIT_ID_YES with SET_VALUE_WAIT
lpUser Pointer pointing to the application data, noted upon the call
NormDLLStart
lpError Pointer pointing to the default WinCC error structure
Return Description
TRUE No error
FALSE Error in the API function, description of the error cause via the
pointer lpError
NormGetDLLName
Return Description
LPTSTR Pointer pointing to a string, which contains the name of the format DLL in
plain text; the name depends on the current language setting.
Tag Logging and Alarm Logging notify the format DLL, if the applications are being
closed. The resources are then returned properly in the format DLL.
NormDLLStop
Return Description
TRUE Function successful
FALSE Error in the API function
Certain specifications are required for the S7PMC objects. These specifications are first
requested in a dialog using standard means (without MFC) and go directly into either the
WinCC message number or the name of the archive tag. This means that the format DLL
does not have to store and manage these specifications itself. To guarantee the project-wide
uniqueness of a message number or archive tag, an assignment between the message
number or archive tag and the associated raw data tag is necessary. This assignment
information is an integral part of the message number or archive tag name.
The format DLL has an API function for defining the S7PMC-specific message number.
This function is called by the CS alarm system while assigning parameters to single
messages belonging to a S7PMC format DLL. The message number assigned by the
S7PMC format DLL is a number consisting of two parts.
Part 1:
The number which uniquely identifies a PLC CPU project-wide (raw data tag number).
Part 2:
The number belonging to the message from the PLC side that uniquely identifies the
message within a PLC CPU (format DLL-specific).
In the configuration dialog, the following selection has to be made to establish the message
number:
Structure of an S7PMC message number (32 Bit)
To Part 1
Every message belongs to a raw data tag, which identifies a PLC CPU. In order to perform
the assignment of the raw data tag to the message number, the following definition has been
established.
The name of the raw data tag for the S7PMC - and all connection types with a format DLL
- has the following fixed structure:
@rd_alarm#rd_nr
@rd_alarm# Fixed integral part of the name of a raw data tag for format DLLs
rd_nr Decimal number between 0 and 1023 for the identification of a raw data
tag (without leading zeros)
The most significant Bit of the message number is set for message numbers which are
assigned by format DLLs (externally). These messages must only be processed by the
corresponding format DLLs, i.e. via the configuration dialog of Alarm Logging, the
message number cannot be changed.
To Part 2
This part of the message number can be assigned by the respective format DLL. For the
S7PMC, it has the following meaning:
MldShowDialog
Parameter Description
hwnd Window handle
lpmCS Pointer pointing to the single message data
lpDMProjectInfo Pointer pointing to the project information structure
lpError Pointer pointing to the default WinCC error structure
Return Description
TRUE Function successful
FALSE Error in the API function, description of the error cause via the
pointer lpError
The Format DLL has an API function for defining the S7PMC-specific archive tag name.
This function is called by CS Tag Logging while assigning parameters to the archive tags
belonging to an S7PMC connection. The archive tag name assigned by the S7PMC format
DLL is a name consisting of several components that contains, among other things, the
number belonging to the archive on the PLC. With this algorithm, the S7PMC tag numbers
are uniquely contained in the WinCC archive tag description, resulting in the quickest
possible assignment during runtime.
Tag Logging guarantees that the archive tag names are all unique.
Structure of an S7PMC archive tag name (not longer than 18 Bytes)
Parameter Description
hwnd Window handle
lpszArcVarName Pointer pointing to the string field that stores the format DLL-
specific archive tag name portion
dwArcVarNameLength Maximum length of the format DLL-specific name portion
lpVarKey Pointer pointing to the Varkey of the raw data tags
lpError Pointer pointing to the WinCC error structure
Return Description
TRUE Function successful
FALSE Error in the API function, description of the error cause via
the pointer lpError
Parameter Description
lpDMVarKey Pointer pointing to the Varkey of the raw data tags
lpMsgNumber Pointer pointing to the field with single message numbers
dwNumMsgNumber Quantity of single message numbers
lpError Pointer pointing to the WinCC error structure
Return Description
TRUE Function successful
FALSE Error in the API function, description of the error cause via the
pointer lpError
This function is required because the format DLL does not have the configuration
information about the relevant archive tags. The PdeSendMsg function is therefore called
for a certain number of relevant archive tags. In this way, the configuration information and
additional information of Tag Logging are made known for the archive tags.
Multiple archive tags of a connection can be registered with a single call.
Tag Logging transfers one double word per archive tag as additional information to the
format DLL, which is retained in in the memory of the format DLL memory. This
additional information is required by Tag Logging as soon as the archive tags have to be
processed (in the Callback function TagLogging_ARCHIVE_CALLBACK).
This means that the format DLL can create a table in the main memory during runtime,
with which the S7PMC-specific logon messages can be structured for the respective
archives. The logon messages are required to announce to the PLC the ready to receive
status for the respective archive number. Only after the successful logon, does the PLC
send the archive data to the application (WinCC).
PdeSendMsg
Parameter Description
lpfnCallBack Pointer pointing to the callback routine with which the raw data tag
generated by the format DLL is transferred to the data manager (DM).
If zero, the callback routine is called from the INI structure.
The function address from the INI structure is not identical with this
parameter.
dwFunctionId Function identifier FUNC_ID_REGISTER (compare to table below),
the same function applies to all listed tags
lpszArcVarName Pointer pointing to a pointer field whose elements refer to the archive
tag names
lpdwData Pointer pointing to a field whose elements contain additional data for
the archive tags, can also be zero.
The additional value belonging to an archive tag is transferred without
modifications to the internal lists of the format DLL by the
FUNC_ID_REGISTER function (logon archive tag) and forwarded to
Tag Logging_ARCHIVE_CALLBACK at the appropriate time.
Has no meaning for the other function identifiers.
dwNumArchVar Quantity of the archive tag names to be processed
Name
lpVarKey Pointer pointing to the Varkey of the raw data tags
lpUser Pointer pointing to the user data, transferred unmodified to Callback
lpError Pointer pointing to the WinCC error structure
Return Description
TRUE Function successful
FALSE Error in the API function, description of the error cause via the pointer
lpError
The configuration dialog must be language-dependent, i.e. the format DLL must recognize
the currently set language. During the startup, the language setting is reported in the start
structure. The dynamic language switch must also be forwarded to the format DLL by Tag
Logging and Alarm Logging. For this purpose, the following call is available:
NormSetLanguage
Parameter Description
dwLocalID Language setting at the time of the call
lpError Pointer pointing to the default WinCC error structure
Return Description
TRUE Function successful
FALSE Error in the API function, description of the error cause via the pointer
lpError
5.3.5 Formatting
If an application has logged on at the PLC to receive messages or archive data, this data
will be provided via the respective raw data tag. The format DLL logs on during
registration. From that point on, data messages can be sent by the PLC. Data messages are
packaged in raw data tags and forwarded to the format DLL through the channel DLL, the
data manager and the respective application (in this case, Tag Logging or Alarm Logging);
the format DLL is responsible for the raw data tag type. The format DLL interprets the
incoming data and constructs messages or archive data from them.
The content of a raw data tag (of a message) can store n single messages. The format DLL
has to interpret this S7PMC-specific message and forward the resulting single messages to
Alarm Logging.
The message number (EV_ID) of the S7PMC is a part of the WinCC message number.
In a single message, up to ten process values can be delivered by the S7PMC. In this case,
the string type is permitted as a process value. This process value type is not supported by
Alarm Logging - additional values of such kind have to be rejected by the format DLL.
The MldReceiveMsg function is called by Alarm Logging every time the status of the raw
data tag changes, i.e. if the faulty status following OK or vice versa is detected by the data
manager. The change of status of the raw data tag (corresponding to a connection) is only
of importance for the S7PMC format DLL. Additional information can be found in the
chapter Processing in the Event of a Status Change.
MldReceiveMsg
Parameter Description
lpfnMsgReceive Pointer pointing to the callback routine with which the single message
structured by the format DLL is transferred to Alarm Logging.
lpDMVar Pointer pointing to the raw data tag
lpUser Pointer pointing to the user data, transferred unmodified to Callback
lpError Pointer pointing to the WinCC error structure
Return Description
TRUE Function successful
FALSE Error in the API function, description of the error cause via the pointer
lpError
The callback function for sending single messages to Alarm Logging is supplied as follows:
Parameter Description
lpMsgCreate Pointer pointing to a WinCC message
dwNumMsg Quantity of the single messages
lpUser Pointer pointing to the application data
lpError Pointer pointing to the default WinCC error structure
Return Description
TRUE Function successful
FALSE Error in the API function, description of the error cause via the pointer
lpError
The message and alarm concept of WinCC Alarm Logging and S7PMC makes provision
for messages being acknowledged depending on their configuration. The acknowledgment
information is known to Alarm Logging, but must also be managed in the message
acknowledgment storage of the PLC. In order to achieve this, Alarm Logging sends
acknowledgment messages to the PLC using the format DLL corresponding to the
connection.
On the basis of this input data, the S7PMC format DLL constructs the corresponding
S7PMC messages, which are forwarded to the data manager by the Alarm Logging
Callback function NORM_SEND_PROC.
The same procedure applies, if a single message is to be locked/reenabled by Alarm
Logging, i.e. their generation is to disabled/enabled at the source in the PLC.
MldSendMsg
Parameter Description
lpfnMsgSend Pointer pointing to the Alarm Logging callback routine with which the
raw data tag - constructed by the format DLL - is transferred for writing to
the PLC. The parameters are described in the chapter Query of the
Properties of a Format DLL.
lpSendData Pointer pointing to the send data, its structure is in more detail below
dwNumData Quantity of the individual jobs to be processed
lpUser Pointer pointing to the user data, transferred unmodified to Callback
lpError Pointer pointing to the WinCC error structure
Return Description
TRUE Function successful
FALSE Error in the API function, description of the error cause via the pointer
lpError
Tag Description
DWORD dwVarID Raw data tag ID of the DM
DWORD dwNotify Notify: Possible values
MSG_STATE_QUIT: Acknowledge message
MSG_STATE_LOCK: Lock message
MSG_STATE_UNLOCK: Enable message
MSG_STATE_QUIT_EMERGENCY: Acknowledge all messages
DWORD dwData For QUIT, LOCK, UNLOCK --> message number
For EMERGENCY ACK --> not used
The status change of a connection (raw data tags) must be reported to the format DLL. This
is carried out by the MldReceiveMsg function.
In the case of a message update, the S7PMC format DLL reads the message status of all the
messages that have been reported (via registrations) and sends it as a single message to
Alarm Logging. Consequently, it is possible to build on a consistent message picture upon
system startup.
A message update is required, if
• a status change from faulty to OK has been detected (that is also the case implicitly
upon system startup)
• the PLC sends a message update message. This message is sent to each logged on
participant, if, for example, a message overflow has been detected, messages from other
participants are acknowledged or enabled.
During the message update, the PLC sends the message acknowledgment states and the
lock IDs. The additional values and the time are not sent. In this case, the format DLL
supplies the current system time as the time for the single message or writes the ID
MSG_STATE_UPDATE into the message status.
The content of a raw data tag (of a message) can store n archive tag values. The format
DLL has to interpret this S7PMC-specific message and forward the resulting archive tag
values to Tag Logging.
For an archive tag, process value converters can also be sent. The S7PMC format DLL will
then perform the desired conversion from the process value to the archive tag value. This
process involves existing WinCC scaling functions. The exact procedure still has to be
specified.
The PdeReceive function is called by Tag Logging every time the status of the raw data tag
changes, i.e. if the faulty status following OK or vice versa is detected by the data manager.
The change of status of the raw data tag (corresponding to a connection) is only of
importance for the S7PMC format DLL. Additional information can be found in the chapter
Processing in the Event of a Status Change.
PdeReceive
Parameter Description
lpDmVarUpdate Pointer pointing to the raw data tag
lpfnCallBack Pointer pointing to the callback routine with which the format DLL
transfers the individual archive tag values to Tag Logging.
lpUser Pointer pointing to the user data, transferred unmodified to Callback
lpError Pointer pointing to the WinCC error structure
Return Description
TRUE Function successful
FALSE Error in the API function, description of the error cause via the pointer
lpError
The callback function for sending individual archive tag values to Tag Logging is supplied
as follows:
Parameter Description
lpszArcVar Archive tag name as from the raw data ID
Name
doValue Archive tag value
lpstTime Pointer pointing to the time stamp derived from the user data of the raw data
tag
dwFlags IDs, whose exact meaning still has to be specified.
dwData Additional date that was provided upon registration, is transferred without
modification
lpUser Pointer pointing to the user data, applied without modification from the
function call
lpError Pointer pointing to the WinCC error structure
Return Description
TRUE Function successful
FALSE Error in the API function, description of the error cause via the pointer
lpError
With this function, Tag Logging has the option in S7PMC of controlling the receipt of
archive tag values. For this purpose, the S7PMC format DLL forms the call for the logoff
or logon of the respective archive, and forwards this call to the DM via
NORM_SEND_PROC.
From the point of view of the S7PMC format DLL, locking/enabling of archive tags is
almost identical to the functions which are required for registering an archive tag. For both
functions, the same function is therefore called in the format DLL (PdeSendMsg).
Via the dwFunctionId function identifier, the differentiation between registering and
locking/enabling is made: for locking/enabling, the additional data lpdwData for each
archive tag has no meaning. See also chapter Registration of all Archive Tags.
The status change of a connection (raw data tags) must be reported to the format DLL. This
is carried out by the PdeReceive function.
5.4.1.1 Motors
5.4.1.2 PC/PLC
5.4.1.3 Pumps
5.4.1.4 Pipes
5.4.1.6 Tanks
5.4.1.8 Valves
5.4.2 Displays
5.4.2.1 Displays
5.4.2.2 Windows
5.4.2.3 Scaling
5.4.2.5 Meters
5.4.3 Controls
5.4.3.1 3D Buttons
5.4.3.6 Controllers
5.4.3.8 Keyboards
5.4.4 Symbols
5.4.4.4 E Symbols
5.4.4.5 Conveyors
5.4.4.6.1 isa_s55a
5.4.4.6.2 isa_s55b
5.4.4.6.3 isa_s55c
5.4.4.6.4 isa_s55d
5.4.4.6.5 isa_y32a
5.4.4.6.6 isa_y32b
5.4.4.6.7 isa_y32c
5.4.4.6.8 isa_y32d
5.4.4.6.9 isa_y32e
5.4.4.6.10 isa_y32f
5.4.4.6.11 isa_y32g
5.4.4.6.12 isa_y32h
5.4.4.6.13 isa_y32i
5.4.4.7 Motors
5.4.4.8 Valves
5.4.4.9 Miscellaneous 1
5.4.4.10 Miscellaneous 2
Index
Screen, 3-12
Time Range, 3-87
A Value Range, 3-42, 4-20
Workspace, 3-14
Access, 3-55, 5-9 Assignment Lists, 3-66
Reading WinCC Data, 5-9 Authorization, 3-57
Rights, 3-61 Autostart, 3-51
To the Database, 3-55, 3-66 Entry in Folder, 3-51
Access Protection, 3-15, 3-19, 3-54, 3-77
Transfer of the Rights, 3-77
Acknowledgment
B
Messages, 3-84
Actions, 3-23, 4-12 Backup, 3-48, 3-54
At Open Picture, 5-4 Concept for, 3-54
Create, 4-3, 4-14 WinCC Data, 3-55
Edit, 4-11 Basic, 2-2, 3-59, 3-103
Editor for, 4-11 Basic Project, 3-59, 3-77
Folder, 3-49 For Import, 3-69
In WinCC, 4-4 Basic Mathematical Operations, 4-33
Reuse, 4-11 Basic Process Control, 3-16, 3-82, 3-87
Selection, 3-33 Bit Message Procedure, 3-20
Specify, 3-9 Bit Operations, 4-36
Transfer, 3-65 Bitmap, 3-62
Update Cycles, 3-27 Transfer, 3-62
Update in Picture, 3-23 Bus System, 3-18
ActiveX, 2-2, 2-3, 3-57, 3-103
Adaptation, 3-23
Computer Property, 3-58 C
Data for Tag Import, 3-72
Picture Update, 3-23 Callback Function, 5-65
Addition, 4-31 For he Transfer of the Process Value read,
Addressing, 3-6 5-65
Indirect, 3-6, 3-96 For the Feedback of the Status of a Write
Alarm, 3-20 Job, 5-65
General Information regarding the C-API, 2-4
Specification, 3-20 Channel, 3-57
In the Control Concept, 3-16 DLL, 3-57, 3-67, 3-72
Alpha Cursor, 3-15, 3-83 S7 PMC, 3-105
Analog Values Character, 4-42
Time, 3-103 String, 4-42
ANSI, 4-3 Valid for Picture Names, 3-7
API, 2-4, 3-66, 3-67, 3-104 Valid for Tag Names, 3-6
Application, 2-2, 3-40 Valid in Project Names, 3-4
Close, 3-52 Client, 2-4
Integrate other, 2-3 Color
Interface (API), 3-66 Colors in the Project, 3-11
Own, 2-2 Definition, 3-17
Application Window, 2-3, 3-60, 3-84, 3-87 Identification, 3-11
Archiving, 3-3, 3-56 Color Table, 5-15
Archiving Times, 3-23 Command, 4-49
Configure, 3-59 Conditional, 4-49
Area, 3-14 Communication, 3-18, 3-27, 3-61
Key Area, 3-17 Affect on the Update, 3-27
Between Individual Tasks, 3-28 Customized Object, 3-63, 3-97, 3-98, 3-101,
Interfaces, 3-57 3-102
Online Change, 3-105 In Picture Module Technology, 3-92
Process, 3-23 Transfer, 3-63
Computer, 3-52 Wizard, 3-97
Change Type, 3-104 Cycle Time, 3-27
Folder for, 3-50
Hotkey, 3-85
Settings, 3-52 D
Concept, 2-5, 3-12
Control, 3-12, 3-15 Data
Data Backup, 3-54 Backup, 3-56
Prototype Pictures, 3-94 Configuration Data, 2-4
Conditional, 4-49 Data Maintenance, 2-4
Commands, 4-49 Database, 2-5
Configuration, 3-23, 3-49 Import, 3-55
Add Dynamics, 3-43 In the Database, 3-47
Data from, 3-49 Request, 3-40
Dialog, 3-23, 3-30, 3-43, 3-57, 3-62, 3-97 Seperation, 3-48
Mode, 3-51 Storage, 3-21
Specifications for, 3-2 Transfer, 3-59
Configuration Data, 2-4 Transfer from S5 or S7, 3-66
Connection, 3-18, 3-105 Update, 3-18
Connection List, 3-71 Data Export, 5-12
Indirect, 3-93 Via C-Action, 5-12
Logical, 3-66 Database, 2-4
New, 3-92 Access with ISQL, 5-10
Serial with CP525, 5-14 Access with MS Access, 5-9
Set Up, 3-105 Access with MS Excel, 5-6
To the Process, 3-18 Backup, 3-55
UPS, 3-54 Edit, 3-59
With Process Tags, 3-101 Query Language, 2-4
With Tags, 3-96 Reconstruction, 3-47
Content, 3-49 Selection in, 5-13
Display Project Folders, 3-49 DDE, 2-2
Control, 3-12, 3-15, 3-18 Decrement, 4-31
Event-Driven, 3-18 Default, 3-3
Operating Error, 3-10 Language, 3-46
Trend Windows, 3-87 Settings, 3-3
Via Function Keys, 3-80 Trigger, 3-39
Via Keyboard, 3-40, 3-82 Definition, 4-68
Without a Mouse, 3-78 C-Structures, 4-68
Control Concept, 3-15 Development, 2-2
Control Objects, 3-83 Development Environment, 3-49, 3-103, 4-3
Conversion, 3-60 Diagnosis, 3-69, 4-17, 4-18
Single-User - Multi-User, 3-60 File for Import, 3-69
Coros, 3-74 Files, 3-45
Create, 4-118 Scope, 5-5
File with Script, 4-118 Dialog, 3-43
Message Structure, 3-76 Configuration, 3-43, 3-62
Cursor, 3-15 Configurations, 3-23
Alpha, 3-15, 3-83 Direct Connection, 3-23, 3-42, 3-82, 3-95,
Tab, 3-15, 3-83 3-100
Cursor Keys, 3-84, 3-85 Directions, 3-72
For the Data Transfer, 3-72