QuickStart Configuration
Guide
V1.02
Contents
4.6 Operator
Control and Data Entry
Citect is a
very flexible and powerful product which allows system developers to configure
a wide variety of specific requirements as desired, but which requires varying
degrees of programming prowess to achieve some of these features. The need was seen to deliver a set of
standard functionality which would free developers from having to create the
standard pieces of functionality we have all come to expect from a well
engineered Citect system, and to let them concentrate on process issues, rather
than what should be no-brainers.
The Quickstart project (AKA Citect starter project) was created with the small
to medium, first time developer of Citect in mind, in an attempt to deliver a
feature rich environment to the end user, with an absolute minimum of
configuration effort. To this end, the
project ships with pre-configured alarm and trend pages and an automated system
of navigation, amongst other things, which make the project work straight out
of the box for things like alarm filtering by area, configurable trends which
are saved between runs (centrally, in this case) etc. Much of the configuration is actually done in run-time, which it
was thought would make life easier if the developer wanted to create, say for
example another trend page (because they forgot? – or because operations forgot
to ask for it?). In the case of trend
pages, another one can be added either for the specific user, and it will be
available system wide (after the user has logged in again).
Many items that can be changed at run-time are available immediately
system-wide, for example users can be added which are immediately available
system wide. Changing the any of the
attributes of a user will cause them to be applied the next time the user is
logged in.
This immediate system wide behavior is achieved by storing all of the
information on the servers in a data-base styled structure in an .ini file,
which is accessible by all but manager nodes.
Alarm and event logging is handled in a similar way, and none of these configurations
requires the nodes to know anything about each other except that they are a
primary or standby machine in a redundant system or a client of one or two
alarm servers.
The
QuickStart project is intended for Citect V5.40+, on W98 – W2k, Machines should be at least PIII 600’s with
128MB RAM. The project was anticipated
to be 1k – 15k tags, with not more that 450 navigable pages (excluding trend
pages), not more than 450 user plus default trend pages, not more than 10
alarms per second continuously. Between
1 and 20 workstations. 1-2 servers, or more if specialized i/o servers are
required.
The system should function fully for Full licenses, Full IDC’s, and have most
functionality for manager nodes (manager nodes have slightly modified trend
functionality and have local security and configuration databases)
The Citect
computer setup wizard. The most
significant parts of the setup wizard are the alarm server setup, and IO server
setup.
Once the node has been setup, the QuickStart project may be run. If this is the first time it has been run on
the system (ie it is a new (a) server for a system or a new (b) client on an
existing system) then sets of default information will be loaded (a) for the
system for (b) for the workstation, within the system database, and the system
or workstation will startup with these default settings. The settings include things like the users
which are defined, the user which logs into the workstation etc.
The system
could be used successfully with none of the following setup items, but for
maximum customization, they can be configured.
In a new
system, running QuickStart for the first time will result in the system
requsting that you confirm that you indeed wish to create the files necessary
for a new installation. It should be
noted that both server should be present at the time since the server which is
being configured will attempt to replicate its’ database to the other one. If the other server is not present, then
pending writes will be queued until the other server becomes available. (If you disable the LAN or do not specify
the other (alarm) server name then Quickstart will assume that there is no
requirement to replicate its database to the other alarm server, and the server
will only write to the database of the one server configured, or the local
machines.
The database lives in the [data] directory, and is called “database.ini”. If for any reason this file gets out of sync
on one of the servers (say for example, it was shut down, system changes were
made, and the other server was shutdown) then this file should be copied from
one machine to the other. Note that the
Quickstart shutdown functions have built in protection for this situation, and
will hold shutdown until the machines buffers have been emptied, in the first
instance, but will prompt the user in
the second instance if they wish to lose data.
In a redundant system, one of the servers should be running at ALL
times. If it is necessary to take them
both down, then it should be done at the same time so as to ensure that the
data on each is as close to equal as possible.
Once Quickstart has determined that you are setting up a new system, it will
also determine that this is a new workstation.
In a new
system or when adding a new workstation to an existing system, QuickStart will
detect that the workstation has not been connected to the system by virtue of
an entry based upon its’ [LAN] node name not existing. Whereupon, it will set up the workstations
default user (normally viewer) and default SHUTDOWN privilege, as well as home
page (to alarm). The default printer is
not set and a dialogue will be shown for the user to select their printer. The default printer setting and any other
settings then selected by the user from the right mouse menu will not be saved
tot he users’ profile until they select ‘save settings’ from the right mouse
menu.
The default user for the workstation can be set up by selecting ‘set default
user’ from the right mouse menu, once the desired user is logged in.
Graphic
pages are configured as per normal, except that you should use the QuickStart
templates. Only XGA with no title bar
is supplied.
The graphic page names must be designed with a structure built-in, such that
there are multiple underscore separated sections. Each subsequent section represents a deeper look into the plant,
for example:
The plant overview might be called “Plant”, whilst the primary section graphic
could be called “Plant_Primary”, the secondary section could be called
“Plant_Secondary”, etc. Further, there
could be pages called “Plant_Primary_Inlet”, “Plant_Primary_Process” and
“Plant_Primary_Output” etc, and so on.
The depth of the hierarchy is only practically limited by the length of
the page name.
Trends are
all configured at runtime. There are
two types of trend – user trends and system or default trends. User trends are defined by each user and may
only be accessed by them whereas default trends are defined by an engineer and
may be accessed but not modified by everyone.
It is intended that a trend or trends be associated with graphic pages,
and if, when the trend button is pressed, the system fins a trend page with the
same name as the graphic page, it is automatically displayed. If one is not found, then a list of all user
and default trend pages is displayed.
If the user creates a trend page with the same name as an already
configured default trend which is also associated with a graphic page, then
this will be shown by preference when displaying the trend page associated from
a graphic. If the trend button is
pressed when a trend page is already being displayed then the trend page menu
will be displayed.
There are
built in reports which are triggered from the trigger bits which are set at the
intervals defined on the report setup page.
These reports are already being replicated across two servers (if they
exist) and printed (if selected). The
reports need to be configured offline as usual, however.
Alarms are
configured in the usual way, though there are predefined categories which
should be used – CAT_URGENT, CAT_WARNING and CAT_LOGGED. Also there are areas which should be used or
their names changed and then used.
Areas begin with AREA_. Alarms
should be created with the privelege of Priv_Alarm. If you use no category or area, it will still work. You should probably delete the areas in the
labels.dbf, though.
All alarms
and events (such as user actions, PLC commands, confirmation and
logging) are logged to
a single file called eventlog.log.
As a simple way of combining PLC
commands, confirmation and logging, a function called 'QuickSetTagLog' has been
incorporated into QuickStart and should be used in your project whenever you
need to do any of these.
Usage:
QuickSetTagLog(STRING sTag, INT iMode = 0, REAL rValue = 0, STRING
sLOGSTR = "", STRING sPrompt = "")
Where:
sTag is the tag you wish to set
iMode is the mode of the call:
0, Set the tag to a value
obtained from a keypad
1, Set the tag to the value
given
2, Toggle the bit or value
3, Pulse the tag to 1 then
zero
rValue
is the value for mode 1
sLogStr
is the string to log when the change is made.
If left blank, the tag comment will be used
sPrompt
is the prompt string to use for the confirmation form. If lenft blank, no confirmation will be
required.
For smaller
projects, Quickstart was designed so that all additional configuration required
could be done right in the Quickstart project.
For larger projects, it may be necessary to have other, include
projects, to facilitate easier engineering and maintenance. If this path is chosen, then Quickstart
should remain the compile project, and the other projects should be included in
it.
There is a
file called help.htm. This resides in
the Quickstart project and contains many pages of information which users will
find useful. It is intended that this
be added to and it has links to it from various pages in your final
system. The links are configured by
double clicking on the title bar on a page in the graphics builder. A form like this should appear:
Into this form, a word unique to this page should be typed, and this should
correspond to a named location in the help.htm file (ie <A
NAME="***"></A>)
Audible
alarms are configured by:
·
Select
the type of audible alarm from the System Audible Alarm Mode selection on the
areas screen.
·
Enabling
them for the user or workstation on the setup screen.
·
Setting
the wav files for urgent and warning alarms on the user or workstation setup screen.
NB: two wav files are included: urgent.wav and warning.wav, and these are
used by default.
·
Setting
the areas for audible sounds for the user or workstation, either on the alarm
page or on the setup page..
Credits for
system integrator and end user can be set up in the ‘general setup’ section of
the plant areas setup page. Note that
these names will not take effect until the second time each workstation is
restarted, subsequent to the change.
Redundancy
of logging is automatic and in most instances transparent, however if one of
your servers is down for an extended period (> 1 week), it may be necessary
to manually synchronize the data files.
To do this, the contents of the \Citect\data\ directory on the running
machine should be copied to the other machine, and the running machine then
preferably shutdown (this will need to be in conjunction to a plant shutdown)
and then both machines re-started in sequence.
For short outages, the machines will resynchronize automatically, even
if they are completely shut-down.
If the
‘remote server data path’ is supplied on the Setup Plant areas page, then the
synchronization process after medium term outages will be simplified, however,
short term outages may take longer to synchronize.