QuickStart Configuration Guide

V1.02

 

 

 

 

 

 

 

 

 


Contents

1     Overview.. 3

2     Target Platform.. 3

3     Getting Started. 3

3.1      Installation. 3

3.2      Setup. 4

3.2.1       A New System.. 4

3.2.2       A New Workstation. 5

4     Configuring a project 5

4.1      Pages. 5

4.2      Trends. 5

4.3      Reports. 5

4.4      Alarms. 6

4.5      Datalogging. 6

4.6      Operator Control and Data Entry. 6

4.7      Include Projects. 6

4.8      Help. 6

4.9      Audible alarms. 7

4.10     Credits. 7

4.11     Redundancy. 7

 


1         Overview

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.

 

2         Target Platform

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)

3         Getting Started

3.1      Installation

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.

 

3.2      Setup

The system could be used successfully with none of the following setup items, but for maximum customization, they can be configured. 

3.2.1      A New System

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.

3.2.2      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.

4         Configuring a project

4.1      Pages

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.

4.2      Trends

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.

 

4.3      Reports

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.

 

4.4      Alarms

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.

 

4.5      Datalogging

All alarms and events (such as user actions, PLC commands, confirmation and logging) are logged to a single file called eventlog.log.

 

4.6      Operator Control and Data Entry

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.

 

 

4.7      Include Projects

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.

4.8      Help

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>)

4.9      Audible alarms

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..

4.10Credits

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.

4.11Redundancy

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.