TotalPlant Alcont and Printa
System start-up R682Doc-To-Help Standard Manual
TotalPlant Alcont and Printa
System start-up R682
Release: System Releases 682.xxx
05/2008
ST682_0Eng.doc
Notices, Copyright, and Trademarks
While this information is presented in good faith and believed to be accurate, Honeywell disclaims the implied warranties of merchantability and fitness for a particular purpose and makes no express warranties except as may be stated in its written agreements with and for its customers. In no event is Honeywell liable to anyone for any indirect, special or consequential damages.
The information and specifications in this document are subject to change without notice.
ã Copyright 1989 – 2006 by Honeywell Oy. No part of this publication may be reproduced or translated, stored in a database or retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of Honeywell Oy.
TotalPlant Alcontand Printa are trademarks of Honeywell Oy. Other brand or product names mentioned in the document are trademarks of their respective owners.
Honeywell Oy
P.O.Box 168
FIN-78201 Varkaus, Finland
Phone +358 20752 2000
Telefax +358 20752 2400
http://www.honeywell.fi
Contents
1 Overview 1
1.1 Document purpose 1
1.2 Names used in examples 1
1.3 Preliminary steps 1
1.4 Initial data 2
2 System definitions 3
2.1 Department 3
2.2 Highways 3
2.3 Modules 4
2.3.1 Module cards 8
2.4 Cards and I/Os 9
2.4.1 Processor cards 9
2.4.2 I/O extension rack cards 10
2.4.3 Memory cards 11
2.4.4 Cards provided with control execution environment 12
2.4.5 Node module cards 12
2.5 Process areas 13
2.5.1 Tool picture process area (VSYSAREA) 13
2.5.2 OPC (OLE for Process Control) data connection process area (OPCAREA) 13
2.5.3 Process areas 14
2.5.4 Process areas required for Printa operating 14
2.6 Back-up copy storages 15
2.6.1 Back-up copy storage AAF_RD_U 15
2.6.2 Back-up copy storages for other units 15
2.7 Users 17
2.8 Unit groups 17
2.9 Logical devices 20
2.10 Devices 20
2.10.1 Memory cards 20
2.10.2 Process module’s trend memory 21
2.10.3 Storage module’s trend memory 22
2.10.4 Peripherals 22
2.11 Data storage groups 23
2.12 Directories 24
2.13 Trend storage paths 24
2.14 Alarm output modes 24
2.15 Alarm areas 25
2.16 Local area network interfaces 25
2.17 Structures 26
2.18 System start-up 28
2.18.1 Packet lists of units 28
2.18.2 Compile packet lists 29
2.18.3 Route map 29
2.19 Additional functions 30
2.19.1 Open Data Exchange interface (ODX) 30
2.19.2 ODX or OPC interface to the FC’s Ethernet port 30
3 Environmental variables 31
3.1 Overview 31
3.2 Environmental variables – resilience and re-loading 31
3.3 Structure of environmental variable file 32
3.3.1 ENVSY environmental variable file contents 32
3.3.2 ENVAP environmental variable file contents 32
3.4 Environmental variable files in design module 35
3.4.1 ENVSY environmental variable file 35
3.4.2 ENVAP environmental variable file 35
4 ETI Start-up 37
4.1 Preliminary steps 37
4.2 Start-up 38
4.3 ETI connection problems 39
4.3.1 Error message 64H, 65H or 66H 40
4.3.2 Error message No answer 34H 41
5 Checking modules and devices 42
5.1 Checking modules 42
5.2 Checking devices 42
5.3 Checking the environmental variables 43
5.4 Creating Printa module’s mass memory card and directories 43
6 DDMBOOT 45
6.1 Creating DDMBOOT directory 45
6.2 Checking DDMBOOT directory and files 46
7 MEMTABFILE and AEMBOOT 47
7.1 MEMTABFILE.OBJ file 47
7.1.1 Copying MEMTABFILE 48
7.2 AEMBOOT directory 49
8 Halting operation 50
8.1 OPI units 50
8.2 BBI units 50
9 Structures 51
9.1 CONFBUP structure (Back-up copy storages) for OM1/OM2 pair 51
9.1.1 Creating CONFBUP 51
9.1.2 Loading CONFBUP 51
9.2 UNIGRP structure (Unit groups) 51
9.2.1 Creating UNIGRP 51
9.2.2 Loading UNIGRP 52
9.3 CONFBUP structure (Back-up copy storages) for other units 52
9.4 Creating other structures for OMs 52
9.4.1 Loading other structures to OMs 52
9.5 Run-time situation pictures (Saved situations) 53
9.6 Checking modules for structures 53
10 Loading 54
10.1 Checking system definitions 54
10.2 Loading system messages 55
10.3 Loading effects 55
10.4 Loading system pictures 55
10.5 Loading 0 display 56
10.6 Loading Local area network interfaces 56
10.7 Loading Alcont I alarms 56
10.8 Loading new backup copy storage 57
10.9 Commissioning hardcopy picture (OPI) 57
10.10 Loading the Printing Press Editor definitions 57
11 Increasing DDM definition table size 58
11.1 Purpose 58
12 CONFBUP 59
12.1 Changing CONFBUP to be department-specific with the System Builder 59
12.2 Changing CONFBUP to be department-specific with Daxmon 59
13 4 Mbit/s support for FC Upline 60
13.1 Replacing the PAE packet for UIX/FST 60
14 Definitions required by FC Ethernet ODX and OPC interface 61
14.1 FC’s ODX and OPC interface limitations 61
14.2 Defining the IP address for the FC’s Ethernet interface 61
15 Data to be returned to Software production 62
TotalPlant Alcont and Printa Contents · iii
System start-up R682 05/2008
1 Overview
1.1 Document purpose
This document contains the start-up instructions for system release 670. The Design module version must be 4.40.105 or higher.
Note! The System release 682 supports only ETI start-up.
This document doesn’t contain user instructions for the Design Module Explorer or builders. Those are contained in the Configuration Manual.
1.2 Names used in examples
The following names are used in the examples included:
Project directory / PROJECTDeparment directory / 000
Department / XPRDEP
Process area / VALVOMO, WET
Modules / DM1, OM1, OM2, PM1
First application disk: / D:
The \AC_CONF\APPL\ directory of the first application disk is set as M:\.
The following are reserved names in the system:
VSYSAREA, OPCAREA, SYSALARM, PMGROUP, OPIGROUP, DDMUNITS, OSP, DAM, AAF_RD_U, REPORTFILS.
1.3 Preliminary steps
Check that the design module version is compatible with the system version. The version data is displayed at the bottom left-hand corner of the TotalPlant Explorer main page. The design module version must be at least 4.40. 105 if the system version is 682.
Note! The system’s language version is selected in conjunction with the design module software installation.
1.4 Initial data
The following initial data items, at least, are required for the system definitions (consult the project’s chief designer, for example).
· System diagram which shows the module names, module structure, highways and highway addresses.
· Department name
· Back-up copy storages
· Process areas
· Process area users and their passwords
· Alarm areas, alarm output modes and alarm output devices
· Devices
· Mass memory cards' allocation to system software packages, system definitions, pictures, application and data storage units.
· Unit load lists.
· Special functions, such as data storage units, trends, hardcopy definitions and Printa system printing press definitions.
The following system definitions are not required in the system start-up:
· I/O definitions.
· Database definitions (Pacman)
· Serial interface definitions
· Data storage groups
· Project-specific application pictures.
2 System definitions
2.1 Department
A system’s project and department definitions are made by using the Create new function found in the Design Module Explorer’s File menu.
Always check the department name with the System Builder.
From the System Builder, select Definition / Department and correct the department name to comply with that defined with the explorer if necessary.
Note! If you change the department name, you have to update the new name to directory paths already defined. Directory paths are defined using the Definition menu's Directories function in the system builder.
2.2 Highways
Access the System Builder and select Definition / Highways.
The data required for the definition window, such as the highway names, are normally found in the system diagram made by the hardware design department.
An example of system highway definition:
Name: / SYSBUSType: / UPLINE
Usage mode: / SYSTEM HIGHWAY
Once the module and card definitions have been completed, you may check the units connected to the highways by clicking on the Show push button in the Highways definition window’s toolbar.
FC allows the highway transmission rate of 4 Mbit/s. To use this feature the PAE software of the UIX/FST must be replaced if the card is not ordered with the correct PAE version. To replace the software, see instructions in section 13, 4 Mbit/s support for FC Upline.
2.3 Modules
Define as modules all the modules contained in the system, including Field Controllers (FC) and I/O extension racks plus any units containing application blocks, such as the SCI, BBI and IBI cards that are provided with a control execution environment.
SCI cards, which are used to connect alarm or report printers to the system are not defined as modules.
Also BBI cards (BBI NPA/N/01) which act as pairs of ETI cards in an OM are not defined as modules.
Access the System Builder and select Definition / Modules. Select the toolbar’s New push button and write the name of the module to be defined. Use the toolbar’s Show push button to check module definitions.
ACEXEDPT
Note! The system software requires the default department ACEXEDPT which must always be defined as a module.
An example defining the ACEXEDPT default department module:
Module: / ACEXEDPTModule type: / AC1
Module code: / AC1 0.0
Department: / XPRDEP
Reserve module:
Pass through: / no
Interface module 1: / OM1
Interface module 2: / OM2
Design module
Note! Module definition is not needed for Design modules which are connected to the system via an ETI card.
An example defining design module DM1 for the XPRDEP department. This module connects to the system via the ETI card.
Module: / DM1Module type: / DM
Department: / XPRDEP
Highway connection card's type
Note! Leave the Highway interface card type field empty when the design module connects to the system via an ETI card.
Operation module
An example defining operation module OM1 for the XPRDEP department:
Module: / OM1Module type: / OM
Module code: / OM 2.0
Department: / XPRDEP
Cabinet: / CCBS01
Power supply type: / 240VAC
Power supply unit: / LPS/ST/N
Pass through: / Yes
Process module (including FC)
If the module to be defined is Field Controller (FC) see Configuration Manual document PROFIBUS Configuration for FC.
If the module to be defined acts as the host process module for an I/O extension rack see Application Planning Guide document Definitions for I/O extension.
An example defining process module PM1 for the XPRDEP department:
Module: / PM1Module type: / PM
Module code: / PM 1.0
Department: / XPRDEP
Cabinet: / CCBP01/A
Power supply type: / 240VAC
Power supply unit: / LPS/ST/N
Reserve module:
Pass through: / No
An example defining redundant process module PM9P1 for the XPRDEP department.
Module: / PM9P1Module type: / PM
Module code: / PM 1.0
Department: / XPRDEP
Cabinet: / CCBP05/A
Power supply type: / 240VAC
Power supply unit: / MPS
Reserve module: / PM9P2
Pass through: / No
Note! The System Builder automatically creates a module whose name is PM9P2 (back-up module). Cards are not defined for the back-up module. See the example of the chapter Cards and I/Os / Processor cards. See also the Configuration Manual / System Builder / Definition / Modules.
I/O extension rack
For instructions see Application Planning Guide document Definitions for I/O extension.
Note! Starting from the system release R682 it is possible to convert VPR-based process modules into I/O extension racks. In practice this means that the Module, Card and I/O definitions of each VPR-based module must be reconfigured as an I/O extension rack by noticing, among other things, that
- in the Module definition IOR must be selected as the Module type.
- in the Edit cards definition the IOC/ST/N must be selected as the
processor card (card slot P1) although the physical card is VPR.
Storage module
An example defining storage module SM1 for the XPRDEP department:
Module: / SM1Module type: / SM
Module code: / SM 1.0
Department: / XPRDEP
Cabinet: / CCBS01
Power supply type: / 240VAC
Power supply unit: / LPS/ST/N
Reserve module:
Pass through: / Yes
SCI card
An example of a SCI card’s module definition. The SCI card is located in the process module PM1 in the card slot 9. (Cards that are provided with control execution environment must be defined as modules. These kind of cards are IBI, BBI and SCI, except for SCI cards for printer connection.)
Module: / PM1SCI09Module type: / PM
Module code: / PM 0.0
Department: / XPRDEP
Cabinet:
Power supply type:
Power supply unit:
Reserve module:
Pass through: / no
Universal module
An example defining universal module UM1 for the XPRDEP department:
Module: / UM1Module type: / UM
Module code: / UM 1.0
Department: / XPRDEP
Cabinet: / CCBS02
Power supply type: / 240VAC
Power supply unit: / LPS/ST/N
Reserve module:
Pass through: / no
Node module
If the system connects to other departments via the mill highway, then the other departments’ node modules must be defined in the module definitions. In the example, HONEYOM2 is the node module through which connection can be made to the HONEY department. The module type must invariably be DEP and the code DEP 0.0. As for the module cards, the only ones to be edited are the main processor and the UIX cards. In card definitions, UIX is named as HONUIX08, for example.
An example defining node module HONEYOM2 for the XPRDEP department:
Module: / HONEYOM2Module type: / DEP
Module code: / DEP 0.0
Department: / HONEY
Reserve module:
Pass through: / No
Alcont I interface module and QALCONT module
For the definitions of the Alcont I interface module and the QALCONT module, see Application Planning Guide document Alcont I Interface.
Printa module
An example defining Printa system’s Printa module (PRM):
Module: / PRM1Module type: / MM
Module code: / MM 1.0
Department: / XPRDEP
Capinet: / CCBS02
Power supply type: / 240VAC
Power supply unit: / LPS/ST/N
Reserve module:
Pass through: / Yes
Imposition programme PC
Note! The module definition for a Printa system’s imposition programme PC is needed only if the module connects to the system via the PI2-A card. The imposition program PC (e.g. RPG1) is defined in the same way as the design module.