C Programme Comos Help ENGLISH HelpMenu Manual

Imprint
2006 innotec GmbH

Issued by: innotec GmbH
Eisenwerkstraße 1
D-58332 Schwelm
http://www.innotec.de
Comos is a product of innotec GmbH.
The software and hardware designations mentioned in this manual are, in
most cases, also registered trade marks and as such are subject to statutory
regulations.
Comos® is the registered trade mark of innotec GmbH.
This manual is protected by copyright laws. All rights, even those including
translation, reprint and duplication, be it partially or in whole, are reserved.
No part of the documation may be reproduced, distributed or processed using
electronic systems, copied or disseminated in any form whatsoever
(photocopy, microfilm or a different process), also not for teaching purposes,
without the written consent of the publisher.
The Comos license is linked to the license floppy disk and the related adapter
(dongle). Loss of the license floppy disk or adapter (dongle) automatically
leads to loss of the license.
For any questions in connection with the documentation, please contact:
[email protected].
Comos Hotline Support:

Monday-Friday between 08:30 and 17:00
Phone: +49 (0) 228 6480 577
Manual - HB82E07 Status: June 21, 2006
© 2006 innotec GmbH

© 2006 innotec GmbH
Table of Contents
1 STARTING COMOS / DATABASE SELECTION
1.1 Start properties ...............................................................1-1
1.2 Database types / Keycode.exe.......................................1-1
1.3 Starting Comos from the command line.......................1-2
1.4 Starting Comos externally .............................................1-3
1.5 Open database and project (login) ................................1-4
1.6 Personal settings ............................................................1-5
1.6.1 Profiles .......................................................................1-5
2 MENU OVERVIEW
2.1 File....................................................................................2-1
2.2 Editing..............................................................................2-3
2.3 View..................................................................................2-4
2.3.1 Direct commands .......................................................2-4
2.3.2 Sub-menu Icon with placing information ....................2-5
2.3.3 Sub-menu Menu bar / Symbol bar .............................2-6
2.4 Administrator ..................................................................2-8
2.4.1 Sub-menu Base data .................................................2-8
2.4.2 Sub-menu System......................................................2-9
2.5 Extra ...............................................................................2-10
2.5.1 Sub-menu Bulk processing ......................................2-10
2.5.2 Sub-menu Query ......................................................2-10
2.5.3 Sub-menu Standard import ......................................2-11
2.5.4 Sub-menu Language translation ..............................2-11
2.5.4.1 Sub-menu Test........................................................2-11
2.5.5 Sub-menu Detail ......................................................2-11
2.5.6 Sub-menu Working layers / histories .......................2-12
2.5.7 Commands...............................................................2-13
2.6 Windows ........................................................................2-13
2.7 Help ................................................................................2-14
2.8 The “PlugIns” icon bar .................................................2-14
© 2006 innotec GmbH 1

3 DATABASE ADMINISTRATION
3.1 Login ................................................................................3-1
3.1.1 Open data base / login window ..................................3-1
3.1.2 Setup login in the release data base..........................3-1
3.1.3 Alternative access ......................................................3-2
3.1.4 First login in a new data base ....................................3-2
3.1.5 Login checks ..............................................................3-2
3.1.5.1 Definitions..................................................................3-2
3.1.5.2 Matching of database scheme and database
indices .......................................................................3-2
3.1.5.3 Increment database version ......................................3-4
3.1.5.4 Increment document version .....................................3-4
3.2 Create / link databases ...................................................3-5
3.2.1 Initial logging-in into a new database .........................3-6
3.2.2 Setup login in the sample database ...........................3-6
3.2.3 Create new Access database ...................................3-6
3.3 Distributed databases (synchronized DB)....................3-7
3.3.1 Distributed access via a Terminal Server using the
example of Citrix ........................................................3-7
3.3.2 Preparation of a Comos database .............................3-7
3.3.3 Creating the synchronized copy (ExportDB) ..............3-8
3.3.4 Working with synchronized distributed data ...............3-9
3.3.5 Reconcile the data again or summarize it ................3-10
3.4 Import / Export of databases .......................................3-11
3.4.1 Import .......................................................................3-11
3.4.2 Export.......................................................................3-11
3.5 Copy system project ....................................................3-14
3.6 Support ..........................................................................3-15
3.6.1 Update versions .......................................................3-15
3.6.1.1 Introduction and concept .........................................3-15
3.6.1.2 Application...............................................................3-17
3.6.1.3 Effect of database version adjustment: ...................3-17
3.6.2 Database utility programs ........................................3-18
3.6.2.1 Compression ...........................................................3-18
3.6.2.2 Check and clean......................................................3-18
3.6.3 database organization ..............................................3-19
3.6.4 Project utility programs.............................................3-19
3.6.5 Status .......................................................................3-19
3.7 Database adjustment....................................................3-19
2 © 2006 innotec GmbH

3.8 System Monitor .............................................................3-20
3.8.1 The Comos system status........................................3-20
3.8.2 Releasing objects (ReleaseObjects,
ReleaseAllObjects)...................................................3-21
3.8.2.1 Advantages and disadvantages of a cache.............3-21
3.8.2.2 Preparing to release objects: matching the cache
and main memory....................................................3-21
3.8.2.3 Executing an object release ....................................3-22
3.9 Performance Monitor ....................................................3-24
3.9.1 The History tab.........................................................3-24
3.9.2 Select modules for monitoring..................................3-25
3.9.3 The Monitoring tab ...................................................3-26
3.9.4 Notes........................................................................3-26
3.10 CVS Monitor ..................................................................3-26
4 WORKING LAYERS / PROJECT HISTORY

4.1 Goal ..................................................................................4-1
4.2 Functional principle of working layers .........................4-1
4.2.1 Four states of objects.................................................4-1
4.2.2 Basic example: released area and a working layer....4-2
4.2.2.1 Definitions..................................................................4-2
4.2.2.2 Adding information ....................................................4-3
4.2.2.3 Deleting information ..................................................4-4
4.2.2.3.1 Technical details of “soft deletion” ............................................ 4-4
4.2.2.3.2 Deleting objects in the working layer (hard deletion /
soft deletion)............................................................................... 4-6
4.2.2.3.3 Restore........................................................................................ 4-7
4.2.2.3.4 Release........................................................................................ 4-7
4.2.2.3.5 Collisions.................................................................................... 4-8
4.2.2.3.6 Delete in the released area / “UndoDelete”................................ 4-8
4.2.3 Working with multiple working layers .........................4-9
4.3 Scope of action of working layers...............................4-10
4.4 Managing working layers .............................................4-13
4.4.1 Database version .....................................................4-13
4.4.2 Controlling the properties of working layers
(@WOLevels)...........................................................4-13
4.4.3 Controlling the display of the list for layer selection .4-15
4.4.4 Rights administration for working layers ..................4-15
4.4.4.1 Global control of levels of working layers ................4-15
4.4.4.2 Allocation of rights in layer management ................4-16
4.4.5 Managing working layers .........................................4-16

4.4.6 Managing documents in working layers ...................4-18
4.4.7 WO-Administrator.....................................................4-18
4.5 Using working layers....................................................4-19
4.5.1 Dialog window “Select working layer” ......................4-19
4.5.1.1 Activation.................................................................4-19
4.5.1.2 “Overview” tab ........................................................4-19
4.5.1.3 “List” tab .................................................................4-20
4.5.2 Working in layers / working layer display .................4-20
4.5.3 Legend .....................................................................4-21
4.5.4 History ......................................................................4-22
4.5.4.1 Overview .................................................................4-22
4.5.4.2 Preparations: base data, project settings ................4-24
4.5.4.3 History entries for working layers ...........................4-25
4.5.4.4 History display .........................................................4-26
4.5.4.5 History of the attributes ...........................................4-27
4.5.4.6 License administration / rights administration .........4-27
4.5.5 Dialog window “Object status” .................................4-27
4.5.6 Importing/Exporting working layers ..........................4-28
5 PROJECT MANAGEMENT
5.1 The system project .........................................................5-1
5.2 Create or delete projects................................................5-1
5.3 Import / Export of projects .............................................5-3
5.3.1 Export project .............................................................5-3
5.3.2 Import project .............................................................5-3
5.3.3 Comparison of exporting and importing: ....................5-4
5.3.4 DBSync.exe ...............................................................5-5
5.3.4.1 Purpose .....................................................................5-5
5.3.4.2 Synchronization sequence ........................................5-6
5.3.4.2.1 Step 1: Create synchronous databases with ExportDB...............5-6
5.3.4.2.2 Step 2: modify DBSync.ini .........................................................5-6
5.3.4.2.3 Step 3: Export of the original Comos database (“source”) .........5-8
5.3.4.2.4 Step 4: Import with retrospective matching................................5-9
5.3.4.2.5 Step 5: Retrospective matching ................................................5-10
5.3.4.2.6 Alternative: Import without retrospective matching.................5-10
5.3.4.3 Error messages .......................................................5-11
5.4 Joint access to projects ...............................................5-12
5.4.1 Introduction ..............................................................5-12
5.4.2 Attributes for joint access .........................................5-12
5.4.3 Project utility programs.............................................5-13
5.5 The project properties ..................................................5-13

5.5.1 The General tab .......................................................5-14
5.5.2 The Links tab............................................................5-14
5.5.3 The Options tab .......................................................5-15
5.5.3.1 Prefixes and delimiters ............................................5-15
5.5.3.2 Device labelling .......................................................5-16
5.5.3.3 Static link .................................................................5-17
5.5.3.4 DisplayValue ...........................................................5-17
5.5.3.5 Revision monitoring.................................................5-17
5.5.3.6 Revision archive ......................................................5-17
5.5.3.7 Automatic referencing of the documents .................5-17
5.5.3.8 Potential tracking.....................................................5-17
5.5.3.9 Name is folder-wide unique.....................................5-18
5.5.3.10 Local instances........................................................5-18
5.5.3.11 Signal tracking.........................................................5-18
5.5.4 The Module options tab............................................5-19
5.5.4.1 Detail .......................................................................5-19
5.5.4.2 Process engineering................................................5-19
5.5.4.3 R&I (i.e. P&ID).........................................................5-20
5.5.4.4 EE / I&C reference layout ......................................5-20
5.5.5 The Languages tab .................................................5-23
5.5.6 The Run cases tab ..................................................5-24
6 RIGHTS MANAGEMENT
6.1 Overview of rights management within Comos ...........6-1
6.1.1 Access an the database.............................................6-1
6.1.2 Meta-rights .................................................................6-1
6.1.2.1 Administrator ...........................................................6-1
6.1.2.2 Project management ..............................................6-2
6.1.3 Notes regarding licenses............................................6-2
6.1.3.1 Viewing license..........................................................6-2
6.1.4 Definition of the three rights groups ...........................6-3
6.1.5 General effect of the mechanism for rights ................6-4
6.1.6 Overview of the options for allocating rights ..............6-4
6.2 Object rights....................................................................6-5
6.2.1 Inheritance in the case of object rights.......................6-5
6.2.2 Object rights in detail..................................................6-5
6.2.2.1 Read completely........................................................6-5
6.2.2.2 Write ..........................................................................6-6
6.2.2.3 Delete ........................................................................6-6
6.2.2.4 Create........................................................................6-7
6.2.2.5 Create revision ..........................................................6-7
6.2.2.6 Check revision...........................................................6-7
6.2.2.7 Release revision........................................................6-7
6.2.2.8 Set user rights ...........................................................6-7
6.3 Function rights................................................................6-8

6.3.1 Base data function right .............................................6-8
6.3.2 Product data function right ......................................6-10
6.3.3 Object debugger function right .................................6-10
6.3.4 Project options function right ...................................6-10
6.3.5 Lock object function right ........................................6-11
6.4 Working areas ...............................................................6-11
6.4.1 Definition and area of application.............................6-11
6.4.2 Create working areas in the base data ....................6-12
6.4.3 Allocate base data to the working areas ..................6-13
6.4.4 Local working areas .................................................6-15
6.4.5 Temporarily restrict working area .............................6-15
6.4.6 Allocate working areas to users ...............................6-16
6.4.7 Allocate working areas and connections..................6-16
6.5 Manage rights: user management...............................6-16
6.5.1 The User tab ............................................................6-17
6.5.2 The properties of a user profile ................................6-18
6.5.2.1 The Memberships tab............................................6-18
6.5.2.2 The Rights tab .........................................................6-18
6.5.2.3 The Contact data tab...............................................6-18
6.5.2.4 The Working areas tab ............................................6-19
6.5.2.5 The Miscellaneous tab ............................................6-20
6.5.3 The Groups tab ........................................................6-20
6.5.4 The properties of a group.........................................6-20
6.5.5 The Rights tab..........................................................6-21
6.6 Managing rights: Object management........................6-23
6.6.1 General tab ..............................................................6-23
6.6.2 Rights tab .................................................................6-24
6.7 Evaluate rights ..............................................................6-24
6.8 Grant rights for status management ...........................6-25
6.9 Rights Management for databases .............................6-25
7 INHERITANCE
7.1 Definition of the methods...............................................7-1
7.1.1 Inheritance with planning objects ...............................7-1
7.1.2 Definition of hierarchical inheritance ..........................7-1
7.1.3 Definition of references (links)....................................7-3
7.1.4 Definition of links ........................................................7-4

7.1.5 Definition of inheriting via catalog attribute ................7-6
7.2 Application ......................................................................7-6
7.2.1 Hierarchical inheritance..............................................7-6
7.2.2 Making a reference (link)............................................7-6
7.2.3 Making links ...............................................................7-7
7.2.4 Inheriting via catalog attributes ..................................7-8
7.3 Check in object ...............................................................7-9
8 COPYING
8.1 General definitions and delineations ............................8-1
8.1.1 The constituent parts of an object ..............................8-1
8.1.2 The amount to be copied ...........................................8-1
8.1.3 References.................................................................8-2
8.1.3.1 Allocation of objects ..................................................8-3
8.1.3.2 Definition and classification .......................................8-4
8.1.3.3 Special reference types .............................................8-6
8.1.3.4 Alternative solutions ..................................................8-6
8.1.4 Extended amount to be copied ................................8-10
8.2 Copying with the Navigator and an additional one ...8-11
8.2.1 Copying within the Navigator (within the project) .....8-11
8.2.1.1 Functional scope .....................................................8-11
8.2.1.2 Application...............................................................8-13
8.2.2 Simple copying with a change of project ..................8-14
8.2.2.1 Functional scope .....................................................8-14
8.2.2.2 Application...............................................................8-16
8.3 Copy structure ..............................................................8-17
8.3.1 Scope of copying......................................................8-17
8.3.2 Application................................................................8-20
8.3.2.1 Rights that are required...........................................8-20
8.3.2.2 Preparing for the copy operation .............................8-21
8.3.2.3 Intermediate editing.................................................8-22
8.3.2.4 Concluding the copying operation ...........................8-26
8.3.3 Special cases regarding projections and prohi-
bitions on projection .................................................8-26
8.4 Copying across projects ..............................................8-26
8.4.1 Scope of copying......................................................8-27
8.4.2 Application................................................................8-28
8.5 The Object Matcher ......................................................8-31
8.5.1 Explanation of the interface......................................8-31
8.5.2 Scope of copying......................................................8-34

8.5.3 Mode of functioning..................................................8-35
8.5.3.1 Color scheme ..........................................................8-35
8.5.3.2 Allocation of objects ................................................8-36
8.5.3.3 Comparison of objects.............................................8-36
8.5.3.4 Summary of the main points....................................8-40
8.5.3.5 Special case Documents.........................................8-41
8.5.4 Application................................................................8-41
8.5.5 The mouse menus ...................................................8-47
8.5.6 Controlling the Object Matcher by a script ...............8-49
8.6 Comparison of copying methods ................................8-50
8.7 Other sections of interest regarding copying ............8-53
8.7.1 Copying system projects ..........................................8-53
9 DELETING
10 DISPLAY IN THE NAVIGATOR

10.1 Using the Navigator ......................................................10-1
10.1.1 Navigation and filter bar ...........................................10-1
10.1.2 Navigator settings ....................................................10-3
10.1.2.1 “Settings” command ................................................10-3
10.1.2.2 “Status display” command.......................................10-3
10.1.2.3 “Symbol preview” command ...................................10-4
10.1.3 Arrange tabs.............................................................10-4
10.1.4 Mouse operation within the Navigator ......................10-4
10.1.5 Functions of the right mouse button (“Context-sensitive
mouse menus”) ........................................................10-7
10.2 Views..............................................................................10-9
10.2.1 Purpose....................................................................10-9
10.2.2 Application................................................................10-9
10.2.3 Administration ........................................................10-10
10.2.3.1 Base objects structure...........................................10-10
10.2.3.2 Managing object queries .......................................10-13
10.3 Object class symbols .................................................10-14
10.4 Other symbols.............................................................10-22
10.5 Context-sensitive symbol change.............................10-22
10.5.1 Object colors ..........................................................10-23
10.5.2 Additional object elements .....................................10-23

11 PROPERTIES: BASE LISTS
11.1 Standard tables ............................................................11-1
11.1.1 General information on standard tables ..................11-1
11.1.1.1 Definition .................................................................11-1
11.1.1.2 Creating or modifying standard tables.....................11-1
11.1.1.3 Symbol allocation (subsymbols) for P&ID plans......11-3
11.2 Unit systems .................................................................11-3
11.2.1 Editing unit systems .................................................11-3
11.2.1.1 The “Groups” area...................................................11-4
11.2.1.2 The lower “Units” dialog area“ .................................11-4
11.2.1.3 The “Return objects” area .......................................11-7
11.2.2 Converting values across projects ...........................11-7
11.3 Document types ...........................................................11-8
11.3.1 Interface ...................................................................11-9
11.3.2 Properties.................................................................11-9
12 PROPERTIES: SYSTEMTYPE CDEVICE

12.1 General buttons ............................................................12-1
12.2 “System” tab .................................................................12-1
12.2.1 Inheritance ...............................................................12-2
12.2.2 General details .........................................................12-3
12.2.3 Text masks...............................................................12-5
12.2.4 Edit group “Reference” .............................................12-8
12.2.5 Edit group “Miscellaneous”.....................................12-10
12.2.6 Edit group “Object behavior” ..................................12-10
12.2.7 Edit group “Creation option” ...................................12-11
12.2.8 Edit group “Creation mode” ....................................12-13
12.2.9 “Inheritance mode” .................................................12-14
12.2.10Edit group “Virtual” ................................................12-14
12.2.11Edit group “Status” ................................................12-15
12.3 “System settings” tab ................................................12-15
12.3.1 Edit group “Implement requests” ............................12-15
12.3.2 Edit group “Allowed links”.......................................12-16
12.3.3 Edit group “Product data: comparison method” .....12-16
12.4 “Specifications” tab....................................................12-16
12.5 “Elements” tab ............................................................12-17
12.6 “Connectors” tab ........................................................12-19

12.6.1 Interface and connector types ................................12-19
12.6.2 Subtypes in the case of connectors .......................12-22
12.6.3 Mouse menus and mouse operation......................12-22
12.6.4 Preassigning connectors with wires, signals or
logical potentials.....................................................12-23
12.6.5 Effect of the implementation pointer.......................12-23
12.7 Symbols” tab...............................................................12-24
12.8 “Script” tab..................................................................12-26
12.8.1 General ..................................................................12-26
12.8.2 The Script Editor ....................................................12-27
12.8.3 Conversion of old data ...........................................12-31
12.9 “Usage” tab .................................................................12-31
12.10“Inheritance sources” tab..........................................12-32
12.11“Configuration” tab ....................................................12-33
12.12“Steel construction grid” tab ....................................12-36
13 PROPERTIES: SYSTEMTYPE DEVICE

13.1 Iconbar ...........................................................................13-1
13.2 Reference fields ............................................................13-2
13.3 General data area..........................................................13-2
13.4 Tabs................................................................................13-3
13.4.1 Base data tab ...........................................................13-3
13.4.2 Specifications tab .....................................................13-4
13.4.2.1 Paste data from Excel into the list attribute .............13-4
13.4.2.2 Command “Update values” .....................................13-4
13.4.2.3 Command “Copy tab data” / “Paste tab data” .........13-5
13.4.2.4 Commands “Refresh static links...” .........................13-5
13.4.2.5 “Accept static links” commands...............................13-6
13.4.2.6 Read-only mode ......................................................13-6
13.4.3 Elements tab ............................................................13-6
13.4.3.1 Option 1: Create elements via the Elements tab.....13-7
13.4.3.2 Option 2: Create elements in the Navigator ............13-7
13.4.3.3 Objects of class Element.........................................13-7
13.4.3.4 Commands on the Elements tab .............................13-8
13.4.4 Connectors tab.........................................................13-8
13.4.4.1 Set connectors by drag & drop................................13-8
13.4.4.2 Context-sensitive mouse menus .............................13-9
13.4.4.3 Save settings (scheme).........................................13-11
13.4.5 Wires tab ................................................................13-12
13.4.5.1 General..................................................................13-12

13.4.5.2 Save scheme for the Wires tab .............................13-13
13.4.5.3 Predetermined wires .............................................13-14
13.4.5.4 Indeterminate wires (only for virtual elements)......13-14
13.4.6 Strip tab..................................................................13-14
13.4.7 Status tab ...............................................................13-16
14 PROPERTIES: SYSTEMTYPE DOCUMENT

14.1 General buttons ............................................................14-1
14.2 General tab ....................................................................14-2
14.3 Change tab ....................................................................14-2
14.3.1 Comos reports..........................................................14-2
14.3.1.1 Evaluation Report....................................................14-2
14.3.1.2 Interactive Reports ..................................................14-4
14.3.1.3 Evaluation Report template .....................................14-5
14.3.1.4 Interactive Report template .....................................14-5
14.3.2 General documents ..................................................14-5
14.3.3 External documents (default interface) ....................14-6
14.3.4 Logicad function plan ...............................................14-7
14.3.5 Management documents..........................................14-7
14.3.5.1 Grouping of documents (documents folder) ............14-7
14.3.5.2 Reference document ...............................................14-7
15 PROPERTIES: TABS
15.1 General...........................................................................15-1
15.1.1 Definition, structure and technical background ........15-1
15.1.2 Rights administration................................................15-3
15.2 Mouse menus and operation .......................................15-3
15.2.1 Mouse menus of the tab...........................................15-3
15.2.2 Mouse menu of an attribute .....................................15-5
15.2.3 Attribute display: Scaling, shifting, grouping ............15-6
15.3 Properties of a specification-tab .................................15-7
15.3.1 General tab ..............................................................15-7
15.3.2 Script tab ..................................................................15-8
15.3.3 Uses tab ...................................................................15-9
15.4 Specifications tab: List view......................................15-10
16 PROPERTIES: SPECIFICATIONS
16.1 Create copy of a specification .....................................16-1

16.2 General tab for specification properties .....................16-1
16.2.1 Type of display .........................................................16-1
16.2.2 Description, Name, Value ........................................16-4
16.2.3 Format, Length, Unit, Type, Standard table .............16-5
16.2.4 Working area............................................................16-6
16.2.5 Edit mode .................................................................16-6
16.2.6 The Catalog specification field .................................16-8
16.2.7 Planning object status, planning object status value 16-8
16.2.8 Inheritance mode .....................................................16-9
16.2.9 The Base specification information ..........................16-9
16.3 Link tab .......................................................................16-10
16.3.1 Overview ................................................................16-10
16.3.2 Types of links (Link types)......................................16-11
16.3.2.1 No link ...................................................................16-11
16.3.2.2 By own object ........................................................16-11
16.3.2.3 By owner ...............................................................16-11
16.3.2.4 By linked object .....................................................16-12
16.3.2.5 By script function <GetLinkedSpecification>
By script function <GetDisplayValue> ...................16-12
16.3.2.6 By connector .........................................................16-13
16.3.2.7 About the Navigation assistant..............................16-14
16.3.3 Value ......................................................................16-14
16.3.3.1 Static value...........................................................16-14
16.3.3.2 Dynamic value.......................................................16-16
16.3.3.3 Fully dynamic ........................................................16-17
16.3.4 Specification...........................................................16-18
16.3.4.1 Overview ...............................................................16-18
16.3.4.2 Identical names .....................................................16-19
16.3.4.3 Access to lists (XValues).......................................16-19
16.3.5 Special functions of an attribute .............................16-19
16.3.5.1 “Product“, “Request“ .............................................16-19
16.3.5.2 “3D“ .......................................................................16-19
16.4 Script tab .....................................................................16-19
16.4.1 Block techniques with scripts .................................16-19
16.4.2 Operation ...............................................................16-20
16.5 Help tab .......................................................................16-20
16.5.1 Context help ...........................................................16-20
16.5.2 Own Information window in the event of invalid
input for the attributes ............................................16-20
16.6 Usage tab ....................................................................16-21

17 PROPERTIES: DESIGN OF SPECIFICATION
17.1 Frames ...........................................................................17-1
17.2 Button ............................................................................17-1
17.3 Checkbox.......................................................................17-1
17.4 Edit field.........................................................................17-2
17.5 Excel interface...............................................................17-3
17.6 File selection .................................................................17-4
17.7 Image selection .............................................................17-4
17.8 Description ....................................................................17-4
17.9 Link.................................................................................17-4
17.10Liste ...............................................................................17-5
17.11Memo field.....................................................................17-5
17.12Edit: (Min Value Max) ...................................................17-5
17.13Edit: (Min Max) ..............................................................17-6
18 PROPERTIES: LIST ATTRIBUTES

18.1 Overview ........................................................................18-1
18.2 Creating list attributes ..................................................18-2
18.2.1 1.: Creating and editing columns (on the “Specifi-
cations” tab) .............................................................18-2
18.2.2 2.: Creating and editing rows (“Index” tab)...............18-3
18.2.3 3.: Behavior and appearance of the table (“General”
tab) ...........................................................................18-4
18.2.4 4.: Editing individual cells (“Specifications” tab) .......18-4
18.3 Limitations.....................................................................18-5
18.4 Accessing lists (XValues) ............................................18-5
19 USING AND LINKING SPECIFICATIONS

19.1 Mapping table................................................................19-1
19.1.1 Area of application ...................................................19-1
19.1.2 Attribute on attribute.................................................19-1
19.1.2.1 Comparison to related functionalities ......................19-1
19.1.2.2 Preparation..............................................................19-2
19.1.2.3 Interface ..................................................................19-2
19.1.2.4 Script editor .............................................................19-4

19.1.3 Mapping table for Excel............................................19-7
19.2 Other links for attributes ..............................................19-7
19.3 Calculation formulas in the “Value” field ...................19-9
19.3.1 TValue......................................................................19-9
19.3.2 CatStd ....................................................................19-10
19.4 Control by means of attributes ..................................19-13
19.5 Editing attributes in a group ......................................19-14
20 INSTANCES (REDUCING THE NUMBER OF OBJECTS)

20.1 Project option instances ..............................................20-1
20.2 Definition of setting up instances ...............................20-1
20.3 Prepare base objects for instances ............................20-2
20.4 Planning objects with the setting up of instances ....20-2
20.5 Effects within the planning project .............................20-3
20.6 Retrospective setting up of instances ........................20-5
21 STATUS MANAGEMENT
21.1 Preparing base objects ................................................21-1
21.1.1 Base object @Status................................................21-1
21.1.2 Base objects, System tab.........................................21-2
21.1.3 Controlling the status through attributes ..................21-3
21.1.4 Controlling the status through a base object script ..21-4
21.2 Status management on the planning side ..................21-4
21.2.1 Setting the status in the Properties window .............21-4
21.2.2 Setting the status within the Navigator.....................21-5
21.2.3 Automatic status change..........................................21-7
21.2.4 Status calculation log ...............................................21-7
21.3 Allocation of rights for status management...............21-8
22 SCRIPT FUNCTIONS OF COMOS OBJECTS

22.1 General...........................................................................22-1
22.2 Scripts at the CDevice (alphabetically).......................22-1
22.2.1 CalcNextName ()......................................................22-2
22.2.2 CheckDelete (Object)...............................................22-2

22.2.3 CheckStatus[1-13]....................................................22-2
22.2.4 Connect(Connector) .................................................22-2
22.2.5 CreateDocumentGroup (class document)................22-2
22.2.6 DeleteWarning (Object)............................................22-3
22.2.7 DisConnect(Connector)............................................22-3
22.2.8 GetConnectorLabel (Connector) ..............................22-3
22.2.9 GetConnectorSpecification (Device, ConnectorName,
SpecName) ..............................................................22-3
22.2.10IsImplementationValid (Device)...............................22-4
22.2.11IsLocationValid (Device)..........................................22-4
22.2.12IsLockAllowed (Lock) ..............................................22-4
22.2.13IsReleaseAllowed....................................................22-5
22.2.14IsUnitValid (Device).................................................22-5
22.2.15NavigatorText (Object) ............................................22-5
22.2.16OnCheck(Device, Modus) .......................................22-5
22.2.17OnCreateReferenceDocument() .............................22-6
22.2.18OnDocObjCreate (DocObj) .....................................22-7
22.2.19OnDocObjDelete (DocObj)......................................22-7
22.2.20OnEditOk() ..............................................................22-7
22.2.21OnEStampCreate (ST,RevElm) ..............................22-7
22.2.22OnEStampShow (PdfStamper, Revision)................22-8
22.2.23OnImplementationSet (OldValue) ...........................22-8
22.2.24OnLocationSet (OldValue) ......................................22-9
22.2.25OnLockDone (Lock) ................................................22-9
22.2.26OnMenuCreate(Popup, Context).............................22-9
22.2.27OnMenuExecute(ID, Context) .................................22-9
22.2.28OnNotLongerReferencedByDevice(Device)..........22-10
22.2.29OnProjectOpen(Project) ........................................22-10
22.2.30OnReferencedByDevice(Device) ..........................22-10
22.2.31OnReferencedByDocument(Document)................22-10
22.2.32OnRelease ............................................................22-10
22.2.33OnReleaseDone....................................................22-10
22.2.34OnRevision() .........................................................22-11
22.2.35OnSubMenuCreate (Popup, Context) ...................22-11
22.2.36OnUnitSet (OldValue)............................................22-11
22.2.37RestoreRequest (Request)....................................22-11
22.2.38UserScript[1-9] ......................................................22-12

22.3 Script at the attribute..................................................22-12
22.3.1 Display types and their script blocks ......................22-12
22.3.1.1 General script blocks.............................................22-12
22.3.1.2 Description ............................................................22-13
22.3.1.3 Image selection .....................................................22-14
22.3.1.4 Checkbox ..............................................................22-14
22.3.1.5 File selection .........................................................22-14
22.3.1.6 Date.......................................................................22-14
22.3.1.7 Edit: (Min, Max) .....................................................22-14
22.3.1.8 Edit: (Min, Value, Max) ..........................................22-14
22.3.1.9 Edit field.................................................................22-15
22.3.1.10 List.........................................................................22-15
22.3.1.11 Memo field(ASII)....................................................22-15
22.3.1.12 Memo field (RTF) ..................................................22-15
22.3.1.13 Query.....................................................................22-15
22.3.1.14 Frame ....................................................................22-15
22.3.1.15 Repeater................................................................22-16
22.3.1.16 Button ....................................................................22-16
22.3.1.17 Signature ...............................................................22-16
22.3.1.18 Link........................................................................22-16
22.3.1.19 Tip .........................................................................22-16
22.3.2 Alphabetic reference of the script blocks ...............22-16
22.3.2.1 CustomizeFileOpenDialog.....................................22-16
22.3.2.2 CustomizeTree (Tree) ...........................................22-17
22.3.2.3 FillComboList (Combobox)....................................22-17
22.3.2.4 FilterRow (StdTabItem) .........................................22-17
22.3.2.5 GetDisplayValue () ................................................22-18
22.3.2.6 GetDisplayXValue (Index) .....................................22-18
22.3.2.7 GetLinkedSpecification () ......................................22-19
22.3.2.8 GetLinkObject (txt) ................................................22-19
22.3.2.9 GetRoot ()..............................................................22-19
22.3.2.10 Import (SpecOwner, ExcelActiveWorkbook) .........22-20
22.3.2.11 IsLinkobjectValid (Specification)............................22-20
22.3.2.12 IsSignatureAllowed (String)...................................22-20
22.3.2.13 OnChangeOther ().................................................22-21
22.3.2.14 OnClick () ..............................................................22-21
22.3.2.15 OnEdit () ................................................................22-22
22.3.2.16 OnLinkobjectSet (Specification) ............................22-22
22.3.2.17 OnShow () .............................................................22-22
22.3.3 Script blocks for “Graphical user interface with
scripts”....................................................................22-23
22.3.3.1 GetScriptUnit ()......................................................22-23
22.3.3.2 GetScriptValue ()...................................................22-23
22.3.3.3 SetScriptUnit (Unit)................................................22-23
22.3.3.4 SetScriptValue (Value) ..........................................22-23
22.3.4 Examples ...............................................................22-24
22.3.5 Script commands for attributes ..............................22-25
22.4 Script for the project object .......................................22-25

23 CONCEPT BEHIND OBJECT QUERIES
24 OBJECT BROWSER
24.1 Overview ........................................................................24-1
24.2 Displaying the list of objects .......................................24-2
24.2.1 Changing the order of the columns ..........................24-2
24.2.2 Row height ...............................................................24-3
24.2.3 Column width ...........................................................24-4
24.2.4 Editing cells directly..................................................24-4
24.3 Display attributes (additional columns)......................24-5
24.4 Row statistics................................................................24-5
24.5 Sort.................................................................................24-6
24.6 Filter ...............................................................................24-8
24.7 Sorting/Filter................................................................24-10
24.7.1 Sorting area............................................................24-11
24.7.2 Filter area ...............................................................24-12
24.8 Options .......................................................................24-13
24.8.1 General tab ............................................................24-14
24.8.2 Administration tab ..................................................24-14
24.8.3 Column edit tab ......................................................24-17
24.8.3.1 General..................................................................24-17
24.8.3.2 Object evaluation...................................................24-18
24.8.3.3 Value calculation ...................................................24-19
24.8.3.4 Extras ....................................................................24-19
24.8.3.5 Languages.............................................................24-21
24.8.3.6 Extension classes..................................................24-21
24.9 Export...........................................................................24-22
24.10New (additional columns) ..........................................24-23
24.10.1| General column ...................................................24-23
24.10.1.1 General tab............................................................24-24
24.10.1.2 Object evaluation tab.............................................24-24
24.10.1.2.1 Navigation library short.......................................................... 24-25
24.10.1.2.2 Navigation library extended ................................................... 24-27
24.10.1.2.3 Script type............................................................................... 24-29
24.10.1.3 Value calculation tab .............................................24-30
24.10.1.4 Extras tab ..............................................................24-31
24.10.1.5 Languages tab.......................................................24-31
24.10.2Default columns (project, timestamp, etc.) ............24-31
24.10.3New | Row statistics ..............................................24-32

24.11Other mouse commands ...........................................24-32
24.11.1Print .......................................................................24-32
24.11.2Delete ....................................................................24-32
24.11.3Properties .............................................................24-32
24.12Status line ...................................................................24-33
25 STANDARD QUERIES
25.1 Creating and opening standard queries .....................25-1
25.2 Operation: Standard controller....................................25-3
25.3 Standard query Planning objects ................................25-7
25.4 Standard query Base objects ....................................25-12
25.5 Standard query Documents / printing.......................25-13
25.5.1 General ..................................................................25-13
25.5.2 Further information regarding printing ....................25-18
25.6 Standard query Attributes..........................................25-19
25.7 Standard query Connectors.......................................25-21
25.8 Other queries...............................................................25-22
25.8.1 Standard tables for picklists ...................................25-23
25.8.2 Values of standard tables.......................................25-24
25.9 Special applications ...................................................25-26
25.9.1 Translation .............................................................25-26
25.9.2 Reimport.................................................................25-26
25.9.3 Device selection (product data)..............................25-26
25.9.4 User-defined...........................................................25-26
25.10Query as list ................................................................25-27
25.11Outputting standard queries in reports....................25-27
26 BULK PROCESSING
26.1 Preliminary comments .................................................26-1
26.2 Bulk processing of planning objects ..........................26-2
26.2.1 Purpose....................................................................26-2
26.2.2 The left-hand window area.......................................26-2
26.2.3 The right-hand window area.....................................26-2
26.2.4 Work flow for bulk processing ..................................26-3
26.2.4.1 Step 1: Setting the object and defining filters ..........26-3

26.2.4.2 Step 2: Collecting and preparing attributes .............26-3
26.2.4.3 Step 3: Save the settings ........................................26-4
26.2.4.4 Step 4: Mark the objects..........................................26-5
26.2.4.5 Step 5: Change the general data and change the
attributes..................................................................26-5
26.2.5 Closing bulk processing ...........................................26-6
26.3 Bulk processing of base objects .................................26-6
26.4 Bulk processing of attributes ......................................26-6
26.5 Bulk processing of documents ...................................26-7
26.6 Bulk processing of connectors ...................................26-7
27 QUERIES - PROGRAMMER’S VIEW

27.1 Object structure in the overview .................................27-2
27.1.1 General ....................................................................27-2
27.1.2 Display component...................................................27-4
27.1.3 Calculation component.............................................27-5
28 DECISION TABLES
28.1 Concept and scope.......................................................28-1
28.2 Creating a decision table .............................................28-1
28.3 Design mode .................................................................28-1
28.3.1 Addressing extended values ....................................28-1
28.3.2 Condition columns....................................................28-2
28.3.3 Action columns.........................................................28-3
28.4 Working mode ...............................................................28-4
28.4.1 Conditions ................................................................28-4
28.4.2 Actions .....................................................................28-4
28.5 Documentation of the action taken .............................28-5
28.6 Applications ..................................................................28-5
28.7 Controlling decision tables by scripts ........................28-6
29 OLD PROCESSING TECHNIQUES

29.1 Editing documents........................................................29-1
30 TOOLS AND UTILITY PROGRAMS

30.1 Synchronize project folder...........................................30-1

30.1.1 Documents ...............................................................30-1
30.1.1.1 Documents tab ........................................................30-1
30.1.2 Comparing revision directories.................................30-3
30.2 Unit conversion.............................................................30-4
30.3 Object test .....................................................................30-5
30.3.1 Concept....................................................................30-5
30.3.1.1 Structure of the test list............................................30-5
30.3.1.2 Meaning of the entries.............................................30-5
30.3.1.3 Source of the entries ...............................................30-6
30.3.1.4 Chronological sorting of the entries.........................30-7
30.3.2 Starting the object test .............................................30-7
30.3.3 The interface of the object tester..............................30-9
30.4 Object debugger .........................................................30-11
30.5 External programs in the bin directory .....................30-12
30.5.1 ComosReg.exe ......................................................30-12
30.5.2 DBSync.exe ...........................................................30-12
30.5.3 DBExtras.exe .........................................................30-12
30.5.4 DBMon.exe ............................................................30-12
30.5.5 Dongle.exe .............................................................30-13
30.5.6 ExportDB.exe .........................................................30-13
30.5.7 ImportDB.exe .........................................................30-13
30.5.8 KeyCode.exe..........................................................30-13
30.5.9 Konverter.exe.........................................................30-13
30.5.10LCODBC32.exe ....................................................30-13
30.5.11MultiCRP.exe ........................................................30-13
30.5.12ptmcast.exe ...........................................................30-14
30.5.13RegMaid.exe .........................................................30-14
30.5.14SetLang.exe ..........................................................30-14
30.5.15SetLicPath.exe ......................................................30-14
30.5.16Sychange.exe .......................................................30-15
30.6 Pause bridging ............................................................30-15
31 SYSTEM PROJECT: STANDARD TABLES

31.1 Generally applicable information ................................31-1
31.2 @ConnectionTypeE / Contact point types (EE/I&C) ..31-1
31.3 @ConnectionTypeF ......................................................31-2
31.4 @ConnectionTypeI .......................................................31-3

31.5 @ConnectionTypeR......................................................31-4
31.6 @ConnectionTypeS ......................................................31-4
31.6.1 @ConnectionPossibleS ...........................................31-5
31.7 @PROPAR / Tables for project parameters................31-5
31.7.1 @PROPAR | ELO_DOCSORT / Combo box
contents....................................................................31-6
31.7.2 @PROPAR | ELO_OUTPUT / Combo box contents31-6
31.7.3 @PROPAR | ELO_PATH / Path / Zone output ........31-7
31.8 @SYSTEM / System tables...........................................31-8
31.8.1 @SYSTEM | @BridgeType / Bridge types...............31-8
31.8.2 @SYSTEM | @DRW_TYPE / Diagram type............31-9
31.8.3 @SYSTEM | @ELO_KSP / Contact mirror ............31-10
31.8.4 @SYSTEM | @LCID / Country codes....................31-10
31.8.5 @SYSTEM | @LNTYPE / Line type.......................31-11
31.8.6 @SYSTEM | LNWIDTH / Line width ......................31-11
31.8.7 @SYSTEM | @ProdReqShow / Request/Product
data ........................................................................31-11
31.8.8 @SYSTEM | @RGB_COLOUR / RGB colors........31-12
31.8.9 @SYSTEM | @WireColor / Wire colors .................31-13
31.8.10@SYSTEM | @WireCrossSection / wire cross
sections ..................................................................31-13
31.8.11@SYSTEM | @WireCrossSectionAWG / American
National Standard ..................................................31-14
31.8.12@SYSTEM | WireEndHandling .............................31-14
31.8.13@SYSTEM | WireTypeInfo / Type information for
wires.......................................................................31-14
31.8.14@SYSTEM | DDM / DDM......................................31-14
31.8.14.1 CheckInKind / CheckInKind...................................31-15
31.8.14.2 CheckOutFolder / CheckOutFolder .......................31-15
31.9 BOOLEAN / Yes/No.....................................................31-15
32 BASE OBJECTS OF THE SYSTEM

32.1 @Local instance............................................................32-1
32.2 @System........................................................................32-1
32.2.1 @D Data ..................................................................32-1
32.2.1.1 @GRAPHICS ..........................................................32-1
32.2.1.2 @Layer working areas ............................................32-1
32.2.1.3 @R Revision ...........................................................32-1

32.2.1.4 @Status ..................................................................32-1
32.2.2 @O Interface............................................................32-1
32.2.2.1 @Bulk processing ...................................................32-2
32.2.2.2 @Print .....................................................................32-2
32.2.3 @T Tools..................................................................32-2
32.2.4 @Tree views in the Navigator ..................................32-2
32.2.5 @ Versions of the database.....................................32-2
33 IMPORT VIA ACTION OBJECTS

33.1 Tables.............................................................................33-1
33.1.1 Overview: Scope and concept .................................33-1
33.1.2 The interface of a table import operation .................33-2
33.1.2.1 Properties window of an action object.....................33-2
33.1.2.2 The interface in Draft mode.....................................33-2
33.1.2.3 The interface for Runtime mode (execute)..............33-6
33.1.3 Import sources .........................................................33-6
33.1.3.1 Access.....................................................................33-6
33.1.3.2 Excel........................................................................33-7
33.1.3.3 Text file....................................................................33-7
33.1.4 Script for import actions ...........................................33-8
33.1.4.1 Overview of an import script....................................33-8
33.1.4.2 Script modules.........................................................33-8
33.1.4.3 Declarations ..........................................................33-13
33.1.4.4 Example ................................................................33-14
33.2 XML data ......................................................................33-16
33.2.1 Scope and concept of the table import function .....33-16
33.2.2 Application..............................................................33-17
34 QUERY REIMPORT
34.1 Read the data into the query........................................34-1
34.2 Prepare the data............................................................34-2
34.3 Carry out the reimport ..................................................34-3
35 AUTOCAD (IMPORT, EXPORT DXF)

35.1 Export.............................................................................35-1
35.1.1 Preparations.............................................................35-1
35.1.2 Exporting ..................................................................35-2
35.1.3 Scope of the interface ..............................................35-3
35.2 Importing .......................................................................35-4
35.2.1 Importing an AutoCAD drawing................................35-4

35.2.2 Convert DWG drawing to PDS objects ....................35-6
35.2.3 Break down DWG drawing into planning objects .....35-7
35.2.3.1 DWG Mapping Editor ..............................................35-8
35.2.3.2 Other import settings ...............................................35-9
35.2.3.3 Central base data branch for DXF imports ..............35-9
35.2.3.4 Scope of the interface ...........................................35-10
35.2.4 Break down DWG drawing graphically...................35-11
36 CDI (COMOS DOCUMENT INTERFACE)

36.1 Excel...............................................................................36-1
36.1.1 Interface ...................................................................36-1
36.1.2 Comos -> Excel........................................................36-3
36.1.3 Comos -> Excel -> Comos .......................................36-4
36.2 Word ...............................................................................36-9
36.2.1 Comos -> Word ........................................................36-9
36.3 Additional properties of Office documents ..............36-13
36.3.1 General tab ............................................................36-13
36.3.2 Specifications tab ...................................................36-13
36.3.3 “Excel sheet” / “Word” tab ......................................36-13
36.3.4 Revisions tab..........................................................36-14
36.4 Script help ...................................................................36-14
36.5 ComosXML object classes.........................................36-16
36.6 Document ....................................................................36-16
36.6.1 Property..................................................................36-16
36.6.1.1 Pointer ...................................................................36-16
36.7 SCGlobal ......................................................................36-16
36.7.1 Function .................................................................36-16
36.7.1.1 ExcelABC ..............................................................36-16
36.7.2 Property..................................................................36-16
36.7.2.1 Document ..............................................................36-16
36.7.2.2 Project ...................................................................36-16
36.7.2.3 ReportObject .........................................................36-17
36.7.2.4 WorkSet.................................................................36-17
36.7.3 Sub.........................................................................36-17
36.7.3.1 Content..................................................................36-17
36.7.3.2 ContentFix .............................................................36-17
37 RNE (REPORT TO EXCEL)

37.1 Area of application........................................................37-1

37.2 Preparation of the Evaluation Report .........................37-1
37.3 Start export....................................................................37-1
37.4 Control via the options script ......................................37-1
37.5 Reimport ........................................................................37-3
38 XML / MOTIONX
38.1 Overview ........................................................................38-1
38.2 Navigator display for XML documents .......................38-1
38.3 Linking specifications and XML attributes .................38-4
38.4 Free import / export (XML Connectors) ......................38-5
38.4.1 Aim / basic principles of XML Connectors................38-5
38.4.2 Implementation in the interface ................................38-9
38.4.3 XML template (XML Connector template) ..............38-11
38.4.4 Configuring queries for XML ..................................38-12
38.4.4.1 Changing templates ..............................................38-12
38.4.4.2 Properties of a column, Extras ..............................38-13
38.4.4.3 Options of a column, MotionX ...............................38-15
38.4.5 XML Document (XML Connector document) .........38-17
38.4.5.1 Properties ..............................................................38-17
38.4.5.2 Export ....................................................................38-18
38.4.5.3 Import ....................................................................38-19
38.4.6 Configure XML Connector......................................38-20
38.4.6.1 Preparations ..........................................................38-21
38.4.6.2 Interface ................................................................38-21
38.4.6.3 Application.............................................................38-24
38.4.7 Script for the XML Connector.................................38-24
38.5 MotionX Server............................................................38-28
38.5.1 Objective ................................................................38-28
38.5.2 Installation ..............................................................38-28
38.5.2.1 Comos 8.1 .............................................................38-28
38.5.2.2 Comos 8.2 .............................................................38-29
38.5.3 Uninstallation..........................................................38-30
38.5.4 Administration ........................................................38-30
38.5.4.1 MotionX Server configuration file .........................38-30
38.5.4.2 Edit command file..................................................38-31
38.5.4.3 Sequence ..............................................................38-33
38.5.4.4 Process figure .......................................................38-34
38.5.4.5 Response messages in Comos.............................38-35
38.5.4.6 Log files .................................................................38-35
38.5.5 Example files..........................................................38-35
38.5.5.1 ComosMotionXServerManager.config ..................38-35

38.5.5.2 Command files ......................................................38-36
38.5.6 Appendix 1: Synchronization of the SharedFolder .38-37
38.5.7 Appendix 2: Participating files ................................38-38
39 OTHER INTERFACES
39.1 Comos-Comos (import, export) ...................................39-1
39.2 Comos-Comos (import planning projects) .................39-1
39.3 Comos-Comos (import system project) .....................39-2
39.4 Translations (import, export) .......................................39-2
39.5 WMF data (import) ........................................................39-2
39.6 Report templates (import) ............................................39-2
40 DOCUMENT MANAGEMENT (DQM)

40.1 Overview ......................................................................40-1
40.2 Preparing the base data of document groups ...........40-1
40.3 Creating and structuring document groups...............40-2
40.3.1 Creating document group systems manually ...........40-2
40.3.2 Automatic unit or location hierarchy .........................40-2
40.4 Revisioning document groups ....................................40-3
40.5 Automatic page number ...............................................40-3
40.6 Automatic reference creation ......................................40-5
40.6.1 Overview ..................................................................40-5
40.6.2 Basic technology (determine reference documents) 40-6
40.6.2.1 Project option ..........................................................40-6
40.6.2.2 Syntax conventions (String comparison of prefix) ...40-7
40.6.2.3 Substring comparison..............................................40-7
40.6.3 Generating names of reference documents.............40-8
40.6.4 Generating virtual page numbers .............................40-9
40.6.5 Generating or deleting references..........................40-11
40.6.6 Optional: Set additional pointer ..............................40-12
40.6.7 Consequences with other Comos functionalities ...40-14
40.7 @REPORTS Document Group ..................................40-14
40.8 Drag&Drop - Import @DocumentTypeMapping .......40-15
40.9 Full-text search ...........................................................40-16
40.9.1 Objective ................................................................40-16

40.9.2 Interaction with the working layers .........................40-16
40.9.3 Project options .......................................................40-17
40.9.4 Administration of full-text search ............................40-18
40.9.5 “Full-text search” plugIn .........................................40-19
40.9.5.1 Profile object of full-text search .............................40-19
40.9.5.2 Options ..................................................................40-20
40.9.5.3 Standard search ....................................................40-21
40.9.5.4 Complex search queries........................................40-22
40.9.5.4.1 Wildcards (“placeholders”).....................................................40-22
40.9.5.4.2 Regular expressions ................................................................40-24
40.9.5.4.3 Boolean search ........................................................................40-25
40.9.5.5 Attributed search ...................................................40-27
40.9.5.6 Search results / Hit list...........................................40-30
40.9.6 Checklist if a document is not found ......................40-31
40.9.7 Performance...........................................................40-32
41 REVISIONS
41.1 Creating revision base objects (revision types) ........41-1
41.1.1 General ....................................................................41-1
41.1.2 Structure of a revision base object / revision table...41-1
41.1.2.1 The "revision carrier" ...............................................41-1
41.1.2.2 The revision elements / revision steps ....................41-2
41.1.2.3 Creating multiple revision base objects...................41-4
41.1.3 "@Project" revision ..................................................41-4
41.1.4 Switching off animation ............................................41-4
41.2 Base object of a document: Selecting the revision type .
41-5
41.3 Preparing group revisions ...........................................41-5
41.3.1 Base objects of a document group: Selecting the
revision type .............................................................41-5
41.3.2 Planning objects for document groups.....................41-5
41.4 The "Index" of a revision..............................................41-6
41.5 Project options: Revision options...............................41-7
41.5.1 The general revision procedure ("PDF at first step") 41-7
41.5.1.1 Overview .................................................................41-7
41.5.1.2 "PDF at first step" ....................................................41-8
41.5.1.3 "Create PDF file at first step": deactivated .........41-9
41.5.2 Revision monitoring..................................................41-9
41.5.2.1 Overview .................................................................41-9
41.5.2.2 Basic settings (Project settings) ..............................41-9
41.5.2.3 Report templates: AutoWatchRevisions................41-11
41.5.3 Report comparison method: Timestamp ................41-11

41.5.3.1 Monitored objects ..................................................41-11
41.5.3.2 Monitored properties .............................................41-12
41.5.3.3 The timestamps .....................................................41-12
41.5.4 Report comparison method: Content (text) ............41-13
41.5.4.1 Function overview .................................................41-13
41.5.4.2 Data comparison across the revision ....................41-14
41.5.4.3 Deleted rows .........................................................41-16
41.5.4.4 Uniqueness of names............................................41-16
41.5.4.5 Preparations / options ...........................................41-17
41.5.4.6 Asterisk revisions ..................................................41-18
41.5.5 Switching between content comparison and
timestamp comparison ...........................................41-18
41.5.6 Revision settings: Revision archive (printer driver) 41-20
41.5.6.1 Purpose of the "Revision archive" .........................41-20
41.5.6.2 Installation of printer driver ....................................41-20
41.5.6.3 Special features of the individual revision printer ..41-21
41.5.6.3.1 "Tiff" settings ......................................................................... 41-21
41.5.6.3.2 "None" setting ........................................................................ 41-24
41.5.6.3.3 Settings for PDF ..................................................................... 41-24
41.5.6.3.4 "User-defined" setting ............................................................ 41-24
41.5.6.4 Configuration of the printer driver: Security
settings ..................................................................41-24
41.5.7 Revision settings: further options ...........................41-25
41.6 Revisioning in working layers (no @Project)...........41-26
41.7 Release manager / Plant revision manager ..............41-27
41.7.1 Background: Matching across layers .....................41-27
41.7.2 Operation ...............................................................41-29
41.8 Effect of revisions on reports ....................................41-30
41.8.1 Revision monitoring in the Interactive report
(Revision rectangles) .............................................41-30
41.8.2 Revision table in the report (presentation) .............41-31
41.8.3 Texts ......................................................................41-32
41.8.4 Evaluation of revision data in the report script .......41-32
41.8.4.1 Overview through the DocHeader.dll ....................41-32
41.8.4.2 Generating MaxRevisionIndexOf / Revision index 41-33
41.8.4.3 Checking manual details on user and date ...........41-34
41.8.4.4 Functions for "Revisioning"....................................41-35
41.8.5 Miscellaneous ........................................................41-35
41.9 Rights administration for revisions ..........................41-35
41.10Revision tab/ Revision table......................................41-36
41.11The first revision/ opening a report for the first time.......
41-37
41.12Programming notes....................................................41-38

41.13Data synchronization/ Updating................................41-39
41.13.1Data synchronization between open interfaces.....41-39
41.13.2Updating reports....................................................41-40
41.14Checklist .....................................................................41-40
41.15Storage of revision files.............................................41-42
42 LANGUAGES (LOCALIZATION)
42.1 General...........................................................................42-1
42.1.1 Language areas in Comos .......................................42-1
42.1.1.1 The program interface (interface language) ............42-1
42.1.1.2 The database (project language) ............................42-1
42.1.1.3 Template files ..........................................................42-2
42.1.2 Combination of language areas ...............................42-2
42.1.3 Technical background ..............................................42-3
42.2 Interface language ........................................................42-3
42.3 Project languages .........................................................42-3
42.3.1 Switching languages / language management ........42-3
42.3.1.1 Language management (Languages tab)..............42-3
42.3.1.2 Mouse-menus on the Languages tab ....................42-5
42.3.1.3 Application...............................................................42-6
42.4 Translation of project data ...........................................42-9
42.4.1 Translating attributes................................................42-9
42.4.1.1 Procedure:...............................................................42-9
42.4.1.2 Technical background ...........................................42-10
42.4.2 Translate “description” (object language translation) ......
42-10
42.4.2.1 Application.............................................................42-10
42.4.2.2 Editing multiple objects one after another .............42-11
42.4.2.3 Relationship between base objects and
planning objects ....................................................42-11
42.4.3 Translation of multiple objects ...............................42-12
42.4.4 Translation of ComosDB .......................................42-15
42.4.4.1 Interface of the dialog window...............................42-15
42.4.4.2 Carrying out an export operation...........................42-16
42.4.4.3 Carrying out an import operation...........................42-20
42.5 Language-dependent selection of template files.....42-21
42.6 Exclusions ...................................................................42-22
43 DESIGNER (2D-DRAWINGS)
43.1 General operation of the interface ..............................43-1

43.1.1 Copy/Move ...............................................................43-1
43.1.2 Zoom / Move ............................................................43-2
43.1.3 Placing with drag & drop ..........................................43-3
43.1.4 Placing templates .....................................................43-4
43.1.5 Standard toolbar.......................................................43-5
43.2 The design tools ...........................................................43-7
43.2.1 The Identifier tool .....................................................43-7
43.2.2 The Line tool ............................................................43-8
43.2.2.1 Line parameters ......................................................43-8
43.2.2.2 Lines: expanded design (construction) mode..........43-9
43.2.3 The Circle tool ..........................................................43-9
43.2.4 Placing text ............................................................43-11
43.2.4.1 Text defaults..........................................................43-11
43.2.4.2 Text properties ......................................................43-12
43.2.5 Hatching .................................................................43-12
43.2.6 Transforming ..........................................................43-13
43.2.7 Toggling Design mode ...........................................43-15
43.3 Status bar ....................................................................43-15
43.4 Layers in reports ........................................................43-16
43.4.1 Setting up layers for reports ...................................43-16
44 MULTICRP.EXE
44.1 Objective........................................................................44-1
44.2 Selecting reports...........................................................44-1
44.3 Manual search and replace ..........................................44-2
44.4 Re-establish uniqueness of names .............................44-3
45 SYMBOL-DESIGNER
45.1 Background: types of diagrams ..................................45-1
45.2 General rules for designing symbols..........................45-1
45.3 Toolbar ...........................................................................45-3
45.3.1 Properties of a text (text parameters) ......................45-3
45.3.1.1 Text defaults............................................................45-4
45.3.1.2 Text parameter: properties ......................................45-4
45.3.2 Set origin ..................................................................45-5
45.4 Properties of a text .......................................................45-6
45.4.1 Text functions...........................................................45-6

45.4.1.1 Overview .................................................................45-6
45.4.1.2 AllMyReferences .....................................................45-8
45.4.1.3 Ansi1 .......................................................................45-9
45.4.1.4 Ansi2 .......................................................................45-9
45.4.1.5 BltPfd.....................................................................45-10
45.4.1.6 ComosDevSpec ....................................................45-10
45.4.1.7 ComosElmSpec.....................................................45-11
45.4.1.8 ComosSegSpec ....................................................45-12
45.4.1.9 ComosSpec...........................................................45-13
45.4.1.10 DetailReference.....................................................45-14
45.4.1.11 DevAllDescription ..................................................45-14
45.4.1.12 DevContact............................................................45-14
45.4.1.13 DevDescription ......................................................45-14
45.4.1.14 DevFunction ..........................................................45-15
45.4.1.15 DevGUnit...............................................................45-15
45.4.1.16 Device ...................................................................45-16
45.4.1.17 Device.FullName ...................................................45-16
45.4.1.18 DevLocation ..........................................................45-17
45.4.1.19 DevLocation1L ......................................................45-17
45.4.1.20 DevName ..............................................................45-18
45.4.1.21 DevPosition ...........................................................45-19
45.4.1.22 DevSignalDescription ............................................45-19
45.4.1.23 DevType ................................................................45-19
45.4.1.24 DevTypeL ..............................................................45-19
45.4.1.25 DevTypeW.............................................................45-20
45.4.1.26 DevUnit..................................................................45-20
45.4.1.27 DevUnit1L..............................................................45-21
45.4.1.28 DevUnitPosition.....................................................45-21
45.4.1.29 Element .................................................................45-22
45.4.1.30 Elements ...............................................................45-22
45.4.1.31 Elm..CO.................................................................45-23
45.4.1.32 Elm..CP .................................................................45-23
45.4.1.33 Elm..DS .................................................................45-24
45.4.1.34 Elm..Label .............................................................45-24
45.4.1.35 Elm..VW ................................................................45-25
45.4.1.36 FromDoc................................................................45-25
45.4.1.37 FromDocObj ..........................................................45-25
45.4.1.38 Function.................................................................45-26
45.4.1.39 MainDevice............................................................45-26
45.4.1.40 Position..................................................................45-26
45.4.1.41 PotAllDescription ...................................................45-27
45.4.1.42 PotDescription .......................................................45-27
45.4.1.43 PotLocation ...........................................................45-27
45.4.1.44 PotName ...............................................................45-27
45.4.1.45 PotUnit...................................................................45-27
45.4.1.46 Rack ......................................................................45-28
45.4.1.47 RefChain ...............................................................45-28
45.4.1.48 Reference..............................................................45-28
45.4.1.49 RefMaster..............................................................45-29
45.4.1.50 RefSimple..............................................................45-29
45.4.1.51 ReportScript ..........................................................45-29
45.4.1.52 Requirement..........................................................45-29
45.4.1.53 Rqmt......................................................................45-30
45.4.1.54 Rqmts ....................................................................45-30

45.4.1.55 Slot ........................................................................45-30
45.4.1.56 ToDoc....................................................................45-30
45.4.1.57 ToDocObj ..............................................................45-30
45.4.1.58 UserFunction .........................................................45-30
45.4.2 Sub-symbols ..........................................................45-32
45.4.2.1 Text symbol ...........................................................45-32
45.4.2.2 Element .................................................................45-32
45.4.2.3 Attribute .................................................................45-33
45.4.2.4 Base object............................................................45-34
45.4.3 Connection points ..................................................45-34
45.4.3.1 Connection point ...................................................45-34
45.5 Symbol script ..............................................................45-36
45.5.1 ScriptHeader commands........................................45-36
45.5.2 Tips & tricks............................................................45-38
45.5.2.1 Security .................................................................45-38
45.5.2.2 Container...............................................................45-38
45.5.2.3 CurrentTrans .........................................................45-39
45.5.2.4 Demo script for fill areas........................................45-39
45.5.2.5 User-defined grab points .......................................45-41
45.5.2.6 GetAllPropertiesAndMethodsByObject .................45-42
45.5.2.7 Deactivating the scaling and rotation grab points..45-42
46 REPORT DESIGNER
46.1 Background: Types of diagrams .................................46-1
46.2 General operation of the interface ..............................46-1
46.2.1 Toolbar .....................................................................46-1
46.2.2 Context-sensitive mouse menus ..............................46-2
46.2.2.1 Insert object.............................................................46-2
46.2.2.2 Import / export scripts ..............................................46-4
46.2.2.3 Correction function ..................................................46-4
46.2.3 Options: worksheet parameters and script ..............46-5
46.3 The toolbar ....................................................................46-6
46.3.1 Placing texts.............................................................46-6
46.3.1.1 Text Defaults ...........................................................46-7
46.3.1.2 Text properties .......................................................46-7
46.3.1.3 Properties window ...................................................46-8
46.3.1.4 Type “ReportObject-Property” ...............................46-11
46.3.1.5 Type “Expression” .................................................46-11
46.3.1.6 Type “Script”..........................................................46-12
46.3.1.7 Type “Item-Property” .............................................46-13
46.3.1.8 Type “Fixed” ..........................................................46-14
46.3.1.9 Type “Attribute”......................................................46-14
46.3.2 Switch / Options switch .........................................46-17
46.3.2.1 General tab............................................................46-18
46.3.2.2 Properties tab ........................................................46-18
46.3.2.3 Type “ReportObject-Property” ...............................46-18

46.3.2.4 Type “Expression” .................................................46-18
46.3.2.5 Type “Script”..........................................................46-19
46.3.2.6 Type “Item-Property” .............................................46-19
46.3.3 Determining the working area / setting the origin...46-19
46.3.4 Place Windows metafile ........................................46-20
46.3.5 Place picture frame ................................................46-22
46.3.6 Place list ................................................................46-23
46.3.6.1 Place list frame......................................................46-23
46.3.6.2 List parameters (properties of the list)...................46-24
46.3.6.2.1 General tab .........................................................................46-24
46.3.6.2.2 Rows tab..................................................................................46-25
46.3.6.2.3 Script tab..............................................................................46-25
46.3.6.3 Create sub-report manually...................................46-27
46.3.6.4 Automatically generate sub-reports.......................46-28
46.3.7 Place sub-report.....................................................46-29
46.3.8 Graphic objects ......................................................46-31
46.3.9 Place attribute .......................................................46-34
46.4 Script options in reports ............................................46-36
46.4.1 Overview of script options ......................................46-37
46.4.2 Reference of the script options ..............................46-40
46.4.2.1 AnsiWiringRadius (Double) ...................................46-40
46.4.2.2 Application (String) ................................................46-40
46.4.2.3 AutoConnectExternObjects (Boolean) ..................46-40
46.4.2.4 AutoDistributeTerminals (Boolean) .......................46-41
46.4.2.5 AutoLoop (Boolean) ..............................................46-41
46.4.2.6 AutoLoopCables (Boolean) ...................................46-41
46.4.2.7 AutoLoopConnectorLayers (Long) ........................46-41
46.4.2.8 AutoLoopDebug (Boolean)....................................46-41
46.4.2.9 AutoLoopFactor (Long) .........................................46-41
46.4.2.10 AutoLoopFilter (String) ..........................................46-41
46.4.2.11 AutoMarkAsChanged (Boolean)............................46-42
46.4.2.12 AutoSaveDocument (Boolean)..............................46-42
46.4.2.13 AutoStartLoop (Boolean).......................................46-42
46.4.2.14 AutoWatchRevisions (Boolean).............................46-42
46.4.2.15 CableObjectVersion (Long) ...................................46-43
46.4.2.16 CheckDocObjects (Boolean) .................................46-43
46.4.2.17 CheckIOConsistency (Boolean) ............................46-43
46.4.2.18 CObjectFullNameForPipe (String).........................46-43
46.4.2.19 ConcessionRI (Boolean) .......................................46-43
46.4.2.20 ConnectionHook (Double) .....................................46-44
46.4.2.21 ConnectionLineMode (String)................................46-44
46.4.2.22 ContactMirror_X (Double) .....................................46-44
46.4.2.23 ContactMirror_Y (Double) .....................................46-44
46.4.2.24 CopyConnectionDependentObjects (Boolean) .....46-44
46.4.2.25 CutLineWidth (Double) ..........................................46-44
46.4.2.26 DefaultIdRectsForSymbols (Boolean) ...................46-45
46.4.2.27 DeleteModePFD (Boolean) ...................................46-45
46.4.2.28 DimensionSymbol (String).....................................46-45
46.4.2.29 DimensionTextHeight (Double) .............................46-45

46.4.2.30 DimensionUnit (String) ..........................................46-45
46.4.2.31 DrawPipeConnectorSymbol (Boolean)..................46-46
46.4.2.32 DrawPipeEndSymbol (Boolean) ............................46-46
46.4.2.33 DrawPipeEndSymbolForSegment (Boolean) ........46-46
46.4.2.34 DrawTerminalSideMark (Long) .............................46-46
46.4.2.35 EnableButtonANSICable (Boolean) ......................46-46
46.4.2.36 EnableButtonOblique (Boolean) ............................46-46
46.4.2.37 EnableButtonSpline (Boolean) ..............................46-47
46.4.2.38 EnablePaging (Boolean) .......................................46-47
46.4.2.39 EnableProcessConnection (Boolean) ...................46-47
46.4.2.40 EnableProcessConnectionActor (Boolean) ...........46-47
46.4.2.41 EnableProcessConnectionSensor (Boolean) ........46-48
46.4.2.42 EnableSynchronizeNavigator (Boolean) ...............46-48
46.4.2.43 EXFConformable (Boolean) ..................................46-48
46.4.2.44 GeneralScaleFactor (Double)................................46-48
46.4.2.45 ListMaster (Boolean) .............................................46-48
46.4.2.46 PotentialProlongation (Double) .............................46-49
46.4.2.47 PreferredDirection (String) ....................................46-49
46.4.2.48 QuadrantOffsetLeft (Double) .................................46-49
46.4.2.49 QuadrantOffsetTop (Double).................................46-49
46.4.2.50 QuadrantSizeX (Double) .......................................46-49
46.4.2.51 QuadrantSizeY (Double) .......................................46-50
46.4.2.52 QuadrantStartChrX (String)...................................46-50
46.4.2.53 QuadrantStartChrY (String)...................................46-50
46.4.2.54 QuadrantStepX (Integer) .......................................46-50
46.4.2.55 QuadrantStepY (Integer) .......................................46-50
46.4.2.56 RestoreReferencesAfterCopy (Boolean) ...............46-50
46.4.2.57 ScaleForObjects (Boolean) ...................................46-51
46.4.2.58 SectorOffset (Integer)............................................46-51
46.4.2.59 SectorSize (Integer) ..............................................46-51
46.4.2.60 ShowConnectedWith (Boolean) ............................46-51
46.4.2.61 ShowConnectionInfo (Boolean).............................46-51
46.4.2.62 ShowLineModeControl (Boolean) .........................46-52
46.4.2.63 ShowSymbolBar (Boolean) ...................................46-52
46.4.2.64 SideView_X (Double) ............................................46-52
46.4.2.65 SignalLeftX (Double) .............................................46-52
46.4.2.66 SignalRightX (Double)...........................................46-52
46.4.2.67 SignalSlotCount (Double)......................................46-53
46.4.2.68 SignalSlotHeight (Double) .....................................46-53
46.4.2.69 SignalTopY (Double) .............................................46-53
46.4.2.70 SignalWidth (Double) ............................................46-53
46.4.2.71 SignalWidth1 (Double) ..........................................46-53
46.4.2.72 SignalWidthGraphic (Double) ................................46-53
46.4.2.73 SignByEmptyReference (Boolean)........................46-53
46.4.2.74 SnapPrecision (Double) ........................................46-54
46.4.2.75 SortNewObjectsInCategories (Boolean) ...............46-54
46.4.2.76 StdPipeFlagNoColor (Boolean) .............................46-54
46.4.2.77 StdPipeNoReflect (Boolean) .................................46-54
46.4.2.78 SuppressReference (Boolean) ..............................46-54
46.4.2.79 SymbolType (String)..............................................46-54
46.4.2.80 Unit ........................................................................46-55
46.4.2.81 VGBConnectionLength (Double)...........................46-55
46.4.2.82 WorkingBackupTime (Double) ..............................46-55
46.4.2.83 XXDocProgID (String) ...........................................46-56

46.5 Functions in reports ...................................................46-56
46.5.1 Functions for Text and List scripts .........................46-56
46.5.1.1 Property ComosDocument As Object.................46-56
46.5.1.2 Property AutoMarkAsChanged As Boolean .......46-56
46.5.1.3 Property EvalForEveryPage As Boolean ...........46-56
46.5.1.4 Property EvalSequence As Long ........................46-56
46.5.1.5 Property ItemObject As Object............................46-56
46.5.1.6 Property KeepScriptRunning As Boolean ..........46-57
46.5.1.7 Property Layer As Long .......................................46-57
46.5.1.8 Property LineType As Long .................................46-57
46.5.1.9 Function MainComosDocument() As Object .....46-57
46.5.1.10 Function MainReportDocument() As Document 46-57
46.5.1.11 Function MasterReportDocument() As
Document ..............................................................46-57
46.5.1.12 Property Name As String......................................46-57
46.5.1.13 Function ParentReportDocument() As Document......
46-57
46.5.1.14 Property Report As Object ...................................46-57
46.5.1.15 Function ReportDocument() As Document........46-57
46.5.1.16 Property Script As String ......................................46-58
46.5.1.17 Property SystemTypeName As String ................46-58
46.5.1.18 Sub ToBack() .......................................................46-58
46.5.1.19 Sub ToFront().......................................................46-58
46.5.1.20 Property Visible As Boolean ................................46-58
46.5.1.21 Property X1 As Double .........................................46-58
46.5.1.23 Property Y1 As Double .........................................46-58
46.5.2 Functions for List scripts only.................................46-59
46.5.2.1 Direction As Long ................................................46-59
46.5.2.2 Function EvalOneRow() As Long........................46-59
46.5.2.3 Function EvalOneRowDocument(RowObject As
Object, FileName As String, ComosDocument As
Object) As Long ....................................................46-59
46.5.2.4 Function EvalOneRowObject(Object As Object,
RowDocName As String) As Long........................46-59
46.5.2.5 Function EvaluatedRowCount() As Long...........46-59
46.5.2.6 Function EvaluatedRowDocument(Index As
Long) As Document ..............................................46-59
46.5.2.7 FileName As String..............................................46-59
46.5.2.8 Function NewPage() As Long .............................46-60
46.5.2.9 RowDocument As String .....................................46-60
46.5.2.10 Sub SetLineWrap() .............................................46-60
46.5.3 Functions for Text scripts only ...............................46-60
46.5.3.1 Align As String......................................................46-60
46.5.3.2 Angle As Double ..................................................46-60
46.5.3.3 BackColor As OLE_COLOR................................46-61
46.5.3.4 Clip As Long/Boolean...........................................46-61

46.5.3.5 FIT As Long/Boolean ............................................46-61
46.5.3.6 ForeColor As OLE_COLOR ................................46-61
46.5.3.7 Function MaxPageNr() As Long..........................46-61
46.5.3.8 Function MaxRevisionIndexOf(ItemsNames As
String) As String ....................................................46-61
46.5.3.9 Function ScriptObject() As Object.......................46-61
46.5.3.10 SoftAlign As Long ................................................46-61
46.5.3.11 text As String ........................................................46-62
46.5.3.12 Transparent As Long/Boolean.............................46-62
46.5.4 Functions for all scripts ..........................................46-62
46.5.4.1 Sub OutPutDebugString(s As String) ...............46-62
46.5.4.2 Property Report As Object ...................................46-62
46.5.4.3 Property ReportObject As Object........................46-62
46.5.4.4 Function CallScriptLib(CDevFullname As String,
FuncName As String, [Param1], [Param2], [Param3],
[Param4], [Param5], [Param6], [Param7], [Param8],
[Param9], [Param10]) ............................................46-62
46.5.4.5 Function DocHdr() As Object...............................46-63
46.5.4.6 Property Document As Object .............................46-63
46.5.4.7 Function GlobalPageNr() As Long......................46-63
46.5.4.8 Function DSpec(Chapter As String, OrgName As
String) As Object ...................................................46-63
46.5.4.9 Function OSpec(Chapter As String, OrgName As
String) As Object ...................................................46-63
46.5.4.10 Sub Output(s As String) .......................................46-63
46.5.4.11 Property PageNr As Variant.................................46-63
46.5.4.12 Property Project As Object...................................46-63
46.5.4.14 Function RevisionIndex(PltObject As Object)
As String................................................................46-64
46.5.4.15 Function RevisionLabel(PltObject As Object)
As String................................................................46-64
46.5.4.16 Function RevisionTableDate(RevLineNr As Long,
RevColumnNr As Long) As String.........................46-64
46.5.4.17 Function RevisionTableIndex(RevLineNr As
Long) As String......................................................46-64
46.5.4.18 Property FirstPageNr As Long ............................46-64
46.5.4.20 Property RevisionTableLength As Long ............46-64
46.5.4.21 Function RevisionTableUser(RevLineNr As Long,
RevColumnNr As Long) As String.........................46-65
46.5.4.22 Property Specs As Object ....................................46-65
47 DESIGNER AS INTERACTIVE REPORT

47.1 Toolbar ...........................................................................47-1
47.1.1 The Connection tool .................................................47-1
47.1.2 Types of lines and graphic properties of lines ..........47-2
47.1.2.1 User-defined line sample (USERLNTYPE) .............47-2
47.1.2.1.1 Basic principle.......................................................................... 47-2
47.1.2.1.2 Structure of standard table USERLNTYPE ............................. 47-3
47.1.2.1.3 Digression: Symbol structure ................................................... 47-3

47.1.2.2 Diagram-type-specific line types (LINETYPES) ......47-6
47.1.2.3 Connector-specific line types ..................................47-7
47.1.2.4 Line types in P&ID...................................................47-9
47.1.2.4.1 Overall systemology .................................................................47-9
47.1.2.4.2 Structure of @1RI|1|J and @1RI|1|K......................................47-11
47.1.2.4.3 Connector-specific line types..................................................47-12
47.1.2.4.4 Old versions ............................................................................47-12
47.1.2.5 Lines in EE ............................................................47-13
47.1.2.5.1 Connector-specific line types..................................................47-13
47.1.3 The Assign object tool (Identifier tool) ....................47-14
47.1.4 Text tool .................................................................47-14
47.1.4.1 Text defaults..........................................................47-14
47.1.4.2 Text properties ......................................................47-15
47.2 Placing a template on a report...................................47-16
47.3 Placing a report on a report .......................................47-16
47.4 Editing properties .......................................................47-17
47.5 Mouse menu ................................................................47-17
47.6 Copying and inserting on a report ............................47-19
47.7 Installation plans.........................................................47-19
47.7.1 Attributes ................................................................47-19
47.7.2 System templates and Standard tables .................47-19
47.7.3 Automatic rotation ..................................................47-20
47.7.4 Scaling symbols .....................................................47-20
47.7.5 Scale ......................................................................47-20
47.7.6 Oblique connections...............................................47-20
47.8 ANSI plans ...................................................................47-20
47.8.1 ANSI cables ...........................................................47-20
48 STANDARD TABLES OF BASE PROJECTS

48.1 SO1.................................................................................48-1
48.1.1 @1PE Process Engineering.....................................48-1
48.1.1.1 AE Aspen Units .......................................................48-1
48.1.1.1.1 DELTA-T Aspen units..............................................................48-1
48.1.1.1.2 HEAD Aspen units ...................................................................48-2
48.1.1.2 CA Attributes-Catalog..............................................48-2
48.1.1.3 EQ Equipment .........................................................48-2
48.1.1.3.1 ND0227 - ND0229 TEMA character........................................48-2
48.1.1.4 HE HTFS Physical Units .........................................48-2
48.1.1.5 IO Import Options ....................................................48-3
48.1.1.5.1 ND0931.....................................................................................48-3
48.1.1.5.2 ND0932.....................................................................................48-3
48.1.1.6 NORM ANSI/DIN Catalog .......................................48-4

48.1.1.7 SYS System ............................................................48-4
48.1.1.7.1 1 Graphic representation .......................................................... 48-4
48.1.1.7.2 @NC Naming convention ........................................................ 48-5
48.1.1.7.3 @UNITSYSTEMS Unit systems ............................................. 48-6
48.1.1.7.4 BOOL ....................................................................................... 48-6
48.1.1.7.5 ND0208 Routing status ............................................................ 48-6
48.1.1.7.6 NSYS Standard system ............................................................ 48-6
48.1.1.7.7 SY0001 Object classes ............................................................. 48-6
48.1.1.8 TD Technical data ...................................................48-6
48.1.1.8.1 ND0238 .................................................................................... 48-6
48.1.1.8.2 ND0250 .................................................................................... 48-7
48.1.1.9 XX Other..................................................................48-7
48.1.1.9.1 TRAYSYMBOLTYPE ............................................................ 48-7
48.1.2 @1RI / RI catalog.....................................................48-7
48.1.2.1 1 Presentation .........................................................48-7
48.1.2.1.1 E Symbol description ............................................................... 48-7
48.1.2.1.2 J / Logocad line types............................................................... 48-7
48.1.2.1.3 K / Line types for action lines .................................................. 48-7
48.1.2.2 3 Device data ..........................................................48-8
48.1.2.2.1 P Function................................................................................. 48-8
48.1.3 @3D 3D/ISO Catalog...............................................48-8
48.1.4 @3DCM Catalog 3D ................................................48-8
48.1.5 @EXF.......................................................................48-8
48.1.6 @IRF_<diagram type> z.B.: @IRF_DETAIL............48-8
48.1.7 @Local .....................................................................48-9
48.1.8 @SYSTEM / Tables for Comos ...............................48-9
48.1.8.1 @SYSTEM | @AREA / Sheet area .........................48-9
48.1.8.2 @SYSTEM | @BRIDGESYMBOLS / Bridge
symbols ...................................................................48-9
48.1.8.3 @SYSTEM | @CLASS | <diagram type> / Header
classes ....................................................................48-9
48.1.8.4 @SYSTEM | @CONNECTION / Connection ........48-10
48.1.8.5 @SYSTEM | @IMP_ARROW / Implementation
arrows....................................................................48-10
48.1.8.6 @SYSTEM | @LINETYPES | <diagram type,
list> / Line types.....................................................48-10
48.1.8.7 @SYSTEM | @MASK / Masks (default) AKZ........48-10
48.1.8.8 @SYSTEM | @MASK01 / Masks (KKS) ...............48-10
48.1.8.9 @SYSTEM | @MASK02 / Masks (ANSI metric) ...48-10
48.1.8.10 @SYSTEM | @PIPECONSYMBOL / Pipe: sheet
reference symbol ...................................................48-11
48.1.8.11 @SYSTEM | @PIPEENDSYMBOL /Pipe termination
symbols .................................................................48-11
48.1.8.12 @SYSTEM | @PipeCutMode Pipe cut mode........48-11
48.1.8.13 .@SYSTEM | @S7Classes / S7 classes...............48-11
48.1.8.14 @SYSTEM | @UNITMAPPING / Representation of
English and metric systems...................................48-11
48.1.8.15 @SYSTEM | @USERLNTYPE / User-defined
line types ...............................................................48-11

48.1.9 ET Electrical engineering .......................................48-12
48.1.10FP Functional engineering ....................................48-12
48.1.11FT Fluid engineering .............................................48-12
48.1.12IC Catalog I&C ......................................................48-12
48.1.12.1 S Signal .................................................................48-12
48.1.12.1.1 IOA System signal mode ........................................................48-12
48.1.13ME Mechatronic ....................................................48-12
48.1.14PI Catalog P&I.......................................................48-12
48.1.14.1 Y Attributes catalog ...............................................48-13
48.1.14.1.1 0 Attribute collection ..............................................................48-13
48.1.15RIDIVPOS /P&I measuring position lettering ........48-20
48.1.16RIFLOWDIRSYMBOL / P&I Flow direction
symbol....................................................................48-20
48.1.17RILNTYPE / Pipe identification..............................48-20
48.1.18RIST / Substance stream properties .....................48-20
48.1.19RK Pipe class ........................................................48-20
48.2 SO1_EXT......................................................................48-21
48.2.1 eCl@ss...................................................................48-21
49 DESIGNING DATABASES (CUSTOMIZING)

49.1 Definitions .....................................................................49-1
49.1.1 Relationship between base objects and planning
objects......................................................................49-1
49.1.2 Local base objects ...................................................49-2
49.1.3 The tree structure: Hierarchies.................................49-2
49.1.4 Information transfer: inheriting .................................49-3
49.2 Creating new base objects...........................................49-3
49.3 Database adjustment....................................................49-3
49.4 Preallocating connectors .............................................49-5
49.4.1 Preparing wires ........................................................49-5
49.4.1.1 Specific wires ..........................................................49-5
49.4.1.2 Non-specific wires (only with virtual elements)........49-6
49.4.2 Preparing logical potentials ......................................49-6
49.4.3 Preparing signals .....................................................49-7
49.5 Templates ......................................................................49-8
49.5.1 Definition ..................................................................49-8
49.5.2 Organizing / preparing templates .............................49-9
49.5.3 Structure / retaining the structure .............................49-9

49.5.4 Determining the positioning....................................49-10
49.5.5 Variants ..................................................................49-10
49.5.6 Using templates .....................................................49-11
49.6 Labeling systems ........................................................49-11
49.7 Alias for labels ............................................................49-14
49.7.1 Objective ................................................................49-14
49.7.2 Precondition ...........................................................49-14
49.7.3 Application..............................................................49-14
49.7.3.1 Step 1 ....................................................................49-14
49.7.3.2 Step 2 ....................................................................49-14
49.7.3.3 Step 3 ....................................................................49-15
49.7.3.4 Step 4 ....................................................................49-17
49.7.4 Effect ......................................................................49-17
49.7.5 “AliasLabel” script commands ................................49-18
49.8 Categories ...................................................................49-18
49.8.1 Administration ........................................................49-18
49.8.2 Application example EE/I&C ..................................49-19
49.8.3 Application examples P&ID ....................................49-19
49.9 New document: report template ................................49-20
49.9.1 Overview ................................................................49-20
49.9.2 Creating a new document of type “report
template” ................................................................49-22
49.10Creating ready-made reports ....................................49-23
49.10.1Create report .........................................................49-23
49.10.2Documents under the base object of the document
group ......................................................................49-25
50 BASE OBJECTS OF THE RELEASE DATABASE

50.1 @Local instance............................................................50-1
50.2 @1EA standard catalog EE ..........................................50-1
50.3 @1EB standard catalog ANSI ......................................50-1
50.4 @1EI standard catalog IE .............................................50-1
50.5 @1EM standard catalog I&C ........................................50-1
50.6 @1FP standard catalog FD ..........................................50-1
50.6.1 @Template...............................................................50-2
50.7 @1PE standard catalog PE Data .................................50-2

50.8 @1RI standard catalog Plant and Piping Design .......50-2
50.9 @3D 3D planning ..........................................................50-2
50.9.1 @A Attributes ...........................................................50-2
50.9.2 @AXIS .....................................................................50-2
50.9.3 1 Components..........................................................50-2
50.9.4 2 Data catalog ..........................................................50-3
50.9.5 3 Pipe classes ..........................................................50-3
50.9.6 4 Structural steelwork...............................................50-3
50.9.7 5 Assemblies............................................................50-3
50.9.8 9 Other .....................................................................50-3
50.10@C Costs hookup ........................................................50-3
50.10.1@01 Costs hookup accessory ................................50-3
50.11@F Functions................................................................50-3
50.12@G Document Groups.................................................50-4
50.13@J Project.....................................................................50-4
50.14@K Routing / ducting...................................................50-4
50.15@KD Catalog data PE ..................................................50-4
50.16@L Locations................................................................50-5
50.17@M Maintenance ..........................................................50-5
50.18@O Documents.............................................................50-5
50.19@P Position ..................................................................50-5
50.20@Q Actions: Decision tables and queries .................50-6
50.20.1@Q Actions | SC Script ...........................................50-6
50.21@S Signals....................................................................50-6
50.22@ Template ...................................................................50-6
50.23@U Units .......................................................................50-6
50.24@Device views..............................................................50-7
50.25@Y Attributes catalog ..................................................50-7
50.26ASPEN Import attribute................................................50-7
50.27eCl@ss 4.0 ....................................................................50-7
50.28FT Fluid technology .....................................................50-8
50.29GF Graphic symbols ....................................................50-8
50.30Import ............................................................................50-8

50.30.1@DXF .....................................................................50-8
50.30.2@EXF......................................................................50-8
50.30.3@PDS .....................................................................50-8
50.30.4VNS .........................................................................50-9
50.31Pro II Simulation objects..............................................50-9
51 FEED – INTERFACES TO SIMULATORS

51.1 Scope .............................................................................51-1
51.2 Preconditions ................................................................51-2
51.2.1 Comos......................................................................51-2
51.2.1.1 General settings and preconditions .........................51-2
51.2.1.2 Initial planning structure in Comos ..........................51-2
51.2.2 Simulators ................................................................51-4
51.2.2.1 Versions ..................................................................51-4
51.2.2.2 Aspen Plus: options for XML nodes ........................51-4
51.2.2.3 Mapping of units between Aspen Plus and Comos .51-6
51.3 Technical sequence......................................................51-6
51.3.1 Importing the main case...........................................51-7
51.3.1.1 Import object level 1 ................................................51-7
51.3.1.2 Step 1: Starting the import.......................................51-9
51.3.1.3 Step 2: Creating the Comos PFD objects .............51-11
51.3.1.4 Steps 3 and 4: Placing the objects ........................51-17
51.3.2 Importing subcases ................................................51-20
51.3.2.1 Import object level 2 ..............................................51-20
51.3.2.2 Step 1: Importing the data .....................................51-21
51.3.2.3 Step 2: Creating the run case for PFD objects ......51-21
51.4 Base data, attributes, standard tables ......................51-22
51.4.1 “@1PE|PO|SIM Simulation Objects” ......................51-23
51.4.1.1 Properties of the simulation objects ......................51-23
51.4.1.2 “@1PE|PO|SIM|BLC Equipment Simulation
Objects” .................................................................51-25
51.4.1.3 “@1PE|PO|SIM|STR Stream Simulation Objects” 51-27
51.4.1.3.1 “...|CCSIM CompCalc Simulation Object”............................ 51-27
51.4.1.3.2 “...|MSSIM Material Stream Simulation Object”................... 51-28
51.4.1.4 “@1PE|PO|SIM|SUB Simulation Subobjects” .......51-29
51.4.1.4.1 “.|SIM|SUB|HCSIM Heating Curve Simulation Object”....... 51-29
51.4.1.4.2 “...|SIM|SUB|LHCSIM LNG Cells Simulation Object” ........ 51-29
51.4.1.4.3 “...|SIM|SUB|MAPSIM Component Simulation Object” ...... 51-30
51.4.1.4.4 “...|SIM|SUB|TRSIM Column Tray Simulation Object” ....... 51-31
51.4.1.5 “@1PE|PO|SIM|XXSI Simulation Import objects”..51-31
51.4.1.5.1 “...|AXSI Aspen XML Simulation Import”............................ 51-31
51.4.1.5.2 “...|AXSI1 Aspen XML Simulation Import (Case)” .............. 51-34
51.4.1.5.3 “...|SIMCASE Simulation Case” ............................................ 51-34
51.4.2 PFD objects............................................................51-34

51.4.2.1 “@1PE|PO|EQ equipment” ...................................51-35
51.4.2.1.1 Properties general....................................................................51-35
51.4.2.1.2 “...|EQ|02|COL Column” ........................................................51-36
51.4.2.1.3 “...EQ|04|HEX Heat Exchanger” ............................................51-37
51.4.2.1.4 “...|EQ|04|LNG Heat Exchanger” ...........................................51-37
51.4.2.1.5 “...|EQ|08 Components|CCS|TRA Tray Layout (General)”....51-37
51.4.2.1.6 “...|EQ|08 Components|CELL LNG Heat Exchanger Cell”....51-37
51.4.2.1.7 “...|EQ|08 Components |COS Column Section” .....................51-38
51.4.2.2 “@1PE|PO|EC Equipment Case”..........................51-38
51.4.2.2.1 Properties general....................................................................51-38
51.4.2.2.2 “...|EC|02|COLEC” .................................................................51-39
51.4.2.2.3 “...|EC|08|CCS|TRAEC Tray Layout (General)”....................51-39
51.4.2.3 “@1PE|PO|SO|MAP Component Pointer” ............51-39
51.4.2.4 “@1PE|PO|SO|MAS Components”: Pure Compo-
nents Library..........................................................51-41
51.4.2.5 “@1PE|PO|SO|MS Material Stream”.....................51-42
51.4.2.6 “@1PE|PO|SO|PS Process Stream” .....................51-44
51.4.3 “@1PE|DS Data Structures” ..................................51-47
51.4.3.1 „@1PE|DS|@O Documents“ .................................51-47
51.4.3.1.1 “...||PRZ ProII Simulation Import” .........................................51-47
51.4.3.1.2 “...|HYSYS PRO/II Simulation Import” .................................51-50
51.4.3.2 “@1PE|DS|@Y CA Attributes Catalog” .................51-51
51.4.3.3 “@1PE|DS|CC Tab Catalog”.................................51-51
51.4.4 Standard tables ......................................................51-52
51.5 Modification of the standard import..........................51-52
51.5.1 Overview ................................................................51-52
51.5.2 Import objects: BUTTON1 to BUTTON4 ................51-53
51.5.3 Simulation objects ..................................................51-54
51.5.3.1 Overview ...............................................................51-54
51.5.3.2 Import()..................................................................51-56
51.5.3.3 ImportDone() .........................................................51-56
51.5.3.4 SimulatorImport()...................................................51-57
51.5.3.5 SimulatorImportDone() ..........................................51-57
51.5.4 Aspen Plus: Class AspenNode ..............................51-57
51.5.4.1 Properties ..............................................................51-58
51.5.4.2 Read() ...................................................................51-60
51.5.4.3 ReadArray()...........................................................51-62
51.5.4.4 CreateSubObjects()...............................................51-64
51.5.4.5 XMLValueExists()..................................................51-64
51.5.5 PRO/II: Class ProIINode ........................................51-65
51.5.5.1 Properties ..............................................................51-66
51.5.5.2 Read() ...................................................................51-67
51.5.5.3 ReadArray()...........................................................51-68
51.5.5.4 ReadArrayToFewSpecs()......................................51-69
51.5.5.5 ReadSI() ................................................................51-69
51.5.5.6 GetComosSpecArray() ..........................................51-70
51.5.5.7 Functions that are used internally .........................51-70
51.5.6 HYSYS: Class HYSYSNode ..................................51-71

51.5.6.1 Properties ..............................................................51-72
51.5.6.2 HYSYSClass() .......................................................51-73
51.5.6.3 LiquidPhase1() ......................................................51-73
51.5.6.4 LiquidPhase2() ......................................................51-73
51.5.6.5 Read() ...................................................................51-73
51.5.6.6 ReadPhase............................................................51-74
51.5.6.7 VapourPhase() ......................................................51-74
51.6 Application / user interface........................................51-74
51.6.1 Application: Aspen Plus import ..............................51-75
51.6.2 Application: PRO/II import ......................................51-85
51.6.3 Application: HYSYS import ....................................51-93
52 PE AND CM MODULES
52.1 General notes on templates .........................................52-1
52.2 Preparing 3D / CM templates from scratch ................52-1
52.2.1 Creating the unit to contain P&ID and 3D objects....52-1
52.2.2 Placing 3D objects in the Model space ....................52-2
52.2.3 Creating a Mapping table and linking PFD objects
to 3D objects ............................................................52-4
52.2.4 Linking the DimLen object to PFD objects ...............52-5
52.2.5 Connector mapping..................................................52-5
52.2.5.1 PFD -> PID connector mapping ..............................52-5
52.2.5.2 PFD -> CM connector mapping...............................52-6
52.3 Preparing P&ID templates ............................................52-7
52.4 Availability of P&ID and 3D templates ........................52-8
52.5 Preparing 3D templates using existing ones .............52-9
52.6 The PE base object structure ....................................52-11
52.6.1 PE root node ..........................................................52-11
52.6.2 CN Nomenclature Catalog node ............................52-11
52.6.3 DS Data Structures node .......................................52-11
52.6.4 CA Attributes Catalog.............................................52-12
52.6.4.1 CC Tabs Catalog...................................................52-12
52.6.4.2 MT Mapping Tables...............................................52-12
52.6.5 QU Queries ............................................................52-13
52.6.5.1 REM Remarks .......................................................52-13
52.6.6 PO Process Objects...............................................52-13
52.6.6.1 EQ Equipment .......................................................52-13
52.6.6.3 SO Stream Objects ...............................................52-14
52.6.7 US Unit System ......................................................52-14
52.7 Tips for administrators on PE objects ......................52-14

52.7.1 Tips on process units .............................................52-14
52.7.2 Tips on balance streams ........................................52-15
52.7.3 Tips on equipment..................................................52-15
52.7.4 Tips on material stream attribute links ...................52-15
53 ISOMETRIC MODULE
53.1 Defaults and definitions ...............................................53-1
53.2 Base data, lists, templates ...........................................53-4
53.2.1 | PI| EN| D| 03 Pipe ..................................................53-4
53.2.2 “@3D” branch...........................................................53-4
53.2.2.1 “@3D| @Menu” .......................................................53-4
53.2.2.2 “@3D| @PPC| @01 PipeSpec”...............................53-5
53.2.2.3 “@3D| @PPC| @CTS Part Components” ...............53-6
53.2.2.3.1 Structure ....................................................................................53-6
53.2.2.3.2 Technical background ...............................................................53-7
53.2.2.3.3 Designing symbol .....................................................................53-7
53.2.2.3.4 Tabs.........................................................................................53-14
53.2.2.3.5 “FT Fabrication” .....................................................................53-14
53.2.2.3.6 “GD 3D Geometry” ................................................................53-14
53.2.2.3.7 “SYSISO System Information” ..............................................53-17
53.2.2.3.8 “VTX Texts” ...........................................................................53-19
53.2.2.3.9 “VDM Data sheet” ..................................................................53-19
53.2.3 “|@ISO” node .........................................................53-20
53.2.3.1 “|@ISO|A Tag symbols” ........................................53-20
53.2.3.1.1 Creating tag symbols...............................................................53-20
53.2.3.1.2 Configuring base objects.........................................................53-21
53.2.3.1.3 Modifying tag symbols ...........................................................53-21
53.2.3.1.4 “...| 01 Seal”, “...| 06 Position number”, “...| 09 Welding
point”.......................................................................................53-22
53.2.3.1.5 “...|02 Equipment”...................................................................53-22
53.2.3.1.6 “...|03 Flow direction”.............................................................53-22
53.2.3.1.7 “...|04 Mounting tags” .............................................................53-22
53.2.3.1.8 “...|05 Nominal diameter/Pipe class” ......................................53-22
53.2.3.2 |@ISO| B Constr. symbols ....................................53-23
53.2.3.2.1 “...|01 Wall breakthrough” ......................................................53-23
53.2.3.3 “|@ISO|C Spool symbols” .....................................53-23
53.2.3.4 “@ISO|D|01 Check symbols” ................................53-25
53.2.3.5 “|@ISO|O|ISO documents”....................................53-25
53.2.4 Standard tables ......................................................53-26
53.2.4.1 “|@3D|01|PC|01|03 Functionscode”......................53-27
53.2.4.2 “|@3D|01|BC|02 Connection Types” .....................53-27
53.2.4.3 “|@3D|01|06 Contact faces” ..................................53-28
53.2.4.4 “|@SYSTEM| @NORTHARROW” ........................53-28
53.2.4.5 “@SYSTEM|@NORTHARROWANGLE” ..............53-28
53.2.4.6 “@SYSTEM|SLOPEINPUTTYPE” ........................53-28
53.3 Report/ Data sheet ......................................................53-29

53.3.1 Report template......................................................53-29
53.3.2 Configure report template ......................................53-29
53.3.3 Working with the isometric drawing........................53-34
53.3.4 Bill of material.........................................................53-35
53.4 Slope ...........................................................................53-36
53.5 Tag symbols for position numbers ...........................53-39
53.5.1 Overview ................................................................53-39
53.5.2 Allocated components ............................................53-40
53.5.3 Generation modes for position numbers ................53-41
53.5.3.1 Automatic vs. manual generation ..........................53-41
53.5.3.2 Compression key...................................................53-43
53.5.4 Possible configurations ..........................................53-44
53.6 Spools ..........................................................................53-46
53.6.1 Spool marks ...........................................................53-47
53.6.1.1 Create spool marks ...............................................53-47
53.6.1.2 Moving spool marks ..............................................53-50
53.6.1.3 Controlling spool marks .........................................53-50
53.6.2 Spool document .....................................................53-51
53.6.2.1 Creating spool document ......................................53-51
53.6.2.2 Properties of the spool document..........................53-52
53.6.2.3 Content of spool document ...................................53-52
53.6.2.4 Editing the spool document ...................................53-53
53.6.2.5 Fabrication documents ..........................................53-55
53.7 Pipe structure for piping isometrics .........................53-56
53.8 Pipe class management .............................................53-57
53.8.1 Opening the Pipe class management and
selecting a pipe class .............................................53-58
53.8.2 “Devices” tab ..........................................................53-60
53.8.3 “Branch table” tab...................................................53-60
53.8.4 “Connector table” table...........................................53-62
53.8.5 “Test” tab................................................................53-65
53.8.6 Remaining tabs ......................................................53-65
54 OVERVIEW COMOS PT
55 CROSS-MODULE PT TOOLS
55.1 Signal management ......................................................55-1
55.2 Signal name matching..................................................55-2
55.3 Assignment Manager....................................................55-2

56 INTERFACES PT
56.1 ECAD data (import) .......................................................56-1
56.2 Eplan data transfer (import ExF) .................................56-1
56.3 Simatic S7 (export, import) ..........................................56-1
56.3.1 Scope .......................................................................56-1
56.3.2 Creating the basic structure of the planning data in
Comos......................................................................56-1
56.3.3 Configuring Simatic objects in the planning data .....56-2
56.3.3.1 Name of the objects (plausibility checks) ................56-2
56.3.3.2 Generally applicable attributes ................................56-3
56.3.3.3 Cards (Assemblies) .................................................56-3
56.3.4 Exporting to HW Config............................................56-5
56.3.5 Importing from HW Config........................................56-6
56.3.6 Direct start from Simatic tools ..................................56-7
56.3.7 Comparing / Deleting objects ...................................56-7
56.3.8 Technical background ..............................................56-7
56.3.8.1 Data exchange object..............................................56-7
56.3.8.2 Allocation of Comos planning objects and S7
objects .....................................................................56-8
56.3.8.3 Exporting Comos planning objects (allocate S7
object class) ............................................................56-9
56.3.8.4 Creating objects for each order number / part
number ....................................................................56-9
56.3.8.5 Addressing channels in Comos.............................56-10
56.3.8.6 Allocating symbolic channel addresses.................56-10
56.4 Triga (up to 1.04) ........................................................56-11
56.5 VNS import ..................................................................56-11
56.6 Triga document (from V.3.0) ......................................56-11
56.7 Metzner Triathlon ........................................................56-11
57 P&ID MODULE
57.1.1 PI Piping and instrumentation ..................................57-1
57.1.1.1 Basic structures PI|PI EN ........................................57-1
57.1.1.1.1 Labeling ....................................................................................57-1
57.1.1.1.2 Symbol ......................................................................................57-2
57.1.1.1.3 Connectors and auxiliary connectors ........................................57-3
57.1.1.1.4 General attributes and calculated attributes ..............................57-4
57.1.1.2 @RI-B labeling symbols P&ID.................................57-4
57.1.1.2.1 All .............................................................................................57-4
57.1.1.2.2 RW Revision clouds .................................................................57-5
57.1.1.2.3 @RIGRAFIK Graphic symbols P&ID .....................................57-6

57.1.1.2.4 @RISYMBOL.......................................................................... 57-8
57.1.1.3 @1RI | @ST Nozzles ..............................................57-8
57.1.1.4 @1RI | V2 Fittings ...................................................57-9
57.1.2 Unit structure............................................................57-9
57.1.2.1 General....................................................................57-9
57.1.2.2 Reports and administration objects underneath the unit
structure ..................................................................57-9
57.1.3 @P Positions..........................................................57-11
57.1.4 @F Functions.........................................................57-11
57.2 Pipes ............................................................................57-11
57.2.1 Pipe structure .........................................................57-11
57.2.1.1 Overview ...............................................................57-11
57.2.1.2 First level: Pipe......................................................57-12
57.2.1.3 Second level: Pipe branch.....................................57-13
57.2.1.4 Third level: Pipe segments (P&ID) ........................57-13
57.2.1.5 References to the base objects of the pipe
structure ................................................................57-14
57.2.2 Separating pipes with components ........................57-15
57.2.3 Optical interruption on the report............................57-15
57.2.4 Graphical properties of pipe objects.......................57-16
57.2.5 Pipe tags ................................................................57-17
57.3 Positions......................................................................57-17
57.3.1 General ..................................................................57-17
57.3.2 Creating positions ..................................................57-18
57.3.3 Data flow of positions .............................................57-19
57.4 Functions.....................................................................57-20
57.4.1 General ..................................................................57-20
57.4.2 Structure of base objects .......................................57-21
57.4.2.1 Level “@F|A<number>”: neutral functions ............57-21
57.4.2.2 Levels “@F|A<number>|01 Measurement function”
and “... |02 Actuating function”...............................57-22
57.4.2.3 Levels underneath “@F|A<number>|01 Measure-
ment function” and “... |02 Actuating functions” .....57-23
57.4.2.4 “@F| SE Structure elements for functions”............57-23
57.4.2.5 “@F| Y Attributes catalog” .....................................57-23
57.4.2.6 “@F| Z Structures (create new/assembly groups)”57-24
57.4.3 Tabs / attributes .....................................................57-24
57.4.3.1 “SYS System information” tab ...............................57-24
57.4.3.2 “RI Presentation” tab .............................................57-25
57.4.3.3 “IC110 Function data measuring point” and “IC110
Function data actuating point” tabs .......................57-26
57.4.3.4 “PI01x Substance data” and “IC22x Process
connector” tabs......................................................57-27
57.4.3.4.1 General ................................................................................... 57-27
57.4.3.4.2 Measurement function with process coupling nozzle ............ 57-28

57.4.3.4.3 Measurement function with process coupling inline device...57-28
57.4.3.4.4 Actuating function ..................................................................57-28
57.4.3.5 'Process connection data” tab ...............................57-29
57.4.4 Function code.........................................................57-29
57.4.5 Process coupling and process connector ..............57-30
57.4.5.1 Creating a process connector ...............................57-30
57.4.5.2 Data flow ...............................................................57-31
57.4.5.3 Process coupling for measurement functions .......57-33
57.4.5.3.1 Connection via nozzle.............................................................57-33
57.4.5.3.2 Connection through inline devices..........................................57-34
57.4.5.3.3 Switching process connectors ................................................57-34
57.4.5.4 Process coupling actuating function......................57-34
57.4.5.5 Automatically create process coupling .................57-35
57.4.5.6 Number of process connectors .............................57-35
57.4.6 Connectors.............................................................57-36
57.4.7 Allocating symbols .................................................57-38
57.4.8 Display on the diagram ..........................................57-41
57.4.8.1 Neutral function .....................................................57-41
57.4.8.2 Basic symbol .........................................................57-41
57.4.8.3 Optional graphics ..................................................57-43
57.4.9 Scripts ....................................................................57-43
57.5 Vessels.........................................................................57-46
57.6 Templates and definitions..........................................57-46
57.6.1 Project settings - Module options tab .....................57-46
57.6.2 Report templates....................................................57-47
57.6.3 Properties of a P&ID report ....................................57-48
57.6.4 Attributes for pipes .................................................57-48
57.6.5 Standard tables ......................................................57-50
57.7 Using P&ID ..................................................................57-51
57.7.1 Importing AutoCAD data ........................................57-51
57.7.2 Process units..........................................................57-51
57.7.3 Defining streams ....................................................57-52
57.7.4 Data lines and action lines ....................................57-52
57.7.5 Working with functions in the planning view ..........57-53
57.7.5.1 Overview ...............................................................57-53
57.7.5.2 Working in the P&ID diagram ................................57-53
57.7.5.3 Working only in the Navigator ...............................57-55
57.7.6 Opening process units / further level......................57-57
57.7.7 Hierarchical structure of the P&ID planning data ...57-57
57.7.7.1 Object assignment.................................................57-58
57.7.7.2 Categories .............................................................57-58
57.7.8 Search strings and cross references......................57-59

57.7.9 Expand graphic options..........................................57-59
57.8 Interfaces .....................................................................57-59
58 TOOLS FOR EMR

58.1 RUPLAN import ............................................................58-1
58.2 Importing ECAD components .....................................58-1
58.3 Change per rule: name / label......................................58-3
59 ELECTRICAL ENGINEERING
59.1.1 Devices (planning objects) .......................................59-1
59.1.1.1 “Simple” devices ......................................................59-1
59.1.1.1.1 DIN labels................................................................................. 59-1
59.1.1.1.2 Symbol...................................................................................... 59-2
59.1.1.1.3 Connectors and auxiliary connectors ....................................... 59-4
59.1.1.1.4 Attributes and calculated attributes .......................................... 59-4
59.1.1.1.5 Request property....................................................................... 59-5
59.1.1.1.6 Product data.............................................................................. 59-5
59.1.1.2 @1EA Catalog EE |- I Potentials .............................59-6
59.1.1.2.1 Logical potential....................................................................... 59-6
59.1.1.2.2 Physical potential ..................................................................... 59-8
59.1.1.3 K Relay, contactor .................................................59-10
59.1.1.4 O Other..................................................................59-12
59.1.1.4.1 @BB Blackbox....................................................................... 59-12
59.1.1.4.2 @SG ID segment.................................................................... 59-14
59.1.1.5 W Cables ...............................................................59-17
59.1.1.5.1 Goal ........................................................................................ 59-17
59.1.1.5.2 Control of the extended capabilities....................................... 59-17
59.1.1.5.3 Application ............................................................................. 59-17
59.1.1.5.4 Placing a cable on the report .................................................. 59-20
59.1.1.5.5 Shields .................................................................................... 59-21
59.1.1.5.6 Other objects........................................................................... 59-22
59.1.1.5.7 Supporting documents............................................................ 59-22
59.1.1.5.8 Pre-allocating wires to connectors ......................................... 59-23
59.1.1.6 X Terminal strips / plug strips ................................59-23
59.1.1.6.1 Goal ........................................................................................ 59-23
59.1.1.6.2 Control of the extended capabilities....................................... 59-23
59.1.1.6.3 Terminal strips........................................................................ 59-23
59.1.1.6.4 Terminals................................................................................ 59-24
59.1.1.6.5 Bridges.................................................................................... 59-24
59.1.1.6.6 Supporting reports .................................................................. 59-25
59.1.1.6.7 Plug strips ............................................................................... 59-26
59.1.1.7 ZA_1EA templates / part switching .......................59-26
59.1.1.8 ZE_1EA elements .................................................59-26
59.1.1.8.1 HK Auxiliary contacts............................................................ 59-26

59.1.1.8.2 KS Terminals, plugs................................................................59-26
59.1.2 Structure objects, document objects ......................59-27
59.1.2.1 @G Document groups |S |E Structure electrical
engineering............................................................59-27
59.1.2.2 @J Project |@E Project templates EE ..................59-27
59.1.2.3 @L Locations |EE Location structure EE ..............59-27
59.1.2.4 @O Documents |EE electrical engineering ...........59-27
59.1.2.5 @U Units |BKZ |E Unit structure EE .....................59-28
59.1.3 Administration objects ............................................59-28
59.1.3.1 @L Locations |SSE switching cabinets |BASIC
| Views...................................................................59-28
59.1.3.2 eClass 4.0 .............................................................59-28
59.1.4 Descriptions ...........................................................59-28
59.1.4.1 Base project @1EA ...............................................59-29
59.1.4.2 Base project @IRF ................................................59-29
59.1.4.3 Base project @System..........................................59-29
59.1.4.3.1 Base project @System |@Bridge symbols..............................59-29
59.1.4.3.2 Base project @System |@Class | Detail..................................59-29
59.1.4.3.3 Base project @System |@Connection ....................................59-29
59.1.4.4 System project @ConnectionType E ....................59-30
59.1.4.5 System project @System ......................................59-30
59.1.4.5.1 System project @System |@BridgeType................................59-30
59.1.4.5.2 System project @System |@ELO_KSP..................................59-31
59.1.4.5.3 System project @System |@WireColor..................................59-31
59.1.4.5.4 System project @System |@WireCrossSection......................59-31
59.1.4.5.5 System project @System |@WireTypeInfo............................59-31
59.1.5 Interactive Report templates ..................................59-31
59.1.5.1 Circuit diagrams ....................................................59-31
59.1.5.1.1 Attributes.................................................................................59-31
59.1.5.1.2 Options for EE reports ............................................................59-31
59.1.5.2 Layout plans ..........................................................59-34
59.1.6 Evaluation report templates ...................................59-34
59.1.6.1 PMA.......................................................................59-34
59.1.6.2 PPB .......................................................................59-34
59.1.6.3 PQA.......................................................................59-34
59.1.6.4 PPC .......................................................................59-34
59.2 Connections ................................................................59-35
59.2.1 Graphic connections ..............................................59-35
59.2.1.1 Preparing connections...........................................59-35
59.2.1.2 Dragging connections............................................59-35
59.2.1.3 Parallel connections ..............................................59-36
59.2.1.4 Open connections .................................................59-37
59.2.1.5 Direction of wiring..................................................59-38
59.2.1.6 Connections / wiring for terminal bridges ..............59-41
59.2.1.7 Document cross-references ..................................59-44
59.2.1.8 Reconciliation of database and report
connections ...........................................................59-45
59.2.1.9 Connection-independent objects...........................59-47
59.2.1.10 Limitations of “connection-independent objects” ...59-49

59.2.2 Connection information ..........................................59-51
59.2.2.1 Bridges ..................................................................59-51
59.2.2.2 Logical potential ....................................................59-51
59.2.2.3 Cables and wires / wire information without wires.59-52
59.2.2.4 Shielded cables .....................................................59-53
59.2.2.5 Summarizing cables in cable channels / routes ....59-55
59.3 Special concerning circuit diagrams ........................59-56
59.3.1 Placing devices ......................................................59-56
59.3.2 Revising and controlling devices ............................59-56
59.3.3 Setting the pointer in the report / allocating
information .............................................................59-57
59.3.4 Identification keys in EE reports.............................59-57
59.4 Special points regarding layout plans ......................59-58
59.5 Special points regarding single line diagrams ........59-58
59.5.1 Report template......................................................59-58
59.5.2 Allocating ELO connectors and single line
connectors..............................................................59-58
59.6 Evaluation (order lists / materials lists / parts lists) 59-58
59.6.1 General ..................................................................59-58
59.6.2 Settings tab ............................................................59-59
59.7 Object-oriented EE planning......................................59-61
59.7.1 Object connections (connectors)............................59-61
59.7.1.1 Definition of connections .......................................59-61
59.7.1.2 Settings connections in the Navigator ...................59-61
59.7.1.3 Working with the Connectors tab and the
Navigator ...............................................................59-62
59.7.1.4 Working with two Properties windows open ..........59-63
59.7.1.5 Working with the “connect device” dialog window 59-63
59.7.1.6 Connection information for connectors:
dialog window “Characteristics for connections” ...59-64
59.7.1.7 Providing connectors with logical potentials
beforehand ............................................................59-65
59.7.2 Strip tab..................................................................59-66
59.7.2.1 Terminal strips and terminal strips ........................59-66
59.7.2.2 Bridges ..................................................................59-66
59.7.3 Product data and real devices................................59-68
59.7.4 Other auxiliary tools ...............................................59-68
59.7.4.1 Change by rule: name, label .................................59-68
59.8 Other ............................................................................59-69
59.8.1 Translation / language management......................59-69
59.8.2 Management of rights and licenses .......................59-69

60 REQUEST AND IMPLEMENTATION
60.1 Request..........................................................................60-1
60.2 Implementation .............................................................60-3
60.2.1 Implementation phase (preparing for ordering) ........60-3
60.2.2 The Implement request dialog window ....................60-3
60.2.3 Replacing or retaining a request ..............................60-5
60.2.3.1 Project option “‘Implement request’ replaces
objects”....................................................................60-5
60.2.3.2 Setting the implementation pointer..........................60-5
60.2.3.3 Base object change.................................................60-6
60.2.4 Release device requests..........................................60-7
60.3 Report PQA....................................................................60-7
61 PRODUCT DATA AND MANUFACTURER DEVICE

61.1 Definition and area of application ...............................61-1
61.2 Function right product data .........................................61-2
61.3 Preparing requirements ...............................................61-3
61.3.1 Preparing request base objects ...............................61-3
61.3.2 Preparing attributes..................................................61-4
61.3.3 Controlling the display of product-related attributes .61-6
61.4 Importing manufacturer devices .................................61-6
61.5 Planning work (input of product data) ........................61-7
61.6 Selecting a manufacturer device .................................61-8
61.6.1 Creating manufacturer devices by feedback ............61-8
61.6.1.1 Feedback for an individual planning object .............61-8
61.6.1.2 Feedback for a planning branch..............................61-9
61.6.1.3 Automatically creating structure branches for
manufacturer details..............................................61-10
61.6.2 Selection of manufacturer devices .........................61-10
61.6.2.1 Selection with a single planning object..................61-10
61.6.2.2 Selection for a planning data branch.....................61-12
61.6.3 Deviations from the manufacturer device templates
(orange background)..............................................61-14
61.7 Output product data ...................................................61-15
62 EPLAN (IMPORT/EXPORT EXF)

62.1 Background information ..............................................62-1
62.1.1 EPLAN structures in comparison with Comos

structures .................................................................62-1
62.1.2 EPLAN pages in comparison with Comos reports ...62-3
62.1.3 Overview of an export of Comos data to EPLAN .....62-6
62.2 Prepare Comos planning project ................................62-7
62.3 Importing EPLAN data (EPLAN -> Comos).................62-9
62.3.1 Importing EPLAN article base data into Comos .......62-9
62.3.2 Importing EPLAN symbols into Comos ..................62-11
62.3.3 Importing plot frames .............................................62-15
62.3.4 Importing forms ......................................................62-16
62.3.4.1 Exporting projects from EPLAN.............................62-17
62.3.4.2 General import details ...........................................62-17
62.3.4.3 EXF tab import ......................................................62-17
62.3.4.4 The import process................................................62-19
62.3.4.5 Conversion of individual objects ............................62-20
62.4 Working in Comos with (imported) EXF data ...........62-22
62.4.1 Ready-made labelling systems and objects ...........62-22
62.4.2 Ready-made objects in the categories ...................62-23
62.4.2.1 Documents category .............................................62-23
62.4.2.2 Terminal strips category ........................................62-23
62.4.2.3 Category controller ................................................62-23
62.4.2.4 Cables category ....................................................62-24
62.4.2.5 Category Devices ..................................................62-24
62.4.3 Cross-references....................................................62-25
62.5 Exporting from Comos (Comos -> ExF)....................62-25
62.5.1 The Export symbols tab .........................................62-26
63 DIAGRAM TYPE DESIGN

63.1 Overview ........................................................................63-1
63.2 Control cabinets (“design diagrams”) ........................63-1
63.2.1 Views for design diagrams .......................................63-1
63.2.1.1 Definition of the views .............................................63-1
63.2.1.2 Operation of views...................................................63-2
63.2.2 Technical implementation of views / symbols for
views ........................................................................63-5
63.2.3 Administration of design diagrams ...........................63-7
63.2.3.1 Attributes of the cabinet objects ..............................63-7
63.2.3.1.1 Tab “EBD Installation data” in the case of design diagrams ... 63-7
63.2.3.1.2 Tab “GD 3D”............................................................................ 63-9
63.2.3.1.3 Tab “MKY Mounting key” .................................................... 63-10
63.2.3.1.4 Tab “BHD Drill data”............................................................. 63-10
63.2.3.2 Views.....................................................................63-11
63.2.3.3 Using third-party data ............................................63-11

63.2.3.4 Standard tables .....................................................63-11
63.2.3.4.1 ET |Y Attributes catalog .........................................................63-11
63.2.3.4.2 0 Attribute collection: 02 Construction..................................63-12
63.2.3.5 Report templates ..................................................63-12
63.2.4 Examples ...............................................................63-13
63.2.5 Using design diagrams...........................................63-14
63.2.5.1 Creating and placing objects .................................63-14
63.2.5.2 General information on operation..........................63-17
63.2.5.3 Automatic routing in design diagrams ..................63-19
63.2.5.4 Interaction with VIPER (3D) ..................................63-20
63.2.5.5 Evaluation..............................................................63-20
63.2.5.6 Printing ..................................................................63-20
63.2.6 Interface: Metzner Triathlon ...................................63-21
63.3 Installation diagrams ..................................................63-21
63.3.1 Views for installation diagrams...............................63-21
63.3.2 Administration of installation diagrams...................63-22
63.3.2.1 Attributes of the installation diagrams ...................63-22
63.3.2.1.1 Cable tray ................................................................................63-22
63.3.2.1.2 Arc, rise, line, T-piece (physical tray elements) .....................63-22
63.3.2.1.3 Duct (logical tray component) ................................................63-23
63.3.2.1.4 Cable insets .............................................................................63-24
63.3.2.1.5 Installation objects ..................................................................63-24
63.3.2.2 Report templates ..................................................63-24
63.3.2.2.1 Installation diagram ................................................................63-24
63.3.2.2.2 Circuit diagrams......................................................................63-24
63.3.2.2.3 Cable assignment (evaluated) .................................................63-25
63.3.2.2.4 Tray overview (evaluated) ......................................................63-25
63.3.3 Using installation diagrams ....................................63-25
64 I&C SUB-MODULE
64.1 P&ID defaults.................................................................64-1
64.1.1 Base data .................................................................64-1
64.1.2 Unit planning ............................................................64-1
64.1.3 Position and functions ..............................................64-2
64.2.1 Devices from other branches ...................................64-2
64.2.1.1 Folder “EE/I&C Engineering”...................................64-2
64.2.1.2 “@Position” .............................................................64-5
64.2.1.2.1 General ......................................................................................64-5
64.2.1.2.2 Tabs / attributes.........................................................................64-6
64.2.1.3 “@F Functions” .......................................................64-8
64.2.1.3.1 General ......................................................................................64-8
64.2.1.3.2 Display of functions ..................................................................64-8
64.2.1.3.3 Tab / attributes ..........................................................................64-8
64.2.1.3.4 “@F| SE Structure elements for functions” ............................64-10

64.2.1.3.5 “@F| Y Attributes catalog” .................................................... 64-10
64.2.1.3.6 “@F| Z Structures (Create new/assembly groups)” ............... 64-10
64.2.1.4 @G Document groups...........................................64-12
64.2.1.4.1 “@G| S Structures acc. to IEC 61355“................................... 64-12
64.2.1.4.2 “@G| Z Structure elements“................................................... 64-13
64.2.2 Devices of branch “ET I&C, Electrical engineer-
ing“ .........................................................................64-13
64.2.2.1 Basic structures .....................................................64-14
64.2.2.1.1 First level................................................................................ 64-14
64.2.2.1.2 DIN labels for “ET | D VDevices” ......................................... 64-14
64.2.2.1.3 Symbol.................................................................................... 64-15
64.2.2.1.4 Connectors and auxiliary connectors ..................................... 64-17
64.2.2.1.5 Attributes and calculated attributes ........................................ 64-17
64.2.2.1.6 Elements ................................................................................. 64-18
64.2.2.2 “ET | 3 Structures IC”.............................................64-18
64.2.2.2.1 “ET| 3| 01 Units” .................................................................... 64-18
64.2.2.2.2 “ET| 3| 02 Signals” ................................................................. 64-20
64.2.2.2.3 “ET| 3| 04 Document design”................................................. 64-21
64.2.2.2.4 “ET| 3| 99 MCC drivers” ........................................................ 64-21
64.2.2.3 “ET| B Mounting” ...................................................64-21
64.2.2.4 “ET| C Expense” ....................................................64-21
64.2.2.5 “ET | D Devices” ....................................................64-21
64.2.2.5.1 “ET |D Devices |B Transmittors, sensors|A B Sensors
|IC B Structured at elements (channel)“................................. 64-21
64.2.2.5.2 “ET |DDevices |U U Transducers”......................................... 64-21
64.2.2.6 “ET |E Elements” ...................................................64-22
64.2.2.7 “ET |L Locations” ...................................................64-22
64.2.2.8 “ET |O Documents”................................................64-24
64.2.2.9 “ET|Q Queries, Tables, Scripts” ............................64-24
64.2.2.10 ET |S Signals.........................................................64-25
64.2.2.10.1 Base data structure.................................................................. 64-25
64.2.2.10.2 Tabs / attributes ...................................................................... 64-26
64.2.2.10.3 Scripts..................................................................................... 64-26
64.2.2.10.4 Incorporate process visualization (WinCC, PVSS II) ............ 64-26
64.2.2.11 ET |U Units ............................................................64-26
64.2.2.12 ET |Y Attributes catalog.........................................64-27
64.3 Settings and definitions .............................................64-27
64.3.1 Project properties ...................................................64-27
64.3.2 Standard tables ......................................................64-28
64.3.2.1 AREANAME ..........................................................64-28
64.3.2.2 “ET|Y|O|S001|S001 Document types“...................64-28
64.4 Standard-Loop ............................................................64-29
64.5 I&C reports ..................................................................64-30
64.5.1 Evaluation Reports .................................................64-30
64.5.1.1 Configurable I&C reports .......................................64-30
64.5.1.1.1 List of configurable reports .................................................... 64-30
64.5.1.1.2 Overview ................................................................................ 64-32
64.5.1.1.3 Technical implementation ...................................................... 64-33

64.5.1.2 Remaining I&C Evaluation Reports.......................64-35
64.5.1.2.1 “PDAB.1 PLT position overview” .........................................64-35
64.5.1.2.2 “PDAC.1 PLT position - function overview”.........................64-36
64.5.1.2.3 “PDAD.1 Armature overview” ...............................................64-36
64.5.1.2.4 “PDAE.1 Function and signal list” .........................................64-37
64.5.1.2.5 “PQAC.1 Loop, check protocol” ............................................64-37
64.5.1.2.6 “PFPA.1 Signal list and PFPA.2 Signal list (hardware)” .......64-38
64.5.1.2.7 “PFPB List of references”.......................................................64-38
64.5.1.2.8 “PQBA List of security-relevant E/I&C installations” ...........64-39
64.5.1.2.9 PPC reports .............................................................................64-39
64.5.2 Interactive Reports .................................................64-39
64.5.2.1 Loop diagrams.......................................................64-39
64.5.2.1.1 “PFSM.2 Position diagram”....................................................64-40
64.5.2.1.2 “PFSM.1 Loop ANSI” ............................................................64-40
64.5.2.1.3 “PFA.04 Position diagram, single line” ..................................64-41
64.5.2.2 “PFFA Functional diagram” ...................................64-41
64.6 Auto functions of loop diagrams...............................64-42
64.6.1 First opening of a loop diagram..............................64-42
64.6.2 Automatic Placing ..................................................64-42
64.6.3 Automatic Connecting ............................................64-44
64.6.4 Configuring auto-functions ....................................64-45
64.6.4.1 Overall conditions in the base objects:
“AREANAME”........................................................64-45
64.6.4.2 Options script of the report template .....................64-46
64.6.4.3 Segmentation of the diagram ................................64-48
64.7 Using I&C ....................................................................64-50
64.7.1 Working with signals ..............................................64-50
64.7.1.1 General..................................................................64-50
64.7.1.2 Mouse menu of the measurement function ...........64-50
64.7.1.2.1 Overview.................................................................................64-50
64.7.1.2.2 Working with assembly groups: “Assembly groups
(signals with channels)” ..........................................................64-51
64.7.1.2.3 Creating signals and device requests manually ......................64-54
64.7.1.3 The mouse menu of the actuating function ...........64-55
64.7.1.3.1 Assembly groups for actuating functions ...............................64-56
64.7.1.3.2 Alternative: Creating signals and channels manually .............64-56
64.7.1.4 Connector: Signal of owner ...................................64-57
64.7.1.5 Signal Manager .....................................................64-58
64.7.1.6 Signal name matching...........................................64-58
64.7.1.7 Assignment manager ............................................64-59
64.7.2 Location planning ...................................................64-59
64.7.2.1 Planning the location structure ..............................64-59
64.7.2.2 Relation of the location view to the unit view.........64-61
64.7.2.3 Control system ......................................................64-62
64.7.2.3.1 S7 / HW config .......................................................................64-62
64.7.2.3.2 Creating a DCS control cabinet .............................................64-62
64.7.2.3.3 The racks .................................................................................64-62

64.7.2.3.4 The cards ................................................................................ 64-62
64.7.2.3.5 Assembly groups .................................................................... 64-64
64.7.2.3.6 Implementation....................................................................... 64-65
64.7.2.4 Ex-protection control cabinet ................................64-68
64.7.2.4.1 Moving ex-protection from the DCS control cabinet
into the ex-protection control cabinet .................................... 64-69
64.7.2.4.2 Assembly groups .................................................................... 64-69
64.7.2.5 Marshalling cabinet ...............................................64-69
64.7.2.6 Field distributor......................................................64-70
64.7.2.6.1 Linking the unit and location views through pointers............ 64-70
64.7.2.6.2 Creating the field distributor .................................................. 64-72
64.7.2.6.3 Carrying out the marshalling.................................................. 64-73
64.7.3 Marshalling management .......................................64-75
64.7.4 Assigning product data...........................................64-76
64.8 Mounting catalog ........................................................64-78
64.8.1 General ..................................................................64-78
64.8.2 Constituent parts ....................................................64-79
64.8.3 Documents folder PPC Parts list, Hook Up ............64-81
64.8.3.1 “PPCA Hook-Up” (mounting drawing) ...................64-81
64.8.3.1.1 Overview ................................................................................ 64-82
64.8.3.1.2 Hook-Up graphic.................................................................... 64-82
64.8.3.1.3 Material list............................................................................. 64-84
64.8.3.1.4 Mounting texts........................................................................ 64-84
64.8.3.2 “PPCB Hook-Ups with positions”...........................64-85
64.8.3.3 “PPCC parts list evaluation (mounting
accessories)” .........................................................64-86
64.8.4 Mounting expenses ................................................64-87
64.8.4.1 Mounting expense object ......................................64-87
64.8.4.2 Determination of quantities and expenses ...........64-87
64.9 Interfaces .....................................................................64-88
64.9.1 S7/HW Config ........................................................64-88
64.9.2 Process visualization..............................................64-88
65 LOGICAL DIAGRAMS / FUNCTIONAL DIAGRAMS

65.1 The aim of logical diagrams.........................................65-1
65.2 Base data and administration ......................................65-1
65.2.1 Base object classes .................................................65-1
65.2.2 Standard tables ........................................................65-2
65.2.3 Document objects ....................................................65-3
65.2.4 Report templates......................................................65-4
65.2.4.1 Ready-made report templates .................................65-4
65.2.4.2 The options script for a function diagram ................65-4
65.2.5 Base object libraries.................................................65-6

65.3 Inputs and outputs (signals) ........................................65-6
65.3.1 The slots...................................................................65-6
65.3.2 Diagram type-specific symbols for inputs and
outputs .....................................................................65-7
65.3.3 Automatic symbols for inputs and outputs ...............65-7
65.3.3.1 Signals: Ready-made objects in the default
database..................................................................65-7
65.3.3.2 Overview of the default signals ...............................65-8
65.3.3.3 Display of function diagram signals in Comos.........65-9
65.3.3.4 Automatic connector breaks..................................65-11
65.3.4 Navigation options..................................................65-11
65.4 Control system at the function diagram ...................65-12
65.4.1 Function blocks general .........................................65-12
65.4.1.1 Layout of the function blocks.................................65-12
65.4.1.2 Function blocks: Ready-made objects in the
default database....................................................65-12
65.4.1.3 The blackbox .........................................................65-13
65.4.1.4 Connecting function blocks ...................................65-13
65.4.2 Function blocks for IEC ..........................................65-13
65.4.3 Function blocks for VGB ........................................65-15
65.5 Evaluation....................................................................65-15
65.6 Interfaces .....................................................................65-15
66 PQM

Starting Comos / database selection Start properties
1 Starting Comos / database selection
1.1 Start properties

Comos can save the window state and window position so as to use the same
values again next time it is started.
This is especially helpful if Comos was started from another application and
not as a full screen. This can be by inputting the text “vbNormal” in procedure
XIF.Init in the last optional reserved parameters. Effect: Comos is not max-
imized when it appears and takes up 2/3 of the screen, centered.
1.2 Database types / Keycode.exe

The Comos databases are product-related. In other words: Comos PT,
Comos ET, etc. all use a database of their own. For that reason there are also
genuine functional subsets (exactly as with the products). Examples:
Comos PT covers all the functions of Comos ET; Comos ET is thus a subset
of Comos PT. The database for Comos ET is correspondingly a subset of the
database for Comos PT.
If necessary, a Comos ET database can thus also be opened with Comos PT.
However, Comos ET cannot open this database afterwards.
Keycode.exe
If the above was done accidentally and if the locking of the Comos ET data-
base is to be released, then proceed as follows:
• Look in Windows Explorer for sub-directory ..\comos\bin .
• Start KEYCODE.exe
• Select the database to be released from the dialog window shown below:
© 2006 innotec GmbH 1-1

Starting Comos from the command line Starting Comos / database selection
• Press the [CONTINUE] button

• Follow the instructions given in the dialog window shown below:
Only close the above dialog window once the entire process has
been completed!
1.3 Starting Comos from the command line

Original state/ Jet Database
If a correct command line is available, then a direct start is ignored.
The following parameters can be attached in any order when calling up
Comos:
/D (database name) (D = database)
Opens the specified database.
/U [0,1,2] (U = User)
Takes the name of the user from logging into the
database:
0 (default): Default access for the user
1: Universal access
2: Alternative access for the user
/P (Project name) (P = Project)
Opens the specified project.
/V (V = View)
Read mode (View mode). See also SECTION 6.1.3:
NOTES REGARDING LICENSES.
/E Specifically use a Comos ET license.

/PID Specifically use a Comos P&ID license.
1-2 © 2006 innotec GmbH

Starting Comos / database selection Starting Comos externally
/NO Turn off the startup greeting.
Example:
Comos /D z:\ReleaseDatabase\Comos.mdb /P SO1 /NO
Screens:1 and Screens:2 respectively

Determines the number of screens used. Special solution for Windows 2000,
which cannot automatically detect the number of screens.
Old form
As an alternative to the above method, you can also use parameters separated
by spaces. In that case they must follow a specific order:
1. Parameter [Complete database file name with directory]
2. Parameter [0: Default access; 1: Universal access;
2: Alternative access for the user]
3. Parameter [Project name]
Example:
Comos.exe z:\ReleaseDatabase\Comos.mdb 1 SO1
This older form must not be mixed with the usage parameters.
Server database
<Comos.exe> /d [SQL - SERVER]pt_sql_server_1 /P Test
“pt_sql_server_1” is an example of a name of the data source. Please note the
space character in “SQL - SERVERS”!
1.4 Starting Comos externally

There is the DOS program XIF.exe in the bin directory of Comos. Document
XifExample.txt is located there in parallel.
XIF can start up Comos via an external program call, it can open a project,
select an object in the Navigator and open a report on which the object has
been placed.
There is a sample script for WinCC in XifExample.txt.

Open database and project (login) Starting Comos / database selection
Application examples
• Search for an object by means of FullLabel
The device or document that is being searched for can also be identified via
the FullLabel. However, the FullLabel does not take into consideration
the folder or prefix. If a document is searched for by means of FullLabel
and not found, then all the parallel folders are automatically searched in
parallel to see whether the object can be found there. In addition, any
possible prefixes are taken into consideration.
• Open report
An object can be placed on multiple reports. For that reason you can now
specify the /PA: <Symbol type> option. This stipulates a specific type of
report on which the object in question is placed. Please note in such a case
that it is not allowed to place the object on two reports of the same type.
The Properties window of the object opens if no document was found (the
object was not placed on a report of this type or the symbol type is unknown).
This function can also be used in a targeted way: you simply need to input an
unknown symbol type as the option if the Properties window is to be opened
explicitly.
1.5 Open database and project (login)

See SECTION 3.1: LOGIN, SECTION 5.2: CREATE OR DELETE PROJECTS.
Server login with file

In the case of SQL Server and Oracle the password for the server login (not
the Comos login) is stored in a file:
SQL Server: sqlpwd.dat
Oracle: orapwd.dat
Advantages:
• The password does not need to be input each time on login.
• It is sufficient if an administrator knows the password. The administrator
creates this file and subsequently distributes it to all the Clients.
As a result any desired user name can also be used and you are no longer
restricted to the user name “Comos ”.

Starting Comos / database selection Personal settings
1.6 Personal settings
1.6.1 Profiles
At many points the user can design the interfaces to suit his or her own wishes.
For example, when selecting a project.
Do this right-clicking on the head of a column:
The table can be designed as you wish. There is a comprehensive description
on how these tables (“object queries”) can be designed in SECTION 24: OBJECT
BROWSER.
Then right-click again on a column head and select the | SETTINGS | SAVE com-
mand.
The user-specific layout is stored in the profiles directory of the base data.

Personal settings Starting Comos / database selection

Menu overview File
2 Menu overview
2.1 File
Open or create a database
Call: | FILE | OPEN DATABASE (Ctrl+D)

The login information can be input in the following dialog field. (The last
database that was used is offered as a suggestion.) See also Quick start Basic:
“Opening databases and projects”.
Alternatively: Create a database (Access). See SECTION 3.2: CREATE / LINK DATA-
BASES regarding the topic of Creating a database .
Open or create a project
Call: | FILE | OPEN PROJECT (Ctrl+P)

A database can include one or more projects, but only one project can be open
at a time. Which projects you see also depends on the rights you have been
granted. See also Quick start Basic: “Opening databases and projects”.
Alternatively: Create a project. See SECTION 5.2: CREATE OR DELETE PROJECTS con-
cerning the topic of Creating a project .
Closing a project
File | CLOSE PROJECT

Saves and closes the active project, but not the database.
Saving the current project
Call: | FILE | SAVE

Effect of “saving” in Comos:
• All open objects and actions are saved.
Please note: This also means that a save is made in all Properties windows
that had changed (and then of course the [ACCEPT] button is set to inactive.)
[CANCEL] is no longer possible after saving There is no undo for all
Navigator operations.

File Menu overview
• An attempt is made to save as much as possible, while the Save buttons in

the dialog windows only save if the inputs are consistent.
Example: A duplicate name in the Properties window:
• Saving in Comos:
The name is corrected automatically, the object is saved.
• Saving in the Properties window:
Saving is rejected, an error message is shown because of the duplicate
name.
• The cache is cleared under certain circumstances.
The existence of objects in the object cache is not an illegal action and
should only be reduced by saving if the number has become extremely large
due to the use of certain bulk processing functions such as import actions,
etc. See SECTION 3.8: SYSTEM MONITOR.
Printing (of documents)
Call: | FILE | PRINT

This menu starts up the PrintManager that allows documents to be managed,
revised and printed. In the PrintManager this involves the default query for
documents, see SECTION 25.5: STANDARD QUERY DOCUMENTS / PRINTING.
Language of the interface
Call: | FILE | LANGUAGES

Select the language for the interface in the following dialog window.
You can find an explanation of language management in Quick start Basic
and in SECTION 42: LANGUAGES (LOCALIZATION).
End (of the program)
Call: | FILE | END

Comos is terminated with this command. All changes since the last save oper-
ation are saved in the project and in the database.

Menu overview Editing
2.2 Editing
The following functionalities are described here in the way that they behave
in a planning project. The form of behavior in a base project can differ
slightly, especially in the case of references.
Deleting one or more objects
Call: | EDIT | DELETE

A function of the Comos clipboard. A reference is deleted when it is marked,
but the object itself and all the other references to this object are retained. If a
planning object is deleted, then the marked object and all the references to this
object are deleted; but the associated base object still exists. If a a base object
is deleted, then under certain circumstances the derived planning objects are
deleted as well.
Cut object(s)
Call: | EDIT | CUT

A function of the Comos clipboard. Cuts out the object and places it in the
Comos clipboard. Please note that the clipboard is deleted if the database is
changed or closed; hence, objects in the clipboard are lost without any further
warning in such a case.
If a planning object is cut and pasted back in again, all the references (= point-
ers) are lost.
Copy object(s)
Call: | EDIT | COPY

A function of the Comos clipboard. Creates new objects in the clipboard on
the basis of the marked objects.
You can find a detailed overview of all the options and information on copy-
ing in SECTION 8: COPYING.
Paste object(s)
Call: | EDIT | PASTE

View Menu overview
A function of the Comos clipboard. If the | CUT function had been used before-
hand, the objects that had been cut are pasted in at this position. If the | COPY
function had been used beforehand, the newly created objects are pasted in at
this position. It is not possible to copy a reference and paste it with the aid of
the | PASTE command; the | PASTE REFERENCE command must always be used
instead for that.
Paste link
Call: | EDIT | PASTE LINK

This does not paste new objects but instead references to the copied objects.
These references function in a similar way to links in Microsoft Explorer: the
object is made available through this reference, but the link is not the object
itself.
A reference can only be created once in the unit view and once in the location
view. The reason for this is that the reference is the visual equivalent of a
pointer. In other words: if a reference is pasted in the planning side, a pointer
to the unit / location is then set in the Properties window of the planning
object. And each object can have only one additional pointer to a unit / loca-
tion.
A reference is marked with an L (= link) in many list windows. See also
SECTION 7: INHERITANCE regarding referenced objects (= linked objects).
2.3 View
2.3.1 Direct commands
Direct start
| VIEW | DIRECT START
If direct starting has been activated, then the next time that Comos starts it
automatically attempts to recreate the working environment that had existed
when it was last quit.
Thus the database and the project that had been running when Comos was last
ended are opened again. If the last object that had been selected in the Navi-
gator was not inherited, the tree is folded out correspondingly up to this point.
Navigator
| VIEW | NAVIGATOR

Menu overview View
The Navigator is called up when Comos starts. This menu item allows the
automatic activation of the Navigator to be disabled. See also SECTION 10: DIS-
PLAY IN THE NAVIGATOR.
Open extra Navigator
Call: | VIEW | EXTRA NAVIGATOR

A Navigator is opened in a separate window. You can quickly copy objects
between two different areas of the structure tree with the aid of the separate
Navigators.
The extra Navigator contains the “old” project when the project is changed.
See alsoSECTION 10: DISPLAY IN THE NAVIGATOR.
Load PlugIns
| VIEW | LOAD PLUGINS
This command updates the PlugIn menu bar. Please note that a number of
functionalities are only offered by the PlugIn symbol bar. If this symbol bar
is not shown, then probably a number of Comos functionalities have not been
made available to you.
Script error handling

| VIEW | SCRIPT ERROR HANDLING
If the option has been enabled, then in the event of a script error the system
shows the point of the error within the corresponding script editor of the
object that possesses the script with the error.
Under certain circumstances the project can also be changed within the base
project.
The user can now directly correct the error in the script or else edit the prop-
erties of the queries. The global variables can also be queried.
2.3.2 Sub-menu Icon with placing information
If the option is activated, a tick is shown in the Navigator at the icons at the
top right when the object is placed on a report. It is possible to distinguish
between two options here:
For all placed objects : The tick is shown for all objects that are placed.
Only for placed elements : The tick is only shown for objects that are in the
elements collection of another object (created on the Elements tab).

View Menu overview
Please note that this option requires a good deal of computer capacity. It is
best to disable this option on slower PCs.
2.3.3 Sub-menu Menu bar / Symbol bar
The following commands relate to the appearance of the menu bar. In partic-
ular, you can use them to save symbol bars that you have created.
| MENU CONFIGURATION |LOAD ORIGINAL CONFIGURATION
– The original menu configuration is loaded.
| MENU CONFIGURATION | LOAD MENU BAR FROM...
– Here you can stipulate which configuration file (*.atb) you wish to
access.
| MENU CONFIGURATION | LOAD MENU BAR LAYOUT...
– At this point you can specify which menu layout you wish to load
(selection of *.atb files).
| MENU CONFIGURATION | SAVE MENU BAR TO...
– Here you can stipulate where the current menu configuration is to be
saved.
Sub-menu Symbol bar

| MENU BAR /SYMBOL BAR | SYMBOL BARS | ...CREATE SPECIFICALLY
– Base objects can be made available in the self-created symbol bar. In
other words: you do not need to search for certain base objects in the base
data, but instead you can have access to these objects directly from the
symbol bar.
Apart from base objects (CDevices), templates and queries can also be
placed in symbol bars. Symbol bars can also be displayed in the second
screen in a multi-screen setup.
If there are base objects with a template in the symbol bars, you can get a
preview of the symbol by clicking on the symbol itself.
Apart from base objects (CDevices), modules and queries can also be
placed in symbol bars.
– Symbol bar created specifically by the user
This is the symbol bar that you can design entirely as you wish. This
symbol bar is created as an atb file in the personal profile directory by
Windows, the name of the atb file is the same as the name of the symbol

Menu overview View
bar. In other words: nobody else but you can access this symbol bar, but
you also have the security of knowing that you will not “disturb”
anybody.
– Symbol bar created specifically by the base data
If a symbol bar is created specifically by the base data, this symbol bar is
visible to all Comos users who work in the same database. The symbol
bar is created in the base project in branch @System | @Symbols. You do
not have to switch to the base project to do this. The base-data-specific
symbol bar can also be created within the planning project, provided that
you possess the Base data editing function right. However, you may not
edit @Symbols in the Navigator but instead must use the dialog window
to create special symbol bars, see the next section.
– Symbol bar created specifically by the document
This symbol bar is visible to all Comos users who open this document. A
planning object with the name “@Symbols” is created under the report
template in the base project to do this. The @Symbols planning object
points to another template through the implementation pointer or else
possesses directly under it the collection for the symbol bar.
Here too you may not work in the Navigator itself. The command (and
also the | LOAD ORIGINAL DOCUMENT-SPECIFICALLY command) is active
when a report is opened.
Create symbol bar

All symbol bars are created the same way, regardless of which type they are.
Step 1: Select or create symbol bar
Click on the Create new symbol bar icon. The new symbol bar is
initially given a default name such as “@Sb_1”.

Administrator Menu overview
Now right-click in the upper area of the dialog window, as shown in the fol-
lowing screenshot:
Click on the | CUSTOMIZE command.

In the following dialog window you should click on the symbol bar that you
wish to rename and then select [RENAME]. Ignore all the other buttons. Con-
firm with [OK].
All symbol bars are offered in the Symbol bar dropdown field. Pick one.
Step 2: Insert base objects
Use the mouse to drag base objects onto the “Drag... objects ” field.
Step 3: Confirm
The confirmation also closes the dialog window. The newly created symbol
bars are by default always added to the right at the edge of Comos, since this
arrangement is good when working with Interactive Reports. You can also
reposition the new symbol bars. Click on the edge of the symbol bar and drag
it to the new position.
2.4 Administrator
Apart from CVS MONITOR, the administrator functions can only be used when
a database is opened.
2.4.1 Sub-menu Base data
Standard tables
| ADMINISTRATOR | BASE DATA | STANDARD TABLES
See SECTION 11.1: STANDARD TABLES

Menu overview Administrator
Unit systems
| ADMINISTRATOR | BASE DATA | UNIT SYSTEMS
See SECTION 11.2: UNIT SYSTEMS
Document types
| ADMINISTRATOR | BASE DATA | DOCUMENT TYPES
See SECTION 11.3: DOCUMENT TYPES
Import ECAD components

| ADMINISTRATOR | BASE DATA| IMPORT ECAD COMPONENTS
See SECTION 56.1: ECAD DATA (IMPORT).
2.4.2 Sub-menu System
Support
| ADMINISTRATOR | SYSTEM | SUPPORT

The Support dialog window includes a number of utility programs and orga-
nizational aids.
See SECTION 3.6.1: UPDATE VERSIONS
See SECTION 3.6.2: DATABASE UTILITY PROGRAMS
See SECTION 3.6.3: DATABASE ORGANIZATION
See SECTION 3.6.4: PROJECT UTILITY PROGRAMS
See SECTION 3.6.5: STATUS
Performance Monitor
| ADMINISTRATOR | SYSTEM | PERF. MONITOR
See SECTION 3.9: PERFORMANCE MONITOR.
CVS Monitor
| ADMINISTRATOR | SYSTEM | CVS MONITOR
See SECTION 3.10: CVS MONITOR.
User management
| ADMINISTRATOR | SYSTEM | USER
See SECTION 6: RIGHTS MANAGEMENT

Extra Menu overview
Database reconciliation
| ADMINISTRATOR | SYSTEM | DATABASE RECONCILIATION
See SECTION 49.3: DATABASE ADJUSTMENT
Project directory matching

| ADMINISTRATOR | SYSTEM | PROJECT DIRECTORY MATCHING
(document directory matching)
See SECTION 30.1: SYNCHRONIZE PROJECT FOLDER
2.5 Extra
2.5.1 Sub-menu Bulk processing
Bulk processing of planning data

| EXTRA | BULK PROCESSING | BULK PROCESSING
See SECTION 26.2: BULK PROCESSING OF PLANNING OBJECTS.
Bulk processing of base data

| EXTRA | BULK PROCESSING | BULK PROCESSING FOR BASE DATA
See SECTION 26.3: BULK PROCESSING OF BASE OBJECTS.
Bulk processing of attributes

| EXTRA | BULK PROCESSING
| BULK PROCESSING FOR ATTRIBUTES
See →SECTION 26.3: BULK PROCESSING OF BASE OBJECTS.
Bulk processing of documents

| EXTRA | BULK PROCESSING | DOCUMENT EDITING
See SECTION 29.1: EDITING DOCUMENTS.
2.5.2 Sub-menu Query
At this point you have available to you all the base objects that are in the base
data under @System | @O | @Query and are created by using the
| NEW QUERY... mouse menu.
A basic structure can be created by database reconciliation, see SECTION 49.3:
DATABASE ADJUSTMENT.

Menu overview Extra
2.5.3 Sub-menu Standard import
At this point you have available to you all the base objects that are in the base
data under @System @O @StdImport and are created by using the
| NEW STANDARD IMPORT... mouse menu.
A basic structure can be created by database reconciliation, see SECTION 49.3:
DATABASE ADJUSTMENT.
2.5.4 Sub-menu Language translation
Translate “Description” of an individual object

| EXTRA | LANGUAGE TRANSLATION | OBJECT LANGUAGE TRANSLATION
See SECTION 42.4.2: TRANSLATE “DESCRIPTION” (OBJECT LANGUAGE TRANSLA-
TION).
Translate “Description” of multiple objects

| EXTRA | LANGUAGE TRANSLATION | TRANSLATION FOR OBJECTS
See SECTION 42.4.3: TRANSLATION OF MULTIPLE OBJECTS.
Translate entire database

| EXTRA | LANGUAGE TRANSLATION | TRANSLATION OF COMOS DB
SECTION 42.4.4: TRANSLATION OF COMOSDB.
2.5.4.1 Sub-menu Test
Test individual objects

| EXTRA | TEST | OBJECT TEST
See SECTION 30.3: OBJECT TEST.
Reduce object data: instances for attributes

| EXTRA | TEST | EDIT INSTANCES
See SECTION 20.6: RETROSPECTIVE SETTING UP OF INSTANCES.
2.5.5 Sub-menu Detail
Implement request object
Call: | EXTRA | DETAIL | IMPLEMENT REQUEST OBJECT

Extra Menu overview
Device requests are replaced by actual manufacturer devices with the aid of
this dialog window. See SECTION 60: REQUEST AND IMPLEMENTATION.
Signal Manager
Call: | EXTRA | DETAIL | SIGNAL MANAGER

This dialog window allows large numbers of signals to be set or changed
quickly. See SECTION 55.1: SIGNAL MANAGEMENT.
Copy data for the template project
Call: | EXTRA | DETAIL | COPY FROM TEMPLATE PROJECT

The template project is opened in the Comos Navigator (for short: Navigator).
Objects can be copied from here and edited.
Device modification
| EXTRA | DETAIL | CHANGE BY RULE:...
See SECTION 58.1: RUPLAN IMPORT.
Product data
| EXTRA | DETAIL | DEVICE SELECTION (PRODUCT DATA)
See SECTION 61.6.2.2: SELECTION FOR A PLANNING DATA BRANCH.
Determine connection characteristics

| EXTRA | DETAIL | CHARACTERISTICS FOR CONNECTIONS
See SECTION 59.7.1.6: CONNECTION INFORMATION FOR CONNECTORS: DIALOG WIN-
DOW “CHARACTERISTICS FOR CONNECTIONS”.
Connecting devices with one another

| EXTRA | DETAIL | CONNECTING DEVICES
See SECTION 59.7.1.5: WORKING WITH THE “CONNECT DEVICE” DIALOG WINDOW.
2.5.6 Sub-menu Working layers / histories
Management of working layers and histories

| EXTRA | WORKING LAYERS/HISTORIES | MANAGEMENT
See SECTION 4.5.1: DIALOG WINDOW “SELECT WORKING LAYER” for the Histories tab.

Menu overview Windows
See “Working layers” tab, P. 4-16 for the Working layers tab.
Monitor object status

| EXTRA | WORKING LAYERS / HISTORIES | OBJECT STATUS
See SECTION 4.5.5: DIALOG WINDOW “OBJECT STATUS”.
2.5.7 Commands
Compare properties of objects

| EXTRA | OBJECT COMPARER
See SECTION 8.5: THE OBJECT MATCHER.
Copy objects across properties

| EXTRA | COPYING ACROSS PROJECTS
See SECTION 8.4: COPYING ACROSS PROJECTS.
Create report templates

| EXTRA | REPORT DESIGNER
See SECTION 46: REPORT DESIGNER.
Test working areas

| EXTRA | TEMPORARILY RESTRICT WORKING AREAS
See SECTION 6.4: WORKING AREAS
Test and manipulate objects

| EXTRA | OBJECT DEBUGGER
See SECTION 30.4: OBJECT DEBUGGER.
System Monitor
| EXTRA | SYSTEM MONITOR ([Ctrl]+[S])
See SECTION 3.8: SYSTEM MONITOR.
2.6 Windows
This menu controls the display of multiple open windows. If, for example
(with a single screen), both a Properties window and an Interactive Report are
opened, the second window covers the first window that was opened.
| WINDOWS | ON TOP OF ONE ANOTHER (CASCADE?)

Help Menu overview
– Arranges the windows on top of one another.

| WINDOWS | NEXT TO ONE ANOTHER (TILE?)
– Arranges the windows next to one another.
| WINDOWS | OVERLAPPING
– The windows cover one another.
If two or more reports are opened, an additional entry “CLOSE ALL DOCUMENTS”
appears in the Comos menu under | Windows .
If you select this menu item, a list appears with all the Comos documents that
are open; you can thus determine whether or not the document in question is
to be saved. By default all documents are set to “Save ”. The function can be
applied to all the elements of the list by using the [CLOSE ALL] button.
Please note: Only Comos documents are included in the list. For example, the
list does not include MS Office documents, since these are displayed and
edited outside Comos in MS Office applications.
2.7 Help
Contains the PDF files of the Comos manuals, the PDF file for the Microsoft
VB Script reference and the command for the information window. Please
note that Comos also has context-sensitive help available through the F1 key.
2.8 The “PlugIns” icon bar

Document interface
See SECTION 36: CDI (COMOS DOCUMENT INTERFACE).
Base data import Triga 1.04

See SECTION 56.5: VNS IMPORT.
DWG/DxF Mapping Editor

See SECTION 35: AUTOCAD (IMPORT, EXPORT DXF).
Assignment Manager
See SECTION 55.3: ASSIGNMENT MANAGER.
EPlan data exchange

See SECTION 56.2: EPLAN DATA TRANSFER (IMPORT EXF).

Menu overview The “PlugIns” icon bar
Marshaling Management
See Quick start MSR.
Pipe classes
See Quick start Viper.
Ruplan import
Viper
See Quick start Viper.
Conversion of units
See SECTION 30.2: UNIT CONVERSION.
VNS import
See SECTION 56.5: VNS IMPORT.
Export LogiDoc (in Access)

The “PlugIns” icon bar Menu overview

Database Administration Login
3 Database Administration
3.1 Login
3.1.1 Open data base / login window
Command: | FILE | OPEN DATABASE or [Ctrl]+[D].

Line 1: this is where the database type is selected.
The basic version of Comos is supplied with an Access database.
If you want to work with Access, leave the default setting at Microsoft Jet .
Line 2: this is where a specific database is selected.
The [...] button opens a file selection dialog where you can look for mdb files.
You will find a sample database on the Comos CD. If an Oracle or SQL Ser-
ver has been selected in line 1, you cannot select a database, only an instance
can be selected.
See Installation, section 3.2.1.2 “Create instances for SQL Client” and
section 3.3.1.3 “Create ODBC data source for Oracle Client”.
Line 3: Firstly, the user name you used to log on to the company network
when you started your PC ('login') is copied. However, you can change your
Comos access level by right-clicking on the User name field. The different
access levels (login names) are explained in the following chapters.
3.1.2 Setup login in the release data base

Universal access
This command enters the user @SETUP in the User name field. Whereas
the two other access possibilities (Default or standard and Alternative
access) enter a different name on each PC, you can use the universal access to
log on to Comos from all PCs as @SETUP .
The rights of the user @SETUP are defined within the framework of the
rights administration (user management).
In the sample database Comos.mdb, a user @SETUP has been set up under
user management with administrator rights for this sample database. If you
log on with this account, you can test all the possibilities.
This only applies, of course, if the administrator rights have not been with-
drawn from @SETUP in the sample database.

Login Database Administration
3.1.3 Alternative access
Alternative access
If this command is selected, the ending '_2' is added to the user name. This
means that a second user name to which independent rights can be assigned
is available to each user in Comos.
3.1.4 First login in a new data base
See SECTION 3.2.1: INITIAL LOGGING-IN INTO A NEW DATABASE.
3.1.5 Login checks
3.1.5.1 Definitions
Database scheme
All the object properties that are available in Comos are stored in the Comos
database. If an object property that did not exist before is introduced in a cur-
rent Comos version, the Comos database must be extended to be able to take
this new property.
Database indices
Database indices are required to speed up access. The result of this check is
displayed in a dialog window together with the test of the database scheme.
Database version
Comos databases are given explicit version numbers when the appropriate
developments are made.
Document version
In the same way as for database schemes, with documents there is also a con-
stant further development of options. The document version determines the
range of options open to the user. New options can only be used once the doc-
ument version has been incremented.
3.1.5.2 Matching of database scheme and database indices
Joint matching
The database scheme and database indices are jointly matched. A dialog win-
dow opens and clicking on [MATCH] acts on both of them.

Database Administration Login
Conversion matrix
• Old Clients
– Old database (scheme and/or indices not matched):
Normal state
– Converted database (scheme and/or indices matched):
Old Client can open the database and use the “old” functionalities, but not
the new ones.
• New Clients
– Old database (scheme and/or indices not matched):
New Client cannot open the old database.
– Converted database (scheme and/or indices matched):
Normal state
User
If the user opens an older Comos database with the current version of Comos,
the following message is shown:
The tables of this database do not meet the requirements of COMOS!
Please contact your COMOS administrator!
Comos remains open after the message and you can select another suitable
database.
Administrator
If an administrator opens an older Comos database with the current version of
Comos, a dialog window “Checking the tables ” opens as well. There are the
following options:
[No ]
The database remains unchanged and is not opened. Comos remains open and
you can select another suitable database.
[Yes ]
The database scheme is matched. Both the older and the new current Comos
Clients can be used in the usual way. No data is lost. However, the older
Comos Clients cannot make use of the options that are made available by
updating the database scheme.

Login Database Administration
3.1.5.3 Increment database version
Conversion matrix
• Old Clients
– Old database (database version not matched):
Normal state
– Converted database (database version matched):
Old Client cannot open the converted database.
• New Clients
New Client can open the old database.
Normal state
Implementation
The database version is managed with the aid of the support dialog in Comos,
see SECTION 3.6.1: UPDATE VERSIONS.
Please note: The database version cannot be set back to an older version after-
wards.
3.1.5.4 Increment document version

Old Clients cannot work with documents that have a higher document ver-
sion.
Conversion matrix
• Old Clients
Normal state
Old Client is given a warning message when logging in.
Old Client can open and edit documents that have not been updated to the
new document version.
Old Client can only open documents that have been updated to the new
document version.
• New Clients

Database Administration Create / link databases
– Old database (document version not matched):

New Client can open old databases.
New Client can open and edit old documents.
– Converted database (document version matched):
Normal state
The old documents are updated to the new document version when they
are saved for the first time by the new Client.
Implementation
The document version is managed with the aid of the support dialog in
Comos, see SECTION 3.6.1: UPDATE VERSIONS.
Please note: The document version cannot be set back to an older version
afterwards.
3.2 Create / link databases

In addition to Comos, you also need a database in which Comos can save its
data.
Currently the following databases are supported:
Access Access 95, Access 97, Access 2000 (via DAO)

A preconfigured Access database is included with
the program.
MS SQL-Server MS SQL-Server 7.0 or 2000 (via ADO)
ORACLE ORACLE 7.3x, ORACLE 8.x (via ADO)
Recommendation:
Number of users < 5: Access
Number of users 5 or more: MS SQL Server
Please note that in particular accesses can be set up via instances, see for
example Installation, section 3.2.1.2 “Create instances for SQL Client”.

Create / link databases Database Administration
3.2.1 Initial logging-in into a new database
Please note: it is not possible to start work at once with a new blank database.
In particular, it is not possible to make any accesses that are external to the
database, such as an export access (see SECTION 3.4: IMPORT / EXPORT OF DATABA-
SES). The administrator must first of all be logged in: he or she is entered in the
User management window as the administrator during this first login.
3.2.2 Setup login in the sample database
A user @SETUP has been created in the user management in the sample data-
base Comos.mdb. But as described above, for security reasons it is not possible
to enter just any name for the login. The user name is taken from the operating
system in the Open database dialog window.
A preconfigured entry is available when right-clicking with the mouse to
input the user name @SETUP in the Open database window.
• Open the sample database Comos.mdb .
• Command: right-click in the User name field
• Mouse context menu | Universal Access
This creates a login name @SETUP.
Alternative form of access

You must use the mouse context menu to input the alternative access in the
Open database window:
• Open the database.
• Command: right-click in the User name field
• Mouse context menu | Alternative Access
This creates a login name that consists of the default login name with a “2”
attached to it. Other user rights than those given to the default user can now
be allocate to this user.
3.2.3 Create new Access database
1. On the File menu, choose the OPEN DATABASE command.

2. Make sure you have the default setting Microsoft Jet enabled and click
on the [...] button to the right of the input field.

Database Administration Distributed databases (synchronized DB)
3. This window behaves like Microsoft Explorer: You can navigate within
the directory structure of your PC.
Change to the desired directory and input a filename. The required file
extension is added automatically.
4. Click on the [OPEN] button.
You are asked if you are sure, and this must be confirmed with [YES].
5. You are returned to the Open Database dialog window. Log in as
administrator.
3.3 Distributed databases (synchronized DB)
3.3.1 Distributed access via a Terminal Server using the example of

Citrix
It is possible to access the same database from different PCs with the aid of
the third party Citrix Terminal Server software.
3.3.2 Preparation of a Comos database
Comos has the option of version management for the distributed keeping of
data. In this case the stocks of data of physically separated databases can be
synchronized. The synchronization is initiated manually and then carried out
automatically.
This method must not be confused with the importing or exporting of projects.
Data can be bundled together in a database in this way, but this process creates
parallel projects in the Comos database that must then be merged manually.
The prerequisite for synchronization is that a Comos database has been pre-
pared and then a special copy is made of it. If two completely independent and
separate databases are created, these databases cannot be synchronized retro-
spectively, regardless of how similar these databases appear to be.
1. Open a database, using administrator rights, and open any desired project.
2. Open the Support dialog window via the | ADMINISTRATOR | SYSTEM
| SUPPORT menu and change there to the DB Orga. tab.
3. Input any letter in the DB identifier field.
Please note: You may not use any letters that have ever been used at any time
by any database as a DB identifier! This also include test versions, meaning
database copies that had been deleted later.

Distributed databases (synchronized DB) Database Administration
Please create a list of which DB identifiers you have used and for
which database!
It is not important for the next step whether Comos remains open or is closed.
3.3.3 Creating the synchronized copy (ExportDB)
The sub-directory \bin is in the objects folder of Comos. There you should
start the program ExportDB.exe. See also SECTION 3.4.2: EXPORT regarding the
export of a database.
Input in the Source the database to which a DB identifier had been allocated
in the previous step. Ensure that you are logged in as administrator in the User
name field.
A new database is input in the Target field. You cannot use any of the exist-
ing databases.
Without deleted This option is not evaluated during a synchroniza-

objects tion. For that reason this option is greyed out when
DB synchronization is activated. The setting of the
Without deleted objects option is not important at
this time.
In principle, deleted objects are ignored during a syn-
chronization operation. In other words: a DB syn-
chronization behaves as if the Without deleted
objects option had been activated.
DB Activate the option switch with DB synchroniza-
synchronization tion .
DB identifier The DB identifier field appears as soon as the option
switch is activated. Here you can input any letters
that have not been used yet.
Please note: You may not use any letters that have ever been used at any time
by any database as a DB identifier! This also include test versions, meaning
database copies that had been deleted later.
Please create a list of which DB identifiers you have used and for
which database!

Database Administration Distributed databases (synchronized DB)
You can input in the Projects dialog window which projects are to be
exported synchronized. You have two options available: You can specifically
mark the projects that are to be exported synchronized or else simply mark all
the projects. Depending on the database and the amount of data, the options
can save time under the appropriate circumstances.
If there are only a few projects that you do not require within a large number
of projects, it is nonetheless quicker to mark all the projects. (The “superflu-
ous” projects can be deleted later from the target database.) The reason for
that is that while “superfluous” data is exported in this case, it is only neces-
sary to go through the database once.
If there are only a few projects that you actually require within a large number
of projects, it is nonetheless quicker to select only those projects that you
want. The reason for that is that while it is necessary to go through the data-
base for each project, no “superfluous” data is exported.
Confirm with [EXPORT].
Caution: the export process can take several hours if the database is large!
You get the corresponding message once the export process has been com-
pleted.
3.3.4 Working with synchronized distributed data
You can work in the normal way with both databases.

Distributed databases (synchronized DB) Database Administration
3.3.5 Reconcile the data again or summarize it
You have both the option to summarize the data in one of the synchronized
databases and also to reconcile the databases. In the first case the source data-
base remains unchanged, while in the second case the updating is done in both
directions. Use the ImportDB.exe program in sub-directory \bin for both
options:
In principle, either of the two databases can be the Source or Target in the
Import Comos database dialog window. (Ensure that you have logged in
as administrator in the User name fields of both databases.)
A number of different changes take place, depending on which database was
selected as the source and which one as the target, since the source database
always wins in the event of a data collision!
The corresponding query messages are shown if the identifiers are not differ-
ent or were not set.
The following dialog window has the title Projects :
Synchronize databases
• If the switch was not activated, then the data in the target database is
summarized and the source database is not changed.

Database Administration Import / Export of databases
• Both databases are synchronized if the switch is activated.
Confirm with [IMPORT].

You are given a confirmation when the import process has been completed.
The import process runs automatically. The data is created, deleted or
changed without the user having to intervene. It is not possible to tell in the
synchronized database which data had been chenged or added in the course of
the synchronization. All the data is of equal value.
Any data collisions are logged in the error list which is output in the Object
test dialog window. The value from the source database is used in the event
of a collision.
See also SECTION 30.5.2: DBSYNC.EXE.
3.4 Import / Export of databases
3.4.1 Import
The import function is used exclusively to adjust synchronized databases. See

SECTION 3.3.5: RECONCILE THE DATA AGAIN OR SUMMARIZE IT.
3.4.2 Export
Comos is in the position to export its own databases. The procedure depends
to some extent as to which types of database were used. While Access data-
bases can also be created by Comos itself, the server databases that are cur-
rently supported must be created from scratch from the corresponding
software.
In other words:
• If you wish to export to a server database, a blank new server database must
exist already.
In addition, the administrator must have already logged into the new blank
database so that he is listed in the user administration of the new blank
database as administrator.
• If you wish to export to an Access database, it must be created during this
export process. It is not possible to use an existing database.

Import / Export of databases Database Administration
The sub-directory \bin is located in the objects folder of Comos. There start
the program ExportDB.exe.
In order to use ExportDB, the user must have the following rights: “Read” and
the meta-right “Project management.” ExportDB can also be used for the syn-
chronization of databases, see SECTION 3.3.3: CREATING THE SYNCHRONIZED COPY
(EXPORTDB).
Input the name of the database to be exported from in the Source field.
Ensure that you have been logged in as administrator in the User name field.
The new database is input in the Target field. If you selected an existing data-
base as the target, then all the data in the target database will be deleted and
the data from the source will be written to it.
Documents sub-directory
If you select a server database in the Target , you then have the option to select
an instance. In addition, you can set the documents directory:
Select a new blank directory as the documents directory.

Never select a directory that has already been used as a documents
directory by other databases! A double access would lead to a loss
of data.
Never select a directory that already includes other data or sub-
directories! The documents directory is used by various functions
within Comos (for example, by a number of Support functions)
and data would be lost as a result.

Database Administration Import / Export of databases
See also SECTION 3.6.3: DATABASE ORGANIZATION regarding the documents direc-
tory.
The options switches are as follows:
Without deleted If objects are deleted in Comos, they have still not
objects been deleted physically for safety reasons. Instead
the objects are simply given a Delete-Flag and
can no longer be accessed by a normal user.
Use the Support function to finally and defini-
tively delete such objects.
If the option has been activated, then objects with
the Delete-Flag are not exported.
With DB See SECTION 3.3.3: CREATING THE SYNCHRONIZED COPY
synchronization (EXPORTDB)
Confirm with [NEXT].

You can input in the following Projects dialog window which projects are to
be exported synchronized.
You have two options available:
1. You can mark the specific projects that are to be exported synchronized.
If there are only a few projects that you do not require within a large
number of projects, it is nonetheless quicker to mark all the projects. (The
“superfluous” projects can be deleted later from the target database.) The
reason for that is that while “superfluous” data is exported in this case, it
is only necessary to go through the database once.
2. If there are only a few projects that you actually require within a large
number of projects, it is nonetheless quicker to select only those projects
that you want.
If only planning projects are marked, an additional query is made: “Are the
system project and base objects project to be exported as well?” A planning
project cannot be run without the system project and the base objects project.
The query ensures that you are reminded of this in case you simply forgot to
mark these projects as well.
Confirm with [EXPORT].
Caution: the export process can take several hours if there is a lot of data.

Copy system project Database Administration
You get the corresponding message once the export process has been con-
cluded.
If the export process was terminated manually or if an error occurred, you can
then open a new database but should not use the projects involved in the error.
Comos displays the corresponding message:
... Please delete the project from the database
3.5 Copy system project

The system project includes lists and information that run across all
the projects, see SECTION 5.1: THE SYSTEM PROJECT. This function should
only be used by administrators.
Start the program Sychange.exe, P. 30-15 in sub-directory \bin under the installa-
tion path of Comos. The Accept Comos system project dialog window
appears:
Please ensure that you have been logged in as the administrator in the User
name field, otherwise the process is terminated for safety reasons.
The Oracle and SQL Server options presuppose that the corresponding data-
base links have been installed in the ODBC administrator of your PCs.

Database Administration Support
You can determine in the From section (the upper part of the window) from
which database the system project is to be taken for use. Select the drive, path
and filename of the database containing the new system project by using the
[...] button.
Within the target database a sequential number is appended to the name of the
previous system project, and then the new system project is copied.
You get the corresponding message once the function has been concluded.
Error log
Any objects that could not be allocated when the system project was copied
are logged in error log file C:\..\TMP\NoCon.DAT. You can also input in the
“Error output at” field into another path and filename or select with the but-
ton next to the field.
3.6 Support
The “Support” tool is opened with:
| Administrator | System | Support
3.6.1 Update versions
3.6.1.1 Introduction and concept

All the components of Comos are constantly being further developed: the
software, the databases and the documents.
Further development of the database

Normal case: table adjustment
As a rule further development consists of adding new functionalities while
continuing to support old functionalities. In such cases the administrator is
requested to adapt the tables suitably. However, workstations with older ver-
sions of Comos can still continue to work with the database and with the other
Clients in the network.
Special case: database version adjustment
In rare cases it is necessary to remove a functionality or to change it in such a
way that the previous older versions can no longer work with a current data-
base. An adjustment of the database versions is only required and carried out
in such a case.

Support Database Administration
The administrator can only carry out a database conversion once all the PCs
have been equipped with the new Client version. The full upgraded scope of
Comos is available after the database has been converted.
Further development of the documents

Constant functional further development of the reports requires a form of doc-
ument version management to avoid problems with older versions of Comos.
Interactive reports such as hatching will be processed and save at the latest
further development level. These further developments are managed as
“report versions”: functional further developments on a larger scale increment
the report version number.
The usual rules concerning the compatibility of the of the software are:
• Reports with older version numbers can be read and processed by current
versions of Comos versions.
• Older versions of Comos cannot fully read or process reports with higher
report versions.
If an interactive report is saved, then a crp file is created within the Comos
documents directory and this includes details on which report version is
involved. In practice, after version changes there are both workstations work-
ing with the current version of Comos as well as workstations that still use
older versions of Comos. The older report versions still need to be kept so that
the reports can still be read and processed at the workstations with the older
setup during the transitional phase. This means:
• Reports with an older version level are not converted to the newer version.
• New reports are still created in the older report version.
If the newer version of Comos was installed on a workstation and was used to
access a database in which the “ database-internal permitted document ver-
sion” (see the following) had not yet been brought up to the latest version
number, then information to that effect is given during the login.
The version management function determines from when the newer report
version is to be used.
The Version tab is in the | Administrator | System |Support menu. In it
there is the [Match document Versions ] button that has the following
effect:
• In the database the information is stored to the effect that reports are
permitted as of immediately with the current (higher) version numbers. This
information is known as the “database-internal documents version.”

Database Administration Support
• Thus no messages are shown during login concerning the deviation between
the documents version and the database version.
• New reports are created as of immediately with the higher version.
• Older reports initially remain unchanged (no automatic mass conversion),
they are only saved in the higher version once these reports have been
opened and saved again.
3.6.1.2 Application
Open the Support dialog window with the | Administrator | System
| Support command. Change to the Version tab.
[Match document Versions ]
If this function is initiated, then not only is a variable set to a higher value, but
conversions are made within the database. These conversions cannot be
undone. Once a database has been converted, PCs with older version levels
can no longer access it.
During the transition period, on networks there will be PCs with the current
version of Comos as well as PCs with older versions of Comos. It is therefore
recommended that you do not convert the database until all the Comos Clients
have been changed over accordingly. “Old” and “new” Clients can still access
the “old” database and work quite normally. There is no pressure to convert
the database at the time of the first login of a Comos Client.
The question of the compatibility of different version levels obviously will
not arise if Comos is only used locally on non-networked PCs.
3.6.1.3 Effect of database version adjustment:

The effect depends on what further development must be adjusted by carrying
out a database adjustment.
[Match document Versions ]
In the database the information is stored to the effect that reports are permitted
as of immediately with the current (higher) version numbers. This informa-
tion is known as the “database-internal documents version.”

Support Database Administration
3.6.2 Database utility programs
3.6.2.1 Compression
Databases mostly have a number of different functions to ensure the security
and integrity of the data. The disadvantage of such safety functions is that they
require a lot of memory and disk space. For that reason there are two functions
within Comos to reduce the size of the database again.
Open the Support dialog window with the | Administrator | System
| Support command and change from there to the DB Utility tab.
[Compress When data is deleted in Comos, this information is not

Comos data] actually deleted physically. Instead the data is given a
Delete-Flag and is no longer displayed in the interface.
If this function is run, all data, directories and drawings
with a Delete-Flag are also deleted physically as well.
[Repair, The Access compression function is run for the selected
Compress ] Access database.
3.6.2.2 Check and clean
[CHECK This function is not required if you are working within

INDEXES] the default Comos database, type mdb.
Perhaps the indexes had been deleted at some time by the
administrator for operational reasons. In such a case the
processing speed within Comos drops considerably. The
missing indexes are restored with the help of this com-
mand.
[CHECK Deletes unused login entries. The user administration is
“LOGIN” not affected (list of registered users, user rights, etc.).
ENTRIES]
Login entries are used for efficient administration of the
time stamp. For example, all the objects possess a piece
of information, this being when they were created and by
whom. The information on by whom the object was cre-
ated is not stored n times for n objects but is taken from
the login entries. For that reason a complete list of all
entries is saved first of all. The login entries that are not
used can be deleted later.

Database Administration Database adjustment
3.6.3 database organization
Commands of the DB Orga. tab:
Document Determines the documents directory.

directory The importance of the documents directory depends on
the database that is used. While Access does not need an
entry here, server databases require an entry to be made.
Please note that root directories are not allowed. For
example, root directories can also be mapped drives in
Windows Explorer.
DB identifier Means of indentifying the databases. The DB identifier is
only needed if a Comos database is to be copied for
decentralized processing. This is done by exporting a
Comos database and determining a character (usually a
letter) as an identifier for the export process. From this
time on the original database and the copy created with
the identifier can be automatically adjusted.
The DB identifier is not able to retrospectively adjust two
different databases.
The adjustment rule in the event of data collisions is sim-
ple: the database that is being imported from wins.
See also SECTION 3.3.3: CREATING THE SYNCHRONIZED COPY
(EXPORTDB).
3.6.4 Project utility programs
See SECTION 5.4.3: PROJECT UTILITY PROGRAMS.
3.6.5 Status
The status information shows you whether Comos can be started correctly and
what settings you are working with. You should always have this information
at hand if you contact Support at innotec with a question.
3.7 Database adjustment

See SECTION 49.3: DATABASE ADJUSTMENT.

System Monitor Database Administration
3.8 System Monitor

The System Monitor is opened via the EXTRAS | SYSTEM MONITOR menu. Alter-
natively, click on any desired object in the Navigator and select the keyboard
command [Ctrl]+[S]. The result is that the System Monitor dialog window
opens.
The System Monitor makes it possible to control the cache and gives an over-
view of the Comos Client.
3.8.1 The Comos system status
Refresh speed
The Refresh speed determines at what intervals the System Monitor is
updated.
1. Number of objects
Number of Comos objects in the cache. The Number of objects is
limited by the entry in the Maximum loaded objects field.
2. Referenced objects
Number of Comos objects that are held by components and cannot be
removed from memory. Releasing objects does not affect the referenced
objects, which still remain in memory.
The Number of objects in 1. above is thus always greater than the
number of referenced objects.
3. Cache entries
Number of cache entries. The cache entries are a result of the Number of
objects from 1. above. The rule is as follows: the number of cache entries
is always considerably greater than the Number of objects . However, a
cache entry needs considerably less memory than an object. Releasing
objects does not affect the cache entries, which still remain in memory.
4. Hash table size
The cache entries are managed in the hash table. As a rule, initially a table
with 50,000 fields is created, and these are filled up bit by bit. If that is
not adequate, the hash table is enlarged to 100,000, and so forth.
5. Number of collections
Number of Comos collections in the cache (subset of 1.).

Database Administration System Monitor
Summary
The main points are the Number of objects and the Cache entries . Both
take up memory. The cache entries each take up less memory than do objects,
but on the otehr hand there are also significantly more cache entries.
The Number of objects is limited by the Maximum loaded objects field
and can also be reduced by “releasing objects”, see below.
The Cache entries cannot be limited in advance and also cannot be released.
If the number of cache entries has become so large that Comos runs slowly
(very rare), you need to quit and restart Comos.
3.8.2 Releasing objects (ReleaseObjects, ReleaseAllObjects)
3.8.2.1 Advantages and disadvantages of a cache

Comos uses its own cache. The advantage: The cache speeds up access to the
data. The disadvantage: The cache takes up more memory.
Using a cache has nothing but advantages as long as there is enough memory.
If there is not room in memory, in formation is written from the memory to
the hard disk and data is constantly swapped betwen the memory and the hard
disk. In such a case the cache has the opposite effect of what was intended and
access to the data is slowed down.
You should therefore never “globally” delete the object cache, because
Comos runs more slowly without caching if there is sufficient memory. The
object cache should never run short of memory in normal day to day opera-
tions; it is only worth clearing the object cache when carrying out operations
involving very large amounts of data.
3.8.2.2 Preparing to release objects: matching the cache and main memory
The amount of main memory available is not determined dynamically during
operations and released as required. Instead, Comos has the “Maximum
loaded objects” function.
Maximum loaded objects
The value selected for Maximum loaded objects determines from what
point the cache is to be emptied.
Optimum setting of the Maximum loaded objects field

From experience, this option should be set to Very low for 64 MB or less.

System Monitor Database Administration
The Maximum loaded objects field can be edited. Do this by marking the
text in the field, deleting it, and entering a number. Your input is saved per-
manently. The value that is input here is stored in Comos function MaxLoade-
dObjects (class Workset).
The limit to be set for the maximum number of objects to be loaded depends
on the amount of free memory available. For example, the amount of free
memory available can be checked from within Task Manager: start Comos
and determine how much memory is free. As a rule of thumb, 10,000 objects
require 10 MB of free memory.
Example: If you press Save, Comos then checks within the System Monitor
to see whether the specified upper limit has already been reached. If it has,
then any objects that are no longer required are deleted from the cache. You
can do the same thing by right-clicking on the Status bar on the SAVE field and
selecting the | SAVE command.
In very rare cases the user could carry out a series of actions that would not
be covered by Comos’s own optimization rules, and in such a case the cache
can become too big for the main memory and information is written back and
forth between the main memory and the hard disk. This can happen if a very
large number of objects are edited simultaneously, for example, due to bulk
processing or when copyimg a large unit.
In such a case the action should be terminated (if necessary, also with the Task
Manager), sicne the write operations to the hard disk require an extremely
large amount of time and make effective work impossible. Manual termina-
tion does not cause any loss of data.
To prevent an overflow of the cache, you should check whether the cache still
has enough space before carrying out larger operations (copying a unit or the
like), meaning that the number of objects in the cache should be well below
the limit for the maximum number of objects to be loaded.
Please note: If the limit for Maximum loaded objects is set too low, then
even the number of items that cannot be released (such as modified objects,
referenced objects) could push you over the limit. In such a case objects
would be released unnecessarily and caching would have almost no effect.
3.8.2.3 Executing an object release

The object release (in other words, a partial or total clearing of the cache) is
always done as the result of a user action. The cache is never deleted or
cleared by Comos itself.

Database Administration System Monitor
You can release the memory manually if there is no longer enough memory
(if the Number of objects is no longer well below the limit for the maximum
number of objects to be loaded).
There are a number of ways to clear the cache:
Manual deletion: releasing unused objects (ReleaseAllObjects)

Right-click on the Status bar that is at the bottom of the Comos window on
the Total objects field. Select the | RELEASE UNUSED OBJECTS command.
The cache is cleared in a targeted way by this command and the value given
in Maximum loaded objects is no longer evaluated. Before you use this
command, you should check whether it is really necessary to empty the cache.
Please note: This command only releases the memory within Comos. The
memory is not made available to the operating system. In other words: the
memory is still shown as being in use within the Windows Task Manager
or similar tools.
Clearing as the result of a user action (workset.ReleaseObjects)

The following actions also call up the ReleaseObjects Comos function:
• Save all (diskette symbol at the top left in Comos and Workset.SaveAll)
• ScanDevices
• Global Test (a Comos utility program)
• connecting a project to or disconnecting a project from a base project or a
system project
• copying a project.
Effect of ReleaseObjects: The value in Maximum loaded objects is eval-

uated and the cache is clear as far as possible if it has more objects in it than
the specified value.
Effect of clearing the cache

This clears out all objects and not only the number of objects “exceeding” the
value given in Maximum loaded objects .
The following are not deleted:
Modified objects that have not been saved yet, referenced objects, cache
entries. See SECTION 3.8.1: THE COMOS SYSTEM STATUS for an explanation of these
terms.

Performance Monitor Database Administration
Overview: all the Comos functions involved

MaxLoadedObjects
The number of objects, above which objects are to be deleted from memory
by ReleaseObjects.
ClearCache
Deletes all objects from memory! The state corresponds to a reinitialisation of
the workset, and all the old object variables are no longer valid, CurrentUser
and CurrentProject must be set again. ReleaseObjects must be used when
working with Comos; ClearCache can offer clear advantages if you are
developing your own software on the basis of Comos.
ReleaseObjects
Deletes the released objects from the cache if MaxLoadedObjects is
exceeded.
ReleaseAllObjects
As for ReleaseObjects. However, MaxLoadedObjects is not evaluated here.
3.9 Performance Monitor

The Performance Monitor is a tool that is used to measure the behavior of
Comos in great detail. This tool can only be used meaningfully by experi-
enced Administrators or by the customer service consultants of innotec
GmbH.
The Permanent Performance Monitor is of interest to developers and Admin-
istrators, since this tool logs the accesses of the software on different levels.
3.9.1 The History tab
The active modules are shown on this tab together with the monitoring value
that is currently valid for a module.
Please note: Only those modules that are currently active are shown in the list
area in the presettings. The list of active modules does of course change
according to the current working situation. If you wish to carry out base
objects processing, other modules than are shown in an EE/C&I report are
activated. A number of modules nearly always need to be run, such as
Functree. The options mean:

Database Administration Performance Monitor
[REFRECH] A new monitoring value is determined for the active

modules with this button. The relevant last three val-
ues can be displayed; the oldest value is deleted if you
initiate a refresh operation the fourth time.
An asterisk appears in the column Changed if a
change has been made to the currently determined
value (column: value) and the last value.
[DELETE] The older values are deleted.
Level Changes the level of the monitoring.
In the case of Off measuring has been turned off, in the
case of Debug most of the accesses are logged - and
even changes in the text fields of a report. The greater
the scope of the performance measurement, the
greater the amount of resources required by the Per-
manent Performance Monitor.
Time Switches all the modules on or off that measure the
time required by an action. These modules have at the
end the text .Time.
Count Switches all the modules on or off that measure the
frequency of an action. These modules have at the end
the text .Count.
AV Time Switches all the modules on or off that measure the
average time required per action. These modules have
at the end the text .AvTimeperCall.
0 Switches all the modules on or off that are not cur-
rently active, and thus have the value “0.”.
Instance Count Switches all the modules on or off that measure the
number of instances. These modules have at the end
the text .InstanceCount(er).
Various Switches all the modules on or off that do not come
under the above groups. These modules have no spe-
cial ending.
3.9.2 Select modules for monitoring
• Select one or more lines (modules).

CVS Monitor Database Administration
• Right-click on the selected lines and choose the command Monitor .

• Change to the Monitoring tab.
3.9.3 The Monitoring tab
This tab determines at regular intervals a monitoring value for the modules
that you selected.
• Click the [START] button.
The other options are as follows:
Time The interval within which a monitoring interval is deter-

interval mined.
Stop Stops the monitoring.
Calculate Not the monitoring values themselves but the only differ-
the ence between the currently determined values and the last
difference value is output.
3.9.4 Notes
If you retrospectively mark a value for monitoring, the module may indeed by
listed correctly on the Monitoring tab but no column header is shown. The
determined values are correct.
3.10 CVS Monitor

The CVS Monitor displays all Clients that can be reached at that time via
CVS.
• Last update:
The time at which the Client last made contact with the other Clients in the
network.
[Start protocolling ]
Writes the CVS information into a text file.
ID
Computer The name under which the PC is logged into the company
network.

Database Administration CVS Monitor
User The name under which the user is logged in to Comos.

Module The licenses currently being used by the user.
Database The database opened by the user.
Notes
The CVS Monitor uses resources-intensive network functions. It is impossi-
ble to run the CVS Monitor “simultaneously”. You can run other tasks when
the CVS Monitor has been switched on.

CVS Monitor Database Administration

Working Layers / Project History Goal
4 Working Layers / Project History
4.1 Goal
Aim: Splitting up data into topic-related blocks. These subsets can be edited,
modified and transported considerably more quickly, cost-effectively and
precisely. For that reason there are the following main functions:
• Create new working layer, release working layer.
– Initially the working layer is completely blank and only shows all the
information of the “parent layer”. Working in the working layer means
that you create a “subset of information” of the entire planning data. You
create a new working layer for each topic that you wish to edit separately
and only work there.
– If a topic is completed, you can release the working layer and thus make
the work generally available.
– Working layers can be set up and structured hierarchically. This gives
you the option to further sub-divide topics into sub-topics, etc.
• Working layer display and history display. Both functions illustrate the
respective editing status of the objects in a similar way to status display.
• Importing and exporting working layers
• History of the released area
4.2 Functional principle of working layers
4.2.1 Four states of objects
Objects are edited in working layers. If you compare a current object with any
desired earlier initital state, there can be four states:
Unmodified object Modified object

Deleted object New object

Functional principle of working layers Working Layers / Project History
These four states do of course occur in the original data as well, or in other
words, in the data that already exists regardless of any working layers. This
original data is also called the “released area”. See also SECTION 4.4.2: CON-
TROLLING THE PROPERTIES OF WORKING LAYERS (@WOLEVELS) for a definition of the
hierarchy of working layers.
If you thus open any particular project and check the data before and after a
certain point in time, the state could look like the following, for example:
Released Area
The above example has nothing to do with the display of the history, but
instead only symbolizes that the four basic states (Old, New, Deleted, Modi-
fied) do of course exist for all data. And not only in working layers.
Nonetheless, we would like to point out here that there are in fact five states
that can be shown in Comos, since deleted objects can be sub-divided once
again into two groups.
• “Hard deleted“
The objects are physically deleted and have actually been completely
removed.
• “Soft deleted“
These objects are only marked as “deleted” and are removed from the
Navigator. However, the data still exists physically.
It is displayed as follows:
Hard deleted Soft deleted
See SECTION 4.2.2.3: DELETING INFORMATION for an exact definition.
4.2.2 Basic example: released area and a working layer
4.2.2.1 Definitions
Superordinate, preceding: the working layer was there “first” and passes on
its information to the following working layers.
Subordinate, following: the working layer takes over (“inherits”) the informa-
tion from the preceding working layers.
Equal priority, parallel: the working layers have a common predecessor.

Working Layers / Project History Functional principle of working layers
4.2.2.2 Adding information
Creating a new working layer

When you create a new working layer, it is initially blank from a technical
point of view. All the objects are in the released area and are simply inherited
by the working layer.
But naturally the user does not see a blank Navigator when in the working
layer, even though the working layer is blank, technically speaking. This is
displayed to the user in such a way that all the inherited data, or in other
words, all the objects from the released area, initially exists in the working
layer in the form of “unmodified objects”:
Working layer 1
Released Area
New objects in the released area

If new objects are created in the released area, the working layers take these
over in the form of unmodified objects. The illustration above would look just
the same up to now and would only contain more objects that had been inher-
ited by the working layer.
Changing objects in the working layer

If an object in the working layer is modified, the inheritance mechanism is
broken:
Working layer 1
Released Area
Only now is a physical copy of the object actually created. This difference
between objects that are only displayed (inherited) and objects that actually
exist in the working layer in the form of a copy must be taken into consider-
ation, primarily when copying or exporting (working layers).

Modifying objects in the released area

The effect of this action differs according on whether or not the object in the
following working layer was modified. As was stated above, any modification
breaks the inheritance mechanism.
• Object was modified in the working layer: the modification from the
released area is not transported into the working layer, since the inheritance
mechanism had been broken. This results in a collision, see SECTION 4.2.2.3.5:
COLLISIONS.
• Object is not modified in the working layer: the working layer takes over
(inherits) the modified object in the released area.
New objects in the working layer

Logically enough, objects in the working layer are independent of the objects
in the released working area.
4.2.2.3 Deleting information
4.2.2.3.1 Technical details of “soft deletion”

When using working layers in Comos, the handling of deleted objects
changes: in addition to the physical deletion of objects, there is also the option
for logical deletion (“soft deleted”).
Definition of “soft deleted”:
• The deleted objects are not usable but still exist physically.
• Deleted objects are not visible in the Navigator when the default settings are
used.
• Deleted objects remain in red text in the “Working layer display” and
“History display” displays, but remain visible in all interfaces (Navigator,
queries, etc.). (The colours can also be changed as the user wishes.)
The objects also remain as “soft deleted” objects if a working layer is released
into a working layer. The only alternative is when a working layer is released
into the released area (Level 0 (zero)).
There are two ways that “soft deleted” objects can arise:
• When working with working layers
See SECTION 4.2.2.3.2: DELETING OBJECTS IN THE WORKING LAYER (HARD DELETION /
SOFT DELETION).

• When working with the project history

See SECTION 4.5.4: HISTORY.
The objects themselves are technically still the same: they are given the “soft
deleted” flag. But the way they are handled differs.
“Soft deleted“ in working layers

Inherited objects are “soft deleted” when they are deleted.
If objects are deleted while working with working layers, this automatically
provides the basis for comparison: The object exists in the preceding working
layer but it has been deleted in the subordinate working layer.
If you wish to monitor the “soft deleted” objects, all you have to do is to
switch on display of working levels in the Navigator. There you are also given
a hierarchical display: The objects know when one of the child objects has
been modified (and deletion is also a form of modification) and indicate this.
You thus do not need to go through all the objects individually to find the
deleted objects, but instead you can go down through specific branches to find
the ones that have been marked as “Modified”.
Soft deletion in the project history

If objects have been “soft deleted” in the subordinate working layer and if the
project history function has been activated, then all the “soft deleted” objects
are accepted in the released area as “soft deleted”.
If the project history function had been deactivated, then all “soft deleted”
objects in the released area are deleted.
Thus “soft deleted” objects in the released area can also be created as a result
of the above release mechanism. If objects in the released area are deleted,
then they are always “hard deleted”.
There is no working layer display in the released area, since there is no longer
a preceding working layer. You have already arrived at the root.
A history display in a working layer is only available if this working layer has
entries in the object history. If this is the case, a comparison point in time can
be set. This comparison point in time determines which entries of the object
history are displayed in the history display in color – this reducing the number
of entries.

If one of the objects beneath a node is displayed in color, the complete path
(up to the first level of the project hierarchy) is also displayed in color. In the
release database these nodes are displayed in a light blue color. The hierarchi-
cal information is computed from the database. If there are too many object
histories for one working layer, it will take more time to compute the path.
4.2.2.3.2 Deleting objects in the working layer (hard deletion / soft dele-
tion)
Objects that have been deleted in the working layer can be divided into two
groups:
• The deleted object was created in the working layer. In this case the object
is physically deleted (“hard deleted”).
Please note: The object is also hard deleted in all the succeeding
(subordinate) working layers that it had been checked into.
• The deleted object originally came from the released area. In that case the
object was checked in as a result of the deletion (if that had not been done
already):
Working layer 1
X
Released Area
This might at first sight seem contradictory, but it is necessary from a techni-
cal point of view. It is precisely the objects of the released area that should not
be edited in the working layer. Consequently in all cases the object must be
separated initially from the released data, meaning that it is to be checked in.
The object that had been checked in is now given the “deleted” property and
is no longer displayed. An object of this type is also called “soft deleted”.
An object can only take the “soft deleted” property when it is in a working
layer. A hard deletion is always done if objects are deleted in the released
area.
If, however, a working layer is released into the released area, then any
objects with the “soft deleted” property can be transferred to the released area.
In other words: While the released area can contain “soft deleted” objects,
these objects must always originate from subordinate working layers.

Exception when working with working layers:

If the | RESTORE command is executed, the objects that were previously modi-
fied are physically deleted. See next chapter.
4.2.2.3.3 Restore
If the working layers display is activated, the | RESTORE command is offered
in the Navigator when an object that had been checked in is selected. It is only
available for WO administrators.
This object and all the objects underneath it are deleted (“hard deleted”) and
the corresponding information is removed from the preceding working layer.
This also applies to the project root (the blue globe): in this case all the objects
in the Navigator are deleted and are removed again from the preceding work-
ing layer.
Exceptions:
• In the Layer-independent functions, P. 4-11 section a number of areas were named
that work completely independently from the working layers. These areas
are of course not affected by the | RESTORE command (because they cannot
be modified in the working layer).
• In addition, there are the following areas that can be modified within a
working layer but are not affected by a | RESTORE command:
– systems of units,
– document types
4.2.2.3.4 Release
A release can also be regarded as a reduction in the amount of information.
Deletion of the working layer on release

The information that certain objects or changes to objects originate from this
working layer is lost. (Optionally, a working layer can remain unchangeable
on release.)
Release into the released area

In principle, objects remain “soft deleted“ even when a working layer is
released into a released area. However, when it is released into a released area,
an object can be toggled from “soft deleted” to “hard deleted” and thus finally
physically deleted.
Whether or not that happens depends on the “History management ” project
option:

• Option switched on: The objects remain “soft deleted” and thus exist
physically.
• Option switched off: “Soft deleted” is toggled to “Hard deleted”. The
objects are physically deleted.
See SECTION 4.5.4: HISTORY.
4.2.2.3.5 Collisions
Information can be lost as a result of collisions.
Definition of a collision: An object that had been checked into the working
layer was edited again in the preceding working layer. In other words, the
object that had been checked into the working layer is no longer based on the
most up to date information in the preceding working layer.
There are only two possible ways to resolve a collision:
• Restore to the object
In this case the information of the object is lost.
• Release of the working layer
In this case the information of the preceding object is lost.
Collisions are displayed at the object level and not at the level of the working
layer. If an object was not checked into a working layer, then no collisions
will be shown if the object is modified in the preceding working layer.
Instead, the modified object is displayed. The collision is displayed in the
working layer into which the object was checked in the first time.
Special case: Due to the hierarchical structure of working layers, it is possible
for an object that had been checked into a preceding working layer to be
edited again, or in other words, checked in again. In that case the collision is
only displayed for the first object that had been checked in.
4.2.2.3.6 Delete in the released area / “UndoDelete”

If an object is hard deleted in the released area, then this object is also hard
deleted in all the other working layers that it had been checked in to, indepen-
dent of the settings of the project history. Exception: The object is under his-
tory monitoring. The object will then also be “hard deleted“ in all worling
layers in which it was checked in.
Recommendation: For that reason never perform a hard deletion in the
released area.

Restoring deleted objects (“UndoDelete”)

Independently of the Comos “soft deleted” function, there is this one last
option to access deleted objects: namely, by working directly at the database
level.
Comos typically does not delete objects from the database at once but simply
sets a delete-flag. Under certain circumstances it is possible to restore deleted
objects by deleting the delete-flag at the database level. There is a special tool
(a special object query) in Comos for this for administrators. If the delete-flag
is thus deleted, we talk in terms of an “UndoDelete”.
However, this is a very uncertain method, since it depends completely on the
circumstances that pertained when the objects with the delete-flag were phys-
ically deleted from the database. Under no circumstances can you rely on still
being able to rescue Comos objects that had been “hard deleted” by working
at the database level and deleting the delete-flag.
Please note: “UndoDelete” otherwise only functions in the released area, not
in the working layers. An example for clarification:
• An object is in the released area and was checked into a working layer.
• This object was hard deleted in the released area. The object is also deleted
in all the working layers. The object that had been checked in and all the
information that it contained are lost.
• An UndoDelete was done in the released area. The object is restored in the
released area, but it is still missing in the working layer. The object that had
been checked in originally is still lost.
In other words: The UndoDelete object query does not display any objects
that had been deleted in the working layers, and consequently it also cannot
restore them.
4.2.3 Working with multiple working layers
In this case there are the same relationships between Working_layer 1 and
Working_layer 2 as those already introduced above for the “Released area ->
Working_layer 1” case.

Scope of action of working layers Working Layers / Project History
From a technical point of view, the new working layer is initially blank and
inherits the objects, which it displays as “unmodified objects”. But now there
is in addition the case in which this inheriting can “reach through” multiple
working layers:
Working layer 2
Working layer 1
Released Area
Starting out on this basis, objects are then once again modified, deleted or cre-
ated in Working layer 2.
4.3 Scope of action of working layers

Planning objects
Fundamentally speaking, all planning objects are covered by the working lay-
ers. However, individual objects can also be excluded from the working lay-
ers, see Layer-independent functions, P. 4-11.
Base project
You can create and use working layers in the base project. In this way you can
elegantly further develop the base project. However, at the present time plan-
ning projects can still only use as the base project the released stock of data of
the base project. It is not possible to insert a working layer within the base
project into a planning project as the base project.
Interactive Reports
Interactive Reports support working layers. In this case all the changes from
the preceding working layers are taken over each time that a report is opened.
When a working layer is released, all the changes in the working layer are
transferred into the preceding working layer. If the working layer display has
been activated, the objects that had been placed on the report are shown in the
appropriate colors (depending on the Comos module).
In addition, you can also use the following project option:

Working Layers / Project History Scope of action of working layers
• Project option ShowSoftDeleted

If it is set to True, deleted report items are displayed in the working layers.
The default is False.
Imported third party documents

Office documents:
When the document is closed, it is checked if the document has changed in
comparison to the preceding working layer. If it has, the document is checked
into the working layer.
However, the inheritance mechanism is broken off when files are copied.
Thus if something is changed in this document in a preceding working layer,
the document that had been “checked in” into this working layer is not
affected. Thus there are no collision messages, etc.
Other documents:
The document is checked into the working layer when it is opened.
Layer-independent functions
There are functions that are completely independent of the working layers.
Changes to these areas therefore take effect at once in all the working layers.
• Project properties
• User administration
• Run cases
• Languages
• Time stamps
• Individual objects
In very special cases objects, and also planning objects, are generally
excluded from the working layers. Important examples:
– System project, @PROPAR: That is the variable part of the project
properties. Since the project properties are layer-independent overall, this
also has to apply for objects as well.
– Device with name “@Project” and class “Document group” (and all the
objects underneath it). This planning object is part of DQM when you
work with the redundant document administration.
– Device with name “@Groups” (and all objects underneath it). This
planning object is part of the user administration. Since the user
administration is layer-independent overall, this also has to apply for
these objects as well.

Scope of action of working layers Working Layers / Project History
• Creating report templates

Report templates (*.crp) have a hierarchical structure. A report template can
use a further template, etc. This calling up of Master Reports and sub reports
is layer-independent.
• Calling up report templates
In Comos each report must possess a template. This call is layer-
independent. It is therefore not necessary to call up different templates in
different working layers.
• External files
In Comos it is also possible to refer or link to external documents. The
document still remains outside Comos and a hyperlink to the file is created
within the Navigator. In this case the document can still be started within
Comos, but it can equally well be edited outside Comos as well. In this case
that already rules out working with working layers on organizational
grounds.
Tools
• Information list
Shows everything from all working layers. This also means that if a
reference is made to objects that are in other working layers, then these are
“not found”, so to speak, and are shown with a black cross.
• Support: Project utility programs
The global test relates to all objects that are “visible” in a working layer, and
thus includes objects that had been taken from preceding working layers. It
is not possible to test only those objects that had been modified in the
working layer.
• Database reconciliation
Relates to the database, and thus the released area and all the working layers
of all projects.
• All other tools
Relate to the working layer. This also applies to the project directory
matching.

Working Layers / Project History Managing working layers
4.4 Managing working layers
4.4.1 Database version
Support: Version tab, [reconcile database version]

The database version was updated to a newer one. If you wish to make use of
working layers, the administrator must first of all upgrade to the newer data-
base version. Please note: If the database version has been updated, older
Comos installations (before Comos 8.02) can no longer access the database.
4.4.2 Controlling the properties of working layers (@WOLevels)
Levels of working layers

Working layers possess base objects. However, not every working layer is
given its own base object, but instead the working layers are divided into lev-
els and each level of a working layer is given a base object.
Level 0
A “root”, which is called the original project or also the “released area“ here,
takes priority. This central point is called Level 0 (zero).
Levels 1 to N
All the directly subordinate (succeeding) working layers belong to Level 1, all
the layers directly after Level 1 belong to Level 2, etc.
Example:
Level 0 Level 1
S1 Level 2
S11
S2
S22
S23
S24
All the base objects for the levels of the working layer are collected in the
@WOLevels branch. An example for @WOLevels can be created by updating
the database (see SECTION 49.3: DATABASE ADJUSTMENT):

Managing working layers Working Layers / Project History
@System |@D |@WOLevels

|--- 0 Unit
|--- 1 Valid planning status
|--- 2 Conversion
|--- 3 Private
This example thus works in terms of four levels of working layers, but it could
equally well be more as well. In the above examples the base object belongs
to “1 Valid planning status”, or to the first subsequent level of the
project. The number must be used as the name, and the description, which in
this case is Valid planning status, can be any that you wish.
Missing base objects for levels of working layers

If a working layer is created on a level for which there is no object underneath
@WOLevels, then @WOLevels itself is evaluated.
If @WOLevels is deleted, the following default setting is used:

Level locked: No
Can only be managed with the project administration right: No
Delete working layer on release: No.
Display level in working layer selection: Yes.
Control options
• Text masks
The text masks of the base objects control the names of the new working
layers.
• Attributes for access administration
Controls access to the working layers, see SECTION 4.4.4.1: GLOBAL CONTROL OF
LEVELS OF WORKING LAYERS.
• Attributes for list display

In addition, @WOLevels has the effect that the “List ” tab appears during
project selection. Without @WOLevels there would only be the tree display
of the working layers.
If an attribute was created for the base object that is responsible for the
working layer level, this list can be made visible as new columns. For
example, you can filter or sort the list by means of these new columns. See
the next section.

4.4.3 Controlling the display of the list for layer selection
In the basic state the working layers are displayed in the form of a tree struc-
ture that the user can select from. If the @WOLevels base object exists, then the
List tab appears in the working layer selection as well.
Specification tabs and attributes can be created in the usual way in the base
objects of the working layers. These attributes are made available to the user
on the List tab and can be made visible in the form of new columns. For exam-
ple, you can filter or sort the list by means of these new columns.
If the user has changed the display of the List tab in this way, he can also save
his own settings. The information is stored in the following base object:
@System |@Profiles... |WOList
The administrator can also create a default for the display. This default is cre-
ated in exactly the same way as a user creates his own personal form of dis-
play. See SECTION 4.5.1.3: “LIST” TAB.
4.4.4 Rights administration for working layers
4.4.4.1 Global control of levels of working layers

A @WOLevels base object can be created in the base data. This base object (or
to be more precise: the base objects underneath it) control the typing of the
working layers. In other words: if one of the following attributes is activated
in one of the sub-objects of @WOLevels, this applies for all the working layers
of this level.
• SYS | Locked “Level locked”
The rights may have been prepared at the level, but even so nobody can
work in this level. Example: in the original stock of data (the “released stock
of data”) all the rights for the workers had been prepared and are inherited
by the working layers. The original stock of data is then locked and so
protected against accidental changes.
• SYS | Project Management “Can only be administered with Project
Management right”
If this option has been activated, then you still need in addition the Project
management right to manage working layers. See SECTION 4.4.5: MANAGING
WORKING LAYERS regarding the management of working layers.
• SYS | DeleteOverlay “Delete working layer by release”

Self-explanatory.

• SYS | ShowInProjectList “Show layer in working layer selection”

Self-explanatory. If there is only one permitted working layer in addition to
the released area, then no combo box is displayed but instead this working
layer is offered directly.
4.4.4.2 Allocation of rights in layer management

Layer management comprises the commands | NEW, | DELETE, | IMPORT,
| EXPORT, | RELEASE and | PROPERTIES, see SECTION 4.4.5: MANAGING WORKING LAY-
ERS.
These management functions cannot be directly granted or revoked for a

worker. Nonetheless, working layers can be given object rights. Do this by
opening the rights administration for a user and then Object rights . Create a
new right. Open the Working layers/History management dialog window
in parallel. Drag a working layer object from the Working layers tab into the
Object field of the new right.
Now you can grant or revoke object rights in the same way as for any other
object.
For example, if you wish to create a new working layer on a working layer,
you need the “Read ”, “Create ” and “Write ” rights.
The “normal” user only requires the “Read ” right in the layer management
so as to be able to see and open a working layer in the selection. All further
rights are only granted in the working layer itself, see the next section.
Working within a working layer

The rights within a working layer are managed in the usual way. An object is
selected within the Navigator and rights administration is called up. The
worker is given the relevant rights to this object. These rights are inherited
within the working layers.
4.4.5 Managing working layers
Activation
Comos menu | EXTRA | WORKING LAYERS/HISTORY | MANAGEMENT
“Working layers” tab

• Release
Releases this working layer. The changes are written to the immediately
preceding working layer. It depends on the DeleteOverlay attribute as to

whether or not the released working layer is deleted. Fundamentally

speaking, a working layer cannot be released if it possesses further
subordinate working layers.
Special point: If a release is made in the original project (the “released
area”), the history management is made available as well. In this case a
small “History entry ” window opens. See SECTION 4.5.4: HISTORY.
• Export
Exports the entire working layer into an Access database and creates (or
overwrites), as applicable folders with the documents. Please note: only
information that had been checked in is transported, and not superimposed
information from preceding working layers.
Please note: Documents are also stored physically outside Comos, see
SECTION 4.4.6: MANAGING DOCUMENTS IN WORKING LAYERS.
• Import
Automatically creates a new working layer and imports the Access database
there. The folder with the documents is also included, of course.
Multiple import:
In principle, each import operation creates a new working layer in the target.
Thus two working layers would be created at the target if a working layer
was imported twice. The second import “does not overwrite itself”, as you
might assume.
Exception: If a working layer is imported and then released, the working
layer no longer exists at the target, but the objects still do (in the preceding
working layer). If the working layer is imported again in this case, all the
objects that were not modified (time stamp not changed) are not imported
again! In this case the new working layer created in the target by the second
import operation would have significantly fewer objects.
Detecting collisions:
If a working layer is exported and reimported later, collision detection then
shows whether an object that is being reimported had been modified in the
interim in the preceding working layer.
• Delete
Deletes a working layer.
• New , Property
Creates or modifies a new working layer or deletes it. The properties are:
Name : Any, but it must be unique.
Description : Any.

ID: An automatically allocated identification number. Only even numbers

are allocated, the odd numbers are always reserved for internal system
purposes. The range of numbers goes up to 20,000, meaning that 10,000
working layers can be created per Comos project.
The number of layer levels is not restricted, except that you are not
permitted to exceed a total number of 10,000 working layers.
Specification tabs: working layers are controlled via the sub-objects of
@WOLevels. If Specification tabs had been created there, these are also
shown here in the properties.
4.4.6 Managing documents in working layers
Documents can possess external files that are stored outside the Comos data-
base. When a working layer is created, the external files are copied as well as
required. To this end there is an “Overlays” directory with sub-directories.
Example:
Comos\Test.mdb
Comos\Test\<Project name>\Overlays\WO<sequential number>
The sub-directory is copied again when exporting a working layer in a
“Test2” database:
Comos\Test2.mdb
Comos\Test2\<Project name>\Overlays\WO<sequential number>
See also SECTION 4.3: SCOPE OF ACTION OF WORKING LAYERS.
4.4.7 WO-Administrator
To release, delete, create, import etc. working layers you need specific rights.
These rights are sometimes also called “WO-Administrator“. As “WO-
Administrator you need to have the following object rights for the working
layer object in question:
• Write
• Delete
• Create
• Read completely
• plus all the rights of the @WOLevels base object that are controlled by
specifications:
Tab SYS , specification ProjectManagement .

Working Layers / Project History Using working layers
– Specification on:
Level can be administrated if you have
Meta right Project management or
Function rigth Project options .
– Specification off:
Level can be administrated if you have
Meta right Project management or
Function rigth Project options or
if you are the owner of the working layer (i.e. the one who created the
working layer).
4.5 Using working layers
4.5.1 Dialog window “Select working layer”
4.5.1.1 Activation
• When logging into a project with working layers
When logging in, the Select working layer dialog window is combined
with the project selection window. However, the Select working layer
dialog area only appears if a working layer already exists somewhere in this
project or if the base object @WOLevels exists.
Please note: if you are the administrator or if you possess the relevant rights
for layer management, then one of the expanded mouse menus is available
for your use, see SECTION 4.4.5: MANAGING WORKING LAYERS.
• Select the project root, | CHANGE WORKING LAYER context-sensitive mouse
menu.
4.5.1.2 “Overview” tab

Black: The user has read rights, as a minimum, for the working layer
Grey: The user is not allowed to open this working layer, but a permitted
working layer exists underneath it.
Not visible: All other working layers.
Select one of the working layers by double-clicking on it.

Using working layers Working Layers / Project History
4.5.1.3 “List” tab

In the List tab you can select a relevant level of working layers from the drop-
down menu.
Basically, level “0 Unit” is not shown in the “Select level ” field.
The display is based on a query and can be sorted and filtered.
Display additional
If list display of the working layers has been switched on through @WOLevels,
you can then change this list display individually: sorting, filtering, making
new columns visible, etc.
To do this, a Specification tab with attributes must first be created in a sub-
object of @WOLevels. In the next step you select the appropriate level in the
List tab. Then click on a column header in the list and select | NEW
| ATTRIBUTE... In the following dialog window you select one of the new attri-
butes that you had just created.
Save personal settings

You must save these user-specific settings to ensure that they are not lost:
right-click on a column header of the list, | SETTINGS | SAVE command. They
are then saved as base objects on the base object tab. See SECTION 1.6: PERSONAL
SETTINGS. The settings may only be saved in the system project and the corre-
sponding rights must of course be available.
4.5.2 Working in layers / working layer display
Working layer display

Mouse menu | WORKING LAYER DISPLAY of the Navigator.
Shows the changes in the working layer.
The display of the working layers can only be switched on when you are in a
working layer that has not been released.
The legend determines how the objects in the working layer display are
shown. For individual objects there is in addition a considerably enhanced
form of status display in the Object status dialog window, see SECTION 4.5.5:
DIALOG WINDOW “OBJECT STATUS”.
Deleted objects “Soft deleted”

See SECTION 4.2.2.3.2: DELETING OBJECTS IN THE WORKING LAYER (HARD DELETION / SOFT
DELETION) for basic information on the topic of deleted objects.

If working layers are used in Comos, the way in which deleted objects are
handled changes: objects are no longer deleted physically but only logically
(“soft deleted”):
• The deleted objects cannot be used but still exist physically.
• Deleted objects are not visible in the default display mode of the Navigator.
• Deleted objects retain their red text in the “Working layer display” and
“History display” displays but remain visible in all interfaces (Navigator,
queries, etc.). (The colors can also be changed by the user as desired.)
Exceptions:
If the | RESTORE command is used, then previously modified objects are phys-
ically deleted.
The objects also remain soft deleted when a working layer is released into
another working layer. The only alternative is when a working layer is
released into the released area (Level 0 (zero)).
Collisions
Definition of a collision: An object that had been checked into the working
layer was edited again in the preceding working layer. In other words, the
object that had been checked into the working layer is no longer based on the
most up to date information in the preceding working layer.
See SECTION 4.2.2.3.5: COLLISIONS.
Restore
The | RESTORE command is offered in the Navigator when an object that had
been checked in is selected.
The | RESTORE command is offered in the Standard tables dialog window.
See SECTION 4.2.2.3.3: RESTORE.
4.5.3 Legend
To set the colors for the working layers and for histories perform a right-click
in the Navigator and select the | LEGEND command. For more information go
to SECTION 10: DISPLAY IN THE NAVIGATOR.
This is done by clicking on a color box next to an entry. The Colors dialog
window opens.
Colors that are saved like that are saved as personal settings on the base object
tab. For more information on personal settings go to SECTION 1.6.1: PROFILES.

4.5.4 History
4.5.4.1 Overview
Area affected
Aim of the project history: Project-oriented tracking of the release of all
Comos objects.
The project history provides an overview of the changes made within the
working layers. The history can thus only be used if working layers have also
been used.
The history consists of the following areas:
• Automatic history entries on release into the released are:
History entries permanently store the various editing states of the data, but
only if it concerns validated data. According to the working layer model in
Comos, there are therefore only history entries for Level 0 (zero), this being
the released area. The released area includes by definition the validated data,
while the subsequent working layers can only include data that is still
incomplete or has not been checked yet.
• Automatically running object history:
Creation of entries in the object histories also while work is being carried
out.
This is controlled by means of an object property that is transferred to the
elements in the planning area. The Object Debugger is used to this end.
Enter the following statement into its script window:
Object.SetObjectOverlayBehaviour 3, TRUE
The property applies for the object and all subordinated objects solely for
the current layer (respectively the released area). If the object is to be
monitored in another layer, the monitoring property must likewise be
activated there at the object.
Again, the backup copy only contains own data. Information that is only
inherited is not saved in the copy. This applies both to inherited attribute
values and to information that is taken over by means of pointers.
A history data record is created by activating the monitoring. In the interface
of this data record, the “History monitoring” column has the entry
“activated”. Once the monitoring has been activated, all changes made to
the existing data lead to the production of history data records (backup of
the data before the change). It is possibly to precisely track from the history
within which period a stock of data was valid and who had edited it.

An entry in the running object history is triggered by: each change to an

object. This can be done via the interface [Save], [Apply] or by a script,
import, etc.
• History display
A history display in a working layer is only available if this working layer
has entries in the object history. If this is the case, a comparison point in time
can be set. This comparison point in time determines which entries of the
object history are displayed in the history display in color – thus reducing
the number of entries.
If one of the objects beneath a node is displayed in color, the complete path
(up to the first level of the project hierarchy) is also displayed in color. In
the release database these nodes are displayed in a light blue color. The
hierarchical information is computed from the database. If there are too
many object histories for one working layer, it will take more time to
compute the path.
Display
Open the object history: context-sensitive mouse menu, command “Object
history“:
The above example contains the released area and a working layer. The acti-
vation point in time of the history monitoring can be found at any time.
Buttons (from left to right):
• Layer limiting
[ALL UNDERLYING LAYERS]
Current layer plus all preceding layers (released area first, etc.)
[CURRENT LAYER]
If there is no entry in the object history of this object in one of the dis-
played layers, then no entry is displayed for this layer, not even the cur-
rent status.

• Properties limiting
[ONLY DIFFERENT VALUES]
Only changed properties are to be shown in the columns (description
here)
[ALL VALUES]
Show changed and unchanged columns
Otherwise, the dialog window uses a query and functions in the usual way.
Meaning of the entries in At/From , To
It is possible to determine from the At/From and To columns when an editing
status of the object was applicable.
In principle, the From column can never be blank. There is always a point in
time at which the object was created, modified or taken into the history man-
agement.
The To column is blank in the following cases:
• If history monitoring has been activated.
• If history monitoring has been deactivated (this case is not given in the
above illustration).
• In the last entry of an object for a layer. This is the currently applicable
status.
Please note: The object history of an object does not automatically reveal
which specification values of an object have changed. To find out about these
changes, open the object history of the specification object: Either open its
mouse menu in the navigator, or perform a right-click on the label of the spec-
ification in the properties window of the planning object (not on the entry
field!) and select the command | OBJECT HISTORY.
4.5.4.2 Preparations: base data, project settings
Project property history

Properties of the project, Options tab: History management option.
Effect:
• The history entries are activated. If the “History management” project
option had been activated, each release into the released area automatically
and unavoidably now creates a history entry.

• In the Properties window of the planning objects the history of the value is
made available for the attributes in the mouse menu.
• Deleted objects are not deleted physically but only logically. See Deleted
objects “Soft deleted”, P. 4-20.
4.5.4.3 History entries for working layers
Create history entry

Brings about a release of a working layer in the original project (“released
area“), and then a backup copy of the modified or deleted objects is created.
A small “History entry ” dialog then appears:
The time stamp appears as the default text. However, any other text can be
input, since the time stamp is written to the history entry in any case. This text
is written to the backup copy together with the time stamp.
The backup copy contains all own data, This means that information that was
only inherited is not saved in the backup copy. This applies both to inherited
attribute values and to information that had been accepted via pointers.
There is an overview of all the history entries, and thus of all the backup cop-
ies, in the “Working layers/History management ” dialog window.
History entries can also be used in the history display.

4.5.4.4 History display
Activation
Comos menu | EXTRA | WORKING LAYERS/ HISTORY | MANAGEMENT
“History” tab
This tab controls the history display in the Navigator. The | HISTORY DISPLAY
mouse menu is blocked as long as a comparison point in time has not been set.
Once a comparison point in time has been set, all the objects are given colors
in accordance with the Not changed / Changed / New / Deleted scheme.
Changes since index :
Klick on an index above.
Changes since :
Any desired object can be dragged into this field. The time stamp of this
object is evaluated and the date of the last change is taken from it for use. It is
also possible to drag an object into this field from the list of history entries. In
this case the current state of the working layers is compared against the
backup copy of the history entry.
Fundamentally speaking, however, the history display can also be used with-
out history entries. In that case an object of the Navigator is used. The objects
are then given the appropriate status colors by comparison with the point in
time at which this object had been created.
See SECTION 4.4.5: MANAGING WORKING LAYERS.

4.5.4.5 History of the attributes

Display the object history for the specification values of devices:
Right-click on the label of the specification in the properties window of the
device (do not click in the input field!) and use the | HISTORY command. See
Display, P. 4-23.
4.5.4.6 License administration / rights administration
FDA
This license allows history management for working layers. The FDA license
controls:
• |Extra |Working layers/Histories |Management
Project properties, Options tab, “History management” option.
4.5.5 Dialog window “Object status”
Activation
Comos menu | EXTRA | WORKING LAYERS/ HISTORY | OBJECT STATUS
Application
This dialog window displays all the important information for an individual
object with respect to working layers. When the dialog window is opened, the
object that was currently selected in the Navigator is evaluated. Another
object can be set for evaluation by using drag & drop.
Working layer overview , History : these two fields display exactly those
object colors that would appear in the Navigator if the corresponding display
were to be activated.

Change in ...: the following objects count as “allocated”: connectors, attribu-

tes, symbols, extended objects.
Layer relevance : There are objects that are layer-independent, such as the
project . Objects of this type are not layer-relevant.
Release relevance : Objects can be explicitly excluded from a release. In
such a case the changes in this object are not written to the preceding working
layer when the working layer is released.
Collision ...: Collisions are always checked with respect to the preceding
object. However, the preceding object need not necessarily come from the
preceding working layer, as it can also “jump” layers if the object had not
been edited in these layers.
4.5.6 Importing/Exporting working layers
This documentation will soon be available. We appreciate your understand-

ing.

Project management The system project
5 Project management
5.1 The system project

The system information is stored in a project, the so-called system project.
The Comos system project includes all the components (interfaces, standards,
parameters, etc.), that must exist as a minimum to be able to meaningfully
work with a planning project.
You should not work within a system project in itself.
Exchange or transfer system project: see SECTION 3.5: COPY SYSTEM PROJECT.
5.2 Create or delete projects
Command: | FILE | PROJECT OPEN
The “open project” dialog window

On the mouse menus of the column headers:
|SAVE COLUMN The current column layout is stored in the Win-

LAYOUT dows NT profile of the user. The next time the pro-
gram is called up under the same user name, the
columns in Open project appear again with the
same layout and size as before.
| RESET COLUMN Individually saved columns are restored to the
LAYOUT default layout.
| DELETE COLUMN Removes the column by a right mouse-click. The
new layout can subsequently be saved in a user-
specific way.
If you right-click with the mouse in one of the column headers, you can sort
or filter the dialog window.
Open project
A database can include one or more projects, but only one project can be open
at any one time. Which projects you can see also depends on the rights allo-
cated to you.

Create or delete projects Project management
Select a project type from within the Open Project dialog window, then all
the projects of this type for which you have read rights as a minimum are dis-
played.
Mark with the cursor the project that you wish to open. Double-click on it or
press the [OK] button.
The opened project is displayed in the main window, the Navigator.
Create new project

• Select the project type in the Open Project dialog window by means of the
option buttons.
• Right-click in the Open Project window (not on a column header) and
select the menu item | NEW.
The Project properties dialog window opens, see also SECTION 5.5: THE PRO-
JECT PROPERTIES.
On the General tab, the drop-down field Type always has the Planning
project type as the default input. If necessary, you must change from here to
Base objects, etc.
Copy project
A project can be duplicated within the Open Project window with the mouse
commands | COPY and | PASTE. The user is asked whether the document revi-
sions should be copied?
Only with SQL Server: fine control when copying a project
If a project is to be copied in the Open Project window, a query is made as
to the priority of the action. Effect: more or fewer resources are allocated to
the copying process.
Delete project
This right is not coupled to the Administrator rights. Anyone may delete a
project as long as he or she possesses the DELETE right to this project.
The project rights are opened by clicking on the globe and pressing
<Ctrl><A>. See also SECTION 6.6: MANAGING RIGHTS: OBJECT MANAGEMENT.

Project management Import / Export of projects
5.3 Import / Export of projects
5.3.1 Export project
Projects can be exported to other databases. The following mouse context

menu is used in such a case:
• Open the Open project window with | OPEN PROJECT
• Right-click with the mouse on a project
• | EXPORT
The target database to which the project is to be exported can be selected in

the following dialog window:
Please check first whether you have the necessary rights for this operation for
both databases. When a project is exported, the user is queried as to whether
or not the users are to be exported as well.
The | EXPORT function should only be used for base object projects. The
| IMPORT function is more efficient for planning projects, see the next section.
5.3.2 Import project
This command is only applicable for planning projects.

Projects can be imported from one of the other databases. The following
mouse context menu is used:
• Open the Open project window with | FILE | OPEN PROJECT
• Right-click with the mouse on any project
• | IMPORT

Import / Export of projects Project management
The source database from which the project is to be imported can be selected
in the following dialog window:
Please check first whether you have the necessary rights for this operation for
both databases.
The project that is to be imported is selected in the second step and a new base
project is allocated:
When a project is imported, the user is queried as to whether or not the users
are to be imported as well.
5.3.3 Comparison of exporting and importing:
If an project is transferred from one database to another, all the objects must
be “grabbed.”
In addition, the base project must be reset. All the objects are likewise
“grabbed” when the base project is reset.

For that reason the | IMPORT function is more efficient for planning projects
than the | EXPORT function, since here the two steps of “Transfer” and “Reset
base project” can be done in one pass. The objects only need to be “grabbed”
once.
If the| EXPORT function is used, all the objects need to be “grabbed” twice,
since the two steps are separate here. The difference in time between | IMPORT
and | EXPORT can be very great, especially with big databases.
5.3.4 DBSync.exe
5.3.4.1 Purpose
The program “DBSync.exe ” is a DOS-based program working at the system
level that is used for the synchronization of Comos databases.
Call:
• Open a DOS window
• Base directory Comos \bin\
• DBSync.exe. [mandatory parameters]
In functional terms, DBSync is comparable to using a combination of
ExportDB and ImportDB . The combination of ExportDB and ImportDB is
safer and more efficient, nonetheless, ExportDB /ImportDB can only be used
if there is online access to both databases (for example, via a permanent line).
DBSync does not require online access of this type.
DBSync.exe may only be used by authorized administrators with
system experience. Incorrect use can lead to data inconsistency or
even a loss of data.
DBSync is not able to meaningfully synchronize documents. There
is a risk of a loss of data if DBSync is used on projects in which
there are planning documents. We there emphatically recommend
that DBSync should only be used for the synchronization of base projects.
Any use going beyond this is entirely at your own risk.
DBSync may only be used if the databases to be synchronized are not being
accessed online.

5.3.4.2 Synchronization sequence
5.3.4.2.1 Step 1: Create synchronous databases with ExportDB.

DBSync is used exclusively for the matching of synchronous databases.
The target database must have been created beforehand by means of
ExportDB .
The ExportDB tool is explained in the operation reference manual. At this
point we can only emphasize once again that an export operation using
ExportDB should only be carried out by authorized administrators with suit-
able system experience. Please note that you have to keep a list of “database
identifiers” by yourself. In particular, you must allocate a new DB identifier
for each synchronized database. Thus if you export a database on a test basis,
you have used up a DB identifier.
Each target database must have its own (unique) DB identifier. If you are
working in a star structure (one source, multiple target databases), then each
database must nonetheless possess its own DB identifier.
5.3.4.2.2 Step 2: modify DBSync.ini

DBSync requires an ini file. You can likewise find a template for this ini file
in the \bin directory. This template is not functional and you have to modify
the ini file.
All the details required for the synchronization are taken from DBSync.ini.
The program DBSync accesses this ini file during each synchronization, both
during the working step for the source and the working step for the target. In
other words: you require the same DBSync.ini both at the source and at the
target. Simply copy DBSync.ini and send it to the other location.
Each DBSync.ini can work with exactly one source and one target database
respectively. If you wish to synchronize several target databases (for example,
because you are working in a star structure), you will then also require several
DBSync.ini files.
We recommend that you create a directory of its own for each target database
and then place the relevant DBSync.ini in this directory.
Structure of DBSync.ini
SOURCEMailAdr = "[email protected]"
TARGETMailAdr = "[email protected]"
SOURCE_DB = "C:\Ccc_Test\Step2\Source\ComosPT.mdb"
SOURCE_ID = "A"
TARGET_DB = "C:\Ccc_Test\Step2\Target\ComosPT.mdb"
TARGET_ID = "B"

USER = "@SETUP"
ZIP = ""
[Data]
PROJECT = "A0QHWDIFM8"
PROJECT = "A17VG71WMB"
$
[Messages]
SUBJECT = "Synchronize DB"
LINE1 = "Hello Mr. User"
LINE2 = "please synchronize our databases"
Line 1, line 2: Mail address of source and target. Please note: Do not confuse
the source and the target at the various locations! You might think that the
location that is the source from one point of view is the target from the point
of view of the neighboring location. But it is not so, the source is always the
location at which the synchronization is begun.
Line 2: If this involves an Access database, this line includes the source data-
base with full pathing details.
The following entries apply for other database connections (to be set in the
apostrophe area in DBSync.ini):
ORA Oracle default setting

ORA_1 Oracle instance 1
ORA_2 Oracle instance 2
SQL SQL Server default setting
SQL_1 SQL Server instance 1
SQL_2 SQL Server instance 2
Line 3: DB identifier of the source database

Line 4: If this involves an Access database, this line includes the target data-
base with full pathing details.
The following entries apply for other database connections as described under
line 2 above.
Line 5: DB identifier of the target database.
Line 6: [Optional] Drive letter for the temporary files.
This drive letter can be created by mapping to a specific directory.

Line 7: User name. This user must likewise possess administrator rights
within the database.
Line 8 ff: Projects to be synchronized.
In each line there is the SystemUID of the project to be synchronized or
exported, as applicable. A new line must be used for each project (“Return”).
The area in which the projects are located is terminated by a ”$” (without
apostrophes in DBSync.ini).
Following line: Header text of the mail
Following lines: In the following lines is the text of the mail.
Please note: The order of the lines is not important, but instead the relevant
keywords at the beginning of the line are important.
5.3.4.2.3 Step 3: Export of the original Comos database (“source”)

DBSync.exe 1
Parameter “1” = Export
An export with synchronization is done from the source database listed in the
ini file.
A “working copy” of the Comos database is created. This working copy is
always an Access database, regardless of what type the original Comos data-
base was (Oracle, SQL Server, etc.).
The name of the working copy is made up of the DB identifiers from the
source and the target, e.g. “AB.mdb”, (A = DB identifier source, B = DB iden-
tifier target). The DB identifiers are taken from the ini file.
This working copy may not be opened with Comos! New objects
would be created by the opening (e.g. “User”) and this would pro-
duce inconsistencies.
Technical background: The working copy only contains the changes from the
source database to the target database. This means that, among other things,
there are only individual objects (CDevice, Device, etc.) without a project in
the working copy database. As a rule, the working copy database contains no
projects at all.
Changes in the source

The original Comos database is also changed during the export
operation!

The “stamp” is then set in the original Comos database, meaning that the DB
identifier of the target database is entered in the “SYNC_FIELD” column as
applicable. This stamp provides the information that this data record has been
matched with a target database.
Please note: Technically speaking, no matching has taken place yet
at this time. The matching is broken down into two steps for techni-
cal reasons, and the completed matching has already been entered in
the source database before the second step - this being the actual matching -
has actually taken place. The working copy (the Access database that was cre-
ated) must be used on the target side as well for synchronization, otherwise
there is a risk of losing data.
Do not confuse the order of the working copies! If you call up DBSync several
times one after another and thus also create multiple working copies, then the
working copies must be read into the target in the exact order in which they
had been created.
If DBSync is called up several times one after another, and thus several dif-
ferent target databases are to be synchronized, then the relevant DB identifier
is inserted. If there is the text “XBD” in a data record in the “SYNC_FIELD”
field in the source database, then the data record is first matched with a target
called “X”, then with target database “B” and finally with target “D”.
Each change in the data record in the source database means that the field is
deleted (reset).
Further action
Optional: The working copy is packed in the next step.
The working copy is then sent as mail to the target side. The mail address is
taken from the ini file.
5.3.4.2.4 Step 4: Import with retrospective matching

DBSync.exe 2
Parameter “2” = Import with retrospective matching
In the target database, the file (e.g. “AB.mdb” or “AB.zip”) must be in the
same directory as that in which the program DBSync is located. The working
copy is automatically unpacked after the program is called up.
The target database stipulated in the ini file is synchronized with the working
copy. The table entries of the target database are stamped when doing this,
meaning that the DB identifier of the source database is entered in the
“SYNC_FIELD” column as applicable.

New working copy for the retrospective matching

A new working copy is then generated from the target database. The name is
again made up from the DB identifiers, but this time the letters are reversed,
producing, for example, “BA.mdb” when the first working copy was called
“AB.mdb”.
The table entries of the target database are stamped.
Please note: Do not mix up the terms “source database” and “target
database”! Even when as in this case the transfer is made “in the
other direction”, the source and target are still entered in DBSync.ini as
described above in working step 1. Regard the terms SOURCE_DB and
TARGET_DB as proper names.
Further action
The Access database is packed (optional) and sent as mail to the source data-
base side.
The first working copy is deleted.
5.3.4.2.5 Step 5: Retrospective matching

DBSync.exe 3
Parameter “3” = Retrospective matching
On the source database side, the packed file (e.g. “BA.zip”) must be in the
same directory as where program DBSync.exe is located. The working copy
is automatically unpacked after the program is called up.
Ensure that you use the correct copy of DBSync.ini if you are working with
more than two synchronized databases.
The source database is synchronized with the second working copy from the
target database.
Further action
The second working copy is deleted.
5.3.4.2.6 Alternative: Import without retrospective matching

DBSync.exe 4
Parameter “4” = Import without retrospective matching
After the program has been called up with parameter 1 and the working copy
has been sent to the target database side, the program can be called up on the
target database side with parameter 4 instead of Parameter 2.

On the target database side, the packed file (e.g. “BA.zip”) must be in the
same directory as where program DBSync.exe is located. The working copy
is automatically unpacked after the program is called up.
The target database stipulated in the ini file is synchronized with the working
copy. The table entries of the target database are stamped when doing this,
meaning that the DB identifier of the source database is entered in the
“SYNC_FIELD” column as applicable.
Further action
The working copy is deleted.
Differing from parameter 2, there is no retrospective matching of
target and source, and consequently no second working copy of the
target database is created.
This method is very useful if development work was done on the source data-
base side and only those changes need to be made available on the target data-
base side.
5.3.4.3 Error messages
“An error occurred when exporting the database.”

Call up program DBSync.exe again.
“An error occurred when synchronizing the databases.”

Call up program DBSync.exe again.
“An error occurred when copying the files.”

Manually pack the database that was created and which is in the directory of
the program DBSync.exe, and send it to the target side.
Do not call up the program again under any circumstances.
“An error occurred when packing the files.”

Manually pack the database that was copied and which is in the directory of
the drive letter (line 6 of the ini file) or the database that was created and
which is in the directory of the program DBSync.exe, and send it to the tar-
get side.
Do not call up the program again under any circumstances.

Joint access to projects Project management
“An error occurred when unpacking the files.”

Manually unpack the packed file that had been received by mail so that the
database and the associated directory are located in the same directory as that
in which the program is in.
“An error occurred when deleting the files.”

The database that was created and the directory were created in the same
directory as that in which the program is in.
Manually delete the database (e.g. AB.mdb) created by program DBSync and
the associated directory (e.g. AB).
“An error occurred when deleting the copied files.”

The database that was created and the directory were copied into the directory
of the drive letter (line 6 of the ini file) and packed from there.
This error message means that these copied files cannot be deleted.
Delete the files manually in this case.
5.4 Joint access to projects
5.4.1 Introduction
1. Interactive reports can only be opened once with write access.

2. Object operations are coordinated via the CVS, see SECTION 3.10: CVS
MONITOR.
3. Joint working on attributes is coordinated.

See SECTION 5.4.2: ATTRIBUTES FOR JOINT ACCESS.
5.4.2 Attributes for joint access
Please note: the mechanisms described below only apply to joint work on
attributes (specifications). If, for example, the Label is changed for an object
that has been opened jointly, the other user is not informed of this and no color
labelling is done either. This restriction prevents the user from being
“flooded” with information.
The Navigator is of course updated after every change.

Project management The project properties
Coordination by the information window

If several users are to work simultaneously on the attributes of an object, the
software automatically coordinates the work. The users are told through infor-
mation windows when a user has changed an attribute:
... The Specification was changed by ... (or a similar message appears)
If an object is saved whose attributes are likewise being edited by other users,
a message is also shown to this effect with the aid of an information window.
The message is similar to the message below:
... Object was saved on another station ...
Color scheme for attribute values with joint access

See SECTION 19.5: EDITING ATTRIBUTES IN A GROUP.
5.4.3 Project utility programs
Global test The project is checked for defective objects. Any erors
that are found appear in the error list that is opened auto-
matically. This list is displayed in the Object test dialog
window. Although the Object test dialog window is
only used for display, the Global Test and the
| ADMINISTRATOR | OBJECT TEST functions are not identi-
cal: the Global Test has the peculiarity that it also finds
objects that no longer have an “owner”. In the case of the
| OBJECT TEST function a search is made hierarchically
downwards from the project, with the result that objects
without owners are not found.
Delete “pick” Deletes the entries in the pick list of the Navigator.
lists
Project Changes the project directory. A new directory is not
directory selected, but the existing directory is renamed instead.
5.5 The project properties

Open:
• by right-clicking with the mouse on | PROPERTIES in the Open project
window, and then clicking the Options tab or

The project properties Project management
• by double-clicking with the left mouse button on the topmost hierarchical

level of project (i.e. the globe), and then clicking the Options tab.
5.5.1 The General tab
Name Project name with up to 80 characters.

Description 1-3 Three descriptive texts, each with up to 80 charac-
ters.
The name and the description in the first field appear in the Navigator. The
second and third descriptions are displayed as well in the Open project win-
dow.
Type :
• Planning
• Base object
• Templates
• System
The dropdown field Type is only activated if the object right “Write ” and the
function right “Project options ” are available for the project.
5.5.2 The Links tab
Data from other projects can be used by linking with other projects.
Project precepts
Defines the base object (i.e. the layout objects) for the project.
Generally @J Project .
The base object script of the project also comes from the base object. Script
functions can as such also be run from a base object, for example to extend
the context menu via OnMenuCreate.

You can drag a new base object into this field and as such change its defini-
tion.
Base Data Determines the base objects project.

A base project can be used in as many planning
projects as desired. All projects of type Base
object that had been created are available for selec-
tion in the current database.
Base objects form standardized prototypes for the
planning objects.
Templates Determines in which project the templates are
stored.
When a template project is opened, all the Units ,
Locations , Documents and Base objects are
made available to the user in a separate Navigator.
Thus, for example, sub-units that had already been
planned earlier can be taken over simply by copy-
ing.
All projects that were created as type Template are
offered.
For details on handling see SECTION 49.5: TEMPLATES
The objects queries are in a position to make tar-
geted searches for templates.
5.5.3 The Options tab
5.5.3.1 Prefixes and delimiters

A division is made here according to the class of the base object (such as
action, etc.) and by sub-classes (such as decision table, script, etc.) as to which
characters are to be placed before and between the relevant objects. The sub-
classes are displayed indented under the object class. If no delimiter has been
defined for a sub-class, the delimiter of the object class is used.
First select from within the left-hand dropdown field the class or the sub-class
as applicable, and then input the suffix and the two delimiters.

A single space cannot simply be input as a space. If the delimiter is

only to be a single space, you must make the corresponding entry
Space in the dropdown menu.
Delimiters are also inherited. For example, if a detail class explicitly
has no delimiter, you cannot simply delete the entry by entering
nothing, so to speak. You must use the corresponding entry None in
the dropdown menu.
5.5.3.2 Device labelling

Changes the description of the objects.
Normal - M 1
The devices are numbered
sequentially
Device Sequential
prefix number
ID char
Label / Path - 1 M 1
(= key letter / path) The
page number automatically
precedes it. Device Sequential
prefix number
Page number ID char

(automatic)
The labelling of the devices is affected by factors other than this option. An
evaluation is made as to whether a device is under a different unit than the one
given in the report:
Label / Number = AN2 - M 1

If the unit / location differ
from those in the standard
sheet, the unit prefix pre- Unit prefix Device Sequential
prefix number
cedes it.
Used unit ID char

But this information does not depend on the option and can appear in both the
above cases.
5.5.3.3 Static link

Option: Handle empty source values differently
Effect (option turned on): If no input is made in the link source (in other
words, not “0” but no value is given at all) and a value has been input in the
target attributes, then the two entries are treated as being different and the
orange marking is applied. See also SECTION 16.3.3: VALUE.
5.5.3.4 DisplayValue
Zeroize decimal places
The number of post-comma positions a numerical attribute possesses, can be
specified in the units.
By default, these post-comma positions will be displayed even if the actual
value has less post-comma digits.
In this case, the post-comma positions will be filled with zero digits.
If this option is switched off, then these post-comma positions will not be
filled.
5.5.3.5 Revision monitoring

See SECTION 41.5.6: REVISION SETTINGS: REVISION ARCHIVE (PRINTER DRIVER).
5.5.3.6 Revision archive

See SECTION 41.5.6: REVISION SETTINGS: REVISION ARCHIVE (PRINTER DRIVER).
5.5.3.7 Automatic referencing of the documents

See SECTION 40.6: AUTOMATIC REFERENCE CREATION.
5.5.3.8 Potential tracking

Comos can pass on (forward) potentials within the data structure via the con-
nections. However, the passing on of potentials takes up computer time. This
option should be turned off if you are not working with logical potentials.

Potential tracking is only done for types “ELO/C&I”, “single line” and
“Fluid.” The reason is that potential are not relevant from a technical point of
view for all other types of connections, and thus time-consuming potential
tracking is also not necessary in such cases.
5.5.3.9 Name is folder-wide unique

The terminus „folder“ means the option „Folder“ in the property window of
objetcs, see SECTION 12.2.6: EDIT GROUP “OBJECT BEHAVIOR”.
Example:
Unit
Folderobject1
Object X
Folderobject2
<New Object>
Option off: The „New Object“ could use the same name as Object X.
Option on: The „New Object“ gets a different name as Object X.
5.5.3.10 Local instances

This option determines whether local instances are set up. See SECTION 20:
INSTANCES (REDUCING THE NUMBER OF OBJECTS).
5.5.3.11 Signal tracking

Comos can pass on signals within the data structure via the connections. How-
ever, passing on these signals takes up computer time. This option should be
turned off if you are not working with signals at all, or at least, not with signals
that are being passed on.
Entire
Signal tracking is turned on. The signals are searched for as described below
in “How signals are searched for.”
Ignore bridge connection
Signal tracking is turned on, but no tracking is done via the bridges of terminal
strips. Terminal strip bridges are used to short-circuit terminals. Otherwise the
signals are searched for as described below in “How signals are searched
for.”
None
Signal tracking is turned off.

How signals are searched for

Signals are searched for automatically and adopted if they are found at one of
the following objects, the searching being done in the following sequence:
1. Owner of owner
2. Unit pointer of the owner
(Unit pointers can point to units, elements, functions or to signals)
3. BackPointer pointer to device with implementation
4. Owner of 3.
5.5.4 The Module options tab
5.5.4.1 Detail
“Implement request” replaces objects :
This option determines whether an implementation is only to be set as a
pointer to the request object or whether the request object is to be deleted.
Display relative label:
This option determines whether the texts that are output by functions such as
DevUnit are to be displayed as before or as AliasRelativLabel.
ANSI standards:
This option determines whether ANS standards are to be the basis of the dis-
play.
Regard rotation of *V*-variables
This option refers to the "Additional symbols" or "Sub symbols" technique,
see SECTION 45.4.2.4: BASE OBJECT.
The option determines how the integrated sub symbols are to be handled when
placing the main symbols.
„Regarding rotation of *V*-variables“ on: The sub symbols will be rotated in
the position of the place holder text.
„Regarding rotation of *V*-variables“ off: Sub symbols will always appear
with horizontal base line.
5.5.4.2 Process engineering

Base object for pipe / streams :
Here the base object in which the PFD streams flow (a pipeline as a rule) is
defined. See the PFD section for more detailed information.

Implementation name :
This gives the key term by which the implementations of a PFD are labelled
as being together (system setting). See the PFD section for more detailed
information.
Disable automatic generation of Comos connectors:
Determines whether or not a new connection in the report automatically gen-
erates new connections in the database as well.
Always create a new name at unit assignment:
Determines whether or not new object names are always generated.
5.5.4.3 R&I (i.e. P&ID)

PipeCAD pipe classes project : Comos can work together with PipeCAD
and pipe classes. Input here from which PipeCAD project the pipe classes are
to be taken.
5.5.4.4 EE / I&C reference layout

For the use of references see SECTION 59.2.1.7: DOCUMENT CROSS-REFERENCES.
The settings are currently used in flowcharts. In order to test the effect, you
must:
• create an Interactive Report, and
• connect with a report template that has been set up for circuit diagrams, and
• use reference base objects.
You can find the reference base objects on the Base objects tab under
@1EA Catalog EE . This concerns:
• Page references (pair reference, pair reference with device tag)
• Cables
• Potentials
(“References” should not be taken literally in the case of potentials, since
they “refer” to themselves in a manner of speaking and thus make it possible
for a potential to extend over several pages.)
There are two types of potential references:

• Chain
• Master / Slave

It is possible to switch between these two options on the basis of a specific

system. The two options determine where the “label” is output.
• Master: label on the right
• Slave: label on the left
• Chain: on both sides.
The labels can be turned on or off on both sides as desired by using the mouse
context menu.
Sort documents
Determines in what order the documents are addressed internally. (This has
nothing to do with the form of display in Navigator.) The internal sequence
determines in turn which documents are displayed as the next or previous in
the corresponding diagram cross-references.
The “sort documents” option does not change anything in the data or the con-
sistency of the data within Comos. This option is solely used to allow the user
to page quickly back and forth between the individual documents in the doc-
umentation that is output. The documents are printed out in the order stipu-
lated by the user within Print Manager. The cross-references to the diagrams
should now be such that the user does not have to always “jump back and
forth” when paging up and down but can quickly get to the desired diagram.
If the parameter is changed, this has two effects:
• Objects that run across multiple documents can have a label at the edge
showing on which document this object continues on. An example of such
objects is provided by potential references: potentials often extend over
several documents. If the Sort documents option is changed, a different
document will be displayed as the next in the series in the labels at the edge.
(Potential references are created automatically if the same potential object
is used on different diagrams.)
• The parameter is also taken into consideration in the output of the next and
previous pages when Interactive Reports are printed. This is a label on
diagrams that states which document is the next in the sequence and which
is the preceding one. The same applies here: If the Sort Document option is
set accordingly, then a different document is displayed as next / previous for
these labels.
Please note: the parameter Sort documents does not change the order in
which the documents are printed! This sequence is determined by Print Man-
ager.

Which documents are affected by the sorting?

Using the Standard or Name options, those documents that are under the
corresponding owner are sorted. All other options sort across the entire
project, whereby nonetheless only the same type of diagram as the initial doc-
ument is taken into consideration. It is recommended that you turn off these
options before printing for reasons of speed.
The Reference documents option is a special case.
Depending on their configuration, documents – and also Interactive
reports – are automatically referenced on the Documents tab, see also the
user manual. These reference entries (called links in Windows terminology)
are in a different order.
If the Reference documents option is activated, the order of the references
is used internally and sorting is only done within the corresponding document
group.
Reference not The text that had been entered in this text field is
resolved displayed if a reference still has no target.
Use complete This option has the effect that the complete owner
structure name structure is displayed in the reference.
Remove document When the reference evaluates the document groups
group (e.g. in Reference via reference object ), it is
possible to set here whether the Name document
group is to be displayed as well.
Delimiter unit / One or more delimiters.
location to sheet
Delimiter sheet to One or more delimiters. (The path is the horizontal
path component of a standard sheet.)
Delimiter path to One or more delimiters. (The zone is the vertical
zone component of a standard sheet.)
Reference with Determines when the name of the unit is to be
unit named in the reference.
Reference with Determines when the name of the location is to be
location named in the reference.
Table 5-1: Project parameters for the display of references

Reference with Determines when the name of the page is to be

sheet named in the reference.
Prefix These characters are appended to the beginning of
the reference.
Suffix These characters are appended after the end of the
reference.
Path vertical Takes the path into consideration in the name. (The
(path) path is a component of a standard sheet.)
Path horizontal Takes the zone into consideration in the name. (The
(zone) zone is a component of a standard sheet.)
Table 5-1: Project parameters for the display of references
5.5.5 The Languages tab
These properties are described together with language translation for the
objects in a chapter of their own, see SECTION 42: LANGUAGES (LOCALIZATION).

5.5.6 The Run cases tab
Create run case

Run cases are various interpretations of a project that are shown in the form
of differing values for the attributes: the object structure and the objects
always remain the same, but the relevant attribute values are set differently as
required.
Run cases are used, for example, to document in parallel the operation of a
unit under various load states, times, etc.
Right-click with the mouse in the dialog window and select the mouse context
command | NEW.
Run cases are defined by Name (mandatory field) and Description . The
name and the description can still be changed later by calling up the Properties
window with the mouse context menu.
Select run case

The run cases that have been determined for the current project are offered for
selection in the topmost menu line. This drop-down menu is only available if
run cases have also been defined for the project that has been opened:
The name of the selected run case is displayed in the Navigator at the top level
next to the project designation.
In addition, the run cases can be switched by means of their own dialog win-
dow. Open this dialog window by clicking on the project and selecting the
| RUN CASES mouse command.
Delete run case

Command: right-click with the mouse, and | DELETE
The marked run case is deleted. All the information associated with this run
case is lost.
Run cases can also be controlled by objects.

Rights Management Overview of rights management within Comos
6 Rights Management
6.1 Overview of rights management within Comos
6.1.1 Access an the database
Databases could use own passwords. See SECTION 6.9: RIGHTS MANAGEMENT FOR
DATABASES.
6.1.2 Meta-rights
In Comos there are rights that go beyond the “normal” rights management.
6.1.2.1 Administrator
As is generally the case, that is the name for the user who possess all the
rights. Regardless of how the rights of a user are otherwise granted: if the
administrator right has been allocated to the user, the user may manipulate the
data in all possible ways. An administrator automatically possesses the
“project management” right as well. The following tasks and tools are only
available to administrators:
• Menu | ADMINISTRATOR | SYSTEM
– Support
– User management
User management covers the options for creating and editing users and
user groups.
In addition to user management, in Comos there is also a second option
for granting rights, this being via object management. Within object
management there is a “grant rights” right for this very purpose. In other
words, rights can also be partially allocated even without going through
user management, but this only relates to a specific object in which you
are allowed to do that.
– Database reconciliation
– Synchronize project folder
• DBsync (tool at the bin-folder)
• ExportDB (tool at the bin-folder)
• ImportDB (tool at the bin-folder)

Overview of rights management within Comos Rights Management
– SyChange (tool at the bin-folder)

– Recreate deleted objects
A new object query must be created for this purpose:
| NEW | NEW QUERY | APPLICATIONS | USER-DEFINED
Click on the icon Save/load: and choose Load from file in the object
query.
Open: Comos\Ocx\Query\customextendedobjs\Beispiel.xml
6.1.2.2 Project management

The “project management” right can also be regarded as a function right. For
technical reasons this was created as a meta-right.
In principle, you are given the option to create or move, etc., projects with this
right. However, these tasks can only be carried out in the case of projects for
which you have the required object rights in addition.
It should be noted as well that the “project management” right is not a genuine
meta-right, since there are interactions with the other rights:
• New: no additional rights are required.
• Copy / Paste - requires in addition: Read
• Delete - requires in addition: Read, Delete
• Import - requires in addition: Write
• Export - requires in addition: Read
6.1.3 Notes regarding licenses
The usable functional scope varies according to the license in use. The license
limitations state which rights are available for a particular license.
6.1.3.1 Viewing license

There is no "viewer" in Comos, but only a "viewing license" that can be used
in a completely normal Comos installation.
If the viewing license is used, then the write right in the Comos core is turned
off. This thus provides 100% write protection. The interface of Comos may to
some extent give the impression that you can still edit the data, but that is
definitively not the case.

Rights Management Overview of rights management within Comos
This also applies to administrators. If access to Comos is made via the view-
ing license, then of course even an administrator is not allowed to make any
write accesses. The administrator has in this case all the read rights and also
access to all the working areas, but no more than this.
If all the write rights are missing, the interface of Comos can behave
strangely. A number of user interfaces presuppose that you have unrestricted
write rights and can no longer be used, or only with restrictions, without the
write right. An attempt was made in such interfaces to simulate an access that
resembles a write access and so to make operation appear uniform throughout.
However, we cannot exclude the possibility that individual, very specialized
components can only be used with restrictions with a viewing license.
6.1.4 Definition of the three rights groups
In Comos there are three different areas in which rights are granted: object
rights, function rights and working areas.
Definition of object rights

Object rights relate concretely to individual data records and are ultimately
the permission to read data within Comos or to manipulate it in a particular
way.
Since the options for manipulating data are ultimately restricted from a tech-
nical point of view, the individual manipulation rights are also predetermined
to a large extent and are the same in most software tools in the world: read,
write, copy, etc.
Please note that a project is also an object in itself in the object-oriented world
of Comos. Thus object rights can also be granted for projects. Nonetheless, a
project is a “somewhat different object,” with the result that the effect of the
object rights in a project can be somewhat different.
Definition of function rights

The function rights manage access to specific tools and working techniques
within Comos. The function rights are thus especially tailored to suit Comos
in a way that does not need to be used in other software tools.

Overview of rights management within Comos Rights Management
Definition of working areas

Working areas structure the data from the point of view of the various techni-
cal fields, or in other words, the data for process technology, for electrical
engineering, etc. A number of such working areas have already been pre-
defined in Comos. But the working areas that are actually needed can differ
from customer to customer.
For that reason there is the option to for you to define working areas by your-
self and to allocate rights for these self-defined working areas.
6.1.5 General effect of the mechanism for rights
Project-oriented granting of rights

Apart from the meta-rights, which are not related to a specific project, rights
always only take effect within a project. It does not matter if this concerns an
object right, a function right or the allocation of working areas: the allocated
rights are only valid for a specific project.
This applies in particular to new projects: users there, with the exception of
administrators, have no rights whatsoever. The users therefore can not yet see
new projects in the project management part, since this requires read rights.
Inheritance of rights
Object rights (but only these) are inherited. See SECTION 6.2.1: INHERITANCE IN THE
CASE OF OBJECT RIGHTS.
Addition and subtraction of rights

All rights are derived from the personal rights and the group memberships.
Both the personal rights and the rights of the group can be derived from user
management as well as from object management.
6.1.6 Overview of the options for allocating rights
If actions are undertaken in Comos, then there are always two participants: the
user who is doing something, and the data or components that are affected by
the action. Thus you always have two options to allow a user to do something
within an action:
• You can allow the user to do specific things.
See SECTION 6.5: MANAGE RIGHTS: USER MANAGEMENT.
• You can inform the data or components who is allowed to manipulate them.
See SECTION 6.6: MANAGING RIGHTS: OBJECT MANAGEMENT.

Rights Management Object rights
To all intents and purposes the two methods are just as good as one another
and it is purely a matter of preference or the amount of work involved that
determines which one is to be used.
6.2 Object rights
6.2.1 Inheritance in the case of object rights
An object right is passed on and inherited until it is specifically blocked or

revoked.
If you are given the “read completely” right at a much higher level of the tree
structure, you can then view and open all objects lying underneath this object.
If this right is then turned off again in one of the lower-lying objects under-
neath it, then you cannot view or open this sub-branch, although you can still
do so with all parallel sub-branches.
• Rights from individual and group rights definitions only add up
cumulatively if both definitions were created for the same object.
• If a copying action is carried out, copied objects lose the user rights of the
previous owner and inherit those of the new owner.
6.2.2 Object rights in detail
6.2.2.1 Read completely

• At the project level
This project can be seen in the project selection window and can be opened
or manipulated with the relevant rights.
• At the object level
The object can be seen in the Navigator and its properties window can be
opened.
All further windows, dialogs and tools function independently of this right. In
other words, if you do not possess this right, it does not mean that you may
not view or read an object at all. It simply means that you may not view or
read this object at specific locations, and no more than that.
This mode of operation is ultimately based on the basic principle that certain
documents must always be correct. This document-oriented principle is
explained in the following.

Object rights Rights Management
Let us assume that a user had no read rights at all for an object. Then he or she
would also not be allowed to see this object in drawings, parts lists or other
documents. However, this would mean that a parts list or other documents
would only be complete and correct if the user of this document possessed all
the read rights for all the objects involved.
But since the situation always arises within complex CAE systems that the
read rights of the users are not completely up to date, incorrect documents are
often produced.
This cannot be allowed. Documents must always be correct, or to put it in
another way: either you get no document at all or you get a correct document.
But it cannot be allowed that incorrect documents are output. For that reason
the read right is not evaluated in the case of documents: if the user has the right
to open this document, then it does not matter if he or she also possesses read
rights for all the objects within the document.
Setting
With the exception of the project, all objects start out with the Read comple-
tely right switched on for each user. The effect is that users can in particular
read all the base objects (and thus use them) without the administrator needing
to explicitly give users read rights for the base objects.
6.2.2.2 Write
To change the General tab and all tabs inherited from the project base
object. All other project properties are controlled via the Project options
function right.
The entry for Current user may be switched over on the Languages tab
within the project properties without needing to possess write rights for the
project.
To modify the object.
6.2.2.3 Delete
This right only takes effect within the project if you also possess the Project
management right. If you possess both rights, you are permitted to delete the
project within the project selection window.

Rights Management Object rights

To delete the object.
6.2.2.4 Create
• All objects
To create new objects underneath this object.
Write rights are required to modify these “blank” new objects.
All actions that do not involve the creation of any new Comos objects are
unaffected by this. Thus you can draw circles and lines on a report or move
objects, etc.
6.2.2.5 Create revision

• In the case of documents and document groups
Executing the first revision step at the object.
The first revision step has the following name and description:
<Lowest number> / <Description>
This right has no effect with all other objects, since revisions are created
exclusively for documents and document groups.
6.2.2.6 Check revision

Executing all the revision steps apart from the first and last steps at the
object.
6.2.2.7 Release revision

Executing the last revision step at the object.
The last revision step has the following name and description:
99 / <Description>
6.2.2.8 Set user rights

• All objects
To set up, change and delete the rights of third parties to this object (object
rights and function rights).

Function rights Rights Management
6.3 Function rights
6.3.1 Base data function right
This right is by far the most comprehensive of the function rights. The right
represents an intermediate level between the administrator and the normal
user.
Please note: The base data function right can also be allocated within a plan-
ning project and then relates only to this one. When the term “base object” is
used in the following, it includes within itself all action objects.
The right has the following effects:
• Navigator display
– All objects are visible on the Base objects tab within the Navigator.
(All the system branches are greyed out if you do not have this right.)
– All the text components are visible. (All the texts that have a name
starting with “@” are greyed out if you do not have this right.)
• Context-sensitive mouse menu Navigator | New
– The | New menu command is available for the base objects of this
project. In other words: if you are within a planning project, then the
| New menu is not available in the case of objects that were displayed
from the base project. You can thus create local base objects within a
planning project with this right.
– | New | New query
– | New | New standard import
• Context-sensitive mouse menu Navigator | Delete
– You can delete local base objects within a planning project with this
right.
• Context-sensitive mouse menu Navigator | Navigate
– (In the case of planning objects) | Navigate | Object in base project
– | Navigate | Inheritance source
– Context-sensitive mouse menu Navigator | Template
– Neither the | TEMPLATE PROPERTY command nor the | OPEN DOCUMENT
command are available in the original document.
• Context-sensitive mouse menu Report | Navigate

Rights Management Function rights
– | Navigate | Object in base project

– | Navigate | Document in base project
• Comos menu bar
– | ADMINISTRATOR | BASE DATA
These commands are then correspondingly available as well in the icon
bar.
– | VIEW | MENU BAR / SYMBOL BAR | SYMBOL BARS | CREATE BASE OBJECT
DEFINED
– | EXTRA | REPORT DESIGNER

– | EXTRA | BULK PROCESSING | BULK PROCESSING FOR BASE OBJECTS
– | EXTRA | BULK PROCESSING | BULK PROCESSING OF SPECIFICATIONS
– | EXTRA | TRANSLATION | PROJECT
– | EXTRA | CHECK | EDIT INSTANCES
• Open the properties window of the attributes or the specification-tabs by
double-clicking on the planning objects
• Properties window base object
– Data tab: Change
– Specifications tab: Switch to Design mode. (The menu behaves in the
same way as on the planning side if you do not have this right.)
– Elements tab: | New
– Connectors tab: | New
– Script tab: Change script
– System tab: Change
• Dialog window CDI: Script
• Query base objects of the object
– Icon bar Save/Load: Save
“Save as” is still possible, because this only makes a copy but the object
query itself is not changed.
– Icon bar Save/Load: Load from file
XML archives can be loaded with this command.
– Icon bar Save/Load: Load from base object
• Base objects of import objects

Function rights Rights Management
• Icon bar Save/Load: Save

“Save as” is still possible, because this only makes a copy but the object
query itself is not changed.
– Icon bar Save/Load: Load from file
XML archives can be loaded with this command.
– Icon bar Save/Load: Load base object
• Edit script error
– While the menu command | VIEW | SCRIPT ERROR HANDLING is available,
when the script error is displayed, it may not be changed without the base
data function right.
6.3.2 Product data function right
For planning objects of the “Device” class if this had been prepared for prod-
uct data:
• Icon bar: Create base object product data
• Allocate base object product data (“device selection”)
Attributes (specifications) can also be edited without this right.
6.3.3 Object debugger function right
Allows access to | EXTRA | OBJECT DEBUGGER.
6.3.4 Project options function right
• Properties window for the project

– Links tab: Change
– Options tab: Change
– Module options tab: Change
– Languages tab: Change
However, the language can also be changed in the Current user column
even without this right.
All the other tabs can also be edited without this right if the write object right
is available for the project. This applies in particular to tabs that are loaded via
the base object of the project.

Rights Management Working areas
6.3.5 Lock object function right
There is a green key and a red key in the icon bar within the properties window
of planning objects of the “Device” class. The “lock object” function right
controls who may use this switch and thus who is permitted to “terminate”
planning objects, document objects or document groups. The following func-
tions are blocked in an object that has been terminated:
• Editing of the properties window, including changes to the pointers (base
object, unit pointer, location pointer, implementation, etc.)
• Creation of elements
• Deletion
(also forbidden to administrators, who can otherwise continue to use all the
other functions)
• Moving, cutting
• Revision of the object
• Setting the status (checking is still possible)
Connectors and elements that have already been created are allowed to be
edited.
Terminated objects can still be copied. The copy is likewise blocked.
A locked document object also blocks the report against being changed.
Object queries have their own blocking functions.
A number of properties can be terminated in the base object (name, label,
description).
6.4 Working areas
6.4.1 Definition and area of application
Working areas (“layers”) are a freely configurable allocation of base data. In

this way this allocation can be broken down to the level of tabs and even of
attributes. The selected working areas determine for whom the base object
(the tab, the attribute) is visible and thus usable.
Technical working areas have been set up (P&ID, EE, Mechanical, etc.) have
been set up in the standard database. This sub-division is purely given as an
example and can be changed at any time. For example, working areas could
be set up for an allocation of personnel or for a planning work flow.

Working areas Rights Management
The base objects (tabs, attributes) are always allocated to at least one working
area.
Working areas are not identical with the levels in interactive reports, which
are likewise often referred to as “layers” (see @GRAFICS | @LAYERS).
6.4.2 Create working areas in the base data
The working areas must have been created in the base data if they are to be
available to all:
@System | @D Data | @Layer Operating ranges
Thus additional objects that have a name with a letter between A and Z are
created underneath @Layer:
A layer object corresponds exactly to a working area. All the defined layer
objects are then available for selection in the Working area dialog field of
the base objects (tab, specification/attribute).

6.4.3 Allocate base data to the working areas
Properties window for a base object, System tab, Miscellaneous option

group:
The working area is also evaluated for the base objects of documents! In other
words: the document is not visible in the Navigator if it belongs to a “foreign”
working area.
Properties window for an attribute (a specification), General tab:
Properties window Specification-tab:

Working areas Rights Management
The Working area dialog field

This window appears when you click on the [...] button to the right of the
above working area field:
The Working area without restriction option has been set in the default set-
tings. Ignore this option, it will be adjusted later automatically.
• Mark one or more of the working areas with <CTRL> or Shift and right-
click on the selection.
• Select ON or OFF. (The Working area without restriction option is
switched off automatically if at least one working area has been set to OFF.)
The list can be sorted by clicking with the left mouse button on the head of the
one of the columns:
Click on the Working area without restriction check box if you wish to
reactivate all the working areas. If this option has been activated, the user also
automatically receives all rights for all working areas created in the future. If
this option has been deactivated, the user has no rights for all working areas
created in the future.

6.4.4 Local working areas
A working area is created if you input in the Working area dialog field a let-
ter that is not yet included in the list:
This local working area is then included in the list of working areas when you
click on the [...] button:
As soon as you switch off the local working area in the list, the local working
area disappears again from the list and from the dialog field.
For technical reasons, the local working areas are deleted in the window when
changing the “Working area without restriction“ option. If you turn the
switch off again, you have to input the local working areas by hand once
again.
6.4.5 Temporarily restrict working area
Comos menu, EXTRA | RESTRICT WORKING AREA TEMPORARILY:

Manage rights: user management Rights Management
The effect in this dialog window is the same as if fewer working areas had
been allocated to the user account. You can thus quickly check how the data
will be displayed for a user with fewer rights regarding the working areas.
6.4.6 Allocate working areas to users
Working areas are allocated via the user management, see SECTION 6.5.2.4: THE
WORKING AREAS TAB.
6.4.7 Allocate working areas and connections
The Type field is located in the properties window for connectors. It is stip-
ulated within the base data which working areas the type of connector should
belong to.
A base object with the fixed name @Connector is created for this purpose in
the base data under the base object @Layer underneath the relevant base
object of a working area.
A base object is created underneath @Connector for each type of connector
allocated, the name of which is exactly the same as the Comos constant for
the Type of connector. The Comos constant can be found by selecting the text
in the Type field of the connector properties window; you can find the Comos
constant on the Connectors tab in the Type column.
6.5 Manage rights: user management

As was explained above in SECTION 6.1: OVERVIEW OF RIGHTS MANAGEMENT WITHIN
COMOS, “normal” users initially possess no rights at all. User management is
only available to administrators and is opened via:
| ADMINISTRATOR | SYSTEM | USER MANAGEMENT.
Alternatively, click on the icon shown at the left that is in the Admini-
strator icon bar.
User management consists of two tabs: Users and Groups .
All the lists in the user management are mini-queries and can be correspond-
ingly sorted and filtered, etc. See the “Object queries” section of the Quick-
start Basic manual or the corresponding section in the Comos manual.

Rights Management Manage rights: user management
6.5.1 The User tab
Automatic entries in the user list

When logging into the database, each participant is automatically created in
the user management with his system login name as a user. In other words: all
employees who have tried at least once before to log into the Comos database
(and who have not been deleted in the interim) are listed on the Users tab.
A user profile has no rights until an administrator grants it rights.
Create new user profile manually

In addition, the user profiles that had been created manually also appear in the
user list:
Right mouse button | NEW | USERS.
Note in this case that the “Name” used by the administrator for the user profile
is written exactly the same as the login name of the user, since Comos uses
the system login name for identification.
Delete user profile

Mark one or more user profiles, right mouse button | DELETE.
When a user is deleted, this also affects the database. In Comos all objects
have a time stamp. This time stamp includes the relevant date details and a
user name. Once a user has been deleted, all the time stamps that include this
name are meaningless.
For that reason a dialog pops up during the deletion process so that you can
“repost” the time stamp. This means that another user name is entered for all
objects in which there is the user name that is to be deleted.
The time stamp must be reposted under all circumstances.
Please note: This raises the problem that it is no longer possible to guarantee
that the objects that had been assigned to a user had actually been created or
edited by him or her. If you make use of a QA system, we recommend that
you set up a user profile especially for reposted time stamps so that the user
profiles of the employees remain consistent.
User profiles that cannot be deleted

The following user profiles cannot be deleted:
• “@Setup”
• “COMOSSYSTEMUSER”

Nonetheless, all rights can be withdrawn from the above two profiles.
• The relevant own user profile
If it were possible to edit the user profile that you had used to log in at that
time, it would cause massive problems due to inconsistency.
Edit user profile

You can change the text directly in the first three columns (Name, Abbrevia-
tion, Description ):
Right mouse button | EDIT
All the other information relating to the user profile can only be changed in
the properties.
6.5.2 The properties of a user profile
User management, User tab, mark a user profile, right mouse button
| PROPERTIES
6.5.2.1 The Memberships tab

The tab consist of two fields. At the left are listed all groups within which the
user is already a member. At the right are listed all the other groups in which
the user is not (yet) a member.
Start group membership

Mark one or more groups at the right, click on the [ADD] button.
Terminate group membership

Mark one or more groups at the left, click on the [REMOVE] button.
6.5.2.2 The Rights tab

The Rights tab is valid everywhere and is explained in The Rights tab, P. 6-21.
6.5.2.3 The Contact data tab

This tab has no special features and is self-explanatory.

6.5.2.4 The Working areas tab

You can find all the basic relevant information on the topic of working areas
in SECTION 6.4: WORKING AREAS.
The tab has two dialog fields. The upper field, Working areas, lists the areas
that you are allowed to edit.
The lower field, Read only, lists the areas that you can read but not edit, as
the name implies:
You can input the working areas directly into the dialog fields if you know the
letters off by heart. Alternatively, click on the [...] selection button and select
from the list of working areas:
The Working area without restriction option has been set in the default set-
tings. Ignore this option, it will be adjusted later automatically.
• Mark one or more of the working areas with <CTRL> or Shift and right-
click on the selection.
• Select ON, OFF or READ ONLY. (The Working area without restriction
option is switched off automatically if at least one working area has been set
to OFF or READ ONLY.)
The list can be sorted by clicking with the left mouse button on the head of the
one of the columns.
Click on the Working area without restriction option to reactivate all the
working areas.

Local working areas

The list of working areas only makes available those areas that had also been
created in the base data. You can create local working areas by simply insert-
ing directly into one of the Working areas or Read only dialog fields one
or more letters that have not already been allocated.
The same letters can be entered in the working areas of base objects, tabs or
attributes. Nonetheless, you must make a note which letters you have used as
local working areas, since in the dialog fields the working areas always appear
in the working areas that had been created within the base data.
6.5.2.5 The Miscellaneous tab

This tab has no special features and is self-explanatory.
6.5.3 The Groups tab
The Groups tab consists of two lists: the groups are shown in the upper list.
The lower list is to provide information on which employees are in the rele-
vant group that had been clicked on above.
Editing is always done in the upper list only.
Create groups
Command: Right mouse button | NEW | GROUP
Delete groups
Mark one or more groups, right mouse button | DELETE
Edit groups
The first two columns (Name, Description ) can be changed directly in the
upper lists:
Right mouse button | EDIT
All the other information on the group can only be changed in the properties.
6.5.4 The properties of a group
User management, Groups tab, mark a group, right mouse button

| PROPERTIES

Add group members

Open the properties of the group, Members tab: the [ADD] button opens the
list of user profiles. One or more entries can be marked and accepted with
[OK].
Delete group members

Open the properties of the group, Members tab: mark one or more user pro-
files and then click on [Remove].
Edit the rights of a group

The Rights tab is valid throughout and is explained in The Rights tab, P. 6-21.
6.5.5 The Rights tab
The Rights tab differs only slightly in appearance according to where it is

opened. The tab looks like the following as a maximum:
Administration rights
(User management) Only appears when the tab is called up within user man-
agement and only for users, not for groups. See SECTION 6.1.2.1: ADMINISTRATOR
concerning the importance of the rights.
If the Administration rights has been activated, the Project management
option is fixed in the “on” setting. The reason: an administrator possesses all
the rights in any case. In that case it thus makes no difference which object
rights or function rights appear in the list at the bottom.
Project management
(User management) Only appears when the tab is called up within user man-
agement. See SECTION 6.1.2.2: PROJECT MANAGEMENT concerning the importance
of the rights.

Display of object rights / function rights

(User management / project object) These options are available within user
management, since you can manage both object rights and function rights
there.
These options are only available within object management when you call up
the management for the project: mark project, [CTRL]+[A]. The Function
rights option is deactivated for all other objects and only the object rights
appear automatically in the rights list.
The two options toggle the list in the lower area. A column appears for each
object right and each function right respectively, and a “+” appears in the col-
umn if this right exist.
Show rights for current project / All projects
(User management) Only appears when the tab is clicked within user manage-
ment.
The Rights list

This list is dynamic and the contents depend on from where the Rights tab
was called up from.
As was explained above in SECTION 6.1.6: OVERVIEW OF THE OPTIONS FOR ALLOCA-
TING RIGHTS,there are two options for allocating rights: from the point of view
of the subjects (the user) and from the point of view of the objects:
• If the Rights tab was called up from within user management, then the
question is: what is a user (or a group, as applicable) allowed to do and with
which objects? We are thus looking at a concrete user / a concrete group.
– The objects to which the user has rights appear in the rights list
• If the Rights tab was called up from within object management, then the
question is: who may do what with this object. We are thus looking at a
concrete object.
– The users who have rights to this object appear in the rights list.
However, all the other columns are identical, since the question of which
rights can be granted is totally separate from how the rights are granted!
Please note: the entries in the rights list are not complete, since the effective
rights of a user are derived from a combination of his or her personal rights
and the rights of the user groups to which he or she belongs.

Rights Management Managing rights: Object management
6.6 Managing rights: Object management

Rights can be allocated at the object level within Comos, i.e., in an extreme
case it would be possible to have specific user rights set for individual objects.
Normally, however, for administrative reasons that would only be applied to
objects that are “high up” in the tree structure.
Please note: there are general rules concerning object rights, see SECTION 6.2.1:
INHERITANCE IN THE CASE OF OBJECT RIGHTS.
Object management opens up by marking the object with the mouse and then
pressing [CTRL]+[A].
6.6.1 General tab
First of all, use the selection button to search for a user for whom the evalua-
tion is to be made:
Name Name of the marked object.

Created A time stamp: Date and user for creation of the
object.
Last change A time stamp: Date and user for the last change.

Evaluate rights Rights Management
Current object Shows the actual rights that the user in question has
rights for regarding this object.
Read only because Shows the reasons why an object for which you
possess all the rights cannot be changed:
Object is not in the current project
Example: Base objects may be shown in the plan-
ning project, but they belong to the base project.
Inherited
Often in the case of attributes. Inherited properties
cannot be changed or else need to be checked in.
Locked
This affects objects in the properties window with
the red key. Blocked objects cannot be changed.
This information can also be queried with the
SystemRO function, see „IComosBaseObject“.
Status Object saved :

This option is activated if no changes had been
made since the last time that it was saved.
Object can be saved :
This option is activated if the object could not be
saved, e.g., because the name is not unique.
6.6.2 Rights tab
The Rights tab is valid throughout and is explained in SECTION 6.5.5: THE RIGHTS
TAB.
6.7 Evaluate rights

We explained in SECTION 6.5.5: THE RIGHTS TAB that the rights list is not a com-
plete listing of the effective object rights. You can create a complete overview
of the effective rights with the help of an object query.
You do this by using an object query for planning objects and inserting an
additional column that has the following script (example):
Script ColumnValue = cstr((RefColObject.GetObjectRights and 2)
= 2)

Rights Management Grant rights for status management
The “2” is a constant here and stands for the “write” object right.
Effect
“True” appears in the column if the evaluated right exists for this object, and
“False” if the user does not possess the right.
6.8 Grant rights for status management

Status management is a control instrument in Comos. It is used to classify
objects (and thus data). For example, you can specify which data you are still
editing and which data is already finished. See also SECTION 21: STATUS MANA-
GEMENT.
Status management is set up on the following base objects:

@System |@D Data|@Status
An own base object is created underneath this each for each status. The ele-
ments that determine the status values lie one level deeper.
You can allocate to the base objects the status values to indicate which users
may possess write rights by using the object management.
Only those users who have write rights there are permitted to set the corre-
sponding status value in the planning data.
6.9 Rights Management for databases

Background
These details apply to:
• Oracle
• MS SQL Server (from version 7.1)
Each user wishing to work in one of these databases must be logged in
through an account. Unlike in Comos, the account can be chosen freely, and
then you can allocate the corresponding rights to this account. But nothing can
be done without an account.
If you work with Comos, then as a rule an account called “Comos” is created
in the rights management of the database.
Without the user having to take any further action, he or she is given the dialog
window for database login when trying to login into the database with Comos
and there must input the account name and the password.

Rights Management for databases Rights Management
This login can be automated. This achieves two things:

• On the one hand it makes it unnecessary for the database administrator to
have to make a “public” distribution of an Oracle password as plain text.
• Since the user does not know the account name and the password, he or she
cannot misuse these details by, for example, logging into the database as
Comos through other tools.
• On the other hand, it is more convenient for the Comos user.
Application
Comos creates a file in the Comos\OCX directory when the database is
accessed for the first time:
With Oracle: orapwd.dat.
With multiple instances: This mechanism also applies to orapwd_1.dat.
However, orapwd_2.dat is not covered by this mechanism, so you can login
“freely” with this instance.
With MS SQL Server: mssqlpwd.dat.
With multiple instances: This mechanism also applies to mssqlpwd_1.dat.
However, mssqlpwd_2.dat is not covered by this mechanism, so you can
login “freely” with this instance.
If you have logged in correctly into the database for the first time, this login
is thus stored in the file: this file includes the account name and the access
password in an encrypted form that can only be read by Comos. This file can
now be transferred publicly over the network to all authorized Comos users
and stored locally in the Comos\OCX directory.

Inheritance Definition of the methods
7 Inheritance
This section covers the mechanisms by which information can be transferred
automatically within Comos from one object to other objects.
7.1 Definition of the methods

All information that is collected on the tabs of the base objects, or in other
words, properties and collections, can be transferred and inherited. Examples
of collections are attributes, connectors, elements, etc.
7.1.1 Inheritance with planning objects
In principle, the same terms are used in the case of planning objects, but com-
pletely different mechanisms are described there.
Hierarchical inheritance: There is no hierarchical inheritance in the case of
planning objects.
Referring: There is the Base object field in the properties window of a plan-
ning object that connects the planning object with a base object. From a tech-
nical point of view, this is similar to the use of References on the properties
window of base objects, except that only a portion of the data is transferred
from the base object to the planning object, while in the case of base objects
all the information is transferred. For example, the Symbols and Usage tabs
that are required for administration are not available on the planning side.
Linking: A link is also called a “reference” in the case of planning objects.
Links can be created within a planning project, but information is not col-
lected, unlike within the base project. Links within planning objects thus rep-
resent nothing more than an alternative access point for the object.
So much for the planning side, the following details relate to the base data.
7.1.2 Definition of hierarchical inheritance
Inheritance can also be called „1-to-n inheritance“, since an object can have
any desired number of “children,” but each object only has one “parent
object.”

Definition of the methods Inheritance
Catalog
Pump
Spec1 Z.B. Quantity
Spec2 Z.B. Power

Hierarchical
Special pump Inheritance
Spec1 Quantity
Spec2 Power
Hierarchical
Pump 1
Inheritance
Spec1 Quantity
Spec2 Power
Pump 2
Spec1 Quantity
Spec2 Power
In the case of hierarchical inheritance, new objects take the properties and col-
lections of the “parent object” that is higher up in the hierarchy. If any infor-
mation is changed in the “parent object” (also called parent”), this change
takes effect in all “child objects” as well.
If information is inherited, as shown above in the example for “Power,” this
information can be added to and modified at the lower levels of the hierarchy.
A value could be assigned to the “Power” property or the description is mod-
ified. In this case we refer to a property that has been checked in, see
SECTION 7.3: CHECK IN OBJECT.
Please note: if the name of the attribute is changed at a higher level within the
hierarchy, then any properties that had been checked in are now unusable.
Avoid changing the name of an attribute that has already been checked in
somewhere.
This inheritance always takes place, and automatically. This is shown by an
“E” in the Status column of list mode. A reference breaks the original inher-
itance chain at this point and inserts a new one (see SECTION 7.1.3: DEFINITION OF
REFERENCES (LINKS)).

7.1.3 Definition of references (links)
A reference transports all information that can also be inherited. (The man-
agement of the rights structure is completely separate from this, although that
too deals with the question of “inheritance”).
In the case of references an object receives the information (properties and
collections) off an object that is on another branch of the tree structure when
seen from a hierarchical point of view. If an attribute of the source object is
changed, for example, this change also takes effect for all objects that have a
reference to this source object.
References also have a 1-to-n relation, since an object can serve as the source
of a link as many times as desired, but each object can only have one “refer-
ence source object.”
A reference breaks the inheritance chain:
Catalog 1
Old pumps
Spec3
Spec4
Catalog 2
Special pumps
New pumps
Spec3
Spec1 Z.B.
Quantity
Spec4
Spec2 Z.B.
Power Pump 1
Special pumps
Spec1 Quantity
Spec1 Quantity
Spec2 Power
Spec2 Power
Link/ Reference
Pump 1
to...
Spec1 Quantity
Spec2 Power
Please note: the attributes in the various branches can of course be given the
same name.
There are two options, which from a technical point of view are both forms of
reference, but which differ in the way that they are used: a reference to another
base object, and an assembly reference.

Definition of the methods Inheritance
Base object reference

A reference to a base object is primarily used to transfer all the information of
another base object, but additionally to allow the current base object to be
expanded or modified. An item of information can be checked in and then
changed.
Attributes that had been transferred by means of a reference are checked in
when a change is made, in exactly the same way as for inheritance.
An assembly reference (see below) overwrites a base object reference.
Template reference
The current base object can no longer be modified in the case of a template
reference. All the input fields are blocked and it is not possible to check in any
more information. In practice, an assembly reference is used in order to set up
a reference to a predefined group of planning objects.
In order to understand this, you need to know that a base object does not need
to be within the base project and a planning object does not necessarily have
to be located within the planning project. It is possible to create, wire and pre-
pare objects in all possible ways within the base project planning.
Nonetheless, the user cannot later access within the planning project the
“planning objects“ from the base project. An “intermediary” is required to
make these prepared planning objects accessible. An assembly reference is
used for this purpose.
In other words: the base object only serves as a “container” for the module;
and for that reason it is also not necessary to change the information that had
been transferred from the module. And by the same token, you cannot do that
either with an assembly reference.
An assembly reference overwrites a base object reference.
7.1.4 Definition of links
Links are not base objects in their own right, but from a programming point
of view, merely objects of type CLink). If a link is affected in any way, this
change takes effect on the original (and this is visible in the original with all
links). Technically speaking, this concerns an “inheritance via Backpointer
Clink”: By contrast with the two methods introduced previously, in this case
information is not transported forwards but instead backwards.
Links are n-to-1 relations, since a link can be created at any desired number
of locations and each link adds information to the original.

If links exist to an object, the inheritance mechanism (or alternatively, the

allocation mechanism) is not broken off: the object retains both the inherited
information (or the information transferred by a reference) as well as all the
information coming to the links.
Effect:
• All collections such as attributes (specifications) are transferred
• Its own properties are not transferred, meaning properties such as the
description or label.
Please note: Links can be switched to active or inactive within the Navigator
(mouse command Inheritance active via this link).
Catalog 1 Norm 1 Link to

Special pump
Spec1
Catalog 2 Pump Special pump
From Norm1
Spec1
Spec2 via link
Spec2 Inherited from Pump
Spec3 Own specification
From other tab

Spec4
via link
Other Link to
Catalog 3
tab special pump
Spec4
Legend:
Original, changeable Readable, but unchangeable

(as far as not checked in)

Application Inheritance
All the information is visible everywhere, both in the original of the object
and also in all links. Please note that if the inherited information is modified,
that this does not change the “source” (which cannot be changed at this point),
but instead checks the information in and changes it locally. See SECTION 7.3:
CHECK IN OBJECT.
7.1.5 Definition of inheriting via catalog attribute
If tabs are linked via the Catalog specification field, then the attributes on
the tabs are also linked.
This linking of a tab has in addition the result that the hierarchical inheritance
of owners is broken off for this tab. The effect is that same as that we have
already seen in the case of references for base objects: a reference breaks the
inheritance chain from above, and it is only possible to inherit from the refer-
ence source.
The sole difference here is that this inheriting of owners is only broken off for
this special tab.
7.2 Application
7.2.1 Hierarchical inheritance
Hierarchical inheritance is an automatic mechanism and is not set manually.

The only way to prevent inheritance from an “owner” (also called a “parent”)
is to set up a reference (see the next section).
7.2.2 Making a reference (link)
A reference is set up via the properties window of a base object:

Inheritance Application
Proceed as follows to create a reference (link):

1. Open the dialog window for the properties of the base object by double-
clicking on the object in question. Activate the Data tab.
2. Use drag & drop to pull the object from which the attributes are to be
transferred by reference into the Reference input group. You can drop the
object at any desired location within the frame.
The result is as follows:

• Attributes that had been created in the object itself are retained.
• A reference transfers the attributes of the object that is referred to. This also
includes attributes which the source object that is being referred to has itself
inherited.
• The hierarchically-inherited attributes of the object are lost as a result of the
linking.
A reference can be deleted with [DELETE REFERENCE], and then hierarchical

inheritance is resumed.
7.2.3 Making links
A link is created in the Navigator as follows:

• Copy the object
• Change to the position at which the link is to be added.

Application Inheritance
• Select the context-sensitive mouse menu |Paste link
The result is as follows:

• Attributes that had been created within the object itself are retained.
• Inherited attributes are retained.
• A link transfers attributes that come to the link. This also includes any
attributes that the link itself had inherited.
• The “Inheritance active via this link” mouse command can be used
for such references to base objects. Inheritance via the reference (link) can
be switched on or off with the aid of this command. The mouse menu shows
an activation of this sort with a tick.
Rules concerning use

• The links may not be in the same part of the sub-tree, as this could cause
undesirable effects such as endless loops.
• The names may not be identical on the tabs.
Normally the a location of names for tabs is no problem:
If the objects are arranged hierarchically above and below one another, then
each name only occurs once.
If the objects are located within different sub-trees, identical names can be
allowed, since each of them comes from a unique source.
However, whenever links are used, the user must ensure that there are no
tabs with identical names.
7.2.4 Inheriting via catalog attributes
Catalog attributes are valid for attributes and Specifications tabs:

• Properties window of a Specifications tab, General tab, Catalog
specification field.
• Properties window of a Specifications tab, General tab, Catalog
specification field.
The Catalog attribute field has the same meaning as “reference“ options
group in the base object that has already been described. The result is the same
in both cases: the object / attribute only serves as a container and all the infor-
mation is transferred from the linked object.
If there is a @Y Catalog attribute base object within the current project,
this is selected first of all when you click on the selection of the catalog
attributes.

Inheritance Check in object
7.3 Check in object

The following objects can be inherited and thus checked in:
• Attributes (specifications)
• Connectors
• Symbols
• Elements
• Documents
Example of attributes
Devices can have attributes that had been defined at a higher hierarchical level
and are to be valid for all lower levels. This is displayed in the “list view“ in
the Status column by an “E”.
If inherited attributes are to be modified, they must be changed within the own
attributes of the device. This procedure is called “checking-in.” Checking-in
is done automatically by the system.
Inheritance and checking-in are done in principle at the level of the item, or
element (elements are not to be confused with the Elements tab). However,
a further distinction is made as to which Properties of the items are actually
to be modified. This means that the Value property can be checked in, while
the Control properties property continues to be inherited. Modified properties
are released from the higher hierarchical levels.
Please note: if the name of the attribute is modified in a higher hierarchical
level, the properties that had been checked in before will become unusable.
Avoid changing the name of an attribute that has already been checked-in
somewhere else in the system.
• Mark an inherited attribute in the Navigator (this can be seen by the black
arrow at the top left)
• Right-click, context-sensitive menu | PROPERTIES.

Check in object Inheritance
• The arrow changes to white once the change has been made (checked-in
attribute).
After confirmation, the inherited attribute is definitively checked in into the

device and thus into the own attributes of the device.
Checked-in attributes are marked with a “P” in the Status column.
Please note:
• Although checking-in is done at the item level, an additional distinction is
made as to which properties were modified. The checked-in items (such as
attributes) continue to inherit at the properties level information that had not
been modified.
• All properties can be changed, except for the name.

Copying General definitions and delineations
8 Copying
8.1 General definitions and delineations
8.1.1 The constituent parts of an object
In the broader sense, an object consists of the following components:

1. The object itself
2. Properties at the object itself
Name, label, description, etc.
3. Any inherited properties
All properties that are taken over from the inheritance source
4. Collections at the object itself
Quantity of subordinated objects, quantity of attributes, quantity of
connectors, etc.
5. Any inherited collections
All collections that are taken over from the inheritance source
6. References
Links to other objects
These components are handled in different ways by the different methods for
copying. The following defines the components to the extent that is necessary
for an understanding of a copying operation. Further information on the struc-
ture of the objects can be found in the Reference 1 manual.
8.1.2 The amount to be copied
Each copying operation starts with the marking of an object. Fundamentally

speaking, each copying method copies quantities 1., 2. and 4.: the object itself,
the object’s own properties (OwnProperties) and the object’s own collections
(OwnCollections).
This minimum amount of information is called overall the “amount to be cop-
ied”. To put it simply, you define an amount to be copied as follows:
Amount to be copied =
The marked object and all objects located underneath it.

General definitions and delineations Copying
Multiple selection
There are small differences in a multiple selection: a number of copying pro-
cedures summarize all the marked objects into a single amount to be copied,
while other procedures handle the marked objects individually and make
independent amounts to be copied. More on this in the relevant sections.
Inherited information is recalculated on the basis of the new owner.

Quantities 3. and 5. are not copied. To be more precise, this information also
cannot be copied because it is in fact “not there” but only has validity for this
object as well. In many cases inherited information is displayed as well in the
Navigator at the object, but because of this it is nonetheless still not a “genu-
ine” constituent part of the object.
This rule has no effect in the case of planning objects, since inheritance is very
restricted in their case (through the base object pointer).
However, unexpected things can happen with base objects, since the inherit-
ance mechanism plays an important role here. If a base object has just been
created, it then first of all inherits from the inheritance source nearly all the
information, and the class as well, for example. You can recognize an inher-
ited class from the fact that the entry is shown italicized in the Class
drop-down menu.
The inherited information is recalculated when a base object is copied. If the
class was inherited, this may change according to the new owner. (It also can
only be copied one to one once the information has been checked in.)
Inherited information is not copied. Inherited information is recal-
culated on the basis of the new owner.
A number of copying methods offer the option to set up the owner structure
as well if it does not already exist in the target project. In that case the most
important inherited information is retained because the “new” owner structure
matches the “old” owner structure in the relevant information.
Please note that it is not possible to say in general when which object infor-
mation will be copied and when which inherited object information is recal-
culated, because that depends on the relevant data structure in the target
project. There is more on this in the relevant sections.
8.1.3 References
The individual copying methods primarily differ through their handling of

references.

8.1.3.1 Allocation of objects

References are allocations of objects.
1. This allocation can affect objects that are within the amount to be copied.
In that case the references to the object that has been copied as well are
retained.
Example: In the following case the transformer and the device are joined
by connectors. From a technical point of view, this connection is nothing
other than a reference. Since both the objects are within the amount to be
copied, the reference is correspondingly retained (the connectors of the
two copied objects are joined):
References that point to objects within the amount to be copied are

retained.
2. References can “point out of the amount to be copied”. This means that
the referenced object is not within the amount to be copied.
Example: A unit is marked and copied; thus the amount to be copied is a
subset of the Units tab. If, for example, the device possesses a location
pointer, the referenced location is then on another tab and is thus not
within the amount to be copied:

A further example: If a planning object is copied, then as a rule the CDevice

on which the planning object is based is within the base project and is thus
likewise not in the amount to be copied.
There are various types of “references pointing outwards”, which are also
handled differently to a certain extent. The next section therefore starts off
with an explanation of the various types.
8.1.3.2 Definition and classification
Definition of the term “references”

References are allocations of objects. This allocation can simply have a logi-
cal function or it can result in comprehensive changes to the object. The term
“references” is an umbrella term, and for certain types of information the
terms connections, pointers or links are used as well. But in all these cases it
always involves references.
Some examples:
• Connections (connecting information between two connectors) in planning
objects are references.
• The unit pointer and the location pointer are examples of references that are
more of a logical nature. Thus it should show the logical allocation of a
device to a unit or a location although the device itself is not changed. Often
these references are used in Evaluation Reports to determine the full name
or full labeling of a device.
• On the other hand, the base object pointer radically changes a planning
object.

Reference types can be divided into two major classes:

• References that point to “planning objects in the broader sense” (the
project’s own references) and
• References that point to “base objects in the broader sense”.
Planning object references (P-references)

This groups includes, for example, unit pointer and location pointer, (closed)
connections.
Please note that planning object references can occur not only in a planning
project but also in a base project! An example of this is the modules pointer
to CDevices.
Referenced planning objects do not have to be located within the
planning project. But they are always located in the same project as
the objects of the amount to be copied.
Base object references (S-references)

These are references that point to “base objects in the broader sense”.
“Base objects” in the narrower sense are only CDevices, or in other words,
those objects that are created as the basis of a planning object. In the broader
sense, additional data is taken into the term:
• All objects on the Base objects tab, regardless of whether or not they are
of system type CDevice and regardless of the project in which they are
located.
• All lists, standard tables, document types, units groups, etc. These objects
are primarily located in the base project, but sometimes also in the system
project or even in the planning project.
Please note that base objects in the broader sense are not necessarily always
automatically located in the base project! For example, it is permitted to create
local base objects (instances), or in other words, base objects within the plan-
ning project. Document types, for example, are also permitted to be located in
the system project. In other words, the referenced objects can be located out-
side the project in which the copying operation took place.
Base objects in the broader sense can be located either in a planning
project, in the base project or in the system project. They also do not
need to be located in the same project as the objects of the amount
to be copied.

Reference types
There is a list of all references in the annex. There it is also stated whether a
planning object reference or a base object reference is involved.
8.1.3.3 Special reference types

Connectors and the alias pointer form a 1-to-1 reference. These are relation-
ships that are clearly and unambiguously visible from each view:
• Each connection has exactly one counterpart and not just any one, but a very
specific one. It is never permissible to have two connectors that both point
to the same counterpart connector.
• Each object has exactly one alias object and not just any one, but a very
specific one. It is never permissible for another object to use this alias
object.
The special points are likewise given in a list in the annex.
8.1.3.4 Alternative solutions
In the case of objects within the amount to be copied

If a referenced object is located in the amount to be copied, then the reference
will no longer point to the original object but instead to the copy in the amount
to be copied.
In the case of “references pointing outwards”

If an object possesses a reference, and this reference points to an object that
is not part of the amount to be copied, there are then five options:
1. The reference to precisely this object is retained
2. The referenced object must be copied as well although it is not in the
amount to be copied (bringing over the objects) or
3. If technically possible: the reference can be transferred (projection), or
4. The reference is deleted, or
5. The copying process is blocked.
There are no “open” references.

Regarding option 2: objects that have been brought over

In the case of option 2.: “copy referenced objects as well”, we refer to “objects
that have been brought over”. Here the referenced object itself is copied as
well, but not necessarily completely. Thus in the case of objects that have
been brought over it is necessary to restrict how much information is copied
as well to prevent the quantity of objects that have been brought over from
growing excessively due to the iterative process
An object that has been brought over can in turn contain all the information
introduced in SECTION 8.1.1: THE CONSTITUENT PARTS OF AN OBJECT. In this case it is
primarily the collections and the references that are of interest.
These collections are brought over (created) in the copying operation:
System type Collections

All objects Attributes
Base objects Attributes
(CDevice)
OwnElements
OwnDevSymbols
OwnSuppliers
OwnConnectors
OwnDocuments
Documents Attributes
Documents
DocObjects
Devices
Standard table Standardvalues
Standard value DevSymbols
Table 8-1: Information taken from the referenced object

Objects that have been brought over can in turn bring over other objects as
well. At the simplest, this can be made clear from the example of the base
object: a base object can possess a collection of documents that are then like-
wise brought over.
Result:
Pic. 8-2: Objects that have been brought over in the case of collections (example)
There is a similar mechanism for the references of objects that have been
brought over. Very broadly speaking, the rule is as follows:
P-references are lost and S-references are retained when copying the struc-
ture.
The references are retained and bring over additional objects when copying
across projects and when using the Object Matcher.
Regarding option 3: projection

In the case of option 2.: “references are transferred”, this refers to “projected
objects”.
A projection is the information that there is no need to create a new object in
the target for the referenced object because there is already an existing object
in the target that can be used as the reference. This is done by comparing the
object that has been brought over with a potential target object. The following
information must match:
• Name
• Complete path
• System type

• Class
An example:
Pic. 8-3: Successful projection

The comparison produces the following:
In object brought over In the target object

Name Transformer Transformer
Path UnitA | PlantA UnitA | PlantA
System type Device Device
Class Device Device
Table 8-4: Example 1 regarding projection
However, in the following case the projection of Transformer fails:

Pic. 8-5: Unsuccessful projection
In brought over object In the target object

Name Transformer Transformer
Path UnitA | PlantB UnitA | PlantA
System type Device Device
Class Device Device
Table 8-6: Example 2 regarding projection
8.1.4 Extended amount to be copied
The main difference of the individual copying methods is in the extended

amount to be copied.
Extended amount to be copied = amount to be copied + objects that shall be
brought over.

Copying Copying with the Navigator and an additional one
8.2 Copying with the Navigator and an additional one
8.2.1 Copying within the Navigator (within the project)
8.2.1.1 Functional scope
Minimum amount to be copied

In SECTION 8.1.2: THE AMOUNT TO BE COPIED we explained that all the copying func-
tions in Comos have a common minimum scope of copying (constituent parts
1., 2., and 4.):
• the object itself,
• all the object’s own properties (OwnProperties), and
• the object’s own collections (OwnCollections).
In other words: everything that was not inherited is copied. Inherited informa-
tion is recalculated on the basis of the new owner.
Furthermore, the copying methods differ in the way that references are han-
dled.
Handling of references in the case of simple copying

• Planning object references
– P-references with 1-to-1 relation
Connectors
a) The referenced object (namely, the device with the counterpart
connector) is part of the amount to be copied: The reference is retained to
the extent that it points to the object that has just been created by the
copying and not to the originally referenced object.
b) The referenced object is not a constituent part of the amount to be
copied: The reference is lost in the case of “simple” copying. In other
words, if a connector had been joined previously, the connector is not
joined to the copied object.
Alias pointer
An object that has been referenced by an alias pointer never becomes part
of the amount to be copied, since the alias branch must be created directly
under the project. Since the project itself cannot be copied by means of
“simple copying” and a true form of multiple selection is also not
possible, there is no way to simultaneously copy planning objects and

Copying with the Navigator and an additional one Copying
alias objects by using the simple copying function.

In other words, the alias functional scope is always lost in the case of
simple copying.
– All other P-references (functional scope) without 1-to-1 relation
“Functional scope without 1-to-1 relation” means that there can be
multiple objects that point to an object. Examples: unit pointers, location
pointers.
a) The referenced object (for example, a cable that has been allocated to
a connector) is part of the amount to be copied: the reference is retained
and points to the copied object.
copied: the reference is retained and points to the original object.
Exception to b): Cable reference that is lost in the case of a reference
pointing outwards. In other words: if a cable had been allocated
beforehand, the connector of the copied object has no cable information.
• Base object references (all)
– a) The referenced object is part of the amount to be copied. One might
perhaps expect as an example the base object pointer of a planning
object; but this does not cover all the possibilities that might occur. For
that reason the CDevice pointer of the base object was chosen as an
example; this is the reference that is input in the Reference field of a base
object. CDevice pointer: The pointer is transferred appropriately and after
the copying operation points to the object that had been copied as well and
no longer to the original referenced object.
copied. The CDevice pointer is retained and continues to refer to the
original object after the copying operation:
• DocObj
When an object is placed on a report, a DocObj is created in the structure
tree that shows this placing. Please note that the DocObj is located
underneath the report within the meaning of the object model but is
displayed in the Navigator underneath the placed object. In connection with
the copying operation, the only thing that is of interest is where the DocObj
is located within the meaning of the object model.
If a DocObj is deleted, the object placed on the report is not lost completely:
the report itself still possesses the information on what kind of object was
placed, but the report no longer has any information as to which object it
was concretely.
There are three ways to handle DocObjs when using “simple copying”:

[1] Default case: The DocObjs are deleted. When the document is opened
for the first time after copying, new objects are then created according to the
information of the report itself. In other words, the document no longer
contains the original placed objects but instead the new objects that have
been created. Where and how the objects are created is determined by the
type of diagram involved. To some extent it can be helpful to create the
objects underneath the report, and to some extent the objects are created in
parallel to the report.
[2] DocObjs are retained. If the placed object is likewise part of the amount
to be copied, then after the copying operation the DocObj points to the new
object that had been created by this copying operation. If the placed object
is not in the amount to be copied, the DocObj then points to exactly the same
object. The device is then placed twice: once on the original document and
once on the document produced by the copying operation.
[3] DocObjs are modified. A copy is automatically created in parallel with
the placed object. If there was previously a placed Indicator1 , then after the
copying operation there will also be Indicator1_1 . The DocObj points to
the object that has just been created.
The mode that is set for a DocObj can be determined by the object interpreter.
This is done by dragging the DocObj into the drag & drop field A and select-
ing the A.CopyMode command. As a result a number [1, 2, 3] is displayed
that corresponds to one of the three above-mentioned cases.
• Revisions are deleted in the case of documents.
8.2.1.2 Application
Because of its limitations the default copying function is fast and simple.
Mark an object in the Navigator and select the | COPY context-sensitive menu
with the right mouse button.
The object is copied with all its properties and collections into the Comos clip-
board and can be pasted in again at another position.
Please note that a common amount to be copied is not set up when making a
multiple selection! The effect is the same as if the relevant marked branches
had been copied individually. This is primarily of importance in the case of
“references pointing outwards”, since without the common amount to be cop-
ied the references are treated as “pointing outwards” by one of the marked
branches in one of the other branches.

Move versus Cut

The | CUT and | PASTE functions will be familiar from Windows. Since Comos
wishes to offer the usual well-known Windows functionalities as well, these
functions have likewise been made available in Comos. But they should not
be used! The following combination should be used instead:
• | COPY and afterwards
• | MOVE
The | Copy and | Move combination is functionally identical to the | Cut and
| Paste combination from the point of view of the user but it offers greater
safety in technical terms, since no objects can be lost.
Example: If an object is cut, it then only continues to exists in the Comos clip-
board. The clipboard is deleted without a safety prompt when Comos is
closed. But Comos can always be closed with no risk when using | Copy and
| Move , since the original still exists in addition to the copy in the clipboard.
8.2.2 Simple copying with a change of project
8.2.2.1 Functional scope

From a technical point of view there is no difference between simple copying
within a project and simple copying with a change of project. However, there
are a number of special cases that are only visible to the user in the second
case, the one involving a change of project. For that reason we refer at this
point almost completely to the previous section and only cover these special
cases here.

See SECTION 8.2.1.1: FUNCTIONAL SCOPE
Handling of references in the case of simple copying with a change of project

P-references are lost in the case of simple copying with a change of project.
• Base object references

– a) The referenced object (example CDevice pointer: the base object that
was entered in the Reference field of a base object) is part of the amount
to be copied. After the copying operation the pointer points to the object
that had been copied as well and no longer to the object that was originally
referenced.
copied, but it is precisely the referenced base object that can be found
from the target. The pointer is retained and after the copying operation
continues to point to the original object.
re b) Comos searches for the base object in the following sequence:
1) The base object is part of the amount of copied objects.
2) Alternatively, the target project is searched for the base object.
3) Alternatively, a search is made in the base project of the target project
for the base object.
– c) The copying function is blocked if neither a) nor b) is possible. As an
example, the case of the base object pointer:
The base object pointer reveals on which base object the planning object
is based. A precise object allocation follows; simply having the same
name is not enough:
Pic. 8-7: Prerequisites for “simple copying”: same base objects

In the left-hand case the “simple copying” was successful: the base
objects are identical because both projects point to the same base project.

In the right-hand case Object A from project HKS 51 could not be

copied into project HKS_new because HKS_new has another base
project S01_new . It is true that there is also a Device A base object
there, but this base object only has an identical name; it is not identical to
Device A from S01 .
This copying function is blocked if all the options fail and the base data
pointer is thus lost. In such a case you should use copying across projects, and
perhaps activate the “without references ” option when doing so. This cor-
responds the most closely to the usual impression of what constitutes “simple
copying with a change of project”.
Special treatment of objects:

See SECTION 8.2.1.1: FUNCTIONAL SCOPE
Other
This procedure is not identical with “copying across projects”!
It is not possible to copy across databases.
8.2.2.2 Application
Copying within the Navigator

The Comos clipboard is independent of the project. In other words: an object
in the clipboard is retained even if the project is changed. We can make use
of this effect in the case of simple copying as well:
• Copy an object
• Change the project
• Paste the copied object.
| Move is not available when the project was changed.
Copying with the additional Navigator

The use of the additional Navigator is somewhat more convenient. You do
this by making use of the | VIEW | ADDITIONAL NAVIGATOR command.
The special point to note here: the additional Navigator retains that project
that had been opened previously even with a change of project. For that reason
the following procedure makes it possible to carry out a simple copying oper-
ation from one project into another project:
• Open the source project

Copying Copy structure
• | VIEW | ADDITIONAL NAVIGATOR

• Mark the desired object in the additional Navigator
• Open the target project
• Copy the object in the additional Navigator (which still shows the “old”
project) by means of the Copy mouse menu
• Mark the object, underneath which the copied objects are to be pasted, in the
Navigator that shows the “new” project and select | PASTE.
8.3 Copy structure

With | COPY STRUCTURE an object – regardless of whether it is a base object or
a planning object – is copied into a separate PT Explorer together with its
structure and all the links and is made available there for intermediate editing.
Hence this function has a basic difference from | TEAR OFF: the links, etc., are
not copied over as well when using the latter command.
| COPY STRUCTURE takes time and, above all, memory, since the objects are all
duplicated for intermediate editing. If there are very large amounts of data, it
is better to do without intermediate editing and to select Copy across projects
instead.
8.3.1 Scope of copying

It was explained in SECTION 8.1.2: THE AMOUNT TO BE COPIED that all the copying
functions in Comos possess a common minimum scope of copying (constitu-
ent parts 1., 2. and 4.): everything that was not inherited or referenced is cop-
ied. Inherited information is recalculated on the basis of the new owner.
Handling of references in Copy structure

P-references with a 1-to-1 relation
– Connectors
a) The referenced object is part of the amount to be copied:
The reference is retained, both copies are linked to one another.
copied:

Copy structure Copying
b1) The object is brought over and a projection is possible:

A projection in the target project is searched for on the basis of the
FullName. Connectors are joined at the object to which the projection is
made.
The connectors may not be joined in any other way.
Example 1: Device A and Device B are connected: CP1 with CP1 and
CP2 with CP2. Device A is copied, a Device B is found in the target
project.
This Device B has four connectors, of which CP2 is already being used,
while the other three are still free. The effect: there is no projection
because CP2 is already being used, and instead an attempt is made to
create a new Device B. The name is incremented to prevent a collision of
names (because there is already a Device B in the target project!). Result:
an object Device B_1 is created in the target project.
Example 2: Device A and Device B are connected: CP1 with CP1 and
CP2 with CP2. Device A is copied, a Device B is found in the target
project.
This Device B has four connectors, of which CP4 is already being used,
while the other three are still free. The effect: it is projected. Once the
structure has been copied, connectors CP1, CP2 and CP4 at Device B are
occupied.
b2) The object is brought over but a projection is impossible:
The referenced object is created. The name is incremented if it is not
possible to make a projection because the connectors have already been
allocated.
– Alias pointer
The object that is referenced by an alias pointer can be part of the amount
to be copied if the alias branch was selected by means of multiple
selection.
a) The referenced object is part of the amount to be copied:
The alias pointer is retained, the device points to the copy of the alias
branch.
copied:
The object is searched for in the target project, see SECTION 8.1.3.4:
ALTERNATIVE SOLUTIONS.
The alias object must not have been referenced in any other way than as
an alias.

b2) The object is brought over but a projection is not possible:

The referenced alias object is created. The name is incremented if a
projection is not possible due to the use of an existing alias.
A projection is not possible if no object with a matching FullName can
be found, or if a matching object exists but this object is already used as
an alias object. Please note that in this case the alias object is nonetheless
shown in the additional Navigator for Copy structure as a “projection”.
• All other P-references
– a) The referenced object is part of the amount to be copied:
After the copying operation the pointer points to the object that had been
copied as well and no longer to the original referenced object.
copied:
The object is searched for within the target project, see SECTION 8.1.3.4:
ALTERNATIVE SOLUTIONS.
b2) The object is brought over but a projection is not possible:

The referenced object is created again.
• All base object references
– a) The referenced object is part of the amount to be copied. After the
copying operation the pointer points to the object that had been copied as
well and no longer to the original referenced object.
copied:
b1) The object is brought over and a projection is possible: The base
object is searched for, and the pointer to the original base object is
retained.
Comos searches the associated base object in the following order:
- In the target project.
- In the base project of the target project.
b2) The object is brought over but a projection is not possible: The
referenced object is recreated within the target project as a base object. If
the target project is a planning project, the copy can also be a local base
object.
Handling of references for subordinated objects

S-references are retained.
P-references are lost.

Special points
The Copy structure function contains a number of rules by which the amount
to be copied can be increased. In other words: normally the OwnCollections
alone form the basis for making up the amount to be copied, but an additional
evaluation is made with Copy structure:
• Tracing the connectors
| COPY STRUCTURE automatically traces the connectors.
Example:
A copy is made of object A , which has six connectors, of which four are actu-
ally connected. The connectors that are joined lead to four objects that are
now all included within the extended amount to be copied, either as a projec-
tion or as a new object to be created.
The first of these four objects also has four connectors joined to it. One of
these is the counterpart to object A , but the other three connectors point to
three further objects. Each of these objects is included in the extended amount
to be copied if it has not been included already.
Please note: if | COPY STRUCTURE is included in a quantity of data that is inter-
linked within itself in a complex way, the extended amount to be copied can
be very large.
• BackPointerDevicesWithUnit, BackPointerDevicesWithLocation
The information as to which planning objects (class Device) are joined
within this unit or location. In other words: not only a planning object
“knows” with which unit it is linked; the unit also “knows” which planning
objects are linked with it.
• BackPointerDocsWithUnit, BackPointerDocsWithLocation
As for the previous item, but for documents.
8.3.2 Application
8.3.2.1 Rights that are required

You must have all the necessary rights (read, write, etc.) in the target project
so as to be able to use | COPY STRUCTURE. It is not essential to be logged in as
administrator, but an administrator does of course automatically have all the
rights that are required.

8.3.2.2 Preparing for the copy operation

Call: Mark the object(s) and right-click on | COPY STRUCTURE.
Pic. 8-8: The | COPY STRUCTURE command

Using | COPY STRUCTURE it is possible to copy one or more objects together
with their structure from the marked node downwards and with all the links
into an additional Navigator:
Sub-unit AN1 was marked and copied in the above example. The link to the
R1 and S01 location view are taken over automatically.
Do not use the [OK] command when using | COPY STRUCTURE within
a project! The data must first be subjected to intermediate editing
before you can close the copying operation.
Special preparations for Copy Structure with a change of project

When the | COPY STRUCTURE command is executed it aims at the main Naviga-
tor. If the copying operation is terminated with [OK], the objects are then cre-
ated in the project that was visible at that point in time in the main Navigator.
Thus, this also produces the option to copy across projects:

• Open the source project and then an additional (second) Navigator (by
means of | COPY STRUCTURE).
• Change the project. The additional Navigator retains the “old” project.
• Execute the | COPY STRUCTURE command in the additional Navigator. The
result of the copying operation is executed in the main Navigator - and
hence in another project!
It is still possible to edit the objects before the copying operation is actually
executed, see the following. The changes only take effect once the objects
have been accepted in the main Navigator by means of [OK] or [ACCEPT].
Result of the preparation

The extended amount to be copied is formed out of the result and is trans-
ferred to the Copy structure to... dialog window.
8.3.2.3 Intermediate editing
Automatic intermediate editing: projection

It was explained above in the Purpose section that as much as possible of the
information and properties of the copied object should be taken over when
using | COPY STRUCTURE. At the same time, any existing information should be
used as far as possible.
If Copy structure is executed, the extended amount to be copied is compared
with the current project and all objects that can be allocated by means of
FullName are offered as a projection. If the projection is accepted by the user,
then no new object is created but instead the object that was found is used in
the current project.
Projected objects can easily be recognized by the black arrow in the top
left-hand corner:
A location that is projected. No new object is created when the

copying operation is concluded, but instead an existing object is
used.
A location that is not projected. A new object is created when the
copying operation is concluded.

A projection is thus an item of information during the preparation for copying

that indicates that it is not necessary to create a new object for a reference, but
instead reference can be made to an existing object.
The | RENAME and | DELETE commands are not available for projected objects
because the commands would need to have an effect through the projection
on the existing objects in the stock of data. However, the projection can be
removed manually. A new object would be created without the projection and
this potential object can be edited manually.
Inconsistency check
In Comos there are cases in which 1-to-1 links are absolutely essential: with
connectors, in Comos’s own alias naming system, and in implementation.
Multiple connections could arise if there are inconsistencies, but these are
strictly prohibited.
If there are any inconsistencies, the projection is not totally prohibited, but the
projection is run through first of all. (No objects have yet been copied at this
point in time.)
If it turns out during the actual copying that a multiple connection would be
produced, then the copying action is permitted but a portion of the source
information - precisely that portion of the information that would lead to a
multiple connection - is discarded.
The deleted information is taken into the notification list.
Manual intermediate editing

The projection can be removed manually if you wish to create a new object
regardless:
| DELETE Comos attempts to use existing objects as a template.

PROJECTION Select the | DELETE PROJECTION option instead if you wish
to create new objects.
The new object is given as a default template the name of
the original object. A new name can be allocated by
means of | RENAME. If there is a collision of names, the
object name is automatically incremented when the
copying operation has been concluded.

If a projection is deleted within a hierarchy, then logically enough the projec-

tion is deleted for all the objects lying underneath it. When the projection is
deleted, a new object is created - and hence a new branch in the tree structure!
Since the branch is new, there cannot be any existing objects beaneath it onto
which it would be possible to project.
If, nonetheless, you wish to use an existing object but not the object
that was offered automatically, you can still change the projection
by means of drag & drop.
For example, you simply drag a new location onto S1 . The result is that the
object of the extended amount to be copied is displayed and in addition also
the projection that was set manually:
Object S1 is projected onto S6 .
This also makes it possible to reduce the number of hierarchical levels (reduc-
tion of levels).
Example: in the extended amount to be copied there is an object that had orig-
inally been located on the fifth level of the structure tree. A projection is set
onto an object that is on the third level by using drag & drop.
However, the relative ordering of the levels must still be retained; if the object
related to another object that was higher up in the hierarchy, the other object
is not allowed to be at the same level or at a lower level in the hierarchy as a
result of the reduction in levels.
From a technical point of view, this means:
A reduction in levels (the removal of objects) is only permitted if during the
preparation for the copying there are no other objects located on that level and
there are no pointers referring to them.
This sounds complicated, but it is simple enough in actual practice. If two
projects have been set up in a very similar way, but an additional folder level
was incorporated in the source project, for example, then all objects in the tar-
get can “move up one level”. All the relative superordinated and subordinated
relationships are still retained in this case.
The original projection to the existing object S1 can no longer be reproduced
automatically. In other words: the automatic projection is carried out just once
and at that very moment, since the extended amount to be copied is transferred
to the Copy structure to... dialog window.

Of course, a manual projection can be carried out by using drag & drop, and
this has the same effect. But if the user has done considerable editing after-
wards in the case of an automatic projection, it is necessary to bear in mind
that you cannot lightly discard all the changes that have been made and go
back to the initial state.
A number of further editing commands are available for all objects that are
not projected – and hence also for all objects for which the projection was
removed manually.
The simplest form of post-editing is a change of name:
| RENAME The name for the newly created object. If there is a

collision of names, the object name is automatically
incremented when the copying operation has been
concluded.
An object for which there is a projection cannot be
renamed. First of all the projection must be removed,
and then a new name can also be input for the object
(which as a result is created as new). See below for
more regarding the topic of “projection”.
A further form of editing could be to manually exclude specific information

from the transfer:
| DELETE The object is deleted (not created). If the object on

which the | COPY STRUCTURE command was used is
deleted, then copying does not take place.
The command is not available for objects that have
been projected.
Please note that it is not possible to delete an individual reference.

When you call up the context-sensitive mouse menu at a reference
and select the | DELETE command, then not only the marked refer-
ence but also the referenced object is removed. Consequently all the other ref-
erences that had pointed to this referenced object are lost as well.
It is left entirely up to the user to reject all intermediate editing done to date
and to call up Copy structure again.

Copying across projects Copying
8.3.2.4 Concluding the copying operation

Confirm with [OK] or [ACCEPT].
Objects that are not projected are created as new. If necessary, further objects
are created, including the relevant hierarchy as applicable.
8.3.3 Special cases regarding projections and prohibitions on

projection
The subordinated objects are likewise projected by a projection. Normally the

name, path, system type and class are used as comparison criteria: projection
is as a rule possible if there is already an object with precisely these criteria.
• Elements
In the case of DeviceClassElement (e.g., terminals) the next free element
with the same prefix is searched for and projected instead.
Rules for objects that cannot be projected:

• Objects that are to be projected must be of the same system type and must
have the same device class. In addition, they are also not allowed to have
been inherited; this can primarily be the case with elements and attributes.
A projection cannot be made if these conditions are not met; a new object is
created in such a case. (At the moment the Copy structure function only
works with structures that have not been inherited.)
• Elements placed on documents cannot be projected, i.e.,
DeviceClassElement with BackPointerDocObjs is not empty.
• Special case: It is not possible to project in the case of planning objects if
the BackPointer-DevicesWithImplementation collection is not empty. In
this case the implementation pointer is set to construct special points in
planning technology. Example: routes.
• Planning objects with joined connectors cannot be projected.
Exception to the exception: planning objects with detail class Potential .
8.4 Copying across projects

Copying across projects is intended to completely copy all Comos objects –
in other words, including all references, connections, sub-structures, etc., –
within a database from one project into another project. The type of the
project is completely unimportant: it is also possible to copy across project
types, in other words, from a template project into a planning project, etc.

Copying Copying across projects
Copying across projects cannot be used within a project, it is necessary to

change the project.

functions in Comos possess a joint common minimum scope of copying (con-
stituent parts 1., 2., and 4.): everything that was not inherited or referenced is
copied. Inherited information is recalculated on the basis of the new owner.
Restriction: the following objects cannot be used as the source:
• DocObj
• Spec
• Connector
In other words, you cannot explicitly drag an attribute into the Source field.
However, these exceptions also only apply to the starting point; these three
object types can of course be copied as well in the case of all subordinated
objects.
Handling of references when copying across projects

Projection for referenced objects: Copying across projects uses projections,
just as the Copy structure function does. However, this projection is not visi-
ble when copying across projects and also cannot be set again by drag & drop.
However, there is nonetheless a somewhat restricted alternative way to edit
projections, see SECTION 8.4.2: APPLICATION.
See SECTION 8.3.1: SCOPE OF COPYING.
Deviations:
– Alias pointer
The object that has been referenced by means of the alias pointer can
never be part of the amount to be copied. Reason: the alias branch is
directly underneath the project. It is not permitted to copy the project
itself by means of copying across projects and multiple selection is also
not possible. Thus it is not possible to set up an amount to be copied that
has both a device branch and the alias branch as well.


Handling of references from objects brought over

References in objects that are brought over are retained and bring over addi-
tional objects.
Special points
The structure of the source project from the project root (the globe) up to the
marked object can be reconstructed in the target project with the aid of the
automatically create hierarchy option.
Difference from Copy structure:
In the case of Copy structure the hierarchy is reconstructed first of all. The
levels can be matched by using drag & drop.
It is not specifically possible to match the levels when copying across projects
because the intermediate processing function is highly restricted. You only
have the choice to select the marked target object as the target (i.e., the objects
are copied to underneath this target object) or to completely reconstruct the
hierarchy to be the same as it was in the source.
8.4.2 Application
1. Called up through the | EXTRA menu.

2. The starting node is dragged from the source project into the Source field
using drag & drop in the opened dialog window:

Copying Copying across projects
Pic. 8-9: The project window for copying across projects

Please note that only the new object hierarchy is supported! The object
types Unit or Location that may have been used in old databases are not
supported.
You also cannot set the project (the blue globe) as the source. In that case
a complete project would be copied under a project, which is technically
not possible because projects are not hierarchically sub-divided of
themselves.
3. Intermediate editing
When the copying operation is initiated, a search is also made for
projection possibilities (see SECTION 8.1.3.4: ALTERNATIVE SOLUTIONS
regarding the search criteria). Thus if the name of an object in the
extended amount to be copied has been changed, the projection will be
done as well onto another object.
It is possible to change the name during the intermediate editing.
This is done by dragging any desired object of the source project into the
left-hand lists window. The previous name appears in the Name field
when the object in the lists window is marked. The old name can now be
overwritten and the entry can be checked in the lists window: column
Name (old) = original name, Name (new) = name that was entered. The
object is projected with the new name.
If a unit possesses a location pointer, you can thus drag the location into

the left-hand lists window and input a new name. However, you need to
already have the information as to which objects are referenced and what
the reference targets are called, because this information is not shown in
the Copying across projects dialog window.
If a projection is not possible, the object is of course created with the new
name.
In other words: objects can either be projected differently or renamed
with the aid of intermediate editing.
4. Setting the options:
– Object
The sub-area from the source project is copied directly underneath the
target object.
or
– automatically create hierarchy
The structure is created in the target project just as it is in the source
project and the objects are correspondingly appended to the source
project.
– without references
If activated: all references that relate to planning data (in the introduction
these were called “P-references”) are lost during the copying operation.
These include, for example, the unit pointer and the location pointer.
References to the base data (in the introduction these were called
“S-references”) are retained. These are thus the pointer to the base object,
references to base lists, etc. Please note: in principle this loss of references
always relates only to “references pointing outwards”.
5. The target project is now opened and the target node is dragged into the
Copy under field by means of drag & drop.
6. The copying operation is started by pressing the [EXECUTE] button.
The message “The copying operation has been completed” is shown
when the copying operation has finished, and this message must be
confirmed with [OK].
7. The dialog window remains open. The copying operation can be repeated
or a new target node can be set.
8. The process can still be cancelled with [Cancel]. The objects that had
been displayed in the Navigator are deleted again.
The new structures that have just been created (the first branch of the objects
that have been brought over) are displayed in the right-hand list window.

Copying The Object Matcher
8.5 The Object Matcher

The tasks of the Object Matcher: comparing and copying
The Object Matcher compares two sub-trees in different projects. Differences
(object only in the source, object only in the target, object differs in the source
and target) are always resolved in favor of the target. In other words: only the
target project is changed, while the source project remains unaltered.
8.5.1 Explanation of the interface
Call: | EXTRA | OBJECT MATCHER
The buttons at the top have the following functions:
Set target project Transfers the project from the Source project
and source field into the upper Navigator and the project
project in the tree from the Target project field into the lower
Navigator.
Start object The allocation and comparison of the objects is
comparison done. No data has been changed yet.

The Object Matcher Copying
Filter setting for The filters affect which objects are allocated
the object and compared. No data has been changed yet.
comparison
New start Deletes all fields in the dialog window. The
effect is the same as if the dialog window had
been closed with [CANCEL] and then reopened.
To the next Navigate to the next object difference
difference
Option “Display with inherited objects”

Comos has a number of different methods to transport information from one
object to another, and these also include inheritance through references. A ref-
erence object itself cannot be edited but is only used to collect information and
to pass it on to the original object. Let us look at an example:
Pic. 8-10: The amount to be compared also contains a reference

Result starting from the start node and target node (@1EA in each case):
Option is activated Option is deactivated

Object A on the left is flagged as Object A on the left is flagged as
“the same” as object A on the right. “the same” as object A on the right.
Table 8-11: The effect of the “... with inherited objects” option

Option is activated Option is deactivated

Object B on the left is flagged as Object B on the left is flagged as
“different” with regard to object B “the same” as object B on the right.
on the right.
Object C on the left is flagged as Object C on the left is flagged as
“different” with regard to object C “different” with regard to object C
on the right. on the right.
Table 8-11: The effect of the “... with inherited objects” option
The difference between the two displays thus only affects object B.
Both displays are correct in themselves. Technically speaking, the change in
data takes place at object C, which is also correctly flagged as “different” in
both cases. The change at object B is “only” a consequence of the change at
object C.
It is thus as a rule a good idea to do as follows when carrying out data match-
ing at object C: either take over or delete the reference at object C. Recom-
mendation: the “with inherited objects” option should be deactivated.
But object B also changes from the point of view of the user, since in the one
case it displays the attributes of object C and in the other case it does. How-
ever, the display with inherited objects could lead to a situation that could
cause problems: a user might get the idea of checking in and editing the inher-
ited attributes at object B and thus make the data match that at the other object
B. This is not recommended because the cause is, as described above, to be
found at object C.
Comparison list, detail display

The upper right-hand dialog area of the Object Matcher is the “results area”
in which are listed the objects that differ between the source node and the tar-
get node.
The lower, right-hand dialog area of the Object Matcher is the “detail display”
where all the differences from the above marked object are listed.


functions in Comos have a common minimum scope of copying (constituent
parts 1., 2., and 4.): everything that had not been inherited or referenced is
copied. Inherited information is recalculated on the basis of the new owner.
Extended object quantity

There are various items of information that must or should apply in the same
way throughout the project for all users: standard tables, unit systems, and so
forth.
Since this information should apply throughout the project, it is appended in
the information hierarchy directly underneath the project. It makes no differ-
ence whether you now name and display this information as a “table” or as an
“object”, the principle is always the same: a summarizing of information that
is to be applicable throughout the project. If you wish, we could also talk of
containers.
In many of the dialog windows this information is displayed in the form of
“tables”. But please note that it is not necessary to display this as a table, it is
simply more practical on some occasions.
All this information has one feature in common: it is managed by the admin-
istrator; normal users simply use this information without needing to know
exactly where this information is located and how it is to be edited.
For that reason this information is not displayed in the Navigator.
This information is collected in the Object Matcher. In other words, the
Object Matcher displays more than does the Navigator. Thus the display is
selected as an object. But do not be confused by this: if something is also dis-
played as an object within the Object Matcher, then it is for example still
exactly the same unit system that perhaps you had edited a few minutes earlier
as a “table”.
Handling of references in the Object Matcher

Projection for referenced objects: a projection is made when using the Copy
structure function. There is a similar mechanism in Object Matcher, but as
opposed to the Copy structure function this projection is not visible and also
cannot be set again by using drag & drop.


Handling of references from objects that have been brought over

References for objects that have been been brought over are retained and
bring over additional objects.
If a report is copied into another project, the planning objects that have been
placed on this report are always brought over. (From a technical point of view:
DocObj.Reference is brought over.)
Special point
It is also permissible to view the project in the Object Matcher. This allows
the project to be copied. Please note, though, that projects cannot be located
under other projects. In other words, the copied project is not inserted into the
target project, but instead the target project is overwritten.
8.5.3 Mode of functioning
The allocation and comparison of the objects is done from the start node
onwards (including the start node itself and all objects located underneath it).
8.5.3.1 Color scheme

The Object Matcher not only possesses the most comprehensive filter func-
tion of all anywhere within Comos. In addition to that it can compare the
source and the target of the copying operation beforehand and display the dif-
ferences in colored form in a structure tree.
The colors of the objects have the following meaning:
Red Object only exists in the target project (allocation level)

Green Object only exists in the source project (allocation level)
Yellow Objects differ (comparison level)
Blue Object differences in the sub-structure (comparison level)
Grey Objects are largely the same. (comparison level)

8.5.3.2 Allocation of objects

1. The allocation as to whether two objects are to be compared is done on
the basis of the name.
2. In addition, the class is taken into consideration in the case of planning
objects.
3. If a name differs, the hierarchically subordinated objects are no longer
allocated.
The situation in the illustration above produces the following:

– Despite differing names in the start nodes (@1EA and @1EA_new ),
object Lamps from the left-hand side is allocated to object Lamps from
the right-hand side.
– At the next level 12V_Lamp from the left is allocated to 12V_Lamp
from the right
– Despite differing classes (left: Devices, right: Element), both the
20V_Lamps are allocated
– The Indicator from the left is not allocated to Indicator_new
– Consequently the Bell and the Gong are no longer allocated, although
the name and the hierarchical level would match.
8.5.3.3 Comparison of objects
What does “the same” mean?

Within Comos objects are uniquely identified by means of the UID. In other
words: in Comos there are two objects that are identical in terms of all their
properties, collections and links, but nonetheless they cannot simply be
swapped with one another. The UID makes each object as unique and unmis-
takable as does the genetic fingerprint of a human being.

The Object Matcher does not take the UID into consideration, otherwise
objects would always be regarded as being different.
Often you can tell immediately at a glance why two objects are flagged as
“different”. Sometimes the reason for the difference may be hidden more
deeply. The following explains all the situations that lead to differences.
1. Comparison of the properties:

Properties always contain a single item of information and only relate to the
object itself. Each property has a data type.
An example for a property of this type is the label that had been input for an
object. The data type is thus a string. A string of this type can be compared
easily and each difference leads to the two objects being flagged as “differ-
ent”. This also corresponds to the intuitive understanding of the user: if the
labels differ in the case of two allocated objects, then the objects are also to
be flagged as “different”.
But the settings for options and switches are also saved and compared as prop-
erties. As a rule the data type here is Boolean (yes/no). If the Request option
has been activated for a base object and not for the allocated second object,
then both objects are flagged as “different”.
In addition, there are properties that serve for a sequencing, sorting or func-
tional labeling. An example of this sort is the status. This information is saved
as data type Long. If different status information had been input for planning
objects (the first object is “open” and the second one is probably “closed”),
then both objects are flagged as “different”.
The last group of properties is made up of pointers (= references), for exam-
ple, a unit pointer or a location pointer. These pointers are of data type Object
and therefore cannot be directly compared with one another in a meaningful
way.
Helpfully, the FullName of the referenced object is queried from the source
and the FullName is also determined from the referenced object in the target.
The FullName is a string, which means that two strings are now available and
these can be compared.
Please note: the name of an object is only a part of the FullName! For this rea-
son references can also be characterized as being different even if the names
themselves are identical. The following example makes this clear:

The situation in the illustration above is as follows:

First of all the data was created as shown on the Units tab and the Locations
tab. The project was copied, so all the information was taken over one to one.
Then a NewLevel object was created on the Locations tab and RoomA was
moved to there. In other words:
• The Transformer object was not changed.
• The RoomA object was not changed, only moved.
• The Transformer pointer to RoomA was retained, correctly (Comos
default function: moving an object has no effect on the pointers).
– When the situation on the right is checked against the situation on the
left by means of the Object Matcher (the start node in each case is object
UnitA ), the left-hand Transformer object is flagged as being “different”
from the right-hand Transformer object.
The reason for this: in the situation on the left the RoomA object has the
FullName “RoomA” and in the situation on the right the RoomA object has
the FullName “NewLevel|RoomA”. This FullName is a constituent part of the
properties of the Transformer object! Thus there is a difference in a property
of both Transformer objects and they are flagged as being “different”.
This auxiliary construction has a further effect that tends to be undesirable in
practice but which is unavoidable from a technical point of view:
• If the pointer goes to an object that is located relative to the starting object
both in the source and in the target as well,
• and the start nodes are different, then

• the FullName of the referenced objects is different and the starting objects
are flagged as being “different”.
Recommendation: the names of the source node and the target node should be
the same, otherwise a reference that is pointing outwards cannot be allocated
meaningfully. The exception to this is the project itself; this should in any case
be different.
2. Comparison of collections
There are different types in the case of collections as well. The basic princi-
ples are:
• Collections that are regarded as “belonging to the object”
Examples in the case of the planning object: attributes or connectors. This
information is displayed in the lower window area when the object is
marked above.
• Collections that are treated as a collection of “independent objects”
Examples in the case of the planning object: elements, documents. These
objects are displayed in the structure tree in the upper window area.
The collection of attributes will be taken as an example from the first group,
“collections belonging to the object”. Objects are flagged as “different” in the
collection if:
• an attribute has been renamed.
• the contents of an attribute have been changed (Value or OwnValue).
• the data type of an attribute has been changed.
This case is partially one that cannot be seen at first glance! A ‘zero” can be
input either as a number or as a character; in both cases only a “0” is to be
seen, but the attribute is different!
• The position of the attribute on the tab is moved.
• An attribute is deleted or added.
• And all other properties.
The objects of the second group – collections of “independent objects” – are

displayed in the upper window area and are completely compared again. In
other words: if a difference is found in an object of this collection on the basis
of the above rule, then the “parent object” of the collection is flagged as hav-
ing a “difference in the sub-structure”.

8.5.3.4 Summary of the main points
Important rules concerning object allocation:

The allocation of objects is done by means of the name per level.
If a name has been changed, then one object is flagged as being
“only in the source project” and the other one is flagged as being
“only in the target project”.
In other words: the inner relationship of the objects is lost. (If you do require
an absolute allocation of objects, for example with distributed databases, you
then have to resort to the “synchronize databases” function, see SECTION 3.3.3:
CREATING THE SYNCHRONIZED COPY (EXPORTDB). Allocation through the name is
not resistant to moving, meaning that if an object is moved to another level,
no allocation is done any longer (in each case relative to the start node).
Colors: red and green
Important rules concerning object comparison and matching

Properties are compared precisely, with the exception of pointers
(see the next section). In other words: even if just one single prop-
erty changes, the object is flagged as being “different”.
Color: yellow
Pointers or references (special type of a property) are compared
through the FullName of the referenced object. Moveing has the
effect that the FullName of the pointer changes, thus a property of
the two comparison objects differs objects and the objects are
flagged as being “different” in the Object Matcher.
Color: yellow
Collections that are regarded as belonging to the object are com-
pared completely. In other words: if a characteristic in such a col-
lection changes even minimally, the object is flagged as being
“different”.
Color: yellow

Collections that are treated as a collection of independent objects

are assessed in two stages:
In relation to the “parent object” of the collection: if a member of
the collection is renamed, if the collection is made larger or
smaller, the “parent object” is flagged as having a “difference in
the sub-structure”.
Color: blue
The objects of the collection appear in the structure tree in the
upper window area and are compared completely. Here the mech-
anism begins again.
Color: yellow, blue or grey, depending on the difference from the
target object
8.5.3.5 Special case Documents

In the case of reports the contents are only partially compared: only that infor-
mation is compared that has an effect in the object model. Graphic elements
(lines, circles) are only stored in the crp file and are not taken into consider-
ation when comparing two objects.
Please note that DocObjs tell the documents which objects have been placed
on them. How DocObjs of this type are treated during the copying operation
primarily depends on the mode.
However, the effect of the mode only applies when copying is actually done.
In other words: an amount of data can be flagged as being the same in the
Object Matcher, but small differences may appear nonetheless after the copy-
ing operation, depending on the mode of the DocObj.
8.5.4 Application
Compare objects from different projects

1. Set the source project and the target project
Select a source project and a target project from the drop down menu.

2. Take over the project
Display the projects in both Navigators:
3. Set the start node

Once the projects have been set, the character of the two dialog fields Source
object node and Target object node changes.
Using drag & drop you can pull a start node from the upper Navigator into the
Source object node field and a target node from the lower Navigator into
the Target object node field:
As opposed to step 1: “set source project and target project”, the two fields
can now also be used with drag & drop for all further Comos objects. For
example, an object from the main Navigator can be dragged into the applica-
ble field or a standard table from the Standard tables dialog window .

Note carefully when doing this which project is open right then! If project
HKS 51_1 was open at that moment, then in the above example you also only
could fill in the Target object node field from the main Navigator or from
the Standard tables dialog window (or other dialog windows). Change the
project if this is necessary, the Object Matcher dialog window will remain
open.
Any object can be dragged from either Navigator within the Object Matcher
without needing to change the project as well.
Once the start node and the target node have been set, the two buttons Start
object comparison and Filter settings also become active.
4. Filter settings (which objects are to be compared)
The filter settings are more comprehensive than elsewhere within in Comos.
Among other things, objects are offered that are not visible in the main Nav-
igator.
It is important to emphasize at this point that not all the information (objects)
that is managed within Comos is also displayed within the main Navigator,
since otherwise the display would become too cluttered. An example of that
concerns objects that are located hierarchically underneath the project: stan-
dard tables, unit systems and so forth.
The Object Matcher makes it possible to compare and reconcile all objects,
and consequently an extended form of display is required within the Object
Matcher. In other words: the Object Matcher displays more than does the
main Navigator. You can stipulate in detail in the filter settings what is not to
be compared (and hence also not displayed):
The classes for the “planning object” object are displayed on the left-hand
side. If the option for planning objects has been deactivated on the right, then
all the classes on the left are deactivated automatically.

The system types are displayed on the left-hand side. The following list
explains a number of important system types:
Object (system Icon Comment

type)
Planning objects This includes all classes of planning objects;
these are the objects on the left-hand side of
the filter settings. If system type Planning
objects has been switched off, then links of all
classes are deactivated automatically.
Base objects The term “base object” is used here in the strict
sense and only applies to system type CDevice.
Documents This class of an object only makes sense if
(links) base data is compared, since there this class
bears the attributes for documents.
This class cannot be used in a meaningful way
with planning objects.
Do not confuse with system type Document of
a planning object (shown on the right-hand
side)! These are the “actual” documents.
Standard tables Directly under the project; not displayed in the
main Navigator and the two Navigators to the
Suppliers/ left in the Object Matcher. In other words, this
manufacturers object is exclusively to be seen in the “results
of the object comparison” area.
Unit group
Run cases
Languages
Parameters
Document types
Table 8-12: Objects in the filter settings

Start comparison
Pic. 8-13: Start object comparison

The results of the comparison are mainly shown in the upper windows, and to
some extent also in the lower window. The following appears at the bottom:
• In all objects: own attributes
• In all objects: own connectors
• DocObjs
• Values of the standard tables (Standardvalues)
• Standardvalues: symbols for planning objects (DevSymbols)
• Base objects: own symbols (OwnDevSymbols)
• Base objects: own suppliers (OwnSuppliers)

The result could look like the following, for example:
• Objects that only exist in the source object or target object are displayed
without any further functionalities in a list line. These lines also do not have
an icon at the start of the line.
• Objects that exist in both branches but which differ are identified as such
with the aid of an icon at the start of the line. If this involves attributes or
connectors, you can open an additional information window by
double-clicking or from the | DETAIL DISPLAY context-sensitive mouse menu:
All the properties that have been changed are listed in the Object differences
dialog window in the same way as for control properties (graphic properties)
that have changed. Sometimes black and white arrows are shown as well. The
white arrow stands for a property that is checked in, and the black arrow for
an inherited one.

If you wish to see the detailed view for another object, leave the details win-
dow open and simply double-click on the other object. Effect: the contents are
swapped in the detail window that is open.
Editing data: reconciliation

Differences (object only in the source, object only in the target, object differs
in the source and the target) are always resolved in favor of the target. In other
words: only the target project is changed, while the source project remains
unchanged.
You have two options:
• you can edit the differences individually, or
• you can make a global reconciliation for the entire amount of data being
investigated.
8.5.5 The mouse menus
The mouse menus reconcile the differences individually. The mouse menus
are called up by right-clicking, whereby only that subset of commands is vis-
ible that is also meaningful for this object.
STRUCTURE DIFFERENCES The information of the source project is taken

-> TARGET PROJECT over for the marked object and all objects
(WITH DELETION OF THE underneath it. In doing so, all objects that only
OBJECTS AT THE TARGET) exist within the target project in this sub-branch
are deleted.
STRUCTURE DIFFERENCES The information of the source project is taken
-> TARGET PROJECT over for the marked object and all objects
(WITH RETENTION OF THE underneath it. In doing so, all objects that only
OBJECTS AT THE TARGET) exist within the target project in this sub-branch
are retained.
TAKE OVER OBJECT Takes over the information of the source object
DIFFERENCE INTO THE for the marked object.
TARGET PROJECT
TAKE OVER OBJECT INTO Copies the object from the source project into
THE TARGET PROJECT the target project.
DELETE OBJECT IN THE Deletes the object in the target project.
TARGET PROJECT

NAVIGATE TO THE NEXT Navigates to the next object that is new, was
OBJECT DIFFERENCE deleted, or differs. If possible, the object is also
displayed in one or both Navigators of the
Object Matcher.
This is especially helpful if a difference in the
sub-structure is shown for an object.
COMPARE AGAIN The data can also be edited within the Object
Matcher to remove any differences. New
objects could be produced in the target project
as a result of this editing of the data and hence
also differences could arise that had not existed
at the time of the first comparison. The two
databases to be matched can be processed in an
iterative manner until there are no more
differences.
This mouse menu is identical with what you
would get if you pressed the Start object
comparison button.
Click on the [Match] button for an automatic overall comparison (matching):
Before matching, you still have to choose whether objects that only exist in
the target project are to be deleted:

8.5.6 Controlling the Object Matcher by a script
The “Object Matcher” plugin can now also be controlled through a script
(properties and methods). However, please note the order:
,source object and internally the source project is set
Public Sub Let Source (Byval vNewValue as Object) ‚
‚target object and internally the target project is set
Public Sub Let Destination (Byval vNewValue as Object)‘
‚set the FilterMatchOption, however, after that the matching process always
needs to be restarted
Public Sub FilterMatchOption (ByVal MatchOption as String, ByVal
Dummy as String, ByVal NewValue as long)
E.g.: FilterMatchOption “ “ Specifications””, ““““, 0 => attributes are not
matched as well.VNewValue = 0 or 1
OptionStrings:
“DocObj” = DocObj
“Specifications” = attributes
“Connectors” = connectors
“Symbols” = symbols
“Documents” = documents
“CDevices” = base object
“Devices” = planning object
“Cases” = run cases
“Company” = supplier / manufacturer
“DocumentTypes”= document types
“Language” = language
“Parameters” = parameters
“StandardTables” = standard tables
“PhysUnitGroup” = unit groups
“Device. Unit” = unit references
“Device. Location” = location references
“Device. Alias” = alias references

Comparison of copying methods Copying
“Device. CDevice” = CDevice references

“Device. Implementation” = implementation references
‚Start matching operation:
Public Sub Match ()
‚interface display with ProjTrees or only with MatchTree
Public Sub OnlyMatchTree (ByVal ShowMode as Boolean)
8.6 Comparison of copying methods

If the referenced object is not in the amount to be copied, then...
“Simple Copy structure Copy across Object Matcher
copying” projects
X X X X
Lists, tables, Extended Some objects as Extended

unit systems: object amount: not permitted as object amount:
Not through the connector root. lists, tables,
Navigator, tracking, some unit systems
but in dialog BackPointer
windows collections
(X) X X X
Base object (otherwise (otherwise (otherwise

pointer is created) created) created)
searched for.
Base object pointers
The copying
operation is
(S-references)
blocked if the
pointer to this
precise object
cannot be
retained.
Table 8-14: Quick overview of copying methods

Copying Comparison of copying methods

copying” projects
– X X X
Connector reference
(connections)
– X X X
Alias functional
scope
– X X X
Planning object references (S-references)
Project not The unit to which The unit to which The unit to which
changed: the pointer points the pointer points the pointer points
is retained is searched for on is searched for on is searched for on
Project changed: the basis of the the basis of the the basis of the
e.g., unit or location pointers
is lost FullName. If the FullName. If the FullName. If the

unit is not found, unit is not found, unit is not found,
it is created. it is created it is created
The result (incompletely). (incompletely).
initially appears
in an additional
Navigator for
intermediate
editing.

Comparison of copying methods Copying

copying” projects
(X) X X
References in the case of objects
There are no P-references Are retained and Are retained and

that have been brought over
objects that have are lost bring additional bring additional

been brought S-references objects over. objects over.
over. are retained
– X X –
hierarchy
Create
X X X X
DocObj DocObj DocObj DocObj

depending on depending on depending on depending on
mode. mode. mode. mode.
-> Effect on
DocObjs
“sameness” of
data after the
copying!
– X – –
selection
Multiple
Only apparently!
X – X –
Quick
– X (X) –
mediate editing
Manual inter

Copying Other sections of interest regarding copying

copying” projects
(X) X X X
Rights query
at the target
Create All rights are All rights are All rights are
required; but not required; but not required; but not
necessarily necessarily necessarily
Admin Admin Admin
Revisions are Dialog window Dialog window

deleted. remains open remains open:
Special
both allocation
points
and object
matching
8.7 Other sections of interest regarding copying
8.7.1 Copying system projects

The system project contains lists and information that runs across projects. In
particular this also applies to the underlying lists that are required for Comos
to function and which are supplied as standard with it.
In SECTION 3.5: COPY SYSTEM PROJECT you can find all the relevant information on
how you can copy a system project.

Other sections of interest regarding copying Copying

Deleting
9 Deleting
ing.

Deleting

Display in the Navigator Using the Navigator
10 Display in the Navigator
10.1 Using the Navigator

The Navigator has four tabs (settings: Units , Locations , Documents , Base
objects ) in the header area, and underneath there is a Navigation and filter
bar. Most of the structure area is taken up with the display of the tree structure,
and the detail windows appears underneath it, if it has been activated.
Please note that only those objects for which you have read rights are visible
in the Navigator.
10.1.1 Navigation and filter bar
This drop-down list displays all owners of the

current marked object.
In other words: Here you can see all the interme-
diate levels that are on the way from the top level
down to this object. Simply mouse-click on an
entry in the drop-down list to display the corre-
sponding object in the Navigator. Each tab has its
own drop-down list that is managed separately.
Anchor (also called Root-Filter)
and
Definition: A filter is set as a new starting point for the tree structure for the
object that is currently marked within the Navigator.
Effect: Within the Navigator only those objects that lie underneath this start-
ing object are still visible. If the filter has been set, the question mark is
replaced by a lightning flash symbol.
You can input an object as an anchor by:
• marking the object in the tree structure.
• left-clicking on the Anchor symbol.
Each tab has its own Anchor filter that is managed separately. Left-clicking
once again deactivates the filter.

Using the Navigator Display in the Navigator
Once you have set an anchor, all the

superordinate objects (“owners”) are
then displayed in the drop-down list:
If you select one of these superordinate objects, this is used as the new anchor.
Pick list
Definition: The pick list is used to quickly find objects again within
large projects. A function of this type is often called a “bookmark” as well.
Each of the four tabs has its own pick list that is managed separately.
Effect: If you mouse-click on an entry in the pick list, the corresponding
object is shown in the Navigator. The pick list contains the last ten objects that
had been pasted.
You can input an object into the pick list by:
• marking the object in the tree structure.
• left-clicking on the pick list symbol.
• Select the | CURRENT OBJECT... ACCEPT context-sensitive mouse menu.
Drag & drop with the Navigation and filter bar

Using drag & drop, you can drag an object into the Combo box or onto the
Anchor icon or into the pick list.
Combined functions in the filter bar

• If an anchor has been set and you select an object from the pick list, this pick
list object automatically becomes the new anchor as long as it is not in the
visible part of the sub-tree.
• If you left-click on the [+] field while holding down the [SHIFT] key, the
object is set as the anchor (= root object) and the branch is opened. Ensure
that you actually mouse-click on the [+] field, because mouse-clicking on
the text behind it is not sufficient!
• If you try to click on an object that is outside the anchored area for reasons
of navigation, the anchor is removed automatically.
(Background information regarding Navigation: In the context-sensitive
mouse menu there is a | NAVIGATION menu for all objects. This menu lists
those objects that have a relationship to the current object. If you mouse-
click on one of the entries in the Navigation menu, the corresponding object
is searched for and displayed within the Navigator.)

10.1.2 Navigator settings
Right-click on the white background of the Navigator to get a menu.
10.1.2.1 “Settings” command

Right-click in the white area: | SETTINGS
The Navigator settings dialog window opens.
Display
Here you can set what is to be displayed in the Navigator in the upper part and
in the lower part, or whether nothing at all is to be displayed.
General
Directly edit new objects
If this has been activated, it opens the Properties window for all new objects.
The option is also evaluated if objects are created as planning objects by
means of drag & drop.
Otherwise the object is created with an automatically-generated name.
Save automatically
Activated: Objects are saved automatically.
Not activated: Right-clicking in the white area of the Navigator opens a con-
text-sensitive mouse menu that gives you the option to save.
Sort alphabetically
Objects are sorted alphabetically within the Navigator.
Sort “folder” objects is ascending order
Objects with the “Folder” property are shown at the top in the tree, and only
then those objects without this property are displayed. This form of display is
thus similar to the default form of display in Explorer, which also displays the
folders first.
See SECTION 12.2.6: EDIT GROUP “OBJECT BEHAVIOR” concerning the “Folder” prop-
erty.
Tabs
Here you can set which tabs are to be displayed and whether the detail win-
dow should be visible.
10.1.2.2 “Status display” command

Right-click in the white area: | STATUS DISPLAY.

The Navigator is switched over to status display and the objects are displayed
in color. The color symbolizes the status level for the selected type of status.
See SECTION 21: STATUS MANAGEMENT.
10.1.2.3 “Symbol preview” command

Right-click in the white area and select: | SYMBOL PREVIEW.
This activates an additional window in which the symbol of the Symbols tab
for the currently selected object is displayed. The symbol preview starts with
the drawing type of the report that had been opened most recently, and the
default is “DETAIL ”. The symbol preview functions for:
• planning objects (Device)
• base objects (CDevice)
• base objects with template.
If a base object on the System tab in the Template field possesses a link,
then you can use the symbol preview with this base object.
• the entries in the mouse menu | New, and
• for the symbol bars.
• The *V*P S: and *V*P E: texts are evaluated as well.
10.1.3 Arrange tabs
If you right-click on the tabs of the Navigator, you are offered a number of
different options to make settings.
If you select Horizontal or Vertical , you are only offered two of the four tabs
and can determine by mouse-clicking again which of the tabs are to be dis-
played.
10.1.4 Mouse operation within the Navigator
Select
Objects, documents, attributes, etc., can be selected by marking so that they
can be moved or printed or made the object of other actions. This is possible
both for individual and multiple objects.
In the usual way as elsewhere in Windows, the extent of the marking and the
unmarking (selection and deselection) can be controlled precisely by using
the [Shift] key and the [Ctrl] key.

In the usual way as elsewhere in Windows, the Navigator decides whether an

object has been selected.
• Selection
Object selected by mouse-clicking
(blue marking.)
• Single selection
Select a single object by [Ctrl] +
mouse-clicking
(Grey background behind the icon and blue marking.)
You can of course select more than one object at a time:

• Multiple selection
Select multiple objects by [Ctrl] +
multiple mouse-clicks
(Grey background behind the icon and the texts; the last object that was
clicked on is marked in blue.)
If a selection has been made, no other object can be moved by drag & drop.
First mouse-click on an object in the Navigator to clear the selection, and then
the selected object can be pulled by drag & drop onto a diagram, for example.
Double-clicking
Double-clicking within the Navigator without opening of the Properties win-
dow: The double-clicking opens the Properties window of the object.
Double-clicking within the Navigator with opening of the Properties window:
The data of the new object is displayed in the Properties window.
Double-clicking on a document opens the document.
Navigation
If you right-click on an object, you are offered the | NAVIGATE... menu. The
commands in the | NAVIGATE... menu vary according to the object that was
marked.
| NAVIGATE...
| ORIGINAL
Jumps from a reference to the object that was referenced.

| INHERITANCE SOURCE
This command jumps to the object from which the information had been
transferred: In the simplest case the hierarchically-superordinate object can
also be a base object that has ben set as a “link”.
In the case of referenced objects it is first necessary to navigate to the original.
| BASE OBJECT
Jumps within the planning project in the Base objects tab to the base object.
| BASE OBJECT IN BASE PROJECT
Jumps within the base project to the base object. The base object can now be
edited.
[Name of a unit or a location]
Jumps to a referenced object.
| DOCUMENTS ->
Jump function to the documents on which the object has been placed. The
document is opened and the object is displayed. The document can now be
edited.
| CONNECTIONS ->
In this case a jump is made to the connected device via the connector. This
function is ideal for moving “along” cables.
Base objects: | TEMPLATE
Jumps to the object that had been entered within the base object on the
System tab in the Reference |Template field.
Planning objects: | BASE OBJECTS WITH TEMPLATE
This command only exists for planning objects that are located in the @Tem-
plate branch.
All objects: | INHERITANCE SOURCE
Currently this command is only relevant in the base data view.
Base objects: | OBJECT IN BASE PROJECT
This command is available when you are working within a planning project
on the Base objects tab. If the command is selected, the base project is opened
and the selected base object is displayed.
Documents: | TEMPLATE or | TEMPLATE IN BASE PROJECT
Displays the template in the Navigator.
Documents: | REPORT OBJECT
Each document possesses a “report object”, this being an object to which all
the interactions of the document relate as a starting point. You can now jump
to this report object via the Navigation menu.

Documents: | BASE OBJECT IN BASE PROJECT

The Navigation commands described here represent only a small selection of
all that are available. Depending which object was clicked on, a great many
additional Navigation commands appear, and these are described in the rele-
vant sections of the Comos manual.
Jumping from the Navigator into a report

If objects exist in the Navigator and have also been placed on a report, then
you can jump from the Navigator into the Report.
• To this end the tree underneath the object is unfolded (expanded) in the
Navigator. You can see all the reports on which the object was placed in the
form of document links.
When double-clicking on one of the links in this document, the report is
opened and you zoom in onto the object. The zooming-in is done on the
bounding rectangle plus an outside edge of 2 cm.
• Alternative: use the context-sensitive mouse menu of the | NAVIGATE
| DOCUMENTS object.
10.1.5 Functions of the right mouse button (“Context-sensitive mouse

menus”)
Main commands in the context-sensitive mouse menu of the Navigator

| NEW
Prepared objects are offered here. Exactly which objects are available within
the New menu depends on at which point you activated the menu and what
preparations had been made in the base data.
| CHECK STATUS, | SET STATUS VALUE
See SECTION 21.2: STATUS MANAGEMENT ON THE PLANNING SIDE.
| COPY STRUCTURE
Objects can have a wide variety of relationships to other objects. To put it
another way: your planning data can be linked in complex ways.
The | COPY mouse command views an object by itself in isolation and only
copies the object itself. The | COPY STRUCTURE command views an object as a
part of the overall planning and copies not only the object itself, but also all
the other objects with which it is linked. The structure into which the object
is embedded is thus retained.

| PASTE LINK
A link produces an additional means of access to an object (in the same way
as a link in Windows Explorer). Links can only be set within a project. You
can create a link as follows:
1. copy object,
2. then right-click on | PASTE LINK
If a link is deleted, the object itself and all the other links are retained. If the
object is deleted, all the links are deleted together with it.
| NAVIGATE...
Already explained above.
| PRINT
This command is only available if one or more documents or document
groups are marked. In the case of marked document groups, only those docu-
ments lying directly underneath are printed. Any sub-document groups are
not printed as well. | PRINT includes the following sub-commands:
...| PRINT prints all marked items at the default printer without prompting
...| PRINT... opens the Windows printer selection box.
| TEAR OFF
This command “tears off” one or more portions of the tree structure into sep-
arate Navigators. The sub-sections include the complete structure from the
marked node downwards. All the mouse commands can be used in the torn-
off structure portion.
Please note: You cannot change the settings of the Navigator in the reduced
Navigator window that is torn off. For example, if connectors are shown in
the Detail window of the Navigator, then you cannot see the connectors in
the “additional Navigator”, since there is no detail area there.
| SEARCH
Opens a dialog window to allow you to search for objects.
| PROPERTIES
Opens the Properties window.
| DELETE CONTENT
Only available for interactive reports and only for the original document (not
for a reference).
Warning: The entire contents of the interactive report are irrevocably deleted!

Display in the Navigator Views
The document object with its “Name”, “Description”, and “Template” prop-
erties and the revisions are retained. The graphic contents and all information
as to which objects were placed on the report are deleted. The created objects
themselves are retained, but are no longer placed on the report.
| REFRESH
Only available for the project object. Refreshes (updates) the Navigator dis-
play.
| CHANGE RUN CASE
Only available for the project object. Changes the run case for the project.
Additional context-sensitive mouse menus

The context-sensitive mouse menus described here are only a small selection
of what is available.
10.2 Views
10.2.1 Purpose
In the case of the “views”, special object queries are set up and then integrated
into the Navigator. What had been conveyed by the object queries is then dis-
played in the nodes at specific points in the Navigator.
Please note: only that information that had been conveyed via the object que-
ries is displayed. If not all the required object queries had been created in the
views, then the objects will be missing in the Navigator display.
10.2.2 Application
Views can be created for all tabs. All the created views are available in the
Navigator settings: right-click in the white area of the Navigator, | SETTINGS
command, Tabs options field:

Views Display in the Navigator
All the created views are available for the Units , Locations and Documents
tabs. The administrator must ensure that users correctly allocate the views of
the various tabs. The views of the various tabs are independent and can be
allocated as desired. In particular, a level-independent view on the one tab and
a base object-dependent view on the other tab can be selected.
Only level-independent views are available for the Base objects tab.
If an additional Navigator is opened within the Navigator with the aid of the
| TEAR OFF command, the data is displayed there in the classical way, meaning
that the views there are not evaluated.
Only the “anchor” for views is supported in the Navigation and filter bar of
the main Navigator.
The calculation required can take relatively long, depending on the organiza-
tion of the queries. In that case the tree structure cannot be refreshed quickly
enough in all parts. The sub-sections of the tree structure that are not refreshed
appear against a yellow background. The display is up to date again after col-
lapsing and opening the node again.
10.2.3 Administration
10.2.3.1 Base objects structure

The structure has four levels:
1. Level: folder: @System | @Tree

All the views must be underneath this node. The following attributes
should be present on the General tab of the @Tree object:
ByLevel
If this option is activated, then the base object is regarded as a template
for a Navigator level and the ForCDevice drag & drop field is not
evaluated. (No base object should have been input there, either.) More
details in the “Define views with respect to the level” section below.

Drag & drop field ForCDevice

If the ByLevel option has been deactivated, then the base object for
which the view had been defined must be input here. More details in the
“Define views with respect to the base object” section below.
IsGroup
This attribute is used to create further sorting levels. Example: there can
be a number of queries within a view that search for documents. In such
a case you can create at the third level an object with the IsGroup option
and then collect all the document queries underneath it.
All three attributes are inherited at the second level. There you can select
a valid relevant setting. The attribute is only evaluated at level 2, so from
a technical point of view it would also function if the three attributes are
not inherited from level 1 but are only created at level 2. However, this
makes for more work.
2. Level: view objects
The object that is to be selected later in the Navigator is created at the
second level. Here the three attributes described above are evaluated.
3. Level: evaluation objects
Object of the relevant base object / relevant level.
4. Level: object queries.
Define views with respect to the level

This stipulates which objects may be seen at the first and second, etc., levels
in the Navigator. The ByLevel (true) attribute must be activated within the
view object.
The Navigator sets up a tree structure. At the very top is the “root”, the project.
After that follow the objects of the 1st level, which are usually units or loca-
tions. If you expand an object of the 1st level, the objects of the 2nd level fol-
low, and so on.
If you look at the tree structure in such a strictly hierarchical way, it makes no
difference at all what kind of object is located on the 1st level. It could involve
a unit, a location or a document group. The only thing that matters is that the
object is at the 1st level (or any other level, as applicable).
All the objects of this level are given the same queries.
Underneath the view object are a number of evaluation objects that have a
number in the Names field. The “1” in the name determines base objects for
the 1st level of the Navigator, the “2” for the 2nd level, and so on.

Views Display in the Navigator
You can also work with gaps in this case. Example: in the view objects there
are items with names “2” and “4”. The result:
- All the objects of the 1st level are displayed in the usual way in the Naviga-
tor.
- The objects of the 2nd level are displayed as in the view.
- The objects of the 3rd level are displayed in the normal way.
- The objects of the 4th level are displayed as in the view.
It is also possible to make the Navigator “break off” beyond a certain point.
For example, an object of the 5th level has been defined, but no object queries
were created. Thus no information is displayed below the 5th level.
Each evaluation object can possess as many object queries as desired.
Define views with respect to the base object

This stipulates which objects may be seen underneath a specific object (a
measuring position, an item, etc.). The ByLevel attribute must be deactivated
(false) in the view object.
All the planning objects in the Navigator are based on base objects. As many
base objects as desired can be created, and these do not need to be distin-
guished between on the basis of Class or Sub-class .
In the case of views related to the base object, a base object is dragged into
the ForCDevice field in the evaluation objects. Only those planning objects,
that are based on this very special base object are displayed on the basis of the
views.
Each evaluation object can have as many object queries as desired.
Groups
You can create an object query in the views with the IsGroup=true (acti-
vated) option.
The result: In the base objects view you can create the actual object queries
underneath this object. An additional folder level is created in the planning
view in the tree structure, underneath which the query results can be seen.
Alternatively, you can create the queries hierarchically yourself, and then they
are displayed in the Navigator as groups as well.
Both options for grouping objects make input for level-related views more
difficult: The grouping levels are not counted as well when counting the lev-
els!

10.2.3.2 Managing object queries

Any desired number of object queries can be created underneath the evalua-
tion objects, as described above.
The object queries are managed in the usual way, see SECTION 24: OBJECT BROW-
SER.
The starting object

Nonetheless, the Start object field is not evaluated. The owner of the object
concerned is always used as the starting object in the planning data.
The purpose of the views is to define an evaluation object that can be used at
various points within the tree structure. If the same starting object were
always to be used in the object queries, you would then always see the same
results, regardless of which evaluation object was used.
A starting object must exist in the other view, and the software cannot leave
its searching to chance. Thus the owner is used within the planning data as the
starting object.
Column definition / Navigator texts

Texts are displayed as well as the icons of the objects in the Navigator. As a
rule, the label and the caption can be read in the classic form of display.
When a view is being set up, the administrator can determine which texts are
to be displayed.
The object query is opened in the base objects for this purpose. Right-click on
the header of the column and select | PROPERTIES.
1. A keyword must be input in the Name field on the General tab:
• Object - This is the first text, this being the text shown at the extreme left.
If no column with the keyword “Object” was found in the Name field,
then only the classic texts are displayed. In particular, subsequent
columns are not investigated to see if the keyword “Description” occurs
(see the next item).
Please note: this does not mean that the view would no longer be
evaluated. The view still continues to be active and within the Navigator
only those objects that had been determined by the object query are
visible. But then these objects receive the classic Navigator texts, which
will probably be Label and Description in the object properties.

Object class symbols Display in the Navigator
• Description... - here any desired text can be input instead of the

periods. The crucial point is whether “Description” is at the beginning
of the text. Thus Description1, DescriptionPipe or
DescriptionMüller can be used.
2. The text to be displayed is input or determined on the Value calculation

tab.
Please note: the text that has been determined here is completely
independent of the Name on the General tab. Even if Description1 is
in the Name field of the text, the text that is displayed within the
Navigator does not need to be a Description. It can be anything.
The texts are displayed in the same order as that in which the columns are
defined. Thus if column Description1 was created after column
Description2, then the text of column Description1 will likewise be dis-
played further to the right in the Navigator text. The texts are shown one after
another with the “>>” separator.
If you wish to display more than two texts, you must create additional col-
umns and proceed accordingly.
10.3 Object class symbols
Action It can also be called a procedure. An action

controls other Comos objects.
Decision table
Other Comos objects are modified or replaced
on the basis of fixed criteria. For example, if
you had created a motor within an assembly,
you could replace the fuses with a decision
table that varied according to the rating. In
electrical engineering this is referred to as a
parameterized macro.
See SECTION 28: DECISION TABLES.

Display in the Navigator Object class symbols
Import
External tables can be imported into Comos
and the data of the tables can be stored in the
form of base objects or planning objects. Cur-
rently Access databases, Excel spreadsheets
and text files are supported. It is recommended
that Access databases are used as the import
source.
See SECTION 33: IMPORT VIA ACTION OBJECTS.
Object query
A query object is a powerful tool to search for
objects, and thus to filter and sort the search
and the results of the search in all kinds of
ways. There are five types of object queries:
object query for planning objects; object query
for base objects; object query for documents;
object query for attributes; object query for
connectors.
Script
A container for a script.
Unit A group of functionally related technical
devices or facilities, or the topmost logical
grouping that appears meaningful to the user
from a technical point of view. Units are set up
hierarchically, meaning that they can possess
superordinate units (sub-units).
Blackbox
Can be set to blank if it is not yet sufficiently
clear which object will be required later. For
that reason the number of connections has not
been determined yet either, but a blackbox can
have any desired number of connections.
Category
With the aid of “categories”, components can
also be sub-divided automatically into these
classes instead of just being allocated globally
to a unit.

Connector A connector is a position at which one techni-

cal product can be connected with another
technical product in an appropriate way.
Comos recognizes “intelligent connectors”,
meaning that a logic that prevents incorrect
connections can be applied.
Assembly An aggregation of Comos objects, usually
prewired or preconnected. In electrical engi-
neering this is referred to as “part switching”.
Data set Module P&ID:
Objects of this class only serve as holders of a
graphic. Symbols can be defined in the usual
way for the base object and then placed on an
interactive report. However, no planning
object is created. The symbol thus can never be
inconsistent and consequently is not displayed
in red either
Other modules:
The class creates a normal Device.
User address
Here you can store the User addresses of work-
stations in the network.
Document A document is the interface that allows any
desired number of electronic documents to be
bundled together. A document can thus be a
CAD drawing, a report, a spreadsheet, a text
document, etc.
Document group Logical unit within the Document tab in
Comos. If the unit or location view has been
linked with a document group, documents that
were created according to a specific naming
scheme can be referenced automatically.
See SECTION 40.2: PREPARING THE BASE DATA OF
DOCUMENT GROUPS.

Element A constituent part of a device that as a rule is

not fully and independently functional in itself.
Elements in this sense generally cannot be
ordered individually.
Exception: terminals. Although terminals pos-
sess the Element object class, they tend to
behave instead as a Device .
Although it is feasible from a technical point of
view to use elements directly as planning
objects, such a method should not be used. It is
recommended that you always incorporate ele-
ments by means of the Elements tab.
Break
Is needed in reports for pair references.
Wire
Wires are elements of cables.
Graphic
Module EE:
Objects of this sub-class only serve as holders
of a graphic. Symbols can be defined in the
usual way for the base object and then placed
on an interactive report. However, no planning
object is created. The symbol thus can never be
inconsistent and consequently is not displayed
in red either.
Other modules:
Sub-classes are not evaluated. In other words:
The object acts like a normal element.
Terminal
Terminals are elements of terminal strips.
Pipe
Is used in the PFD module for pipes.
Segment
Defines a unit and/or a location for a sub-area
of a diagram. It can also be called a standard
sheet section.

Plug
Plugs are elements of plug strips.
Function Synonym: Comos actuating function. The
function the measurement or actuating task and
the processing function(s) at a position. It cor-
responds to a “measuring function” in the
P&ID schematic layout.
A Comos position that has a controlling func-
tion from a process control point of view pos-
sesses at least one function, but can have
multiple functions.
Actuator
A component, such as a valve, that executes an
action in the P&ID planning. By comparison
with an actuator (inline), this is a add-on com-
ponent, the pipe continues to be a single part.
Actuator (inline)
A component that executes a function in the
P&ID planning. By comparison with an actua-
tor, this is a built-in component, the pipe is
interrupted and is split into two parts.
Instrumentation
Components in P&ID diagrams, such as a mea-
suring function.
Function Function modules are used in function dia-
component grams. Example: function logic (AND link,
OR link)
See SECTION 65: LOGICAL DIAGRAMS / FUNCTIONAL
DIAGRAMS.
Action block
Used in function diagrams.
Step

Transition
Visualization element
This object represents a graphic / visual ele-
ment of the subsequent unit controller. In the
classic sense, this could be a lamp; in modern
usage this could just as well be an OCX of the
unit controller.
Function element Function elements were formerly used under
the measurement functions.
Instrumentation
Device A device is the smallest separately marked

technical product that fulfills a task together
with other devices. For that reason in Comos
devices are always part of a unit or a loca-
tion .
Terminal strip
Terminal strips connect devices together. Ter-
minal strips can possess bridges. By compari-
son with a plug strip, a terminal strip is made
up as required and can thus be of any size.
Cable
A cable is a bundle of wires.
Logical potential
A logical potential is used to pass on a potential
value in the database from one object to the
next.
Potential
A potential represents a physical potential, or
in other words, a potential-carrying cable. For
that reason a potential can have any desired
number of connectors.

Contactor/Relay
This detail class initiates the creation of a con-
tact mirror at an object. A contact mirror is reg-
ularly created for relays or contactors. In
principle, it is also conceivable that you could
force the creation of contact mirrors for other
components by means of this detail class.
Plug strip
Plug strips connect devices by means of plugs
and sockets. Plug strips typically have no
bridges. As opposed to a terminal strip, a plug
strip is supplied as a rule in a fixed size.
Device request Obsolete, has been replaced by the Request
property of base objects.
This class was useful in the planning phase.
Only a request was input for the subsequent
detail planning, for an item such as a pump, and
the engineer could replace the device request
with a manufacturer device in the planning
project.
Costs Any desired unit of cost, such as DM, Euro,
etc.
Mounting As a rule, the time required for or any special
information regarding the mounting of a device
or a unit is entered here.
Location As a rule, the location or place of installation of
a technical device. Frequently, however, the
term is understood to have a wider meaning
and is regarded as a functional allocation.
Room
Represents the physical room in which parts of
a unit controller are to be installed.
Cabinet
Represents a physical switch cabinet.

Rack
A sub-area within a switch cabinet.
Slot
A sub-area within a rack and the smallest logi-
cal sub-area within a switch cabinet. For exam-
ple, to hold I/O cards.
Quality assurance A blank information block that can be used for
any purpose desired.
Revision In Comos the means of checking, and correct-
ing or approving as required, versions of docu-
ments on the basis of defined criteria (the
elements in a revision object). Since the soft-
ware has no way of knowing which revision
criteria are meaningful, there are no predefined
examples; fundamentally, the user has to
define the revision scheme by himself or her-
self.
See SECTION 41: REVISIONS.
Signal A signal designates the information unit that is
processed in function diagrams and signal
flowcharts, for example, “ON” or “OFF”. It
thus represents the input or output respectively
of the C&I item.
A Comos position can possess multiple sig-
nals.
Position A position designates a C&I or process control
task.
Equipment
Equipment in the P&ID planning, for example,
a tank or a pump.
Pipe
A pipe in the P&ID planning.
Cable route A route/cable channel is used to put together
pipes or cables between two location into a
spatial group.

Other symbols Display in the Navigator
Modify This object is used in connection with signal

processing.
Maintenance A freely available parameter that is often
defined as costs for a period of time (such as
DM per month).
Time A freely available parameter that allows peri-
ods of time or points in time to be defined.
Accessory The term accessory covers devices that are
available for another specific device. An acces-
sory thus possesses as its most important prop-
erty an allocation (pointer) to a device from the
catalogue of devices. Example: screws, gauge
pieces and insets.
10.4 Other symbols
Project Symbolizes a globe.
Tab to collect Attributes can be collected and sorted by

attributes means of the Specification tabs.
Attribute Attributes are the properties that make a more
special object out of a general object. The more
attributes are added, the more precise is the
description of the object.
See the Administrator manual.
10.5 Context-sensitive symbol change

The Navigator displays the individual types of data in visual form through the
use of symbols. The administrator can determine which type of symbols are
displayed. In addition, the symbols change according to how the objects are
used.

Display in the Navigator Context-sensitive symbol change
10.5.1 Object colors
Base objects: Red

Planning objects: Colored
Objects on the Elements

Option Color RGB values
Virtual 1 times or Green (0,255,0)
virtual n times
Default Dark green (0,125,0)
Not virtual Cyan (0,180,0)
Please note: each object class can be created on the Elements tab,
not only objects of the Element class!
10.5.2 Additional object elements
On the other hand, additional elements can be added to the symbol:
Original, Without any further changes.

here: device
Created locally With a small blue globe in the top right-hand
corner. Only for base objects.
Referenced With a small blue box in the top left-hand cor-
ner. This does not involve an object in the usual
sense, but instead a link or a cross-reference
respectively. “Link objects” of this type can
often, but not always, be used in the same way
as the original.
Request A blue triangle in the bottom right-hand corner.
Block Currently only for elements: Marked with a red

box at the top left.

Context-sensitive symbol change Display in the Navigator
Placed element This symbol shows that this element has

already been placed in a diagram.
Inherited object. Only for base objects: Symbolized by a black
arrow in the top left-hand corner.
Check-in object. Only for base objects. Symbolized by a white
arrow in the top left-hand corner.
Projected object For | COPY STRUCTURE. Symbolized by a black
arrow in the top left-hand corner. See
SECTION 8.3: COPY STRUCTURE.
Document object This symbol does not in itself stand for an

object that would exist at this point within the
tree structure. Instead it states on which docu-
ment the object was placed.

Properties: Base lists Standard tables
11 Properties: Base lists
11.1 Standard tables
11.1.1 General information on standard tables
11.1.1.1 Definition
A standard table describes a property and offers values for selection
relating to this property. Normally standard tables are used to either
simplify or force a selection of specific attribute values.
Nonetheless, other information can also be stored in the form of standard
tables, such as diagram types, symbols or the like.
Synonyms used for the term “standard table” include “default table” and base
list.
Standard tables can be created hierarchically. Please note that differing hier-
archical structures in the standard tables in different databases can lead to
inconsistencies when projects are swapped out or imported.
11.1.1.2 Creating or modifying standard tables

Open the project with the standard table, which as a rule is the system project
or the base project.
Select the | ADMINISTRATOR | STANDARD TABLES menu.
The following Standard lists dialog window has two areas: the left-hand one
is used to display the lists in the form of a tree structure, while the right-hand
area is used to display the entries for the selected list.
Using the three options in the Project field, you can determine whether the
lists of the current project, of the base project or of the system project are to
be displayed.
Only standard tables that have been created in or checked into the current
project can be modified. If you attempt to modify a standard table that has not
been checked in, the error message This object is not in the current project
appears.
Alternative: If you have opened a planning project and wish, for example, to
modify a list from the base object, you can check in the list with the aid of the
right mouse button. Now select the display at Current . The corresponding

Standard tables Properties: Base lists
commands are now made available in the context-sensitive mouse menu (see
below). However, the changed values are only available in the particular plan-
ning project in question.
Properties
The | PROPERTIES of the values, which are displayed in the right-hand area, are
likewise called up by right-clicking:
Name Unique name

Description Descriptive long text (optional)
Value1 The contents of field Value1 of the various entries
are later offered for selection within the planning
project.
Value2 - Value10 Additional fields that are made available for pro-
gramming purposes. For example, these values can
be queried by a script.
Determining the input value

An input value can be set after at least one value has been defined. Do this by
mouse-clicking with the menu.
The input value that has been set is displayed at the upper edge of the dialog
window in the Input value field.
Create standard table / properties

• Right-click in the left-hand window | NEW or | PROPERTIES
• Input the properties Name , Description (optional) and a value. The new
standard table appears in the tree structure after you have confirmed with
[OK].
Creating entries for the standard table

Entries can be inserted into a table that has just been created or into an existing
table. Mark a standard table in the left-hand window.
• The list must be available in the Current view.
• Call: Right-clicking in the right-hand window | NEW
The work is easier if you use Copy and Paste .

Properties: Base lists Unit systems
11.1.1.3 Symbol allocation (subsymbols) for P&ID plans

The Plan type and Symbol file dialog fields can be found in the bottom area
of the standard tables:
A symbol can be allocated to each entry of the standard table for the P&ID
diagram type. These allocations can be used as graphically-relevant attributes.
This makes it possible to ensure that a object based on this base object in a
P&ID drawing can be displayed by various different symbols (subsymbols),
depending on the attribute value selected.
11.2 Unit systems

Unit systems describe the properties of unit groups and offer units for
selection.
For example, the “Length” unit group would be described in Germany by the
physical symbol l and the reference unit meters. The units used could include,
for example, micrometers, millimeters, inches, feet, etc. Once the unit system
has been created, then a pipe object can be defined, for example, in such a way
that the user can select from the list of units or is only allowed to work with
a specific unit.
11.2.1 Editing unit systems
Open the project with the units systems, which as a rule is the system project
or the base project.
Select the | ADMINISTRATOR | UNIT SYSTEMS menu.

Unit systems Properties: Base lists
11.2.1.1 The “Groups” area

The unit groups appear here. You can toggle the display with the All groups
switch:
On: Those unit groups that have not been checked in are also dis-
played, e.g., unit groups from the base project or the system
project.
You can mark a unit group and check it into the current project
via the mouse, using the context-sensitive mouse menu. This
makes it possible to input units that deviate from the units in the
base project or system project.
Off: Only unit groups that have been checked into the current
project are displayed.
Properties
Using the right mouse button, you can display and edit the properties of the
table for all unit groups that have been checked into the current project:
Symbol The letters that have been defined as the
physical symbol.This would be l for length.
Reference unit The SI unit, or the international conversion
and standard unit of this unit group. This
would be the meter for “Length”.
Default unit Default value offered to the user.

The first value is automatically used as the
input value if no other value had been speci-
fied by the administrator.
The default unit is also required if it is
intended to convert all the units across a
project.
11.2.1.2 The lower “Units” dialog area“

All the units of the unit group marked above appear here. Only the units from
groups that have been created in or checked into the current project can be
changed. If you attempt to change a unit that has not been checked in, the error
message This Object is not in the Current Project appears.

Properties
Open the Properties window of the units by right-clicking:
Unit The combination of letters used to display the unit. In the

case of millibars this would be mbar.
Conversion dialog area

The formula used to convert the Standard International unit (SI unit) into the
current unit. The SI unit is specified in the unit group above the Reference
unit field.
Decimal places
Specifies the number of decimal places displayed. This would be 2 in the case
of “Currency”.
Unit conversion dialog area

1. British or Metric must be selected first of all. If British is selected, this
means that the unit entered above in Name is British (imperial and US)
and a metric value has been allocated to it, and vice versa in the case of
Metric .
2. After that, one of the units that had been created in this group can be
selected from the drop-down menu.
You can thus create both metric and British (imperial and US) units and then
allocate them mutually as required with a unit group. The units are converted
as required through the relevant SI formulas. In other words, the British (US)

Unit systems Properties: Base lists
unit has an SI conversion formula allocated to it, and the metric unit likewise.
When both formulas are combined, you can convert the metric unit into Brit-
ish (US) ones and vice versa.
When a metric unit is allocated to a British (US) unit, Comos stores this allo-
cation and transfers the allocation at once to the other unit as well.
Example: If an allocation of mm to inch is made within the properties, then
the corresponding mirror-image allocation is automatically made in the Prop-
erties window for inches as well.
It is also possible to link more than two units, since this does not necessarily
involve a 1-to-1 relation. Thus both mm and km could be allocated to the unit
inch. If a unit conversion is then made (see below), then all units with mm and
also all units with km are suitably converted to inches.
However, the reverse does not apply, as an inch unit can only have one con-
version unit. An inch cannot have both mm and km as a conversion unit. The
conversion unit to be input is always the one that was entered first. If mm and
inch had been linked, then mm is also shown in the properties for the inch unit.
The allocation can of course be changed retrospectively (but it can no longer
be removed completely, see below).
Please note: If more than two units have been mutually allocated and if con-
sequently there is no longer a 1-to-1 relation, then the units will be rounded
off in the conversion.
Example: If both mm and km have been allocated to the inch unit, then both
unit values are converted to inches. However, if the conversion is reversed
later, then all the inch values would be converted into mm, for example. The
information that specific units had earlier been input in the form of km is lost.
Storage location of the conversion formulas

Once an allocation has been made, this allocation can never be removed via
the properties of the units. If an allocation is to be removed completely, then
the UNITMAPPInG standard table must be edited.
The unit conversion accesses the @System | @UNITMAPPING standard table,
which is created automatically when you use the Unit conversion area in the
Properties window of a unit for the first time. Allocation pairs are created
there using the system Value1 = name of the British unit and Value2 = name
of the metric unit. If an entry is deleted in this standard table, then the corre-
sponding allocation is also removed.

Running the units conversion

In the course of the planning work, the Unit conversion dialog window from
the PlugIn toolbar in Comos can be opened, see SECTION 30.2: UNIT CONVERSION.
11.2.1.3 The “Return objects” area
Default unit Again displays the selected Default unit .

Group Again displays the Symbol of the selected
group.
Unit Again displays the Unit of the selected unit.
11.2.2 Converting values across projects

Normally the value of an attribute is linked with the unit. If a unit is converted
within a planning object, the change only affects this one particular object.
Example:
Planning object test1 : The unit Minutes is provided for the Time requi-
red field. The value 10 is input in the field.
Planning object test2 : The unit Minutes is provided for the Time requi-
red field. The value 10 is input in the field.
In test1 the unit is converted from minutes to seconds . The value is auto-
matically converted to 600. In test2 there are no changes: the value 10 and
the unit Minutes continue to be used here.
There is the option to create base objects and unit systems in such a way that
all the planning objects that access the same unit group can be converted at
the same time. Two steps are required to do this:
1. Create attributes that do not access a unit but instead a unit group.
2. Check the corresponding units group into the planning project.

Document types Properties: Base lists
Re step 1.
Create an attribute within the base object that does not access a unit but
instead a unit group:
The entry field in the planning object appears to be unchanged. Probably what
will appear is an entry field for the value and a drop-down list for the unit. The
unit is checked in if a unit has been selected from the drop-down list within
the planning object. However, the conversion mechanism only functions as
long as the unit has not been checked in. The unit should be set to static in
the Control properties of the attribute to prevent the user from switching over
the unit in the planning object and thus checking it in.
Re step 2.
Switch to the planning project and open the unit systems. Activate the All
groups option so that all the unit systems are displayed.
Mouse-click on the corresponding units group and select the Check into the
current project context-sensitive mouse menu.
Deactivate the All groups option again if you wish to switch over a unit
across projects. Only the units systems that had been checked in are displayed.
The Properties window can be opened by right-clicking. The default value can
be switched over in the Edit properties dialog window. The unit is switched
over and the value is recalculated for all planning objects that access this unit
group (and for which the unit has not been checked in, see above).
11.3 Document types

The corresponding interface must be set up within the system project
so that the document type can be used within Comos.
• Open the system project in your database.
• Now open the menu:
| ADMINISTRATOR | BASE DATA | DOCUMENT TYPES

Properties: Base lists Document types
11.3.1 Interface
Status (first column)

S = System project
Mode (last column)
0: External file exists. This means that there is a physical file for this docu-
ment somewhere on the hard disk.
2: No external file. This document only exists within Comos.
Mark the desired document type and call up the properties by right-clicking.
If you wish to create a new document type, right-click on any desired entry
and select | NEW.
Confirm with [OK].
The default document types available correspond to the Properties window
for documents.
11.3.2 Properties
You will see the following dialog window if you open the properties of an
entry or create a new document type:

Document types Properties: Base lists
The entry fields have exactly the same meanings as those in the column head-
ings that were described in Interface, P. 11-9.

Properties: Systemtype CDevice General buttons
12 Properties: Systemtype CDevice

Create a new base object or open an existing base object by means of the right
mouse button, | PROPERTIES. The object data is divided into tabs:
Opening another base object

Instead of closing the open window and opening a new Properties window,
you should simply double-click on another object.
12.1 General buttons

[Navigate]
Top left: Depending on the object, a number of different Navigation
options are offered:
OBJECT
Selects the object in the Navigator. The project is not switched.
OBJECT IN BASE PROJECT
Switches to the base project where the object is selected in the Navigator.
USES
Shows where the base object is being used (as element or link).
INHERITANCE SOURCES
Shows from which objects the base object inherits information (through
hierarchical inheritance, links and references).
[Owner]
Top left: Switches to the hierarchical owner.
[Keep ... visible]
Top right: If this switch is pressed, then the contents of the Properties
window are not changed if you double-click on another object, but instead a
second Properties window is opened.
12.2 “System” tab

The general data of the base object is managed on the System tab.

“System” tab Properties: Systemtype CDevice
12.2.1 Inheritance
The inheritance of base object properties was introduced in SECTION 7: INHERI-

TANCE. Recall that the following properties are not inherited:
• Folder (IsFolder)
• Virtual group(Virtual)
Only available for elements.
• Inheritance mode
Only available for elements.
• Visible for all users (Visible)
• Creation option (CreateOption) (inheritance only via the base object)
All further information can be found in the above-mentioned section on inher-
itance.

Properties: Systemtype CDevice “System” tab
12.2.2 General details
Class
This dropdown list contains all the classes of base objects. This list can be
extended. Depending on which class was selected, different subclasses are
available in the right-hand field.
Subclass
This dropdown list contains all the subclasses that are available for the
selected base object class.
[Delete]
If the subclass of the base object had been changed by the user, this but-
ton restores the inherited initial value.
[Object icon]
Here you can assign a user-defined icon of your own to the base object
to distinguish it more clearly from the other objects. A small dialog window
opens when you click on the icon button.
Icon library
A sample library is offered here.
File
You can specify an ico or bmp file of your own with this option.
Your inputs are accepted when you click on the [OK] button at the bottom of
the dialog window.

If you click on the button with the cross, you delete the icon that was specified
for this base object. The base object then once again inherits the icon from its
parent object (letters in italic). If this is icon is deleted as well, then the code
character “_” is used. This tells Comos that inheritance is broken here and
thus there is “nothing”.
Deleting a user-defined icon: open the above dialog window again and click
on the button with the cross:
Confirm the deletion by pressing the [OK] button.

The corresponding icons also appear in the derived planning objects. Docu-
ments also take over and use the icon of their base object.
Please note that Comos is faster if you use the internal icons of
Comos (provided in the Icon library ). Comos becomes slower if
you select an external file by means of this icon.
Here you can specify a DLL of your own that is

executed when the object is started. The DLL is
ControlType (ProgID) enteted with the ProgID from the Registry.
Edit fields
Name
Unique name.
Label
Enter the label of a base object if you are working with labeling systems. Spe-
cial cases in which a label is also used outside a labeling system (for example,
in the case of document groups), are documented in the corresponding sec-
tions.
Description
Long text, this is displayed in the Navigator. The Description field is inter-
nally managed as a “Memo field”. The reason for this is that you can work
with several languages within Comos. Translations into other languages are
saved invisibly in the same field. Although the translations are invisible (until
you switch languages), they do of course still take up part of the field length.

Even very large texts can be translated into various languages by using the
Memo type without reaching the maximum field length permitted. See also
SECTION 42: LANGUAGES (LOCALIZATION) for more details.
The checkboxes under the key determine whether the fields for Name ,
Label or Description are locked.
If the option has been checked, these fields cannot be changed for a
planning object that is based on this base object.
The two checkboxes underneath this icon determine whether the entries
for Name or Label are checked for validity by the mask generator.
In Comos the “checkboxes” have properties that go beyond the typical
Windows functionalities and thus they also have special display forms:
Text italicized, checked or not checked: The associated property
has been inherited.
Text normal, checked or not checked: The associated property is
the object’s own (not inherited).
Checkbox grey, checked or not checked: the checkbox has been
locked.
12.2.3 Text masks
A text mask defines a pattern that is used to automatically generate texts when
a planning object is created. The text mask consists of two edit fields:
The pattern of the mask is specified in the front edit area, and in the rear area
the starting value. Both fields must be filled out.
Character Meaning
. (Period) Any desired character.
9 Numbers, [0-9]
a Alphanumeric, only lower case letters [0-9a-z]
A Alphanumeric, only upper case letters (capitals) [0-9A-Z]
x Alphanumeric, [0-9A-Za-z]
Table 12-1: Wildcards when creating text masks

Character Meaning
c Lower case letters, [a-z]
C Upper case letters, [A-Z]
z Any letter [A-Za-z]
* Zero or several of the previous characters or expressions, e.g.
9*
+ At least one of the previous characters or expressions.
? Zero or one of the previous characters or expressions.
<> Open for calculation, i.e. the part that is to be calculated
\ Always placed in front of the literal
*+? – If not used as a literal: Cannot be used on their own.
– Can occur either inside or outside the calculation part
<> Is only allowed to occur once
Table 12-1: Wildcards when creating text masks
Examples:
Comos mask First value Last value Regular expression,

internal
...<9*> ABC ...[0-9]*
\M<c> MA Mz M[a-z]
\C<9+> A1 [a-z][0-9]+
\T\V<99> TV01 TV99 TV[0-9][0-9]
..<999+> XY001 ..[0-9][0-9][0-9]+
\H<99+>. H01N H99N H[0-9][0-9].
.*<9+> 1 .*[0-9]+
<9*>.* 1 [0-9]*.*
\A\C<CC> ACAA ACZZ AC[A-Z][A-Z]
Table 12-2: Examples for text masks

Check validity
Compares the starting value in the right-hand field with
the text mask in the left-hand field.
Use standard table : Here a value from a standard table is used.
Exceptions: if the text masks have been deactivated

It is not possible to create a text mask for tobjects that:
• were created on the “Elements” tab (not to be confused with the class
“Element”.) and
• whose Virtual option is set to Off or Default .
Reason: The elements prepared in the base data and the planning objects
derived from these elements are connected solely through their names. For
that reason, the name may not be changed when a planning object is created
by means of the prepared element (in other words, when the user “creates” the
Element). And text masks are provided precisely to change the name during
this phase (to create a new name automatically).
Project-specific text masks

If a text mask is defined at the base object, then this definition applies for all
derived objects, regardless of within which project these objects are actually
located.
You should not attempt develop different base objects for different projects in
order to avoid this. Such a solution would be unduly complicated and has a
disadvantage: a user who is project manager but who has no rights in the base
project would no longer be able to change this option.
A better solution:
• The text mask entry of a base object is assigned to an entry in the standard
table |SYSTEM|@MASK from the base project.
• Standard table @MASK is checked into the planning project and individual
deviations can be added.
This is how it is done:

• Open the base project
• Open the properties of the base object, System tab.

• Select the “i” button in the mask line of the base object
• Enter the mask and the default value
• Press “i” again and click on the Write to standard table ... command that
is right at the bottom
(This option is only visible if entries have been made in the Mask field and
in the Default value field.)
• Open the planning project, select the | BASE DATA| STANDARD TABLES menu
item from the from the ADMINISTRATOR menu (or the [STANDARD TABLES]
icon).
• Check in the standard table |@SYSTEM|@MASK.
To be able to open the standard tables you must be logged in as
administrator; otherwise the Administrator menu is not available.
• Modify the entries.
12.2.4 Edit group “Reference”
Base object Here you can set a link to another base object:
either by using drag & drop or by pressing the [...]
button. The properties of the base object that is ref-
erenced are taken over.
Dereference This option only appears if a reference has been set
to a base object. The option changes the inheritance
structures:
When a planning object is created, it only takes
over the Name , Label , and Description fields of
this base object. All other properties are inherited
from the base object that had been entered in the
Reference field.

After instantiating the planning object, the infor-

mation that the planning object had originally been
derived from this base object is lost. Instead, the
planning object saves the information that it is con-
nected to the base object “one level further”, i.e. the
base object that had been entered in the Reference
field.
Result: If this base object is modified at a later
point in time, this has no effect on any planning
objects that have already been created, because
they are no longer connected to this base object.
Instead, changes that are made at the base object
that had been entered in the Reference field are
taken over.
Assembly An assembly group consists of a group of planning
objects that have been prepared in the base project.
The components are completely planned in the base
project (their properties are set, they are connected
to each other etc.). Then the assembly group is
made available by means of a base object.
In other words: If a link to an assembly group is set
here by means of drag & drop, then this base object
only serves as a link to the preprepared planning
objects – in a similar way to a “shortcut”. All other
properties of the base object are ignored. As a
result, all the tabs except the System tab are hid-
den.
You can also use the Block option when working
with assembly groups, see below. The option has
the following effect:
Normal : The planning object that forms the start-
ing node of the assembly group is created as well.
Block : The planning object that forms the starting
node of the assembly group is not created.
Base objects that link to an assembly group cannot
be created directly as planning objects. They must
be made available as elements, see SECTION 49.5:
TEMPLATES

12.2.5 Edit group “Miscellaneous”
Visible for all users If this option is deactivated, then the object and all
objects underneath it are invisible for normal users.
The option can be used to filter the base data struc-
ture for normal users, to whom many of the base
data branches are of no interest and can be omitted
from view.
This property is not inherited downwards.
Count This option only appears in the Properties window
of an object that is located on the Elements tab.
The option is not evaluated by Comos but is freely
available. The option can be addressed with CDe-
vice.Number by means of a script.
Working area The selected working area determines in which

areas the base object is to be used. This also con-
trols the visibility of devices, etc. that are based on
thisbase object.
See SECTION 6.4: WORKING AREAS.
12.2.6 Edit group “Object behavior”
Define run cases Run cases are variations of a project. They are used
to be able to simulate different load states, for
example. With this option the planning object
influences which run case is to be used.

Folder A base object that is a folder has a purely adminis-

trative purpose: to serve as a unit under which other
objects can be grouped and sorted. Objects with the
Folder property are not taken into consideration
when calling FullLabel in order to compute the full
name of an object.
This property is only inherited to the planning
objects.
If an object had been declared as a folder in the base
data view, this property cannot be deactivated in
the planning view!
See also “Folder - Sort objects bottom-up ”
SECTION 10.1.2.1: “SETTINGS” COMMAND.
See SECTION 5.5.3.9: NAME IS FOLDER-WIDE UNIQUE.

Instanciating Instanciating is used to reduce the number of
objects. This is done by creating attributes that are
used jointly. See SECTION 20: INSTANCES (REDUCING THE
NUMBER OF OBJECTS).
Unique label Normally the label of an object must be unique. (If

no label had been entered, then the name is used
instead, and the name is always unique).
However, it can also happen (for example, with ter-
minal strips) that objects with the same label are
required. In such a case the unique label can be
deactivated here.
12.2.7 Edit group “Creation option”
The Creation option specifies what the base object is to be used for.
Normal
A normal base object that serves as the basis for planning objects.
Block
A block is used to be able to create several elements in one step. See
SECTION 12.5: “ELEMENTS” TAB.
A base object with the Block option cannot itself be created as a planning
object but represents only the individual elements.

Group
Similar to the Folder option in the case of planning objects, a Group is used
to sort base objects. A Group is ignored when names are computed automat-
ically, for example by calling FullLabel.
A base object with the Group option cannot be created as a planning object.
Structure
A structure object is not used to become a planning object in itself but instead
its function is purely related to organize the base data:
A structure object is used to make base objects accessible that are located
underneath it.
Implementation: Create a base object with the Structure option. Create
additional base objects underneath this structure object in the usual way.
(Do not confuse this with the creation of elements).
The structure object is now entered as an element at another base object (i.e.
is added on the Elements tab) – for example, a unit.
If the base object of the element does not have any “child base objects”, then
the Base object link is evaluated in addition, and the “child base objects”
of that referenced base object are used.
Effect: After creating the unit in the planning project, the structure object is
offered in the | NEW mouse menu for this unit. However, if you select the
structure object from the mouse menu, it is not created but instead a
submenu appears in which the objects located underneath the structure
object are offered.
This option is primarily helpful for defining labeling systems.
[DELETE] button
This button undoes the setting made by the user and activates the inher-
ited setting.
In Comos, there is always a Delete button of this type if only one of a group
of selector buttons can be activated.
Not selectable
Option “Not selectable ”: All exisiting planning objects derived from this
base object can continue to be used, but no further new use of the base object
is possible. This has the following effects, for example:
• The derived planning objects can still be edited. The derived planning
objects can also still be copied and pasted in again.

• But it is no longer possible to create a planning object by using drag & drop
on the base object (neither in the Navigator nor on a report).
• The base object likewise no longer appears on the | NEW menu.
• The base object also appears no longer in the selection of real devices.
12.2.8 Edit group “Creation mode”
Creation mode controls which objects can be created in the planning view. A
particular mode is activated in the base data view and the base data is set up
accordingly. But you only see the effect of this mode once you are in the plan-
ning view.
Effect of links
Hence objects may also be created that do not themselves belong to the ele-
ments but which only end up in this group because of base object pointers.
Example 1:
An already existing base object CDevice2 is dragged onto the Elements tab
by means of drag & drop. As a result of this, an element is created that has a
base object link to CDevice2. CDevice2 is of course permitted, but so are all
objects located underneath it.
Example 2:
CDevice1 has an element Element1 with the property Virtual N-times .
Element1 has a base object link to a CDevice2 that is located in another base
object branch. CDevice3 in another base object branch possesses a base object
link to CDevice2. CDevice3 is permitted.
Free
All
Elements
If the base object has virtual elements, then only objects can be created in the
planning that have been permitted virtually. When creating a planning object,
the ELEMENT FROM LIST menu entry is offered in the menu by right-clicking.
That way elements that are to be created can be selected directly from the base
object.
Subelements
Additional elements that exist in the element tree of the base object can also
be created underneath the planning object.

12.2.9 “Inheritance mode”
Inheritance mode
This property only appears in the case of objects that had been created on the
Elements tab (Elements-Collection; not to be confused with objects of class
Element). See SECTION 12.5: “ELEMENTS” TAB.
Inheritance mode is also used in:
• Attributes, see SECTION 16.2.8: INHERITANCE MODE.
• Connectors, see SECTION 12.6: “CONNECTORS” TAB.
12.2.10 Edit group “Virtual”
The Virtual group only appears in the case of objects that had been created on
the Elements tab. Do not confuse them with objects of class Element.
Virtual, X times Enter how often the element is allowed to be cre-

ated manually. If the maximum number of virtual
elements specified in the base object has been
reached, the corresponding context-sensitive
mouse menu is no longer offered in the planning
view.
In order to find out if the maximum number of ele-
ments to be created has been reached, Comos not
only checks the names but also the base object ref-
erences. That way, virtual elements that were
renamed after being created in the planning view
are also considered.
Virtual, N times The element can be created in the planning project
as many times as desired. It must be created manu-
ally.
Off (not virtual) The element is created automatically when the
planning object is created. The element cannot be
deleted afterwards.
Default The element is created automatically when creating
the planning object, but it can still be deleted after-
wards. Also, it can be created again manually after
having been deleted.

Properties: Systemtype CDevice “System settings” tab
For documents
When setting the base object pointer for a planning object (this also means
when creating it), the default documents are created both for elements with
the Off property (as before) and for elements with the Default property.
12.2.11 Edit group “Status”
Status management is done here at the object level, see SECTION 21: STATUS
MANAGEMENT.
12.3 “System settings” tab
12.3.1 Edit group “Implement requests”
This group allows you to specify for a base object if the request object is to be
replaced or retained when it is implemented. This option overwrites the
project setting from the Properties window of the project, Module options
|Detail tab, property “Implement request” replaces object .
Request
This option declares an object to be a request object. In the planning view,
request objects are later on replaced by real devices.
Do not use objects with class Request anymore. Use this option instead.
Replace objects
The request object is fully replaced by its implentation (a real device), i.e.
it is deleted.
Don’t replace objects
The request object is retained. Beneath the request object a reference to
the implementation object is created and vice versa.
Project settings
Takes over the setting that from the project properties, Module options
|Detail tab, “Implement request” replaces object .
Compare also SECTION 60: REQUEST AND IMPLEMENTATION.

“Specifications” tab Properties: Systemtype CDevice
12.3.2 Edit group “Allowed links”
The Allowed links group determines which links an object can have in the
planning view. If one type of link offered in this group had not been selected
in the base object, a link of this type may not be set in the planning object, nei-
ther over the interface by drag & drop nor by a script or an import operation.
Planning objects can have links to:
– a unit / position / function / signal
– a location
– an implementation / target / cable route.
If a type of link is deactivated in the base object, the corresponding links of
already existing planning objects are still valid.
Sometimes, simply activating or deactivating the use of a pointer is not
enough. If you want to explicitly control the use of a pointer, then you should
use script blocks IsUnitValid (Device), P. 22-5, IsLocationValid (Device), P. 22-4 and
IsImplementationValid (Device), P. 22-4.
If a type of link has been deactivated here, then the corresponding entry can-
not be selected any longer on the Configuration tab. If it had already been
selected and moved into the “Current components ” area, then this compo-
nent is automatically moved back into the “Default components ” area.
12.3.3 Edit group “Product data: comparison method”
If the Recursive option has been activated, then the same function also oper-
ates recursively for elements (CDevice.RealElements) of the object.
12.4 “Specifications” tab

The attributes collected on this tab (and its sub tabs) contain the specifications
of the CDevice, respectively of its planning objects: Its technical data and
manufacturer data, the substance data, accessories, dimension ect.
In view of its complexity, this tab is described in its own sections: SECTION 16:
PROPERTIES: SPECIFICATIONS, SECTION 16: PROPERTIES: SPECIFICATIONS.

Properties: Systemtype CDevice “Elements” tab
12.5 “Elements” tab
The subordinated components of an object are created here. The elements of

the Elements tab primarily serve the following purposes:
1. To set up a naming system
Here the objects are only required as ordering criteria and the
Dereference option should be activated. See SECTION 12.2: “SYSTEM” TAB
regarding the Dereference option. See SECTION 49.6: LABELING SYSTEMS
regarding labeling systems.
2. To set up multi-level objects, such as terminal strips
Dereference must have been deactivated.
The Dereference option is deactivated by default when an object is
pulled onto the Elements tab by means of drag & drop.
3. To make available objects that belong together technically or
thematically. The objects of the Elements tab are offered in the planning
view in the | NEW mouse menu.
Creating new elements

Call: right mouse button| NEW
or
Use drag & drop to pull an object from the Navigator into the Elements
window (then a Link: base object is created).
Elements can be nested, meaning that they in turn contain elements.
The Properties window of the new element looks almost exactly like the Prop-
erties window of a “normal” base object. The created elements can also con-
tain attributes, connectors and the like.
Element-specific options on the “System” tab

Inheritance mode

“Elements” tab Properties: Systemtype CDevice
• Active
If activated, the element is inherited both by the planning objects and, in the
base data view, by the child-objects.
• Inactive
Inheritance is completely deactivated. The element is neither inherited by
derived planning objects nor child-objects in the base data view.
With this option you can, for example, neutralize an element that was
inherited from the parent-object but is not needed at the object. This allows
you to prepare numerous elements at a higher level of the structure tree and
then to deactivate the elements that are not required in the lower levels.
• Inactive for base objects
Inheritance within the base data is deactivated. However, planning objects
still inherit the element.
Virtual
This option controls how often and when the element is created in the
planning project. Elements prepared in the base data but not yet created in
the planning project are called “virtual”.
The virtual and Off options do not take effect in the base data view. They
only have an effect when a planning object is created.
• [ ] times
Enter here how many times the element may be created manually.
• N times
The element can be created manually in the planning project as many times
as desired.
• Off
(Not virtual) The element is created automatically when the planning object
is created. The element cannot be deleted afterwards.
• Default
The element is created automatically when the planning object is created,
but it can also be deleted afterwards. It can be created again manually after
deletion.
Miscellaneous - Count
The field is not evaluated by Comos. In this field you can freely input a num-
ber that can be processed later as you wish.
See SECTION 12.2: “SYSTEM” TAB for all further details.

Properties: Systemtype CDevice “Connectors” tab
Preassigning wires, signals or logical potentials

There are devices in which this information is already known in advance for
certain connectors. Regardless of how often this device is used within the
planning project, this information always remains the same. In this case it is
useful to predefine the logical potential or signal or wire respectively. See
SECTION 49.4: PREALLOCATING CONNECTORS.
Creating elements in a block

1. Create an object of class Element on the Elements tab.
2. Use the Block option on the System tab.
For example, input N times for Virtual .
3. Open the Properties window of the newly created element from above and
create objects on its Elements tab – but this time without the Block
option.
Effect: If you use the | CREATE function in a planning object, it is not the block
element itself but instead the elements contained within it that are created.
12.6 “Connectors” tab
12.6.1 Interface and connector types
“All connectors” option

This toggles whether the connectors of the objects located underneath this
object are to be displayed, too, or whether only the connectors of the object
itself are to be displayed. More processing time is required if all the connec-
tors are displayed.
The default setting for devices (class: Device) and elements is “Activated”.
For all other objects, the default setting is “Deactivated”.

“Connectors” tab Properties: Systemtype CDevice
Properties window of the connectors

The Connectors tab contains details on the connection options of an object.
Each connector has its own Properties window in which the precise type of
connector is specified:
Name Unique name of the connector.

Label by owner In the case of terminals the label of the element is
also the label of the contacts. Tedious and
error-prone synchronizations and the mulitplying
of data can be avoided by using the Label by
owner property at the contacts of a base object.
If this option has been activated, the contact label
(Connector.Label) is taken over from the owner
(Device.Label) in all cases.
This option should be activated for the elements of
terminals so that copying produces the desired
results.
Label Visible labelling of the connector. Name is used if
the Label field is blank. In some cases (such as
with documents) the label is always displayed
instead of the name.
Description Long description, which also appears in the struc-
ture tree of the Navigator.
I/O Each selection option offered here has a symbol of
its own in the planning view.
Type Only connectors of the same type can be connected with

one another.
EE/MCR Electrical connection

Single line Various areas of application

P&ID P&ID connection
Signal Signal connection (e.g. control
voltage)
Functional plan Connection in logical diagrams
Fluid Connection in hydraulic and
pneumatic diagrams
Subtype The contents of this selection field depend on the

Type that had been selected and specify the type.
See SECTION 12.6.2: SUBTYPES IN THE CASE OF CONNEC-
TORS.
Single line connec- Only displayed if the Type is EE/MCR. Shows the
tor single line connector with which the EE/I&C con-
nector is joined.
ET/IC connectors Displays connectors of type ET/IC with which the
single line connector is joined. Only displayed if
the Type is single line.
Wire Shows by which wire a connector is joined with
another connector.
Feed through A feed through connector is used to pass on signal
and potential information via the connectors of a
device.
In the Feed through field, enter the name of the
connector to which the information is to be passed
on to.
Example: A switch possesses the two connectors
CP1 and CP2. CP2 is entered as the feed through
connector for CP1. If the information is to be able
to flow in both possible directions, then CP1 must
be entered as feed through connector for CP2.
Currently, only one entry can be taken into consid-
eration for a feed through connector.

“Connectors” tab Properties: Systemtype CDevice
Inheritance mode
• Active
Both the planning objects and the “child-objects” in the base data view
inherit the connector.
• Inactive
Inheritance is completely deactivated. The connector is neither inherited by
the “child-objects” in the base data nor by the planning object.
Use this mode in order to neutralize a connector that had been inherited from
the parent-object but which is not required here in this object.
• Inactive for base objects
Inheritance within the base data is deactivated. However, planning objects
still inherit the connector.
Signal of owner
The Signal of owner option joins a connector with the signal of its
owner-object.
12.6.2 Subtypes in the case of connectors
There is the Subtype field in the Properties window of connectors. This field
contains the entries defined in in the relevant @Connection table of the sys-
tem project.
Subtypes control the display of the connection at this connector, see
SECTION 47.1.2.5.1: CONNECTOR-SPECIFIC LINE TYPES.
Default subtype
A subtype @DEFAULT can also be created in standard table @Connec-
tionType [type]. This entry is then used if no special subtype had been
defined.
12.6.3 Mouse menus and mouse operation
The mouse menu onthe Connectors tab is context-sensitive. Only the | NEW
command is available if there is no connector.
Multiple selection is also available for the connectors.
New connector
Call: right mouse button, | NEW

In order to create a new connector, select the Connectors tab and press the
right-mouse button. You can now enter the name, label and description, input
/ output and specify the attributes for the new connector in the New connec-
tor below... dialog window.
Copy connector
Call: right mouse button, | COPY
The connector and all its data is copied to the Clipboard and can be pasted in
at another location (another object, another project).
Cut connector
Call: right mouse button, | CUT
The connector is deleted with | CUT but it still exists in memory (the Clip-
board). The connector that has been cut can be pasted in at another location.
Paste connector
Call: right mouse button, | PASTE
A connector that has been copied or cut can be pasted in at any desired loca-
tion. The connector remains on the Clipboard after that and can be pasted
again until you copy or cut another connector. When pasting copied connec-
tors, the name is incremented automatically.
12.6.4 Preassigning connectors with wires, signals or logical potentials

There are devices in which this information is already known in advance for
certain connectors. Regardless of how often this device is used within the
planning project, this information always remains the same. In this case it is
useful to predefine the logical potential or signal or wire respectively. Use ele-
ments to do so.
12.6.5 Effect of the implementation pointer
If the implementation pointer has been set at a planning object, the connectors
not only get the information on the potential, signal, wire and counterpart con-
nector, but also information on the cross section, color and number in addi-
tion. If the implementation is undone later on, the connectors are reset to their
original values.

Symbols” tab Properties: Systemtype CDevice
12.7 Symbols” tab
(1) (2)
(3)
(4) (5) (6) (7)
(8) (9)
(10)
Symbols display objects in a diagram type-specific way (e.g. symbols for cir-
cuit diagrams, P&ID schemes, etc.). On this tab you specify which symbols
are used to display the current object in the various types of diagrams. Apart
from assigning symbol drawings, you can also specify a corresponding text
symbol for each type of diagram.
“Symbol path” (1)

Enter the directory path to the symbol drawings. This path is the default set-
ting forthe symbol selection of thevarious types of diagrams.
The [ .... ] button opens the Find folders dialog field. You can now enter a
path. Confirm this by pressing [OK].
“Load symbol scripts” (2)

Pressing this button reloads all the symbol scripts that had been created under
this object.

Properties: Systemtype CDevice Symbols” tab
“Specifications with graphical relevance” (3)

The old form of generating an attribute-value-dependent symbol. Only
retained for reasons of backward compatibility. A better way is to use a script
(SECTION 45.4.2: SUB-SYMBOLS) for attribute-dependent display
“Type” (4) / “Kind of sheet” (5)

The entries Name/Description of the @SYSTEM@DRW_TYPE list from the
system project are shown here. The contents of the list can be extended in a
user-specific way in the system project.
“Symbol” (6)
If a symbol had already been created, this column contains a simplified depic-
tion of the symbol. If the column also contains the word „SCRIPT“, this sig-
nals that the symbol was defined in a VB script. If the symbol is not defined
through script, the path and name to the original drawing are displayed.
“Text” (7)
Similar to the Symbol column, but without the simplified symbol display.
Additional symbols can be stored here.
“Symbol” (8) / “Text” (9)

[ ... ]
Opens a file selection dialog set to the default symbol path. Selecet a symbol
drawing.
[X]
This button deletes the assigned symbol drawing. You can now select another
symbol drawing by pressing the [ ... ] button.
[S]
This button creates a free script. This way it is possible to design a symbol
yourself. When you click on this button, the Script of the symbol dialog
window opens, where you enter the script for the symbol, see SECTION 12.8.2:
THE SCRIPT EDITOR. However, as a rule you would use the Symbol Editor
(SECTION 45.3: TOOLBAR).
The [OPEN VARIANT] button opens a variants report in which a
three-dimensional object is displayed in the form of six two-dimen-
sional symbols.

“Script” tab Properties: Systemtype CDevice
“Hide unused drawing types” (10)

This option is activated in the default setting. It hides all diagram types for
which neither a symbol nor a symbol script has been defined.
The setting cannot be activated for a single base object only, but is always
activated for all base objects. (Depending on which symbols have been
defined for the base object, different diagram types will be hidden for each
base object.) The setting remains active for a working session.
12.8 “Script” tab
12.8.1 General
This tab contains a predefined set of functions, but also offers the opportunity
to write script functions of your own.
The basic structure of each function has already been prepared in advance and
cannot be changed. When selecting a function, the user can only enter com-
mands that will be executed when the corresponding event occurs.
If you wish to change s script, click on the [...] button at the far right.
If you only want to read the scripts, you can pull up the lines (drag the lines
higher) by moving the mouse on the column at the far left side of the lines.
The mouse must be positioned in the gap between two lines and then dragged
downwards while holding down the mouse button.
The various types of script blocks

There are three types of script blocks:
• The predefined script blocks for standard functions
Here you write the script that is to run in the case of standard functionalities
- for example, if two connectors are to be joined together or if a pointer is to
be set.
The functions for which there is a predefined script block cannot be defined
in any of the so-called user scripts. Thus, the mode of working differs
somewhat from that of earlier versions of Comos: in earlier versions there
was just one single, global script in which the user also defined the scripts
for standard functions. Now you have to use the predefined script blocks for
these standard functions.
• The UserScriptBlocks
Here the user can write scripts to cover all cases that are not provided for by
the predefined script blocks. The user can execute the standard functions in

Properties: Systemtype CDevice “Script” tab
the usual way and Comos automatically calls up the corresponding script
block if any script is stored there. Thus, if two connectors are to be joined in
a UserScript, Comos automatically checks whether the Connectt script
block has been implemented (whether any script is stored there).
• The script block for parameters
Parameters that are to be made available in all other script blocks are defined
here.
Advantages
The use of script blocks has the advantage that scripts can be inherited and
modified at lower levels in a systematic and controlled way. If only one large
script had been inherited, you could, of course, still edit the script at lower lev-
els of the object hierarchy. However, in that case the entire script would be
checked in and thus the inheritance chain would be broken. If you then edited
the script in a base object higher up in the hierarchy, these modification would
be lost to the objects lower down the hierarchy.
With script blocks, you can insert additional script blocks at lower levels, or
edit some of the script blocks, and all the script blocks that had not been mod-
ified are still inherited.
In addition, the use of individual script blocks is considerably faster. Many
functions involve a call to the base object. If there is only one single large
script, it is necessary to load the entire script in order to check whether there
is information in the script for this specific call.
On the other hand, if individual script blocks are used, the program recognizes
at once whether a specific call is of any importance for this base object. The
overall result is that significantly fewer scripts are loaded.
See also SECTION 22.2: SCRIPTS AT THE CDEVICE (ALPHABETICALLY).
12.8.2 The Script Editor
The Script Editor is used in many of the dialog windows in Comos, and not
only in the Properties windows of base objects. This section will give a
detailed description of the Script Editor, and other sections of this manual will
refer back to this section.

The Script Editor offers the tools a user needs to write small scripts quickly
and without complications. When the Script Editor is opened, you will nor-
mally see a predefined text that cannot be changed. Whether a text is seen, and
which one, depends on within which dialog window the Script Editor was
called. You will see something like the following:
Options
[OPTIONS]
Font
The Truetype fonts of the operating system are offered here. The font size can
either be selected from the dropdown list or entered freely by typing directly
in the field.
Color

Properties: Systemtype CDevice “Script” tab
• Keyword
(Default setting: RGB(0, 0, 128) = blue)
All lines beginning with a keywords cannot be changed at all. The list of
keywords is defined by Comos, for example, “Function” and “End
Function”.
• User-defined keyword
(Default setting: RGB(128, 128, 64) = brown)
User-defined keywords must have been passed beforehand in a TextArray
by calling the UserKeywords method. Example:
RtfScript.UserKeywords = Array("DrawArc", "DrawCircle",
"DrawLine", "DrawText")
• Comment
(Default setting: RGB(0, 128, 64) = green)
Comments are indented by a single quotation mark and are not evaluated
as script commands.
You can change the color by mouse-clicking on the Color field.
Tabulator length : Specifies by how many characters a tab is shifted. This
setting also affects tabs that have already been set.
Background image : Sets the background image of the Script Editor.
Shortcut : Here you can allocate a keyboard shortcut to a text. The stored text
is inserted when you press the shortcut. Please note that the shortcut must be
activated explicitly. It is not sufficient to simply enter a text.
All options are saved as follows:
<Windows profile of the user>\RText.xml
Default buttons
[OPEN FILE]
Opens a txt or rtf file.
[SAVE FILE]
Saves the script as a txt or rtf file. All the formatting is lost if the script
is saved as a txt file.
If the script is opened again in Comos, the keywords are recognized automat-
ically and the formatting is reassigned.
However, if the script is opened in a different program, then a txt file appears
to be unformatted while the formatting is retained with a rtf file.
[PRINT]
Opens the default printer dialog.

[CUT]
Cuts the selected text. Nothing is cut if the selection contains lines with
keywords, since it is not permitted to change such lines. (This does not apply
to user-defined keywords.)
[COPY]
Copies the selected text.
[PASTE]
Copies the text from the clipboard. Also see Cut as regards treatment of
keywords.
[DELETE]
Deletes the text. Also see Cut.
[SEARCH], [SEARCH FORWARDS / BACKWARDS]
[COMMENT] / [UNCOMMENT]
A single quotation mark is written at the beginning of the text and the
text is marked in the color that you had chosen in the options. To uncomment:
Remove the single quotation mark at the beginning of the line.
[INCREASE INDENT / DECREASE INDENT]
A tab is inserted before the text. To reduce the tab: Remove a tab at
the beginning of the line.
[HELP]
This button starts the programming help. The programming help con-
sists of at least two tabs:
Script components
Sample scripts. The sample text can be copied into your script either by dou-
ble-clicking or by using drag & drop.
Declarations
A “COM Object viewer ” that lists all the properties and commands that are
available in a component. Generally, by default the Comos.dll and vbs-
cript.dll.
Components can also be dragged manually from the Windows Explorer onto
this tab, and then all the properties and commands are likewise listed.
If you click on a node in the structure tree, the exact definition then appears
at the bottom in the information area. This definition can be brought in by
marking the text, pressing the <Ctrl> button and dragging the text into the
Script window by means of drag & drop.

Properties: Systemtype CDevice “Usage” tab
12.8.3 Conversion of old data
In earlier versions of Comos each base object only had one large script, not
several script blocks.
Please note that old data that had been produced by earlier Comos
versions must be converted manually to the new technology of using
script blocks. The advantages of the new technology cannot be uti-
lized without a conversion. In addition, the new technology makes the exist-
ing data run more slowly than it did with earlier versions of Comos. In other
words: If a new Comos version is used with an existing database without
switching over to the new technology, performance will decrease. (It will
remain roughly the same if no scripts are used.)
The [DISPLAY] button appears on the Script tab at the bottom right if there is
old data in a base object – meaning a script without the new block technology.
This opens the Script functions without block technique dialog window.
All the script functions that are recognized by the program can be distributed
automatically with the aid of the [SEPARATE FUNCTIONS INTO BLOCKS] button.
Do this by cutting the corresponding portion of the script, inserting it into the
corresponding script block and activating (= implementing) this script block.
The remaining script code that is still left in the old script must be distributed
by hand over the UserScript blocks. In the end, the dialog window should
be completely empty, because only then is the old script deleted and the speed
advantages of the new block technology take effect.
12.9 “Usage” tab
Determines where the base object is used. The fields are as follows:
• Direct, Indirect
This option switch specifies whether the planning objects that are being
searched for are directly dependent or whether a concatenation of base
objects is also permitted.

“Inheritance sources” tab Properties: Systemtype CDevice
Base objects can be derived from one another. Do this by creating a base
object “Test1”, for example, and then drag another base object “Test2” into
the Reference field of “Test1”. There are the following dependencies if a
planning object is derived from base object “Test1”:
Test2 -> Test1 -> Planning object1
If a search is made from Test2, suing the direct option, planning object1
will not be found. If you use the indirect option, then both the directly
dependent planning objects and the indirectly dependent planning objects
will be found.
Planning objects, Base objects
Planning objects only searches for planning objects. Base objects only
searches for base objects.
Using the latter you can also find base objects that possess a link to this base
object.
• Current, All
Determines whether to search the database only in the project that is open
or in all projects.
Tab, Specification
The dropdown menus are active if the marked object possesses attributes. The
Specification tab is selected from the upper dropdown menu and the attribute
from the lower menu.
12.10 “Inheritance sources” tab

This tab determines all base objects from which attributes or properties have
been inherited.
The tab is divided into two areas:
The left-hand window area contains a list of objects. The current object is at
the top of that list. Then all the sources, i.e. all the objects from which the cur-
rent object inherits information, are listed in logical order.

Properties: Systemtype CDevice “Configuration” tab
First of all, mark two objects in the left-hand list. The object marked first
appears in the Primary object edit field of the right-hand window area, and
the object marked second appears in the Secondary object field.
The difference in the information between these objects is shown at the right.
The following information is taken into consideration when doing this:
• Properties (text edit fields on the General tab, options of the System ,
Script ) tab
When properties are compared, the field remains blank if no value had been
entered for one of the objects that are investigated. Please note that if a
property is inherited, then this property is empty at the object!
When properties are compared that exist at both the objects, then both
values are listed.
• Assigned objects (specifications, connectors, elements, symbols)
When objects are compared and the object exists at the one object but not at
the other one, this is symbolized through three lines. Example: If a
connector had initially been added “lower” in the tree structure, then the
connector does not exist at the owners of the CDevice.
When specifications are compared that exist at both the objects being
compared, a black arrow symbolizes that the object was inherited. A white
arrow symbolized that the objects have been checked in.
12.11 “Configuration” tab

This tab controls the display of the planning object.

“Configuration” tab Properties: Systemtype CDevice
Group “Tab type”

This group controls where the Specification tabs are to be collected in the
planning object. If the Nested option has been activated, they are collected
on the Specification t ab. If the In one line option has been activated, then
the Specification tabs appear in one row with the main tabs (Status , Connec-
tors etc.).
Button “Inherit configuration”

If [INHERIT CONFIGURATION] was selected, then the settings from the inherit-
ance source are taken over and used. This can also be a base object pointer,
etc.
Configure display
You can configure the display of the planning object by moving the desired
components from the list of default components into the list of current com-
ponents.
Please note that as soon as one component is moved to the Current compon-
ents list , only the tabs and edit fields contained in this list will be displayed
for the planning objects. This also applies to the dynamic edit fields of the
pointers:

Properties: Systemtype CDevice “Configuration” tab
– In the default state, the edit fields for location, unit, etc., are created
automatically when the user drags a corresponding pointer onto the
planning object.
– This automatic mechanism is deactivated as soon as a manual configuration
is undertaken. The base data administrator must then explicitly provide the
fields for the pointers.
Default components
This list contains all the tabs and properties that are offered in Comos. Please
note that components are blocked if they have been deactivated on the
System settings tab , see SECTION 12.3: “SYSTEM SETTINGS” TAB.
The Separator component is used to structure the tab and inserts a line. It can
be used as many times as desired for the General tab.
Current component
Initially blank; corresponds to the display from Comos 7.0.
Prog-ID for user-defined components
Here you can enter some code that is to be used to load a customer-specific
tab.
Behavior in the event of an inconsistent configuration / tracking and

preventing user errors
If you change the display of an object, then incorrect operation can result in
fields and areas being hidden that are being used.
A further source of errors is an import operation: It is possible that the import
data includes pointer information that was not intended for use in the manu-
ally configured interface.
In such a situation Comos nonetheless attempts to process the most important
cases as described in the following.
If an object possesses a pointer of the following classes:
• unit
• location
• implementation
• alias

“Steel construction grid” tab Properties: Systemtype CDevice
then the corresponding edit fields are also displayed for this object (and only
for this one and not for all of them), even if they had not been intended to be
used on the Configuration tab. In this case the fields are also usable if nothing
else has been restricted.
Group “Navigator”
Extended display
Specifies whether the backpointers are to be displayed in the Navigator (both
for the object itself and for all subordinated objects). Performance is improved
by turning off display of the backpointers.
In that case you can no longer tell within the Navigator if another object has
been linked to this object.
In particular, it is worth switching off the extended display if you do not use
the Comos “implementation” technique. The “implementation” technique
also functions entirely correctly without the extended display, but in day to
day work it is more practical to activate the extended display.
See also Comos Kernel: SetBackpointerBehaviour.
12.12 “Steel construction grid” tab

The Steel construction grid tab is automatically displayed for certain 3D
base objects (@3D |5 |2 |06 Steel construction grid) and is available
on the Configuration tab. Steel construction can only be used in conjunction
with 3D.
A component has been registered in CDevice @3D |5 |2 |06 Steel con-
struction grid on the System tab via the CONTROL TYPE (PROGID). This
component controls the display of the following tabs in the planning view:
• Steel construction grid
• Components
• Material stream list .
Create a device to the CDevice from the 3D structure:

• The Steel construction grid tab is shown in the planning view. The tab
possesses attributes.
• If you open another device has not registered a ProgID: The Properties
window of the new device is not opened in the same window; instead a
second second window is opened.

Properties: Systemtype CDevice “Steel construction grid” tab
• If you open another device that has registered a ProgID, a refresh is done but
the Material stream list and Components tabs disappear and the Steel
construction grid tab is blank.
If you remove the CDevice from its 3D structure and paste it in at another
point in the Navigator, the following happens when you create a device:
• Not only the Steel construction grid tab is displayed but also the Material
stream list and Components tabs. All the tabs are blank.

“Steel construction grid” tab Properties: Systemtype CDevice

Properties: Systemtype Device Iconbar
13 Properties: Systemtype Device
13.1 Iconbar
Navigate “:
The first icon serves as a “menu”: a menu with Navigation com-
mands opens up when you click on it. The effect is the same as with
the Navigation commands in the context-sensitive mouse menu within the
Navigator.
Owner
The contents of the opened Properties window change: the properties
of the superordinate object in the tree are displayed. The icon is deac-
tivated for the topmost level, or in other words, the objects directly underneath
the globe.
New ...
A new object is created on the template of the active object at the same
level in the tree. The name is incremented automatically at the same
time.
Released / Locked
An object cannot be modified any more if it is locked. Whether or not
you are permitted to lock an object depends on the individual rights.
Locking or unlocking objects is handled via the Lock object function right.
A locked object can be unlocked again at any time if you have the appropriate
rights. The administrator can also edit locked objects, regardless.
Please note: there is also the option to lock only the input fields for Name ,
Label and Description via the base data.
Additional icons:
The iconbar changes according to the circumstances and then has additional
icons. Example: When the tabs are opened (the tabs are explained further
below), extra icon buttons appear as well. The most important of them are the
icon buttons for filtering:
If, for example, objects of various types are displayed on the Connectors tab,
an icon button appears for each type. When you click on the icon (the icon is
pressed in), all the connectors of this type are displayed as well. If the icon is
deselected, then all the connectors of this type are grayed out.
(Icon) Drag object

Drag & drop operations for the planning object can be carried out with
this. Dragging this symbol has the same effect as if the planning object
had been dragged within the Navigator.

Reference fields Properties: Systemtype Device
Drop...
Here you can link your data. For example, if you wish to allocate a
component to a specific location, you can drag the location object onto
this position of the Properties window. A “reference field” appears, in which
the location is input.
“Keep current window visible” :
If a Properties window has already been opened and if you now dou-
ble-click on another planning object, then normally the contents of the
window are only changed.
If the Properties window that had been opened before is to be kept, then you
must press the “Keep current window visible“ symbol. Now a second Prop-
erties window is opened when you double-click.
13.2 Reference fields

A navigation menu appears when you right-click in the text field of the
pointer. The most important references are:
Alias pointer
If an alias branch was defined in the unit or location world (i.e., if there is a
unit with the name @ALIAS on the first level), the Properties window gets
the Alias drag & drop input field.
For detailed information on the Alias functionality see SECTION 49.7: ALIAS FOR
LABELS.
Unit pointer / location pointer

Precisely one unit and one location can be set as a pointer with each “normal”
planning object (technically speaking, a “device”).
Implementation pointer
If a planning object is based on a base object with the Request property, then
the planning object possesses an Implementation field. If the implementa-
tion pointer has been made active in this way, a new planning object can be
set as the implementation in the usual way by drag & drop.
13.3 General data area

Name
The name is generated automatically or else is input.

Properties: Systemtype Device Tabs
The Automatically generate name/device tag icon button located

behind the name input field creates a new name.
Label
There is an interaction between the Name and the Label :
If a Label is input, then it covers the Name (in the Navigator, for example).
As a rule, you can sort either by Name or by Label in the list windows; at
some points either the Name or the Label can be input again as new so to
make the order of the Name and Label items consistent with each other.
The Name is the more important property from the point of view of the data
system: it is the mandatory field and, moreover, it is always unique. However,
in practice the Label is often more important, since the stock of data is clas-
sified with the aid of the “labelling systems”.
Description
The entry is italicized if the description was taken from the base object. If the
entry was made manually, the entry now becomes the “own description” of
this object and is no longer italicized.
Folder
The new planning object to be created can also be declared as a folder. A
folder only has an organizational function, e.g., to sub-divide further planning
objects. Folders are not taken into consideration in the overall labelling of an
object. This applies in particular if a labelling system exists. It is possible to
search for folders in a targeted way within list windows. The Folder option
can already be activated in the base object. If the Folder option has already
been set there, it cannot be deactivated on the planning view.
13.4 Tabs
13.4.1 Base data tab
The Base data tab is only required if new, free planning objects are created.
In this case a base object can be set here with drag & drop.
Click on the Base objects tab and search for the required template from the
data. Then use drag & drop to pull the base object from the Navigator onto the
Base object field in the opened Properties window.
Apart from the drag & drop field for the base object, this also finds the Pro-
duct data: search for base object button. See SECTION 61: PRODUCT DATA AND
MANUFACTURER DEVICE.

Tabs Properties: Systemtype Device
13.4.2 Specifications tab
13.4.2.1 Paste data from Excel into the list attribute

It is possible to copy in both directions between Excel and the list attribute.
This is done by marking the desired cells, copying them and then pasting them
at the relevant point.
An area can also be copied and pasted within a list attribute and between var-
ious list attributes.
Operation is similar to that in Excel: mouse-click in a cell, hold down the
mouse button and drag out a rectangular frame. The copying frame can be
moved as such and disappears when the ESC key is pressed.
Either the context-sensitive mouse menu or the key combinations
[CTRL]+[Ins ], [SHIFT]+[INS] can be used for the copying operation. The user
is informed if the copy and paste areas are of different sizes. If a copy process
succeeds nonetheless, the data is pasted starting from the top left.
The following commands are made available by right-clicking on the blank
gray area of the tab.
Note in this case that you should not click into a frame often used for the
design of the Specification tabs. The following mouse commands are not
available within a frame.
Further mouse menus may be available, depending on the amount of data. The
following only describes the most important mouse commands that should
always available.
13.4.2.2 Command “Update values”

Refresh/Update.
This command is only seldom required, since as a rule the tab is updated auto-
matically. There are only a few cases in which automatic updating is not done.
In the case of dynamically linked attributes, the value of an attribute is linked
with the value of another attribute. In the simplest case, this technique is used
to reduce the amount of inputting: if you enter a value for a planning object
and wish to see this in another planning object as well, you simply need to cre-
ate a “dynamically linked attribute” at the other object.
These dynamically linked attributes are also updated automatically as a rule –
unless you have simultaneously opened the Properties windows of two
objects.

You do not need the REFRESH VALUES command apart from in these special
cases.
13.4.2.3 Command “Copy tab data” / “Paste tab data”

All the values (and the associated units) are copied to this Specifica-
tions tab with the aid of the ”Copy tab data” command.
The ”Paste tab data” command is only available if data had been cop-
ied beforehand.
Once you have copied the data, you can open the Properties window of
another planning object and switch to another Specifications tab of the same
name there.
The Paste tab data menu is only displayed if the current Specifications tab
on the other planning object has the same name as the one at which the copy
operation was initiated.
The Paste tab data command now has the effect that the names of the
attributes are checked on the current Specifications tab. The corresponding
value and unit are transferred for each attribute whose name matches the name
of the attribute from which you are copying.
No new attributes are created.
13.4.2.4 Commands “Refresh static links...”

These mouse commands are only available if the Specifications tabSpecifica-
tions tab contains “linked attributes”.
The behavior of linked attributes can be controlled precisely by the adminis-
trator. Among other things, the administrator can determine whether the link
is to be updated automatically or whether the link is to be updated manually
by the user. In the latter case this is called a “static link”.
The | REFRESH STATIC LINKS commands are the commands by which the user
carries out this manual updating.
| REFRESH STATIC LINKS ON TAB
| REFRESH STATIC LINKS FOR ALL TABS
| REFRESH/UPDATE STATIC LINKS OF THE SPECIFICATION
| REFRESH/UPDATE STATIC LINKS FOR THE OBJECT
-> A sub-menu with all the linked cells appears with this command.

13.4.2.5 “Accept static links” commands

Statically-linked attributes can also be designated as valid on the planning
view. For that reason there are the following mouse commands in the Proper-
ties window of a planning object on the Specifications tab:
| STATIC LINK: ACCEPT DIFFERENCES FOR OBJECT ...
| STATIC LINK: ALWAYS ACCEPT DIFFERENCES FOR OBJECT ...
| STATIC LINK: NO LONGER ACCEPT DIFFERENCES FOR OBJECT ...
If the differences are accepted, then this has three effects:
• The orange switching background is turned off if there is a deviation
between the local value and the value of the linked attribute.
If a difference is accepted, the difference to the linked value is displayed in
the Tooltip.
• Secondly, the value is no longer marked as invalid in the status management
as well.
• Consequently the linked value is no longer transferred when a comparison
is made, but instead the local value is retained.
13.4.2.6 Read-only mode

If an object is “Read-only”, then its data can only be read and not changed.
An important area of application of the “ReadOnly” property is viewing
mode.
In read-only mode attributes can nonetheless still be opened to some extent so
that all the entries are legible.
13.4.3 Elements tab
The following objects appear on this tab:

• Planning data elements
The objects are defined on the planning view as “belonging” and simply
through the fact that the objects are located under one another in the tree
structure. Thus if an object B is located under object A, then B automatically
becomes an element of A.
• Inherited elements
The objects have already been defined on the base data page as “belonging”.
This instance is known as “inherited elements”.

• Objects of class Element

If elements are to fulfill special tasks, then they must be created with the
Element class.
| CHANGE BASE OBJECT...

A new base object can be set for the marked element by using this command.
The effect is the same as if you had opened the Properties window of the
marked element and dragged a new base object onto the Base data tab.
13.4.3.1 Option 1: Create elements via the Elements tab

| CREATE
The | CREATE command creates a new element (planning object) on the basis
of the marked template.
| CREATE N
The command opens a small dialog window.
13.4.3.2 Option 2: Create elements in the Navigator

The inherited elements are offered within the Navigator via the mouse menu:
13.4.3.3 Objects of class Element

If this involves elements of class Element , then the connectors are given after
the name, in brackets:
In the above screenshot element “e1” is an object of class Element , while ele-
ment “e2” is an object of class Unit .

To edit the connectors, open the Properties window for the element in the
usual way and select the Connectors tab.
13.4.3.4 Commands on the Elements tab

Apart from the commands described above that relate to a specific selected
element, there are also commands that affect the tabs. Do this by right-click-
ing on the white area of the tab.
New under Master
Opens the Properties window of a new planning object. You can stipu-
late a base object and input all the other data in the usual way. Once you
have confirmed with [OK], the planning object that has been defined in this
way is created as a new element directly under the “master”, i.e., under the
planning object that you had originally opened.
Paste under Master
Creates a new element under the “master” on the basis of the Comos
Clipboard. A Comos planning object must be copied first to do this.
For both commands the effect is almost the same as if you had created new
planning objects in the Navigator (as discussed further above). But it is also
more practical sometimes to be able to create new planning objects directly
on the Elements tab as well.
Sort by name
Sorts the contents of the tab by name.
Sort by label
Sorts the contents of the tab – including the virtual elements – by label.
Sort by description
Sorts the contents of the tab – including the virtual elements – by
description.
Update
Updates the tab.
13.4.4 Connectors tab
13.4.4.1 Set connectors by drag & drop

First open the Properties window of one of the two objects. Switch to the
Connectors tab.

Then select the second object in the Project Explorer and open the structure
tree in the Navigator until the connectors can be seen.
Now one or more connectors can be pulled from the Navigator onto the tab by
drag & drop.
If you selected multiple connectors, then there are two options:
1. A multiple selection was only made in the tree. In the Properties window
the free connectors are placed in order, this being the order in which they
are sorted on the Connectors tab.
2. A multiple selection was made both in the tree and also in the Properties
window. In this case Comos attempts to place the selected connectors in
order.
You get a warning message if the number of connectors thus selected does not
match up. If you decide to carry out the action nonetheless, the connectors are
processed in order until the smaller of the two groups selected no longer has
any free connectors.
13.4.4.2 Context-sensitive mouse menus

Please note: The mouse menu for the Connectors tab is context-sensitive. In
other words: The mouse menu changes according to the column.
| CONNECT WITH
When a Comos object is copied to the Clipboard, the connectors of the object
are made available via this mouse command.
| CONNECTION
The | CONNECTION mouse menu is only available in the connected with col-
umn and has the following sub-menus:
...| DISCONNECT
Breaks the connection between two connectors. The information on the
wires in the via field is likewise deleted.
...| DISCONNECT (KEEP WIRES)
wires in the via field is kept.
...| DISCONNECT (KEEP WIRES AT TARGET)
wires in the via field is kept in the target object.

...| CUT
Cuts the opposing connector, and including the information on the wires.
The opposing connector can now be linked to another connector by using
the | PASTE mouse menu.
...| PASTE
Pastes the connector that is in the Clipboard, meaning that the marked
connector is linked with the connector in the Clipboard.
| WIRES
The | WIRES mouse menu is only available in the via column and has the fol-
lowing sub-menus:
...| BREAK
Deletes the information on the wires at the connector.
...| CUT
Cuts the wires. The wires can now be allocated to another connector by
using the | PASTE mouse menu.
...| PASTE
Pastes the wires that are in the Clipboard.
| CREATE AUXILIARY CONNECTORS
A Comos connector element (Connector) can only be linked to precisely one
other connector element; in the same way that a plug can only go into one
socket. If you wish to depict the situation within Comos in which, for exam-
ple, multiple wires are connected to a terminal, you must create auxiliary con-
nectors for them; you can then envisage this case as being like a socket strip.
| CROSS-SECTION, | COLOUR, | TYPINFO
The corresponding details are allocated to a connection. However, you can
only see the allocated information once the corresponding columns have been
made visible, see below.
| COLUMNS
This entry has the following sub-menus:
...| RESET
Removes all filters and other modifications from the list window.
...| <...> MAKE VISIBLE
There are a series of commands to make additional columns visible. All
the columns that have been made visible are shown with a tick in the
mouse menu. The column is grayed out again if you click on the entry
again.
| NAVIGATE
Navigates within the Project Explorer to the object of the column.

Please note: Depending on the column, there can be different objects within
the line. In other words: The effect of the | NAVIGATE command depends on
which column it is used in.
| UPDATE
Updates the tab.
| PROPERTIES
Displays the Properties window for the object in the column.
Please note: Depending on the column, there can be different objects within
the line.
13.4.4.3 Save settings (scheme)

List windows can be sorted, filtered and expanded. These settings are saved
and made available again when another list window of the same category is
opened.
There is also the option to save the scheme belonging to a particular planning
object. Click on the Scheme icon and select the | SCREEN SCHEME | SAVE com-
mand:
Any user can overwrite a scheme.

The option | SCHEME PER OBJECT to control whether a saved scheme is also to
be loaded automatically.
If the option has been activated, a search is automatically made for a scheme
when the Properties window of a planning object is opened.
If the option has not been activated, the scheme must be loaded manually by
means of | SCREEN SCHEME | LOAD.
| DELETE: If the matching scheme has been deleted, then the “current” scheme
(the last one that was created) is used for this object.

13.4.5 Wires tab
This tab is only required for objects of type Cable (transmission routes).
13.4.5.1 General
The Wires tab gives a quick overview of all connectors (devices) linked with
this cable. This tab is only available
• if the planning object is based on a base object, class: GDevice, detail type:
Cable , or
• for type Element , detail class Wire
The wires of this cable can also be edited quickly:
| DISCONNECT Breaks the wires at the connector or at the two connec-

tors that are linked.
| SWAP Swaps two wires.
| RESET FOR ALL Removes all filters and other modifications from the
COLUMNS list window.
| NAVIGATE Navigates in the Project Explorer to the object of the
column. Please note: Depending on the column, there
can be different objects within the line.
| AUTO CORREC- Attempts to correct all incompletely or incorrectly
TION connected wires. Example: Two connectors have been
linked, but only one of the two connectors has a wire.
In that case both connectors must be linked with the
wire and the missing information on the wire is
inserted for the second connector.
| UPDATE Updates the tab.
| PROPERTIES Displays the Properties window for the object of the
column. Please note: Depending on the column, there
can be different objects within the line.

13.4.5.2 Save scheme for the Wires tab

List windows can be sorted, filtered and expanded. These settings are saved
and made available again when another list window of the same category is
opened
If, for example, a number of different settings have been made within a plan-
ning object (not of type Terminal strip ) for the Wires tab and then another
planning object is opened, the Wires tab there is filtered and sorted in exactly
the same way.
There is also the option to save a scheme for each planning object. An invisi-
ble attribute is prepared within the planning object, in which all the required
information can be saved. Click on the Scheme icon and select the | SCREEN
SCHEME | SAVE command.
Now the scheme is stored in the attribute. The following makes a distinction
between whether the scheme is also to be loaded automatically.
The option | SCHEME PER OBJECT is used for this purpose: If the option has been
activated (as above in the illustration), then a search is automatically made for
a scheme when the Properties window of a planning object is opened. If the
option was not activated, the scheme has to be loaded manually by means of
| SCREEN SCHEME | LOAD.
Document scheme
The | DOCUMENT SCHEME command also saves the scheme of the current form
of display. But the purpose is different: this scheme is to be used as output as
a list within a report. The scheme is transferred to DLL ComosWiresListIR
for this purpose and the scheme can be retrieved again from there within an
Interactive Report.
In an Interactive Report you insert a list frame and use the following com-
mands:
Set InfoDll =
CreateObject("ComosWiresListIR.ClassWiresListIR")
Set Cables = ReportObject.ScanDevices("D*")
Please bear in mind that each user can overwrite a scheme! In particular, if
you have adapted the layout of the report to a specific scheme, no users may
be allowed to save a document scheme, to thus prevent the matching of the
layout and the scheme from being lost.
The use of document schemes in reports is described in the manual.

13.4.5.3 Predetermined wires

Connectors can be prepared in such a way that there is already an allocation
of a cable / wire when the planning object is created.
Result in the planning project

If a planning object is created on the basis of this base object, it is visible in
the Connectors tab in the column above the wires. Since the connection has
not been made yet, the wire is marked as not connected by means of a cross
with a question mark.
13.4.5.4 Indeterminate wires (only for virtual elements)

Indeterminate wires can also be defined within virtual elements. The name of
the cable and an asterisk as a placeholder for the wires appears in the field:
@L.4 x 0,75.*

If the object is created within the planning project, in this example the object
“Test”, the planning object contains a virtual element “indicator”. The indica-
tor can be created with the | CREATE or | CREATE N functions. The first free
wire is automatically searched for and entered in the cable of the indicator.
13.4.6 Strip tab
This tab is only required for objects of types Terminal strip or Plug strip .
The Strip tab displays the terminal and plug objects lying underneath as well
as the connectors of these objects.
Background
Terminals strips and plug strips are set up in two stages:
1. There is one object that represents the strip. As a rule the strip itself
possesses no connectors.

2. There is an object located hierarchically underneath for each terminal or

plug respectively. Each of these terminal objects or plug objects possesses
as many connectors as are required.
Only two levels can be used together: there is no sense in creating a terminal
strip without terminal objects, nor in using a terminal object without a termi-
nal strip.
In other words: The Connectors tab is often blank in the case of a terminal
strip. The connectors of the strip are “one level deeper”, with the objects of
the terminals and plugs, and these are displayed on the Strip tab.
The Strip tab is set up as follows:
1. There is at least one entry (a line) for each terminal (or each plug)
2. Two connectors are displayed for each line: a I-connector (IN) and a O-
connector (OUT).
3. If a terminal has more than two connectors, the extra lines are added as
required.
4. Each of these lines again contains one I-connector and one O-connector,
but it is not necessary to create both of them. In such a case an icon shows
which of the two possible connectors is missing:
The I-connectors are always shown on the left, and the O-con-
nectors are always shown on the right. Here the I-connector is
missing.
Load / save scheme
A scheme can also be saved for the Strip tab. Operation is the
same as on the Wires tab, see SECTION 13.4.5.2: SAVE SCHEME FOR THE
WIRES TAB.
EE/I&C
Displays the EE/I&C connectors of the terminal objects or plug
objects.
In future more icons will be used for connectors, for example, for SingleLine
or for ANSI.

| CREATE AUXI- A Comos connector (Connector) can only be linked to

LIARY CONNEC- precisely one other connector. If you wish to depict
TORS within Comos the situation in which, for example, multi-
ple wires are connected to a terminal, you need to set aux-
iliary connectors for it. Auxiliary connectors are created
automatically in the case of potentials.
13.4.7 Status tab
See also SECTION 21: STATUS MANAGEMENT.

Operation is very simple. Open the Properties window of an object and switch
to the Status tab. If you wish to change the status value for a status, select the
corresponding entry from the corresponding drop-down menu:
1. [SET] Button of the Properties window.

A check is made as to whether the manual selection of the user is valid.
If the value is valid, the status value newly selected manually is set
recursively for the object and all the objects of its hierarchical sub-
structure.
The value is invalid, if the object or an object from its hierarchical sub-
structure supply a lower value; in this case the lower value is set.
2. [CHECK] Button on the Status tab

The current object and all the objects of its hierarchical sub-structure are
checked recursively for their status values. If the object or an object from
its hierarchical sub-structure supply a lower value, the lower value is
accepted and used for the current object.
In other words: It is checker whether a status value is valid, and if not, a
valid status value is determined. However, no data is changed.
Confirm your input with [ACCEPT] or [OK].


Properties: Systemtype Document General buttons
14 Properties: Systemtype Document

The Revisions tab is explained in SECTION 41: REVISIONS.
14.1 General buttons
Lock/Release
Prevents any changes from being made within the Properties window.
Administrators can makes changes nonetheless.
Please note: If you terminate in the properties of a report, not only can the
properties themselves not be changed, but also the report itself can no longer
be changed.
Name , Label , Description
The Name field is 256 characters long. With it you can also address external
files (Word documents, report templates) in folders lower down by means of
the document object.
Folder
This switch controls whether the name or the label respectively of the docu-
ment appear during the various functions for the output of structure informa-
tion. If the option has been activated, the name is filtered out.
Base object
Self-explanatory.

General tab Properties: Systemtype Document
14.2 General tab
Type
The basic detail as to what kind of document is involved (Word, Excel,
Report, Conval, etc.)
A number of document types possess a template document with which you
work at once (for example, Excel, Word or Text). In that case you can ignore
the other tabs for the time being.
With many document types you also need to input further details on the mid-
dle tab (the “Change tab”) before the document is functional.
The document object gets a different icon, depending on the Type . Bear in
mind that the corresponding program must be installed. For example, you can-
not use a Word document if Word is not installed.
First page
Page number of the first page.
14.3 Change tab

The caption and the contents of the middle tab depend on which document
type was selected. With some document types this functions in the same way
as the type-specific tab.
14.3.1 Comos reports
14.3.1.1 Evaluation Report

Evaluation Reports are the basis for data sheets and lists.

Properties: Systemtype Document Change tab
The Report tab is in the middle of the Properties window:
Report template
A report template is searched for here. The report template also determines the
type of plan. The Select report template window opens when you mouse-
click in the dialog field or on the [...] button.
The base project is offered first of all in the dialog window. If the
@REPORTS document group exists on the Documents tab, then this is
offered as the default. If there is no @REPORTS document group , then the
project window is initialized with the project root.
Please note: Unlike most of the other forms of Navigator display, here all the
tabs of the project are displayed simultaneously under the project root. This
also holds true if you switch to the project yourself within the drop-down
field: You can now see all the objects of all the tabs under the blue globe.
You can switch over to the planning project that had just been opened by
using the “Current ” button. The same applies here as well: If the
@REPORTS document group exists on the Documents tab, then this is
offered as the default, otherwise the project root is offered. You can switch
back to the base project with the “Base ” button.
Select the desired report template from within the AWR branch. Confirm with
[OK]. The window is closed.
Object
The “object of a report” is the basis from which all the active and automatic
functions of a report are executed. There cannot be a document that does not
possess an “object”, therefore the entry also cannot be deleted with the [X]
button. Ask your administrator if you require any other setting here @@
[OPEN]
Opens the report. The effect is the same as if you had double-clicked on the
report within the Navigator.

Change tab Properties: Systemtype Document
[PRINT]
Prints out the report at the Windows default printer. The effect is the same as
if you had selected the | PRINT | PRINT mouse command within the Navigator.
[DXF]
Exports the report as a dxf file (“write to file”).
14.3.1.2 Interactive Reports

Interactive Reports are the basis of plans and drawings.
In the middle of the Properties window is the Report tab:
Report template
A report template is searched for here. The report template also determines the
type of plan. The Select report template window opens when you mouse-
click in the dialog field or on the [...] button.
The dialog window works in exactly the same way as described above. Select
the desired report template from within the IAR branch. Confirm with [OK].
The window is closed.
Object
possess an “object”, therefore the entry also cannot be deleted with the [X]
button. Ask your administrator if you require any other setting here.

File storage
See also SECTION 30.1.1: DOCUMENTS.
Three instances of the document are saved in the case of Interactive Reports:
crp file
This is the “normal” working file.
bak file
The relevant last saved version before the current change. In other words:
each time you save the report, the bak file is overwritten with the last version.
tmp file
This file is open during the working session. If the document is closed cor-
rectly, the tmp file is deleted as well.
If a technical defect arises for any reason and the crp file becomes defective,
then either the last tmp file or the last correct version saved (bak) are available
to you.
[OPEN]
Opens the crp file, bak file or tmp file that was clicked on.
[PRINT]
Prints the report to the default printer. Only available for crp files.
[DXF]
Writes the reports to an AutoCAD file. Only available for crp files.
14.3.1.3 Evaluation Report template

The type creates a template for Evaluation Reports. See SECTION 46: REPORT
DESIGNER.
14.3.1.4 Interactive Report template

The type creates a template for Interactive Reports. See SECTION 46: REPORT
DESIGNER.
14.3.2 General documents
This document type is used if “foreign” documents are brought into Comos
by means of drag & drop.

14.3.3 External documents (default interface)
This section applies to:

• AutoCAD drawings
• Conval (all Conval types)
• Excel
• Word
• Imagineer documents
• Logocad drawings (from V.3.0)
If Triga is not installed, Triga documents can nonetheless be displayed and
printed.
• Smartsketch
• Text
• Tiff documents
Options group documents

Normal
A new external document is created by Comos. There is no template. The
external file is deleted if you switch over to one of the other two options.
Using the [DISPLAY] button, the application program of the external document
is started and a blank document is created and saved within it.
File link
The Comos object is linked with a document in the file structure. There is no
template.
No additional external file is created through this option, instead a reference
is made to an existing external file. Nothing happens if the “file link” is
switched over to “Normal” (the linked file is kept).
The [DISPLAY] button opens the application program of the external document
and loads the allocated document file under the original name (not under the
Comos name).
Reference
The base project is offered first of all in the dialog window. You can switch
over to the planning project that had just been opened by using the “Current ”
button.

Effect of the reference: A new document is created on the basis of a template.

Comos creates a new temporary file. The references can also be set by means
of drag & drop.
Please note: Unlike most of the other forms of Navigator display, here all the
tabs of the project are displayed simultaneously under the project root. You
can now see all the objects of all the tabs under the blue globe
Options group objects

possess an “object”.
You can accept the default details “Object = owner” or “Object from tem-
plate” .
14.3.4 Logicad function plan
This document type can only be used in connection with the Logicad program.
File name The original filename of the LogiCAD document (i.e.,
not the name of the Comos documents object).
Folder
[OPEN] Creates a new LogiCAD document and opens it.
14.3.5 Management documents
14.3.5.1 Grouping of documents (documents folder)

Groupings of documents are not intended to be used as a plan, but act as orga-
nizational criteria.
14.3.5.2 Reference document

This concerns a management object. An object of type reference document is
used to provide an alternative form of access to a document object. In Win-
dows you would refer to a link.


Properties: Tabs General
15 Properties: Tabs
15.1 General
15.1.1 Definition, structure and technical background
In Comos specifications or attributes belong to objects. In other words,

attributes that are not ultimately used within objects are therefore meaning-
less. See also Quickstart Basic, section “Object definition” regarding the def-
inition of objects.
Definition of the terms “specification” and “attribute”

Every CDevice, and thus every Device, has a set of attributes. This set of
attributes defines the specifications of the CDevice/ Device – for instance its
substance data, technical data, manufacturer data, dimension ect. The
attributes are collected on the Specifications tab of its Properties window,
and on the sub tabs of that tab.
In the database, these attributes are saved in objects of system type Specifi-
cation, which store all the properties necessary to create an attribute, for
instance its name, edit type, behaviour (in the form of scripts) and possibly
also a link to another specification object (= attribute).
Therefore, the graphical user interface also uses the term specification when
actually referring to attributes. Vice versa, the term attribute is also used when
speaking about objects of system type Specification.
Normal use of specifications (attributes)

Normally you edit the attributes in the properties window of every object on
the “Specifications ” tab. Admittedly it is also possible to collect attributes
“in isolation” in the so-called “attributes catalog” under base object
@Y Catalog attributes. But these “free” attributes are also only used in
turn in the properties window of an object.
Attributes are sorted by means of additional tabs, or more precisely, by the
so-called “specification-tabs .” These are tabs that are on the “Specifica-
tions “ tab. The structure is as follows:
• Object
• Specification-tab 1
- Attributes of the tab 1

General Properties: Tabs
• etc.
Specifications directly under the object

It is also possible to create specifications directly under an object. For exam-
ple, this can happen in the case of an import operation or if you create speci-
fications in the properties window of an object before the specification-tabs
were created.
Please note that if you subsequently create specification-tabs at a later point
in time, the “old” specifications continue to be located directly under the
object!
If you view the attributes in the properties window of an object, then the
attributes that were created directly under it appear to be located on a General
tab. But this is only true from a visual point of view; the attributes are not
located on a tab but instead “float” freely under the object. In this case the
structure would then be as follows:
• Object
– Attributes (apparently on the General tab)
• Specification-tabs 1-n
- Attributes of the tab
A structure of this type is very hard to make sense of and should be avoided.
Always create a specification-tab first, and only then should you
create the attributes.
Attributes and specification-tabs from an object point of view

The attributes and the specification-tabs are objects as well! Like all other
objects, attributes and specification-tabs also have a properties window.
Furthermore, specification-tabs are likewise attributes from a purely technical
point of view. In visual terms the tabs and the attributes do of course look
completely different, and that is how it appears to the normal user. But, in
technical terms, attributes and specification-tabs both involve the same object
type. This should be noted when programming Comos by yourself for specific
purposes.

Properties: Tabs Mouse menus and operation
15.1.2 Rights administration
The user must possess the “Base data” function right in order to create or edit
attributes, see SECTION 6.3.1: BASE DATA FUNCTION RIGHT. This also applies to local
base objects that are only located in the current planning project! Administra-
tors automatically possess this right.
The only actions that may be carried out without this function right are to
input a value (DisplayValue) and a unit (Label), and also the mouse menu
command | REFRESH VALUES.
15.2 Mouse menus and operation

If you open the properties window of a new base object and change to the
Specifications tab, you will initially see a blank area:
Depending on your personal working environment, the blank area can also be
stippled. Whether or not the area is shown with a grid of dots depends on
whether the tab had already been switched over to “Design mode”. See also
SECTION 15.2.1: MOUSE MENUS OF THE TAB.
The Layout check box is located at the top right. This check box should
always be switched on. If it is switched off, you are switched over to list view.
This form of display is very old-fashioned but is still supported, see also
SECTION 15.4: SPECIFICATIONS TAB: LIST VIEW.
15.2.1 Mouse menus of the tab
If you right-click on the stippled surface you will get the mouse menu of the
tab.

Mouse menus and operation Properties: Tabs
|Working mode / Design mode

Working mode
In Working mode the system behaves in more or less the same way as it will
later on in the planning object. Working mode thus simulates the subsequent
planning work or environment.
Design mode
In Design mode you can create or edit specification-tabs and attributes via the
context-sensitive mouse menu. The screen is overlaid with a grid of dots.
The other mouse menus only appear once you have switched to
Design mode.
| New ...
| New | Specification
A new attribute (specification) is created and the blank properties window is
opened, see also SECTION 16: PROPERTIES: SPECIFICATIONS. The attribute that has
just been created appears on the grid of dots at the position at which the right
mouse button was pressed.
– New attributes can also be created by creating a copy of an existing
attribute. In addition to the Copy/Paste commands that we have already
seen, it is also very convenient to make use of the properties window of
an attribute, see SECTION 16.1: CREATE COPY OF A SPECIFICATION.
– New attributes can also be created by dragging an existing attribute
from the Navigator onto the tab, see SECTION 15.2.3: ATTRIBUTE DISPLAY:
SCALING, SHIFTING, GROUPING.
| NEW | Tab
A new tab is created and the empty properties window is opened, see
SECTION 15.3: PROPERTIES OF A SPECIFICATION-TAB.
Please note: First create the tab, and then the specification! If no specifications
have been created by then, i.e., if the very first object to be created is a tab, the
virtual General tab disappears after creating that first tab.
| DELETE, | CUT, | COPY, | PASTE

The effect of these commands depends on what action took place beforehand.
Since, technically speaking, specification-tabs and attributes are the same as
objects, both attributes and tabs can be copied, cut or inserted. For that reason
it is necessary to check whether a delete or copy command affects an attribute
or a tab.
If a tab is deleted, all the attributes contained in it are also deleted.

Properties: Tabs Mouse menus and operation
The copied object (specification or tab respectively) can also be inserted on

another tab or into another base object. Inherited attributes cannot be copied
as long as the | ALL SPECIFICATIONS | DESIGN MODE command is selected.
The inserted object (specification or tab) is given the same name, or if that has
already been allocated, an alphabetic name that is generated automatically.
| ALL SPECIFICATIONS | DESIGN MODE

Inherited attributes can also be edited. Once an inherited attribute has been
edited, this is noted, and it can also be edited the next time without this com-
mand.
This command is only available if the base object is located within the current
project.
If this option has been activated, an x is shown in the mouse menu. Click again
on this mouse command to switch this option off.
| ALL SPECIFICATIONS | SHOW NAME or | SHOW DESCRIPTION as applicable

Determines whether the name or the description of the attribute is to be dis-
played. Default setting: Show description.
| PROPERTIES
The properties window of the current tab is opened, see SECTION 15.3: PROPER-
TIES OF A SPECIFICATION-TAB
15.2.2 Mouse menu of an attribute
| DELETE, | CUT, | COPY

Attributes can also be inserted onto another tab or into another base object.
Inherited attributes cannot be copied as long as the | ALL SPECIFICATIONS |
DESIGN MODE command is selected.
Since, technically speaking, specification-tabs and specifications are the same
as objects, both specification and tabs can be copied, cut or inserted. For that
reason it is necessary to check whether a delete or copy command affects a
specification or a tab.
| PROPERTIES | DISIGN OF SPECIFICATION

See SECTION 17: PROPERTIES: DESIGN OF SPECIFICATION.

Mouse menus and operation Properties: Tabs
| PROPERTIES | SPECIFICATION
See also SECTION 16: PROPERTIES: SPECIFICATIONS.
15.2.3 Attribute display: Scaling, shifting, grouping
Scaling
You can mark an attribute with a mouse-click. All four corners and the mid-
points of the sides then appear as points at which you can change the size:
If you wish to change the size, the mouse must hover exactly above one of the
grab points (the mouse pointer changes). Hold down the left mouse button and
drag the attribute into the new shape.
Shifting by a drag & drop operation

Mouse-click on an attribute and hold the mouse button down. Drag the
attribute to the desired position and then release the mouse button.
Grouping: Working with frames

When an attribute is created, the most important choice is the selection of a
“type of display.” In the Type of display list there are two selection options
that are only used to design the tab: Frame and description.
Frames
A frame groups attributes. If a frame is moved, then all the attributes that are
completely within the frame in question are moved with it.
If you right-click on a frame, you get the commands | NEW | SPECIFICATION and
| NEW | TAB in addition to the normal commands to use to edit attributes.
If a frame is deleted, the attributes that are within it are still retained. If a frame
is copied or pasted, only the frame is copied, and without the attributes within
it.
Description
A piece of text that can be moved freely is created.

Properties: Tabs Properties of a specification-tab
Attributes via drag & drop from the Navigator

Attributes can be dragged from the Navigator onto the tab in Design mode of
a specification-tab.
The result is that a copy of the attribute that had been dragged is created in the
base object.
Special case: The dragged attribute is given an entry in the Catalog specifi-
cation field on the General tab in its own properties window if:
– the dragged attribute is located under @Y and
– the dragged attribute and the specification-tab are located within the same
project.
15.3 Properties of a specification-tab
15.3.1 General tab
Description
Optional; any desired text.
Name
The name must be unique for each base object.
Sort text
If any text is entered here, the tabs are sorted by this text, otherwise by name.
If some of the tabs have sorting text and others none, all the tabs are shown
with sorting text.
Catalog Specification
A link to another specification-tab can be placed in this field. All the informa-
tion in the linked tab is then accepted (general data, attributes, scripts). The
link can either be placed with the [...] button or by dragging from the base
data. A text reference to the catalog attributes is displayed in the Navigator.
Catalog specifications can only be used within a project. Thus a catalog spec-
ification of the base project cannot be used in the case of a local base object.

Properties of a specification-tab Properties: Tabs
Tabs have been prepared in the standard database under:

@Y Catalog attributes | CHP Chapters or |CHP tabs
If a @Y Catalog attributes base object exists within the current project,

this is offered as a template when you click on [...].
Inheritance mode
Active
In this option the planning object as well as in the base data “child objects”
inherit this tab.
Inactive
Inheritance is switched off completely. The tab is not inherited in the base
data to “child objects” and the tab does not appear in the planning object.
Inactive for base objects
Inheritance within the base data is switched off. However, a planning object
inherits the tab.
Working area
The working area allocates the tab to an organizational area (process technol-
ogy, mounting, administration, etc.). Only users who are permitted to see this
working area can also see the tab. Working areas are controlled via the user
administration; see SECTION 6.4: WORKING AREAS.
15.3.2 Script tab
A specification-tab has a script attached to it, within which the user can call
up his own program code.
The use of script blocks has the advantage that scripts can be inherited in a
targeted way and extend to deeper levels. If only a single large script were to
be inherited, then it would of course be possible to edit this in deeper levels.
Nonetheless, in this case the entire script would be transfered and thus the
inheritance would be broken off. If the script were then to be edited for a
higher base object, this change would no longer have any effect on the
lower-lying objects.
With different script blocks it is possible to insert additional script blocks at
deeper levels or to edit some of them and thus inherit all the other script blocks
that had not been modified.
If you wish to edit an existing script, you have to click on the far right of the
screen on the button with the three dots.

Properties: Tabs Properties of a specification-tab
Details on operation of the script editor are given in SECTION 12.8.2: THE SCRIPT
EDITOR. You can find a reference to script functions in SECTION 22: SCRIPT
FUNCTIONS OF COMOS OBJECTS.
15.3.3 Uses tab
Determines where the specifications tab is used. The meanings of the fields
are as follows:
• Evaluation of:
– Base objects - Objects of system type “CDevice” are evaluated.
Please note that documents are not included in this, but constitute a
system type of their own.
– Planning objects - Objects of system type “Device” are evaluated.
Please note that documents are not included in this, but constitute a
system type of their own.
– All - Objects of system type “CDevice” and “Device” are evaluated.
– None - Neither “CDevice” nor “Device” are evaluated. Only the results
from option group “Considered documents ” are displayed.
• Considered documents
– Templates - All objects that can be used as document templates are
evaluated. On the one hand these are “report templates” and “interactive
report templates,” on the other hand these are MS Office documents that
can be used as templates for other documents.
– Planning - All planning documents, or in other words, objects of
system type “Documents” are evaluated.
– None - Neither “templates” nor “planning documents” are evaluated.
Only results from option group “Evaluation of” are displayed.
• Project
The selected projects are evaluated.
• Display and evaluation including inherited objects
Inherited tabs are also evaluated.

Specifications tab: List view Properties: Tabs
The comparison
The lower area makes a comparison possible:
If results appear in the upper dialog area, then:

• the current tab itself is automatically entered in the left-hand input field.
• you can click on one of the results. The tab that was clicked on is accepted
in the right-hand input field.
• the information appears in the lower list as to how the tabs in the left-hand
and right-hand input fields depend on each other.
15.4 Specifications tab: List view

List view of the tabs
Layout switched off: Overview of the attributes of the devices
in list form. This method is old-fashioned, but is still sup-
ported.
Drop down field section

The Specifications tab itself can be sub-divided into further tabs. The
attributes can thus be sorted in this way. In Layout mode the tabs appear in
the form of “index cards.”
If no additional “sub-tab” was created, then all the attributes belong to the
General tab. This situation should be avoided; always create additional tabs
instead.
New tabs can only be created in the Design view of Layout mode.
Column: Status
In this column the display shows whether the attribute belongs to the object
or whether it had been created in an element of a higher hierarchical level.
No entry: The attribute was created within this object.

(The object is the “owner”)

Properties: Tabs Specifications tab: List view
E The attribute was inherited by an element from a higher

hierarchical level. Its properties cannot be changed
SECTION 7.3: CHECK IN OBJECT.
P The attribute was checked in for this device and “fixed,”

its properties can be changed SECTION 7.3: CHECK IN OBJECT.
The checking-in is done at the level of the properties. For example, the prop-
erty Value can be checked in, while the property Control properties contin-
ues to be inherited.
Only properties that have been changed are released from the higher hierar-
chical level.
Please note that the name of the attribute is changed in the higher hierarchical
level, and thus a property that had been checked in previously could have
become unusable. Avoid changing the name of an attribute that has already
been checked in somewhere.
Column: Name Unique designation of the attribute.

Column: Description Explanatory text.
Column: Unit The unit used for this attribute.
Column: Value Displays the value.
Column: Type This column stipulates the type of unit to be used
for this attribute:
N number
T text
A alphanumeric
Column: Project Stipulates from which project the displayed
attribute comes. No entry: The attribute comes
from the project that is currently open, see
SECTION 16.3: LINK TAB.

Specifications tab: List view Properties: Tabs

Properties: Specifications Create copy of a specification
16 Properties: Specifications
Mark a specification on the Specifications tab, right-click and choose
| PROPERTIES, or else create a new specification.
Note:
For the definition of the terms “specification” and “attribute” as used in the
Comos graphical user interface and in this documentation, see section
Definition of the terms “specification” and “attribute”, P. 15-1.
16.1 Create copy of a specification

If you wish to create a series of specifications from scratch on a tab,
use the button at the top right within the properties of the specifi-
cation. Each time the button is pressed, it creates an exact copy in terms of the
form and function of the selected specification. Names are generated automat-
ically. New specifications are likewise placed exactly underneath the ones
placed previously. The newly created specifications can be edited in the usual
way. This method has the advantage that it is considerably faster when creat-
ing several specifications.
16.2 General tab for specification properties
16.2.1 Type of display
The type of display selected has three effects:

• The form of display of the specification changes, see SECTION 17: PROPERTIES:
DESIGN OF SPECIFICATION
• The script blocks that are available change, see SECTION 16.4: SCRIPT TAB.
• The options on the Link tab change as well with certain types of display, see
SECTION 16.3: LINK TAB.

General tab for specification properties Properties: Specifications
Frames
All the attributes within a frame can be moved or dragged together. See
SECTION 15.2.3: ATTRIBUTE DISPLAY: SCALING, SHIFTING, GROUPING.
Button
A text can be input in the Description field of a Button , all other inputs are
ignored. The OnClick script block must be used to make use of the button in
a meaningful way.
Checkbox
This creates a box that can be checked with a cross. A text can be input in the
Description field, all other inputs are ignored. The OnClick script block
must be used to make use of the button in a meaningful way, and if applicable,
the GetSpecification and GetDisplayValue script blocks are used as well.
Edit field
Creates a field or a standard table for user inputs.
Excel interface
An interface to open an Excel spreadsheet. This technique is obsolete. Today
an Excel spreadsheet can be created directly within the Navigator.
File selection
An interface to make a file accessible. Technically speaking, the name, and if
applicable, the path of a file are stored, but the file itself is not opened.
The selection is stored in Value . The path is always stored relative to the cur-
rent documents directory. Thus, if a file is selected from the current docu-
ments directory, then only the filename is saved but not the path.
If you require an absolute path instead of the relative path within a script, this
can be set up with the aid of a small script:
st = a.Value
If InStr(st, ":") < 1 and InStr(st, "\\") < 1 Then
st = a.Project.GetDocumentDirectory + "\" + st
End If
output st
Whereby “a” is the specification object.

Properties: Specifications General tab for specification properties
You can use the object debugger if you wish to try out the script. Open the tree
structure in the Navigator until the file selection attributes can be seen. Drag
the attributes themselves into field A of the debugger, copy the script to the
script field, and click on the execute button [!].
If the value of the attributes only includes the filename, the absolute path is
produced again. If the attributes already include the filename plus path, then
this information is taken for use without any changes.
Image selection
The following graphics formats may be used:
• Bitmap files (.BMP)
• Symbol files (.ICO)
• Cursor files (.CUR)
• Files in RLE format (.RLE = Run length encoded)
• Files in Metafile format (.WMF)
• Files in extended Metafile format (.EMF)
• GIF files (.GIF)
• JPEG files (.JPG)
Since graphics are often intended to be used as background images, the | NEW
mouse command is also made available (unlike with many other attributes) if
you click on an image specification.
Description
Creates a text that cannot be changed, which is taken from the input in the
Description field. This type of display is solely used for text.
Link
Links can also be set up to other objects for attributes, i.e., a LinkObject
pointer is set by which you can make use of another attribute with the aid of
a string that is made up of the section name and the attribute name.
The way that these attributes is used can be set on the Link tab. A more
detailed explanation of links is given in SECTION 16.3: LINK TAB.

List
Lists can quite simply be used in the same way as Excel lists, from the point
of view of the user. But to be technical, the lists attribute is a complex nesting
of attributes.
Among other things, the Description is used from the Properties of the Lists
attribute to provide text for the field in the first row and column. Most of the
inputs in the properties window are not taken into consideration. All the other
inputs and settings are taken from Design of specification, accessed via the
mouse context menu of the specification.
See SECTION 18: PROPERTIES: LIST ATTRIBUTES.
Memo field
The Memo field attribute allows texts to extend over several lines. Attributes
of this type can also be queried by means of a text field script and output in a
report.
Edit: (Min, Value, Max)

This makes it possible to enter a range of values. “Value” thus corresponds to
the default value for an attribute of type Input field .
A check is made automatically to determine whether the value is within the
Min/Max range.
If this type of display is chosen, the setting number is automatically entered
into the Type field. This setting cannot be changed.
Edit: (Min, Max)

This makes it possible to input a range of values.
If this type of display is chosen, the setting number is automatically entered
into the Type field. This setting cannot be changed.
16.2.2 Description, Name, Value

These are the “basic inputs.”
• Description
Explanatory text.
• Name
Unique designation of the attribute
• Value
Can be input or searched for from the selected Standard table .
There are input controls, depending on the Type set. If the input does not

match the type, the attribute cannot be saved. Please note that many types of
display have fixed templates in the Type field. Thus the Edit attribute
automatically always uses type number .
16.2.3 Format, Length, Unit, Type, Standard table
The input is controlled with these fields.

• Format
An input mask that must be complied with is defined in the same way as for
text masks.
• Length
A limit on the number of characters allowed during input.
• Unit
Here a unit that had been defined in the | ADMINISTRATOR | BASE DATA | UNIT
SYSTEM menu can be allocated to the value. A dialog field in which you can
select a units group (such as power or current strength) and the relevant
reference unit for the selected group by typing them in appears under the [...]
button.
The selected unit appears in a small window between the units group and the
units.
• Type
Values: number, text or alphanumeric
Which of the options is used depends largely on the selected Unit , e.g.:
Unit = Ampere, Type = numeric
Unit = Editor, Type = text
The input in the Value field is controlled according to the Type that had
been set. If the input does not suit the type, the attribute cannot be stored.
Please note that many types of display possess fixed templates in the Type
field. Thus the Edit attribute automatically always uses type number .
Standard table
A standard table that contains permissible values for the selected unit can be
allocated to the attribute under the [...] button.
In that case only the values included in the standard table can be selected in
the Value field.

16.2.4 Working area
The working area allocates the attribute to an organizational area (process

technology, mounting, administration, etc.). Only users who are allowed to
see this working area can also see the attribute. Working areas are controlled
via the user administration, see SECTION 6.4: WORKING AREAS.
16.2.5 Edit mode
Editable - normal
No limitations on access rights, no further effects on input.
Editable - high priority

The input field for the attribute is displayed in red. No further effect.
Not editable
The field is only displayed, no input is possible.
Not editable - (Value set by script)

No input at all is possible via this interface.
Editable - in base object tree only.

The value may be modified for the base object, but not for the planning object.
Editable - in base project only.

The value may only be modified in the case of base objects and only in the
base project.
Instance building
If a value is entered that had not been there before, then a new “instance” is
set up. See also SECTION 20: INSTANCES (REDUCING THE NUMBER OF OBJECTS) regard-
ing the setting up of instances for objects and attributes.
Instance building and editable - only via a script

Inputs via the interface are not possible, but it is possible to set new values by
means of a script. If a value is set by the script that did not exist before, then
a new “instance” is set up. See SECTION 20: INSTANCES (REDUCING THE NUMBER OF
OBJECTS) regarding the setting up of instances for objects and attributes.

Hidden
For normal users an attribute of this type is not visible both with planning
objects and with base objects, and it is likewise not visible in either the prop-
erties window or within the Navigator.
In the case of users with the base data function right, the attribute is visible
within the base object and can be edited, while in the planning object the
attribute is visible but cannot be edited (the value is also blocked). (Adminis-
trators automatically possess this function right.)
The advantage of this editing mode is that it simplifies the work, since you can
create an attribute at a relatively “high” level. The attribute is inherited, and
you only need to switch to Hidden for objects in which the attribute is not
required.
Graphical user interface with scripts

This edit mode has its own script commands:
• GetScriptValue
The attribute fetches the value from the script.
• SetScriptValue
The attribute passes the value to the script.
• GetScriptUnit
The attribute fetches the unit from the script.
• SetScriptUnit
The attribute passes the unit to the script.
Please note that each type of display can possess this editing mode. In other
words, an attribute of this type cannot be distinguished externally from the
point of view of a user. An Edit attribute with editing mode Graphical user
interface with scripts will possess an input field, text, and so on.
Please note that as a rule you will require both script commands.
Example: The text for the attribute is to be reset on the basis of the input: The
input is passed to Comos with SetScriptValue, and the input is fetched
back again from Comos and reset as a description with GetScriptValue.
“Values in XML limited functionality)”

If this edit mode is selected, the values are not stored in a database field but
in an XML string at the Device.

Advantage:
The specification is not checked into the project; this accelerates the import
of objects.
Note:
• Working layer context:
Changes to the specification are saved in the XML string of the owner of the
specification, i.e. at the Device. The Device is checked-in, not the
specification. The entire XML string is released.
If several users are working in the same working layer, and with the same
Device: Since the entire XML string is set, it may happen that the
modifications added by one user are overwritten by another user.
• If several users are working with the same Device: same as in the working
layer context.
• The specification does not have a timestamp.
Consequence:
• No timestamp-based revisioning possible.
• The status of the specification is not changed.
This mode cannot be used for link specifcations (Display type : Link).
Recommendation: use with statical data.
16.2.6 The Catalog specification field
A link to another attribute can be set in this field. All the information in the
linked attribute is then transferred. The link can be set by using the [...] button
or with drag & drop from the base data. A text reference to the catalog
attributes is displayed in the Navigator.
Catalog attributes can only be used within a project. Thus a catalog attribute
of the base project cannot be used for a local base object.
Catalog attributes have been prepared in the standard database under:
@Y Catalog attributes
If a @Y Catalog attributes base object already exists within the current

project, this is then offered as a template if you click on [...].
16.2.7 Planning object status, planning object status value
See SECTION 21: STATUS MANAGEMENT.

16.2.8 Inheritance mode
Active
With this option the attribute is inherited to both the planning object and also
in the base data to the “child objects.”
Inactive
Inheritance is switched off completely. The attribute is not inherited in the
base data to the “child objects,” nor does the attribute appear in the planning
object.
For example, with this option it is possible to neutralize an attribute that had
been inherited from the parent object but which is not required here in this
object.
Inactive for base objects

Inheritance is switched off within the base data. However, a planning object
receives the attributes.
Furthermore, this technique is used with:
• Objects of the Elements-Collection
• Connections.
16.2.9 The Base specification information
If this concerns an inherited specification, then this appears on the General tab
of properties window of the inherited specification under the “Base specifica-
tion” row that states from which base object this specification was inherited
from. Please note: if the specification in question is not an inherited specifi-
cation, the “Base specification” row will not appear in the properties window.
To the right of the Base specification row is a button that you can use to
open the properties window of the “original specification.”

Link tab Properties: Specifications
16.3 Link tab
16.3.1 Overview
How a link works

In the case of a link, the Value (DisplayValue) of the attribute is controlled
by the link. This requires a number of details and options to be harmonized,
and consequently a link should only be set up by system experts.
Although a link is defined on the base data side, it is only evaluated on the
planning side:
• For that reason, first of all a planning object is searched for via the type of
link.
• The specification-tab and the specification are searched for in a relative
way, starting from this device that has been read out.
• The specification then takes the values from this linked attribute, assuming
that a specification-tab and an attribute with the defined name have been
found via the link.
The fact that a search is made relative to the device to be read out can have
the result that there is an inconsistency between step 1. and step 2. if you do
not have an adequate knowledge about the system and databases, this incon-
sistency arising precisely at the point where the device being read out pos-
sesses no attribute of this name.
Since multiple attributes can access the same link, any desired number of
attributes can be controlled in dependency on a linked attribute.

Properties: Specifications Link tab
16.3.2 Types of links (Link types)
16.3.2.1 No link
No link is used. If an attribute has already been entered in the Specification
field, then it will be deleted again (after quitting the Specification proper-
ties dialog window) .
16.3.2.2 By own object

With this you can address other attributes within the planning object itself (to
which this attribute belongs). The most important addition in this type of link
concerns the details of an attribute, see SECTION 16.3.4: SPECIFICATION.
16.3.2.3 By owner
Navigation is done “upwards” by means of Spec1.GetSpecOwner from the
attribute that is currently being edited. In this way the owner is found whose
object type is not equal to the attribute (Owner.SystemTypeName <> “speci-
fication”).
If the object that has been found is a device (Owner.SystemTypeName =
“Device”), then a search is made directly in the corresponding Specificati-
ons-Collection for the name of the specification-tab.
If this exists, then the search is continued in its Specifications-Collec-

tion for the attribute name. The object that has been found is the same as the
attribute to be displayed.
From a programming point of view:
V = linked attribute
KapitelSpecName = String
SpecName = String
Set SpecificationOwner = SpecObj.GetSpecOwner
if (SpecificationOwner.SystemTypeName =
“Device“) then
Set V = SpecificationOwner.Specification
else
Set V = SpecificationOwner.SpecficationSets.
item(1).Specifications(KapitelSpecName)
Specifications(SpecName)
Endif

16.3.2.4 By linked object

Only for display type Link
When linking via an object, a pointer to an object is set at an attribute from

whose Specifications-Collection an attribute is to be displayed.
With this type of linking it is first of all necessary to determine which (plan-
ning) object is to be used. (This question does not arise with link types “Own
object” and “By owner.”)
An own attribute is input in the Specification name field for this purpose. In
other words, in this field is an attribute of the base object currently being
edited. This named attribute must possess a link. Later on the planning object
will be found via this link.
In addition, the name of an attribute must be given by which it is to be
searched for within the planning object that has been found, see SECTION 16.3.4:
SPECIFICATION.
16.3.2.5 By script function <GetLinkedSpecification>

By script function <GetDisplayValue>
The Script tab is hereby evaluated.
Special case or display type Edit (Min Value Max)
Display type Edit (Min Value Max) makes use of both a Value and of XVal-
ues and of both the <GetDisplayValue> function as well as the <GetDis-
playXValue> function on the Script tab
If link type “By script function <GetDisplayValue>” has been switched

on at the Link tab, then both functions can be addressed on the Script tab.
Please note that if an attribute is controlled by a script, write
access cannot be made or allowed! Write accesses are, for
example, the setting of a value, the joining of two connectors, or the
allocation of a cable.
If an attribute is controlled by a script and a write access is made within this
script, then this write access is carried out every time that the attribute is
“grabbed.” For example, an attribute is “grabbed” even if it is only being

displayed in the Navigator or in a dialog window. It can be seen that

attributes thus to some extent very frequently “grabbed” - and a write
operation would be initiated each time.
For example, one effect would be that the revision level function would be
affected. There is a mechanism within the revision level function to reset the
revision level under certain circumstances in the event of a change in the
data. A write process constitutes a change in the data, and that even if the
value has only rewritten itself and so no changes are visible within the
interface.
For that reason you should only use (and allow) read operations in the link
via the script!
16.3.2.6 By connector
This type of link is very similar to “By linked object.” However, in this case
a connector is used to locate an object (planning object). The Connector-
name chosen from drop-down button to the right of the field Connector
name :
This concerns the Connector-Collection from the first owner of an attribute

that is a CDevice. (Spec1.GetSpecOwner SystemtypeName = “CDevice” =>
ComboBoxList = Spec1.GetSpecOwner Connectors).
A link via a connector means the owner is found, whose object type is a device
(Owner.SystemTypeName = “Device”), from the attribute by means of
Spec1.GetSpecOwner.
The search is continued in the Connector-Collection of the device that was
found. Here the object with the selected connector name is taken from this
Connector-Collection and the connected object (“Device”) from this. The
search begins in the Specifications-Collection via this reference for the sec-
tion attribute name and continues via its Specifications-Collection to search
for the specification name.
The object that has been found is the same as the value being displayed.
From a programming point of view:
V = linked attribute
KapitelSpecName = String

SpecName = String
SpecOwner = Device
Set V = SpecOwner.Connectors.Item(“ConnectorName")
.ConnectedWith.
Owner.Specifications.Item(KapitelSpecName).
Specifications.Item(SpecName)
It is possible to enter multiple connectors. In such a case the names

of the connectors are separated with commas, as in this example:
Connectors.Item(“O1,I1"). The result is that Comos executes the mech-
anism described above for each one of the connectors in question, one after
another, until an attribute is found, and then the operation stops.
In addition, the name of attribute must be input that is then searched for in the
planning object that was found, see SECTION 16.3.4: SPECIFICATION.
16.3.2.7 About the Navigation assistant

The usage is the same as for the Navigation assistant for object queries, see
also SECTION 24.10.1.2: OBJECT EVALUATION TAB.
The libraries “Navigation library (ObjNavigator.dll); short” and
“Navigation library (ObjNavigator.dll); expanded” are available to pro-
vide help with navigation.
Cell index
Only for link type Via Navigation assistant
A specific cell within a list can be addressed within the Cell index field. Thus
this field fulfils exactly the same function as when with other types of links
an attribute is addressed with the syntax Testkap.Spec1#1.
16.3.3 Value
16.3.3.1 Static value

Only the value is accepted. The contents are not accepted at once in the case
of a static link. The user initiates the acceptance manually.
If a large number of linked attributes have to be created, the refreshing that is
required can quickly be tiresome. This option suppresses the object – and thus
also the value – from being read out.

The reading of the values (“DisplayValue”) is then carried out by means of

the script command CalculateLinkedSpecifications. This script com-
mand can be allocated to the OnClick event trigger of a button. In this way all
the links can be updated by pressing a button.
Exception: This taking over of the values does not function if the linked
attribute itself has no stored value (“Value”) of its own. That is the case if the
displayed value (“DisplayValue”) of the linked attribute was created by
means of a script.
Value/range: Operator
The operator controls the orange background, or in other words, when a value
is marked as deviating from the template in the link.
Comparison only
The linked value is not accepted automatically in the case of a static link, but
the user controls when the value is to be accepted. If the Comparison only
option has been switched on in addition, then the linked value cannot be
accepted at all, but is only used for comparison with the current value.
All the commands that are used to accept linked values are correspondingly
deactivated, such as the | UPDATE STATIC LINK command in the mouse menu.
Apply unit
If the Static option is selected, an option appears so that the unit can be
accepted as well.
Link Min/Value/Max
Only for display type Edit (Min Value Max):
If the Static or Dynamic option was selected in the Value field, an additional
dropdown field appears from which you can select whether you wish to only
link the Value or you wish to link Min, Value, Max .
For display type Edit (Min Max):
For technical reasons, the dropdown field also appears when it concerns
attributes with display type Edit (Min, Max) . However, only the entry Link
Min/Max is meaningful at this point.
Handle empty source value differently

You can find the new option Static link: Handle empty source value dif-
ferently in the properties window of the project on the Options tab.

Effect (option switched on): If nothing had been entered for the source of the
link (in other words, not “0” but no value at all) and a value had been entered
in the target attributes, then the two entries are treated as being different and
the orange background is shown.
Please note that all the other mechanisms that bring up the orange background
also work in the same way:
- you can accept the linked value by right-clicking (and thus the value will
also be deleted in this case)
- the attributes are marked as inconsistent in the status administration.
16.3.3.2 Dynamic value

Only the value is accepted.
Always get linked value

Default: Switched on
The attribute value of the link is always displayed. The result is that the
attribute value cannot be edited. The linked value is shown italicized and in
grey. The value is always updated if the attribute is used or redisplayed.
Exception: Acceptance of the value does not function if the linked attribute
itself has no stored value. This is the case if the displayed value (“Display-
Value”) of the linked attributes was created with a script.
Switched off:
First of all the linked value is displayed. However, it is possible that you enter
a value of your own. If the value that had been input manually is deleted, the
linked value appears again.
If the option has been switched off in this way, then there is a certain similarity
with the “Static” value option.
Differences:
“Orange switching” is used in the case of “Static”; not here.
There is the mouse menu | Update static link in the case of “Static”; not here.
Get linked value

Only for display types By linked object and Via Navigation assistant .
The option means that this value is checked in if the object link is removed.
Accept unit on link

The Unit that had been set is read as well in addition to the Value (Display-
Value).

16.3.3.3 Fully dynamic

All the properties of the linked attribute are accepted automatically. The
Value is accepted in both directions. An attribute that has been configured in
this way is also known as a “view attribute.”
This is mainly used to make an attribute visible and accessible again at
another point. For example, a certain number of attributes could be taken from
a larger number of attributes to make them visible on an extra tab.
Technical effect: The attribute accepts on the planning side almost all the
information of the source. The following are not accepted:
• Name.
The name is subject to a number of logic tests. For example, each attribute
must have a unique name on each tab. (However, attributes are allowed to
have the same name if they are on different tabs.) The technique of the view
attribute is intended to be used to “collect together” attributes from different
tabs. If the name was accepted automatically, this could cause a collision of
the names, since attributes from different tabs should be named the same!
• Description
As a rule, it is not the name but the description of an attribute that is visible
in the interface. And, for example, the administrator might want to make an
addition to the description to make it clear to the user that it involves a view
attribute here.
• Layout information (Design of the attribute/specification)
The view attribute can then be shifted to any desired position on the tab, for
example, and thus does not always appear exactly where it had been created
in the original.
• Information on the type of link
The original attribute itself does not need to be fully dynamically linked yet;
in principle the link is already “fully dynamic” and it is precisely this that
distinguishes the view attribute from the original.
Interactive editing of the value

You can edit the value on the planning side both in the original and also in the
view attribute.
Please note that this will change the original attribute! If you use a view
attribute, then you are not working with two attributes that only show the
same thing, but instead you are working on the same attribute in two different
views.

By contrast, things are handled differently in Value options Static and Dyna-
mic. There the linked value is displayed as well, but if the displayed value is
overwritten manually, the change is only made to the linked attribute, while
the original remains unchanged.
The interactive editing option is only visible on the planning side. This effect
cannot be checked during editing of the base data and objects. Please note as
well that you could edit all the other properties of the view attribute on the
base data side, but as a rule such editing would have no effect, since the infor-
mation of the original attribute is accepted on the planning side.
16.3.4 Specification
16.3.4.1 Overview
Available for display types:
Own object, By owner, By linked object, By connector
Within this field it is determined from which specification (attribute) the value
is to be fetched:
The text shown in the Specification field is made up of the name of the spec-
ification-tab and the specification (attribute) name, separated by a period (full
stop).
Special case for display type By own object :
For technical reasons the base object selection is offered in the same way as
for other types of display. Of course, an attribute of one’s own base object
must be selected for this type of display, otherwise there is a danger of incon-
sistency.
Please note that there is no option to ensure at this point that the selected
attribute also exists within the object that had been found via the link. An
example: If the By owner type of link was selected during editing of the base
data, it is not known definitively at that point which object is to be the owner.
For that reason you must ensure that the selected attribute actually genuinely
exists in the most recently found planning object.

Properties: Specifications Script tab
16.3.4.2 Identical names

If an * is input, then Comos searches within the target object for an attribute
with a name that is identical to that of this Attribute.
“<Tab name>.*” can also be input. This formulation searches on a stipulated
tab for an attribute with the same name.
Example: “TD.*” searches on tab “TD ” for an attribute of the same name as
that of the attribute to which the link has been defined.
16.3.4.3 Access to lists (XValues)

Access to the individual values of a list is done with the connector symbol #.
As is usual in Comos, the first entry in the list has the value 0.
Example: SD.L01#0 accesses the first value of attribute L01 on tab SD.
See also SECTION 18: PROPERTIES: LIST ATTRIBUTES.
16.3.5 Special functions of an attribute
16.3.5.1 “Product“, “Request“

This input area only appears with the following types of display:
Edit field, Edit (Min Max).
An attribute is marked relevant for product data with the help of this option.
See also SECTION 61.5: PLANNING WORK (INPUT OF PRODUCT DATA).
16.3.5.2 “3D“
Attributes are marked as 3D attributes by means of this option.
Use: The attribute must be located on the GD Geometry specification-tab. If
that is the case, the 3D option is offered in the properties window of the
attribute on the Link tab. If the tab is still missing, it can be created with the
aid of database adjustments.
16.4 Script tab
16.4.1 Block techniques with scripts
The use of script blocks has the advantage that scripts can be inherited in a
targeted way and expanded at lower levels. If only a single, large script was
inherited, you could still of course edit it at the lower levels as well. Nonethe-

Help tab Properties: Specifications
less, the entire script would have to be checked in and thus the inheritance
would be interrupted. If the script were to be edited for a higher base object,
then this change would no longer have any effect on lower-lying objects.
With various different script blocks you can add extra script blocks at lower
levels or edit some of them and inherit all the other script blocks that had not
been changed.
The basic framework has thus already been entered as unchangeable when
selecting a function. It can now be filled out with instructions that are to be
executed when the relevant trigger event occurs.
See also SECTION 22.3: SCRIPT AT THE ATTRIBUTE to refer to script blocks in more
detail.
16.4.2 Operation
If you wish to change an existing script, you have to click on the far right of
the screen on the button with the three dots.
Details on the use of the script editor can be found in SECTION 12.8: “SCRIPT” TAB.
16.5 Help tab
16.5.1 Context help
Here you can input a tooltip and a help text for the F1 key. The help texts can
be in different languages, see also SECTION 42: LANGUAGES (LOCALIZATION).
If a Webpage is entered into the Hyperlink field in accordance with the syntax
www.innotec.de, the help text is ignored and this Webpage is displayed
when [F1] is pressed.
16.5.2 Own Information window in the event of invalid input for the
attributes
Administrators can program their own Information windows, which appear

when the user makes an error.
Background: The script function IsValueValid is called up when setting an
attribute value. In this function the administrator has the option to declare a
value invalid. If a value of this type that has been declared invalid is input dur-
ing the planning work, an information window appears with the text “Value
not valid.”

Properties: Specifications Usage tab
Operation: The variable Workset.Globals.ShowSpecValueValidMsgBox =

False can be set in the script for IsValueValid. This turns off the automatic
information window and a user-defined information window can be used.
16.6 Usage tab

Determines where the attribute is used. This function is especially useful with
catalog attributes. The fields are as follows:
Evaluation of
This setting determines whether use only with CDevicen, only with devices
or with all objects is to be considered. Please note that it is not permitted to
use the “None ” option with the corresponding setting “None ” in the Consi-
der documents option, since that would make searching impossible.
Consider documents
Objects of system type Documents possess a base object of system type
CDevice , class Document . This CDevice, class Document , can possess
attribute objects just like all other CDevices and these are inherited by the
documents.
This option is not “responsible” for the CDevice, class Document but instead
for objects of system type Documents that inherited the attributes.
Templates : Only considers report templates (Interactive Report templates,
Evaluation Report templates).
Planning : Only considers Evaluation Reports und Interactive Reports. The
term “planning” thus does not relate to a planning project: planning reports
can also be created in the base project and would be considered as well.
Project
Dtermines in which project a search is made. Please note that if you are in a
planning project that you will still see all base objects on the Base data tab.
However, if the Project option was set to value Current , the base objects of
the base project would not then appear in the results shown.
Display and evaluation with inherited objects
Upper list area:

Lower list area:

Usage tab Properties: Specifications

Properties: Design of specification Frames
17 Properties: Design of specification

The selected Type of display SECTION 16.2.1: TYPE OF DISPLAY determines the
display and use of an attribute
17.1 Frames
Option “Title visible” and “Title” field
If the Title visible option is switched on, input in the Title field is visible.
Frame type
Changes the appearance of the frame.
17.2 Button
No settings concerning display.
17.3 Checkbox
Text alignment
Self-explanatory.

Edit field Properties: Design of specification
17.4 Edit field
The attribute is displayed graphically with two or three areas:
Description Value Unit

(Name/description field)
The Unit area is only displayed if a Unit had also been selected in the proper-
ties on the General tab.
Edit field type

Determines how the Value field functions:
• Text field
Values can be input as desired.
• Combo box
Values can only be selected from a stipulated list of options. For example,
this is usually the case for values from standard table.
• editable combo box
Values can be input as desired and/or taken from a list of options.
Unit
Determines how the Unit field functions:

Properties: Design of specification Excel interface
• Fix
If the option is marked, the unit cannot be changed in the display. The unit
can be changed internally (an automatic conversion is done if everything has
been configured correctly). But the same unit is still to be seen on the tab.
A fold-out menu appears if this option is not marked. There all the units that
belong to the same group of units, such as the unit that was input in the
properties of the attribute, are offered for selection.
• Length
The attribute has a special total length that can be changed as a whole by
dragging.
The Length option determines the absolute length of the Units field. The
amount of space available for the input field is thus made correspondingly
smaller. The length of the title of the attribute is not affected as long as there
is meaningful input. (An input is not meaningful if no space is available any
longer for the input field.)
• Product, request combination
If an attribute is relevant for product data, an additional information field
pops up, within which the product template is visible (see SECTION 61.3.2:
PREPARING ATTRIBUTES). This option determines the proportional length of the
field.
• Length
The Length option determines the absolute length of the attribute title. The
amount of space available for the input field thus becomes correspondingly
less. The length of the units field is not affected as long as there is
meaningful input. (An input is not meaningful if no space is available any
longer for the input field.)
17.5 Excel interface

Buttons
• File selection
If this option is activated, the user can select an Excel file.
If the option has been deactivated, the field for file selection is not displayed
in the planning object: The Excel file must already have been specified in
the base object. The user can only open this one file.
• Assignment
If this option is activated, the user can determine the allocation of attributes
to cell fields in the Excel file. The Allocation window is opened when the
Excel file is opened.

File selection Properties: Design of specification
If this option is deactivated, the Allocation window is not displayed in the

Excel file: The allocations must already have been specified in the base
object. The user can only see these.
• Edit Excel sheet
If this option is deactivated, the Edit button in the planning object is not
displayed.
• Calculate Excel sheet
If this option is deactivated, the Calculate button in the planning object is
not displayed.
• Length of the label field
Determines the absolute size of the area for the text to be input. The
remaining area is used for the file selection field and the buttons.
17.6 File selection

• Length of the label field
Determines the absolute size of the area for the text to be input. The
17.7 Image selection

The select image file dialog window opens if you select the | PROPERTIES
| DESIGN OF SPECIFICATION context menu command.
17.8 Description
No settings for display.
17.9 Link
Description length
• Determines the absolute size of the area for the text to be input. The
• Option Name/Description
Pops up an input field for the length of the name field and displays in
addition the name on the tab.

Properties: Design of specification Liste
View of the linked object

Depending on the selection, you can see the name, description or FullName
(complete system name) of the object that is addressed by the link.
• Not editable
This option controls whether you may also enter text manually in the input
field. The other dialog elements (Navigator selection via [...], the Delete
button [x] and the Navigation icon) can always be used.
The manual entry of text requires in addition the input of a “root” that relates
to the input. In this case a start object must be set in the properties of the
attribute on the Script tab in script block GetLinkObject.
17.10 Liste
The technical creation of a list specification is complex and as such will be
explained in a separate chapter. See SECTION 18: PROPERTIES: LIST ATTRIBUTES.
17.11 Memo field

• Scrollbar active
Toggles the Scrollbar in the Memo field on and off.
• Command button visible
Activates and deactivates the [...] button. A separate window in which you
can input text now opens up when you press this button.
• Description length
Determines the relative size of the area for the text. The remaining area is
used for the file selection field and the buttons.
• Name/Description check box
Pops up an input field for the length of the Name field and also displays the
name on the tab.
17.12 Edit: (Min Value Max)

See also SECTION 17.4: EDIT FIELD.
Controlled data input

This attribute has a built-in range check, regardless of any other mechanisms
that may exist:
Edit (Min, Value, Max)

Edit: (Min Max) Properties: Design of specification
If the condition Min < Value < Max does not apply, then the attribute is
given an orange background. The Min and Max fields may also remain blank.
The test of its own area is an input aid and “depends” on the attribute. For that
reason this test is independent of the type of link. In other words, this test is
done both with a dynamic link and with a static link.
Standard table for values

A standard table can be input for the value:
• An entry is to be selected within the properties window of the attribute from
the General tab in the standard table field.
• The edit field type must be set to Combo box in the design of the attribute.
The edit fields for Min and Max cannot be used with a standard table.
17.13 Edit: (Min Max)

See also SECTION 17.4: EDIT FIELD.
The value (in other words, the Value field in the properties window of the
attribute) is not used with this attribute. Any input in Value is ignored.
Instead, two expanded values are used.

Properties: List attributes Overview
18 Properties: List attributes
18.1 Overview
The technical structure of list attributes (i.e. of objects with SystemType
Specification, type of display: List) is complex.
Attribute of type “List”

Begin by creating a list attribute on the Specifications tab. However, this list
attribute does not contain any columns or rows yet (and obviously no cells
either).
The following information is taken over from the Properties of the list
attribute:
• Description
Labels the header 1 (field on top left).
• Working area
• Catalog specification
• Inheritance mode
• Tab Help : Tooltip , Help
All remaining entries and settings are taken from the Design of specifica-
tion dialog, especially the created columns and rows.
Columns
The columns of the table (or the rows, if the list was rotated on creation) will
then be added via the Design of specification dialog as additional attributes.
In other words: A list consists of an attribute that serves as a “bracket” and of
a user-defined number of sub-attributes, one for each column:
These column attributes have the following script blocks:

• IsValueValid
• GetDisplayXValue
• GetLinkedSpecification

Creating list attributes Properties: List attributes
Rows
The rows within a column are stored as values of the column attribute. In
doing so, you benefit from the fact that, even though an attribute may only
have a single “normal” value (the Value field in the properties window), it
can have as many “Extension values” as necessary.
Please note: The extension values of an attribute are invisible both in the Nav-
igator and in properties window of an attribute!
18.2 Creating list attributes

As opposed to most of the other attributes, the majority of the settings and
inputs are not entered in the Properties window of the list attribute but in its
Design of specification dialog that is opened via the |DESIGN OF SPECIFICA-
TION context menu.
18.2.1 1.: Creating and editing columns (on the “Specifications” tab)
Create new columns

• [ADD]
Internally, a new attribute is created. Name , Description and Type receive
defaults that can be overwritten. Each new attribute represents a new
column.
• [PASTE]
A new column (and thus a new attribute) is inserted after the current column.
Setting the properties of a column

• Index
Each column has a sequential index. Click on the arrow-shaped buttons
[<] [>] to run through the columns.
• Name , Description , Length , Type
These fields behave in precisely the same way as in the properties window
of an attribute, see SECTION 16.2.2: DESCRIPTION, NAME, VALUE and the following.
• Unit
When a unit is set, it then appears (in the normal alignment of the table) at
the right next to the Description column. Click on the header of the column
with a unit that has been set and then all the units in the group are offered.
The width of the column should be set accordingly, see SECTION 18.2.3: 3.:
BEHAVIOR AND APPEARANCE OF THE TABLE (“GENERAL” TAB).

Properties: List attributes Creating list attributes
• Standard table
If a standard table is set, the cell changes into a fold-out menu. However, the
fold-out menu only becomes visible once the cell has been clicked on.
• Catalog specification
This field behaves in precisely the same way as in the properties window of
an attribute.
[Link]
In this dialog window you can link a columns attribute to another columns
attribute. The dialog window basically functions in the same way as in the
properties window of an attribute. However, there is no option to make inputs
that are relevant for products or to set up requirements.
If you have already created some rows, see also SECTION 18.2.2: 2.: CREATING AND
EDITING ROWS (“INDEX” TAB); individual cells will be available in the Linkage for
dropdown menu. See also SECTION 18.2.4: 4.: EDITING INDIVIDUAL CELLS (“SPECIFICA-
TIONS” TAB).
[Script]
Script block IsValueValid
Script block GetDisplayXValue
Script block GetLinkedSpecification
18.2.2 2.: Creating and editing rows (“Index” tab)
Press [ADD] to create a row (in other words, an “expanded value” for each col-
umns attribute).
• Index
Each row has a sequential index. Click on the arrow-shaped buttons [<] [>]
to run through the rows.
• Description
A text can be defined in the Description field for each row that will
displayed in the row header.
• Description inactive
This greys out the row headers (in which there is the row text) in the table.
Please note that the table text that is the uppermost field in the row headers
is also greyed-out automatically.
Rows can be deleted again with the [REMOVE] button.

Creating list attributes Properties: List attributes
18.2.3 3.: Behavior and appearance of the table (“General” tab)
• Column
Here you can run through the columns that have been created. A width can
be entered for each column.
• Specifications vertical
As was explained above, in normal cases the columns are created by
creating additional attributes and the rows (in other words, the rows within
the columns) are covered by expanded values.
If this option is activated, then this behavior is reversed. The rows are
created by means of additional columns and the columns are created by
means of expanded values.
Please note that this changes the command scheme by which the cell values
are accessed.
The inverted display only works correctly once at least one column and one
row have been created.
18.2.4 4.: Editing individual cells (“Specifications” tab)
[Link]
You can select in the Linkage for dropdown menu whether you wish to link
the entire column or just certain cells.
Proceed as follows to link a cell:
• Select the desired cell from the fold-out menu.
• In the Specification field you can select a columns attribute by means of
the [...] button.

Properties: List attributes Limitations
• Click on the Specification field and append an index to the existing text:
This is a hash sign (pound sign, or #) followed by a number starting from
“0”. Thus #0 reads the first row of the column; #1 reads the second row of
the column, and so on.
The procedure must be repeated and the next index must be input for each cell
that you wish to link.
Effect of a cell link

The orange switching technique works for all linked cells. Orange switching
of a cell signals: the value that was input does not correspond to the linking
condition.
If the mouse pointer is held over a cell that has an orange background, the con-
dition for linking is then shown in the tool tip (the yellow memo sheet).
Cells with an orange background (i.e., condition of linking is violated) can
now also be updated individually:
Press down the left mouse button and slowly move the mouse cursor a few
millimeters within the cell.
Thus the cell is selected and a black frame appears.
The command “Update static link” is now available in the context-sensitive
mouse menu of the right-hand mouse button.
18.3 Limitations
List attributes can handle a maximum of 200 rows.
18.4 Accessing lists (XValues)

Single list values can be accessed by means of the connection symbol #.
As is usually the case in Comos, the first list entry is assigned the value 0.
For example: SD.L01#0 accesses the first value of the specification L01 on
the SD tab.

Accessing lists (XValues) Properties: List attributes

Using and linking specifications Mapping table
19 Using and linking specifications

For the definition of the terms “specification” and “attribute” as used in the
Comos graphical user interface and in this documentation, see section
Definition of the terms “specification” and “attribute”, P. 15-1.
19.1 Mapping table
19.1.1 Area of application
This is a new functionality with its own interface that allows attributes to be
linked in the planning view. All objects that are located hierarchically under-
neath the owner of the Mapping table are permitted as links.
19.1.2 Attribute on attribute
19.1.2.1 Comparison to related functionalities

Comos already provides a way to manage links in the base data view. For that
purpose, the user basically creates rules that define which attributes will be
linked in the planning view. Later, when planning objects are created in the
planning view, the attributes of these objects will be linked accordingly. (See
SECTION 19.2: OTHER LINKS FOR ATTRIBUTES.)
Mapping tables work in a completely different way:

• The planning objects that are to be linked must actually exist already.
• The objects are linked directly, without any rules.
• You cannot tell in the base data view that objects have been linked.
• The link is always static. All the mechanisms of static links are available,
including orange switching, the mouse menus on the tabs, etc.
• As with all static links, this involves two values:
DisplayValue: the value that is visible at the attribute
StaticLinkDisplayValue: the value that is kept in the background and is
determined by the link. For example, this second value is displayed in the
tooltip if the cursor hovers over the edit field.

Mapping table Using and linking specifications
19.1.2.2 Preparation
1. Database adjustment:
Select Generate system structure
Execute the first item for Mapping tables: create the node
@O|@Mappingtable.
See SECTION 49.3: DATABASE ADJUSTMENT.
Result:
@System |@O Interface |@Mappingtable Mapping table
2. Derive a planning object from the base object.

3. Open the planning object. The planning object has its own interface that
is filled in by using drag & drop.
19.1.2.3 Interface
Dialog window of a Mapping table:
Icons
At the top of the Mapping table there are three icons.
Navigate ...
The usual navigation menu for the Mapping table itself.
If you have set attributes in the Mapping table, these then have their own nav-
igation menu in the context-sensitive mouse menu. Bring that up by
right-clicking in the Specification column.
Properties
Opens the basic properties of the planning object of the Mapping table, these
being the name, label, etc.
Save as ...
Saves the Mapping table as an XML file.

Upper dialog area

Top, Specification column
The target, or in other words, the object of system type Specification in
which the attribute value will be saved. The object entered here must have the
system type Specification. Only specifications located under the owner of
the Mapping table are permitted.
Top, Description column
Contains the description of the target specification that has been set, so that it
is easier for the user to identify the specifiaction.
Top, Index column
Is required if XValues is to be addressed, for example, in the case of range
specifications or list specifications.
Top, Source object column
The object from which the information was read. That can be any object and
not just an attribute.
The Navigation assistant dialog window is called up to set an object for this
column: right-click in the Source object column, NAVIGATION ASSISTANT
menu entry. See SECTION 24.10.1.2.1: NAVIGATION LIBRARY SHORT and
SECTION 24.10.1.2.2: NAVIGATION LIBRARY EXTENDED regarding operation of the
Navigation assistant .
Top, Property column
This is the Property that is to be read.
Top, Index column
As above.
Top, Function column
Makes available a script that evaluates the lower area. See Evaluating scripts /
multiple attributes, P. 19-7.
Top, “Value ” column

A preview of which information will be transfered.
Top, Unit column
If the source is not a specification, then you can here enter the unit of the value
read from the source object.
Lower dialog area

In the lower dialog are you can, for example, set additional attributes, which
are then used in the upper dialog area in the script. It is pointless to make any
inputs in the lower dialog area if there is no script in the upper area in the
Function field.

It is thus possible to evaluate multiple attributes and to return a common

result.
However, all the other objects can also be set and read by means of the Pro-
perty column.
Bottom, Source object column
The attribute from which the information was fetched.
Navigation assistant when using scripts:
Mouse menu of the Source object column: the dialog window of the Navi-
gation assistant opens. This dialog window corresponds exactly to the
extended navigation library in the column properties of a query.
Bottom, Variable name column
The designation entered in this field can be called in the script from the
Function fieldabove.
Please note: Value and XValue of the specifications entered in the lower dia-
log area are passed as Double, i.e. without a unit. The user is responsible for
keeping track of which units the values from the lower dialog have.
Tooltips in the upper and lower areas

There are “tooltips” in the entire area of the table. The tooltip appears if the
mouse cursor hovers for more than two seconds over a cell and the cell is not
empty.
For example, the tooltip is of interest for the Value column. The value is dis-
played in the column cell in the way that it had been entered in the Unit col-
umn. If the value originally had a unit other than the setting in the Unit
column, then the value is converted or truncated.
Example: if the value actually has four decimal places, but an entry that only
has 2 decimal places had been selected in the unit column, then the value is
truncated in the cell. However, it is only the display in the cell that is actually
changed. Internally, the value remains the same. The internal value, which is
also the correct value, is displayed in the tooltip with the original value.
19.1.2.4 Script editor
General
Call: Select a cell from the Function column of the upper dialog area. Then
right-click, | Script editor command. The mouse cursor should not be inside
the cell when you do this, to avoid double-clicking.
See SECTION 12.8.2: THE SCRIPT EDITOR regarding the Script editor.

A Calc script function can be entered as function. This function is already

known:
S (String)
The S parameter stands for the variable name of the mapping table
SO (String)
SO returns the SpecOwner of the target attribute.
Example:
Function Calc ()
Calc = S("A") * SO("A").Spec("GDS.CD0056").Value
End Function
Addressing mapping table entries by a script

Example for the Object Debugger
Object a: MappingTableOwner object (dragged)
Set MappObj = a.XObj
if not MappObj is Nothing then

'-------------------------------------------------------
'The following SpecNavDefCol collection yields the
'row entries for the upper table
Set SpecNavDefCol = MappObj.GetSpecNavDefCollection

Output "SpecNavDefcol.count = " +
cstr(SpecNavDefcol.count)
'-------------------------------------------------------
'The following ScriptVarCol collection yields the
'row entries for the lower table
Set ScriptVarCol = MappObj.GetScriptVarCollection

Output " ScriptVarCol.count = " + cstr(ScriptVarCol.count)
For i = 1 To SpecNavDefcol.count
Set Item = SpecNavDefcol.item(i)
'Each item of the upper list has the following

properties
'which can also be set accordingly.
'The listing corresponds to the table columns,
'the columns that are not listed below are derived
from
'the available info of the other properties such as
'description, value, etc.
Output "Attributes : " + item.SpNestedName '
Output "Index : " + cstr(item.SpValueIndex)

Output "Source object : " +

Item.NavDescriptionOneLine
Output "Property : " + cstr(Item.PropertyQueryConst)
Output "Index : " + cstr(item.NavSpIndex)
Output "Function : " + item.ScriptText
Output "Unit : " + item.ResultUnit
OutPut "Excel-E/A : " + item.ExcelIO
Next
For i = 1 To ScriptVarCol.count
Set Item = ScriptVarCol.item(i)
'Each item of the lower list has the following

properties
'which can also be set accordingly.
'The listing corresponds to the table columns
Output "Sourceobj:"+
item.ObjectNavigator.NavDescriptionOneLine
Output "Property : " + Cstr(Item.PropQueryConst)
Output "Index : " + cstr(item.ScriptSpecValIndex)
Output "Unit : " + item.ScriptUnit
Output "Variable name : " + item.ScriptVarName
Next
Please note: If a property has been set by means of a script, then the SetChan-
ged method must be called up subsequently at MappingTableOwner so that
the archive is updated accordingly. This is done as follows in the Object
Debugger:
a.SetChanged
You must know the following as well if you now undertake to make any
changes to the Mapping table by means of a script:
Set index
Either the index that had been input in the script is used or else -1 is used for
the simple edit fields (SUIEdit).
Change object
If you wish to change either the source object or the target object, you must
work with ObjectNavigator.dll in which you set the individual steps cor-
respondingly.
Set unit
Unit.Name is always used.
PropertyConst
Corresponds to the Property-Query constants.

Using and linking specifications Other links for attributes
The function and variable name are strings that you also enter in the columns
when editing.
Evaluating scripts / multiple attributes

For example, additional attributes can be set in the lower dialog area and used
in the upper dialog area in the script. Thus it is pointless to make any inputs
in the lower dialog area if there is no script in the upper area in the Function
field.
However, all other objects can also be set and read by means of the Property
column.
Lower area, Variable name column: the designation that had been entered
here can be used above in thescript of the Function field.
Please note: the Value and XValue of the attributes that had been entered in
the lower area are passed as Double and hence without any units. The user is
responsible for keeping track of which units the values from the lower dialog
have.
Navigation assistant when using scripts:
Mouse menu of the Source object column: the Navigation assistant dialog
window opens. This dialog window corresponds exactly to the extended nav-
igation library of the Properties window of a column in a query.
19.1.3 Mapping table for Excel
Deviations from the default

The Mapping table for Excel spreadsheets works in largely the same way as
the general Mapping table. The following lists the differences.
Upper area, Target column
Here, only one cell of an Excel spreadsheet can be specified. This cell must
be pulled in by means of drag & drop.
Upper area, Excel I/O column
Specifies in which direction(s) the information is to be exchanged.
19.2 Other links for attributes

In the base data view, links for attributes can be managed in the Properties
window of an attribute by means of the Link tab. See also SECTION 16.3: LINK TAB
regarding the layout of this tab.

Other links for attributes Using and linking specifications
Linked attributes
A “linked attribute” is an attributes that can automatically or manually take
over or compare the contents of another attribute. Attributes with a link are
also called “target attributes”.
Please note that this involves two attributes in which only the contents are
matched / compared.
Static vs. dynamic links

• In the case of a dynamic link the contents are always taken over at once.
There is no opportunity for the user to affect this in any way.
• In the case of a static link the contents are not taken over at once. The user
manually initiates the taking over of the data. A static link can also be used
as a basis for comparison only, and in such a case the contents are not taken
over at all.
Which values are matched / compared and how?

The following configurations only apply for links with the Static link option.
Comparison If this option is activated, then the attribute values are

only not taken over but are merely used for comparison.
Operator The operator specifies what type of matching /
comparison it is to be.
Dropdown field You can specify here which edit fields are to be
link evaluated for the Edit (Min Max) and Edit (Min
Value Max) attributes.
The options behave differently, depending on the type of attribute.

With type Edit and with entering numbers, the effect of the operator is per-
fectly clear: = tests whether the numbers are equal, > tests whether the value
is greater, and so on.
This mechanism also functions for strings. This makes it possible to check the
alphabetical order of two Labels of type Text .
Edit (Min Max) and Edit (Min Value Max):

Using and linking specifications Calculation formulas in the “Value” field
Attribute Operator Link Result

Edit = Only link the Invalid
(min max) value
Link min/max Range test
>, >=, <, =< Invalid
Within Any Range test
outside
Edit = Only link the Value test
(min/value/max) value
Link Value and range test
min/value/max
>, >= Any Value test
<, =<
Within Any Range test
outside
Table 19-1: Permissible combinations in static links
Automatic value conversion in the case of linked attributes

If attributes are linked statically, the units of the linked attributes can differ.
The attribute values are converted automatically.
19.3 Calculation formulas in the “Value” field
19.3.1 TValue
Appends the values of various attributes.
Toggle the tab into working mode and then enter the calculation formula
directly into the attribute. The formula is only evaluated at the planning
object.
Calculation example
=TValue("VDS.VS009") & "-" & TValue("VDS.VS040")

Calculation formulas in the “Value” field Using and linking specifications
TValue
Returns the DisplayValue of a neighboring attribute (same CDevice).
Optionally, the function can have a unit inserted as text so as to always retain
the same unit if so required.
The index of an attribute value can be entered as the third parameter if the
attribute has “XValues”.
Example attribute: @3D|@PPC|@CTS|1|60|61|1|02|A|1010
19.3.2 CatStd
This function is used to fetch values from list attributes (tables).

In this case it is not the FullName of the object that is used to find the list but
instead a form of syntax is used that has been optimized for the use of PPC
catalogs. In this case the names of attributes of the GD tab can be used as
placeholders. The placeholders are replaced later by the key value of the
attribute.
The CatStd function only works with attributes that have had the 3D mode
activated on the Link tab of their Properties windows.
Preparing the project option

Base project, properties, Module options: Viper tab
Field: Standard catalogs
Default setting: @3D|@PPC|@CatStd
The standard catalog for the 3D attributes of the pipe catalog is entered here.
Help window for CatStd

The help window appears if you click on F2 in an attribute and if the 3D
mode has been activated for this attribute in the properties on the Link tab.

Using and linking specifications Calculation formulas in the “Value” field
The CatStd entry must be selected in the Function field:
Standard catalog
Here a base object is selected that must fulfil the following conditions:
• Class: Data set
• StdVal dimensions specifications tab
On this tab there is a list attribute that corresponds to the requirements of the
nominal width-dependent tables.
The position of the selected base object is entered relative to the standard cat-
alog set in the project options.
Column
Selects the column in the list attribute.
Nominal width ... , 2. Nominal width
Selects the row in the list attribute. The rows correspond to the nominal
widths.
Result
A string is created automatically from the above settings.

Calculation formulas in the “Value” field Using and linking specifications
The CatStd syntax

CatStd (Param1, Param2, Param3, Param4)
1. Param1
Param1 stands for the standard catalog, or in other words, the base object that
had been set in the Standard catalog field. In this case it is not the System-
FullName of this base object that is entered but instead a special syntax.
All the owners are investigated as follows:

BMP Designations and
Rule parameter name field specifications tabs
The entries in this attribute are translated into the following placeholders:
Norm VSTD
Nominal VC<connector number>2
pressure
Connector VC<connector number>3
form
--- Name of the base object
For example: If the entry “1. connector ” has been selected in the “Nominal
width from connector ” field, you would then get the following
= CatStd("PP.30.%VSTD%.%VC13%.%VC12%", "d", 1 )
Exactly the same case, but this time the entry “2. connector ” has been
selected:
= CatStd("PP.30.%VSTD%.%VC33%.%VC32%", "d", 3 )
You can see the differences between VC13 and VC33 and between VC12 and
VC32. Only connectors 1 to 4 are permitted.
2. Param2
The name of the column in the list attribute
3. Param3
Connector number of Nominal width .
4. Param4

Using and linking specifications Control by means of attributes
Connector number of 2. Nominal width . If the 2. Nominal width is missing

then the last parameter is missing in the CatStd expression. All the other set-
tings are mandatory.
Evaluating the CatStd expression

From a purely technical point of view, the CatStd string is always evaluated
when the 3D object is created. However, that the evaluation does not always
give meaningful results. For example, the 3D object is created as well when
the 3D planning object is opened in the Navigator.
The CatStd string is evaluated in a meaningful way if the 3D object had been
created in Viper (meaning that the corresponding object had been placed in
Viper.).
VSTD: is replaced by the current entry from the
GD Geometry tab, VSTD System standard field
VC nominal width: this is replaced by the value that had been assigned to the
object during the placing within Viper. If you select the object in the Naviga-
tor, the “Pipe class ” and “Nominal pipe size ” fields appear in Viper. The
pipe class is ignored by the CatStd function but the nominal width is evalu-
ated.
19.4 Control by means of attributes

Range attribute with own range checking
Comos defines an attribute type that provides built-in range checking, regard-
less of any other mechanisms:
Edit (Min, Value, Max)
If the condition Min < value < Max is not met, then the attribute is shown
with an orange background. The tooltip – the little yellow Post-It note –
shows the reason for the orange switching. However, the Min and Max fields
may also be left blank.
The testing of the actual range is an input assistance and “sticks” to the
attribute. The range checking is independent from the link type. In other
words, this test is performed both for a dynamic link and for a static link.
Additional input assistance

Attributes have a series of options that can also be used in connection with a
flow of data. For example, the following options are useful to reduce the error
rate in input:

Editing attributes in a group Using and linking specifications
• The entering of numbers can be made mandatory.

• The format and length of the edit field can be specified.
• Instead of allowing free input, the input of a value can either be optional or
else be enforced from a fixed and defined list (standard table).
• Instead of allowing free input, the selection of the units can also be enforced
from a fixed and defined menu (units group).
• The edit mode can be changed.
Automatic value conversion within an attribute

There is the option to include the automatic conversion of units for attributes.
In this case the selection of the unit is done from a fixed and defined list and
the value is converted automatically.
19.5 Editing attributes in a group

You can see at once from the Specifications tabs which values had been
entered by yourself and which values had been entered by other users:
Text color: black No change within the past 40 hours.

Text color: blue Own change
Blue (pale): change within the past 40 hours.
Blue (dark): change within the current session
Text color: red Change by another use
Red (pale): change within the past 40 hours.
Red (dark): change within the current session
Only for completeness:
Background color: yel- Instantiating attribute
low
Background color: pink Timestamp matches the comparison stamp
Collisions when working with attributes

In the case of simultaneous data access it is conceivable that two users carry
out an action at the same time. For example, they could create an attribute of
the same name on the same tab.

Using and linking specifications Editing attributes in a group
No data is lost in such a case. The user is informed of the collision and can
decide whether the duplicate attribute is to be deleted.

Editing attributes in a group Using and linking specifications

Instances (reducing the number of objects) Project option instances
20 Instances (reducing the number of objects)
20.1 Project option instances

This option controls whether local instances are to be set up.
In other words: if this option is not activated, then no further instances are set
up if the base objects and the attributes (specifications) have been set up cor-
respondingly.
20.2 Definition of setting up instances

Attributes (specifications) are defined in the base object and then these are
inherited by the planning objects SECTION 7: INHERITANCE. Once the properties of
the inherited attributes are modified within the planning project, these prop-
erties are checked in and become a constituent part of this planning object.
For that reason it is not important that precisely this that had been checked
could appear at another point within the planning project.
Example
A Test attribute with the values Yes and No is provided within the base
object. This attribute is set to Yes or No for each planning object, and thus it
is checked in. If there is a large amount of data – to take an example, 10,000
data records – the Test attribute is checked in, or created, 10,000 times. It
would be more efficient if the attributes only had to be created twice – once
for Yes and once for No – and all that was needed was a reference to one of
those two characteristics in the planning objects.
This procedure is called “Instance building” within Comos.
A new base object is created locally for this setting up of instances, under
which a tree is created, within which the instances are managed. Since this
tree takes up memory, the additional overhead for the storage of the tree be
set off against the saving from the reduced number of attributes to be checked
in. It is not worthwhile to change over a whole project to setting up instances
at one go. Setting up instances is useful in the case of attributes that can only
take a small number of values – from a closed list, for example – and which
are used frequently.

Prepare base objects for instances Instances (reducing the number of objects)
20.3 Prepare base objects for instances

The administrator determines whether or not attributes lead to the setting up
of instances:
1. The corresponding base object is opened in the base project.
2. The Instance building check box is activated on the Data tab:
3. Attributes are declared as relevant for the setting up of instances on the

Specifications tabs.
The Edit mode field is set to the instance building value for this
purpose:
Color marking when setting up instances: attributes that have been declared
in this way are highlighted in pale yellow in the input field.
20.4 Planning objects with the setting up of instances

Planning objects are given the command for the setting up of instances from
the base object, and consequently it is not necessary to make changes in the
planning objects.
1. As is usual, a planning object is given a reference to a base object. This
base object can set up instances.
2. On the Specifications tabs there are attributes that are highlighted in pale
yellow.

Instances (reducing the number of objects) Effects within the planning project
If values are input for the first time here and confirmed with [OK] (and if
there is no corresponding base data branch yet), then a @LocalInstance
branch is created within the planning project.
The following levels are created within this structure branch:
• @LocalInstance
Base object for all instances
• For each base object: the tree structure is set up as in the base project so that
there is exactly one base object in @LocalInstance for each base object that
can set up instances. This base object in @LocalInstance is also called
“OwnerInstance.”
The OwnerInstance is a unique link between the planning objects, the
instances, and the associated base object:.
• Instances
An instance base object: is created for each input that differs. Identical
inputs access the same instance base object.
20.5 Effects within the planning project

In day to day work there is the long term advantage that there is an improve-
ment in performance due to the reduction in the number of objects.
Once the OwnerInstance has been determined for the objects, all the subse-
quent steps such as the creation of instances when new attribute values are
input is done automatically.
But it is not only the input of attribute values that can create instances. There
are also existing planning objects with values; if a base object that is capable
of setting up instances is set up in this way for a planning object of this type,
then the instances are created. In other words: if the base object pointer has
been set within the properties window of the planning object, a check is made
to see whether instances are to be created, and this also applies to all values
that had been input into the planning object up to that point.
This does not cover the case in which a base object is retrospectively declared
as capable of setting up instances; in such a case it is necessary to retrospec-
tively make the planning data capable of setting up instances, for which see
below.

Effects within the planning project Instances (reducing the number of objects)
Properties window for planning objects

The planning objects no longer refer to the base object within the base project
but to the local OwnerInstance in @LocalInstance :
@Use LocalInstance branch

The instances can be used in the structure underneath @LocalInstance ,
meaning that an instance can be dragged into the Base data field in the case
of a new planning object. The attribute values of this instance are accepted.
The effect is the same as if the original base object had been used, and the val-
ues of the original base object were the same as the values that were stored in
this instance.
It is also possible to change the attribute values of an instance. In this case all
the planning objects that refer to this instance are given the new attribute val-
ues. However, this option should only be used by very experienced users,
since attribute values could be duplicated if this option is used carelessly. This
would violate the principle behind the setting up of instances, namely, that
there should be only one instance for each separate attributes value, and this
could lead to inconsistency.
We therefore recommend that instead you should make any large-scale retro-
spective changes to the attribute values by using the bulk processing function,
since it includes a check of the data.
You can quickly see from the @LocalInstance tree for which values an
instance has already been created: the attributes value that is capable of setting
up the instances is also displayed on the last level next to the name of the
object.

Instances (reducing the number of objects)Retrospective setting up of instances
20.6 Retrospective setting up of instances

Modifying the properties of the base objects
This dialog window is used to make retrospective changes to the rules for
instance creation to apply to an existing stock of data.
Example: In a base object, an existing attribute was changed over to instance
creation and planning objects had already been created use this base object
(and these attributes).
As described above, a base object is declared as capable of setting up
instances and then the edit mode of the attribute is modified accordingly.
Dialog window “Edit instances”

Use the | EXTRA | CHECK | EDIT INSTANCES command.
There are two options available:
1. Investigate local instances

• The modified base object is dragged into the dialog field with drag & drop.
In this case all the planning objects that were derived from this base object
are investigated.
• A planning object is dragged into the dialog field with drag & drop. All the
planning objects underneath the node (but not the node itself) are
investigated.
Instances are created automatically in both cases.

Retrospective setting up of instancesInstances (reducing the number of objects)
2. Summarize and reduce local instances

After prolonged work, it can happen that the instances branch includes super-
fluous information at the third level. For example, planning objects may have
been deleted and the instances are not required any longer. Or an import oper-
ation may have resulted in multiple instance objects with exactly the same
attribute values and the same Original CDevice in duplicate.
The “Summarize local instances” function checks in such cases and deletes
any redundant or duplicated CDevice entries from the third level.
Any related information is saved in file instances.txt, which is in the Win-
dows Temp directory.

Status Management Preparing base objects
21 Status Management
Status management is a control instrument in Comos. It is used to classify
objects (and thus data). For example, you can stipulate which data is still to
be processed and which data is already finished.
21.1 Preparing base objects
21.1.1 Base object @Status
All the templates for status management are controlled via base objects and
collected under the following common root:
@System |@D Daten |@Status
Up to 13 base objects can be created under this root object, each one of which
represents a special status:
These up to 13 statuses allow for a delineation of the monitoring flows by

content. The base objects are created as follows:
• Class Data record
• The object must have as its name a number betweeen 1 and 13. The name
does not need to be numbered in sequence, but it must be within the numeric
range from 1 to 13. If there is a gap in the numbers, the corresponding gap
is also shown in the Properties window, see SECTION 21.1.2: BASE OBJECTS,
SYSTEM TAB.
• The description later becomes the status text that is visible to the user.

Preparing base objects Status Management
The status values display the the progress of the data monitoring within each
monitoring sequence - for each status. These status values are created as ele-
ments within the status base objects on the Elements tab:
The elements are created as follows:

• Class Element
• The object must have as its Name a number between 0 and 3. All four
elements must be created.
• The Description later becomes the status value text that is visible to the
user.
Special attributes in status management

Check 3D / P&ID connections
Attribute activated: The status management checks in addition whether
objects have been placed both in a P&ID report and also within Viper. Objects
that only appear in or other form are note in the information list.
Collision
Only created within the default database for status 9 3D collision . This
attribute is used by Comos to identify the status that is responsible for colli-
sion. The attribute has no further effects.
21.1.2 Base objects, System tab
The Status input group is on the System tab of each base object at the very
bottom:

Status Management Preparing base objects
The number and position of the visible input fields depend on which status
objects had been created under @Status.
A value from 0 to 3 can be entered in the fields. This thus determines which
values appear for planning objects that are created on the basis of this base
object.
The input fields for the status are jointly checked in or inherited. Also, if only
local input is made, all fields are checked in and thus are no longer displayed
recursively. And also vice versa: If you press the [X] button, all the local
inputs are deleted and all fields are inherited again.
21.1.3 Controlling the status through attributes
Attributes Properties window, General tab:

Field Planning object status
The created statuses are available in this field. The attribute can be allocated
to exactly one status.
Field Planning object status value
A status value is determined for the status selected above. This status value is
set in the event of an error.
The allocation of the attribute to status management can be removed again by
pressing the [x] Delete button.
Effect for status management:

The above two items initially have no effect. They are only evaluated when
the user selects | CHECK or | SET within the status management.
In this case all the attributes that related to this status are evaluated for a plan-
ning object. If an inconsistency is found in the case of an attribute, the
attribute in question is reduced to the selected status value. An inconsistency
in an attribute can also be seen in the Properties window of the planning
object: the attribute is shown in orange on the Specifications tab.
There are the following causes of inconsistency in an attribute:
• A product data-related attribute infringes the details in the actual unit. See
SECTION61.6.3: DEVIATIONS FROM THE MANUFACTURER DEVICE TEMPLATES (ORANGE
BACKGROUND).
• A range attribute Edit [Min Value Max] infringes the checking of its own
range.
• The value of the attribute does not correspond to that of the static link.

Status management on the planning side Status Management
If multiple status-related attributes exist in the object, then ultimately the low-
est status value takes effect and is set for the object.
21.1.4 Controlling the status through a base object script
The script blocks CheckStatus1 - CheckStatus13 are located in the Proper-

ties window of a base object finden on the Script tab.
These functions are triggered if you click on the [CHECK] or [SET] buttons on
the Status tab of a planning object for the relevant status.
The text shown in the Info column of the calculation log can be defined by
means of Workset.Lib.StatusInfo. Example:
Function CheckStatus1()
Res = 3
k = InStr(Name, „_“)
If k > 0 Then
Res = 1
Workset.Lib.StatusInfo = „Name not valid.“
End If
CheckStatus1 = Res
End Function
21.2 Status management on the planning side
21.2.1 Setting the status in the Properties window

There is the Status tab in the Properties window of a planning object. If the
status value is to be changed for a status, the corresponding entry can be
selected from the drop-down menu:
1. [SET] button of the Properties window.

Status Management Status management on the planning side
This checks whether the manual selection of the user is valid.

If the value is valid, the new status value that had been selected manually
is set recursively for the object and all the objects in its hierarchical sub-
structure.
The value is invalid if the object or an object from its hierarchical sub-
structure supplies a lower value; in this case the lower value is set.
2. [CHECK] button on the Status tab
The current object and all the objects of its hierarchical sub-structure are
checked recursively for their status values. If the object or one of its
objects from its sub-structure supplies a lower value, the lower valve is
taken over and set for the current object.
In other words: A check is made to see whether a status value is valid, and
if it is not, then a valid status value is determined. However, no data is
changed.
Effect of checking and setting: See SECTION 21.2.4: STATUS CALCULATION LOG.
21.2.2 Setting the status within the Navigator
Status display
First of all the display of a status is switched on in the Navigator. Right-click
in the white area of the Navigator and select | STATUS DISPLAY
All the objects in the Navigator are colored once you have switched on one of
the status types. The colors symbolize the relevant status level. The status
level describes the progress of the data monitoring within a monitoring
sequence (meaning: within a status).
The relevant color of an object in the Navigator is the same as the color of the
status value on the Status tab in the Properties window.

Status management on the planning side Status Management
Check or set status

If you right-click on an object, then the | SET STATUS and | CHECK STATUS com-
mands are available (in the same way as in the Properties window):
Effect of checking and setting: see SECTION 21.2.4: STATUS CALCULATION LOG.
Control Navigator commands via a script

You can also generate individually the entries in the mouse menu of the Nav-
igator. The usage is the same as for the other classes from PPGeneral.dll:
The component that controls the popup must have a global variable per class
(in the case for PPStatusCheck, PPStatusSet) and the Add method must be
run in PopUp_Popup. Do not forget ShutDown when closing.
Example:
' Global variables:
Dim mPPStatusCheck As ComosPPGeneral.PPStatusCheck
Dim mPPStatusSet As ComosPPGeneral.PPStatusSet
. . .
. . .
Private Sub Popup1_Popup()
. . .
If mPPStatusCheck Is Nothing Then
Set mPPStatusCheck = New ComosPPGeneral.PPStatusCheck
End If
mPPStatusCheck.Add Popup1, m_CurObject
If mPPStatusSet Is Nothing Then

Set mPPStatusSet = New ComosPPGeneral.PPStatusSet

Status Management Status management on the planning side
End If
mPPStatusSet.Add Popup1, m_CurObject
. . .
End Sub
. . .
Public Sub Shutdown()
. . .
If Not mPPStatusCheck Is Nothing Then mPPStatusCheck.Shutdown
Set mPPStatusCheck = Nothing
If Not mPPStatusSet Is Nothing Then mPPStatusSet.Shutdown

Set mPPStatusSet = Nothing
. . .
End Sub
21.2.3 Automatic status change
Another status value can also be the result in other objects as well due to a sta-
tus that had been increased (manually). The Min-Max rule is applied here:
1. If the status was set manually for an object, all the objects lying
unterneath it are given this status as a maximum. Lower status levels are
retained.
2. If the status was set manually for an object, all the objects lying above it
are automatically checked to determine whether they can also be raised to
this status. The check is positive if all the objects lying underneath the
relevant object possess at least the new status per object that had been
checked.
21.2.4 Status calculation log
If a status value cannot be set, the Status calculation protocol dialog win-
dow opens up with the appropriate information:
Column Object
This shows in which planning object a problem had been found. If you right-
click on a cell in this column, you are then offered the Navigation menu.
Column Description
The description of the object.

Allocation of rights for status management Status Management
Column Status value

Displays the status value of the object for the status currently set within the
Navigator. These details are thus identical to the details given on the Status
tab in the Properties window of the corresponding object.
Column Inconsistency
Shows the exact reason why the status value could not be set. The text shown
here can also be set by a script, see SECTION 21.1.4: CONTROLLING THE STATUS
THROUGH A BASE OBJECT SCRIPT.
Column Type
The reasons stated in the Inconsistency column are divided into three types.
The following texts can appear here:
• Status value at the object
As was explained above in SECTION 21.2.3: AUTOMATIC STATUS CHANGE rule 1, if
a new status is set, then all the objects lying unterneath the object in question
are given this status as a maximum, while lower status values are kept
unchanged. This type of message occurs if that is the case. You then see
“Lower value at object ” in the Inconsistency column.
• Attribute value
Attributes can be relevant to the status, see SECTION 21.1.3: CONTROLLING THE
STATUS THROUGH ATTRIBUTES.
• Script
There is the option to influence the status management by means of a script,
see SECTION 21.1.4: CONTROLLING THE STATUS THROUGH A BASE OBJECT SCRIPT.
Column Value , Linked value , Value min , Value max
Corrections can be made here at once if this involves information type Attri-
bute value .
“| UPDATE STATIC LINKS” (via the mouse menu)
As was explained in SECTION 21.1.3: CONTROLLING THE STATUS THROUGH ATTRIBUTES,
a static link can also cause an attribute to be marked as inconsistent. The static
link can be subsequently evaluated again by means of this command to deter-
mine if the inconsistency still exists.
21.3 Allocation of rights for status management

See SECTION 6.8: GRANT RIGHTS FOR STATUS MANAGEMENT.

Script Functions of Comos Objects General
22 Script Functions of Comos Objects
22.1 General
The following states explicitly when each script function is triggered. This
means:
Interface: This function is only triggered when the user manipulates the data
via the interface. Example: when an attribute is changed via the Specification
tab. On the other hand, these script blocks are not executed if the data is edited
in another way, such as by a script or an import, etc.
Comos: This function is always triggered, regardless of the way in which the
data is manipulated.

If this option is switched on, then in the event of a script error the location of
the error is shown in the corresponding script editor of the object that possess
the defective script.
Under certain circumstances a change of project can also take place within the
base project.
The user can now correct the script error directly or query the properties of the
object. In addition, the global variables can be queried.
22.2 Scripts at the CDevice (alphabetically)

The following script blocks are available when you open the Properties win-
dow of a base object and switch to the Script tab, see SECTION 12.8: “SCRIPT” TAB.
Depending on which class property the base object has, not all the script
blocks are available.
If you wish to modify an existing script block, you must click on the far right
on the button with the three dots.
Tip: if you wish to test the trigger of a script block, simply write msgbox “OK”
in the script.

Scripts at the CDevice (alphabetically) Script Functions of Comos Objects
22.2.1 CalcNextName ()
Trigger: Interface
The script block is called when you click the Generate Name / Label auto-
matically icon switch on the device. The script block is called only here.
A new name is computed for the planning object.
22.2.2 CheckDelete (Object)
Trigger: Interface
Returns the error text and prevents the deletion of an object.
22.2.3 CheckStatus[1-13]
Triggertrigger: interface
The function is triggered when you click on the [CHECK] or [SET] button on the
Status tab of a planning object.
A function has also been prepared for each of the prepared status types:
CheckStatus1 reacts to Status 1, etc.
22.2.4 Connect(Connector)
Trigger: Comos
Is called up when connecting two connectors.
22.2.5 CreateDocumentGroup (class document)
Trigger: Before the document referencing.

If the “Reference automatically” project option is enabled, the document ref-
erencing takes place each time a document is saved.
This script function is processed just before the automatic document referenc-
ing is carried out. CreateDocumentGroup is an easy means to create addi-
tional document groups. It is not possible to use it to change the mechanism
of the automatic referencing. The following still applies with regard to auto-
matic referencing: Through name comparison it is determined whether a doc-
ument group exists in which the document must be referenced.
But with the help of the above function, you can generate the corresponding
structure in the document groups, so that a document group with a matching
name will be found during automatic referencing.

Script Functions of Comos Objects Scripts at the CDevice (alphabetically)
22.2.6 DeleteWarning (Object)
Trigger: Interface
Returns a warning message if an object is to be deleted.
22.2.7 DisConnect(Connector)
Trigger: Comos
Is called when disconnecting two connectors.
The script block is also executed when linking already linked connectors.
Reason: During this action, the connectors are first separated, then connected.
22.2.8 GetConnectorLabel (Connector)
Trigger: Script
Returns the label of the Connector object. Also supports a prefix, e.g. Q?1.
The question mark is replaced by the owner’s label.
22.2.9 GetConnectorSpecification (Device, ConnectorName,

SpecName)
Trigger: Comos
This is used to also be able to find the attribute that is being searched in the
case of a “By connector” link if the Spec-Name is different.
Example:
The attribute “Test” is searched for via a connector on the Data tab. However,
the attribute is called “Testnew”. This script function is then entered at the
linked device, and if a query is made for “Test”, then the function inputs:
“What you had been looking for as “Test” is now called “Testnew” here”.
Effect:
The links themselves do not need to be changed. You can only ensure via the
script function that the link functions nevertheless in the case of objects that
deviate from the naming syntax.
Syntax:
Device: linked planning object
ConnectorName: connected connection
SpecName: attribute name of the link.

22.2.10 IsImplementationValid (Device)
Verifies whether a pointer is valid. Please note: Limitations on the Comos-

side are fully disabled. If you need limitations, then these must be pro-
grammed independently.
Validity range IsImplementationValid: Device system type
22.2.11 IsLocationValid (Device)
Trigger: Script
Verfies whether a pointer is valid.
Validity range: Document system type and Device system type
Please note: Limitations on the Comos-side are fully disabled. If you need
limitations, then these must be programmed independently. Example: If the
IsLocationValid script function is available, then plausibility checks for the
unit pointer are disabled.
Background: Plausibility checks are conducted when a unit or location pointer
is set in the in the Properties window of planning object. Example: When you
set the unit pointer, then it is checked whether the unit comes from the same
branch. If yes, then the unit may not be set as pointer.
22.2.12 IsLockAllowed (Lock)
Trigger: Interface
Reacts to the attempt to lock or unlock.
Input: Parameter “lock”:
If the user activates the “Block ” icon, True is passed to the script function in
the lock parameter.
If the user clicks the “Released ” icon, False is passed to the script function
in the lock parameter.
Output: String (Warning message)
Please note: Locking or unlocking is not explicitly prevented in the script.
Rather, when the script returns a string, this is interpreted as prohibition or
permission by the script.
Example:
If Lock = True Then
IsLockAllowed = “Locking not allowed”
...

Only due to the fact that a string is returned as a result of Lock = True, Comos
detects that locking is not allowed.
22.2.13 IsReleaseAllowed
Only available at the base object of working layers, see IsReleaseAllowed, S. 5-15.
22.2.14 IsUnitValid (Device)
Trigger: Script
Verifies whether a pointer is valid.
Validity range: Document system type and Device system type
Please note: Limitations on the Comos-side are fully disabled. If you need
limitations, then these must be programmed independently. Example: If the
IsUnitValid script function is available, then the plausibility checks for the
unit pointer are disabled.
Background: When the unit or location pointer is set in the properties window
of a planning object, plausibility checks are conducted. Example: When you
set a unit pointer, it is checked whether the unit comes from the same branch.
If yes, then the unit must not be set as pointer.
22.2.15 NavigatorText (Object)
Trigger: Interface
Allows you to script the text displayed in the Navigator; returns a string that
replaces the standard Navigator text. As long as not provided explicitly in
NavigatorText, all references are filtered. Example: For base object point-
ers, there double arrow >> and FullName will be filtered.
Also allows you to generate new texts for the existing entries of the | NEW
mouse menu command.
22.2.16 OnCheck(Device, Modus)
Trigger: Comos
Is called when an object is saved within Comos; e.g. when you click [OK] in
the Properties window (and the object was changed and thus needs to be
saved) or when a new object has been created by a script.

Input: Device
The script is written at the base object, but is executed for a planning object.
Device is used to determine for which planning object the script block should
take effect.
Input: Mode
The mode determines whether the object is only to be checked or whether it
should be repaired as well. 0 = check; 1 = repair.
Purpose: Checks an object when it is saved.
1. Standard checks within Comos:
1.1 Name (unique)
1.2 Label (unique)
1.3 Creation mode
2. All checks that the user has created himself or herself in the script block.
A failed check is triggered by a return message and made known:
If Parameter < Condition Then
OnCheck = “The parameter is invalid”“
If all the checks were successful, then no message is sent. In other words: if
you wish to have positive acknowledgments, you need to use the msgbox,
since each text allocation to OnCheck is interpreted as a failure by Comos. The
allocation:
...OnCheck = “Check successful“
is thus meaningless, since it will also be interpreted as an error by Comos.
Similar functions:
OnEditOK
OnEditOK is only triggered via the interface (via the [OK] button). OnCheck
is always triggered when an object is saved.
22.2.17 OnCreateReferenceDocument()
Trigger: Comos
Event is triggered on automatically referencing a document in a document
group.
For that, in the project options, the Automatic referencing option must be
enabled and a specific name syntax must be complied with.

22.2.18 OnDocObjCreate (DocObj)
Trigger: Comos
Event when setting the Reference-Pointer to DocObject. (This function is
only meaningful for base objects of “objects-managing documents”, namely,
interactive reports).
Examples:
- Is triggered when an object is placed,
- Is triggered for an import.
22.2.19 OnDocObjDelete (DocObj)
This function is triggered when the Reference-Pointer to DocObject is deleted

again.
22.2.20 OnEditOk()
Trigger: interface
Event after pressing the [OK] button of the device or document properties
screen.
Output:
Integer value = 0: no error text is output
Integer value <> 0: error text from standard table ('SCRIPT_ERRORS')
22.2.21 OnEStampCreate (ST,RevElm)

For Document class.
Trigger:
On generation a PDF revision file.
ST = ComosPdfStamper: Object with which you can fill user-defined place-
holders on the document.
RevElm = ICOmosDDevice: The respective revision element that was just cre-
ated.
Exceeding the standardized eSign settings, here you can customize if, with
regard to the signautre, other freely definable placeholders are to be displayed
in the PDF document.
Check-out a document and define the placeholder in the document by writing
it into the document at the desired position in curly brackets. Then assign a
value to the placeholder in the script, e.g. with following command:

PdfStamper.SubstituteValue “BenutzerdefinierterPlatzhalter“,
“BenutzerdefinierterWert: “ & RevisionElm.Name
When the document is converted into a PDF file, the placeholder is replaced
by the value assigned in the script. The value is then displayed in the docu-
ment.
22.2.22 OnEStampShow (PdfStamper, Revision)
For Document class.

Trigger:
When a PDF revision file is displayed.
PdfStamper = ComosPdfStamper: Object with which you can fill user-
defined placeholders on the document.
Revision = ICOmosDDevice: Revision object that refers to the relevant revi-
sion file.
Application: see OnEStampCreate.
22.2.23 OnImplementationSet (OldValue)
Trigger: After placing the pointer.

• Validity range: Device system type
Please note: When the OnImplementationSet function is used, then the
Comos-specific implementation function is disabled in the Device.dll. This
Comos-specific implementation function would, for example, run when an
implementation pointer is set at a planning object. When this is done, the
Comos-specific function carriers out a lot of work: Elements, connectors and
symbols are transferred, etc. All these automations are dropped if OnImple-
mentationSet is used.
In particular, the mechanism that automatically replaces request objects is

dropped. In that case, the “’Implement request’ replaces objects” project
option no longer takes effect.
The OldValue parameter is available. If a pointer already exists, it is saved
in this parameter. OldValue is available while the script function is running.
Afterwards, the information on the former value of the pointer is lost.

22.2.24 OnLocationSet (OldValue)
Trigger: After setting the pointer.

• Validity range: Document system type and Device system type
Afterwards, the information on the former value of the pointer is lost.
22.2.25 OnLockDone (Lock)
Called after locking/releasing.
22.2.26 OnMenuCreate(Popup, Context)
Trigger: interface
Event before creating the context-sensitive popup menu.
Input:
Popup: the popup menu object
Context: Context object from which the call is made.
Example: Context.ComosObject returns the current object.
Examples that can be used in OnMenuCreate:
PopUp.OutputDebugString
Sends the entries (IDs) from the context menu to DBMon.
Popup.Delete „PASTE“
Deletes the “PASTE” menu item.
Popup.Disable „PASTE“
Deactivates the “PASTE” menu item.
While writing the script at the base object, you can consider define whether
multiple selection will apply withing the the planning view or not:
MenuContext.ComosObjects
22.2.27 OnMenuExecute(ID, Context)
Trigger: interface
Event after selection of an entry in the context-sensitive popup menu
Input:
ID: [String] ID of the entry from the entry from the popup menu

Context: Context object from which the call is made.

When calling up the context-sensitive popup menu from an interactive report,
a context object containing the following information is transferred:
associated Comos object, pointer to the current report object and the OCX
abbreviation “Report”.
Example: Context.ComosObject supplies the current object.
22.2.28 OnNotLongerReferencedByDevice(Device)
Trigger: Comos
Event when deleting the CDevice pointer to the device.
22.2.29 OnProjectOpen(Project)
Trigger: interface
Is called when opening a project.
22.2.30 OnReferencedByDevice(Device)
Trigger: Comos
Is called on setting the CDevice pointer to the device (allocation of a base
object) and on copying the Device.
22.2.31 OnReferencedByDocument(Document)
Trigger: Comos
Is callen when setting the CObject pointer to the document (allocation of a
base object) and on copying the Document object.
22.2.32 OnRelease
Only available at the base object of working layers, see OnRelease, S. 5-15.
22.2.33 OnReleaseDone
Only available at the base object of working layers, see OnReleaseDone, S. 5-15.

22.2.34 OnRevision()
Trigger: interface
The event is fired when a new revision is created for documents. (Properties
window of a document, Revisions tab: [NEW REVISION])
There is a further option for writing a script for this event.
The script OnReferencedByDevice is used at the base object of the revision
or at the objects lying underneath the revision levels.
Reason:
An object is created internally when a new revision is created in the docu-
ment; however, this object is not visible within the Navigator. The CDevice
pointer is set to the prepared revision base objects in the case of this object.
22.2.35 OnSubMenuCreate (Popup, Context)
Trigger: Interface
Allows you to create your own entries in the submenu of the mouse context
menu. See OnMenuCreate.
22.2.36 OnUnitSet (OldValue)
Trigger: After placing the pointer.

• Validity range: Document system type and Device system type
Afterwards, information on the former value of the pointer is lost.
22.2.37 RestoreRequest (Request)
Trigger:
• On setting the implementation pointer for the first time
Nothing is passed as input parameter
• On setting the implementation pointer for the second time
The “old” implementation pointer is passed as input parameter.
• Restore request
The implementation pointer is passed as input parameter.

Script at the attribute Script Functions of Comos Objects
22.2.38 UserScript[1-9]
Trigger: Manual call

Example: There is Test within UserScript1. The call CDevice.Script-
engine.Scriptobject.Test is in a DLL.
Please note that use of the script engine is relatively time-consuming. Use the
predefined script blocks if at all possible.
Purpose:
Blank for user-specific scripts.
22.3 Script at the attribute
22.3.1 Display types and their script blocks
These script functions are used in specifications, see SECTION 16.4: SCRIPT TAB. If
you wish to modify an existing script block, you have to click on the button
on the far right with the three dots. Not all the script blocks are available, since
this depends on what Type the attribute possesses.
22.3.1.1 General script blocks

The following script blocks are always available:
• OnChange ()
This event can be used, among other things, to automatically expand pick
lists. Do this with the following command line in the script block:
Workset.Lib.AddSpecValueToStdTable thisobj
Trigger: Comos
This is called if the value (including “expansion values”) or the unit of an
attribute is changed. Special case: in the case of an attribute of type Link ,
OnChange is also fired if the link is changed.
Purpose: This script function is used to make changes at other points (other
attributes) if this attribute has changed.
Similar functions:
OnEdit
OnEdit is only called up if the change is to be made within the interface, or in
other words, via the tab. OnChange is always called up.

Script Functions of Comos Objects Script at the attribute
• IsValueValid (ValueStr)
The function IsValueValid is called up automatically after setting an
attribute value (LostFocus ). If the value that had been set is invalid, a
message is output and the old attribute value is set. The range of validity of
the attribute values can be controlled by a script.
This script block can also be used to control your own help windows, see
SECTION 16.5: HELP TAB.
Trigger: Comos
This is called up if an input is made for a change in the value of the attribute.
Please note that the input does not necessarily lead to a change, since the input
could always be rejected.
Input: Value or XValue
Output: Boolean
Purpose: The input is not accepted at once, but is checked first. The input is
only accepted into Value/XValue and the attribute changed if the check is suc-
cessful. Only then is the time stamp changed. The time stamp remains
unchanged if the input was rejected.
Please note that in the case of attributes that have multiple fields of types
Value and XValue (range attributes) that this script is executed for each of the
edit fields. It is not known from which of the edit fields the information
comes.
Similar functions:
OnChange
By contrast with OnChange, in the case of IsValueValid the input is not
accepted at once but is checked first. (The time stamp remains unchanged).
OnEdit
OnEdit is only called up if the change is made in the interface, or in other
words, via the tab. IsValueValid is always called up.
Additional general script blocks

Please note: If the Edit mode field is set to Pure user interface with script
in the General tab, then additional script blocks are available with each type
of display, see SECTION 22.3.3: SCRIPT BLOCKS FOR “GRAPHICAL USER INTERFACE WITH
SCRIPTS”.
22.3.1.2 Description
Script block OnShow SECTION 22.3.2.17: ONSHOW ()

22.3.1.3 Image selection

No script blocks of its own.
22.3.1.4 Checkbox
Script block OnClick SECTION 22.3.2.14: ONCLICK ()
Script block GetSpecification SECTION 22.3.2.7: GETLINKEDSPECIFICATION ()
Script block GetDisplayValue SECTION 22.3.2.5: GETDISPLAYVALUE ()
22.3.1.5 File selection

Script block CustomizeFileOpenDialog SECTION 22.3.2.1: CUSTOMIZEFILEOPEN-
DIALOG
22.3.1.6 Date
22.3.1.7 Edit: (Min, Max)

Script block OnChangeOther SECTION 22.3.2.13: ONCHANGEOTHER ()
Script block OnEdit SECTION 22.3.2.15: ONEDIT ()
Script block FilterRow SECTION 22.3.2.4: FILTERROW (STDTABITEM)
Script block FillComboList SECTION 22.3.2.3: FILLCOMBOLIST (COMBOBOX)
Script block GetLinkedSpecification SECTION 22.3.2.7: GETLINKEDSPECIFICA-
TION ()

Script block GetDisplayXValue SECTION 22.3.2.6: GETDISPLAYXVALUE (INDEX)
22.3.1.8 Edit: (Min, Value, Max)



TION ()

22.3.1.9 Edit field


TION ()
22.3.1.10List
22.3.1.11Memo field(ASII)
TION ()
22.3.1.12Memo field (RTF)

22.3.1.13Query
Script block OnEdit SECTION 22.2.20: ONEDITOK()
22.3.1.14Frame

22.3.1.15Repeater
22.3.1.16Button
22.3.1.17Signature
Script block IsSignatureAllowed SECTION 22.3.2.12: ISSIGNATUREALLOWED
(STRING)
22.3.1.18Link
Script block GetLinkObject SECTION 22.3.2.8: GETLINKOBJECT (TXT)
Script block GetRoot SECTION 22.3.2.9: GETROOT ()
Script block CustomizeTree SECTION 22.3.2.2: CUSTOMIZETREE (TREE)
Scriptblock IsLinkObjectValid SECTION 22.3.2.11: ISLINKOBJECTVALID (SPECIFI-
CATION)
Scriptblock OnLinkObjectSet SECTION 22.3.2.16: ONLINKOBJECTSET (SPECIFICA-

TION)
Scriptblock GetDisplayValue SECTION 22.3.2.5: GETDISPLAYVALUE ()
22.3.1.19Tip
If you wish to test the triggering of a script block, all you have to do is to write
msgbox “OK” in the script.
22.3.2 Alphabetic reference of the script blocks
22.3.2.1 CustomizeFileOpenDialog
Available for display type:
File selection SECTION 22.3.1.5: FILE SELECTION
This concerns FileOpenBox.

Trigger: interface
If the icon button to open the file dialog was pressed (MouseUp).
Input: MS object FileOpenDialog.
Purpose: Makes available the properties of MS object FileOpenDialog. See
the relevant help from Microsoft.
22.3.2.2 CustomizeTree (Tree)

Link SECTION 22.3.1.18: LINK
Trigger: interface
If the icon button to open the additional Navigator was pressed (MouseUp).
Input: Tree (Functree object)
Purpose: Makes available the properties of the Navigator (functree.ocx). See
the Comos Core Reference.
22.3.2.3 FillComboList (Combobox)

Edit field SECTION 22.3.1.9: EDIT FIELD
Edit (Min Value Max) SECTION 22.3.1.8: EDIT: (MIN, VALUE, MAX)
Edit (Min Max) SECTION 22.3.1.7: EDIT: (MIN, MAX)
Trigger: interface
This is called up if a value is written in a Combobox and this is then quit (Lost-
Focus).
Input: Combobox + vbCrlf
Purpose: User inputs can permanently be made available in this attribute: the
entry can be selected from the drop-down list for the second input. This avoids
data entry errors.
Example: Combobox.AddItem(<Text>)
22.3.2.4 FilterRow (StdTabItem)


Trigger: interface
If the attribute is displayed on the tab.
Input: StdTabItem (Entry of the pick list that was determined for this
attribute.)
Output: True -> Entry is displayed in the Combobox.
Output: False -> Entry is not displayed.
Purpose: An attribute can be specified as a Combobox in the control proper-
ties. In addition, a pick list can be created for an attribute so that the entries of
the pick list appear in the Combobox.
This script block can also additionally filter the entries of the pick list so that
only a portion is actually available within the Combobox.
22.3.2.5 GetDisplayValue ()
Checkbox SECTION 22.3.1.4: CHECKBOX
Trigger: Comos
If the attribute is displayed. (If the DisplayValue method is used.)
Output: String
Purpose: The following must be set for the Link type on the Link tab: “via
script: <GetDisplayValue>”. A value must be determined and transferred
in the script block.
22.3.2.6 GetDisplayXValue (Index)

Memo field SECTION 22.3.1.11: MEMO FIELD(ASII)
Trigger: Comos
If the attribute is displayed. (If the DisplayXValue method is used.)
Input: Index for the list (numbers the cell of the current column, whereby here
the first cell has index number 0.)
Output: String

Purpose: The controls are called up from the list and from there a switch is
made to the Specifications tab. Links can be selected for the cells via the
[LINK] button. The following must be set for the Link type: “via script:
<GetDisplayValue>”. (However, the XValue is processed internally.)
The [SCRIPT] button is on the same tab: An XValue must be determined and
transferred within script block GetDisplayXValue.
22.3.2.7 GetLinkedSpecification ()
Memo field SECTION 22.3.1.11: MEMO FIELD(ASII)
Trigger: Comos
If the attribute is displayed. (If the DisplayValue method is used.)
Output: Attribute object
Purpose: The following must be set for the Link type on the Link tab: “via
script: <GetLinkedSpecification>”. An attribute must be determined
and transferred in the script block.
22.3.2.8 GetLinkObject (txt)

Trigger: interface
If a text input was made and the field was quit (LostFocus).
Input: Text input
Output: Object
Purpose: Normally the link can only set via the Navigator (drag & drop or via
the additional Navigator that was opened by pressing the icon button). This
script accepts the text input and processes it within the script. A suitable
matching object must be found within the script and finally transferred with
Set GetLinkObject = Object.
22.3.2.9 GetRoot ()

Trigger: interface
If the icon button to open the additional Navigator was pressed (MouseUp).
Output: Object
Purpose: Sets the root object (the object that is currently marked and dis-
played) within the additional Navigator that was opened by pressing the icon
button. The root object must be transferred with Set GetRoot = Object.
Example:
Function GetRoot()
Set GetRoot =
Project.Devices.Item("<Name>")
End Function
22.3.2.10Import (SpecOwner, ExcelActiveWorkbook)

Excel interface SECTION 17.5: EXCEL INTERFACE
This method is obsolete. Please use either an action object or CDI.
Trigger: interface
Before the attribute values are imported, when the Comos Excel interface
dialog window with the query “Should values... be transferred to Comos?”
appears, this should be confirmed with [Yes] (MouseUp)).
Input: ExcelActiveWorkbook
Output: SpecOwner
Purpose: Imports attribute values from an Excel file.
22.3.2.11IsLinkobjectValid (Specification)
Available for display type: Reference
See SECTION 22.3.1.18: LINK
Allows you to determine whether a pointer is valid.
22.3.2.12IsSignatureAllowed (String)
Available for display type: Signature
See SECTION 22.3.1.17: SIGNATURE
Returns a feedback message (String as error text of the Note window) if the
user tries to sign, but a signature is not allowed.

22.3.2.13OnChangeOther ()
Trigger: interface
The script function OnChangeOther is only triggered for the tab that is cur-
rently visible.
It is triggered when working in the Properties window of the object on the
Specifications tab or if working in bulk processing with the tab and one of the
following actions has been executed:
If the value (Value) or the unit were changed for another attribute on this tab
and the field was quit (LostFocus).
Special case: If you also wish to trigger OnChangeOther for a tab that is other
than the one that is visible, this can be done by means of a script call. Within
OnChange you make the call in script Workset.lib.OnChangeOther. Syn-
tax: Sub OnChangeOther (ByVal Spec As IComosDSpecification,
ByVal NestedName As String)
First parameter: the owner of the attribute, namely, the CDevice/Device. The
simplest way is to input the key command “.me”.
Second parameter: unique name of the attribute that is being searched for.
The two attributes that interact with each other must be located on the same
object but can be on different tabs.
Purpose: All areas of application.
22.3.2.14OnClick ()
Button SECTION 22.3.1.16: BUTTON
Checkbox SECTION 22.3.1.4: CHECKBOX
Trigger: interface
This is called up when a attribute of type button is pressed (MouseUp).
Purpose: All areas of application.

22.3.2.15OnEdit ()
Trigger: interface
This is called up when a field of type Value or XValue is edited and quit again
(LostFocus). In the case of a link this is the point in time when the object was
selected and the path and name of the selected object are displayed in the
value of the link.
Purpose: The user guidance ought to be improved. For that reason the function
only takes effect when the change has been made in the interface, or in other
words, via the tab. If the attribute is changed in some other way, if it is
changed by a script, for example, then this script block is not activated.
Similar functions:
IsValueValid
IsValueValid is used to control the input while OnEdit reacts to inputs.
OnChange:
OnChange is always called up, even when the change had been made by a
script, for example.
22.3.2.16OnLinkobjectSet (Specification)
Available for display type: Reference
See SECTION 22.3.1.18: LINK
Trigger: After setting the pointer
Afterwards, information on the former value of the pointer is lost.
22.3.2.17OnShow ()
Description SECTION 22.3.1.2: DESCRIPTION
Trigger: interface
This is called up if the description (label) is displayed on the tab. In other
words: the script is not activated if, for example, the description is displayed
via the Navigator or in a report.

Output: String, displayed as a label.

Purpose: The label can be changed with OnShow = “Text”.
22.3.3 Script blocks for “Graphical user interface with scripts”
The following four script blocks can only be used in connection with edit
mode “Graphical user interface with scripts ”. The attribute must be a
form of display that has a value available.
22.3.3.1 GetScriptUnit ()
Trigger: Comos
For read access to the actual unit. (It is thus used, for example, for display or
evaluation.)
Output: Unit
Purpose: The attribute thus fetches the unit from the script.
22.3.3.2 GetScriptValue ()
Trigger: Comos
For read access to the actual value. (It is thus used, for example, for display
or evaluation.)
Output: Value
Purpose: The attribute thus fetches the value from the script.
22.3.3.3 SetScriptUnit (Unit)

Triggertrigger: Comos
For write access to the actual unit.
Input: User input unit; thus the unit is only processed in the script and is not
written to the attribute. In other words: after the processing in the script, the
attribute has the value returned from GetScriptUnit.
Purpose: The attribute thus transfers the user input to the script.
22.3.3.4 SetScriptValue (Value)

Trigger: Comos
For write access to the actual value.

Input: User input value; thus the value is only processed in the script and is
not written to the attribute. In other words: after the processing in the script,
the attribute has the value returned from GetScriptValue.
Purpose: The attribute thus transfers the user input to the script.
22.3.4 Examples
This script marks SPS addresses

Sub OnChange()
Prefix = Owner.Specifications.Item("Prefix").Value
Set Dev = Owner.Owner
Set Elms = Dev.Enobs("E")
For I = 1 to Elms.Count
Set Elm = Elms.item(I)
If Elm.InheritStatus = "E" Then
Elm.InheritCheckIn
End If
Elm.OwnLabel = Prefix + Value + "." + CStr(I - 1)

Next
End Sub
Allocate SPS addresses on the basis of a starting number.

The script that was executed belongs to an EDIT attribute. The attribute itself
belongs to base object SPS card. Once a start address has been input or mod-
ified in the attribute field, the elements - the channels of the card - are given
a new label.
OnChange
If Not IsNumeric(Value) Then Exit Sub
Set Elements = Owner.Elements
‘ STOP
For I = 1 to Elements.Count
Set Element = Elements.Item(I)
If Element.InheritStatus = "E" Then
Element.InheritCheckIn
End If
Element.Label = Value + (I-1)
Next
End Sub

Script Functions of Comos Objects Script for the project object
22.3.5 Script commands for attributes
GetControlProperty, SetControlProperty
SetControlProperty (PropertyConst, vNewValue-String)
The properties of the SUI* controls can be controlled with SetControlProp-

erty. Call in script:
• Write:
workset.lib.sui.CtrlProperty(PropertyConst, Spec) = xy
• Read:
from = workset.lib.sui.CtrlProperty(PropertyConst, Spec)
ConvertPhysUnits (unit conversion)

This script achieves the same for an object as the “Unit conversion” plugIn.
LIB.DLL:
Function ConvertPhysUnits(ByVal ComosObj As IComosBaseObject,
ByVal ToBritish As Boolean) As Boolean
The units of all attributes of ComosObj are converted (not only the OwnSpeci-
fications), for ToBritish=True from metric to British, otherwise vice-
versa.
22.4 Script for the project object

In the project Properties window, you will find the Base data field on the
Links tab.
The base object scripts are taken over from the base object of the project. That
way, base object functions can also be performed on the project (e.g.: custom-
izing the context mouse menu through OnMenuCreate).

Script for the project object Script Functions of Comos Objects

Concept behind object queries
23 Concept behind object queries

The term “query”
Any program that processes large amounts of data requires a tool to query and
display the data. If you already have some knowledge of databases, then you
will know the term query, in the form of an SQL query, for example.
In Comos the data is managed in the form of objects. The objects are the “con-
tainers” and contain the actual information. Thus, if you wish to query the
data, you have to open this container – the objects. The tool required for this
purpose is called a query in Comos.
The results of the query are passed back in the form of a virtual table:
• Each row is based on an evaluated object.
• You can evaluate text information from this incoming evaluated object or
else determine additional objects that have a relation to the evaluated object.
Example: You can determine the owner or the project from the object.
• Information is read from the evaluated object or additional objects that have
been determined and written into the “rows” of the virtual table. Each item
of information that is displayed in a row is thus ultimately based on a
queried object.
In mathematical terms this virtual table could also be called a data matrix. In
this documentation we will only refer to an “query” in future and we will
assume that you are aware that consequently we are not talking about some-
thing that is “visible” but instead mean the “invisible” results table.
Definition
A query is a tool to extract information from a number of objects and to pass
it back in the form of a data matrix.
Comos also has a number of other options available to query and manipulate
data. For example, you can use a script to access the data or else make use of
one of the open interfaces to Comos through Visual Basic.
But object queries are extremely simple and safe to use by comparison with a
self-programmed query or VB – and in principle they have the same func-
tional scope.
The most important capabilities of the query

1. User input: Formulation of the query
– The query requires a collection of objects for the calculation.
2. Calculation of the results of the query

– The results of the query are written into a virtual table, a so-called “data
matrix”.
In other words: The number of rows is the same as the number of queried
Eingangsobjekte (basic quantity). The number and type of the columns is
the same as the number and type of information items queried.
– The calculation of the table cell takes place at the earliest when the cell
is read. This reading can have the following reasons, for example:
this row appears in the Object Browser (see the following),
this row appears in an Evaluation Report,
the row is checked while the data is sorted or filtered,
etc.
In other words: If you display a query, for example, in an Object Browser,
then initially only the visible part is calculated. This speeds up display.
– The Comos query is initially “virtual”. The calculation of the query is
completely independent of the screen display and can run in the
“background”. Advantages: If required, the results of this query can be
processed further in EDP without the need to use a time-consuming
display.
– The query as such can work with any type of object and theoretically
could also work with any type of object outside of Comos.
– The rules by which the query and the calculation are carried out can be
saved and read as archives.
3. Optional: Visual display
– The form of display can whatever you wish. As a rule a query is
displayed with the Object Browser that is supplied as well.
Object Browser
The Object Browser displays the information from a query. The Object
Browser resembles an Access table in its form of display:

Normal users will as a rule only come into contact with object queries via the
Object Browser. For that reason you can easily get the impression that the
Object Browser IS the query. But this is not the case. As described above, this
involves only one of the possible forms of display of the query.
It is just as easy and safe to display object queries in the form of an Evaluation
Report as well, for example. In this case a query can no longer be recognized
as such among many others.
In principle you can also work within the Object Browser. Depend on the set-
tings in the Object Browser, you can input text and select values, etc., in the
table.
The Object Browser is used almost everywhere throughout Comos. It is the
usual way of displaying information in Comos. The fact that in reality a table
is a query and is displayed by means of the object browser can be seen from
the fact that one of the following symbols is visible at the bottom left:
Standard queries
Standard queries are used to:
• Enable the user input by which the query is formulated. The primary task
here is to determine the quantity of the objects that are evaluated by the
query.
• Execute the query, or in other words, to calculate the results.
• To display the results in the usual way within Comos.
Each standard query is specialized and offers only a portion of the full scope
of all the possibilities for a query. Each standard query has its own interface
to match the special tasks in question.
Since standard queries are restricted to Comos information, they can thus only
be used within Comos. (The query in itself can work with any type of object,
and in theory at least, be able to process information that is outside Comos.)
Standard queries have the following structure:
• A Comos object of system class CDevice/ Device is used as the basis.
• This Comos object contains the Action class and a suitable sub-class.
• The Comos object is given a “special interface”, this being its own separate
interface with its own capabilities. From now on a “normal” user only sees
this special interface and the standard query can only be recognized visually
as a CDevice/ Device.

• This special interface is in the core of an Object Browser so as to display the

information. A number of entry fields, menu bars, etc., are arranged
“around” the Object Browser.
The expanded interface for the “planning objects” standard query is given
here as an example“:
The table-like display of the Object Browser can be seen clearly in the
middle.
Bulk processing
Almost all the usual inputs can be made within the Object Browser (and thus
of course within a standard query as well). In very special cases the entry
options available within the Object Browser are not sufficient, and bulk pro-
cessing can be used in such cases.
Example: The graphic display of information. For example, that also concerns
the graphic display of attributes on the basis of tabs.
Bulk processing is used to query specific Comos information, to display it in
the usual way within Comos, and to be able to process the data easily and
safely. Each form of bulk processing is specialized.
Each form of bulk processing uses a standard query within its core. A number
of entry fields, menu bars, etc., are arranged “around” the standard query.

As an example, here is the “planning objects” bulk processing:
If you look closely at this, you can recognize the “planning objects” standard
query man in the left-hand part of the dialog window.
“Applications” of object queries

Ultimately there are also cases in which object queries are used for specific
technically- or administration-related procedures. In such cases as well a dia-
log window is built around an Object Browser to meet a very special purpose.
• An example of a specific technical application is the selection of product
data. This application is used when request objects are to be replaced by
concrete manufacturer devices in the course of the planning work.
• An example of an administration-related application is the “translation”
application. It is used to translate text in Comos.
• An important “application”“ is the user-defined query. Thus a standard
query that is as neutral as possible is created so that the user can structure it
according to his own wishes.


Object Browser Overview
24 Object Browser
24.1 Overview
The Object Browser displays the information of a query. The Object Browser
resembles an Access table in its display:
The Object Browser shown above is divided into various areas:

1. Header (also called “column title”)
If you right-click on the header of a query column, you get a series of

nested menus:
→SORT →FILTER →SORTING/FILTER

→OPTIONS →PRINT →EXPORT
→NEW (ADDITIONAL →DELETE →PROPERTIES
COLUMNS)

Displaying the list of objects Object Browser
2. Object list (also called “cells”)
Each row of the list of objects is based on an evaluated object. You can
derive text information from this evaluated object or also determine
further objects that have a relation to the evaluated object. Example: you
can determine the project from the evaluated object (first column in the
above illustration) or the location owner (second column in the above
illustration).
Information is read from the evaluated object or additional derived
objects and written into the cells. Each item of information written in a
cell is ultimately based on a queried object.
If you right-click on a cell, then you get approximately the same mouse
menu as if you had clicked on the object in the cell within the Navigator.
In particular, you get the Navigation menu and the | Properties command.
You can change the way that the list of objects is displayed, see
SECTION 24.2: DISPLAYING THE LIST OF OBJECTS.
3. Status line
24.2 Displaying the list of objects
24.2.1 Changing the order of the columns
Use drag & drop to move a column to another position. Two red paste trian-
gles appear:

Object Browser Displaying the list of objects
24.2.2 Row height
Right-click on any desired column title and select the | OPTIONS command.
You can input the row height directly at the General tab (whole numbers
only):
Alternatively, you can use the Record selectors :
As a result, gray boxes called Record selectors appear at the left in the list:
Move the mouse cursor to any desired point above the separator line of the
record selectors until the cursor changes into a double arrow:
Hold down the left mouse button and drag the mouse downwards until you
have reached the desired row height. All the other rows are automatically set
to the height that you selected.

Displaying the list of objects Object Browser
24.2.3 Column width
Slowly move the mouse cursor in the title bar above the right-hand separator
line of the column that you wish to modify. When the cursor changes into a
double arrow, press the left mouse button and drag the column to the desired
width:
Unlike the case when changing the row height, changing the column width
only affects the column that was selected.
24.2.4 Editing cells directly
In the case of queries it is possible to input a new value directly into a cell of
the list. Thus queries not only evaluate the Comos data but are also in a posi-
tion to modify Comos data in a simple and efficient way.
To do this, the checkbox Editable must be activated in the Properties window
of a column on the Value calculation tab, see SECTION 24.10.1.3: VALUE CALCU-
LATION TAB. This checkbox is only made available if the contents of the column
can also be edited.
Attributes of the List type can also be modified within the query in the way
described above.
Multiple cells can also be edited simultaneously. Select the desired cells and
then use the [F2] button or the | EDIT mouse command.
Please note: automatic conversion
Old queries are converted in such a way that this checkbox is also activated
for all columns in which the Editable checkbox is available.
If columns have been locked, then no cells can be edited in these columns, and
the locked columns are grayed out.

Object Browser Display attributes (additional columns)
24.3 Display attributes (additional columns)

Attributes can also be brought into the list area as additional columns. Use
drag & drop to bring over an attribute into the list area:
The result
You can now see a new column, but there is not an entry for each row in the
column. If the cell is blank, then either nothing had been entered in the in
attribute or else the object does not possess this attribute.
You can tell via the mouse menu which of the two cases applies. Right-click
in the blank cell:
• If the attribute exists but is blank, then you get the | NAVIGATE | ATTRIBUTE
mouse command, among others, in the context-sensitive mouse menu for
the cell.
• If the attribute does not exist for this object, you do not get this mouse
command.
Attributes with extended values

If an attribute of List type or a range attribute Edit(Min...Max) is dragged
onto the column header of the query, then as many columns as are needed to
display all the values and extended values are created automatically.
24.4 Row statistics

Column header of the table, mouse menu| NEW | ROWS...
In this mouse menu there are commands that make it easier to get an overview
of the rows, such as NUMBER or TOTAL.

Sort Object Browser
24.5 Sort
Interaction with Sort / Filter through the combined dialog window
There is a Sorting/Filter dialog window in which sorting and filtering can be
done simultaneously. This combined dialog window is the main controller for
all filtering and sorting.
The Sortelement dialog window described in this section always relates to
this main controller and offers in addition only a subset of the control options.
In other words: if a form of sorting has been set in the Sortelement dialog,
this form of sorting also appears automatically as a row in the Sorting/Filter
main controller.
You should therefore only use the Sortelement dialog if it involves a very
simple form of sorting, and otherwise you should always use the main con-
troller. See Sorting/Filter, P. 24-10.
In the Sorting/Filter main controller there is also the option to set a lock and
thus prevent changes from being made. If the lock has been set, then the | SORT
command is no longer available either.
Background: Sorting techniques

Texts can be managed in string or numeric form within queries.
A purely lexical form of sorting with a string. In the dictionary “Aa” comes
after “A”. This is primarily also the case in which there are only numbers in
the string. So in just the same way that “Ab” comes before “B”, then “12”
comes before “2” with a string sort.
With numeric sorting “12” comes after “2”.
Similar deviations can of course occur in cases where numbers and letters are
mixed together.
Operation
Right-click in the column header and select the | SORT menu.

Object Browser Sort
First of all the quick sort options | ASCENDING and | DESCENDING are offered.
This saves you from having to open the Sorting element dialog window and
making the corresponding decision there.
The Sorting element dialog window is opened with the | EDIT command and
a whole series of further options are made available in addition to “Ascend-
ing” and “Descending”:
The fields there mean:

Column
You cannot change anything in this field. The entry simply shows in which
column the | SORT command had been selected.
Ascending, descending
Self-explanatory.
Alphabetic , Numeric , Alphanumeric
Please note: The selected type of sorting much match the contents of the cells
in this column! If you select numeric , but the texts also contain alphabetic let-
ters (in which case alphabetic or alphanumeric would have been correct),
the rows are not sorted correctly.
Grouping
A grouping index can be set with the help of the small arrow buttons.
A grouping produces a compressed table. Plus and minus signs are created at
the left-hand edge of the table by which similar types of rows can be expanded
or closed up as required.
The columns that had been grouped are automatically sorted to the far left.
Effect
An active sort is displayed by the letters “AZ” and “ZA” respectively in the
column headers:

Filter Object Browser
Rows are always kept together. If a sort has been set in a column, then the
entire table is arranged correspondingly in rows.
Sorting in multiple columns has a sequential effect. If a sort is first set in col-
umn B and then in column A, then the sort is carried out first in accordance
with B and subsequently within this in accordance with A.
If sort B is deleted, then only sort A takes effect and the table is rebuilt corre-
spondingly.
Multiple sorting
It is possible to call up the | SORT command several times one after another in
different columns. The sorting then takes effect the order in which it had been
set up. Different sorting sequences thus of course produce different results.
This method of operation has the disadvantage that you cannot tell in what
order the sorting had been set up for. If you wish to set up multiple sorts, then
you should use the Sorting/Filter main controller, see Sorting/Filter, P. 24-10.
24.6 Filter
Interaction with the combined Sorting/Filter dialog window
There is a Sorting/Filter dialog window in which sorting and filtering can be
handled simultaneously. This combined dialog window is the main controller
for all types of filtering and sorting.
The Filter element dialog window described in this section always relates to
this main controller and in addition only offers a subset of the control options.
In other words: If a filter has been set in the Filter element dialog, then this
filter also appears automatically as an AND row in the Sorting/Filter main
controller.
If there is already a complex input in the Sort/Filter main controller, the
| FILTER command is in fact switched off completely.
Thus you should only use the Filter element dialog if it only involves rela-
tively simple filtering, and otherwise you should always use the main control-
ler. See Sorting/Filter, P. 24-10.
In the Sorting/Filter main controller there is also the option to set a lock and
thus prevent changes from being made. If the lock has been set, then the
| FILTER command is no longer available either.

Object Browser Filter
Operation
Right-click in the column header and select the | EDIT command from the
| FILTER mouse menu.
The Filter element dialog window opens:
The fields in the following Filter element dialog window mean:

Column
You cannot change anything in this field. The entry simply shows in which
column the | FILTER command had been selected.
Filter operator
Describes how the filter value is evaluated.
Include : All entries are displayed in which there is exactly the same character
string as was input in the filter value. Example: plan displays Terminal
plan, Planning overview, etc.
>, < etc.: All entries meeting the condition are searched for. Thus for a filter
value of “>100” then “101” would be displayed but not “66”. Alphabetical let-
ters are also compared: “F” would be displayed for a filter value of “> D” but
not “B”.
Like(VB) : This operator uses the definition of “Like” from Visual Basic.
There is a short overview in the Help [?] dialog window. Complete instruc-
tions are given on the Microsoft Webpage.
Filter value
Relates to the filter operator. When you expand the dropdown menu you are
offered all the entries of this column.
However, often you want to input your own filter values, thus for example
with the filter operator “Include ” you might want to set the filter value “t”
(without the quotation marks) to enable you to find all words in which there
is a lower-case letter “t” at any position.

Sorting/Filter Object Browser
Case sensitive
Self-explanatory.
Effect
An active filter is shown by bolding the column title in question.
Multiple filtering
It is possible to call up the | FILTER command in succession in various col-
umns.
This method of operation has the disadvantage that you cannot select all the
possible filter links: if multiple filters are set in this way, then of necessity
they can only be AND links. If you wish to set multiple filters, then you
should use the Sorting/Filter main controller, see Sorting/Filter, P. 24-10.
24.7 Sorting/Filter
This command opens a dialog window in which you can input an individual,
combined sorting and filtering process:
The upper and lower window areas are independent of each other, but none-
theless the instructions are carried out in both windows when the dialog win-
dow is confirmed by pressing [OK].

Object Browser Sorting/Filter
24.7.1 Sorting area
The buttons work in just the same way as described

above in SECTION 24.5: SORT. Any sorting that had been
input incorrectly can be deleted line by line via the context-sensitive mouse
menu.
Resorts the order of the rows. This of course changes the
results of the sorting.
Release/Lock
This toggle switch either permits changes to the settings
(green) or prohibits them (red).
If a lock is set here, then the | SORT command (SECTION 24.5: SORT) can no longer
be used.
Set sorting
The fields can be filled in by means of the drop-down menus. Mouse-click on
the field and select an entry from the list.
Once you have selected an entry in the Column field, the remaining cells in a
row can be changed by means of the buttons above.
Alternative: right-click on a row, | PROPERTIES command. The Sorting ele-
ment dialog window opens up, which works in the same way as described in
SECTION 24.5: SORT.
Set grouping
An integer grouping index can be entered in the column on the far right:
A grouping creates a list that has been set up hierarchically in which you can
expand and close up the next data level in the same way as in the Navigator.
Please note: Even though the techniques look similar to those used for opera-
tion of the Navigator, the contents are different. In the Navigator the objects
are arranged hierarchically as a rule and the next level that has been folded out
displays the hierarchical “children”. The grouping is completely free within
the query and only depends on your decision, so as a rule it only reflects the
hierarchical relationship purely by chance.

Sorting/Filter Object Browser
The front fields of the sorting must be filled in first to enable the sorting to
take effect:
The result looks approximately like the following:
24.7.2 Filter area
These commands determine how the various fil-

ters are to work together.
AND: Only results that meet all the filter criteria are displayed.
OR: Results that meet one or other of the filter criteria are displayed.
NOT: All the values in the Filter operator field can be negated (reversed)
with this operator. This thus doubles the number of possible filter operators.
The rows must produce a logically correct expression. This means that the
brackets change an expression if AND, OR and NOT are mixed together!
Thus a correct example with brackets would look like the following:
If the operators cannot be mixed, you can dispense with the brackets:
Changes the order of the rows. This of course also changes the
result of the filtering.

Object Browser Options
Any filtering that had been input incorrectly can be deleted line by line via the
context-sensitive mouse menu.
Move rows
These two buttons allow the order of individual selected rows for fil-
tering or sorting to be changed.
Release/Lock
This toggle switch either permits changes to the settings
(green) or prohibits them (red).
If a lock is set here, then the | Filter command (SECTION 24.6: FILTER) can no
longer be used.
Set filters
The front fields can be filled in by means of the drop-down menus. Mouse-
click on the field and select an entry from the list.
• Logical operator
This entry determines the interaction of the individual rows (“filter
elements”). Overall, this must produce a logical expression, as described
above.
• Column
This value determines on which column the filter is to take effect.
• Filter operator
These buttons function in the same way as described in SECTION 24.6: FILTER
above. In addition, these commands are also available from the context-
sensitive mouse menu.
• Filter value
Make an entry in the cell in the Filter value column. Editing mode for the
cell is started by pressing F2 or by double-clicking.
24.8 Options
It does not matter which column was selected with this command. This always
affects the entire Object Browser.

Options Object Browser
24.8.1 General tab
Cell style
This option turns on the usual mode of displaying object information in
Comos: inherited texts ate shown in italics, your own inputs are shown in
blue, etc.
This option requires a relatively large amount of computing time and should
only be selected for small numbers of objects or with a fast PC. Otherwise the
response time will be very slow.
If the results from the Object Browser are only to be shown in an Evaluation
Report, then this option can be deactivated, since it only lengthens the calcu-
lation times unnecessarily.
Row height
The numeric input (whole numbers only) determines the factor by which the
row is to be bigger than a default row.
Record selectors
This option brings up grey boxes at the beginning of each row that you can
use to set the row height manually with the mouse, see SECTION 24.2.2: ROW
HEIGHT.
Change monitoring
If monitoring is switched on, most of the changes automatically appear imme-
diately in the Object Browser.
If monitoring is switched off, changed information only appears when you
manually refresh the dialog window.
This option requires a relatively large amount of computing time and should
only be selected for small numbers of objects or with a fast PC. Otherwise the
response time will be very slow.
This option can be deactivated if you only require information from the query
that will not normally be changed later by other persons. An example of such
a case is provided by the object description texts in the event of translation.
24.8.2 Administration tab
Changes
If this setting has been chosen, no further changes can be made in the Object
Browser. This concerns the order of the columns, filtering and sorting, new

columns, etc.
Please note: This change protection also locks the object or the object prop-
erty respectively against changes made by a script or the like!
The only things excepted from change protection are purely visual changes
such as the row height.
Enable save
If this setting has been chosen, changes can still be made in the Object
Browser, but these changes are not saved and are discarded when the Object
Browser is closed.
Please note: This change protection also locks the object or the object prop-
erty respectively against changes made by a script or the like!
Extended administration
If the [EXTENDED] button is selected, you can control the various rights much
more precisely:
You cam also mark several rows and then lock or unlock the cells all together
by right-clicking:
ITopQuery All properties across all the dialog windows:

browser • „Search at once“ -button

ITopQuery All properties affecting the displayed collection (the

total number of objects and then the number of objects
displayed):
• folder options (without/only/all )
• additional search options
• search mechanism (recursive / not r. )
• placing / type of diagram
• dropdown menus (Class / Start object / Base
object )
• subordinated display options: If ITopQuery is
locked, this locks IQuery and thus all the rows
underneath it are automatically locked as well.
IQuery Subordinated display options: If IQuery is locked, all
the rows underneath it are automatically locked as
well.
IFilter All settings relating to filters.
ISorting All settings relating to sorting.
IColumnDefs This row concerns all actions relating to columns but
which cannot be allocated to a special column:
• The | New mouse menu is deactivated. Thus no new
columns can be created in the planning object.
• Columns can no longer be moved within the
planning object.
• All subordinated display options: If IColumnDefs is
locked, all the rows underneath it are automatically
locked as well.
IColumnDef All information relating to a specific column: caption,
sorting, filtering, etc.
(additional An IColumnDef row is offered for each column.
IColumnDef)

Extension object
You can input here a DLL of your own (and thus, for example, an interface of
your own) that is executed when the query is started. The DLL is input here
via its ProgID from the Windows Registry.
24.8.3 Column edit tab
Column edit offers a full overview of and access to the properties of all the
columns. Nonetheless, this dialog window is not sub-divided into tabs:
Instead, you switch between the various editing options by means of the tool-
bar:
Thus the individual areas correspond to the tabs in the properties of a column.
In addition, column editing offers further information that is not visible in the
properties of a column.
If you wish to simultaneously view the editing options of different
areas, you can switch off the “Only display individually ” button. If the but-
ton has been switched off, then multiple areas can be switched on simulta-
neously as well.
24.8.3.1 General
This area corresponds fully to the General tab in the properties of a column.
See SECTION 24.10.1.1: GENERAL TAB.
If you change anything here, this has exactly the same effect as if you had
made a corresponding entry in the Properties window of the column. None-
theless, at this point you have access to the properties of all the columns.
• Name
Mandatory field. A unique name that is used for internal management of the
column.

• Description
Title of the column in the display. (Optional.)
• Reference
Row object
As described above, each row of the object list is based on an evaluated
object, the “row object”.
[Name of the columns]
Each item of information displayed in a cell is ultimately based on a queried
object. This can also be an object that has a specific relationship with the
evaluated object.
If a column is selected as the reference, then precisely that object is used in
the corresponding cell as the starting point for further calculations and
which is located in the neighboring cell to this designated column.
• Display symbol
Displays the associated icon, if there is one.
• Numeric ()
Changes the way that numbers are treated during filtering / sorting: Either
as number or as character.
Examples: In the case of number 2 is less than 10 in the usual way, while
with character a comparison is made on the basis of characters and thus 10
is less than 2 (in exactly the same way that “Aa” is less than “B”).
• Filter
It is permissible to set a filter for this column.
• Sorting
Activates sorting. Sorting must be activated if Grouping is to be switched
on.
• Grouping
This field is only active if sorting had been permitted beforehand. Activates
grouping.
• Add up
Totals the entries within the column, if this is possible.
24.8.3.2 Object evaluation

This area gives an overview of the Object evaluation tab in the properties of
a column. See SECTION 24.10.1.2: OBJECT EVALUATION TAB.
If you right-click here on a row, then you can open the properties of the col-
umn by means of | PROPERTIES and change the object calculation there.

24.8.3.3 Value calculation

This area gives an overview of the Value calculation tab in the properties of
a column. See SECTION 24.10.1.3: VALUE CALCULATION TAB.
If you right-click here on a row, then you can open the properties of the col-
umn by means of | PROPERTIES and change the object calculation there.
The information of the Value calculation tab is displayed and synchronized
here as follows:
Properties, Column editing,

Value calculation tab Value calculation area
Field Calculation type : Direct selection option in the

Default property Default property column. If a
Field Display : selection is made here in the drop-
(An entry is selected) down menu, the properties in the
the entry in the Displays field are
set accordingly.
Field Calculation type : Script Column Default property is set to
***Not defined . The script is
entered in the Script function for
value column.
Field Calculation type : Column Default property is set to

Expression (CallByName) Expression (CallByName) . The
(Underneath: Expression entered.) expression is entered in the
Parameters column.
24.8.3.4 Extras
This area corresponds fully to the Extras tab in the properties of a column.
See SECTION 24.10.1.4: EXTRAS TAB.
made a corresponding entry in the Properties window of the column.
Nonetheless, at this point you have access to the properties of all the columns.
Alignment
Determines the alignment of the cell contents.
Text wrap
Permits a text break at cell boundaries.

Width
Numeric input as the factor with relation to the value of the adjacent button.
Unit for width
mm: The width is entered directly in mm. This unit is often used when a query
is to be output in a report, since you can likewise input the column widths
there in mm. The output of the report is then exactly as stipulated. Please note:
Nonetheless, the effect on the screen can vary according to the resolution set
and the hardware used, since a PC does not know the mm width of a screen
but only the available resolution points.
Twips: A Microsoft-specific width format.
Row height: The width is calculated as a multiple of the row height. This thus
ensures that the relationship of the page length to height remains constant
even when the resolution changes.
Only for columns with attribute objects

Pre-load
This option changes the method by which the information to be displayed is
collected. Normally, in queries only the information that is also currently vis-
ible in the interface of the query is taken from Comos. If you scroll within the
query, then the information must be fetched or reloaded, logically enough.
This old method requires less time initially, but on the other hand it takes more
time when the query is used.
The Pre-load method loads all the data into memory right at the beginning.
Firstly, this defers the time taken: it takes more time initially but requires no
more time during use.
Secondly, the old and the new methods also differ in their contents.
The method that defers the time required for loading requires a length of time
that is roughly proportional to the number of attributes: twice the number of
attributes requires roughly twice as long to load and display.
The Pre-load method is more or less constant: it takes more or less the same
and constant length of time, regardless of the number of attributes.
It is therefore recommended that you try out both methods under your own
conditions and then to decide which one is faster for you.
Comos unit
First of all a units group must be selected, then a unit. The unit that is input is
used to convert the display of the attribute values. The attribute data itself is
not changed.
In the case of cell objects that supply other objects (no attributes), the unit that
had been input is simply ignored.

Local ID
Each language has a unique ID within Comos so as to identify this language,
see SECTION 42.1: GENERAL. You can check which language belongs to which ID
in the project options, Languages tab.
Please note: The texts in the queries are supplied for the most part from the
database and not from the Comos interface. Hence if you change the Comos
interface you will still see the column captions, etc., in German and the ID is
still given as 1031. The query is only changed over to the new language of
your choice once you have changed the language of the database.
Charset
Almost all Western languages work with charset 0, so in most cases a zero is
shown here. For example, Cyrillic has charset 204.
24.8.3.5 Languages
This area corresponds fully to the Languages tab in the properties of a col-
umn. See SECTION 24.10.1.5: LANGUAGES TAB.
made a corresponding entry in the Properties window of the column. None-
theless, at this point you have access to the properties of all the columns.
A column appears for each language stipulated within the project. Any trans-
lations appear in the edit fields.
24.8.3.6 Extension classes

An external DLL can be input in | OPTIONS on the Administration tab, with
which sub-information from the query can be calculated.
The Extension classes area offers an overview as to whether such an exter-
nal DLL is to be used and which sub-information is to be calculated by the
DLL.
ExtendendProgID
If an external DLL is to be used, it is then listed in this column. Normally there
is the same entry in all the cells of this column, since only one DLL can be
used during access via the Object Browser.
Object by
This entry relates to the Object calculation tab (and in column editing
respectively to the area).

Export Object Browser
Value by
This entry relates to the Value calculation tab (and in column editing respec-
tively to the area).
Picture by
The Display symbol option can be activated in the Object Browser via the
General tab (and in column editing respectively to the area). The functional
scope is greater if an external DLL is used: It is not only possible to determine
that a symbol is to be visible, but also which symbol is to be visible.
Style by
The Cell style option can be activated in the Object Browser via | OPTIONS on
the General tab. The functional scope is greater if an external DLL is used:
It is not only possible to determine that a graphic style is to be used, but also
which graphic style is to be used.
24.9 Export
Important rules concerning reimporting
Comos has a number of options for exporting. However, there are a number
of specific points that must be noted if the data is to be processed externally
and then reimported into Comos:
• It is only possible to reimport with the standard tools after exporting as an
Excel file or as Access file.
• Grouped objects cannot always be reimported correctly. A correct reimport
presupposes that editable columns only occur at the last stage of each
grouping.
• The exported data may only be edited at those points that are also free for
editing within Comos as well.
In Excel that means cells with a white background. You should not remove
spreadsheet protection in Excel, since this only concerns cells that cannot be
edited anyway.
• The exported data may not be sorted or filtered.
• The first row of an exported table contains important information and may
not be edited.
• The last column of a table that is exported to Access contains important
information and may not be edited.
Making an export
Right-click on a column title, | EXPORT

Object Browser New (additional columns)
MS Excel
Output as an Excel file.
MS Access
Output as an Access file.
Text file
Output as a text file.
XML file
Output as an XML file.
24.10 New (additional columns)

Right-click on the column header and select the | NEW command:
24.10.1 | General column
You can create your own new column with the | General command.

New (additional columns) Object Browser
24.10.1.1General tab
This tab corresponds to the General area in column editing. See

SECTION 24.8.3.1: GENERAL.
24.10.1.2Object evaluation tab

The Object evaluation tab is used to calculate an object from which the
information to be displayed in the Object Browser is calculated.
We already explained earlier that each cell in the Object Browser (and conse-
quently all the information that is displayed) is ultimately based on an object.
There is an evaluated object for each row in the Object Browser. Properties
can be displayed from this object. However, it is also possible to calculate
other objects that have a relationship to the evaluated object. That is precisely
what happens here: precisely the object that was the last to be evaluated in this
column (and thus this row) is calculated on this tab.

24.10.1.2.1Navigation library short
The short navigation library offers a fixed specified selection of navigation

steps that are frequently required.
You are always offered the same list if you mouse-click on a cell in the Nav-
igation step column. This list is a part of the Comos object structure, but is not
complete. Thus you cannot set up all the possible forms of navigation with the
short navigation library.
This restriction has the advantage that the short navigation library is easy to
take in at a glance within the administration and works very quickly within
the application.
The following columns become visible when the Navigation step list is
expanded:
Navigation step
Descriptive unique text. The designation entered here only has any impor-
tance within the navigation library. There may be a similar method or property
in the Comos Reference, but there need not be.
Example 1: In the Navigation step list there is an entry CObjectByFullName.
This designation is not in the Comos Reference, instead it involves a method
that only exists within the navigation library.
Example 2: In the Navigation step list there is an entry CDocument. This des-
ignation is also in the Comos Reference. But it is not exactly the same func-
tion, but instead a function was set up within the navigation library that works
in a similar way to the CDocument command in the Comos Reference.
In the Explanation column there is always a note to explain how the naviga-
tion steps of the navigation library can be translated into the “normal” Comos
object hierarchy.
Parameter
Since the navigation library should be as easy as possible to use, then no
parameters should be entered as a rule. However, if a parameter is necessary,
an explanation is given here in plain English as to what kind of parameter is

required.
Depending on the type of parameter to be input, you will be helped by a user
prompt.
Returns object
The object calculation of necessity always returns an object. Here it states
what system type the object possesses.
Explanation
In the Explanation column there is always a note to explain how the naviga-
tion steps of the navigation library can be translated into the “normal” Comos
object hierarchy.
Step
The navigation steps are not stored as text in the program but instead are man-
aged as unique numeric codes. There are two reasons for this: firstly, it saves
memory and disk space, and secondly, the Microsoft programming environ-
ment that is required only offers support for codes but not for text constants.
Nav. constant
This designation is the alias name for the internal code of the navigation step.
Support for input

All the steps that does not produce a meaningful solution in connection with
the above are shown in grey:
The steps are examined as follows: The system type of the last step is exam-
ined with respect to the system types of the navigation steps. if a hierarchical
combination of system types has already been forbidden by Comos, then the
entry is shown in grey. Example: No documents are permitted underneath
connectors.
In addition, no plausibility checks are made between the steps.

24.10.1.2.2Navigation library extended
The extended navigation library examines a given stock of data and derives a
navigation rule from it.
In other words: The desired navigation must already have existed as an exam-
ple and can then be completed here. If subsequent planning data deviates even
only minimally from the example structures, the navigation that had been gen-
erated here will no longer function.
This tab has three areas:
• the quick planner, consisting of the Start object and Target object fields,
• the actual Current path definition area, and
• the Go to support area.
Quick planner
Start object
Using drag & drop, a start object can be set here that must match the system
type for the object and which is determined in the Relation field on the Gene-
ral tab.
Target object
Using drag & drop, a target object can be set here that must have one of the
following hierarchical relationships to the start object:
• The target object is within the direct owner structure of the start object.
• The start object and the target object possess a common owner (apart from
the project object).

If all the prerequisites have been met, the route from the start to the target
object is determined automatically and entered in the lower area in the Cur-
rent path .
Use of the quick planner presupposes a good knowledge of the object model
and the database.
Please note: The end effect is that only the Current path definition area is
evaluated. If the inputs of the quick planner are not transferred there into the
definition area, you have to describe a path manually in the definition area.
Current path
The input that is to be evaluated later is made in this area. The evaluation of
these entries generates the path template that are utilized to determine the col-
umn data. Based on the relevant reference object, these pathing instructions
are execured for each cell and the results are likewise in the new column on a
cell by cell basis if they can be displayed.
Step
The individual steps from the start object to the target object. In the following
step only those objects are offered that actually existed beforehand for the
object. The list of commands is sorted alphabetically.
If an object of system class device exists as the current step and if this device
possesses no connectors, then no connectors are offered either in the follow-
ing navigation step.
In addition, no plausibility checks are made between the steps.
Parameters
If this involves objects that actually exist, then they are offered here as well.
Example: if ConnectorByName is selected as a navigation step, then a check
was made beforehand by the navigation help to determine whether any con-
nectors exist at all. These connectors are offered in the Parameters field.
Nonetheless, it is not absolutely necessary to make a selection from the
parameter list offered and you can also make an input of your own. In this case
no plausibility checks are made.
Object
Here the object that has been reached by the current navigation step is dis-
played. Exactly which objects are displayed later in the planning data depends
on the relevant start object.

Go to
If you mouse-click on a row in the left-hand window area, you get a small
selection of possible subsequent steps in the right-hand window area. The
subsequent steps that are offered are selected such that there is a high proba-
bility that a functioning step sequence will follow. To this end the actual data
is examined again and all the objects that are found are offered.
In other words: The owner, all the connectors, all the elements, etc., that actu-
ally exist for the object that had been clicked on are offered under Go to .
Relation
Here it displays which navigation step was suggested.
Object
Supplies on the left-hand-side the result in the event that this subsequent step
would be selected for the example object from the Object field.
You can transfer a navigation step from the right-hand Go to window area to
the left-hand one by double-clicking on it.
24.10.1.2.3Script type
The options available within a script are significantly more comprehensive
than those provided by the navigation library. The evaluation of a script takes
longer than that for a query via the navigation library. However, there is
always no alternative to using a script if the navigation requires decisions or
iterations (loops).
See SECTION 12.8.2: THE SCRIPT EDITOR regarding the script editor.
Help
This button starts the program help. You can also find a short example.
Explanations regarding the script:
Set ColumnObject = Nothing
The variable is typed.
if Not RefColObject is Nothing Then
A check is made to determine whether the query received any valid data at all.
Set ColumnObject = RefColObject.GUnit
The unit underneath which the object is located is determined regarding the
reference (the object that is being evaluated). This unit is stored in the vari-
ables. This also fulfills the condition that an object must always be passed
back as the result of the script.

24.10.1.3Value calculation tab
This tab corresponds to the Value calculation area in column editing. See
SECTION 24.10.1.3: VALUE CALCULATION TAB.
Value calculation uses the object of the Object calculation for subsequent
information processing. This means that the value calculation cannot supply
a result if there is no correct definition on the Object calculation tab.
Calculation mode
You can select from three different types of text calculation: Standard prop-
erty, script and expression.
1. Standard property
Display
When using the Standard property type of calculation, a selection field
with a list of frequently used functions and properties appears. You can
find details on the functions and properties in the Comos Kernel
Reference.
Editable
Activated: You can make an entry directly in the cell with the Object
Browser. This checkbox is only available if the contents of the column
can also be edited.
2. Script
This option opens a script editor, see SECTION 12.8.2: THE SCRIPT EDITOR. the
[SCRIPT TEST] button to check your script, and the result is displayed in a
popup window. You can get a small programming example by clicking in
the Example tab on the button.
Queries possess an interface with which you can create your own
columns: Function ColumnValue. The ColumnValue function can
return texts and numbers (String, Long, Double).
3. Expression
Expression (CallByName) creates an edit field in which a display
instruction can be made with the usual Comos point notation that covers
exactly one row.

You can now enter the usual Comos short notation in this row so as to
calculate the desired text, such as GUnit.Project.Name, for example.
You cannot use the Expression type if you require loops or more than
one row for any reason. In that case you should then use the Script type.
24.10.1.4Extras tab
This tab corresponds to the Extras area in column editing. See SECTION 24.8.3.4:
EXTRAS.
24.10.1.5Languages tab
This tab corresponds to the Languages area in column editing. See

SECTION 24.8.3.5: LANGUAGES.
24.10.2 Default columns (project, timestamp, etc.)
Mouse menu | NEW ...

Other mouse commands Object Browser
There is a series of predefined columns underneath the first entry. Simply

click on one of the entries to create the corresponding column.
The scope of the default columns offered depends on the initial column that
had been selected. This is due to the fact that a default column that has just
been created always relates to the column in which the | NEW mouse menu was
called up.
The Status line shows to which “old” column a new column relates:
24.10.3 New | Row statistics
Self-explanatory.
24.11 Other mouse commands
24.11.1 Print
This menu item makes available the same functions as those found under the
PRINT button in the toolbar.
24.11.2 Delete
Selected columns can be deleted with this command. Deleting one or more
columns does not change any objects or their properties, but only affects the
display. A safety prompt appears to prevent you from deleting anything acci-
dentally.
24.11.3 Properties
This menu item makes it possible to edit and check the column properties. The
forms of display and controls correspond in appearance and function to the
tabs described under SECTION 24.10: NEW (ADDITIONAL COLUMNS).

Object Browser Status line
24.12 Status line

There is a diskette symbol in the fourth field on the status line of a query. This
symbol is activated if anything was changed in the interface of the query and
it has not been saved yet.

Status line Object Browser

Standard queries Creating and opening standard queries
25 Standard queries
Standard queries are premade tools in which specific data is searched for and
edited by Comos by means of an object browser. There are differences
between the interfaces of the various standard queries. In general, a standard
query looks like the following:
25.1 Creating and opening standard queries

Standard queries are special action objects
The basis of standard queries is always a CDevice or a device of class Action .
However, action objects behave differently from other Comos objects:
• The familiar Properties window is replaced by an extended interface. See
below for more details.
• In addition, in the case of action objects inheritance functions differently
from the usual way.
• The distinction between base objects and planning objects is largely done
away with: action objects behave in the same way in the base data and the
planning data. However, action objects are first created in the Navigator on
the Base data tab: the corresponding mouse menu is only offered there.

Creating and opening standard queries Standard queries
• Action objects should only be created by means of the mouse menu, see the
following below.
Action objects are divided into the following main groups: decision tables,
imports, queries, scripts. This chapter only covers queries.
There are six sub-classes for queries. Five of them involve a concrete standard
query and in addition there is a general sub-class called Other . This division
is made for historical reasons and should be ignored for the following reasons:
• Queries cannot be completely created by means of the | NEW BASE OBJECT
function. Only “older” standard queries are available as a sub-class. “New”
standard queries always possess the sub-class Other and are then specified
further by Comos. It is therefore not possible to create “newer” standard
queries by creating and suitably configuring a base object.
• Queries should always be created by means of the mouse menu:
No matter which of the base objects on the Base objects tab you select, the
mouse menu will offer, among others, the | NEW QUERY | STANDARD
command:
→SECTION 25.4: STAN- →SECTION 25.7: STAN- →SECTION 25.3: STAN-

DARD QUERY BASE DARD QUERY CONNECTORS DARD QUERY PLANNING
OBJECTS OBJECTS
→SECTION 25.5: STAN- →SECTION 25.6: STAN-

DARD QUERY DOCUMENTS DARD QUERY ATTRIBUTES
/ PRINTING
The extended interface for standard queries

When you double-click on a query, its special interface is opened and not its
Properties window.
How to open the Properties window:
• In the case of a base object: You must right-click on the object in the
Navigator and use the | PROPERTIES context-sensitive command.
• In the case of a planning object: You must first open the special interface
and then click on the Properties button.
Double-clicking or using the | OPEN mouse menu command always opens the
special query interface and not the Properties window.
Queries in Comos tools

The queries function is used in many tools within Comos:

Standard queries Operation: Standard controller
• PrintManager
• Translation
• Script conversion
• Navigator views
• etc.
In the form normally supplied as standard, the Comos standard tools with que-
ries are stored in the base data under node @System |.. : .
Inheritance in the case of action objects

Inheritance works in the same way with action objects as it does with base
objects. Thus if a new base object is created under an action object, this base
object initially inherits all the information of the “parent object”.
Thus all the information is inherited as a block, since with action objects all
the information is stored together in an “XObj”, an extension object. But if
only one property is changed, then the entire “XObj” is checked in and the
inheritance is broken off.
25.2 Operation: Standard controller

All queries possess a common set of buttons. In addition to these standard but-
tons queries also possess a number of additional special buttons with their
own functionalities, which are explained in more detail in the sections about
the individual queries.
The buttons that are in common are:
Navigation
Opens the Navigation menu. The effect is exactly the same as with the
corresponding commands of the Navigation menu in the Navigator.
See SECTION 10.1.4: MOUSE OPERATION WITHIN THE NAVIGATOR.

Operation: Standard controller Standard queries
Update
This button updates the dialog window and starts a complete recalcula-
tion of the query.
Save / Load
The arrow button opens a selection menu for the extended storage or
loading of settings.
Please note: when you save a standard query, you are not in fact saving data
but only the rules as to how the data is to be searched for. Thus a saved stan-
dard query will return different results if the stock of data has changed in the
meantime. This means that you do not actually “save” a results list when you
press the Save button.
| SAVE | SAVE
The default form of saving data.
| SAVE | SAVE AS ...
Saves a copy of the object. An owner must be set in the Save as field.
Comos automatically creates a name if no name is input. A default
description that can be changed is suggested in the Description field:
| SAVE | SAVE IN FILE ...

This saves the settings in XML format under a special name and/or in a path
outside Comos as well. The settings file can later be opened again via the
LOAD FROM FILE option.

Standard queries Operation: Standard controller
| SAVE | LOAD FROM FILE ...

Loads the settings of another query. A safety prompt appears because the
settings that are currently in use are overwritten when other settings are
loaded:
If you press [NO], the process is cancelled and you return to the dialog
window of the query. If you press [YES], a dialog window opens in which
you can select the path and file.
Please note: for technical reasons the settings of the various “types” of
standard queries cannot be swapped between one other. It is thus not
possible to set columns, filters, etc., as desired within a standard query for
planning objects and then to subsequently load these settings for a standard
query for base objects.
| SAVE | LOADING OF INHERITANCE SOURCE
This menu item loads the archives of the associated base object, depending
on the inheritance route (CDevice pointer). The menu entry Load from base
object appears in the planning object side and has the same effect.
Print
Clicking on the Printer symbol starts standard printing. The list in the
object browser is printed. Clicking on the arrow to the right opens up
a small menu:
| PRINT | PRINT
Default printing.
| PRINT | PAGE SETUP
Self-explanatory.

Operation: Standard controller Standard queries
| PRINT | PREVIEW
Opens a preview of the table to be printed:
Export
This toggle button makes it possible to export the query list that has
been created.
The effect is exactly the same as with the corresponding commands in the
object browser. See SECTION 24.9: EXPORT.
Script
This button brings up the Script window with the Sub Action in the
lower part of the query display:
User-specific scripts can be input and run in the Script window.

Notes on scripts in queries
The “Container” property can be used in the script. Using script, one can
thus determine which object the query itself belongs to (Device or CDevice).
The Object calculation and Text calculation tabs in the properties window
of a column have the paramters BaseRowIndex and BaseColumnIndex. They
are used to determine the index position of a cell.

Standard queries Standard query Planning objects
The ability to gain access to a cell via two different indices (such as i, j) means
that there is a risk that the information will not be received or will be wrong
as a result of layout changes, since the row and column indices change as the
result of a move. At this point it is better to use strings (such as column.name)
for the parameterization, since they do not change if the layout is changed.
The keywords Workset and Project can also be used.
Search
SEARCH AT ONCE: The results are recalculated after each change.
SEARCH: The results are only recalculated when the button is
pressed.
Start object
All standard queries have a Start object field:.
This involves a mandatory field.

A start quantity can be set in the Start object field. Do this by selecting the
desired start quantity, then copy this object quantity to the clipboard and select
the Clipboard entry in the field.
Effect: Searches for all objects that possess one of the start objects or a start
object that is located underneath hierarchically (logical Or combination).
Alternatively, the desired start quantity is selected and dragged all together
into the field by means of drag & drop.
25.3 Standard query Planning objects

Standard query Planning objects Standard queries
Default
Field Class: D Device
Field Start object : If the standard query was initially created on the Base
data tab of the Navigator, then “***Not set” is shown here. When the stan-
dard query is created on one of the other tabs for the first time, the owner is
automatically set as the start object. This is also true if the standard query is
subsequently moved on the planning side. The start object is only fixed once
the settings of the standard query are saved.
Columns: Label , Description
Search procedure : Not recursive; Start object : Include start object; Fol-
der : Without folders; Placing : All.
Controls and switches

The controls that all queries have in common have already been explained in
OPERATION: STANDARD CONTROLLER, so only special points are being dealt with
here.
Search procedure
Not recursive
In many standard queries there is the option to set the search proce-
dure. Generally the first option is “Only first level ”. Only in “standard query
planning objects” it is “Not recursive ”.
This difference in name is due to the fact that the options do the same thing
but function differently in technical terms.
The option “Only first level ” stops the search after the first hierarchical level.
The option „Not recursive“ does not inevitably stop after the first hierarchical
level: Comos searches an object of the first level and all objects beneath it,
until one object of the desired class is found. This object can be on the first
level, but also on the third or fourth one. The object is added to the results list
and Comos continues its search at the next object from the first hierarchical
level. If an object from a higher level is of that you are searching for, than
none of the objects from lower levels that also match this class are not
included into the list.
Recursive
Objects from all the subordinated hierarchy levels are displayed.
Back-pointers procedure
This procedure is used to ensure that CDevice and Device are uniquely
and clearly linked in Comos and not only in relative terms. In other
words: Each device is based on a very specific CDevice and each CDevice

knows the devices that have been derived from it. The “BackPointers proce-
dure” does not investigate the planning objects, but their base objects - in
order to determine which planning objects have been derived from the same
base objects as they do.
This option therefore only becomes available once an entry has been made in
the Base object field.
Comparison of Recursive and Back-Pointers : the structure of the data and
the start object determines which of the two options will be faster. Generally
speaking, it takes longer to compute the results if there are more hierarchical
levels to be evaluated.
Thus if it is necessary to search through four or five levels of the tree on the
planning side until the relevant data is found but there is a clear allocation of
the base data (going directly to the branch of the base data pointer), then it is
faster to start from the base data.
Usages
This option is only available if there is an object in the Start object
field that possesses usages. “Usages” are objects that were derived
from a template.
Used twins
This option is only available if there is an object in the Start object
field that is a usage, meaning that it is derived from a template (see
SECTION 49.5: TEMPLATES. All objects of the current project that were derived
from the same template can be found with the aid of this option.
Note on templates
Please note: You must drag the template itself into the start object field. It is
not sufficient to set a branch underneath which there are templates as the start
object.
Special point: If you use a template as the Start object that has been created
in the base project, then all the projects are searched for usages of this tem-
plate. If you use a template that has been created in the planning project, then
only this planning project is searched for.
Start object
Include start object(s) ...

All objects that have been set in the Start object(s) field can appear them-
selves in the results list.
Exclude start object(s) ...
All objects that have been set in the Start object(s) field will not appear in
the results list.

Standard query Planning objects Standard queries
Folders
Without folders
Objects with the Folders option are not taken into consideration.
Only folders
Only objects with the Folders option are taken into consideration.
All
All objects are taken into consideration.
Placing
This menu has two levels.

The upper part of the selection menu determines whether all objects, only
those that were placed or only those that were not placed are to be shown.
In the lower part you decide for what type of diagram the above decision is to
apply.
You thus have to click twice in the menu to be able to make a full decision.
All
All objects are taken into consideration.
Placed (diagram type)
Only objects that have been placed on a report are taken into consider-
ation.
Not placed (diagram type)
Only objects that have not been placed on a report are taken into con-
sideration.
Select diagram type:
All: The diagram type is ignored and the above decision applies to all diagram
types.
Diagram type selected: A single diagram type is selected, multiple selection
is not possible.
Options
This button opens the dialog to set the search options:

Select the desired classes (a multiple selection is permissible) and mark or

unmark these by right-clicking. Individual classes can be marked or
unmarked by double-clicking.
The calculation of the results can be speeded up greatly if specific branches
of the tree do not need to be investigated because a stop condition applies.
The options mean as follows:
Consider all placed objects (...)
When objects are placed on a report, a reference to the placed object is created
underneath the document object of the report.
If the option is activated, these references are also taken into consideration.
Thus, objects can be displayed in the results list whose original planning
object has been created at a different part of the tree, i.e. in a branch that is not
underneath the start node. In other words, the amount of the results will be
larger if this option has been activated. However, objects cannot appear twice
in the results list: In the case that an object is found twice - once the original
and once a placing reference - one of the entries will be deleted automatically
from the list.
Dereference base objects (...)
This button is only of meaning for the Base object field.
A base object can have a reference to another base object. Such a reference is
set in the Reference field on the Data tab of the properties window. When
this button is pressed, the following happens: The base object is dereferenced,
that is the reference is released and then the object that the reference points to
is used (instead of the object that holds the reference). So it is not the object
that was originally dragged into the Base object field that is used for the
search, but the base object that was set as reference in Data tab. This derefer-
encing is carriet out recursevily - the chain of references is broken until no fur-
ther “reference” has been entered for any base object.
In other words, if a base object was found during the dereferencing and if this

Standard query Base objects Standard queries
base object has in turn a base object entered for it in the Reference field, then
a jump is made to this base object and so forth until no further references can
be found. The base object found at the end is used.
25.4 Standard query Base objects
Default
Field Class: D Device
Field Start object : ***Not set .
Columns Relative name , Description and SystemFullName
Search procedure : Only first level; Start object : Include start object; Inhe-
ritance : All; Hierarchy : All.

here.
Search procedure
Only first level

Only objects of the first subordinated hierarchy level are displayed.
Recursive
Objects of all the subordinated hierarchy levels are displayed.
Start object

All objects that have been set in the Start object(s) field can also appear in
the results list.

Standard queries Standard query Documents / printing

the results list.
Inheritance
All
Display all base data.
Own (checked in)
Only the object’s own (checked in) base data is displayed.
Inherited (not checked in)
Only inherited (not checked in) base data is displayed.
Hierarchy
CDevices
Display CDevices.
Elements
Only display elements. This does not refer to the Class “Element”
but to objects of the Collection “Elements”. These are objects that are
located on the Elements tab.
Show all.
25.5 Standard query Documents / printing
25.5.1 General
Default
Columns Document , Description and Type

Standard query Documents / printing Standard queries
Start object : include start object; options : 1,3,4 activated; Extended

functions: deactivated.

here.
Start object

All objects that have been set in the Start object(s) field can appear them-
selves in the results list.
the results list.
Options
Search documents below documents

Activated: Documents that are located under other documents are also shown
in the dialog window.
Deactivated: The search stops in a branch when a document is found.
Search documents below revisions (TIFF documents)

Activated: The TIFF documents of the revisions are found and can thus be
printed out as well.

Autom. links to“Documents ... with pointer”

Documents can have a pointer to a unit and / or a location. Hence this also cre-
ates a back-pointer, since a link is created under the unit / location. This link
signals: “There is a pointer to this unit from the following document”.
Overall, the mechanism is comparable to the way in which a link is created to
a document or a print on the PV within the Explorer: you can open the docu-
ment or start the program through the link; but the link is not the document.
The back-pointers are evaluated if this option has been activated. In other
words, linked documents, meaning documents that are located as the original
at another position, also appear in the results list.
Please note that documents can appear twice in the results list if this option
has been activated.
Automatic linking to “Documents ... with pointer”

Planning objects can have a pointer to a unit and/or a location. Hence this also
creates a back-pointer, since a link is created under the unit / location. This
link shows that “this unit exists as a pointer for the following planning
object”.
The back-pointers are evaluated if this option has been activated. The links to
planning objects are followed and a further search for documents is made
there, any documents being found there also appearing in the results list.
Please note that documents can appear twice in the results list if this option
has been activated.
Activate extended functions

This option inserts additional buttons into the interface:
Stop
Stops the use of extended functions. In this way you can stop a printing or an
export operation or the printing of a revision file, etc.
Print
Prints out the selected documents with the default printer.

Please note that the order of the documents in the query changes according to
the settings, sorting, filtering, etc.
On the other hand, the data has a fixed position in the Navigator and thus the
documents are also in a fixed order. If you begin with the default setting of the
Navigator, then the documents always appear in the same position in the tree,
in the same document group and in the same order.
If the documents are printed out via the “default query documents”, the order
can differ from that which you are “used” to from the Navigator. For that rea-
son the “default query documents” offer the option to change the order of the
printing during printout so that it matches the order in the Navigator. This
avoids the need to sort the documents by hand after they have been printed
out.
Extended functions
See SECTION 41: REVISIONS.
Evaluate documents
Carrying out revisions
This option brings up a small dialog window:
You can select a revision step here. If a step that is “further down” in the list
is selected, the steps before it are executed automatically as well.
The window is enlarged with the double arrow and descriptive texts can be
input as well.
Please note: the selected revision steps are only executed for the documents if
this is meaningful. You can better assess the effect of your choice if you first
bring up the | NEW | REVISION column. The current revision step of a document
is input in this column. If the current step does not suit your choice, your
choice will have no effect.

Save as DWG/DXF
Opens a small dialog window:
The dialog saves the marked documents as DWG or DXF.

Save without sub-directories : The file name of the saved files is composed of
the name of the Comos object plus the project name.
Save with sub-directories : Sub-directories are created underneath the target
directory; the file names of the marked documents conisist only of the name
of the Comos objects and are then sorted into the sub-directories.
Select... : The target directory, underneath which the documents are saved.
Default setting is C:\Temp\.. .
Extension : The documents can be saved in dxf or dwg format as required.
Copy Tiff / PDF file of the released revision
Operation is the same as the one already explained for “Save as DWG/DXF”.
Report to Word
The selected report is exported to Microsoft Word and its contents are shown
in Word.
Report to Excel
The selected report is exported to Microsoft Excel and its contents are shown
in Excel.
Print current revision file
A TIFF or a PDF file is created when a revision has been concluded. This
option prints out the last available revision file.

Checking of Interactive Reports
Several things happen in Comos when an object is placed on a report:

ReportObject: An object that contains the graphic characteristics of the
Comos object (and some administration information) is created on the report .
DocObj: An object is created below the Comos object that administers the
information regarding which document the Comos object has been placed on.
Under certain circumstances it can happen that DocObj stays put when objects
are copied or moved. If you right-click in an Interactive Report on the white
area, then you get among other things the | Test DOCUMENT command. This
command starts a comparison of report objects and document objects and thus
immediately finds these superfluous references (DocObj).
Display documents with inconsistent DocObj in the error list
The marked documents are checked. The effect is the same as if the docu-
ments had been opened one after another and the | TEST DOCUMENT command
had been used. The results of the check appear in the object test, although it
does not open automatically. The Test note appears at the bottom right in the
Comos status bar if required. You get the | OBJECT TEST command if you click
on this message.
Should the inconsistent references be deleted?
The superfluous DocObj are deleted. This option cannot cause any loss of
data, since it does not affect either the Comos objects or the report objects.
25.5.2 Further information regarding printing
It often happens that a larger number of documents is selected through the

PrintManager, and for that reason Comos attempts to combine print jobs as
far as possible. This speeds up the print jobs, reduces the amount of resources
needed, and simplifies the administration. However, the prerequisite for this
is that the print options (document type, height, width, orientation, etc.) within
the jobs do not change.
The subsequent output format can be specified in the defaults for reports. This
can be done by entering the instruction PaperSize = “Parameter“ in the option
part (script) of the Master Report (permissible parameters: A0 - A4).
Reports with this default setting are automatically reduced or enlarged to the
output size. If the selected output size is not supported by the printer, the cur-
rent printer setting is used.

Standard queries Standard query Attributes
The PrintManager can handle reports with different formats (such as A4, A3,
landscape, portrait, etc.) within a print job.
Non-Comos documents (such as Excel, Word, text files, etc.) are likewise
handled in a separate print job.
Print jobs have a name:
• If a single Comos document is to be printed, the print job is given the
FullLabel of the selected document.
• If several documents are to be printed, the job is given the name “Comos
prn_ ” + a sequential number. (Please note: multiple reports coming one
after another are combined into one print job.)
• If a non-Comos document is to be printed (such as a Word document that
has been dragged into the Navigator by drag & drop), the job is given the
name that the relevant application gave it. For example, in the case of Word
and Excel this is the file name of the relevant document.
25.6 Standard query Attributes
Default
Columns Name , Description
Search procedure : Only first level; Inheritance : All; Hierarchy : All.

here.
The following toggle buttons with their settings have an additive filtering
effect on the display.

Standard query Attributes Standard queries
Search procedure
Only first level

Recursive
Objects of all subordinated hierarchy levels are displayed.
Inheritance
All
Display (checked in)
Only the object’s own (checked in) attributes are displayed.
Only inherited (not checked in) attributes are displayed.
Hierarchy
CDevices
Investigate CDevices to see whether any relevant attributes exist.
Elements
Only investigate elements. This does not refer to the Class Element
but instead to objects of the Collection element. These are objects that are
located on the Elements tab.
Investigate all.
Attributes
Specifications
Only “real” attributes are taken into consideration.
Tabs
Specification tabs are very similar to attributes from a technical point
of view and hence are also covered by the “standard query attributes”.
Specification columns
Lists are set up in two levels in Comos, whereby the first attribute
serves as a container for the entire list. Under it there is a further attribute for
each column that has been created.
All
All of the above options.

Standard queries Standard query Connectors
25.7 Standard query Connectors
Default
Columns Owner , Name and Label
Search procedure : Only first level; Inheritance : All; Hierarchy : Ele-
ments; Connectors All; From connected... : Off.

here.
Search procedure
Only first level

Recursive
Inheritance
All
Display all connectors.
Own (checked in)
Only display the object’s own (checked in) connectors.
Only display inherited (not checked in) connectors.

Other queries Standard queries
Hierarchy
CDevices
Investigate CDevices.
Elements
Only investigate elements. This does not refer to the Class Element
but instead to objects of the Collection element. These are objects that are
located on the Elements tab
Investigate all.
Hierarchy
All
Used
Free
From connected objects only the first connector.

Among other things, the linked connectors can also be shown in the
query in an additional column. This can then have the result that the same con-
nector appears twice in the list: as the “main connector” and as a “linked con-
nector”.
Effect: If the option is activated, then the list (which may already have been
filtered and sorted) is investigated once again and the duplicated entries are
removed.
Subsequent filtering and sorting of the list is blocked if this filter has been
activated. If the filter has been deactivated, all the other filter and sorting
options are released again for use. The option described here is intended to
create connecting lists.
25.8 Other queries

The standard queries in this section can only be created through the mouse
menu and not in the Properties window of base objects.

Standard queries Other queries
25.8.1 Standard tables for picklists
Please note: This standard query only makes the properties of the list itself
available (Name, Description, Input value). The actual list values are edited
with the following standard query.
Default
Field Start object : Project .
Columns Name, Description and Input value
Search procedure : Only first level; Inheritance : All.
Also, only certain branches of the standard tables can be selected in the Start
object field:

here.
The settings of the following toggle buttons have an additive filtering effect
on the display.

Other queries Standard queries
Search procedure
Only first level

Recursive
Inheritance
All
A different collection of standard tables is displayed, depending on
which type of project the query was executed in:
System project: system project standard tables
Base project: system project and base project standard tables
Planning project: system project, base project and planning project standard
tables
Own (checked in)
Only standard tables that have been created in the current project are
displayed.
25.8.2 Values of standard tables
This standard query is the counterpart of the „Standard table“ query.
Default
Field Start object : Project . object
Columns Name, Description and Value
Search procedure : Only first level; Inheritance : All.

Standard queries Other queries
Also, only certain branches of the standard tables can be selected in the Start
object field:

here.
The settings of the following toggle buttons have an additive filtering effect
on the display.
Search procedure
Only first level

Recursive
Inheritance
All
If one value of a standard table is checked in, then the entire standard
table is checked in as well, and hence all values of the standard table.
If this option has been activated, the following standard tables are taken into
consideration in the standard query:
In the system project: only standard tables of the system project
In the base project: standard tables of the base project and the system project
In a planning project: the standard tables of the planning project, the base
project and the system project.
Own (checked in)
Only those values of standard tables are shown that are in the current
project (in other words, either they hav been created here or have been
checked in here).

Special applications Standard queries
25.9 Special applications
→SECTION 25.9.1: TRANSLATION →SECTION 34: QUERY REIMPORT

→SECTION 25.9.3: DEVICE SELECTION →USER-DEFINED
(PRODUCT DATA)
25.9.1 Translation
See SECTION 42.4.3: TRANSLATION OF MULTIPLE OBJECTS.
25.9.2 Reimport
See SECTION 34: QUERY REIMPORT.
25.9.3 Device selection (product data)
See SECTION 61.6: SELECTING A MANUFACTURER DEVICE.
25.9.4 User-defined
This query shows the most general form of all queries. It is completely freely
configurable.
New columns can be created by clicking on the white area and selecting
| NEW.
The icon bar can be extended with the aid of the DLL extension.
Queries possess interfaces with which you can develop your own queries.
This applies in particular to IExtended.
Example: IExtended: CellValue (Variant)
The variant is managed in the cells, limited to string / numeric.

Standard queries Query as list
25.10 Query as list

Queries are used as lists in various dialog windows:
project selection (ProMgr), user list (UsrList), user groups (UsrGrpList), user
rights (RightsList), material flows (PEMStrList), material flow components
(PEMStrComp), autoroute manager (ARManager), project directory match-
ing (DocFileEqualizer), project revisions (ObjRevisions).
The queries list (“mini-query”) can easily be recognized: there is another icon
(a Q in a list) instead of the normal “WQ” in the Status bar at the far left.
The mini-query has a greatly restricted mouse menu in comparison with a
query: only those commands that are useful in connection with a simple list
are made available. Typically these are the following commands: Edit, Navi-
gate, New, Copy, Paste, Delete, Properties cell object. Some special com-
mands appear in addition, depending on the list. If values are to be taken from
a set list, this is done through a Combobox.
The usual commands are available in the column headers (sort, filter, etc.).
25.11 Outputting standard queries in reports

See SECTION 46.3.6.2.2: ROWS TAB.

Outputting standard queries in reports Standard queries

Bulk processing Preliminary comments
26 Bulk processing
26.1 Preliminary comments

Old and new technology in bulk processing
The new Comos version has considerably upgraded the tools for bulk process-
ing. These new tools are based on object queries. However, the change from
the old to the new form of bulk processing is not done automatically with the
update but is controlled by the user.
The new tools are offered in the menu bar of Comos if there are the following
data structures with underlying base objects (CDevices) in the base project:
@System|@O|@Bulkprocessing|@CDevice
@System|@O|@Bulkprocessing|@Device
@System|@O|@Bulkprocessing|@Specification
@System|@O|@Bulkprocessing|@Document
@System|@O|@Bulkprocessing|@Connector
Using these tools, documents and connectors can also be changed completely
by means of bulk processing.
If there are deeply nested hierarchical structures in the base data, these are
then made available in the Comos menu bar in the form of submenus.
The old bulk processing option Edit documents is the exception to this,
since it continues to be used.
The old form of bulk processing is offered again in the Comos menu if the
user switches to a project with the old data structure or if he or she deletes the
above-mentioned base data.
Interface for bulk processing

Bulk processing queries are always split into two areas:
• The left-hand side of the dialog consists of a standard query.
• The right-hand side displays the relevant parts of the Properties window of
objects. The “typical” mouse menus are available here. Thus the mouse
menus for static links are made available if a specification tab is shown on
the right-hand side.
Additional mouse menus in the case of specification tabs:

Bulk processing of planning objects Bulk processing
| HIDE TAB “GENERAL” / SHOW TAB “GENERAL”

| COPY TAB DATA
| PASTE TAB DATA
26.2 Bulk processing of planning objects
26.2.1 Purpose
Bulk processing makes allows the user to rapidly enter and change the general
data and attribute values for large amounts of planning data.
Open the | EXTRA | BULK PROCESSING| BULK PROCESSING FOR PLANNING
OBJECTS| BULK PROCESSING: PLANNING OBJECTS menu.
26.2.2 The left-hand window area
The left-hand area of the bulk processing window consists of a standard query
for planning objects. See SECTION 25.3: STANDARD QUERY PLANNING OBJECTS.
26.2.3 The right-hand window area
All the standard dialog fields (Name , Label , Description , Folder ) can be
used in the usual way. The pointers (here: Unit , Implementation , Base
object ) are set in the usual way by using drag & drop.
At the bottom edge of the right-hand window area you initially see a single
blank tab that is labeled General . This bottom area is used to collect, display
and edit the attributes. Specification tabs can be dragged onto this tab by using
drag & drop, see the following.

Bulk processing Bulk processing of planning objects
Changes to attributes only take effect for objects that have a specification tab
and an attribute of the same name as the changed attribute and which have the
same object class.
26.2.4 Work flow for bulk processing
26.2.4.1 Step 1: Setting the object and defining filters

Drag a planning object from the Navigator into the Start object(s) field:
Thus the root object is specified. In other words: as a maximum, all the plan-
ning objects located underneath the root object are displayed and processed.
Start object(s) : clipboard
It is also possible to set a quantity of base objects as start objects. This is done
by marking and copying a quantity of base objects and then selecting the Clip-
board entry in the Start object(s) field of the query.
Effect: a search is made for all planning objects that possess one of the base
objects or a base object that is located underneath it hierarchically (logical OR
combination).
Often you wish to further restrict the quantity of objects that are displayed
(and hence also processed). This is done by using all the settings that had
already been introduced in SECTION 25.3: STANDARD QUERY PLANNING OBJECTS. It is
the combination of the Start object(s) field and the defined filters that ulti-
mately determines what is displayed – and hence also processed – in the bulk
processing.
26.2.4.2 Step 2: Collecting and preparing attributes

Once the desired object list has been created, the attributes to be edited need
to be specified. Only attributes from the planning project can be edited.

Bulk processing of planning objects Bulk processing
• Right-click on an object in the results list of the bulk processing and select
| NAVIGATE | OBJECT.
Effect: This object is now selected in the Navigator.

• The attributes are displayed in the Navigator underneath the object. Use
drag & drop to move one of them onto the General tab of the bulk
processing window:
This drag & drop operation functions both as illustrated above in the case of
attributes in the Navigator, and with attributes that are in the Properties win-
dow of an object. They can also take over complete tabs.
An attribute is only displayed on the working area of the bulk processing if
the last object to be marked in the list also possesses this attribute!
As a reminder: You can also display and edit the attribute to be edited in the
left-hand window area. Do this by dragging the attribute into the column
header of the results list. Whether or not an attribute is also displayed in the
list window does not effect the functionality of the bulk processing. The cell
in the results list remains blank if an object does not possess the attribute.
26.2.4.3 Step 3: Save the settings

Save
The collection of attributes and tabs that has been created is saved. The set-
tings of the list window are also retained.

Bulk processing Bulk processing of planning objects
26.2.4.4 Step 4: Mark the objects

The inputs that you make at the right-hand side (of the working area) only take
effect on the objects marked at the left. As is usual under Windows, you can
mark items specifically with <SHIFT> and <CTRL>.
Pay attention to the order in which you mark the objects! The attributes that
are dragged onto the working area are only displayed if the first row of the
selection on the left in the list also possesses this attribute!
Normally the list is selected in such a way that all the marked objects possess
the attribute and then the display problem simply does not arise.
26.2.4.5 Step 5: Change the general data and change the attributes
General data
In the upper area of the right hand side of the bulk processing are the edit
fields of the general data:
You can change any of the properties with the aid of the edit fields, including
the name of the object. The multiple selection function is available for this
purpose.
If a group of objects has been marked, the Name , Description , Label , Base
object fields, etc., are shown partly in grey and partly in white. The white
background color is used when all the marked objects for this field have the
same value, for example, a common label. Otherwise the field is displayed in
grey. Both grey and white fields can be edited in the normal way.
The color changes to white if a field that had formerly been displayed in grey
is edited and the inputs are accepted: all the marked objects for this field now
possess the same value.

Bulk processing of base objects Bulk processing
Attributes
The attributes in the working area can be edited in the usual way. The way in
which the attributes are arranged in this scheme can be changed and improved
via the | DESIGN MODE command. (The position and size of the original
attributes are not changed as a result.) In the Design mode, you cannot create
new attributes or delete existing ones. The | DELETE TAB SPECIFICATIONS con-
text-sensitive mouse menu only deletes the tab from the bulk processing
scheme.
26.2.5 Closing bulk processing
Some of the intermediate results are shown in the main Navigator during the
work. But this information has not been written to the database yet, so if you
were to close the dialog window by pressing [CANCEL] the inputs that had been
made so far would be discarded and the display in the main Navigator would
revert to its initial state.
An input is only saved to the database if [Accept] or [OK] are pressed.
26.3 Bulk processing of base objects

Open the | EXTRA | BULK PROCESSING| BULK PROCESSING FOR BASE
OBJECTS| BULK PROCESSING: BASE OBJECTS menu. This bulk processing is oper-
ated in the same way as the bulk processing for planning objects.
The left-hand window area

The left-hand window area of the bulk processing consists of a standard query
for base objects. See SECTION 25.4: STANDARD QUERY BASE OBJECTS.
Please note that a planning object can also be dragged into the Start object (s)
field. In that case, the base object of this planning object is determined; from
then on everything proceeds as if this base object had been set.
26.4 Bulk processing of attributes

Open the| EXTRA | BULK PROCESSING | BULK PROCESSING FOR SPECIFICATIONS
| BULK PROCESSING: SPECIFICATIONS menu. This bulk processing is operated in
the same way as the bulk processing for planning objects.

Bulk processing Bulk processing of documents
Differentiation: Attributes can also be edited in the bulk processing of plan-

ning objects. However, it is only the planning data of the attributes that is
edited during a bulk processing operation of planning objects, i.e. the value
and the unit that had been assigned to the attribute in the planning data.
During the bulk processing of attributes the base data of the attributes is
edited. Since base data is changed, the base project must be opened. Other-
wise you would only be able to view the attributes of the base data but not to
edit them.
In addition, the bulk processing for attributes can also edit the specification
tabs and the columns of attributes lists.

for attributes. See SECTION 25.6: STANDARD QUERY ATTRIBUTES.
Drag a base object into the Start object(s) field.
All the attributes of the base object and all the base objects located underneath
it now appear in the list of results (depending, of course, on what filters had
been set).
26.5 Bulk processing of documents

Open the | EXTRA | BULK PROCESSING | BULK PROCESSING FOR DOCUMENTS | BULK
PROCESSING: DOCUMENTS menu. This bulk processing is operated in the same
way as the bulk processing for planning objects.

for documents. See SECTION 25.5: STANDARD QUERY DOCUMENTS / PRINTING.
Start object(s) : Since documents can be located under any object, any type
of object can also be set as the start object.
Please note that the Properties window of the document is edited at this point
and not the contents of the document.
26.6 Bulk processing of connectors

Open the | EXTRAS | BULK PROCESSING | BULK PROCESSING FOR CONNECTORS
| BULK PROCESSING: CONNECTORS menu. This bulk processing is operated in the
same way as the bulk processing for planning objects.

Bulk processing of connectors Bulk processing

for connectors. See SECTION 25.7: STANDARD QUERY CONNECTORS.
Start object(s) : drag a planning object into the field.
Please note that the Owner column displays the Device itself, whereas the
Name column contains the connector object. Thus the display of the Proper-
ties window in the right-hand area of the dialog window changes correspond-
ingly when you switch between the two columns.

Queries - programmer’s view
27 Queries - programmer’s view

Object model for queries
-----------------------
Query
BaseQuery
ColumnDefs
ColumnDef
ColumnEval
Cell
Filter
FilterItem
Sort
SortItem
Cell
-----------------------
Cell
Style
ValueItems
ValueItem
-----------------------
QueryBrowser
Query
QBrowserEvents
-----------------------
TopQuery
Query
Partners
-----------------------
TopQueryBrowser
TopQuery
TopQBrowserEvents
Partners
-----------------------
Partners
Partner
-----------------------
StringStorage
-----------------------
Query
Extended
-----------------------
ComosBaseObject (Device,CDevice)
XObject
TopQuery
TopQueryBrowser

Object structure in the overview Queries - programmer’s view
27.1 Object structure in the overview
27.1.1 General
shows a simplified display of the interrelations between the objects

PIC. 27-1:
of the Comos object model and objects of the query tool.
CDevice / Device
Comos Kernel
XObj
XML Archive
Application Layer
TopQueryBrowser TopQuery
XML Archive XML Archive
Display Calculation
QueryBrowser Query
XML Archive XML Archive Base query

BaseQuery
Pic. 27-1: Overview: query object model

XObj is the interface between the Comos Kernel and the Application Layer.
All information that is passed between these two layers is passed through
XObj. The information flow is bidirectional.

Queries - programmer’s view Object structure in the overview
CDevice / Device
Comos Kernel
XObj
XML Archive
Application Layer
Display Calculation
Pic. 27-2: XObj between the Comos Kernel and the Application Layer
The XML archive of XObj contains all the necessary information on the mode
of display and the calculation requirements of a particular query. In the case
of an OnLoad operation this information is passed on to the display and calcu-
lation component of the Application Layer for processing. In the case of OnS-
ave the information of the XML archives of the individual components is
collected and written back to the archives of XObj. XObj is a sort of container
for information of all kinds, which is managed within Comos like an object,
and for which typical Comos operations can be executed without actually
affecting the contents.
In the following, we will take a closer look at queries in the Application
Layer. Broadly speaking, queries in the Application Layer can be divided into
a display component and a calculation component, and these can exist inde-
pendently of one another.

27.1.2 Display component
XObj
TopQueryBrowser
XML Archive TopQuery
Display
QueryBrowser
XML Archive Query
Pic. 27-3: Overview: query display

As can be seen in PIC. 27-3: above, the display component consists of the Top-
QueryBrowser, the QueryBrowser, of the connections between these two and
of the connections to XObj, TopQuery and Query. The tasks of the display
component comprise both the visual display of the results and the manual con-
figuration and operation of the relevant calculation component. Both brows-
ers have XML archives to store the settings. At OnLoad / OnSave, the contents
of these archives are compared with the contents at the XObj archive.

Queries - programmer’s view Object structure in the overview
27.1.3 Calculation component
XObj
TopQuery
TopQueryBrowser
XML Archive
Calculation
Query
QueryBrowser Base query
XML Archive
Pic. 27-4: Overview: query calculation

The calculation component consists of TopQuery, Query with BaseQuery, of
the connections between Query and BaseQuery and of the connections to
XObj, TopQueryBrowser and QueryBrowser. Both browsers have XML
archives to store the structural information, whose contents are compared
with the corresponding contents at the XObj archive at OnLoad / OnSave.
The task of TopQuery is to assemble the original set of “objects” to be pro-
cessed, and to directly pass this original collection (OrigCollection) on to
BaseQuery for further processing.
The OrigCollection that has been assembled by TopQuery is a collection

that can be either a ComosCollection, a VB-Collection or of type
KDictionary. BaseQuery as a part of Query creates from this OrigCollec-
tion a first “virtual” two-dimensional matrix as the basis for all further oper-
ations.

TopQuery
OrigCollection
- VB-Collection
- ComosCollection
- KDictionary
Query
QueryBrowser
Base query
XML Archive
Filter ColumnDefs
FilterItem ColumnDef
FilterItem
ColumnDef
XML Archive
XML Archive
Sort
XML Archive
Cell
SortItem
XML Archive
SortItem
XML Archive
Pic. 27-5: Query in detail

Illustrates the dependencies and hierarchical relationships of the
PIC. 27-5:
object constituent elements of Query.
Archives
Almost all the objects of the Query-Tool have their own archives. The
archives are written in XML format and can be processed as files, Strings, etc.
The above-mentioned TopQueries are processed as archives in XObj by
default within Comos. The creation of archives can start at any desired level.
For example, ColumnDefs contains the archives of its items (ColumnDef), or
Query contains the archives of ColumnDef, Filter, Sort. This characteristic
is used in copy methods of the objects. In such cases a (completely) new
object of the same type is created and the archive of the source object is
assigned to it.

Decision tables Concept and scope
28 Decision tables
28.1 Concept and scope

A decision table is in a position to modify objects on the basis of rules that
have been determined beforehand. The start is triggered manually, and then
the subsequent steps are all carried out automatically.
The following objects trigger a change (condition column):
• The value (Value) or the extended values (XValue) in the case of an attribute
The following objects can react to it (action column):

• The value (Value) or the extended values (XValue) in the case of an attribute
• The base object pointer (CDevice pointer ) in the case of planning objects
• The contents of Interactive Reports
(The contents can be replaced completely: The Comos object remains
unchanged; the crp file of the Interactive Report is replaced.)
28.2 Creating a decision table

Decision tables can only be edited or used in the planning data!
1. Create a base object of class Action , sub-class Decision table in the base
data.
2. Create a planning object with this base object.
The position of the planning object already determines its use: Only
objects that are in the same branch as that of the decision table can be used
later.
28.3 Design mode
28.3.1 Addressing extended values
The following explanations apply to condition columns and to action col-

umns. If an attribute has multiple entries, these are stored in the “extended val-
ues”.

Design mode Decision tables
• Lists
Attributes of type “List” are made up as follows from a technical point of
view (by default): The columns are created as attributes. The rows are
written as extended values into the attributes. Thus if there are four rows,
each of the column attributes contains four extended values. Extended
values are visible in the Navigator, but not in the Properties window of the
columns attribute (the Value field remains blank.) If you wish to edit the
cells of a Comos list, you must therefore read the individual extended values
of the columns attributes.
• Range attributes (Min/Max attributes)
Attributes of type Edit (Min,Value,Max) and Edit (Min,Max) are made up
as follows from a technical point of view: An attribute is created, the Value
is written as a value into the attribute, and Min and Max are written to the
attribute as extended values. All three values are visible in the Navigator,
but only the Value (in the Value field) can be seen in the Properties window
of the attribute.
First of all, the columns attribute or the range attribute respectively are
dragged into the object query on the Design mode tab, optionally either as a
Condition column or as an Action column .
Then single-click twice on the Navigation description field. The cursor is
now in the cell. An index is now appended to the text: a hash sign (#) followed
by a number, starting with “0”:
#0 reads the first row of the column or the Min
#1 reads the second row of the column or the Max
etc.
The procedure must be repeated and the next index must be input for each
extended value that you wish to read or edit.
The index that was input is also displayed in the column title on the Working
mode tab.
28.3.2 Condition columns
All the attributes that are to trigger a reaction are collected in the upper win-
dow area. Pull the attributes into the upper window by using drag & drop.

Decision tables Design mode
Further rows are inserted automatically as required.

The first three are filled out automatically. The fourth – condition operator –
you must determine for yourself:
The condition operator

Here you make the selection as to how the value of the attribute is to be eval-
uated. If you use “=”, then a reaction is triggered if exactly this value is found
in the planning data. If you use “<“, then a reaction is triggered if a string that
is smaller is found in the planning data. Etc.
28.3.3 Action columns
Here the planning objects or attributes that are to be changed are input:
• attributes
• planning objects
• Interactive Reports
The Navigation Assistant

You get the Navigation Assistant if you right-click on a marked cell. All the
objects that depend on the start object in terms of content are displayed. You
can transfer an object from the suggestion list on the right into the list on the
left by double-clicking.

Working mode Decision tables
You must once again have an attribute, a planning object or an Interactive

Report at the end of the list! This is because only these three object types can
be input as objects to be changed.
If the last object does not possess one of these three object classes, you are
given the corresponding warning and it is not transferred.
28.4 Working mode
28.4.1 Conditions
In the left-hand window area you can find as many columns as had been cre-
ated earlier on the Design mode tab as condition columns. All the rows are
linked with AND.
In other words: All the values in connection with the operator must be fulfilled
within a row if the action that had been input on the right is to be executed.
Please note: The order of the rows determines the result!
The first row in which all the AND links are valid is then executed.
All the subsequent rows are then ignored.
The input line

If no valid row was found, then the last row is always executed. This row is
also called the input line and has an asterisk (*) as its value. The input line
covers all cases that had not been explicitly taken into consideration by the
user.
Entering values
In the starting situation you see a row in which an asterisk has been entered
for each condition column. Mark the relevant asterisk and input a value of
your own.
The input line is inserted automatically at the end after your input.
28.4.2 Actions
In the right-hand window area you can find as many columns as had been cre-
ated earlier on the Design mode tab as action columns. All the rows are
linked with AND.

Decision tables Documentation of the action taken
Please note: If all the conditions given in the left-hand window area
have been fulfilled, then all the actions given in this row are exe-
cuted! Thus all three objects will always be changed if you have entered three
action objects.
Input action for attributes

Click on a row and overwrite the value.
Input action for planning objects

Drag a base object into the action column. This base object is entered as a new
CDevice pointer when the action is executed.
Input action for documents

Drag another Interactive Report into the action column. If the condition takes
effect and the action is to be executed, then the former contents are deleted
without a query prompt in the case of the Interactive Report that is to be
changed and the contents of the other Interactive Reports are used instead.
Technical background: The crp file is replaced by the crp file of the other
Interactive Report.
Execute
The decision table is started by pressing the [EXECUTE] button. The conditions
are tested and the relevant actions are carried out.
28.5 Documentation of the action taken

On this tab you can find the log with details of the last run initiated by the
decision table.
28.6 Applications
Templates can also be created from decision tables.
A @Template path is set up in the planning data and a decision table is created
underneath this branch. If this decision table is copied and inserted into other
planning data, the Application tab shows where the derived decision tables
are located. See the details given in SECTION 49.5: TEMPLATES.

Controlling decision tables by scripts Decision tables
Running applications
If actions also exist for a copy template, then a [RUN APPLICATION] button
appears to the bottom right on this tab. This executes all the decision tables
that had been derived from this copy template. The conditions are tested and
the relevant actions are carried out.
28.7 Controlling decision tables by scripts

The ExecuteDecisionTables function is used to execute decision tables.
However, this command does not write any <SystemFullName>.rpt files
(execution log).
The ExecuteOneDecisionTable(DecisionTableObj) function writes a
SystemFullName.rpt file on execution, this being located in GetTempPath.
Thus you can check what happened when a decision table was run.

Old processing techniques Editing documents
29 Old processing techniques
29.1 Editing documents

For information on this topic please refer to the Comos 8.1 help files.

Editing documents Old processing techniques

Tools and utility programs Synchronize project folder
30 Tools and utility programs
30.1 Synchronize project folder

| ADMINISTRATOR | SYSTEM | SYNCHRONIZE PROJECT FOLDER
30.1.1 Documents
Application area
Project-specific comparison between the Comos documents in the database
and the files in the file directories.
Application
First open the project to be investigated and then the dialog window.
30.1.1.1 Documents tab

This tab has two tasks:
• To delete the administration files for the Comos document objects
• To delete external document files that have no application in Comos.
The dialog window is initially empty when it is opened. It is initialized by

clicking on the [START] button. No data has been changed as of this point.

Synchronize project folder Tools and utility programs
The left-hand area: delete administration files

Once the dialog window has been initialized with the aid of [START], all the
Comos documents in the project that in principal can access external docu-
ment files are displayed at the left. The columns have the following meanings:
Comos document
The FullName of the Comos object, i.e., the name plus the path.
File name
The name of the external physical file. Thus you can find a file of this name
on your drive via Windows Explorer.
File type
The file extension. Under certain situations files can be created that have the
same name and only differ in their extension. In this case several file exten-
sions appear in this column. This means that there are as many files as there
are entries shown here, each with the same file name but with another ending.
File exists
There are two possible reasons why no files exists for a Comos document,
although they apparently should be there:
- The Comos document has not been opened yet. External files are only cre-
ated physically once the object is opened for the first time within Comos.
- The external file was deleted outside Comos.
• bak files: These files are created automatically when saving reports.
• tmp files: These files are created automatically while working on a report
and are deleted automatically when a report is closed. The temp files remain
if the Comos task crashes or is terminated manually, and can be loaded the
next time that Comos is started.
• log files: The following information is written into the log file when a report
is opened: time stamp (date of the last change / user), file size at the time of
opening.
The following information is added when saving: size at the time of saving.
The log files remain and can provide useful information on the problem in
the event of an error.
• new files: This file is created when documents are saved and is thus in effect
the buffer between the crp file and the bak file.
Purpose: When a document is saved, the current version from the crp file is
written to the former bak file and then the crp file is updated. Thus both the
bak file and the crp file are changed each time that the file is saved. Both
files are placed at risk from a purely theoretical and technical point of view,
since each write access entails a certain technical risk.
However unlikely that may be, in order to prevent both the crp file and the

Tools and utility programs Synchronize project folder
bak file from being lost, a third file - the new file - is generated as well
during the save operation and this is deleted at the very end once the save
operation has been completed.
Technical sequence: First of all the new file is created. If that was
successful, the crp file is read and written to the bak file. Then the new file
is read and written to the crp file. The new file is deleted at the very end.
• lck files: These are created when reports are opened. Comos marks opened
files in this way so that other persons cannot open the document again with
write access.
[MOVE FILES]
Each project has on the drive its own directory and a Deleted directory within
a project directory. When the button is pressed, all the files of the project with
the file extensions that had been clicked on are moved to the Deleted direc-
tory.
Please note: It is not possible to make a selection in the upper left-hand list
and then to edit only the corresponding administration files. The [MOVE FILES]
command always affects all the files of a project (if the type has been acti-
vated).
The right-hand window area: Delete files without a Comos document

Once the dialog window has been initialized with the aid of [START], all the
superfluous files within the file directory for which no Comos document
exists are displayed at the right.
One are more entries can be marked and these files can be moved to the Dele-
ted directory within the project directory by means of the mouse menu. The
Deleted directory is not emptied by Comos, that has to be done manually.
30.1.2 Comparing revision directories
This tab has the following task:

• To delete external revision files that have no application within Comos.
The dialog window is initially empty when it is opened. It is initialized by

clicking on the [START] button. No data has been changed as of this point.
If there are revision files without an associated Comos document, the corre-
sponding entries appear at the right. One are more entries can be marked and
these files can be moved to the Deleted directory within the project directory
by means of the mouse menu. The Deleted directory is not emptied by
Comos, that has to be done manually.

Unit conversion Tools and utility programs
30.2 Unit conversion

Unit conversion is used to convert metric units to imperial units (British/US
units) and vice versa. The “Units conversion” tool has two components:
• The allocation of imperial and metric units (see SECTION 11.2.1.2: THE LOWER
“UNITS” DIALOG AREA“)
• The controller for the actual conversion (in this section)
Mouse-click in the PlugIn toolbar on the Units conversion icon. The follow-
ing dialog window appears:
In the upper line an indication is shown as to which project is to be affected

by the conversion (always the current project). The line cannot be edited. If a
different project is to be converted, then this other project must be opened and
the Units conversion dialog window must be reopened.
Option 1: Conversion direction
The conversion direction evaluates the units to see whether they are classified
as metric or imperial and then converts the value of the unit into the relevant
specified unit.
Option 2: Conversion objects
Base objects: The units are only converted and any existing values converted
in the case of base objects. As was explained elsewhere, the attributes of the
planning objects take over the new templates of the base objects as long as the
inheritance is not broken (meaning that no inputs have been made yet on the
planning side).
Base objects and planning objects: The conversion also applies to planning
objects.
Option 3: Conversion for:
This controls whether only those attributes are to be converted in which no
value has been input, or all of the attributes.

Tools and utility programs Object test
30.3 Object test
30.3.1 Concept
The object test is the central point within Comos in which information
relating to the objects of the Comos database is collected.
30.3.1.1 Structure of the test list

The object test saves a separate information list for each user and project.
Example: A project consists of two units. The first user edits Anl1 , the second
user edits Anl2 . Both users execute an object test; but each one of them selects
the respective sub-quantity to be tested from his or her own unit. The result is
that the first user also only sees the information relating to his or her unit; if
there is any information relating to Anl2 , he or she does not see that at all.
When the object test is opened the next time, a personal information list is dis-
played to the relevant user. Under certain circumstances the user can also see
only an excerpt from the test list, see the following.
The following principle applies here:
The test list is not overwritten. Existing entries are only deleted by the user.
New entries are added to the existing test list without changing the entries
already there.
In other words: The information and errors from the same test list often come
from very different sources. For that reason the entries in the test list are cat-
egorized so that you can scan through the list more quickly and easily. See the
next section.
30.3.1.2 Meaning of the entries

• Not critical: Acknowledgements for automatic corrections
Comos can make corrections by itself in narrowly defined situations.
Example: If you mouse-clicked on the Save symbol in the top left-hand
corner and objects with the same name already existed at that time – which
is not allowed within Comos – then one of the two objects is automatically
given a counter that is added to the name. Before the correction: Obj and
Obj , after the correction: Obj and Obj_1 .
• Not critical: Indicators regarding inconsistencies

Object test Tools and utility programs
This group is characterized by the fact that it is not possible to lose

information, nor to change data. An entry of this type can be edited
immediately or at any subsequent time as desired.
Example: The definitions of the current text masks do not match the names
of the objects.
Each company should decide on the basis of its own needs and requirements
whether in such a case the names should be adapted to suit the new
company-internal naming syntax or whether the old names are to be
retained.
• Critical: Warnings of errors (“lightning flash errors”)
All objects that have critical inconsistencies are marked with a
lightning flash.
In principle, it is not possible to exclude the possibility of, for example,
incorrect inputs by the user or inconsistencies in the course of the planning.
Comos cannot know in such cases what the user really intended to do in such
cases; hence a correction can also only be made by the user.
These objects cannot be saved and a loss of data is possible! You must edit
these entries of the test list at once.
30.3.1.3 Source of the entries

You can tell from the error list which action caused the entries:
• By save
You saved within Comos (the Save icon at the top left or via the | FILE
| SAVE) menu, or you confirmed the input of a dialog window.
• By check
You carried out a object test manually.

• By sync
Database synchronization was run.
• External
The base object pointer of a planning object was changed or a project was
imported.
30.3.1.4 Chronological sorting of the entries

The entries are sorted chronologically: the last entries to be created are also at
the end of the list.
30.3.2 Starting the object test
There are a number of very different actions that can lead to entries being
written to the test list. The object tester is not always visible here; to some
extent the entries in the test list are given in the background. When the object
test is opened the next time, then the user can see all the entries – in other
words, also those entries that had been written in the background into the test
list.
The start of the object test is also reflected in the source that was input in the
test list, see above.
• Manual testing by the user
Open the object test via the | EXTRA | TEST | OBJECT TEST menu. Drag an
object into the Test object edit line by means of drag & drop.
As a rule, this is a special branch of the structure. The object test now tests
all the objects that are hierarchically located underneath the starting node.
The test quantity should also be the entire project.
The result is that all objects with inconsistencies are transferred to the test
list.
• Semi-automatic testing in the case of Properties windows
Comos constantly checks in the background to see whether the details of the
user are correct, or whether incorrect inputs or other errors have been made.
As soon as Comos detects inconsistencies, a lightning flash is shown in the
Status line in the Objects to be checked field. The rule here is as follows:
The lightning flash is displayed if the ErrorObjects number has been
incremented by pressing OK in a Properties window.
Now mouse-click on the Test field in the Status line and select the OBJECT
TEST mouse menu:

The lightning flash in the Status line disappears again after calling up the
program. Do not confuse the lightning flash in the Status line with the
lightning flash within the test list! Even if the lightning flash is no longer
displayed in the Status line, there can still be critical entries (“lightning flash
entries”) in the test list!
• Synchronize databases
Collisions can occur during the synchronization as a result of
inconsistencies in the course of planning: the same objects were modified in
both of the databases to be synchronized. Since Comos cannot know which
modification is correct, these objects cannot be synchronized.
These collisions are documented in the test list. It is not possible to save as
long as there are any collisions present. Please note: You should not simply
cancel or undo an action, especially if it is a long and complicated one, since
the whole work step has to be undone and a great deal of working time is
lost. It is better to correct the inconsistent objects and then save.
• Import project
When a planning project is imported, this project is connected with the
applicable base project. However, the applicable base project can still be
distinguished from the base project with which the project being imported
was formerly connected.
Any inconsistencies arising as a result are displayed in the test list.
• The base project is changed in the case of a planning project
See the justification under the “import project” item.
• Changing the base object pointer in the case of planning objects
The applicable base object can be distinguished from the base object with
which the planning object had been linked previously. The inconsistencies
found as a result appear in the test list.
Example: The planning object has inherited from the former base object an
attribute that was also processed in the planning object (and thus checked
in). The new base object does not possess this attribute.
The result is that the attribute in the planning object is not automatically
deleted, but appears in the test list.
Similar cases can also occur with elements or connectors that have been
checked in.
• Support: project utility programs - [global test]
Checks the entire project.

This test resembles the process in which you drag within the object tester the
project node – the blue globe – and thus check the entire hierarchical stock
of data.
However, a global test will also find objects that no longer have an owner.
These can be objects that are left over as “junk” after unusual user actions.
But there is still a possibility that such objects might still be of importance;
please check for yourself in each individual case here as well.
30.3.3 The interface of the object tester
Open the object test via the | EXTRA | TEST | OBJECT TEST menu.
The following dialog window already includes entries if you had already
made an object test earlier. The information that had been determined in this
way is saved and displayed each time when the object test is opened.
The individual lines of the dialog window are multi-line.
If only one line is visible, use the mouse to drag any
desired line to the desired line height.
Updates the test list.

Changes can affect the first column (“lightning flash column”) in par-
ticular: the lightning flash is removed for an entry if it is no longer assessed
as a critical error.
If a root object has been set in the Checkobject field, entries can be brought
out by an update. If no root object has been set (for example, if the object
tester appears automatically when the project starts), then the list is updated
by mouse-clicking on the icon, but the number of entries does not change.
Updating does not remove entries from the list.
This interface calls up the Comos Check and Correct function. Here the
inconsistencies and errors are displayed, and corrected automatically as
well by Comos to the best of its ability.
Check and Correct (excerpt)

Display only Display and correction
Base objects
Retroactive changes to the base object, Duplicate name.
e.g., the Mode option is toggled.

Check and Correct (excerpt)

Display only Display and correction
Endless loop in the case of references. Duplicate label.
An external graphic file can be used as
an icon for base objects. Check
whether this file exists.
Text masks
Connectors
Additional information concerning Additional information
connectors if the information for the concerning connectors if the
two connectors is contradictory. information for a connector has
been lost.
Documents
Files are stored independently outside
Comos with certain documents. Check
whether these files exist.
Checkobject The root node of the test.

As a rule this is a special branch of the unit structure. The
object test now checks all the objects located hierarchi-
cally underneath the start node. The amount to be tested
can also be the entire project.
Pull an object into the Checkobject edit line by means
of drag & drop.
First column A lightning flash appears in specific situations.

(“lightning If Comos detects any inconsistencies, a lightning flash is
flash column”) shown in the Status line in the Objects to be checked
field.
Object Each cell of this column has three lines under one another
in which the three information items SystemFullName ,
FullLabel and Description are given.

Tools and utility programs Object debugger
Error Each cell of this column has two lines under one another
in which the two information items Error mode and
Error code are given.
Error Full text explanation for the Error code .

description
30.4 Object debugger

The object debugger is used to act directly on objects by means of a
script. Thus tests can be executed by means of a script query, but it is
also possible to modify objects permanently. For that reason the object debug-
ger should only be run by experienced users.
Within the object debugger debug commands can be applied to an object in a
simple way by means of an edit window. You can open the object debugger
via the | EXTRA | OBJECT DEBUGGER menu.
Three positions are provided for objects, A , B and C . They change the position
to be evaluated if you add the corresponding letters before the debug com-
mands. Example:
• A.systemuid: Outputs the name of the object within the system at position
A.
• B.Controlproperties: Displays all the layout information relating to an
attribute at position B.
Start the evaluation by pressing the button with the exclamation mark [!].
Any desired script to be tested can be input in the Script window. If the sam-
ple script was input when opening the object debugger, you can delete it.
Please note that you cannot mix script and command inputs at positions A-C
as you please.
Activate interface help... (switch activated and an object set):
If a text had been input in the Printout field, then a list of all the permissible
following commands appears after the first correct keyword. For example, the
first keyword could be “A.” if an object has been set in field A. Simply keep
on typing and the selection is refined as each extra letter is typed in. Press
<Return> to activate the greyed-out command.

External programs in the bin directory Tools and utility programs
30.5 External programs in the bin directory
30.5.1 ComosReg.exe
ComosReg.exe is a tool that recursively enters or removes the Active Server

files of a directory into or from the Registry at the system level.
Syntax: ComosReg.exe [Pfad] <opt. Parameter>
[Path]: Complete path to the directory to be processed. If none is specified,
the directory in which ComosReg.exe is located will be used.
<optional parameters>: /u is used to deregister the Active Server files.
30.5.2 DBSync.exe
See SECTION 5.3.4: DBSYNC.EXE.
30.5.3 DBExtras.exe
A database utility program that repairs and compresses Comos Access data-
bases. Set the path to the database to be processed via the edit field.
For obvious reasons, running this program requires exclusive
access to the database, so you should ensure beforehand that no
applications are accessing this database.
30.5.4 DBMon.exe
This tool is a product from Microsoft.

DBMon (Debugging Monitor) is a tool that can be started in parallel to the
current Comos session to output messages from Comos. These messages
comprise both local error messages and also information exchanged via CVS
among other Comos users.
If you wish to contact the Comos HotLine for help with problems, you should
use this program to display error messages. The error messages displayed
make it easier for our support staff to allocate and verify the problem and so
make it possible to provide solutions quickly.
DBMon only functions under Windows 2000 with administrator rights.

Tools and utility programs External programs in the bin directory
30.5.5 Dongle.exe
This program provides you with the current data on your software protection
device (dongle), which you require in connection with the licensing of the
software when looking for a solution for problems. You should have this data
ready at hand if you need to contact our Support section.
30.5.6 ExportDB.exe
You can find details on it under SECTION 3.4.2: EXPORT
30.5.7 ImportDB.exe
You can find details on it under SECTION 3.4.1: IMPORT
30.5.8 KeyCode.exe
This program generates a new release code (keycode) for the database. See
SECTION 1.2: DATABASE TYPES / KEYCODE.EXE.
30.5.9 Konverter.exe
The file konverter.exe is located in Comos directory ..\bin.

This program is used to convert obsolete system types such as “Unit”, “Posi-
tion”, “Location” to the new common type “Device”.
30.5.10 LCODBC32.exe
This file is an administrative tool that allows direct access to data in databases
by means of ODBC.
This tool should only be used by experienced system administrators
with the requisite knowledge of SQL, since it is possible to make
far-reaching changes to the databases with it.
30.5.11 MultiCRP.exe
See SECTION 44: MULTICRP.EXE.

External programs in the bin directory Tools and utility programs
30.5.12 ptmcast.exe
ptmcast.exe is a test program for the communication interface CVS (formerly

SMS). The test program is located in Comos directory ..\bin.
You can find further information on this program in the Comos installation
path under ..\Help\Deutsch\Sonstige Dokumentation\ptmcast.pdf (no English
version available yet).
30.5.13 RegMaid.exe
There is the program RegMaid.exe in the Comos directory in sub-directory \

bin. The RegMaid.exe tool from Microsoft is used to clear out OLE entries in
the Registry. You require administrator rights to run this program.
Caution: Like all tools that change entries in the Registry, this tool
must be handled with great caution! Misuse can result in uncon-
trollable system behavior and program crashes. Do not use this
program under Windows 2000!
30.5.14 SetLang.exe
Not used in current versions of Comos, and it no longer has any effect either.
In earlier versions the database language was determined by the interface lan-
guage chosen at the time of installation. It is thus only necessary to run this
program if you link new databases under Comos that the former language set-
tings do not have any information on and if you wish to immediately open the
database in the desired language.
30.5.15 SetLicPath.exe
This tool makes it possible to reassign or change over the license server in a
very simple way if this should be necessary. You then get the appropriate
message once the change has ben made.

Tools and utility programs Pause bridging
30.5.16 Sychange.exe
This tool makes it possible to transfer a system project from one database to
another:
The following should be noted:

• You require administrator rights on your system
• You require administrator rights and exclusive access to the database
selected under OUT.
Ensure that no other application is accessing this database at the same time.
• You require administrator rights and exclusive access to the database
selected under IN.
Ensure that no other application is accessing this database at the same time.
Select the database types and databases from which and into which you wish
to transfer the system project. Stipulate the file in which the error output is to
be made and then start the process by mouse-clicking on the arrow key.
30.6 Pause bridging

Open the Properties window of any desired planning object. Press <Ctrl> +
SHIFT + C and follow the instructions on the screen.

Pause bridging Tools and utility programs

System project: Standard tables Generally applicable information
31 System project: Standard tables

The standard tables in the system project are defined by Comos and may not
be edited there by users.
31.1 Generally applicable information

Changing standard tables in the system project
If standard tables are deleted or reduced in size in the system project, there is
likely to be an irrevocable loss of data.
However, the standard tables may be extended.
Aim of the ConnectionType

Connectors need not have a connector type (ConnectionType). This involves
additional information with which you can specify the ConnectionType.
When a ConnectionType has been set, this connector can only be joined to a
connector of the same type or to a connector without type (short circuit pre-
vention).
Application
A Type is defined in the window of a connector. A standard table is evaluated
in the system project on the basis of the type: ConnectionType[type]. (The
[type] must be replaced by the relevant type name.) The entries that are found
in the standard table are offered in the Properties window of the connector as
subtype.
ConnectionType: inch details

1. Check in the ConnectionType standard table in the current planning
project.
2. Enter the inches as a fraction: a/b. Inputs with this notation are
automatically recognized as inch values.
31.2 @ConnectionTypeE / Contact point types (EE/I&C)

Complete name of this standard table:
@ConnectionTypeE / Contact point types (EE/I&C)
Aim of the ConnectionType, P. 31-1
ConnectionType: inch details, P. 31-1

@ConnectionTypeF System project: Standard tables
Area of application: Properties window of the connectors, type “EE/MCR ”.

Name Unique string
Description Any. This text appears in the list “Subtype”.
Value 1 Is offered as “Subtype” and must be unique.

Value 2 Line thickness
Value 3 Line type (continuous, dashed)
Alternative: user-defined line types. See SECTION 47.1.2.3:
CONNECTOR-SPECIFIC LINE TYPES.
Value 4 - Not used.

Value 10
EE/MCR connectors can be joined with single line connectors. Standard table
SECTION 31.4: @CONNECTIONTYPEI is responsible for single line connectors. See
also SECTION 59.5.2: ALLOCATING ELO CONNECTORS AND SINGLE LINE CONNECTORS.
31.3 @ConnectionTypeF
@ConnectionTypeF / Contact point types (FC)
Area of application: Properties window of connectors, type “Functional

plan ”. 1. Controls the connection logic between two logical connectors in
module FD. 2. Defines the line thickness and line type of the connecting lines
between two logical connectors in the FD module.
Name Unique string
Description Any. This text appears in the list “Subtype”.


System project: Standard tables @ConnectionTypeI

Value 4 - Not used.

Value 10
Connection logic between two logical FD connectors

The FD base objects are set up as a mirror image: step and transition each pos-
sess a S-connector and a T-connector opposite each other, but always crossed.
In other words, a T-output at the step is matched up against a T-input in the
transition opposite, etc. Since only the same type of connectors can be joined
together, a step cannot be matched to another step, because in such a case the
S-output of Step 1 would be paired with the T-input of Step 2.
See also SECTION 65.2.2: STANDARD TABLES.
31.4 @ConnectionTypeI
@ConnectionTypeI /Contact point types (Single line)
Area of application: Properties window of connectors, type “Single line ”.

Creation of data lines / action lines between two connectors.
Name Unique string
Description Any. This text appears in list “Subtype”.

Value 4 - RGB colors (sequence: R-G-B).

Value 6

@ConnectionTypeR System project: Standard tables
Value 7 Layer.
Value 8 - Not used.
Value 10
When creating a data line, the graphic properties for the line are read from the
standard table of system project @ConnectionTypeI. Any changes in the
standard table do not affect any data lines that have already been created but
only new ones.
For the case that no matching entry is found in the standard table @Connec-
tionTypeI, the system provides internal default settings for all data lines, for
example, “Dashed connection” for W-connector connections.
See also SECTION 57.7.4: DATA LINES AND ACTION LINES.
31.5 @ConnectionTypeR
@ConnectionTypeR / Contact point types (P&ID)
For future applications. Controls the subtypes of P&ID connectors.
31.6 @ConnectionTypeS
@ConnectionTypeS / Contact point types (Signals)
Area of application: Properties window of connectors, type “Signal ”. Defines

the data types.
Name Unique string
Description Any. This text appears in list “Subtype”.


System project: Standard tables @PROPAR / Tables for project parameters
Value 3 Line type

Value 4 - Not used.
Value 10
See also SECTION 65.2.2: STANDARD TABLES.
Connection logic of the signals

Signals with the same subtype, or in other words, the same Value 1, can be
connected.
Type “Signal ” is selected in the Properties window of the connectors. Here,
all the connectors (= data types) that are assigned in the next step via standard
table @ConnectionPossibleS are defined. Example:
@ConnectionPossibleS defines that it is permissible to join connectors
ANY_DATE with DATE, TIME_OF_DAY and DATE_AND_TIME.
In @ConnectionTypeS there are the following four entries, ANY_DATE, DATE,
TIME_OF_DAY and DATE_AND_TIME, flat under one another.
31.6.1 @ConnectionPossibleS
Area of application: Addition to @ConnectionTypeS.

Name Unique string
Description Any.
Value 1 and Additional permissible connector combinations: each

Value 2 subtype in Value 2 may only be joined to the
corresponding subtype in Value 1 .
Value 3 - Not used.
Value 10
Identical subtypes may always be connected to one another, hence also if they
have not been explicitly listed in @ConnectionPossibleS.
31.7 @PROPAR / Tables for project parameters

@PROPAR / Tables for project parameters

@PROPAR / Tables for project parameters System project: Standard tables
These values are offered in the project properties: right-click on the globe,
context-sensitive mouse menu | PROPERTIES, Module options tab, “EE/IC
reference layout ” subtab. See SECTION 5.5.4: THE MODULE OPTIONS TAB.
31.7.1 @PROPAR | ELO_DOCSORT / Combo box contents
Module options , “EE/IC reference layout ” sub-tab, dropdown menu “Sort

documents ”.
Name Unique string

Description Any. This text appears in the text in the “Sort
documents ” list.
Value 1 Controls the order of the entries in the “Sort
documents ” list.
Value 2 - Not used.
Value 10
Evaluation: on EE reports. The values of this standard table define for the
links on the documents which document is the predecessor and which docu-
ment is the successor. In other words: which document is “connected” to the
other end of the link.
This connector sequence of the links does not affect the order of the docu-
ments in the Comos collection and also does not affect the order of the docu-
ments in the PrintManager.
31.7.2 @PROPAR | ELO_OUTPUT / Combo box contents
Module options, “EE/IC reference layout ” sub-tab, group Reference dis-

play : Unit label , Location label , Page label .
Name Unique string

Description Any. This text appears in the above-mentioned
dropdown lists.
Value 1 Controls the order of the entries in the lists.
Value 2 - Not used.
Value 10

System project: Standard tables @PROPAR / Tables for project parameters
The relevant entry specifies whether this constituent part of the link is evalu-
ated, hence if the link is shown in the report.
31.7.3 @PROPAR | ELO_PATH / Path / Zone output
Module options, “EE/IC reference layout ” sub-tab, group Reference dis-

play : Path (vertical) , Ladder (horizontal) .
Name Unique string

Description Any. This text appears in the above-mentioned
dropdown lists.
Value 1 Controls the order of the entries in the lists.
Value 2 - Not used.
Value 10
Specifies whether the above links of ELO_OUTPUT are to be output together

with the relevant path and zone.
CALC/ Calculated (5) : details across all documents regarding the path and
zone.
Calculation of the path and zone is limited to just one document for technical
reasons. The following trick has to be used to allow details across all docu-
ments: a number is input in the description of the document (the label) that is
used to specify the position of the document. This assumes as a precondition
that there is a template with 5 paths. A calculation is made on the basis of the
imaginary order that is derived from the label as to which sequentially num-
bered path that is within all the documents.
Example: label = 4 and the third path from the document yield CALC path 18.

@SYSTEM / System tables System project: Standard tables
31.8 @SYSTEM / System tables
31.8.1 @SYSTEM | @BridgeType / Bridge types
Contains the bridge types that are available in the terminal strips. The colors
in which the bridges are displayed are taken from table SECTION 31.8.8:
@SYSTEM | @RGB_COLOUR / RGB COLORS.
Name Unique string
Description Any. This text is offered in the mouse menu of the

connection as the bridge type.
Value 1 This is offered in the mouse menu of the connection as
the bridge type and must be unique.
This information is not visible at the connector points. It
is permissible to extend the table. DB: ridged bridge;
SO: contact bridge, open; SS: contact bridge, closed;
CB: comb bridge.
Value 2 Color of the bridge. Here is the Name of an entry of
@RGB_Colour, see @SYSTEM | @RGB_COLOUR / RGB colors,
P. 31-12.
Value 3 Cannot be changed. Controls the display of the bridge in

the “Terminal plan” Evaluation Report.
Value 4 Line thickness in mm.
Value 5 Line type
Value 6 - Not used.

Value 10

System project: Standard tables @SYSTEM / System tables
31.8.2 @SYSTEM | @DRW_TYPE / Diagram type
This table contains the diagram types, which in Comos are equivalent to the
symbol types. This table cannot be created manually. If this table is deleted or
becomes non-functional for any reason, an undamaged system project must
be copied. However, values can be added or deleted manually.
Name Unique string. The entry is case-sensitive. It is thus
permissible to create a list called “TERMINAL PLAN”
and also one called “Terminal plan”. However, it is not
permissible to use the name “Terminal plan” twice.
This string is used as the “symbol type”. Example:
Interactive Reports, options script: SymbolType =
"..."
Base objects, Symbols tab: Type column.
Description Any. For example, this appears in base objects,
Symbols tab: Diagram type column. If there is no
description, then the contents of Value1 are displayed as
an alternative.
Value 1 As with all standard tables, an entry must be made here;
but currently this entry of @DRW_TYPE is not
evaluated internally within Comos.
For that reason value 1 is currently used for another
purpose: LogoCAD IDs that are required for an import
or export operation are input.
Value 2 The default grid when importing or exporting AutoCAD
files.
Value 3 The value can be input in Value 3. If, for example, the
value is set here to “1” (1 = inch), then scaling factor 25.4
is used when converting AutoCAD drawings. Example:
DETAIL_ANS.
Value 4 - Not used.
Value 10

31.8.3 @SYSTEM | @ELO_KSP / Contact mirror
Area of application: controls the detection of objects with a contact mirror and
supplies the symbol for the contact mirror.
Name Unique string
Description Unique string. The name of the base object must be

included here. If an object possesses sub-class
Coils/Relay , then Comos compares the name of the
object against the names in this table. The object on the
report is only given a contact mirror if the name is also
found in this standard table as a description.
Value 1 Height of the symbol (this is used to specify the distance
from the next symbol).
Value 2 - Not used.
Value 10
Prerequisite: options script of the template, XDocProgID =

"ComosWspXDoc_Elo.XDoc_Elo", for example, circuit diagrams. Exception:
diagram type / symbol type DESIGN* is not used.
Editing the symbols: select the desired diagram type diagram by right-click-
ing on the header and selecting the | SELECT DRAWING TYPE command. You can
see the predefined symbols once you have switched the diagram type: these
symbols are displayed for the relevant component in the contact mirror.
See SECTION 59.1.1.3: K RELAY, CONTACTOR.
31.8.4 @SYSTEM | @LCID / Country codes
This table contains the country codes of the country settings.

Name Unique string
Controls the order in which the entries are visible.
Description Any. This text is visible when a new language is created
in the project options on the Language tab and the drop
down menu is opened.
Value 1 Country code in decimal notation.

Value 2 Country code in hexadecimal notation
Value 3 - Not used.

Value 10
See SECTION 42.3.1: SWITCHING LANGUAGES / LANGUAGE MANAGEMENT.
31.8.5 @SYSTEM | @LNTYPE / Line type
This table was replaced by base standard table @SYSTEM | LINETYPES and
has only been retained for reasons of compatibility.
Name Unique string
Description Any. This text is the visible text.
Value 1 This is the line type.
Value 2 - Not used.

Value 10
31.8.6 @SYSTEM | LNWIDTH / Line width
This table only continues to exist for reasons of compatibility.

Name Unique string
Value 1 This is the line width / thickness.
Value 2 - Not used.

Value 10
31.8.7 @SYSTEM | @ProdReqShow / Request/Product data
The entries in this table determine whether the attribute values of the request
device are displayed in a planning object or those of the real device or both
together .
Name Unique string

Value 1 This value controls the order in which the entries are
offered. In addition, Comos identifies the entries with
them.
Value 2 - Not used.
Value 10
See SECTION 61.3.3: CONTROLLING THE DISPLAY OF PRODUCT-RELATED ATTRIBUTES.
31.8.8 @SYSTEM | @RGB_COLOUR / RGB colors
The key names for the color values are saved in this table.
Name Unique string
The name in the Standard database is set up according to
the international standard for the color coding of wires:
BK = Black, BN = Brown; D = Dark, L = Light, etc.
For example, this name is called up in the Value 2
column of @BridgeType.
Value 1 Unique value. Comos identifies the entries with this

value. The values correspond to the AutoCAD scheme.
Value 2 - RGB values.
Value 4
Value 5 - Not used.
Value 10
This table is used, for example, by BridgeType , see SECTION 31.8.1: @SYSTEM
| @BRIDGETYPE / BRIDGE TYPES.

31.8.9 @SYSTEM | @WireColor / Wire colors
Application: menu | EXTRA | DETAIL, dialog window “Characteristics for

connections ”, and there Cross section / color tab, dropdown menu Color .
Name Unique string
Description Any. This text is the visible text. The entries are set up
according to the international standard for the color
coding of wires: BK = Black, BN = Brown, etc.
Value 1 Unique value. Comos identifies the entries with this
value. This value is written to the object.
Value 2 Explanation of the color codes from the description.
Value 3 - Not used.

Value 10
See SECTION 59.7.1.6: CONNECTION INFORMATION FOR CONNECTORS: DIALOG WINDOW

“CHARACTERISTICS FOR CONNECTIONS”.
31.8.10 @SYSTEM | @WireCrossSection / wire cross sections
Application: menu | EXTRA | DETAIL, dialog window “Characteristics for

connections ”, there the Cross section / color tab, dropdown menu Cross
section .
Name Unique string

In the Standard database this name is the same as
Value 1 . This gives a clearer overview, but is not
essential.
Value 1 Any value. This value is written to the object. If you

determine the cross section in the script, then for
example you do not get 0.75mm² but instead 75.
Value 2 - Not used.
Value 10


31.8.11 @SYSTEM | @WireCrossSectionAWG / American National

Standard
Replaces @WireCrossSection on ANSI diagrams. This table works in the

same way as @WireCrossSection except that it specifies the cross section in
inches.
31.8.12 @SYSTEM | WireEndHandling
The table offers various forms of wire and cable ends to choose from.
31.8.13 @SYSTEM | WireTypeInfo / Type information for wires
Application: menu | EXTRA | DETAIL, dialog window Characteristics for

connections , Cross section / color tab.
Name Unique string

In the release database this name is the same as Value 1 .
This gives a clearer overview, but is not essential.
Value 1 Any value. This value is written to the object.
Value 2 - Not used.

Value 10
The table offers various types of wires and cables to choose from.
31.8.14 @SYSTEM | DDM / DDM

DDM is an internal designation for DVM.

System project: Standard tables BOOLEAN / Yes/No
31.8.14.1CheckInKind / CheckInKind
Application: Module options, “PQM options ” sub-tab, dropdown list
Checkin mechanism.
Name Unique string
Value 1 Any value.
Value 2 - Not used.

Value 10
31.8.14.2CheckOutFolder / CheckOutFolder
Application: Module options, “PQM options ” sub-tab, dropdown list
Checkout mode.
Name Unique string
Value 1 Any value.
Value 2 - Not used.

Value 10
31.9 BOOLEAN / Yes/No

A list with Boolean values (Yes/No, 1/0). This list is used for checkboxes, for
example, to return values that are uniquely identified.

BOOLEAN / Yes/No System project: Standard tables

Base objects of the system @Local instance
32 Base objects of the system

The following overview explains the systemology and the basic structures of
the release database for Comos PT. Special objects are explained in the rele-
vant section, and the corresponding cross-references make access easier. The
database can be expanded or modified at any time without prior notice.
32.1 @Local instance

This branch is only available if local instances have been created, see
SECTION 20: INSTANCES (REDUCING THE NUMBER OF OBJECTS).
32.2 @System
32.2.1 @D Data
32.2.1.1 @GRAPHICS
Detailed information is given in SECTION 43.4: LAYERS IN REPORTS.
Level definitions for Interactive Reports are underneath this base object.
32.2.1.2 @Layer working areas

Detailed information is given in SECTION 6.4: WORKING AREAS.
32.2.1.3 @R Revision
Detailed information is given in SECTION 41: REVISIONS.
A revision is used to identify and make traceable the processing status of an
object.
32.2.1.4 @Status
Detailed information is given in SECTION 21: STATUS MANAGEMENT.
32.2.2 @O Interface
Administration objects for the control of Comos interfaces.

@System Base objects of the system
32.2.2.1 @Bulk processing

The objects that are collected here control the Comos | EXTRA | BULK PROCES-
SING menu.
32.2.2.2 @Print
Controls the interface of the Print Manager.
32.2.3 @T Tools
Contains objects for special administration tasks.
32.2.4 @Tree views in the Navigator
Alternative displays for the Navigator. Detailed information is given in

SECTION 10.2: VIEWS.
32.2.5 @ Versions of the database

Administration object for the database.

Import via Action objects Tables
33 Import via Action objects
33.1 Tables
33.1.1 Overview: Scope and concept
In Comos external tables can be imported and the data of the tables can be
stored in the form of base or planning objects. Currently Access databases,
Excel spreadsheets and text files are supported. We recommend using Access
databases as an import source.
The table import function uses ADO (ADODB.Recordset).
An import operation consists of the following steps:
1. Open the import source

First of all a database or a sub-directory must be opened. All the tables /
spreadsheets / files in it are then displayed. The table that has been selected is
then transferred to the display area. Tables can only be imported singly one
after another.
2. View the import data

Double-clicking on a table in the window of the selection area displays the
data in the display area. The column designation is used here as a column title.
The Status field at the lower edge of the area indicates the current table and
rows and the number of rows (data records) selected. The buttons to the right
and left of the Status field permit rapid navigation within the data records. Use
SHIFT + LEFT MOUSE BUTTON to make multiple selections.
3. Write the import script

The import process is controlled by means of a script. This script and all the
other details relating to a special import process are stored in an “archive” and
can always be used again.
4. Execute
The import operation starts for the marked data records. Only now is it possi-
ble to create or change Comos data.

Tables Import via Action objects
33.1.2 The interface of a table import operation
Create: There is the | NEW | NEW DEFAULT IMPORT | TABLE command in the
mouse menu for base data.
33.1.2.1 Properties window of an action object

The usual double-clicking operation opens the special interface in the case of
objects of the Action class and not the Properties window of the object. The
Properties window is opened as follows:
• In the case of the base object: You must right-click on the object in the
Navigator and use the | PROPERTIES context-sensitive command.
• In the case of the planning object: Here you cannot open the usual Properties
window. The general data of the properties (Name , Label , Description ,
Base object ) can be opened in the special interface by means of the
Properties icon button.
33.1.2.2 The interface in Draft mode

The stipulations that are saved later in the archive are developed in Draft
mode.
Preview of a table
Tree structure:
database
Script area

The icons at the top left

Navigate
Displays the object in the Navigator.
Refresh
The special interface is updated.
Save / Save as
Mouse-licking on the diskette symbol saves the object itself and including the
archive. Clicking on the arrow to the right of the diskette symbol brings up the
following commands:
• Save
This command has the same effect as clicking on the diskette symbol.
• Save as
Duplicates the object, including the archive. The following small dialog
window is opened:
You stipulate in the drag & drop field underneath which object the copy is
to be created. Simply drag an object from the Navigator into the field.
Input the name and the description of the new copy to be created in the
Name and Description fields.
Properties (only in the case of the planning object)
In the case of the planning object the usual Properties window cannot be
opened. This button brings up the general data of the properties (Name, Label,
Description, Base object).
Administration

Here you stipulate to what extent the planning object of the import operation
may be changed:
Stop / continue on error (only in the case of the planning object)

Continue on error: An attempt is made to complete the rest of the import oper-
ation.
Stop on error: The import operation is stopped. The extent to which Comos
creates data depends on the import script. If anything had been saved in the
script up to this point, then this data is imported.
Draft mode / execute (runtime)
Draft mode opens the interface that has already been shown. The stipulations
that will also be saved later in the archive are developed here.
Runtime mode is used to execute an import operation after concluding all the
preparatory work. See SECTION 33.1.2.3: THE INTERFACE FOR RUNTIME MODE (EXE-
CUTE).
Buttons at the bottom right in the script area

Regarding the Script Editor, please see SECTION 12.8.2: THE SCRIPT EDITOR.
Execute / Stop
Execute : The import operation starts for the marked data records.
Stop: Cancels the import process that has been started. The extent to which
Comos creates data depends on the import script. If anything had been saved
in the script up to this point, then this data is imported.
Undo Comos objects
All Comos objects that are imported on a test basis in Draft mode are initially
temporary. The temporary objects can be saved manually or are saved auto-
matically in specific situations (for example, when a Properties window is
opened).
This function undoes all the changes that had been created in the course of a
test import operation for objects that had not been saved yet (newly created
objects are deleted; changes in existing objects are undone).

Save Comos objects

All Comos objects that are imported on a test basis in Draft mode are initially
temporary. The temporary objects are saved manually with this command.
Any objects that have been saved in this way can no longer be undone with
the Undo Comos objects command.
Accept example
A fully usable example for an import that can actually be run is called up.
Please note that all the inputs that had been made up to then in the Import dia-
log window are lost!
Script help
The interactive script help is called up with this button, see SECTION 33.1.4:
SCRIPT FOR IMPORT ACTIONS.
Keyboard commands
If you open the tree structure on the left and double-click on a Table object
or on a Query object, the contents are displayed in the preview (here is an
example for Access):
Preview
The rows in the preview can be selected individually with the mouse. In addi-
tion, the usual selection commands are supported:
<Ctrl>+mouse-click Selects in addition the row that had been clicked

on.
<Shift>+mouse-click Selects all the data records between the last row to
be selected and the next row to be selected.
<Ctrl>+<A> Selects all the data records in the table

33.1.2.3 The interface for Runtime mode (execute)

In Runtime mode only those commands and scripts that had been developed
in Draft mode can be run. See the following interface:
Database
This field is filled in automatically and shows the name of the source that had
been selected while in Draft mode.
Table / Query
This field is filled in automatically and shows the name of the table that had
been selected while in Draft mode.
The progress display shows the number of data records already imported on
the left and the total number on the right.
Execute / Stop
Execute : The import process begins. Base and / or planning objects are cre-
ated and saved at regular intervals.
The Stop command cancels the import process that had been started. Any
objects that had been saved up to then cannot be undone.
33.1.3 Import sources
33.1.3.1 Access
Access is fully supported.
If an Access database is selected, then all the Access tables and all the Access
queries of the selected database are offered for import. All the tables and que-
ries that were found are listed with all the table columns. Information on the
type and size is also given with the table columns.
The table or query that had been selected is then imported. Tables and queries
can only be imported singly one after another.

33.1.3.2 Excel
Excel spreadsheets must use a header row. The field names are entered in the
header row.
If an Excel file is selected, then all the Excel worksheets of this file are offered
for import. The worksheets are described as tables in the import object.
The relevant table (Excel worksheet) that had been selected is then imported.
Tables can only be imported singly one after another.
Please note that data from Excel can only be imported without errors if the
columns of the Excel worksheets have been formatted (number, text), before
the first input is made. Otherwise data can be lost during the import operation.
Reason: Excel uses formats of its own such as “General”. However, this for-
mat is not a format but only a function that reacts to inputs and formats the
cells in various ways according to the situation. Standardized software prod-
ucts (SQL, ADO, TrueDBGrid) cannot work with such undefined constructs.
Retrospective changes to the column definition have no effect. Although
Excel displays on the screen the desired effect, in reality it has not changed
the formats at all. If you wish to retrospectively format an Excel spreadsheet,
each cell has to be formatted individually.
Fortunately this sort of undefined Excel worksheet can be imported into
Access and then you can open the Access database in the import object.
33.1.3.3 Text file

The text files must be saved without formatting (Text, tab delimited). Then
structure of the text file depends on the definition within the Registry. A typ-
ical structure could be as follows:
Field separator: Semicolon

Include field names in the first line: Yes
Text delimiter character: None
The settings that are valid for a PC for ADO import of a text file are in:
\HKEY_LOCAL_MACHINE\Software\Microsoft\Jet\4.0\Engines\Text
When importing a text file, there is no superordinate file in which there are
separate worksheets or tables, unlike the case with Access or Excel. For that
reason the option to select a sub-directory and to import all the text files from
this sub-directory is offered when importing text files.

The individual text files within a sub-directory are offered as tables in the
import object.
The relevant table (= text file) that has been selected is then imported. Tables
can only be imported singly one after another.
33.1.4 Script for import actions
33.1.4.1 Overview of an import script

Each script should cover the areas “Global ”, “Init ”, “ImportRow ” and
“Finish ”. In addition, the user can supplement the script with his or her own
“Subs” or “Functions”.
33.1.4.2 Script modules

Each of the individual modules can be transferred into the script at once. In
such cases it is always the actual script text that is transferred and not the
examples that have been commented out.
The following methods are available:
• Place the text marker on the desired point in the script. Then double-click
on the desired module. The script of the module is inserted at the point
where the text marker is.

• Pull a module in the script to the desired position with drag & drop:
Module Meaning
<Object> = Any desired variable name;
filled with an object.
Set RootObject = Root object in the form of a planning
<Object> object (device). In other words: The
objects in which the imported data is
stored are created underneath this plan-
ning object.
As a rule, the variable is defined in Global
and can thus also be redefined in one of
the other script constituents.
Set RootCObject = Root object in the form of a base object
<Object> (CDevice). In other words: The objects in
which the imported data is stored are cre-
ated underneath this planning object.

Module Meaning
Please note that it is possible to simulta-
neously stipulate in an import procedure a
root object for planning objects with the
RootObject command and a root object
for base objects with the RootCObject
command.
But only one project can be opened! If
planning and base objects are created
simultaneously with the various Set com-
mands, then of necessity these both land
in the same project, thus, for example,
local base objects are created in a planning
project.
Set <Object> = NewOb- Reference object / reference command:
ject(<RelativeName>, Set RootObject
[<Description>])
<RelativeName> = Name plus the speci-
fied path relative to the root object. The
levels of the path are separated with the
default separator. “X|XY”: In this case a
node “X” would be searched for or created
under the root object and an object with
the name XY would be searched for or
created there.
<Description> Optional: Sets or over-
writes the description of the object (here:
XY).
Note also: CNameForNewObject
Set <Object> = NewCOb- Reference object / reference command:
ject(<RelativeName>, Set RootCObject
[<Description>])
<RelativeName> = Name plus the speci-
fied path relative to the root object. The
levels of the path are separated with the
default separator. “X|XY”: In this case a
node “X” would be searched for or created
under the root object and an object with
the name XY would be searched for or
created there.
Optional: Sets or overwrites the descrip-
tion of the object (here: XY).

Module Meaning
Set <Object> = New- Creates a new attribute and/or a new Spec-
Spec(<CObject>, <Nested- ification tab for a base object.
Name>, [<Description>])
<CObject> = The base object at which the
new attributes are created.
<NestedName> = The NestedName is the
combination of the name of the Specifica-
tion tab and the name of the attribute - sep-
arated by a period (full stop).
Example: Chap1.Spec1 is attribute
“Spec1” on the “Chap1” tab.
<Description> Optional: Sets or over-
writes the description of the object.
Please note: The Control properties (loca-
tion of the attribute on the tab, size of the
attribute, etc.) cannot be set.
SpecValue(<SpecOwnerOb- Sets the value of an attribute or overwrites
ject>, <NestedName)>) = it.
<vNewValue>
<SpecOwnerObject> = The object vari-
able of a device or CDevice. (No string
variable with the name of a device or
CDevice!)
<NestedName> = Combined name of the
tab and the attribute. (String)
<vNewValue> = The new value.
SpecUnit(<SpecOwnerOb- Sets the unit of an attribute or overwrites
ject>, <NestedName)>) = it.
<vNewValue>
<SpecOwnerObject> = The object vari-
able of a device or CDevice. (No string
variable with the name of a device or
CDevice!)
<NestedName> = Combined name of the
tab and the attribute. (String)
<vNewValue> = The new value.

Module Meaning
<Variant> = Field(<Field Alternative command for <Variant> =
Name>) StrField
Fetches information from a special cell of
the current row of the imported table.
<Variant> = Variable of type variant
<FieldName> = Name of the column
(field name) or the index of the field, start-
ing with one.
<String> = Alternative command for <Variant> =
StrField(<FieldName>) Field
Fetches information from a special cell of
the imported table.
<String> = Variable of type string
<FieldName> = Name of the column
(field name) or the index of the field, start-
ing with one.
OutputDebugString <Text> Supplies output to DBMon.
CNameForNewOb- Set ... = NewObject
ject(<Index>) = <FullName> Stipulates a base object for the level (or to
be more precise, the planning object that
makes up this node). The base object must
exist already, the base object could also
have been created already at an earlier
point in time while the script was running.
<Index> = Number of the level starting
from the root object. In example “X|XY”:
The node “X” has index 1 and the object
“XY” has index 2. (The first level is
always given the number 1.)
<FullName> = Name plus the specified
path relative to the project of the base
object, e.g. “@U|Anl1”.

Module Meaning
Select Case <...> A normal VBScript routine: Is activated
... when (Case) occurs.
End Select
For i = <...> To <...> A normal VBScript routine: Runs for as

... many times as stipulated.
Next
For Each <...> In <...> A normal VBScript routine: Runs for as

... many times as there are Members in this
Next Collection.
Do <...> A normal VBScript routine: Runs for as

... long as the condition (Do...) is fulfilled.
Loop With Exit option.
While <...> A normal VBScript routine: as for Do ...

... Loop, but without the Exit option.
Wend
The following variables are automatically available:

• WorkSet
Supplies the entire Comos environment. All the possible functions and
properties can be found in Reference 1. See also SECTION 33.1.4.3:
DECLARATIONS: comos.dll.
• Project
Supplies the current project. The command is the quick alternative to
WorkSet.GetCurrentProject.
33.1.4.3 Declarations
This tab displays the functions and properties of the DLLs. A number of
important DLLs have already been entered in the drop-down list:

• ISGlobalObj.dll
The functions and properties that are made available as script modules are
programmed in this DLL. See SECTION 33.1.4.2: SCRIPT MODULES.
• comos.dll
Displays all the functions and properties of the WorkSet. See the Comos
Core Reference.
The following applies for all DLLs:
The last level (functions and properties) can be transferred as follows to the
script: <Ctrl>+drag & drop
Apart from the DLLs offered in the list, any other meaningful DLL can also
be dragged into the edit field. The corresponding DLL is read in and its func-
tions and properties are offered. Nonetheless, the DLL is not saved perma-
nently and must be dragged manually into the list again next time.
33.1.4.4 Example
The following example can be used to import planning objects.
CNameForNewObject(1) = “MyTest|ABC”
CNameForNewObject(2) = “MyTest|MM”
These two rows ensure that the planning objects of

the first level (Index=1) and the objects of the
second level (Index=2) are linked with base
objects. The base objects must exist already.
ImpObjectsCount = 0
Here a counter is initialized to zero.

Sub Init()
' Let us assume that such an object exists already
Set RootObject = Project.Devices.Item("XX3")
Object XX3 is set as the root object in the start

routine that is run right at the beginning. XX3 is
directly underneath the project. All objects that
are created subsequently land underneath this root
object. This assumes that XX3 exists already. If
XX3 does not exist, there is an error.
End Sub
Sub ImportRow()
RName = "Imp|" + StrField("CategoryID")
Here a string is assembled that likewise supplies

the node and the name for the objects to be created
later. The name is made up of two constituent parts:
- a fixed text portion "IMP|": this fixed
constituent supplies the node, under which the
object had been created
- and the text, which is likewise read from the
cells of the imported table - this variable text
serves as the name of the object to be created.
Set ND = NewObject(RName, "imported object")
New objects are created. RName was created as a

string further above. The text "imported object" is
always used as the description.
If Not ND Is Nothing Then

ImpObjectsCount = ImpObjectsCount + 1
End If
If the object was created correctly, then the

counter from Global is incremented by one.
End Sub

XML data Import via Action objects
Sub Finish()
OutputDebugString CStr(ImpObjectsCount) + " objects impor-
ted"
End Sub
The number of imported data records (= number of

objects created) is output in DBMon.
End Sub
33.2 XML data

Create: There is the command | NEW | NEW DEFAULT IMPORT | XML DATA in the
mouse menu for base data.
33.2.1 Scope and concept of the table import function
External XML data can be imported into Comos and stored in the form of base
or planning objects.
The table import function uses DOM (MSXML.DOMDocument).
The data is first read into the action and displayed on the screen for checking,
but it is not actually imported into the Comos database until the second step.
The import process can be controlled by means of a script. This script and all
the other details on a special import process are stored in an “archive” and can
be reused at any time.

Import via Action objects XML data
33.2.2 Application
In the upper part of the action (1), the XML file to be imported is allocated
either by drag & drop or via the Open XML file window and the associated
XML code is displayed in the field underneath.
The instructions on how the XML data is to be handled are input in the script
area (2) in the form of a VB script.

The part on the controls that applies generally has already been explained, so
for that reason only special points relating to queries are discussed at this
point.
This button opens the following administration mask:

XML data Import via Action objects
These two buttons turn on Draft mode (left) and Runtime mode
(right) respectively:

Query Reimport Read the data into the query
34 Query Reimport
This query makes it possible to reimport Comos data that was exported to
Access or Excel and edited there:
Please note that it is not possible to reimport text files or XML files. The pre-
requisite for the correct use of the query is the input of the local ID (Lan-
guage.LCID) for Comos languages.
The reimport is done in the following stages:
• Read the data into the query interface.
• The data items to be imported are checked individually and the actual
reimport is planned.
• Transfer the data into the database.
34.1 Read the data into the query

Select the database
Select a table from the database:
Read the data into the query interface.

No Comos data is changed yet. The data that has been read in can be
edited, see the following.

Prepare the data Query Reimport
A progress bar can be shown during the reading operation, depending on the
data to be imported and the speed of the computer:
34.2 Prepare the data

Prepare the data that has been read for the reimport operation:
Column Action selection

Is offered initially by Comos. No change is possible if the Status column has
been set to “Red ”.
The action is changed by right-clicking on a cell and making another selection
from the mouse menu.
Column Status
Each status value has a Tooltip (a small yellow Post-It that appears when
the mouse cursor hovers over the cell). The meaning of the status value is
explained in this Tooltip.
The Tooltip can also be shown as a column of its own. Do this by right-
clicking on the head of the Status column. Select | NEW
| STD. REIMPORT COLUMNS | STATUS DESCRIPTION.
– Status “Green”: The value of the rows being viewed has changed since
the export and there are no reasons that would prevent a reimport.
– Status “Yellow”
An import is not necessary. The value that is being viewed has not
changed since it was exported and there are no external changes or the
changes within Comos match the external changes.

Query Reimport Carry out the reimport
– Status “Red”
Importing is not possible! Example: the Comos object no longer exists.
Column Import value

All the white cells can be changed. Cells highlighted in grey cannot be edited.
34.3 Carry out the reimport

The data read into the query is written back to the Comos data. This
button is only activated after the data has been read.
Before the database is updated, you have to confirm a safety promt.
The log is opened in the lower window area:
Comos checks all the objects during the import operation to determine
whether they possess all the necessary rights at the project and/or object level.
If that is not the case, the import is rejected at those points. The individual
error messages can be seen in the import log:
Double-click on an entry for an error to jump to the corresponding entry in the

import list.

Carry out the reimport Query Reimport

AutoCAD (Import, Export DXF) Export
35 AutoCAD (Import, Export DXF)
35.1 Export
35.1.1 Preparations
In Comos the import and export of DWG data is controlled by an ini file. This
ini file contains conversion stipulations for the colors, lines, layers, etc.
The DWG Mapping Editor creates and modifies such ini files via a Windows
dialog that is easy to understand. The DWG Mapping Editor can be opened in
the Comos iconbar „Plugins “. Thus a correct dxf.ini file must be created by
the DWG Mapping Editor before the export operation.
The import operation always uses the file comos\ocx\reportdxf.ini.
• General tab
DWG/DXF version : AutoCAD 14, AutoCAD 2000.
Polyline : AutoCAD recognizes two different types of “circles”: on the one
hand there are true circles and on the other hand there are circles made up
of line segments. “True circles” can only be fully controlled externally as of
AutoCAD 2000.
AutoCAD 14 , Polyline ON: Circles are exported as polylines (which are
made up of several lines). The circle attributes (color, line thickness) are
exported as well.
AutoCAD 14 , Polyline OFF: Circles are exported as true circles. The circle
attributes are not exported and the circle is drawn in AutoCAD with the
default parameters.
AutoCAD 2000 , Polyline ON: Circles are exported as polylines (which are
made up of several lines). The circle attributes (color, line thickness) are
exported as well.
AutoCAD 2000 , Polyline OFF: Circles are exported as true circles. The
circle attributes (color, line thickness) are exported as well.
• Line types tab
Is not evaluated during an export operation.

Export AutoCAD (Import, Export DXF)
The following allocation is always applied:
$DWG COMOS
CONTINUOUS 1
ACAD_ISO02W100 2
ACAD_ISO03W100 2
ACAD_ISO04W100 4
ACAD_ISO05W100 5
ACAD_ISO06W100 1
ACAD_ISO07W100 9
ACAD_ISO08W100 2
ACAD_ISO10W100 3
• Colors tab
Is evaluated.
• Layer tab
Is not evaluated, but if this has been defined in the Comos drawing layer that
has not been entered yet into dxf.ini, this is automatically saved there.
• Combination tab
Is not evaluated.
35.1.2 Exporting
Reports can be exported as AutoCAD files. This is done by opening the Prop-
erties window of the report and by selecting the [AUTOCAD EXPORT] button on
the Report tab:

AutoCAD (Import, Export DXF) Export
35.1.3 Scope of the interface
The following information and objects can be exported from a report to

AutoCAD:
• Layer
• Scale
• Lines
• Comos lists
Lists are broken down into lines and texts.
• Cross-hatching
• Circles
Depending on the AutoCAD version and settings, either as true circles or
polylines.
• All report objects that can support a script
The script is evaluated to do this. This determines which objects are
generated in the script (texts, lines, etc.). All these objects are generated,
exported, and put together in a block.
• bmp files
• Texts
Line breaks are exported as well. The current language is exported. If the
texts have translations as well, then not all the languages are exported but
only the one that is currently visible.
• Dimensions
Dimensions are broken down into texts and lines. Dimensions are not
exported as such as “dimensions”.
• Objects with the DXF tab
If a planning object possesses the DXF tab, then a block is created and all
the attributes of the DXF tab are created as “attributes” of the block.
Exclusions
• Deactivated (gray optional) objects are not exported to DXF.
• AutoCAD does not support the “ico” (icon) data format. For that reason
icons are converted into bitmaps when they are exported to AutoCAD.
• Dimensions are broken down and are not exported as such as “dimensions”.
• wmf files are not exported.

Importing AutoCAD (Import, Export DXF)
• Circles: AutoCAD recognizes two different types of “circles”: on the one

hand there are true circles and on the other hand there are circles made up
of line segments. “True circles” can only be fully controlled externally as of
AutoCAD 2000.
• The color “white” is not exported. In AutoCAD the color “white” is
interpreted in all manner of ways, for example, as “black” in screen views
and as “gray” in hard copy output. For that reason the color “white” is not
exported at all so as to avoid any problems or errors.
35.2 Importing
An import operation is carried out in two stages.
1. Importing an object
In this case the AutoCAD object still exists as a totality. This is called an
“embedded object”.
2. Breaking down the object
The AutoCAD object is broken down into Comos objects.
35.2.1 Importing an AutoCAD drawing
AutoCAD drawings can be imported into Interactive Reports or used in a base

object as a symbol.
• Importing into a report: Drag a dwg or dxf file from Windows Explorer into
the report.
• Importing as a symbol: Open the Symbols tab of a CDevice and choose file
selection from the bottom of the Symbol field with the aid of the [...] button.
In the following dialog field you can also select dwg and dxf files from
under the Drawings heading.
No Comos objects have been generated yet as of this time and also no conver-
sion file dxf.ini or dxf_inch.ini has been evaluated. The display of the
AutoCAD object is done with the aid of Windows and AutoCAD interpreters.
In other words: The display of the placed AutoCAD object is not yet con-
trolled by Comos at this time.
The AutoCAD object possesses its own properties.

AutoCAD (Import, Export DXF) Importing
Properties of the AutoCAD object

AutoCAD objects cannot be selected in the usual way: They are not “lassoed”
by a selection frame and also you cannot simply mouse-click on them.
Instead, AutoCAD objects have a selection box:
You can only make a selection by mouse-clicking in this box. Only then can
the context-sensitive mouse menu be called up. There are the following com-
mands in the context-sensitive mouse menu:
<Default commands>: These function in the usual way.
| CONVERT DWG/DXF DRAWING TO PDS OBJECTS
A stage 2 import is done, or in other words, the generation of Comos objects.
See SECTION 35.2.2: CONVERT DWG DRAWING TO PDS OBJECTS.
| BREAK DOWN DWG/DXF DRAWING TO PLANNING OBJECTS
See SECTION 35.2.3: BREAK DOWN DWG DRAWING INTO PLANNING OBJECTS.
| BREAK DOWN DWG/DXF DRAWING GRAPHICALLY
However, in this case only report elements are generated. No planning object
or base object. See SECTION 35.2.4: BREAK DOWN DWG DRAWING GRAPHICALLY.
| ANALYZE DWG/DXF DRAWING
No import, but a form of preparation for an import operation. The DWG draw-
ing is analyzed and the results are written out to a new conversion file. The
file has the name of the dwg file: Thus the file Motorantrieb.ini is gener-
ated from the file Motorantrieb.dwg.
Analysis options: If an analysis of the drawing is started, first of all a small
dialog window Analyze DWG/DXF file with two options appears. These two
options are not evaluated. Fundamentally, only the layers and lines that are
used in the ini file are input.
The dwg values now only need to have Comos values assigned to them within
the DWG Mapping Editor. See SECTION 35.2.3.1: DWG MAPPING EDITOR.

| DWG/DXF MAPPING EDITOR

No import, but a form of preparation for an import operation. Opens a blank
template for a conversion file in exactly the same way as does the icon in the
Comos toolbar. See SECTION 35.2.3.1: DWG MAPPING EDITOR.
| PROPERTIES
The information on the embedded AutoCAD object is shown in the Properties
window:
Filename : Path to the embedded AutoCAD file.

EDITABLE
The individual elements of the drawing can selected and deleted individually.
Layers
The layers of the AutoCAD object are shown here. Layer 0 must always exist.
Visible: You can switch between Yes and No by double-clicking. The corre-
sponding layer is displayed or not displayed in the report as is the case.
Plotting: Cannot be set.
35.2.2 Convert DWG drawing to PDS objects
PDS stands for “Plant Design System”. This involves third-party software.
Comos PT can import data from PDS. The import operation is done in two
stages:
1. Importing the database objects via the special PDS import interface.
2. Importing the associated graphics and then breaking down the graphics
into PDS objects. The constituent parts of the graphics are then allocated
to the PDS database object.
In other words: The “Convert DWG drawing to PDS objects” option presup-
poses that PDS database objects had already been imported.

35.2.3 Break down DWG drawing into planning objects
The AutoCAD drawing creates base objects and planning objects. These are
placed on the report.
The following import dialog appears:
File version
Self-explanatory.
ini file : In the ini file are the parameters that control the import operation. The
ini file thus determines how specific objects are to look like after the import-
ing (for, example the line thickness, etc.). The ini files are edited with the
DWG Mapping Editor, see SECTION 35.2.3.1: DWG MAPPING EDITOR.
Create base objects only
Only base objects are created; There are no planning objects and also no
report elements.
Correct point of origin of page automaticaly
ON: The lower left-hand point of the AutoCAD drawing to be broken down
is placed at the lower left-hand point of the report. The origin of the report is
not evaluated.
Unit conversion: Controls how large the generated objects are to be shown.
With 1:2 the report elements are shown at double the original size after being
broken down. With 1:0,5 the result would be displayed at half the original
size.

35.2.3.1 DWG Mapping Editor
General
In Comos the import and export of DWG data is controlled by an ini file. This
ini file contains conversion stipulations for the colors, lines, layers, etc.
The DWG Mapping Editor creates and modifies such ini files via a Windows
dialog that is easy to understand. The DWG Mapping Editor can be opened in
the Comos iconbar.
You can find a sample file in Comos directories /ocx/dxf.ini and
/dxf_inch.ini.
If changes are made in the DWG Mapping Editor and a dxf.ini file or a
dxf_inch.ini file is saved at another point, then this file is used in the cur-
rent working session. The template files in the ocx directory are used again
after restarting Comos.
When an AutoCAD object is broken down, you have the option to choose a
specific ini file.
Interface
• General tab
Ignore all hidden layers: Layers that have been grayed-out in AutoCAD
are not imported into Comos.
Drawing type : You must select a type of plan, since layers are defined in
Comos according to the type of plan.
• Line types tab
Self-explanatory.
• Colors tab
Largely self-explanatory. Important additional information:
– You can find a corresponding command in the menu: You can call up a
complete sample matching between DWG colors and Comos colors with
“Create DWG color palette”.
• Layer tab
Largely self-explanatory. Important additional information:
– You can find a corresponding command in the menu | SET COMOS LAYER
AUTOMATICALLY. Application: First select a number of rows at the Layer
tab, then run the | COMOS LAYER... command from the Icon menu.

– You can input a “-” (minus sign) in the cells of the Comos Layer
column. The minus sign is translated into the text @IGNORE. All DWG
elements whose DWG layer has been allocated to Comos layer @IGNORE
are not imported.
– Label column: Here you can input additional information, such as the
Headerclass. Example: You can then write a script in which this label in
the texts is evaluated and so specific text would not be created as text
objects but instead as connector objects.
• Combination tab
Here you can identify special objects with the aid of all the convertible
properties (color, lines, layer) and convert them individually. In other
words: Even if only one of the properties is described inaccurately, then the
individual object in question cannot be found and converted.
35.2.3.2 Other import settings

• Automatic scaling when importing AutoCAD files: Details are input into
standard table @DRW_TYPE (often in the system project) for the
individual types of plans. For example, Value 1 contains a LogoCAD label,
Value 2 the detail grid.
The unit can be input in Value_3. If for example the value here is set to “1”
(1 = inch), then scaling factor 25.4 will be used when converting AutoCAD
drawings.
35.2.3.3 Central base data branch for DXF imports

• If DWG drawings are broken down while using the “Create base data”
option, then the base data is stored in branch Import | @DXF:
– If an import is made into the base project and if a corresponding node
does not yet exist there, the latter is created automatically.
– If an import is made into a planning project and an Import | @DXF
node already exists in the base project, then no such node is created in the
planning project. Instead local base objects are created in the existing
node (which is in the base project anyway).
If there is no Import | @DXF node in the base project, the node is created
in the planning project.

• Importing DXF data within a planning project:

A check is made individually for each object to see whether it already exists
in the base data of the base project. Only objects that do not already exist in
the base project in Import | @DXF are created within the planning project.
• Importing DXF data within a planning project:
When overwriting symbols (which can be selected via a dialog when
carrying out the import) the base objects in the base project remain
unchanged. The existing symbols in the base project thus take priority and
an import is only made in this case for symbols that exclusively exist in the
planning project.
• If you wish to modify the symbols in the base project, that must also be done
in the base project of the import.
35.2.3.4 Scope of the interface

Please note: For technical reasons there is no way to “undo” an importing of
dwg / dxf drawings. An import can be undone to the extent that you can close
the report without saving it.
All objects that are created or made up as follows are taken into consideration
and imported:
• Circles, arcs
Also when mirrored, if applicable.
• Lines, polylines, LwpType, MLine
• Vertices (endpoints of polylines)
• Solids
• Cross-hatching (HatchType)
• Blocks
Scaling, shifting, rotating and mirroring are taken into consideration for
nested AutoCAD blocks as well.
Text shifting in AutoCAD blocks is taken into consideration.
AutoCAD objects with subsequent changes in text height in placed text
blocks are taken into consideration.
• Text, MText (MText includes line break)
During the conversion the text height is checked to ensure that it has a size
of at least 1 point; If the value is smaller than this, it is set to 1 point.
Report texts are located in the set layer and not in layer 0.

• AttDef
Are converted into report texts.
• AttribDef
Are converted into attributes.
• Texts made up of text attributes are also generated if the associated block
does not have any graphic elements or Attdefs.
• Dimensions
Dimensions including texts are imported immediately, but only as a graphic.
This has the advantage that the overall display is consistent.
Texts are not generated if the text is an empty string!
Units supported during importing: “inch”, “mm” and “no unit”, If the import
finds that the AutoCAD drawing has the unit “inch”, the ini file
DXF_inch.ini from the OCX directory is used automatically.
Exclusions
• Ellipses are not imported.
35.2.4 Break down DWG drawing graphically
The user gets the same dialog window as that described in SECTION 35.2.3: BREAK
DOWN DWG DRAWING INTO PLANNING OBJECTS. Nonetheless, the Only create base
objects option is deactivated, since no base objects are created.
The DXF import is carried out as described, but after that all the report objects
are broken down into report elements and subsequently all the planning
objects that had been generated are deleted.
At the end of it all, the AutoCAD object that had been broken down exists on
the report in graphic form, but no planning objects or base objects have been
created.


CDI (Comos Document Interface) Excel
36 CDI (Comos Document Interface)

Excel and Word documents can now be filled with Comos data by means of
a CDI script. This means that the inclusion of external documents into the
base object has been radically restructured and simplified.
In older versions of Comos keywords and script commands were used in the
external document, which had to match the corresponding Comos compo-
nents.
Now the external documents are also programmed within Comos itself, just
as in any other Comos component. All the capabilities, aids and tools of
Comos programming are available.
Please note: The CDI (Comos Document Interface) module is not included as
standard with the license for standard licenses.
The CDI plug-in can be started by this button on the Toolbar.
36.1 Excel
The Comos Document Interface (CDI) offers two options for data transfer
with MS Excel:
• a pure export to Excel, and
• an export with a subsequent reimport of the processed data into Comos.
36.1.1 Interface
The underlying procedure is the same in both cases, however:

• Create a document at the desired location.
• Set the Type to Excel sheet :

Excel CDI (Comos Document Interface)
You can find further information on possible settings on the tabs under
→ADDITIONAL PROPERTIES OF OFFICE DOCUMENTS. Save the settings and close the
document.
Now open CDI. If the focus in the Navigator is still on your Excel document,
CDI automatically transfers the document:
Otherwise you must manually allocate the target document to be processed

(by drag & drop).
The CDI interface consists of two areas:
• The script area (on the left). Scripts in CDI always begin with the call Sub
DoCDI() and end with End Sub , the instructions as to how the information
is to be collected and processed is between those lines.
• The XML area (on the right). After starting the XML converter by pressing
the button, a preview of the cells concerned and the exported information
is given here.
Use the button to switch between the tree-type display and the XML dis-
play. Here is the tree-type display:

and the XML display is as follows:
This button opens a help screen. You can find further information in the
section →SCRIPT HELP.
36.1.2 Comos -> Excel
For this case there is a ready-made example that you can call up in Comos. In
this example all the attributes and values of an object that is located hierarchi-
cally directly above the document are output in an Excel worksheet.
• Create an Excel document underneath an object (a unit, a device, etc.) as
described:
• Start CDI. If necessary, allocate the corresponding Excel document to the

input field in the header area of CDI by means of drag & drop.
• Insert a blank line in the script area in between Sub DoCDI and End Sub.
The cursor stays put in the blank line.
• Mouse-click on the question mark button to open a help screen. On the
Examples tab you should mark the text between Sub DoCDI and End Sub
and copy the text with <Ctrl>+C.
• Close the help screen and paste the script into the blank line by using
<Ctrl>+V:

When you run the script by pressing the button, an overview of the
exported information appears in the right-hand window.
You can open the Excel document in the Navigator for checking and /or fur-
ther editing by double-clicking on it. The data is transferred and is now avail-
able to you under Excel with all the usual functionalities:
You require an extensive knowledge of VB Script, of the Comos object struc-

ture and of CDI functions to be able to use CDI correctly. You can find expla-
nations of the CDI functions under →SCGLOBAL.
36.1.3 Comos -> Excel -> Comos
If Comos data is to be reimported after external processing, then a number of

special points must be noted. The “Content” command is of central impor-
tance at this point.
• content: Automatic writing-back to Comos
If Comos information is transferred to Excel by means of CDI and the
Content function, then any changes made in Excel are automatically
written back to Comos when Excel is closed.

Content possesses the following parameters:

DocPointer Pointer to the worksheet and cell of the reference doc-
ument in the form <worksheet name>!<cell> as a
string
ComosObject Comos object, whose properties and their values are
transferred to Excel and also sent back again by Excel
as applicable
PropName Name of the object property that is output to Excel in
string form
PropParameter Possesses object property parameters to be output,
which can be input here. (Example: GetInternational-
Description , parameter LanguageIndex)
PhysUnitLabel Physical unit of the value of the project property as a

string. If this parameter has been input, i.e., it is not
blank, you get the PropParameter on the Excel side
as the number that can be used for further calculation
IOMode If no paramter value is passed for IOMode, a bi-direc-
tional data transfer is carried out. If "O" is passed as
parameter value, the value is only exported, if "I" is
passed, it is only imported.
PhysUnitLabel: Targeted formatting as a number

The PhysUnitLabel parameter is explained again here in more detail due to its
importance. Normally Comos information is passed to Excel in the form of
text. However, the information can also be explicitly formatted as numeric. In
that case a physical unit must be given in the last parameter of the Content
function:
Content “sheet1!A2”, Spec, “DisplayValue”, “”, “µm”
When you input a unit (in the example: “µm”), the relevant value is displayed
within Excel as a number (the cell contains the format “Numeric”) and con-
verted. The unit stated within Content therefore does not need to match the
current unit in the Comos attribute. If a unit that does not exist in the units
group is used, then the current unit of the Comos attribute is used automati-
cally.

Data transfer
Data is transferred between Comos and Excel by means of the OnOpen and
OnClose events, i.e., the data is transferred from Comos to Excel when the
Excel document is opened and entered into the Excel worksheet. Data is trans-
ported back when the document is closed.
Safety valve @U1.1.X001 with its Specifications tabs is to serve as a demon-
stration object here:
The procedure is largely the same as before. Create an Excel document at the
desired point and start CDI. The basic layout of the script is the same, the col-
umn headers of the table are stipulated at the beginning, then there is the nav-
igation to the attributes to be output. In this example all the attributes of the
“Technical Data” section are to be output.
The Technical data tab of safety valve
@U1.1.X001 includes a series of attributes,
but no values have yet been allocated to them
apart from “BT0001 Pipe size = 20”. The stan-
dard tables within Comos that lie behind
attributes L05-L07 and L09 and L10, which
can subsequently be made visible, can like-
wise be edited from within Excel.
The following script is a simple example to
show how a detailed interactive transfer of
data between Comos and Excel is possible
with just a few lines of script code:

Sub DoCDI()
'Find Object
Set DocOwner = Document.Owner
'Find tab
Set testab = DocOwner.Specifications.Item(TD)
Here you get the tab with the name “TD“.
The complexity of the navigation depends on the relative position of the Excel
document with respect to the object information to be processed. In the
present example the document is located in the hierarchical substructure of the
safety valve by which the Owner function can directly access the owner of the
attributes to be output.
But since in principle the document in Comos can be located at any desired
place within the object structure, navigation becomes somewhat more com-
plicated as a rule. We therefore recommend using the Set function to define
variables that contain objects that can be reached in partial steps within the
navigation. This procedure reduces on the one hand the amount of inputting
and the risk of exceeding the maximum permissible number of characters per
line and thus the likelihood of errors, while on the other hand this gives a
clearer overall picture and in addition makes reuse much simpler. A good
knowledge of the object structures and of VB and Comos commands makes
it considerably easier to create correct script instructions.
The next thing to do is to specify the headers for the table columns. The Con-
tentFix command is used for this. ContentFix has two parameters, a document
pointer DocPointer and a parameter of type Variant , which can include both
objects and strings, etc. ContentFix is used in all cases where it is not neces-
sary to transport the information back:
’Column header of Excel sheet
ContentFix „sheet1!A1“, „Comos Object“
ContentFix „sheet1!B1“, „Tab“
ContentFix „sheet1!C1“, „Specification“
ContentFix „sheet1!D1“, „Value“
h=2 ’New row
ContentFix „sheet1!A“+CStr(h), DocOwner.Name+“ „
+DocOwner.Description
ContentFix „sheet1!B“+CStr(h), testab.Description
In the next step the individual attributes are collected by a For..Next loop and
their description and value (Description, DisplayValue) placed in the
“Attribute” and “Value” columns of sheet1. The Content command is used
because values are to be taken from the Excel document at this point. It is
important to input all the parameters, even if they are “blank”.

For i = 1 to testtab.Specifications.Count
set SpecEx = testtab.Specifications.Item(i)
ContentFix „sheet1!C“+Cstr(h), SpecEx.Description
Content „sheet1!D“+Cstr(h), SpecEx, DisplayValue, „“, „“
h=h+1
Next
End Sub
After that the line index is incremented and the loop and the subroutine are
concluded.
Start the XML converter with . The following display shows a number of
special points:
• XML display of ContentFix output (1)
• XML display of Content output (2)
• XML display of selection fields under an attribute (3, 4)
1
2
You should now see the following display when you open the Excel docu-
ment:
The standard tables holding the attribute within Comos are transferred to
Excel and can likewise be edited there:

CDI (Comos Document Interface) Word
geändert
The changes shown above were made in the Excel document. If the document
is closed now, these changes take effect in the attributes in Comos, as the fol-
lowing illustration makes clear:
36.2 Word
36.2.1 Comos -> Word
Example task: A series of data items from several objects are to be collected
together and output in tabular form in a Word document.
Create a new document for this purpose, if you have not done so already, at
the desired location. Set the Type to Word document :

Word CDI (Comos Document Interface)
You can find further information on possible settings on the tabs under
→ADDITIONAL PROPERTIES OF OFFICE DOCUMENTS.
Open the Word document and create a table with the required number of rows
and columns:
Mouse-click on the desired table cell and select menu item Field from the
| INSERT menu:
The following input mask appears:
There you should select Document automation under Categories and

DocVariable under Field names , and in the input field under Field
function you should add the stipulated entry Docvariable to the variable
names of your choice.
Note the space between the automatic input and your variables!

CDI (Comos Document Interface) Word
If you create field variables in a document to which variables and data had
already been allocated, then an “error message” can appear. Do not worry
about this, Word attempts to generate references to old variables at this point.
Right-click on the message and toggle the field functions within the mouse
menu. In the right-hand part you can then see the complete and functional
entry for the field function.
In order to keep the amount of programming required to a minimum, we have
found that it is good practice to use ColumnTitle + LineIndex as DocVariable
names in tables, as you can seen below:
Now input the field functions into all the desired fields, as shown in the above
example, save the Word document and then close it.
Tip: You can make the work easier if you create a table line complete with
field functions, copying it several times, and then editing the copied field
functions (line index) individually!
A unit was created in the unit branch of the Navigator as a demonstration
object and a number of valves and fittings were allocated to it. The Word doc-
ument was created under one of the valves and fittings:
The aim is to output into the table of the Word document the number, name,
description and the value of attribute VC12 on Specifications tab GD of all the
valves and fittings underneath our object.
In the first step it is necessary to navigate to the unit object by using a script.
This is done by means of the following instruction
Set unit = Document.Owner.Owner
Next, all the objects underneath the unit with

Set Element = Unit.Elements.Item(i)

Word CDI (Comos Document Interface)
and the associated attribute VC12 from the Specifications tab GD with
Set GDSpec = Element.Specifications.Item(„GD“).Specificati-
ons.Item („VC12“)
are put together in separate steps.

The output syntax is in the general form of:
ContentFix <DocumentPointer>, <Object>
DocumentPointer : the field variable created within Word in string form.

Object : a Comos or VB object.
The full script is:

Sub DoCDI()
Dim rowcount,count,i
rowcount = 5
count = 1
Set Unit = Document.Owner.Owner
For i = 1 to rowcount
Set Element = Unit.Elememts.Item(i)
Set GDSpec =
Element.Specifications.Item("GD").Specifications.Item("VC12")
ContentFix "Pos" + Cstr(i), i
ContentFix "Count" + Cstr(i), count
ContentFix "Name" + Cstr(i), Element.Name
ContentFix "Descr" + Cstr(i), Element.Description
ContentFix "Spec" + Cstr(i), "pressure" +" "+
GDSpec.DisplayValue + " "+"bar"
Next
End Sub
As has already been stated above, handling CDI correctly requires a corre-
sponding understanding of the Comos object model, its classes and its pecu-
liarities as well as a good knowledge of VB Script. You can find more detailed
information on the Comos object model, the Comos classes, functions and
constants, etc., in the Comos Reference Core.

CDI (Comos Document Interface) Additional properties of Office documents
36.3 Additional properties of Office documents
36.3.1 General tab
You can store further information as required in the Description 2 and Des-
cription 3 fields on the General tab. The number of pages and the first page
are generated automatically.
36.3.2 Specifications tab
The Specifications tab is not already filled, here there is the option for the user
to create his own attributes.
36.3.3 “Excel sheet” / “Word” tab
The labelling of this tab is linked to the selection of the document Type from
the “General” tab. The basic functionalities of this section do not differ in
terms of the selected document type.
Under the Document heading you can select between:

Normal Default setting
File link Opens the FILE NAME input field, here you can
either input the full path to the file manually or
else select it via the Folder button in the file
selection mask.
Reference Opens the TEMPLATE input field, here the selec-
tion mask of the Comos document template is
opened via the button at the right.

Script help CDI (Comos Document Interface)
The owner of the document is entered automatically under the object head-
ing, but another owner can be set and deleted again at this point by using drag
& drop.
36.3.4 Revisions tab
See also SECTION 41: REVISIONS.

The Revision tab displays the revision history of the document, the settings
and behavior do not differ significantly from those on Revision tabs at other
points within Comos. Nonetheless, there is the difference in that the pages are
printed individually when printing the revision of multi-page Office docu-
ments.
36.4 Script help

CDI has programming help built in. Call up this help by clicking on the icon
bar in CDI on the question mark (“Help ”).
On the Script modules tab there are a number of ready-made standard routines
that can be transferred into the Script window by double-clicking on the cor-
responding field or by using drag & drop. A syntax example is given for each
module:

CDI (Comos Document Interface) Script help
The Declarations tab provides further information on the available classes ,

functions , subroutines , properties and parameters . Here is an example for
Content:
A good knowledge of the VisualBasic programming language and of the

Comos object model is required to understand and use correctly the informa-
tion listed there.
Script texts from the Examples tab can be copied and pasted into the Script
window by marking the text with the mouse.

ComosXML object classes CDI (Comos Document Interface)
36.5 ComosXML object classes

The following information given below relates to the functions, subs and
properties of the classes declared in XMLContent.dll :
36.6 Document
36.6.1 Property
36.6.1.1 Pointer
Example / Syntax:Pointer ( ) as string
Pointer in string form.
36.7 SCGlobal
36.7.1 Function
36.7.1.1 ExcelABC
Example / Syntax:ExcelABC ( ByVal Index as Long ) as string
Calculates the corresponding Excel field designation from a numeric value.
For example, “341” produces “MC” in Excel.
36.7.2 Property
36.7.2.1 Document
Example / Syntax:Document ( ) as IComosDDocument
Read only. Supplies the current document as a Comos object for further use.
Thus, for example, the hierarchically superordinate object can be determined
with Document.Owner .
36.7.2.2 Project
Example / Syntax:Project ( ) as IComosDProject

CDI (Comos Document Interface) SCGlobal
Read only. Supplies the current project. This is required so as to be able to

clearly and uniquely allocate any data to be written back and to handle the
associated Comos objects.
36.7.2.3 ReportObject
Example / Syntax:ReportObject ( ) as IComosBaseObject
Read only. Supplies the document owner as a Comos object for further use
and thus the option for navigating within the Comos environment by means
of the usual script notation.
36.7.2.4 WorkSet
Example / Syntax:WorkSet ( ) as IComosDWorkset
Read only. Supplies the current Workset as a Comos object for further use.
This makes possible further navigation in the Comos environment with the
usual script notation.
36.7.3 Sub
36.7.3.1 Content
Example / Syntax:Content ( ByVal DocPointer as string, ByVal ComosOb-
ject as IComosBaseObject, ByVal PropName as string, ByVal PropParame-
ter as variant, ByVal PhysUnitLabel as string )
The use of this output command makes possible the transferring back of data
from the MS Office world into the Comos environment.
DOCPOINTER inputs the MS Office target variable,
COMOSOBJECT the associated Comos object,
PROPNAME the name of the object property,
PROPPARAMETER the value of the property, and
PHYSUNITLABEL the physical unit.
36.7.3.2 ContentFix
Example / Syntax:ContentFix ( ByVal DocPointer as String, ByVal
vNewValue as variant )

SCGlobal CDI (Comos Document Interface)
The output command for Comos data into the Microsoft Office world. The
first parameter gives the corresponding MS Office target variable in string
form, the second the information to be transferred.

RNE (Report to Excel) Area of application
37 RNE (Report to Excel)
37.1 Area of application

Please note: The RNE (Report-to-Excel) module is not included in the stan-
dard licenses.
With the help of the Report-to-Excel module, Evaluation reports can be
exported in Excel format. The data can be edited fully in Excel and even the
layout of the Excel page can be changed as required.
With that, you can forward Comos data to companies that do not use Comos,
e.g. suppliers.
Scope of export
Following report elements can be exported:
Lines, circles, text boxes, checkboxes, SubReports, lists, checkboxes, picture
boxes and WMF images.
37.2 Preparation of the Evaluation Report

Report elements may not overlap on an Evaluation Report, or lie outside the
the sheet area. There is one exception: Free graphics may be placed on top of
other report elements.
37.3 Start export

To start the export, open the Print Manager, set a start object and then mark
one or more Evaluation reports in the results list.
Then, in the options, activate the “Extended functions” and click the “Report-
to-Excel ” icon in the Print Manager icon bar.
37.4 Control via the options script

xlFoldermargin (numeric)
The variable xlFoldermargin can be entered in the options script of a report.
Thus you can set a margin for the page in mm that takes effect when the report
is written to Excel.
ExcelRaster (numeric)
Changes the report grid.

Control via the options script RNE (Report to Excel)
ExcelMergeAll (bool)
If the variable is not used in the options script, False is used.
If the variable has been set to True, blank text fields are also exported to
Excel. Bank text fields are not exported if it was set to False (this gives better
performance).
Hairline, ThinLine, MediumLine, ThickLine (numeric in mm)
In Excel, there are four line types with different line thickness. VVariables
with identical names as in Excel have been created in Comos. Example:
Hairline=0.2, ThinLine=0.5, MediumLine=0.75, ThickLine=1.0
In this case all Comos lines with a line thickness of between 0 mm and
0.2 mm are regarded as type Hairline, and lines between 0.2 mm and
0.5 mm in thickness are regarded as type ThinLine, etc.
All four variables must be set, otherwise this technique cannot be used. If
none or not all of the variables have been set, then the default setting Thin-
line is used for all cell borders.
ExcelSheetScaleH, ExcelSheetScaleV (numeric in percent)

These variables calculate the size of the object properties from scratch. Thus
the text sizes, line thicknesses, width, height, etc., of the objects are corre-
spondingly scaled up or down when an export operation is carried out.
The SheetScale function thus has nothing to do with zooming, which
increases or reduces the size of the display of the object on the monitor but the
size of the object itself remains the same.
Values between 50% and 120% are permitted.
Background: The amount of time required by Excel to calculate an imported
object increases with the size of the object. Excel thus requires noticeably
more time to calculate a large text field than a small one. If the export opera-
tion to Excel takes a very long time, then you can speed it up by setting the
sheet-scale to a smaller value. This will require somewhat more time, since a
calculation is made within Comos for the smaller size, but on the other hand
Excel requires noticeably less time to generate the objects.
The SheetScale option is functionally identical to Sheet scaling in the
Save file dialog window when the export to Excel is prepared within the Print
Manager.
ExportFreeGraphic (bool)
If ExportFreeGraphic has been set to True, then the free graphics are
exported to Excel as well. These graphics are not exported if the variable has
not been input or was set to False.

RNE (Report to Excel) Reimport
Background: In Evaluation Reports circles and lines are classified according

to whether they fulfil a “function” or are “free”. A line fulfils a “function” if
it is part of a text field frame or visually separates a column or a row, etc. The
line is “free” if it does not fulfil a function.
In practice, lines nearly always fulfil a function within Evaluation Reports,
since a table is drawn in the report, text boxes are drawn, etc., with the aid of
lines. Therefore, in the default setting, lines and circles in Evaluation reports
are regarded as having a function.
For lines, the user can define whether a line is to be functional or “free”. To
do that, the user opens the Properties window of the line and click the No cell
delimiter button. With this button, the “G” label is set internally, with which
Comos identifies free graphics.
exVisible (bool)
If the variable has been set to True, then Excel remains visible during the
export operation and you can see how the individual elements are generated
one after another in Excel. If the variable doesn’t exist or is set to False,
Excel is not visible.
The export operation is much faster if Excel is not visible.
37.5 Reimport
It is possible to reimport such exported Evaluation reports.
• The report options script must have the following commands:
Keepscriptrunning = True
ExcelMergeAll = True
ExcelReimportModus= True
The ExcelReimportModus variable generates a “Shadowtable”, i.e. a

hidden Excel sheet.
All cells that can be re-imported are represented in Excel with green
background.
Log file during reimport

Options script ExcelMergeError = True
A file ..\temp\ErrorExcelExport.log is created if there is a collision. This

file contains the report objects (with X and Y-coordinates) that were overwrit-
ten by other report objects.

Reimport RNE (Report to Excel)

XML / MotionX Overview
38 XML / MotionX
38.1 Overview
No particular XML format is supported within Comos, but in principle any
XML format can be handled.
• SECTION 38.2: NAVIGATOR DISPLAY FOR XML DOCUMENTS
• SECTION 38.3: LINKING SPECIFICATIONS AND XML ATTRIBUTES
• SECTION 38.4: FREE IMPORT / EXPORT (XML CONNECTORS)
• SECTION 38.5: MOTIONX SERVER
38.2 Navigator display for XML documents

The following example uses the standard DB.
Comos can handle the normal XML information. The structure information of
XML files is hierarchically nested: both the start and the end of a “level” are
labelled with a tag. This hierarchy can be read and displayed automatically by
the Navigator.
In the simplest case you drag an XML file from Microsoft Windows Explorer
into the Comos Navigator by using Drag&Drop:
Technical effect of using Drag&Drop on the XML file

A window opens, prompting the user to decide whether the file shall be copied
or referenced. Then, an XML document without template is created:
• Mouse-menu at the XML document, | PROPERTIES
• Tab General , field Type : XML - Connector - Document
• Tab XML - Connector - Document , field Template : blank.

Navigator display for XML documents XML / MotionX
• Tab XML - Connector - Document , field File name : is set if you

answered the user prompt on whether the document is to be copied with
[NO].
The XML document in the Navigator

The XML document can now be displayed in the Navigator. As usual there is
a plus symbol (+) in front of the XML document to expand the substructure.
If you click on this symbol, the structure of the XML file is displayed as a tree
structure:
Please note: Since the XML file can contain a great deal of data, it sometiemes
may take several seconds until the nodes underneath an XML Connector doc-
ument can be displayed. The computer appears to have frozen during that
time.
The nodes that are displayed in the Navigator are not objects, since the XML
file has not actually been imported into the Comos data. The XML file is only
displayed in terms of its structure.

XML / MotionX Navigator display for XML documents
Definitions
Comos recognizes XML elements and XML attributes and displays these
XML modules in the Navigator. However, the display in the Navigator has
been simplified and does not correspond to the formally correct definition.
This is how an XML element is displayed:
This is how an XML attribute is displayed:
XPath
XPath stands for “XML Path Language”. This is a query language that has
been developed by the W3C consortium to address portions of an XML doc-
ument. Using a special notation, you can go through the document tree step-
wise, in any direction and from any point. The notation is similar to the well-
known file paths already used in file systems and URLs. Example:
/doc/chapter[5] selects the 5th chapter in doc.
Mouse menus and mouse operations for XML files

The usual Comos mouse menu is not available for the elements and attributes
in the XML tree structure. Only the | XPATH command is available.

Linking specifications and XML attributes XML / MotionX
A mouse menu is only available for the entire XML document:
| OPEN
The XML document has no interface of its own and hence cannot be opened
like normal documents. If you select | OPEN command for the XML document,
the XML structure is displayed in a browser window.
The elements in the XML tree structure cannot be edited by using
Drag&Drop. Only the XML document as a whole can be copied in the usual
way by using Drag&Drop.
38.3 Linking specifications and XML attributes

You can find the new edit mode “Values in XML (limited functionality) ” in
the specifications (attributes).
Area of application:
When importing or exporting large amounts of data.
Effect:
With these specifications you are not working with a Comos object at all
times. Instead, the following details are stored in the XML string of the
device:
• NestedName of the specification
• Value
• Unit

XML / MotionX Free import / export (XML Connectors)
Since temporary specification objects are created at runtime, everything

appears to be unchanged in the interface. But these specification objects are
not saved; instead the values and units are stored in an XML string.
Since the XML specifications are no longer regular specification objects, this
results in a number of limitations if you wish to work with the objects them-
selves. (You cannot see any difference as long as you only work with the val-
ues and units.)
• A query as to whether the specification object has been checked in always
returns True.
38.4 Free import / export (XML Connectors)
38.4.1 Aim / basic principles of XML Connectors
The term “XML Connector” describes not only a single object or a single
interface. An XML connector consists of several constituent parts: the XML
document, XML document template, object queries. The term “XML Con-
nector” is to be regarded rather as the collective term for a particular technol-
ogy. If we talk of a specific XML Connector, then what is meant is a specific
XML interface that consists of all the required objects.
XML Connectors import and export data that has been structured in accor-
dance with a valid XML format. The XML format need not necessarily cor-
respond to Comos’s own XML format. Hence an important task for an XML
Connector is to handle the mapping between the data model in Comos and the
third-party XML format.
This mapping can be bidirectional, because, as a matter of principle, an XML
Connector in Comos can be used both to read and to write XML data.
Contrasting Comos data and XML data

Before you can start working with XML Connectors, you should already have
a good deal of experience in working with queries. You need to be able to
bring the hierarchical structure of the Comos data into a tabular form by
means of a query structure.
In the following pages you will learn how to use object queries in order to
export or import an XML structure.

Free import / export (XML Connectors) XML / MotionX
Structure of a typical XML file

XML files have a tree structure. As a rule, however, XML files have “collec-
tions” of similar elements on the individual levels of the hierarchy. The name
of these “collections” can be whatever you wish. The name “Loops” is used
in the following example that is given for clarification:
<?xml version=“1.0“ encoding=“UTF-8“ ?>
- <XML_Export xmlns=“http:\\www.xmlorg.com>
- <loops Test=““>
+ <loop no=“F4455“>
+ <loop no=“L4444“>
+<additional_loop_data>
-<loop_identification>
<subproject_no>W1</subproject_no>
<unit_main_no>H1</unit_main_no>
<unit_sub_no>T1</unit_sub_no>
</loop_identification>
</loop>
</loops>
</XML_Export>
In the example, there is a level “<loops Test=““>” (the collection), which

has “loop” nodes (the elements of the collection).
You can use this typically highly structured layout of XML files to your avail.
Mapping between the XML file and the queries

The first important task is to “teach” a query that, for example, it is always
responsible if a module <loop> (or any other unique name) exists on a partic-
ular level of the XML file.
The second important task is to “teach” a query which Comos property
belongs to which XML attribute.
Finally, the third task will be to create a suitable hierarchy of queries.

About the first task: mapping of a query to specific modules in the XML file.
You can see in the following example that a query is always responsible if
node /Drive/Object exists in the in the XML file:
The same picture also illustrates the implementation of the second task: the
mapping of the cells of a query to a particular XML attribute. It is clear that a
particular column of the query is always responsible if the attribute
“CDevice” is found underneath /Drive/Object:
On the same principle, you can also process data if there are various “collec-
tions” on a level of the XML file. In an ideal case you would then create a
query for each of the collections that is only responsible for this one collec-
tion:

The following two screenshots illustrate the principle. In the first picture you
can see the query that is responsible for the “HSD” modules:
In the second picture you can see the query that is responsible for “SYS”:
Both queries are “responsible” for the same level of the XML file, as you can
see from the identical information in the Start-XML-Node field. But each of
the queries handles a different collection of information on this level.
The queries are called as often as they are needed:
• While query “Q1 Drive” is creating element “Object (Label=F1)”, then the
two queries “OA1 Spec, HSD” and “OA2 Spec, SYS” are called to create
the next level.

• And while query “Q1 Drive” is creating the next element “Object
(Label=F2)”, then the two queries “OA1 Spec, HSD” and “OA2 Spec, SYS”
are called again to create the next level.
The process continues in this way until all the data has been processed.
Please note: the above example has only been provided for clarification and
would not occur exactly like that in actual practice. For example, it is by no
means necessary to identifiy the specifications “HSD...” and “SYS...” with
two different queries. The specifications could be identified just as well or
even better with just one query.
Special tasks for importing

It is only necessary for an import operation to configure the queries in a way
that enables them to create new row objects .
38.4.2 Implementation in the interface
The Comos data that has been identified or created is displayed on the Comos
tab. The counterpart to this tab is the XML tab: the data that has been identi-
fied from the XML file is displayed here.
The Mapping tab is used to create a specific data level in such a way that the
results are the same on both the Comos tab and the XML tab:

The “rows” in the XML document are mapped to the rows of the query. What
is meant by “XML row” here, is actually a level of the XML structure. The
columns of the query are mapped to the following XML nodes (XML ele-
ments or XML attributes):
If you have several nested queries, then in an ideal case the row objects of the
previous query will be the repsective start objects for the following queries.
Reset the start fields (fields Query , XML Collection , Comos Collection )
and edit the next level. The XML Collection and Comos Collection fields
are also to be regarded as counterparts:
If the queries are nested, all subordinate queries are always executed per row.
For more information see SECTION 38.4.6: CONFIGURE XML CONNECTOR.

38.4.3 XML template (XML Connector template)
Two types of documents have been prepared for XML Connectors:
The template is created as usual in the base project on the Documents tab:
The XML template is the template for the XML document. However, XML
documents need not necessarily have an XML template. For example, an
XML document is created without an XML template if you drag an XML file
into the Navigator by using Drag&Drop. See also Technical effect of using
Drag&Drop on the XML file, P. 38-1.
However, if the XML document is required for an XML Connector, then an

XML template must also exist.
Attribute “XMLEnvelope”
Tab XML , attribute XMLEnvelope |”Envelope ”
You can enter fixed strings that are built around the imported XML content
with the aid of this specification. Hence this surrounding information is not
mapped either.
For example, that can be the definition of the XML format. An example:
<?xml version="1.0" encoding="UTF-8" ?>
<CAETest xmlns:xsi=„http://www.w3.org/2001/XML-Schema-
instance“>
<Content/>
</CAETest>

Here, you enter the information as to which XML definition is used. However,
this detail is not the basis for the mapping but instead is only used for infor-
mation. The mapping is done by manual configuration of the queries, see the
following.
The Comos data is inserted later at the location of placeholder <Content/>.
38.4.4 Configuring queries for XML
The actual definition of the XML Connector is implemented by means of a

hierarchy of queries that are located under the XML Connector template:
38.4.4.1 Changing templates

Please note that each of the actions described below and any changes made to
a property also change the query itself. No copies or the like are displayed.
What you see are the properties of the actual queries that are available here.
This also applies if you are in a planning project and the queries are in the base
project. This likewise applies if the queries have just been created or deleted.
Thus, this function is very similar to the | OPEN DOCUMENT TEMPLATE function
that is used in a planning document.

38.4.4.2 Properties of a column, Extras

Right-click in the head of a column, | PROPERTIES, Extra tab:
Key column
Each query can have multiple key columns. The key columns as a whole serve
to uniquely identify an object within Comos. As an example: in Comos the
total of the name of the object, the unit and the position is always unique. If
you were to create three columns in the query and fill them with the name,
unit, and position respectively, and if all three columns were key columns,
then in that case you could assign any object.
Link / XML mapping

The “link” that is entered here is a path description that is similar to the for-
mally defined “XPath” but has been optimized to suit the relationships within
Comos. This Comos-specific path supports Element-Name and Attribute-
Name. Examples:
/ABC/@XY
/ABC/MN
@XY
The user thus enters a string in this field, describing precisely when used later
together with other similar link strings which element (or attribute) of the
XML file is being referred to.
In order to be able to enter a meaningful string at this point, you need to know
the structure of the XML file fully, and also what hierarchical structure of
queries is used to make up the XML file.

Mapping table for values

These options are required in the event that the data shall be changed during
the import or export operation. Hence, in the end the data in Comos and in the
XML file will be differerent in some way or the other.
Examples:
• A text is to be converted into another key text. To give an example: in
Comos “mm” is the unit for the unit millimeters, but in the XML file the
string must be “Millim”.
• Import and export values need to be mapped to another value on the basis of
a fixed key. (Multiple import values produce a Comos value or vice versa).
Please note that such a simplifying mapping excludes any form of
bidirectional mapping. In such a case you can only export or import, but not
both.
A standard table is set in the “Mapping Table ” field for this purpose:
• | ADMINISTRATOR | BASE DATA | STANDARD TABLES
• Use Drag&Drop to drag a standard table into the “Mapping Table ” field.
Please note that standard tables from the planning project, the base project or
the system project can be used. Comos saves only the name of the standard
table and not from which project the standard table originated. Comos
searches for the standard table in the following order: |Planning project |Base
project |System project.
Thus if a standard table from the base project is set and later on, in the plan-
ning project, a standard table is created that has the same name but different
contents, the standard table from the planning project will “win” and take pri-
ority.
Column with Comos values / column with external values

These two text fields relate to the standard table specified above in the
“Mapping Table ” field.
Each text field contains a column of the standard table, the one column con-
taining the Comos values, the other one the values that are to be imported or
exported.
Logically enough, the values in these two textfields must differ.
The columns can be specified as follows:
Text “Name”. If you enter this text as key, then the “Name ” column of the
standard table is used.

Text “Description”. If you enter this text as key, then the “Description ”
column of the standard table is used.
A number between 0 and 9. The number stands for the corresponding value
column, hence, for example, “0” for column “Value 1”.
38.4.4.3 Options of a column, MotionX

Right-click on the header of a column, | OPTIONS, MotionX tab:
A row is displayed on the MotionX tab for each column in the query.
On the MotionX tab the various default properties of the query are displayed
in the form of columns, these being, for example, the name, description, mas-
ter column, etc. You can find details in SECTION 24: OBJECT BROWSER on the
meaning and use of these properties.
The following sections only cover those columns that come from the XML
Connector technology.
Link
This field has a similar function to the “Link” field described above, see Link
/ XML mapping, P. 38-13.
The only difference is that this “Link” field applies for the XML file as a
whole. To put it more simply: this field identifies the position of the XML file
as such, while the “Link” fields in the column properties serve to find ele-
ments within the XML file.
Show link
Displays in the column header of the query the text from the “Link ” field.

“Master” column
The master column tells the query which cell contains the object that is being
searched for or is to be created in the OrgCollection. There can only be one
master column. The master column is a general function of queries, but can
also be useful for an import operation.
Key column
The key column had already been introduced in the properties of a column,
see Key column, P. 38-13. As was described there, key columns are used to
uniquely identify an object within Comos. Each query can have multiple key
columns.
The key column is required in an import operation so that you can identify the
Comos objects that are to be changed, create new Comos objects or even
delete Comos objects. The key columns do not play a role in an export oper-
ation.
Link (import/export)
Here is the link from the properties of the column, see SECTION 38.4.4.2: PROPER-
TIES OF A COLUMN, EXTRAS. A change here would have the same effect as marking
the column, selecting the | PROPERTIES command and changing the link there.
Mapping table / Column with Comos values / Column with external values
Here are the details from the properties of the column, see Mapping table for
values, P. 38-14. A change here would have the same effect as marking the col-
umn, selecting the | PROPERTIES command and changing a detail there.

38.4.5 XML Document (XML Connector document)
The XML Connector Document is the object with which the XML Connector
is made available:
The same XML Connector is used for import and export operations, or in
other words, the same XML Connector Document with the same XML tem-
plate.
38.4.5.1 Properties
Tab “XML Connector Document”:
Template
An XML template can be set here. In particular, the specifications are taken
over from the template and the queries located underneath the template are
evaluated.

File name
An XML file that is then displayed in the Navigator can be set here, see
SECTION 38.4.2: IMPLEMENTATION IN THE INTERFACE.
Report object / Owner

The report object can serve as the starting point for a number of different auto-
matic functions. For example, when importing data the report object can be
used as the initial owner underneath which the new objects are to be created.
Mouse menu of the document:
The functions are explained in the following.
38.4.5.2 Export
Right-click on the document, | EXPORT:
File name
Here you can search for a file (which is then overwritten) or else specify a file-
name for the new file.

Reference
All calculations and actions necessary to prepare the export operation are
started from this object.
Include in version management
This option has nothing to do with DVM. This option has the effect that an
XML Connector document is created during the export operation. This docu-
ment is linked via the “File name ” field with an XML file that is located in
the documents directory of Comos.
38.4.5.3 Import
Right-click on the document, |IMPORT:
File name
Here you must select the file to be imported.
Reference
All calculations and actions necessary to prepare the import operation are
started from this object.
Delete objects
If this option has been activated, then all the objects that are already in Comos
but are not included in the XML file that is to be imported are deleted.
Create working layer
Creates a new working layer and switches over to it. The data to be imported
is created in the new working layer.

Include in version management

This option has nothing to do with DVM. This option has the effect that an
XML Connector document is created during the import operation. This docu-
ment is linked via the “Filename ” field with an XML file that is located in
the documents directory of Comos.
Consider different objects only
This option also changes the effect of the “Include in version
management ” option, since a comparison is no longer made with the
actual Comos objects during an import operation. Instead, a comparison
is made with the previous version of the XML file during the import
operation.
During the import operation you can edit only the changes from the
previous version if you so wish. This option presupposes that at least one
import operation that used the “Include in version management ”
option has already been carried out and hence that there is at least one
other version of the XML Connector document.
38.4.6 Configure XML Connector
Right-click on the XML Connector document, | CONFIGURE XML CONNECTOR:
This interface comprises almost all the tabs and functions that could be useful
for MotionX. The functions change the template, i.e. the XML template and
the underlying queries. You must have the necessary rights to be able to work
with this interface, especially if the XML Connector document is located in
the planning project but the XML template is located in the base project.

38.4.6.1 Preparations
In order to be able to work with this dialog window, both the XML template
and the queries underneath it must already exist. The queries are configured
by means of this dialog window.
In addition, an exemplary XML file must exist already. If you wish to use this
section of the manual as an example, then you can create a file for testing by,
for instance, exporting an XML Connector and then opening the resulting
XML file in the dialog on the right. In practice such a method does not really
make sense, but it is quick and uncomplicated.
38.4.6.2 Interface
General control elements

Query
Displays all queries that are located underneath the XML template. Select
here the query with which the import/export operation is to be started.
This field has an additional function: it can simulate the effect of what hap-
pens when a query calls up subordinate queries in order to calculate the next
level of the XML file. Do this by selecting the rows on the tabs and then
switching within the Query dropdown menu to a subordinate query. That way
you can simulate a particular state that is passed on to a subordinate query dur-
ing the import or export operation. Background information: if you have sev-
eral nested queries, then, in an ideal case, the row objects of the previous
query become the repsective start objects for subordinate queries. See also
SECTION 38.4.1: AIM / BASIC PRINCIPLES OF XML CONNECTORS.
[...] (Edit queries ) Displays all queries underneath the XML template. Que-
ries can be created (see Edit query container, P. 38-23), deleted, and also edited to
a certain extent (name, description, base object).
Start Comos object
You can drag an object from the Navigator into this field.
Start XMLNode
If an XML file has been selected in the right part of the window, you can now
drag one of the nodes into this field by means of Drag&drop. Initially the top-
most start node of XML file is set.
Tab “Comos”
This tab is a query for planning objects and is also used in just such a way.
The planning objects are displayed here, depending on the “Start Comos
object” field.

This tab can be edited in exactly the same way as the query itself. Any change
at this point is written back to the query. For example, if you insert a column,
then a new line appears on the Mapping tab and the actual query itself also
gets this column.
Tab “XML”
The table on this tab displays the “XML attributes” from the XML field that
has been opened in the right side of the window, or in other words, the leaf
nodes of the XML structure. It is necessary to set the following fields to do
this:
General area, field “Start XMLNode ”
Tab Mapping , field “XML collection ”
Comos combines these two details to set up the XPaths and searches for all
matching XML attributes.
In order to test the effect, we once again recommend to export an XML Con-
nector and to open the XML file created as a result in the right part of the win-
dow. The mapping then matches automatically.
There are two Navigation commands available in the mouse menu. Use these
commands to jump from this tab to the corresponding nodes in the XML file
at the right:
| NAVIGATE | XML NODE
Jumps to the attribute in the XML file.
| NAVIGATE | XML “ROW”
Jumps to the owner of the XML attributes.
Tab “Mapping”
This tab has already been described above in connection with the queries, see
SECTION 38.4.4.3: OPTIONS OF A COLUMN, MOTIONX. The following lists the differ-
ences.
Field “XML collection ”
A node from the XML file (at the right) can be dragged into this field. An
XPath that fills the XML tab is set up together with the details from the “Start
XML Node ” field.
Field “Comos collection ”
This field contains the appropriate query.
Column “Comos info ”

The information displayed in this column is created automatically and cannot

be changed. It specifies which data will be created by this column of the object
query. (Each row on this tab represents a column of the query.) The input need
not be precise, for example when working with a script.
Tab “Script”
A script editor. A number of ready-made examples have been provided for
MotionX.
XML viewer (right)

In the right part of the XML Connector window, the XML file is displayed
once the “XML file name ” field has been set. There are no mouse menus. The
only way to work with the information displayed here is to use Drag&Drop:
General area, field “Start XMLNode ”.
Initially, the owner of <Content/> node defined in the XML envelope is
entered here. See also Attribute “XMLEnvelope”, P. 38-11. To put it more simply:
the topmost node of the XML file is shown here initially.
Tab Mapping , field “XML collection ”,
Any desired node from the XML file can be dragged into this field.
Edit query container

The following dialog can be called from various locations, e.g. via the Map-
ping tab of the XML Connector, Comos collection field: [...] button:
You can create a new query by means of this dialog. Please note that the query
is created underneath the XML template. If the XML template is located in a
different project than that of the currently edited XML Connector document,
then you also need the appropriate rights for the other project.

38.4.6.3 Application
Starting state
When you use the | CONFIGURE XML CONNECTOR command of an XML Con-
nector document for the first time, then at least the “Start Comos object ”
field is set. In addition, there is at least one query available, otherwise the
| CONFIGURE XML CONNECTOR mouse command would not be available at all.
Everything else depends on the method of operation.
It is possible to open an XML file and then to reconstruct the structure of the
XML file by creating queries.
Vice versa, you can first of all set up a structure of queries in Comos and then
export an XML file.
The ‘key columns

When mapping the Comos data and the XML file you must take into consid-
eration that the order of the data can change and must be able to do so. The
“position” of an item of information at a level thus cannot be used as the basis
for the mapping.
How can one find out which row in Comos corresponds to which “row” of the
XML document if the sequence can be any that you want?
You have to define key fields to do this. The keys then function as an index
that is used when searching. There can be multiple key fields.
38.4.7 Script for the XML Connector
By default, the queries that are located directly underneath the XML template
get their Comos start object from the XML Connector document. In addition,
the queries pass their row objects in the form of start Comos objects on to the
queries located underneath them.
There is also the option to change these defaults by means of a script.
The topmost queries that are directly underneath the XML template can call
the following two functions:
• “Master_Export”
• “Master_Import”.
If the master methods exist, then they are called. If they do not exist yet, the
default runs.
The following functions are available for all further levels:

<QueryName>_ImportRow
<QueryName>_ExportRow
For that reason you must assign unique names to the queries.
This applies for each row of the current query. If the script method exists, it
will be called for each row. If not, then the default applies: The row object of
the current query is assigned to all queries located underneath the current
query.
Scope: the complete scripting functionality of Comos is available. But it
would be relatively tedious to implement the actual import/export operation
by means of a script. As a rule, scripts are for example used to change the
order of the queries or the OrigCollection.
The CurrentJob
While the query is executed, the so-called CurrentJob is running. You can
retrieve the following information from this object:
• current query,
• OrigCollection of Comos objects,
• XMLNodes at the XML document.
(see below for a description)
New jobs
You can create and start new jobs within the script.
Type of the job object: 'ComosQueryInterface.IXMLConnectorJob'
Properties:
Job.QueryContainer = <query container>
Job.TopQuery = <ITopQuery>
Job.RootComosObject = <query StartObject>
Job.ComosObjects = <query OrigCollection>
Job.RootXMLNode = <RootNode for 'XML-Rows'>
Job.XMLNodes = <'XML-Rows'>
Job.RootXMLNodeCompare = <RootNode for 'XML-Rows' of compare
version>
Job.XMLNodesCompare = <'XML-Rows' of compare version>
There are two methods to do this:

Job.Import
Job.Export

QueryContainer: in the interface, the QueryContainer corresponds to the

objects that, among others, can be edited in the “Edit query container ” and
“New query container ” dialogs. It is a Device or CDevice that has the actual
query. Apart from the fact that the XObjects are stored in these objects, they
are only of relatively minor importance.
TopQuery: this is the actual query (the calculation core, not the browser).
RootComosObject: in the interface this corresponds to the “Start Comos
object ” field, but in the script the RootComosObject will presumeably
change constantly.
ComosObjects: this is the Comos collection that has been determined and
supplied by TopQuery.
RootXMLNode: in the interface this corresponds to the “Start XML Node ”
field, but in the script the RootXMLNode will presumeably change constantly.
XMLNodes: in the interface this apporximately corresponds to the results on the
“XML ” tab.
RootXMLNodeCompare, XMLNodesCompare: this is only for imports (there
must be at least one XML version). The parameters supply the XML node of
the previous version. This is important if you wish to edit only the differences
with respect to the previous version.
Job.Import, Job.Export: this starts the execution of the job.
The properties are redundant. Some examples:
• If you input QueryContainer, you need not necessarily input the TopQuery
if it comes from this container. In that case the TopQuery will be determined
by QueryContainer automatically.
• If you input RootComosObject, and the default of the query is to search for
the objects, then you do not need to input ComosObjects once again.
• If you wish to redefine the OrigCollection, you do not need to write
IExtender for the query but can input the appropriate objects simply as
ComosObjects property.
Example 1
For example, this is what the revised default case would look like in a script:
Sub Q1_ExportRow(ComosObj, XMLNode)
Set QSubs = CurrentJob.QueryContainer.EnObs("J")
For i = 1 To QSubs.Count
Set NJ = CreateNewJob()
NJ.QueryContainer = QSubs.Item(i)
NJ.RootComosObject = ComosObj

NJ.RootXMLNode = XMLNode
NJ.Export
Next
End Sub
Sub Q2_ImportRow(ComosObj, XMLNode, XmlNodeCompare)

Set QSubs = CurrentJob.QueryContainer.EnObs("J")
For i = 1 To QSubs.Count
Set NJ = CreateNewJob()
NJ.QueryContainer = QSubs.Item(i)
NJ.RootComosObject = ComosObj
NJ.RootXMLNode = XMLNode
NJ.RootXMLNodeCompare = XmlNodeCompare
NJ.Import
Next
End Sub
Script templates
The script templates can be called from the toolbar:
Starting an export/import operation by means of a script

The examples given up to now presupposed that the script had been written in
the “Configure XML Connector ” dialog and had then be started at the XML
Connector Document by means of | XML | EXPORT or | XML | IMPORT.
However, you can also start the export/import operation by means of a script.
Example 1 (normal notation)

Set XMLImpExport =
CreateObject("ComosXMLInterface.XMLInterface")
Set Options = XMLImpExport.CreateJobOptions("Import")
' Import:
Options.Item("VersionsAdministration").Value = False
Options.Item("DeleteObjects").Value = False
Options.Item("CreateWorkingOverlay").Value = True
Options.Item("DifferenceOnly").Value = False
XMLImpExport.Import <Document>, <FileName>, Options

MotionX Server XML / MotionX
' Export:
Set Options = XMLImpExport.CreateJobOptions("Export")
Options.Item("VersionsAdministration").Value = False
Options.Item("ShowFile").Value = True
XMLImpExport.Export <Document>, <FileName>, Options
Example 2 (abbreviated notation)

Set XMLImpExport =
CreateObject("ComosXMLInterface.XMLInterface")
' Import:
XMLImpExport.Import <Document>, <FileName>, False, False,
True, False
'Export:
XMLImpExport.Export <Document>, <FileName>, False, True
We recommend that you use only the first version. Because the meaning of
the parameters is implicitly clear in the first version, while in the second ver-
sion you wold have to document the script in order to describe the meaning of
the script and the parameters.
38.5 MotionX Server
38.5.1 Objective
The MotionX Server is a service developed by innotec, which can control the
Comos XML Connectors outside Comos. To do this, the service starts a
Comos instance, executes all actions necessary in Comos and imports or
exports the required data.
38.5.2 Installation
38.5.2.1 Comos 8.1

1. Comos installation
Install Comos AddOn “U”.
2. Install FrameWork 2.0 (dotnetfx.exe). FrameWork is entered in the
software list:
START |SETTINGS |CONTROL PANEL |SOFTWARE:
“Microsoft .NET FrameWork 2.0 ”

XML / MotionX MotionX Server
If FrameWork is not entered in the software list, then the software has not
been installed properly and MotionX Server will not work.
3. If needed: Install WindowsInstaller. The installation (not the operation)
of the MotionX Server requires WindowsInstaller. The necessary file,
WindowsInstaller30.exe (or similar) is available on the Microsoft
homepage or from the innotec Customer Service.
4. Install MotionX Server
Start InstallService.bat. This file contains only one command:
installutil ComosMotionXServerManager.exe
The command installs the “ComosMotionXServerManager ” service.

This service must have a user account in Comos. There are two
possibilites for this:
– Right-click with your mouse, properties of the service, Login tab: Local
system account. In that case the user logs into Comos as SYSTEM.
– Right-click with your mouse, properties of the service, Login tab: This
account. A username and password can be entered.
Please note: If a specific account is to be used, please make sure that this
account is available in Comos and with the required rights (read and
write)
5. Edit MotionX Server configuration file
See SECTION 38.5.4.1: MOTIONX SERVER CONFIGURATION FILE.
6. Start MotionX Server
The MotionX Server is entered as service:
START |SETTINGS |CONTROL PANEL |ADMINISTRATIVE TOOLS |SERVICES:
“ComosMotionXServerManager ”
Right mouse button: “Start ”
7. If necessary: Stop MotionX Server
START |SETTINGS |CONTROL PANEL |ADMINISTRATIVE TOOLS |SERVICES:
“ComosMotionXServerManager ”
Right mouse button: “Exit ”
38.5.2.2 Comos 8.2

1. Comos installation
All required Comos components must already be installed.

2. Proceed as described in the installation manual for Comos 8.1.
38.5.3 Uninstallation
The file is stored in the bin folder of MotionX Server:

UninstallService.bat.
This file contains a single command:

installutil /uninstall ComosMotionXServerManager.exe
38.5.4.1 MotionX Server configuration file

The configuration file must be customized before the
“ComosMotionXServerManager ” Windows service is started.
<Resources> </Resources>
For later applications.
<InterfaceEXE> </InterfaceEXE>
The location of MXExec.exe is specified here.
<LogDB> </LogDB>
Specifies the location of the database, where the actions of the service will be
entered. See Log.mdb, P. 38-35.
<SharedFolder> </SharedFolder>
The command files will be searched in this folder.
<DriveMappings>
The Windows service ComosMotionXServerManager cannot process
mapped drives of the Explorer. In short: If the Explorer displays a drive
“Test for “CS01” (P) , then the service does not know this path, and neither
can data be retrieved or saved there.
You must explicitly specify the drives for the service:
LocalName = Letter of the mapped drive in Explorer
RemoteName = Network path of the mapped drive.
Example: In some configurations the Comos document folder is specified as

a mapped drive. In that case the mapping must be made known to the service
explicitly.

38.5.4.2 Edit command file

Version
Version number of the command set.
CommandID
ID of the command file / of the command. Optional.
ActionID
ID of the action. Optional.
ConnectionString, Project, WorkingOverlay
These attributes of Connection automatically start an instance of Comos and
generate a workset. In short: The MotionX Server requires a local, executable
Comos installation, including the necessary licenses. The Comos.exe is not
started.
The MotionX Server is registered in the default as described above: with
SYSTEM for the setting “Local system account“, in the other cases as speci-
fied in the field This account . This user account must have the necessary
rights. If the MotionX Server is to be accessed through another user account,
appropriate rights must be set up there, too. The user account can be specified
in the properties of the Windows service.
Therefore, the Connection requires only the position of the database, the
project and the working overlay.
Function Class
Starts a component of Comos. At present, the MotionX Server can only start
the XMLInterface. At present, this interface has two interfaces that are
addressed as follows:
Name = Import or
Name = Export
General parameters
Name="XMLFile"
At present, only XML files can be processed. The XML file to process will be
searched relative to the MXExec.exe.
Name="XMLConnector"
Searches and starts the Comos XML Connector. The XML Connector must
be located on the Documents tab below “@System |@MXC” (or in the beta
version below “@MXC”)
Name="RootNode" Value="08UZX" ParamType="PathFullName"
The RootNode of the XML Connector is the ReportObject, i.e. normally the
owner. You can specify the following as ParamType:

SystemFullName: The SystemFullName is not automatically unique. If you

want to use the SystemFullName, the Administrator must make sure that it is
unique. Other details on the SystemFullName are given in the Comos Ker-
nel documentation.
PathFullName: The PathFullName is always unique, but complicated. It will
always be determined relative to an object, at best relative to the project. It is
recommended to determine the PathFullName using the object debugger:
Take the object from the “Object A ” field of the object debugger and enter
the following command in the Term field:
A.PathFullName(a.project)
Example: If there is a “W1” unit directly below the project, then as Path-
FullName you get “08UW1”. 08 = SystemType Device; U = Class Unit, W1
= Name.
Export-specific parameters
The following options are the counterpart to the options in the “Export ” dia-
log window. The effect of these options is described in SECTION 38.4.5.2: EXPORT.
Name="ShowFile"
If the export is started from Comos, then immediately after the export, the
XML file is displayed in Internet Explorer. This setting is not good for a
Server operation and can thus be disabled here.
Name="VersionsAdministration"
Counterpart to “Include in version administration ”.
Import-specific parameters
The following options are the counterpart to the options in the “Import ” dia-
log window. The effect of these options is described in SECTION 38.4.5.3: IMPORT.
Name="DeleteObjects"
Counterpart to “Delete objects ”.
Name="CreateWorkingOverlay"
Counterpart to “Working overlay ”.
Name="VersionsAdministration"
Counterpart to “Include in version administration ”.
Name="DifferenceOnly"
Counterpart to “Manage only difference objects ”.

Name="SaveMode"
0: The import continues to be processed even if an object cannot be saved.
1: As soon as an object cannot be saved, the import is cancelled and all
imported operations executed so far are undone.
The key factor for this is the ability to save the object. If, for example, Comos
is able to correct an error, then an entry is added to the Hint list. However, this
has no effect on the SaveMode.
For future developments

Name="Filter"
In future versions, it will be possible to filter XML files. At present, still with-
out function, therefore uncommented.
38.5.4.3 Sequence
In Comos, executable XML Connectors must be prepared. These XML Con-
nectors will be searched at the following location:
Target project (for example, a planning project), Documents tab:
@System |@MXC or direct @MXC under the project.
1. Start ComosMotionXServerManager service. Every change at the

Windows service results in an entry in the Log.mdb.
2. The ComosMotionXServerManager service monitors the
SharedFolder. If a mxc file is found there, it is imported to the
MXExec.exe. From a technical point of view, the following steps will be
executed:
2.1 ComosMotionXServerManager evaluates
ComosMotionXServerManager.config.
2.2 In the SharedFolder, the administration file MotionX.sync is

created.
2.3 If a mxc file is found in the SharedFolder, the SharedFolder is
locked using the MotionX.sync. For this, see SECTION 38.5.6:
APPENDIX 1: SYNCHRONIZATION OF THE SHAREDFOLDER.
2.4 The mxc file is checked and. if valid, the parameters are written to a
temporary file.
2.5 The mxc file is deleted and the SharedFolder is released again.
2.6 The MXExec.exe is called with the parameters of the temporary file.

3. The MXExec.exe executes the commands. For this, a Comos instance is

generated and the XML Connector is called.
4. Finally, MXExec.exe generates a mxr file in the SharedFolder.
38.5.4.4 Process figure
Idle
Max. MXExec Yes

processes
runing reached?
No
No mxc file in
shared folder? Realease
MXExec process
Yes
Lock
shared-folder
Command No Unlock Generate Generate

valid? shared-folder error mxr file mxr file
Yes
Generates temp
parameters/delete mxc file
Book a
MXExec process
Unlock
shared-folder
Call MXExec
with parameters
Is MXExec No
runing?
Yes
No Is temporary Yes
response there?

38.5.4.5 Response messages in Comos

Windows Services cannot process response messages. This also applies to the
“ComosMotionXServerManager ” service. Therefore, make sure that the
processing of XML Connectors in Comos does not necessitate user interac-
tion.
For example, if a message box appears in Comos, the user must confirm the
message box with [OK]. The service cannot be processed further until the user
confirms the message.
The MotionX Server must work outside Comos, so that there is no user who
would click away a dialog.
It is very important to check the executability of XML Connectors in Comos
in order to ensure that there is no user interaction under any circumstances
(message box, response or error message or similar).
38.5.4.6 Log files
Log.mdb
Station : The work station from where the command is made.
User : The user logged into Windows (not Comos!).
CommandID : ID of the command, as long as this ID is entered in the XML
file.
ActionID : ID of the action as long as this ID is entered in the XML file.
Status : Status of the action, at present: 0 = Successful; 1 = Failed.
MXCFileName : Network path where the command file is located.
mxr files
An entry is made for each executed action.
Status = 0: Action successful
Status = 1: Failed
38.5.5 Example files
38.5.5.1 ComosMotionXServerManager.config
<?xml version="1.0" encoding="utf-8" ?>
<Config>

<MotionXServer>
<Resources> C:\ComosMotionX-Server\Resources </Resources>

<InterfaceEXE> C:\ComosMotionX-Server\bin\MXExec.exe
</InterfaceEXE>
<LogDB>Q:\VSSUSERS\Irina\PT90\BIN\MXExec\Data\Log\
Log.mdb</LogDB>
<SharedFolder>M:\ComosMotionX-Server\
InOutBox</SharedFolder>
<DriveMappings>
<DriveMapping LocalName="M:" RemoteName="//cs01/Public" />
<DriveMapping LocalName="N:" RemoteName="//CW50-01/DB" />
</DriveMappings>
</MotionXServer>
</Config>
38.5.5.2 Command files
Export configuration
For example “MXExecExport.mxc”.
<MXExec Version="1" CommandID="mxcE" >
<Action ActionID="actE" >
<Connection ConnectionString="D:\ComosApp\DB\RelDBV7_1\
comos.mdb" Project="COMOS_ET" WorkingOverlay="S1" />
<Function Class="ComosXMLInterface.XMLInterface"
Name="Export">
<Parameters>
<Parameter Name="XMLFile" Value="\Data\Export.xml" />
<Parameter Name="XMLConnector" Value="XTest" />
<Parameter Name="RootNode" Value="08UZX"
ParamType="PathFullName" />

<Parameter Name="ShowFile" Value="False" />
<Parameter Name="VersionsAdministration" Value="False" />

</Parameters>
</Function>
</Action>
</MXExec>

Import configuration
<MXExec Version="1" CommandID="mxcI" >
<Action ActionID="actI" >
<Connection ConnectionString="D:\ComosApp\DB\RelDBV7_1\
comos.mdb" Project="COMOS_ET" WorkingOverlay="S1" />
<Function Class="ComosXMLInterface.XMLInterface"
Name="Import">
<Parameters>
<Parameter Name="XMLFile" Value="Data\Import.xml" />
<Parameter Name="XMLConnector" Value="XTest" />
<Parameter Name="RootNode" Value="ZX"
ParamType="SystemFullName" />

<Parameter Name="DeleteObjects" Value="False" />
<Parameter Name="CreateWorkingOverlay" Value="True" />
<Parameter Name="VersionsAdministration" Value="False" />
<Parameter Name="DifferenceOnly" Value="False" />
<Parameter Name="SaveMode" Value="0" />

</Parameters>
</Function>
</Action>
</MXExec>
38.5.6 Appendix 1: Synchronization of the SharedFolder
The following information is not relevant for the normal mode of the Comos-
MotionXServerManager . The information is only relevant for technical
inspections or customizing. All other administrators can skip this chapter.
Access to new commands (*.MXC) in the common SharedFolder must take
place only through one Server. Otherwise, several Servers could be process-
ing the same command.
To prevent this, there is a “MontionX.sync” file. If a server wants to access
the SharedFolder to search for commands (*.mxc files), it first locks
MotionX.sync and signs with its machine name. This means: one can con-
tinue to store mxc files in the SharedFolder. But these files cannot be evalu-
ated during that period. Only the current mxc file can be evaluated.

Thus, both cases are covered:

• Several Windows services ComosMotionXServerManager can access a
shared SharedFolder via the network. .
• The MXExec.exe process can be started several times on one PC, depending
on the configuration. In that case, a second MXExec.exe process can already
process the next mxc file even before the first MXExec.exe process has
written its mxr response file.
In that case, the sequence is as follows:
– MXExec.exe Process 1 finds mxc file
– locks MontionX.sync
– processes the mxc file
– in the meantime, another mxc file appears
– MXExec.exe Process 1 deletes “its“ mxc file and releases
MontionX.sync; but processing not completed yet, thus no mxr file
– MXExec.exe Process 2 processes the next mxc file and, in turn, locks
MontionX.sync. Process 1 and Process 2 work in parallel.
38.5.7 Appendix 2: Participating files
config Control file of

ComosMotionXServerManager.exe in XML
format.
mxc Command files for the Server. There is one
command file for importing and one for exporting
respectively
<mxc-file>.tmp Status file of command file. The progress in the
processing of the command is logged in this file.
ComosMotionXServ Runs as a “Service” under Windows and controls
erManager.exe the import and export operation. Monitors the
input/output folder for MotionX command files,
reads the commands and transfers the parameters
to the MXExec.exe.

MXExec.exe Executes the current import or export of XML

files by considering the
ComosMotionXServerManager.exe parameters.
Writes a mxr log file.
Log.mdb Log file of the
“ComosMotionXServerManager ” Service.
Here, it is entered who started or ended the service
or an action of the service, with what details and
when.
mxr Response file (log file ) of the MotionX Server.


Other interfaces Comos-Comos (import, export)
39 Other interfaces
39.1 Comos-Comos (import, export)

Comos has an option for version management for distributed data storage.
Thus there can be physically separated databases whose stocks of data can be
synchronized semi-automatically. After the synchronization, the project data
from two databases is combined in a common project.
This method is not to be confused with the importing or exporting of projects:
that case projects that are not synchronized are created in parallel.
You have the option to combine the data in one of the synchronized databases
or alternatively to match the databases. In the first case the source database
remains unchanged, while in the second case the updating is done in both
directions. For both options you should use the program ImportDB.exe, which
is located in the \bin directory.
See SECTION 3.3.5: RECONCILE THE DATA AGAIN OR SUMMARIZE IT.
Inconsistencies in the planning can lead to collisions in a synchronization
operation: The same objects were modified in both of the databases to be syn-
chronized. Since Comos has no way of knowing which modification is cor-
rect, these objects cannot be synchronized.
These collisions are documented in the test list of the Object Tester. It is not
possible to save definitively as long as there are any collisions. Please note
that you should not simply cancel or undo an action, especially for actions that
take a lot of time, since the entire work step will be undone and a lot of work-
ing time is lost. It is better to correct the inconsistent objects and then to save.
39.2 Comos-Comos (import planning projects)

This command can only be used on planning projects. Projects can be
imported from another database.
See SECTION 5.3.2: IMPORT PROJECT.
Please note that differing hierarchical structures in the standard tables in dif-
ferent databases can lead to inconsistencies when projects are imported.
When a planning project is imported, this project is linked with the applicable
base project. However, the applicable base project can be distinguished from
the base project which the project to be imported was formerly linked.

Comos-Comos (import system project) Other interfaces
The inconsistencies that arise as a result appear in the test list of the Object
Tester.
39.3 Comos-Comos (import system project)

Vital base objects that Comos cannot meaningfully work without are prepared
within the system project.
In the event of a database change, please use the tool “SYCHANGE.EXE“ in
the sub-directory \Bin to transfer the system project to the other database.You
should make a backup of the project database before carrying out this import
operation.
See SECTION 3.5: COPY SYSTEM PROJECT for further information.
39.4 Translations (import, export)

See SECTION 42.4.4: TRANSLATION OF COMOSDB.
39.5 WMF data (import)

The following icon becomes available when an Interactive Report is opened
within the Report Designer:
Place Windows Metafile
The import function for Windows Metafiles is especially useful as a means of

importing AutoCAD files. To do this, the AutoCAD file must have been
exported beforehand as a WMF file within AutoCAD.
A mapping file (shown by the file extension.pcp) can be selected from the
AutoCAD tab from which AutoCAD line thicknesses, etc., are stored.
See SECTION 46.3.4: PLACE WINDOWS METAFILE.
39.6 Report templates (import)

When an Interactive Report is opened in the Report Designer, the following
command becomes available:
| FILE | IMPORT

Other interfaces Report templates (import)
The command inserts the contents of an existing template file into the current
template file. A template file can be selected from within the Open dialog
field.
All inputs made up to that point are lost without prompting. The IMPORT func-
tion has the same effect as if you had opened the file to be imported and over-
written another file with the SAVE AS option: All existing scripts, texts and
graphics, etc., are lost and the scripts, texts and graphics of the imported file
take effect. That also includes any references to Master Reports and sub-
reports.

Report templates (import) Other interfaces

Document Management (DQM) Overview
40 Document Management (DQM)
40.1 Overview
Comos DQM now comprises the following areas:
• Create and classify document groups
SECTION 40.3: CREATING AND STRUCTURING DOCUMENT GROUPS
• Revisioning documents and document groups

SECTION 40.4: REVISIONING DOCUMENT GROUPS
• Automatic page number

SECTION 40.5: AUTOMATIC PAGE NUMBER
• Automatic reference creation

SECTION 40.6: AUTOMATIC REFERENCE CREATION
• @Reports auto-recognition
SECTION 40.7: @REPORTS DOCUMENT GROUP
• DragDrop import
SECTION 40.8: DRAG&DROP - IMPORT @DOCUMENTTYPEMAPPING
• Full-text search
SECTION 40.2: PREPARING THE BASE DATA OF DOCUMENT GROUPS
40.2 Preparing the base data of document groups

Like all other planning objects, document groups have a base object. The stan-
dard database contains the base object
<Project root> - @G Document groups
Class: Document group
Name : G
Name not compulsory.
Label : Document group
Any label allowed.
However, as a rule, this central base object is not used for document groups.
Instead, use the module-specific base objects. For electrical engineering, that
would be, e.g.:
ET | G Document groups and the objects beneath it.

Creating and structuring document groups Document Management (DQM)
Reason: The module-specific base objects are all collected in one branch to
simplify copying, backups, etc.
40.3 Creating and structuring document groups
40.3.1 Creating document group systems manually
Top level
At the project level (directly below the globe), document groups are available
only in the mouse menu of the Documents tab.
All remaining tools with which you can create planning objects (drag base
objects to a tab; copy&paste etc.) are also restricted so that, at the project
level, document groups can only be created on the Documents tab.
There can be special cases that could lead to a document group appearing at
the project level of another tab (Import etc.).
In such cases, the data operation is performed first, and then the document
group is moved to the Documents tab.
Other levels
At lower levels, document groups can be created on all tabs.
Document groups can contain document groups. Many functions of the doc-
ument management are recursive. This means that the function not only con-
siders a specific document group, but also all document groups that are
created directly under it (and then again directly under that one etc.).
40.3.2 Automatic unit or location hierarchy
Overview / Objective
Automatic matching of the structure on the Documents tab and of the struc-
tures on the Units and Locations tabs. Basic idea: The document groups are
created as elements at the units and locations. If the corresponding unit and
location is created, the document group is created, too, and is then collected
on the Documents tab.
Prerequisite / Options
Project properties, Options tab:

Document Management (DQM) Revisioning document groups
“Automatic referencing of documents ” group

Here, the “Unit/location hierarchy ” entry must be selected. This is done sep-
arately for the the @Project and @NameSystem node.
Application
The document groups are created on the Elements tab of the unit and location
objects.
If this technology is enabled, then the Documents tab only serves as pure
presentation. The document groups and documents are available in the origi-
nal under the units and Places tabs.
Please note: If this technology is activated, then there must be no originals of
documents or document groups on the Documents tab!
Please note: Scripts and accesses must be adjusted accordingly, because as a
rule, they access the Documents tab!
40.4 Revisioning document groups

The Document group is revisioned and the documents underneath it are
automatically considered as well.
Single revision (revision of an individual document) and group revision (revi-
sion of an object with the type document group, including all documents
underneath it) differ in the following points:
• Checking the relevant timestamp
• Generating the revision index
Otherwise, see SECTION 41: REVISIONS.
40.5 Automatic page number

Defining the “Starting page” and the virtual page number
In Comos, there is another method for managing page numbers: the “virtual
page number”. For this, see SECTION 40.6.4: GENERATING VIRTUAL PAGE NUMBERS.
The virtual page number and the automatic page number from the document
properties described in this chapter are not synchronized. Thus, there can be
differences in both page details.
Overview of the automatic page number

Properties of a document, General tab:

Automatic page number Document Management (DQM)
• Starting page
The computed page number for the first page of the document is given here.
The document takes overt the Starting page value from the reference, if the
reference is located in a document group of @NameSystem. References in
other document group branches are ignored.
In @NameSystem, a reference may exist only once. Even manually, you
cannot create another reference to the original in that node. Thus, if a
Starting page is computed here, it is unique.
In all remaining cases, there can be more than one references to an original.
If there are more than one references to the same original, but if neither of
these references exists in @NameSystem, then the value in Starting page
contains no meaningful information. In such cases, it is not clear which
reference passes its Starting page to the original.
• Number of pages
Contains the number of pages of the evaluated document. This field is
always read from the original.
Please note: The number of pages is displayed correctly only in documents
where the application itself manages page breaks. Other documents are
always managed with the number of pages “1”. Example: The number of
pages of a Word document are displayed correctly, the number of pages of
a Notepad text document are always displayed with “1”.
Compute starting page

The “Starting page ” field is not entered manually, but is computed by
Comos. For this, the following factors play a role:
• Document groups not involved
The documents are not located in a document group and do not have
references to a document group, either.
Result: All parallel documents (i.e. all documents with the same owner) are
sorted by the Comos sorting option (sorting by SystemFullName), and then
are numbered, taking into account the number of pages.
Hence, the page numbering through the Starting page field also works
without document group.
• Document groups from the @NameSystem branch involved
Properties of the document group, SYS tab, Starting page field.
This field is evaluated simultaneously by the automatic page number in
“Starting page ” and the virtual page number.
– Documents that are located in a @NameSystem document group or have
a reference in that group
Result: The Starting page field is fully controlled by the document

Document Management (DQM) Automatic reference creation
group:
Comos determines the number of other documents in the document group
and their page number (references and originals are handled in the same
way) as well as the value in the Starting page field.
Subsequent changes in the Starting page field of the document group are
considered automatically and immediately.
– The document itself is not in a @NameSystem document group and has
no reference there, either. But parallel to the document there are
documents to which this applies.
Result: The documents that have a relation to a document group are
controlled from the document group. The other documents are numbered
separately, also considering the the number of pages (not the Starting
page field) of the documents that have a relation to a document group.
The documents are sorted, and always using the Comos sorting. For example,
if “Sort alphabetically” is enabled in the Navigator, then the page numbers in
the Navigator seem to be in the wrong sequence.
Please note: If a document is evaluated, this can change the number of pages
of the document. This mainly applies for evaluation reports: At the time of
evaluation, it is re-evaluated what the report must present, and thus also, how
many pages the report “needs”. Until the next evaluation of the report, the
number of pages remains the same, as an evaluation report is not constantly
updated.
Issue page numbers

The evaluation is done through the Comos functions PageNr (=Starting page),
MaxPageNr (=Page numbers) and GlobalPageNr. For this, also see
SECTION 46.3.1.5: TYPE “EXPRESSION”.
40.6 Automatic reference creation
40.6.1 Overview
Definition of a “document reference”

References serve as alternative access options to an original document. Under
Windows, you would speak of a “link”. If a reference is opened, then in real-
ity, you open the original. In Comos, a reference itself is an object (in other
words: a document of document type Reference document) and as such
requires a unique name and possibly a label.

Automatic reference creation Document Management (DQM)
Manual references (“Links”)

Exactly as in Windows, the user too can create links wherever he needs them.
To do this, he copies a document, in the Navigator clicks on an object and
from the mouse context menu selects the command | PASTE LINK. Reference
documents (i.e. the links to a document) must have a different name from the
original.
In the @NameSystem branch, references may not be created manually.
Automatic references
In Comos, it is possible that document references are automatically created in
document groups on the Documents tab. Thus, the user can create a docu-
ment anywhere in the planning data and then find it through the automatically
generated reference in the document groups.
If a document is automatically referenced in a document group, this informa-
tion is also displayed in the Navigator at the original document: “>>” and the
name of the document group and the reference document are appended to the
name and description of the original. Example:
<Owner> + PFSS.3 Circuit diagram>> .PFSS.004
The automatic referencing comprises the following steps:
1. Determine whether a document must be referenced in a document group.
See SECTION 40.6.2: BASIC TECHNOLOGY (DETERMINE REFERENCE DOCUMENTS).
2. Create a name for the reference (i.e. the reference object).
See SECTION 40.6.3: GENERATING NAMES OF REFERENCE DOCUMENTS.
3. Optional: Create a label for the reference.
See SECTION 40.6.4: GENERATING VIRTUAL PAGE NUMBERS.
40.6.2 Basic technology (determine reference documents)
40.6.2.1 Project option

In the project parameters, the Automatic referencing of documents option
must be enabled, see SECTION 5.5.3: THE OPTIONS TAB.

40.6.2.2 Syntax conventions (String comparison of prefix)

Comos requires information on the document group in which the automatic
reference is to be created. Comos acquires this information by comparing the
document name and the name of the document groups in the @NameSystem
branch.
Example 1:
There is a document group TestDG . If a new document is created with the
name TestDG.1 in the unit view, it is automatically referenced in the
TestDG document group.
For this, only the name of the document is relevant, not how the name was
generated. Thus, the user can work with text masks on base data side, e.g.
with the mask “TESTDG?”.
Decisive factor: The name of the document group must be identical to the pre-
fix of the document name. However, additional characters can be appended at
the end of the document name.
Example 2:
Name of document group: WSP
Document name: WSPTest
Effect: Automatic reference is formed.

Name of document group: WSP
Document name: TestWSP
Effect: The document is not referenced.
40.6.2.3 Substring comparison

SYS |System data tab, Reference settings option group:
Substring comparison document - group
Allows only a part of the document group name to appear in the document
name.
Example 3:
Name of document group: WSPTest
Document name: WSP.1
Effect: Automatic reference is formed.

Name of document group: WSPTest
Document name: Test.1
Effect: The document is not referenced.
Please note: If the Substring comparison is enabled, then some document

groups are possibly no longer unique. In this case, the document is referenced
in the first document group that matches.
Equivocations can be resolved by setting a unit or location pointer at the doc-
ument groups, see SECTION 40.6.6: OPTIONAL: SET ADDITIONAL POINTER.
40.6.3 Generating names of reference documents
The reference generated automatically is itself an object and as such requires

a unique name. The rule required for this is defined as follows:
Document groups, SYS |System data tab, Reference settings option group
Full name (Default)
FullName. Separators for FullName are defined in the project options. Full-
Name generates a string that lists all names of the branch up to the object.
Objects with the “Folder ” property are ignored. The exact definition of Full-
Name is given in the “Comos Kernel” documentation.
Full label (with folder)

FullLabel. Separators for FullLabel are defined in the project options.
FullLabel generates a string that lists all labels of the branch up to the object.
Objects with the “Folder ” property are ignored. The exact definition of
FullLabel is given in the “Comos Kernel” documentation.
Full name (System)
SystemFullName. SystemFullName generates a string that lists all names of
the branch up to the object (including objects with the Folder property).
Please note: The separators within SystemFullName originate from Comos
and consist of Pipe charachters (“|”).
Shorten name
Document groups, SYS |System data tab, Reference settings option
group, Shorten reference name field.
If the option is enabled, then the generated name of the reference document is
shortened by all components that are identical in the unit / location view and
in the document group view.

Please note: If the “Shorten reference name ” specification is not available,

then the technology of shortening the name is controlled by the Numbering
mode field!
In this case:
Numbering mode : value set to “Dynamic ” or “Consecutive ”
= name shortened
40.6.4 Generating virtual page numbers
Defining the virtual page numbers and the “Starting page” field
There is another method in Comos to manage page numbers: The “Starting
page ” page in the document properties window. For this, see SECTION 40.5:
AUTOMATIC PAGE NUMBER.
The automatic page numbers from the document properties and the virtual
page number introduced in this chapter are not synchronized. Hence, there can
always be differences in the two page details.
Overview of the virtual page number

Basic function: The page number is managed via the document label and the
reference document label. It is essentially controlled through a document
group. Without a document group, no virtual page numbers can be generated.
Starting page
This field is evaluated simultaneously from the automatic page numbers in
“Starting page ” and the virtual page numbers.
• Off
(@DynNum specification is not available or has the value -999 = Off)
Name: Document.FullName
Label: empty
Effect: No virtual page number is generated.
• Mask (@R)
(@DynNum specification is set to 2 = Mask)
Name: Document.FullName
Label: yes,
if a text mask for the label has been set at the base object that was entered
in the “Node for mask ” field. The result is written into the label of the
generated references. The originals within the document group remain
untouched.

Node for mask

Only evaluated in the Mask mode.
• Dynamic
(@DynNum specification is set to 1 = Dynamic)
Name: Document.FullName,
but shortened by identical unit /location pointers for document and group.
This also applies for group names. That is, identical to the setting
@DynNum 0 = continous.
Label: On the surface yes,
from a technical point of view, the label remains blank, but a text appears
in the Navigator. For this, the label must be blank initially, otherwise this
will not work.
Effect: The virtual page number is not entered in the label, but is transferred
directly to the Navigator text. Thus, the number of pages can be seen in the
Navigator, but not in the properties window.
The documents are sorted by Comos sorting and then are numbered on basis
of Starting page . New documents are sorted in immediately. Thus, the
numbering of all documents changes dynamically, along with the document
stock of the group.
• Continous
(@DynNum specification is set to 0 = continous)
Name: Document.FullName,
but shortened by identical unit /location pointers for document and group.
This also applies for group names. That is, identical to the setting
@DynNum 1 = Dynamic.
Label: yes,
consecutive numerical in OwnLabel. New references are appended.
Effect: The objects (documents and references) in the document group are
consecutively numbered in the sequence in which they were created. If a
number was already issued, then the next free number is accepted. Initially,
documents are sorted and are numbered consecutively. Thus, the numbering
visible in the Navigator can “skip”.
The page value is fixed in the document Label (OwnLabel). Thus, the label
must be blank for all documents. In Comos, the label over-defines the name
in the Navigator display.
Changes made later in the Starting page field of the document group are
not considered.

Change the “Numbering mode” field

Please note: The “| CREATE REFERENCES” command generates only new refer-
ences, but does not act on already existing references.
If the numbering mode was converted, then new references are generated
according to the new mode. Already existing references are not changed, and
hence are incorrect.
Therefore, a mode change must comprise the following steps:
• Change the numbering mode
• Delete all existing references in the document group (but not the originals)
• In the document group, select | CREATE REFERENCES.
40.6.5 Generating or deleting references
Initiate manual referencing

If you right-click on a document group, you will see the following commands:
| CREATE REFERENCES
Automatic referencing in document groups applies only when documents are
created new. With the help of this command, it is checked whether there are
any older documents that need to be linked to this document group.
| DELETE REFERENCES WITHOUT ORIGINAL
As a rule, all relevant links are deleted when a document is deleted. If not, then
redundant links can be deleted with this command.
Update documents manually

Normally, starting pages, page numbers and number of pages are updated
automatically. However, sometimes Comos cannot detect the current number
of pages in a document. In such cases, you can use the mouse menu
| EVALUATE DOCUMENTS. Effect: All documents are updated. Tbe command
has the same effect as opening and saving all documents.
Change Unit/ Location/ Name

SYS |System data tab, Change of unit/location/name option group:
• Delete references automatically

Fired: When the unit or location pointer of the document group is changed.
Effect: All references are checked to ensure they are still valid. Invalid
references are deleted.
Default = False

• Create references automatically

Fired: When the unit or location pointer of the document group is changed.
Effect: The same effect as if the user had selected the “Create references”
command in the mouse menu. A search is made for documents that should
have a reference but do not have one. No references are deleted.
Default = False
• Create new references after name change
If the name of a document or document group is changed, it is checked
whether an existing reference in a document group is still valid. If not, the
reference is deleted.
Default = False
40.6.6 Optional: Set additional pointer
Document groups can be limited in such a way that they consider only the
documents of a specific unit or location branch.
This method is required if the structural design of the document groups is not
unique, see for example SECTION 40.6.2.3: SUBSTRING COMPARISON.
Example:
Document name: WSP
Name of document group 1: WSPOld
Name of document group 2: WSPNew
Effect: The automatic reference is formed in WSPOld . Reason: Without fur-

ther criterion, the document group is accepted whose name comes first in the
alphabet.
In cases in which parts of the names are identical, it is better to assign a link
to a unit or a location (or both) to the document group. Thereby, first the unit
view and then the location view is checked.

Documents tab, select a document group, right-click |PROPERTIES

Drag the required unit to the document group properties window:
Effect in the document group

Automatic referencing considers only documents that are located (recur-
sively) under this unit.
Documents with location or unit pointer

If a document group evaluates only one unit or location (i.e. if it has a pointer),
then even pointers are considered that point to this unit or location. (Provided
that the syntax convention is fulfilled, of course.)
Example:
• A document group evaluates the location L1.
• There is an original document Test1 in the unit UN1 and has a location
pointer to L1 (and also fulfils the syntax convention).
Effect: The document is referenced in the document group.
Effect in the unit

In the unit view, the reference to the document group is displayed under the
unit. If a document is created under this reference in the unit, then the docu-
ment also appears on the Documents tab under the document group.
In this case, the documents offer no selection options in the | NAVIGATION com-
mand. This is due to the fact that on the Units tab and on the Documents tab,
you can view the same document respectively: not the document that was ref-
erenced, but the Document group.
The usual navigation options are available for the document group.

@REPORTS Document Group Document Management (DQM)
40.6.7 Consequences with other Comos functionalities
Module ET/I&C
In this module, references are used when connections and lines are interrupted
optically, but continue logically.
The representation of the reference text is controlled via the project proper-
ties, Module options tab, EE/I&C reference layout sub-tab. If “Page
number ” is selected in the Sort documents field, then the document
sequence is computed from the Starting page field explained here.
40.7 @REPORTS Document Group

The @REPORTS document group facilitates access to report templates.
Background: In the properties window of Reports, you will find the Report
template field on the Report tab. Press the [...] next to this field to open the
Select report template dialog window.
The user will first see the base project. If the @REPORTS document group
exists on the Documents tab of the base project, then it is shown as default
setting. If no @REPORTS document group exists, then the dialog window
is initialized with the project root.
However, the user can also switch to the open planning project activating the
radio button “Current ”. Here, too, the following applies: If the @REPORTS
document group exists on the Documents tab of the current planning project,
then it is shown as default setting, otherwise the project root is selected. By
activating the radio button “Base ”, you can return to the base project.
An @REPORTS document group can be created both in the base project and
in planning projects.
Create an @REPORTS document group

• Open a project, then activate the Documents tab in the Navigator.
• At the project level, right-click | NEW DOCUMENT GROUP.
• In the following New object under... dialog window, enter these values:
Name @REPORTS (Keyword: case-sensitive)
Description Any
Base object @G Document group (unchangeable)

Document Management (DQM) Drag&Drop - Import @DocumentTypeMapping
All information about organizing report templates is given in SECTION 49.9: NEW
DOCUMENT: REPORT TEMPLATE.
Consequences for the @NameSystem document group

As described in SECTION 40.6: AUTOMATIC REFERENCE CREATION, there are two ways
to manage an @NameSystem document group: either there is only one docu-
ment group at the project level or one of the document groups has the key
name @NameSystem.
The @REPORTS document group is also created at project level. If there is an
@REPORTS document group at one of the deeper levels, then that is a com-
pletely “normal” document group without special functionalities.
Hence, the following applies:
If only one document group exists in aproject and if you then want to create
an @REPORTS document group in this project, you must rename the already
existing group into @NameSystem before creating the @REPORTS group.
Alternative: If there is only one document group at the topmost level, then you
can also name it @REPORTS. Because as long as only one document group
exists, the name is unimportant from the point of view of the @NameSystem
functions.
However, that is not recommended. The @NameSystem document group
manages reports, the @REPORTS document group manages Report templates.
For reasons of clarity, templates and reports should be stored separately.
40.8 Drag&Drop - Import @DocumentTypeMapping

It is possible to import external documents to Comos using Drag&Drop. For
this, you must drag the required document from the Windows Explorer into
the Navigator.
By means of the @System|@D|@DocumentTypeMapping base object, Comos
can exactly determine for a new document which base object is to be used for
the new document object:
• So-called extension objects are created under the
@System|@D|@DocumentTypeMapping administration object. They
represent the file extension of a document type. Their name (in upper case)
corresponds to a file ending.
• On the System tab of this extension object, the document base object to use
is entered in the Reference field.

Full-text search Document Management (DQM)
• If a document is imported using Drag&Drop, Comos first checks if there is

an extension object for the same ending under @DocumentTypeMapping.
• If yes, the program creates a document object that is based on the document
base object referenced in the extension object.
If not, a document object is created that is based on the @O document object.
The @DocumentExtensionMapping base object can also be created through
the database adjustment. See SECTION 49.3: DATABASE ADJUSTMENT.
40.9 Full-text search
40.9.1 Objective
This component enables a full-text search for all documents within Comos.
To improve performance, an index is created through which you perform the
search. To do this, use the dtSearch API software (external component).
Exclusions
The current states of evaluation reports are not entered at present. However,
the revisions are entered.
In interactive reports, texts that originate from symbols are not entered.
40.9.2 Interaction with the working layers

There are many indices: One for the released area and one each per working
layer. Current status: If you are searching in a working layer, then only the
documents (new or changed) checked into that working layer are recorded.
Future development: All documents visible in a working layer must be
recorded.
Project options of indices: Current status - uniform options apply for all indi-
ces (both for the index in the released area and for indices in the working lay-
ers).

Document Management (DQM) Full-text search
40.9.3 Project options
Properties of a project, Full-text index tab:
Inclusion filter / Exclusion filter :

The entries must be separated using comma.
All path information always applies in relation to the document directory.
Files: The standard notation “Name.Extension” is applied. As wildcard
(place holder) the asterisk is allowed in the name and extension. Examples:
*.txt
*.ps
*.mp*
Please note: File endings (extensions) needed somewhere else must not be
excluded. Example: if the revisions are generated in PDF file format, then
do not exclude *.pdf here, otherwise no revisions will be found.
Paths/ folders: Relative information enclosed in inverted commas with
backslash, example:
“\Test\“
Consider case sensitivity

Self-explanatory.
[INDEX]
Manually initiates a (re-)indexing. If you have never worked in a project with
the full-teull-text search, create the index with this button once. Afterwards,
the index is updated automatically. However, there are actions that cannot be
considered by the automatic update, see Exclusions from automatic updating, P.
40-17. If such situations occur, then the index must be reindexed manually.
Exclusions from automatic updating

Once the index has been created manually via the [INDEX] button, Comos
updates the index constantly. However, the following actions are not consid-
ered by the automatic updating:

1. Changing documents outside Comos. This situation occurs in the

following cases:
– If documents in the document directory are edited outside Comos
– If an external document (Word, Excel, AutoCad etc.) is opened in
Comos, and then Comos is closed before the external application.
2. If several users are trying to update an index simultaneously and Comos
is closed too early. Background: The index can only be accessed by one
user exclusively. All other Comos users must register that they have
changed documents that must be included in the index. In case of mass
operations (especially a large import), this will result in a long queue. If a
Comos application is closed that still has unprocessed registrations, then
these change notifications are lost. (This has no effect on the documents.
The result is that the index will not be up-to-date).
In normal Comos operation, this situation will not occur, as the
performance of the index queue is high enough to process multiple
queries. However, this might not be the case for massive imports.
3. Data changes that are indeed expected in a document, but have not been
carried out yet. Many documents react to changes to the Comos objects.
However, this reaction takes place only on “evaluating” of the document,
e.g. on opening or printing the report. Naturally, the index cannot detect
any change in the report before the report itself has been updated.
4. Changes to template files, until the relevant planning reports are
evaluated or are otherwise changed. From a technical point of view, this
is a special case of point 3. Basically, all texts originating from the
template files are also recorded by the full-text index. But changing a
template file does not result in change stamping all relevant planning
documents. Consequently, the index does not recognize the planning
documents as changed, either.
40.9.4 Administration of full-text search
Generated files
When the full-text search is created for the first time using the [INDEX] button,
the “ComosFullTextIndex” folder is created in the document directory of the
project. For example, if the project is called “Comos_PT”, then the following
path is produced:
<Database folder>\Comos_PT\ComosFullTextIndex
If a working layer too exists, for example, for the working layer with ID 2:

<DB folder>\Comos_PT\Overlays\WO00002\ComosFullTextIndex
history.ix
ASCII file. Contains the history of the dtsearch acknowledgements of the
index actions. Each entry begins with a date in * * * 01/11/2006 15:48:42
(7025) format. The latest entry is located at the end of the file.
index_v.ix.log
ASCII file. Contains the history of the file operations.
indexlog.dat
ASCII file. Contains the extract with the latest entry of the history.ix.
Rights required in Comos

To create or update the index, you need the Project options function right in
Comos. In the file system, you need full access to the document folder: The
files to index are located there, including the index administration files.
To use the full-text search, you need only read rights in Comos and read rights
to the document folder.
40.9.5 “Full-text search” plugIn
40.9.5.1 Profile object of full-text search

The FTSearch profile object exists for the full-text search:
The following applies (as for all profile objects): Profiles can be saved either
locally in the current project or globally in the base project. In addition, there
can be one profile for all or individual profiles. For this, see SECTION 1.6.1: PRO-
FILES.
FTSearchAttributes
If this object exists and has specifications, then the full-text search switches
to the attributed search. For this, see SECTION 40.9.5.5: ATTRIBUTED SEARCH.
StandardHitList
The layout of the hit list is saved here. For this, see Customizing the hit list, P.
40-31.

40.9.5.2 Options
Search range
Documents and revisions
Documents and the revisions of the documents are shown as hits.
Revisions
Only the revisions of documents are shown as hits.
Current revisions only
Only the last project revision and the last plant revisions are shown as
hits.
Documents
Only the documents are shown as hits.
Search logic
At least one of the strings
(Natural search)
A hit list is displayed as soon as at least one of the specified words is found in
the content or in the attributes. This mode is also called “natural search”.
All strings
A hit list is displayed if exactly the specified words are found in the document.
Boolean search
The search is performed according to the standard notation: AND, OR, AND
NOT etc.
Search precision
Fuzzy search
Finds the search term even if it is written wrong. The degree of reliable devi-
ation can be defined using the slider.
Fuzziness level
The fuzziness level is controlled by the dtsearch component. However,
innotec cannot define the precision of the fuzziness level evaluation. See %
Fuzzy search (slows down the search), P. 40-22.
Substring search
The search term can appear anywhere within a word.
Background: When you search for a string/word in the basic setting, the
full-text search actually searches for <string>*. Example: If you are searching
for the word “test”, then in the basic setting a hit list is displayed if “testterm”
is found in the document.

If the “Substring search ” option is enabled, then a genuine substring search

is performed, i..e. it is searched for *<string>*. In the above example, a hit list
is displayed even if the string “123testterm” is found in the document.
Exact search
The search term must appear as full word exactly as entered. This option thus
disables the part substring search that exists in the basic setting. For this, see
the explanation for the “Substring search ” option.
Restore standard
Self-explanatory.
Parameters of the index used

Here, the settings of the project options are displayed, for this, see
SECTION 40.9.3: PROJECT OPTIONS. These settings can be changed only in the
project options.
40.9.5.3 Standard search

The standard search exclusively searches the content and the file attributes of
documents and revisions. TIFF revisions cannot be searched, as TIFF files
have no ASCII content.
Please note: The Comos properties are not evaluated. Thus, it is not important
whether the document contains the search term as name or description. The
only decisive factor is whether the searched term exists in the document or
not.
Search below
Sets the starting point of the search. The project node is set as default.

Search keys
One or more words or character strings. The options stipulate in what manner
the term(s) will be evaluated. When entering the details, an input help window
opens, displaying words and strings available in the index and matched to the
letters typed until then.
Hit list
The options in “Document details ” and the hit list are explained in
SECTION 40.9.5.6: SEARCH RESULTS / HIT LIST.
40.9.5.4 Complex search queries
40.9.5.4.1 Wildcards (“placeholders”)
Wildcards * and ?
? Finds any character
* Finds as many characters as you want
These two placeholders can have any position:
App* finds apple, apple cake, etc.
*sad* finds sadly, ampersand, etc.
b?t finds but and bet but not boat.
b*t finds both but and bet and also boat.
The earlier the placeholder appears in the word, the longer the search.
% Fuzzy search (slows down the search)

Syntax: The number of percentage signs entered determines the number of
permitted deviations. The position determines which letters beginning from
front must appear. Examples:
Ba%nana
The word must begin with Ba and must have only one deviation to the word
banana.
Ba%%nana
The word must begin with Ba and must have maximum two deviations to the
word banana.
Result: The fuzzy search finds words written wrong. For example, a fuzzy
search for “B%anana” would also find “Bananna” or “Bana”.

# Phonetic search
Syntax: The word to be searched for phonetically must be introduced with the
pound key (#). Example:
#Brown, #Meyer
Result: The phonetic search looks for similar sounding words, that begin with
the same alphabet. Example: A phonetic search for Meyer would also find
Mayer, Maier and Mayor.
The phonetic search is slower than the standard search and generates larger
hit lists.
~ Stemming search
Stemming search tries to ignore grammatical variations of a word, respec-
tively to find a word despite of grammatical variations. Example: If you are
searching for “mouse”, it would also find “mice”. If you want to use the stem-
ming search, you must first create a STEMMING.DAT. More information on
this is given in the dtsearch help.
~~ Number range
Syntax: To search in a number range, you must specify the upper and lower
limit and separate them using the double tilde:
Apple w/5 12~~17
Result: This query finds documents where the word is not more than five
words away from a number between 12 and 17.
• Every number range search includes the upper and lower limit (in the above
example, 12 and 17 would also be listed as hit list).
• Only positive integer numbers are allowed.
• In the number range search, commas and decimals are evaluated as blanks:
Minus signs are ignored. Example: -123.456,78 will be interpreted as:
123 456 78 (three numbers).
:Variable word weighting

The hit lists are sorted by a weighting; initially all search terms will be
weighted equal. This can be changed with the help of a variable weighting.
Example:
Apple:5 and Pear:1

This search query will find the same hits as without weighting. But the
sequence of hits in the hit list will have changed: the term apple counts five
times more than the term pear.
Word-weights can also be used in Boolean search:
(description:5 contains (Apple and Pear)) or (author:2 contains
("Jim Smith"))
## Regular expressions
Regular expressions allow you search for complex character combinations. A
regular expression must always be included in inverted commas and intro-
duced with the double asterisk. Examples:
Apple and "##199[0-9]"
Apple and "##19[0-9]+"
A regular expression always refers to a single word. For example, the query
"Apple Pear" cannot be found with the regular expression "##App.*ar".
A regular expression behaves like the placeholder asterisk * in relation to the

performance: The sooner the placeholder appears in the character string, the
slower the search. "Appl*" is searched as fast as "Apple", while "*pple" is
more time-consuming.
40.9.5.4.2 Regular expressions
. period and decimal separators

Period finds a single character.“car.” finds “card” and “cart”
.* (period multiply)
The period with the multiplication sign (asterisk) means “0 or more” of some-
thing. If the combination .* is entered within a search term, then anything or
nothing can appear at that location.
.+ (Period plus)
The period with the plus sign means “1 or more” of something. If the combi-
nation .+ is entered within a search term, then anything can appear at that loca-
tion, but at least one character must appear at that location.
^ (caret)
Stands for the beginning of a paragraph.

$ (Dollar)
Stands for the end of a paragraph.
\ (Backslash)
Escape-Sequence: The next character is not evaluated as control character.
Example: “\$100” means that “$100” is searched for, instead of evaluating $
as control character for the end of a paragraph.
[abc] Square brackets with character string

Square brackets define a number of characters from which one must appear.
Example: “pea[kl]” finds “peak” and “peal”, but not “pear”.
[a-t] Square brackets with character range

In the square brackets, you can also enter a character range by using a hyphen.
For [a-t], every letter in lower case from a to t would be found.
[^a-p] Square brackets with character exclusions

Finds all characters except the specified characters. For [â-p], all characters
except letters in lower case from a to p would be found.
[a-z]+
This expression does not only find one character, but one or more (see also
above “Period Plus”).
40.9.5.4.3 Boolean search

A Boolean search consists of a group of words that are correlated using spe-
cial conjunctions. The upper/lower case of conjunctions is ignored. AND works
exactly like and or anD.
and
Apple and pear: Both words must exist.
or
Apple or pear: One of the two words must exist.
w/<number>
Apple w/5 pear: Apple must be found within a range of five words around the
word pear.

pre/<number>
Apple pre/5 pear: Apple must be found in a range of five words before the
word pear.
not w/<number>
Apple not w/5 pear: Apple must not be found in a range of five words before
and after the word pear.
and not
Apple and not pear: Apple must appear, but the word pear must not appear.
name contains <character string>

name contains Smith: the Name field must contain the entry Smith.
w/<number> xfirstword
Apple w/5 xfirstword: Apple must appear in the first five words.
w/<number> xlastword
Apple w/5 xlastword: Apple must appear in the last five words.
() Brackets and combinations

If many conjunctions are used, use brackets.
Example 1:
Apple and Pear or Orange
Better:
(Apple and Pear) or Orange
and
Apple and (Pear or Orange)
Example 2:
(Apple or Banana) and (Pear w/5 Grapefruit)
finds all documents that
• contain the word apple or the word banana
• and simultaneously, the word pear in a range of five words around the word
grapefruit.

NOT
The conjunction NOT before any search expression inverts the meaning. Sub-
sequently, hit lists can be reduced, as documents with the corresponding terms
are excluded. Example:
Apple or not Pear
Apple and not Pear
not (apple w/5 pear)
NOT can be entered as single conjunction at the beginning of the search

expression: not Pear finds all documents where the word pear does not exist.
If NOT is not the first conjunction of the search expression, then NOT must
be entered in connection with AND or OR.
40.9.5.5 Attributed search

The attributed search records exclusively the content of file attributes.
Please note: The Comos properties or the file content are not evaluated. Thus,
it is not relevant whether the documents contains the search term as name or
description or which content is available in the documents. The decisive fac-
tor is if the search value is found in the file attribute.
Background: File attributes / Standardized file properties

File attributes are information that is written to the actual file outside Comos.
File attributes can also be read or set outside Comos. To do this, open a Win-
dows Explorer, right-click a file and select the | PROPERTIES command.

The standard file attributes are found in the Summary tab:
All files in Windows have a series of standard attributes (which are usually
blank). The key names are:
Author
Category
Comments
Company
Keywords
Manager
Subject
Title
LastEditedBy
What the standard attributes are called in the interfaces is not important. Even
Microsoft gives different names for these standard attributes. For example,
the standard attribute “Subject” is sometimes also called “Topic ”. But
“Topic ” cannot be addressed, rather the attribute must be addressed with
“Subject”.
User-defined file properties

In addition to the standard attributes, you can also create and set user-defined
attributes. MS Office in particular has such attributes, which are collected on
the “Custom ” tab:

Even PDF has additional file attributes, but these are not fully supported at
present.
The additional file attributes of AutoCAD are not supported, as additional
licenses are needed for this.
Evaluate file attributes in the full-text search

The name of the Comos specifications must be identical to these key names,
so that Comos can achieve a link between the full-text search and the file
attributes at the operating system level.
To do this, create the “FTSearchAttributes” profile object:
In this base object, create as many tabs with any names as you want. Create
the following type of specifications on these tabs:
• Reference (SUILink)
• Date (SUIDate)
• Edit field, Edit: (Min Max), Edit: (Min Value Max) (SUIEdit)
Name: string is identical to the name of the file attribute

Description: any
Control user-defined file properties in Comos

At the workset, Comos provides the “Workset.SetFileAttribute” function.
This function allows you to set user-defined file attributes. For example, one
option would be to set the attributes when checking in a document in the
Comos version management:
Function OnDocumentCheckIn (Document)
' Event : On checking in a document
' Input : checked-in document object
MetaDataExChange Document, 0
End Function
Sub MetaDataExchange(Document, Mode)

''Begin exchange of meta data

If Document.Documents.Count > 0 Then

'get the current document, depending on whether this method is
called for check-in or check-out
Set DocVersion =
Document.Documents.Item(Document.Documents.Count)
FName = DocVersion.Fullfilename
End If
'get the tabs of the mandatory fields
Set MandSpec = Document.spec("Mandatory")
'Iterate all mandatory fields ...
Ruckgabe =FName 'Ruckgabe = Return val
For i = 1 To MandSpec.OwnSpecifications.Count
Set MySpec = MandSpec.OwnSpecifications.Item(i)
'Only for edit fields and dates
If MySpec.ControlType = "ComosSUIEdit.SUIEdit" or
MySpec.ControlType = "ComosSUIDate.SUIDate" Then
res = Workset.SetFileAttribute( FName, MySpec.Name,
MySpec.DisplayValue)
Ruckgabe =Ruckgabe + vbcrlf + Cstr(res) + MySpec.Name +
MySpec.DisplayValue
End If
Next 'i
'msgbox Ruckgabe
''End exchange of meta data
End Sub
Search results / Hit list

See SECTION 40.9.5.6: SEARCH RESULTS / HIT LIST.
40.9.5.6 Search results / Hit list

In the standard search, the relevant tools are directly integrated on the Search
tab, whereas a separate window opens in the attributed search. Otherwise,
everything is the same: The search results will be displayed and used during
the standard search and during the attribute search:
Document details

– Document Preview
The Document Preview uses the “AutoVue”, which is licensed
separately. This universal file viewer is controlled from the project
options: Project properties, Options tab, enable the “AutoVue - Use as
document view ” option at bottom left. This project option can only be
enabled if you have the license.
Then you can switch to the “Document Preview ” option in the
document details.
– Document Properties
When this option is enabled, a part of the document properties window is
displayed on the right.
Please note: The properties can also be changed there.
Default columns
Standard search:
Document : contains the SystemFullName.
Unit revisions / Project revisions : contains the name of the released
revisions, separated by comma.
Unit versions / Project versions : contains the name of the checked-in
DVM versions of the documents, separated by comma.
Attributed search: For every Comos specification that had been created, a col-
umn is displayed.
Customizing the hit list

The hit list consists of an object query and can be configured separately.
Please note: Changes must be saved, otherwise they are lost. To save the
changes, right-click in the column header of the hit list and select | SETTINGS
| SAVE.
40.9.6 Checklist if a document is not found
• Has a folder that is required been excluded from the project options?
• Has a file ending that is required been excluded from the project options?
• Is the document located in another working layer?
• Has the revision file already been created? The revision file is available
immediately only for the “Create PDF file at first step ” option. In all
other modes, a revision file is only created when the revision is released.

• Is the index up-to-date? In special cases, users can bypass the automatic
update by Comos. In such cases, the index must be updated manually.
• Are you working in the correct full-text search mode? The standard search
finds no metadata (file attributes) and the attributed search finds no
document content.
• Are you trying to search for a property of the Comos object (name or label
of Comos object)? The full-text search is not a Navigator search and does
not find Comos properties.
• Did you find a spelling mistake in the document? Perhaps your search query
is correct, but someone editing the document made a spelling mistake. In
this case, you can still find the document with a fuzzy search or by using
wildcards (“placeholders”). (Attention: more time required.)
40.9.7 Performance
Please note: Full-text searches are mass operations! Full-text searches process
data in extremely large quantities and hence must be used with care. On the
one hand, you must reckon with high processing times, on the other hand, the
search can be speeded up dramatically if you observe certain rules:
• Documents with a Comos UID are found more quickly. This is
automatically the case for Comos reports. For external documents (Word,
Excel, AutoCAD, PDF etc.), this rule applies when the external documents
were generated with the “Normal ” option: Properties of a document, switch
tab (for example, for a Word document the tab is also called Word ),
Document group, “Normal ” option.
• The “Start object ” field retroactively filters the hit list. The basic principle
is that the complete index is searched, which contains the complete project.
If some other object than the project is set as start object, then the
performance drops: first the complete project is searched, then the number
of hits is reduced to match the Start object .
• The “Search range ” group retroactively filters the hit list. Thus, the search
will be faster, if here you select the “Documents and Revisions ” setting.
• The “Boolean search ” is slower than “At least one of the strings ” and
“All strings ”. Both character string searches are equally fast.
• The “Fuzzy search ” and “Substring search ” slow down the search.
• The “Exact search ” does not affect the performance.

Revisions Creating revision base objects (revision types)
41 Revisions
41.1 Creating revision base objects (revision types)
41.1.1 General
The structure of the following base data controls the entire revision process.
A valid "package" of base data always consists of a "Revision carrier” and the
"Revision elements”.
So the first step is always to create one or more “Revision base objects = Revi-
sion carriers”. Only after these base objects have been created, you can select
them at the documents or document groups. At the documents/document
groups the revision base objects are called "Revision types".
Root of all revision base objects

@System |@D Data |@Revision .
41.1.2 Structure of a revision base object / revision table
41.1.2.1 The "revision carrier"

The revision carrier is a base object of class "Revision ":
If a new revision is created, this base object is searched for and used to create
a Device object below the document / document group. This Device object is
invisible in the navigator.

Creating revision base objects (revision types) Revisions
The device object provides the information for the "Index ", "Label " and
"Description " columns:
• The "Index " column contains the name of a revision. In other words: just
like every other object, each revision has a name. However, for revisions,
the user can’t issue a name. Instead the name is issued by Comox, following
a complex classification system. Therefore, the “Name” of a revision is
called “Index” in the interface. If you want to retrieve the index of a
revision, then you must read the “Name” property.
SECTION 41.4: THE "INDEX" OF A REVISION describes the classification system for
indices.
• The "Label " and "Description " columns include the label and description
of the "Revision carrier".
Please note: The "Description" of a revision is not translated. Instead, the
description is written to the primary language and is the same in all
languages.
41.1.2.2 The revision elements / revision steps

The base data side determines which revision steps a document must run
through. For this, objects are created as "Elements " on the revision carrier:
The number of elements determines the exact number of revision steps:

Revisions Creating revision base objects (revision types)
The number of elements (i.e. the revision steps) can vary according to the
revision carrier.
For each revision step that is executed, a Device object of the "Revision "
class will be created (likewise invisible in the navigator). This Device object
provides the revision table with the following information:
• A timestamp
The timestamp for which the device was created is the time stamp of the
revision step. At the same time, the information from the time stamp is used
as default value for the revision step label / the revision step description. The
user can manually enter other values; in that case, you can also retrieve the
timestamp through script.
• Revision step label / Revision step description
The label and description of this device is written into the column (separated
by slash). The timestamp is used as default; the user can also manually enter
anything else.
Please note: The "Description" of a revision step is not translated. Instead,
the description is written to the primary language and is the same in all
languages.
Creating revision elements

• Right-click on the base object @Revision and choose the Properties
context menu.
• Select the Elements tab. It is moved to the foreground.
• Perform a right-click in the dialog window and choose | NEW from the
context menu.
The New base object below... dialog window is displayed. Activate the
System tab and enter the following values:
Class Revision
Name The name is a number; so the first step has the name
1, the second 2 (or a higher number) etc.
Mandatory elements are:
• For the first step: "1" as Name.
The first step "creates" a revision.
• For the last step: "99" as Name.
The last step "closes" a revision.

Creating revision base objects (revision types) Revisions
Label user-defined
Description This text appears as default for the description of a
revision.
Virtual 1 times.
A text mask can be defined for automatically generated labels of a revision.

For this, a text mask is entered for the revision base object.
41.1.2.3 Creating multiple revision base objects

You can create further revision base objects under the @System |@D Data
|@Revision root object:
You can use the @System |@D Data |@Revision root object and all
objects created directly below in any combination as revision base objects.
Any object that is to be used as revision base object ("Revision type"), needs
elements for the revision steps (as described before). At first, the elements are
inherited, but they can also be deleted or new elements added as needed.
41.1.3 "@Project" revision
Below base object @Revision you can create objects with the Name @Pro-
ject. These objects belong to the Dual Document Management (@Project)
of PQM.
41.1.4 Switching off animation
An animation with a stamp appears during the revision process. This anima-
tion can be switched off:
To do so, create a specification "SYS.NoStampDlg" of type Checkbox at the
revision base object.

Revisions Base object of a document: Selecting the revision type
41.2 Base object of a document: Selecting the revision

type
Base objects of the Document class, System tab:
Miscellaneous option field, Revision type field. All revision types defined
under @Revisions will be displayed.
By choosing the entry None , you can disable the revisioning process for a
document group or document.
41.3 Preparing group revisions
41.3.1 Base objects of a document group: Selecting the revision type
Base objects of the Document group class, System tab:

Miscellaneous option field, Revision type field. All revision types defined
under @Revisions will be displayed.
By choosing the entry None , you can disable the revisioning process for a
document group or document.
Relation to the revision type of the single document

A document group can be revised only if all the documents in this group have
the same revision base object as the document group. In short: The same entry
must be selected in the Revision type field.
In contrast to that, a single document can always be revised without consider-
ing the document group (as long as it does not flow into an open group revi-
sion).
41.3.2 Planning objects for document groups
Prerequisites
The following conditions must be met to ensure a document group can be
revised (and thus make the group revision usable):
• Naming convention of group fulfilled
– Document group is in @NameSystem branch or in @Project branch.
@NameSystem branch: If only one document group exists at the topmost
level (directly below the project), then it can have any name. If there is
only one TopLevel group, it is automatically interpreted as @NameSystem

The "Index" of a revision Revisions
group. (It is not important to know how many document groups exist
under it.)
If there are more than one document groups at the topmost level, you must
explicitly use the key name @NameSystem.
• Project options (optional): Automatic referencing
– In the project options, you can switch on the automatic referencing of
documents for the @NameSystem branch.
• Base object of document group: Revision type.

– The base object of the document group must have a valid entry in the
Revision type field in the System tab.
If above conditions are fulfilled, then the Revision tab appears in the docu-
ment group.
Please note: Similar preconditions must be met when using @Project docu-
ment groups.
Properties of a document group

Specifications: SYS System data tab
Revision settings group:
• Revision of all documents
All documents are included into the group revision (and not only the
changed ones).
• Unique group identifiers
This option influences the revision index issue in specific cases, see
SECTION 41.4: THE "INDEX" OF A REVISION.
41.4 The "Index" of a revision

Every completed revision automatically receives an index number. This num-
ber begins with zero and is unique for each object. In short: an index number
can never be given twice on a Revision tab. A higher index number means
that the revision is latest.
The index is computed according to the following rules:
1. Revision to document;
Document is not in a document group
or in a non-revisable document group:

Revisions Project options: Revision options
Index_new = (highest index) +1

In practice, this results in a consecutive counter.
2. Revision to document;
Document is in a revisable document group:
2.1 Unique group identifiers ON
The index is formed through all documents and the document group
itself. So, a new revision receives the highest number plus 1 of all
existing documents and the document group.
Please note: In older Comos versions, this was the default setting.
2.2 Unique group identifiers OFF
Document is revised: Only the document itself and the document
group is checked.
3. Revision to the document group:
Index_new = (Highest index of group and all documents) +1
As relates the index, document groups always consider all documents ,
not only the documents included in the revision.
The above rules allow the following conclusions:
– The index of a group is always unique. It cannot happen that an index used
by a group also appears in a document. All documents that are included in
the group revision, similarly get a revision entry with this index. So, with
the help of the unique index, you can identify all documents that have
participated in a specific group revision.
– But it can happen that documents within a group have the same indices. If
you want to prevent this, then enable the Unique group identifiers options.
41.5 Project options: Revision options
41.5.1 The general revision procedure ("PDF at first step")
41.5.1.1 Overview
In practice, revisions often drag on for days (especially, if several people are
involved). However, it is often not possible to lock a document until the revi-
sion is completed. For that case, there are two possibilites states which the
revision can refer to:

Project options: Revision options Revisions
• Beginning of revision
"Create PDF file at first step " option is enabled.
The immutable revision file is created at the beginning of the revision
process (to be more precise: after the first revision step is completed). Then
you can continue working with the documents: all subsequent changes in the
document are not important for the revision by definition.
This revision method requires a PDF as archive format. Therefore, this
method is also called "PDF at first step".
• Revision completion
"Create PDF file at first step " option is disabled.
The immutable revision file is created only after the last revision step. If the
document is not protected against changes, then changes can still be made
from beginning to end of the revision.
For this case, Comos provides automatic revision monitoring. If the
document has changed in the meanwhile, then the revision is reset and
begins from scratch.
41.5.1.2 "PDF at first step"

A revision file is generated already in the first step and not only in the Create
revision step.
The biggest difference to other methods is that here you several revisions can
be open at the same time. This has different impacts:
• You need to check exactly which revision is selected! The Stamp buttons
refer exactly to the selected revision.
• The Info text also refers exactly to the selected revision. For example, if
there is an open group revision and an open single revision for a document
at the same time, then you must select the appropriate entry to get the
matching Info text.
Another difference is that a revision file is printed here immediately. This has
the following effects:
• The name and label for the revision file can be displayed immediately on the
original document and not only an asterisk.
• The revision file is available independent of the original document.
Therefore, the entire “Fall-back” process is no longer required: the
“Revision monitoring (2)” revision option has no effect and cannot be set
either. You can continue to work in the original document and
simultaneously can complete the revisioning based on the revision data
created in the first step.

• The details from the following revision steps logically can no longer be
considered in the actual revision file, as the revision file is created before
these revision steps are carried out. Therefore, at this point, eStamp is used:
This technology helps to stamp all desired revision information into the PDF
revision file.
• The “Revision label ... editable” option has a different effect, see Revision
label editable during the complete revisioning process, P. 41-25.
Other effects
• The “eSign” revision option can be used only if “Create PDF file at first
step” is activated.
41.5.1.3 "Create PDF file at first step ": deactivated

Not much needs to be said on this revision method, as it is the counterpart of
"PDF at first step ".
If the revision option is deactivated, the revision file is generated only after all
revision steps were carried out.
Therefore, information from the various revision steps is already available
when the revision file is printed.
Comos offers automatic revision monitoring (the "Revision monitoring (2) "
revision option). If the document has changed in the meantime, then the revi-
sion is reset and begins from start.
For this, see SECTION 41.5.2: REVISION MONITORING.
41.5.2 Revision monitoring
41.5.2.1 Overview
The revision monitoring checks for reports (evaluation reports, Interactive
reports), if information was changed that refers to Comos objects.
So, the revision monitoring does not include external documents.
The revision monitoring does not include purely graphical elements (e.g. lines
and circles that are manually drawn on the report).
41.5.2.2 Basic settings (Project settings)

Project properties, Revision options tab, Revision monitoring group.

• (0) No monitoring
Revisions can be opened or closed. The user must make sure that a revision
is consistent. No revision label is provided on the report (Exception: see
AutoMarkAsChanged.
• (1) Create revision on change

As soon as a change is detected in a document that does not yet have an open
revision, a new revision (an * revision) is generated.
What the revision monitoring monitors depends on the selected Report
comparison method:
For timestamp-based comparison, the timestamp is monitored for all
Comos-based objects and texts.
See SECTION 41.5.3.3: THE TIMESTAMPS.
For content-based comparison, for texts, the content is monitored and for the
other Comos-based objects, the timestamp.
See SECTION 41.5.4.2: DATA COMPARISON ACROSS THE REVISION.
• (2) Additional monitoring of document releases
Prerequisite: Final printing (“Create PDF at first step” is disabled)
The process of revisioning a document can contain many revision steps and
in practice, can take several days. When the revision is finally released, a
document could have been changed already. This would mean that earlier
revision steps refer to a different document status than the later revision
steps. To prevent this, you can enable this release monitoring.
The monitoring level (2) involves all monitoring for level (1) and also the
following change monitoring:
If a new change is detected in a report, then any existing revision steps will
be deleted in the open revisions and the revision is reset to *.
This change monitoring is done for the following actions: during release,
open, print, | EVALUATE DOCUMENTS mouse command and obviously during
editing.
Hence, even opening and closing (with save) an interactive report can lead
to the revision steps being deleted and the document being reset to the *
release. Next, [CREATED] would have to be pressed.
Note: The revision monitoring can also be controlled at document level,
with the AutoWatchRevisions script option. For this, see SECTION 41.5.2.3:
REPORT TEMPLATES: AUTOWATCHREVISIONS.

41.5.2.3 Report templates: AutoWatchRevisions

The revision monitoring can also be controlled at document level. Auto-
WatchRevisions is the basic function, AutoMarkAsChanged the extension
function.
With AutoWatchRevisions, the revision monitoring of a report is enabled,
but no report objects are marked if they were changed.
By activating AutoMarkAsChanged, report objects that were changed are
marked with rectangular change symbols.
Default values:
AutoWatchRevisions Default: FALSE
AutoMarkAsChanged Default: TRUE
Compatibility: If AutoMarkAsChanged is set to True or missing, then Auto-

WatchRevisions is automatically set to True.
Interaction effect with the Revision monitoring project option

Revision monitoring project option at None (i.e. disabled):
– AutoWatchRevisions
This option hass no longer any effect, except that it must be set to TRUE
for "AutoMarkAsChanged".
– AutoMarkAsChanged
Is evaluated further. If a completed revision already exists, then the
revision rectangle will be activated. In short: If anything changed in the
report since the last revision step, then it is marked on the report.
Revision monitoring project option enabled (regardless which option):
– If AutoWatchRevisions is set to FALSE, then this report is not included
into the revision monitoring. So, if this project option is enabled, you can
exclude a report from the revision monitoring.
41.5.3 Report comparison method: Timestamp
41.5.3.1 Monitored objects

Inserting, deleting and moving all objects based on Comos objects is moni-
tored.
Purely graphical elements on the report are not monitored.

41.5.3.2 Monitored properties

Properties of Comos objects are often displayed on the report. For example,
you can place a text that retrieves specific Comos properties. Or you can
design a symbol that outputs Comos properties.
If the following properties exist on the report, then a change is monitored:
• Document: OwnDescription, Description2, Description3
• Project: Description2, Description3.
• Comos object placed on the report: Name, Description, Label.
• Specification placed on the report:
OwnUnit, Unit
OwnValue, DisplayValue, GetXValue, DisplayXValue, GetOwnXValue
LValue, LXValue
SIValue, SIXValue
• Device placed on the report:
AliasNestedLabel2 (DevName when constructing symbols),
OwnDescription (DevDescription when constructing symbols)
41.5.3.3 The timestamps
The timestamps at the revision

Each revision gets two timestamps. Each timestamp consists of two pieces of
information: the time ("login") and the “user”.
• Creating the revision
If an asterisk revision is created and no other revision step is carried out,
then the date of creation of the revision is set to the date when the asterisk
revision was created.
As soon as the first revision step is carried out, this date counts as “time of
creation”; the date on which the asterisk revision was created is deleted.
• Releasing the revision
This timestamp is generated when the last revision step (with the number
"99") is carried out.

Interaction between revision monitoring and timestamp

• (1) Create revision on change
The "Last change" timestamp of the objects is compared with the creation
stamp of the revision.
Please note: In a content-based comparison, texts are not compared with the
help of the timestamp.
• (2) Additional monitoring of document release
The "Last change" timestamp of the objects is compared with the theoretical
release stamp of the revision.
41.5.4 Report comparison method: Content (text)
41.5.4.1 Function overview
Mixed method: Timestamp for non-texts

The content-based comparison functions exclusively for texts. All remaining
objects are handled like in the timestamp-based method.
Content comparison for texts

Normally, timestamps are compared in electronic revisions. Disadvantage:
even documents with identical content can be revision-relevant. For example,
if a value was deleted accidentally, and entered again, then this leads to a
change message. The content-based revision method of Comos solves this
problem and offers other advantages:
• Content comparison
We differentiate between content changes and purely formal changes.
In particular, changing, e.g. an attribute value from "A" to "B" and back to
"A" will no longer be considered as difference, although the specification
was saved twice with timestamps that were later than the last revision.
Thereby, "B" can also be "Nothing". So, even if a value is entered, deleted
or re-entered, this would be ignored.
• Selective change symbols
Individual attributes of an object (e.g. name, label, description) are only
marked as changed separately (in italics), if they were changed separately.
• Change symbols for deleted texts
Until now, deleting caused a change message, but this had no effect on the
report. Now, the last revised text can be displayed in strike-through.

As regards the content-based comparison, no difference is made between

evaluation reports and Interactive reports.
41.5.4.2 Data comparison across the revision

For the timestamp-based revision, it is enough to save a central timestamp and
then to compare the current timestamp of items with this central timestamp.
Thus, each item was only accessed once.
For the content-based revision, Comos must compare two contents. To be able
to do that Comos needs two contents that can be assigned as pair.
First, the content of a report is saved in the XML stream of the revision object
of this document. Data can be read from this XML stream and compared with
the current items of the evaluation report.
Below is an overview of how the pair are formed with the various items.
Texts
• Stable names
The allocation of the content of a text field through the various revisions is
done with the name of the textbox in the report. Therefore, the names of the
text boxes in the report template may no longer be changed after the first
creation of a revision. On the other hand, you must be able to change the
layout of the template completely without disturbing the revision process.
• Unique names
See SECTION 41.5.4.4: UNIQUENESS OF NAMES.
The computed texts can come from any source: from the report itself, from the
master report, the sub-reports or the lists.
Lists on script basis (use of row reports)

Row names
Different technologies are used for lists.
First, the user can issue a row ID: Property NextRowID. This information
takes preference.
If this property is not specified, then Comos checks if the list row has a
ReportObject. If it does, then Comos uses the UID of the RowReportOjects
as ID.
If no ReportObject is available for the row, then Comos tries to use the row
number as ID of the row. This works in all cases where the relative sequence
of rows remains the same, e.g. in terminal plans.

Field names
The individual cells within a row: Lists will be generated by the row reports
and from there get their names through the placed items (as a rule, texts).
Lists based on object queries

• Row names
Even here different technologies are used but they differ somewhat from
those of the script-generated lists:
A user detail of a row ID is not yet possible at present.
First Comos checks if the row object is a Comos object. If yes, then Comos
uses the UID of the row object (IQuery.RowObject) as row ID.
Otherwise, the row number is used.
• Field names
For the individual cells within a row, the name of the object query column
is used. So, you may no longer change the column names of object queries
that are used in list reports. (This corresponds to the fact that you may no
longer change the names of text fields in report templates after generating
the first revision.)
• Revision column
Row reports based on object queries can also have a revision column. For
this, a new general column must be inserted, which has the following
settings:
Properties of the column: Name MaxRevisionIndex.
Reference: Row object
Master column: Off
This column generates a revision column on the report. Following script is
generated for the text fields of this column:
Text = MaxRevisonIndexOf ("<QueryColumnName2>,
<QueryColumnName3>, ...)
This means: The MaxRevisionIndexOf column monitors all other columns
of the object query for revision changes (up to the next column
MaxRevisionIndexOf).
In Interactive reports, this technology can be used by creating an appropriate

text field. For this, see Creating MaxRevisionIndexOf with the "Generate revision
index" command, P. 41-34.

Exceptions
The change of fixed texts (e.g. in the template) is not considered. Similarly,
RTF texts, WMFs, OLEs, checkboxes etc. are not considered.
To sum up: The purely graphical layout of the template can be changed with-
out disturbing the revision process.
Comos also automatically excludes text fields with the Description of spec-
ifications from the revision monitoring, as long as it can detect them. Comos
can identify a Description if it was created with the help of one of the follow-
ing methods:
• ReportObject & Property=Description
• ItemObject & Property=Description
41.5.4.3 Deleted rows

The deleted rows will always output at the end of the list.
The content of the deleted rows is always generated from the content of the
RevisionContentXML, without the scripts of the individual text fields or row
reports being processed. Therefore, icons, images or similar objects cannot be
output in deleted rows.
If the "Since beginning of revision " option is set, then more than one
deleted row is presented if necessary. In such cases, the deleted rows are first
sorted by the revision in which they were deleted. Then, they are sorted in the
order in which they were placed in the original list before deletion.
41.5.4.4 Uniqueness of names

The content-based revisions need unique names. On opening the ReportDe-
signer, all items with duplicate names are displayed in red.
This command |RE-ESTABLISH UNIQUENESS OF NAMES in the mouse context
menu fixes the problem of item on evaluation reports that were not properly
named.
When items are created in evaluation reports (i.e. texts, lists etc), it is not part
of the naming process to check whether these items have the same name.
Even though identical names essentially do not lead to serious technical grem-
lins, they often create problems. One problem could be that scripts no longer
address the items clearly (as the items will be exclusively identified by the
names and not by a UID or something similar).

On opening the ReportDesigner, all items with duplicate names will

be shown in red. In the mouse menu of these objects, the
| RE-ESTABLISH UNIQUENESS OF NAMES is available.
With this mouse command, the current object (for which the mouse menu has
been called) is not changed. All other items with duplicate names receive new
names, but this one item remains unchanged. But as all other items receive
new names, there is no longer a duplicate for the current item and all items are
unique.
41.5.4.5 Preparations / options

There are three options that influence the content-based revision monitoring.
All three options can be set in the project properties and in the options script
of the report template.
The report template wins. This applies for each option individually (if only
one, if two or if all three options exist in the report template).
• EnableContentBasedRevisioning
0: Content-based revision monitoring is not used.
1: Content-based revision monitoring is used.
• ShowDeletedTextsInContentBasedRevisioning
If there is no text in a text field in comparison to the last revision, then...
– 0: ...displays blank in the current revision.
– 1: ...displays the text of the last revision in italics and strikethrough.
If there is no text in a text field in comparison to an earlier revision, then...
– 2: ...displays the text of this earlier revision in strikethrough (and not in
italics).
• ShowDeletedListRowsInContentBasedRevisioning
If a row is omitted as regards the last revision, then...
– 0: ...this row is not displayed in the current revision.
– 1: ...this row is displayed in strikethrough and italics at the end of the
list with the texts of the last revision.
If a row is omitted as regards an earlier revision, then...
– 2: ...this row is displayed in strikethrough (not in italics) at the end of
the list with the texts of the last revision in which this row was not yet
deleted.

Exceptions
The AutoMarkAsChanged function must be disabled:
AutoMarkAsChanged = False for all revision list fields
The revision monitoring of level 2 cannot be combined with the content-based

revision.
41.5.4.6 Asterisk revisions

If an asterisk revision is created through the content-based revisioning and
then the change in the report is modified in such a way that the change label
disappears, the asterisk revision will continue to exist.
41.5.5 Switching between content comparison and timestamp

comparison
General
The transition from the hitherto date-based revisioning process to a con-
tent-based revisioning process and vice-versa is also possible in existing cus-
tomizings.
But note that both processes use different methods for comparison. In short:
what is marked as “changed” in one process, can be “identical” in the other
process. This applies in both directions.
Comos uses the content-based revisioning process whenever
1. it is generally enabled: EnableContentBasedRevisioning Project
option/ Document option
2. the previous revision of a document was already carried out with Comos
8.1. and the above option enabled.
In the above scenario, Comos always saves the RevisionContent for a revi-
sion; however, the first revision after introducing Comos 8.1. revision will
still have to be date-based.
So, the administrator must observe the following rules:
• Before switching, all open revisions must be closed. The two processes use
different methods to classify the objects as “identical” or “changed”. Thus,
even the assigned revision index is different. If you switch from one process
to another with an open revision, this would result in inconsistent revision
indices.

• Next, all relevant documents must be revised once. After switching, a

suitable comparison basis is available only after the second revision.
Switching from timestamp to content comparison

The previous sections contain all necessary information. This section explains
nothing new, but sums up the points that are significant for migration.
• Unique field names
Criterion: Correct the template when a red font or line appears.
• Unique row names in lists based on object queries
Lists based on object queries automatically ensure that all rows have a
unique name (row index). So, these lists are not critical for migration.
• Unique row names in lists on script basis ("row reports")
In this case, no red marking is made on the reports. The administrator must
check all lists on script basis to ensure that all rows have a unique name.
As shown in Lists on script basis (use of row reports), P. 41-14, this involves many
cases:
1. User issues a row ID (Property NextRowID)
Solution: check own script
2. Comos checks whether the list row has a ReportObject (UID of
RowReportOjects as ID). Alternately: row string issued automatically.
2.1 Important special case: In data sheets it often happens that various
information of the same object is displayed using several row
reports (e.g. different specification tabs). In this case, Comos can
use the UID of the object only for the first row report; the following
row reports require more unique information. Comos then issues
simple names like "Row1", "Row2".
In the above case, the rows will hav unique names as a result of this
new technique. But now the administrator must no longer insert a
row report at any point in the data sheet: if a row report is inserted
behind the last row report, Comos can correct it. If a row report is
inserted into the middle, then the content-based revision will display
wrong information.
2.2 In other cases, a row report is used to examine a large number of
objects. If the list is organized in such a way that each object is
examined only once, there is no problem.
However, if minimum two objects appear several times in the list,
then it is possible that the content-based revision fails: if the order
of both objects changes. This case may be rare but it could happen.
Simplest example: one of the two objects is renamed in such a way

that it its position is changed relative to the other object.

Solution: Instead, work with a separate row ID (Property
NextRowID).
• AutoMarkAsChanged = False for all revision list fields

Criterion: Correct template if the revision fields appear in italics or
strikethrough.
• MaxRevisionIndexOf
The MaxRevisionIndexOf text field must be directly on the left side of the
text field to which it refers. If not, then you see a red line that stretches from
MaxRevisionIndexOf to the text field with the matching name.
Criterion: Correct template if a line appears
Switching from content comparison to timestamp

No special features.
41.5.6 Revision settings: Revision archive (printer driver)
Project properties, Revision options tab, Revision archive dropdown

menu.
41.5.6.1 Purpose of the "Revision archive"

A "Revision archive" is a printer driver for revision files.
If a revision is completed ("released"), then the document is printed to a file.
The sum of these print files is the revision archive. So, the selection of a
printer driver is synonymous with the format in which the revisions are to be
archived.
41.5.6.2 Installation of printer driver

At present, two formats are supported: PDF and Tiff.
There are different printer drivers for both formats, and thus even the
archiving formats vary somewhat.
Please note: The printer drivers must be installed in addition to Comos (see
the document Comos Installation for this). In the project options, the precon-
figured printer interfaces are displayed even if the printer driver has not been
installed.

Further Information
See Installation, Section 9 “Add-On software: Printer drivers”.
41.5.6.3 Special features of the individual revision printer
41.5.6.3.1 "Tiff" settings

Comos Tiff, (c) Black Ice Software
If Tiff is used as archiving format, then the Windows Tiff-Reader is used to
display the archived files.
Comos knows two different Tiff printer drivers. However, only one can be
active for technical reasons:
• Comos Tiff printer (local)
• Comos Tiff (Server)
If you select the "Tiff " setting in the project options, the correct Tiff printer
driver is located automatically.
Configuring print settings in Comos

If the Tiff printer was selected in the project properties (Revision options
tab, Revision settings option group) in the Revision archive , the [Comos
Tiff printer settings] button is displayed.

The button opens the following dialog:
Paper size
Effect on printer driver: Print settings, Device Settings tab, Paper size :
Paper dropdown menu. The Comos labels are slightly different from those
of the individual entries displayed here, but the order is the same. Example:
The first entry in Comos is called "VARIABLE_mm ". In the printer driver
this corresponds to the first entry called "Variable Paper size ".
Graphic resolution
Effect on printer driver: Print settings, Device Settings tab, Graphic Reso-
lution : Resolution dropdown menu.
Not all Tiff printer driver options are supported: the lowest resolution possible
in Comos is 300x300. This produces the following allocation:
Comos Printer driver

Low (300x300) Medium Resolution (300x300)
Medium (450x450) Custom Resolution with 450 x
450
High (600x600) High Resolution (600x600)
Custom max (1500x1500) CUSTOM Resolution max

(1500x1500)

Color depth
Only for the server version of the Tiff printer driver.
Photo quality
Effect on printer driver: Print settings, File Formats tab, Photo Quality .
Exception: Threshold is not supported at present.
Recommendation:
– Revision of reports that contain lists and tables: Sharp .
– Revision of Interactive reports: Floyd-Steinberg or
Jarvis-Judice-Nike , with 80% intensity respectively. These settings
deliver the best results when presenting the revision rectangles.
Auto configuration through Comos

Comos requires specific print settings when revisioning with Tiff printers. For
this reason, in the last step of the Tiff revision or before beginning a large
scale revisioning, Comos checks the following settings and adjusts them if
needed:
• File Formats tab
– File format : Local variant: One of the Tiff formats must be selected. If
not, "TIFF Group 3,1 Dimension " is set.
Server variant: "TIFF Lempel-Ziv&Welch " must be set. If not, it is set.
– Options : Disable Image : must be deactivated.
– Options : Create Multipage Image : must be activated.
• Filename Generation tab
– Name Generation Method : must be set to Use the document name .
– Filename: Keep existing files option: must be deactivated.
– Output Directory: If an entry is missing here, then the user’s Temp
directory is automatically set as output directory.
This test is run automatically and without feedback. Configurations that were
set up before, directly in the printer driver properties, are overwritten. The
changes also apply after ending the Comos session.
If the auto-configuration cannot be carried out successfully, Comos displays
an error message.

41.5.6.3.2 "None" setting

Effect: No revision file is created. All remaining revision capabilities are pre-
served. Revision indices and revision labels are issued. Revision rectangles
are drawn in the reports.
However, the | SHOW REVISION command and other commands no longer work.
The commands are still available; but as no revision file exists, nothing can
be displayed. The customer is responsible for documenting the revised reports
in some way.
41.5.6.3.3 Settings for PDF

– Distiller (V. 5.0)
(Printer driver not included)
– PDFWriter
(Printer driver not included)
– PDF-Factory (V. 1.5x - 2.21)
(only test version included)
– Adobe PDF (V. 6.0)
Adobe has renamed its own PDF printer from "Distiller" to "Adobe PDF"
when changing its version to Acrobat 6.
Archiving format for all above three printer drivers: as set in the printer driver,
PDF 1.3 in the default setting.
If PDF is used as archiving format, then a PDF reader must be installed to dis-
play the archived files. The Acrobat Reader is available on the Comos-CD.
41.5.6.3.4 "User-defined" setting

See Quickstart Programmer, chapter "Linking or extending Comos exter-
nally: Create own TIFF printer interface".
41.5.6.4 Configuration of the printer driver: Security settings

The printer drivers must be set in such a way that the Comos user has access
to the printer driver “Print settings” from Comos.
• Windows NT: Open printer "Properties", "Security setting " tab,
[Authorizations ] button:
The access type for "Each " (or for the relevant user group) must be at "Full
access ".

• Windows 2000: Open printer "Properties", "Security setting " tab:

For the "Each " group (or for the relevant user group), activate the "Manage
printer " option.
Otherwise, the user gets a warning message when he wants to conclude a revi-
sion. Only very experienced administrators should other security settings.
For further information on the configuration of the printer drivers see the
Installation manual, SECTION 8: ADD-ON SOFTWARE: PRINTER DRIVERS.
41.5.7 Revision settings: further options
Revision label editable during the complete revisioning process

Project properties, Options tab: new option “Revision label editable during
the whole revisioning operation ”.
• Off (Default and at the same time Comos 7.0 procedure)
– PDF at first step is off:
The label can beonly changed in the last revision step (i.e. before the
release).
– PDF at first step is on:
The label cannot be changed.
• On
– PDF at first step is off:
The label can be set during the entire revision process.
– PDF at first step is on:
The label can be changed only before the first revision step (i.e. after
creation and before the first step, in which the PDF file is generated).
Revision is possible in checked out state

This revision option is only evaluated if Comos PQM is used, too. If the
option is enabled, then a document can be revisioned even if the document is
checked out.
For PQM see SECTION 66: PQM.
Generate PDF file in the first step

See SECTION 41.5.1.2: "PDF AT FIRST STEP".

Revisioning in working layers (no @Project) Revisions
Activate eSign
eSign is an independent module with many application options. One applica-
tion of eSign is signing revisions.
Select a revision step in the planning data. If an eSign signature was prepared
for this step and if the “Enable eSign” option is activated, then the “Signa-
ture” dialog box appears. The user logged in at present is entered automati-
cally; you only need to specify his eSign certificate (pfx file) and enter the
matching password.
Comos checks if the pfx file is a valid pfx signature file and whether the pass-
word matches the pfx file. The “Location” that was set during login is adopted
in the signature.
The eSign module is explained in the documentation F&D eSign.
The eSign signature is more than an optical change. Security information is
stored in the signature; with the help of the | CHECK SIGNATURES command on
the Revision tab, one can check if the document has been changed since set-
ting the signature.
It is not the signature that is checked, but whether the Comos document has
been manipulated since the last signature.
Of course, |CHECK SIGNATURE is only available for documents, not for groups.
41.6 Revisioning in working layers (no @Project)

It is technically possible to use working layers and to revise in these working
layers without using the @Project branch.
The following takes place:
The revisions are technically saved as objects (which are invisible in the Nav-
igator) below the original document, in the working layer. However, matching
the names of objects is a process that works across layers. The name of a revi-
sion is the identical to the displayed index.
So, if you try to create a revision with an index that already exists in another
working layer (or in the released area), then this is refused by Comos. An error
message pops up, informing the user that the revision cannot be created
because another revision with the same index already exists in another work-
ing layer or in the released area.
As you cannot set the index manually, in this case, this document can no
longer be revised. In other words: You can only revise in the working layer
with the highest index (in the top screenshot, this is working layer 5).

Revisions Release manager / Plant revision manager
The index cannot be set by hand, as the index number not only ensures the
uniqueness of the revisions, but is also a statement on the sequence of revi-
sions.
Because of that, project revision should always be used when working with
revisions in working layers. See SECTION 66: PQM.
41.7 Release manager / Plant revision manager
41.7.1 Background: Matching across layers
Plant revisions are matched across layers. (In project revisions, this is not
needed, since they are layer-specific.)
Technical background of plant revision

“Revisions” are more than just an entry on the Revision tab of a document.
From a technical point of view, revisions are independent objects, which,
however, are not visible in the Navigator. This applies for plant revisions as
well as for project revisions.
If both project revisions and plant revisions are used, then the latest project
revision is once again saved as “plant revision in stock”. Only this in-stock
plant revision is released during the release of the working layer, the project
revisions are omitted.
In addition, the Comos rule for unique indices applies for the in-stock plant
revision (or rather: the rule for unique names, since for revisions the index is
identical to the name). If an in-stock plant revision with a given index already
exists in one layer, then an in-stock plant revision of the same index cannot be
generated once again in another layer.
Whether these two plant revisions would have something to do with one
another with regard to content (provided one could create both), now is a com-
pany-specific viewpoint.
Basically, there is a reference: Both revisions deal with the same document
(which is in various working layers).
1. One could argue hat the various representations of the document must be
handled in the same way in different layers. In that case, it would not be
a problem if one could no longer create in-stock plant revisions in a layer.
With this view, the only thing that matters is that an in-stock plant revision
does exist - and that is the case.

Release manager / Plant revision manager Revisions
Another possibility would be, to release the layer in which the in-stock
plant revision exists first. Thus, the layer in which the document was
revised for the first time, must be released first.
However, this is document-dependent. For document A one layer can take
priority, and for document B a completely different layer can take priority.
But one layer must be released first.
2. The more frequent case is that the representations of the document in the
various working layers are considered as being different in content - and
accordingly, it does matter which plant revision “wins”.
In this case, a solution must be found before releasing the layers, allowing
you to decide which plant verision is to win.
Technically, in the latter case, only one in-stock plant revision can exist
per index. In the other layer, you cannot create any in-stock plant revision.
With the help of the Plant Revision Manager, it is then possible to discard
(delete) the in-stock plant revisions in the other working layer and
instead, to create another in-stock plant revision in this working
layerworking layer.
Controlling how plant revisions are handled during release

WOLevels base object, Sys tab: option group “Release of working layer”
• Only with all plant revisions

If the option is disabled, then Case 1 takes effect. The user must ensure that
the plant revisions he wants are covered by the release. If a document is
released without in-stock plant revision, then all revisions of this document
from this working layer are omitted.
If the option is enabled, then Case 2 takes effect. On releasing the layer,
Comos checks if an in-stock plant revision is missing. If yes, the working
layer cannot be released.
Please note: This option is only available in the “Release Manager” dialog
window if the “Automatic referencing of documents : @Project ” option
is activated in the project options.
• Do not release * revisions
This option is only indirectly linked to the above option. If this option is
activated, then Comos checks if there are any open revisions. This prevents
the user from forgetting to close a project revision and thus losing a plant
revision (since the last project revision affects the plant revision).
Corrections: The “Do not release * revisions” option is converted into a
dropdown menu. The following options will be available there:

Revisions Release manager / Plant revision manager
– Off (corresponds to the present status that “Do not release * revisions”
was disabled)
– Do notrelease * revisions (as until now)
Do not release unreleased revision
Includes the “Do not release * revisions” option.
In addition, revisions that were created with the “Revision at first step”
option, but for which the last revision step 99 (mostly: “Release”) was not
completed are withheld.
41.7.2 Operation
Comos menu,
| TOOLS | WORKING LAYERS/HISTORIES | RELEASE MANAGER: opens the Release
manager dialog:
The | PLANT REVISION MANAGER menu item is only visible when a working
layer is open.
Only with all plant revisions
This option is only visible when the following option is enabled: Project
Properties, Options tab, “Automatic referencing of documents”: @Project
group must not be set to Off.
Option enabled: If you click [UPDATE], the Plant Revision Manager lists doc-
uments that have project revisions, but no in-stock plant revisions.
Do not release * revisions
Option enabled: If you click [UPDATE], the Plant Revision Manager lists doc-
uments that have open project revisions.
These are the documents that have an asterisk revision in the Revision tab. It
is not checked whether an asterisk revision would be created if the documents
were evaluated.

Effect of revisions on reports Revisions
Mouse menu
| COMPLETE REVISIONS
The plant revision of the current layer is considered as valid and the “compet-
ing” plant revisions of the other layers are deleted (for the selection).
| DELETE REVISION
Self-explanatory.
41.8 Effect of revisions on reports
41.8.1 Revision monitoring in the Interactive report (Revision

rectangles)
If a report was revised and then more changes were made in the report, then
the changes in the report will be marked in the report using a revision rectan-
gle. The following applies:
• Grey: Changes in the last completed revision.
If a revision file is printed, then these revision rectangles are not printed.
• Green: Changes in the current, open revision.
These revision rectangles are printed when a revision file is created, unless
the settings are changed (see Printing revision rectangles, P. 41-31).
Changes that date back to the revision before last (or earlier) are not shown in
the report.
In the following example, you can see the green dashed line around the shutter
-K2M:
Only objects that also have a counterpart in the navigator are monitored in the
report. Pure report items – like a circle that you draw freehand on the report
– are not monitored.
The revision rectangles become effective only after the first revision. In short:
no revision rectangles are visible on new documents (because if there were,
everything would have to be marked, as everything is new).

Revisions Effect of revisions on reports
Revision rectangles without revision monitoring

If the AutoMarkAsChanged option is set, revision rectangles also appear on
the report without revision monitoring.
Printing revision rectangles

Options script of a report template: PrintRevisionRectangles
This option controls if revision rectangles are printed.
Please note: The Tiff printer driver can print only black and white, whereas
the revision rectangles are in color.
The Tiff printer driver must thus convert the color. Depending on the setting,
this can cause the revision rectangle to disappear and nothing is seen in the
revision file.
Therefore, the following settings are recommended for Interactive reports:
• 80% intensity.
• Floyd-Steinberg or Jarvis-Judice-Nike
These settings deliver the best results when displaying the revision rectangles.
For other Tiff printer driver settings, see SECTION 41.5.6.3.1: "TIFF" SETTINGS.
41.8.2 Revision table in the report (presentation)
The term "Revision table" was already used in connection with the Revision
tab. In addition to that, the term is also used to refer to a table displaying revi-
sion information on reports, especially on Interactive reports:
It is obvious that the two revision tables are closely linked, but are not identi-
cal. As a rule, the revision table on the report will reproduce only a subset of
information of the revision table from the Revisions tab.

41.8.3 Texts
Italics On-off
If texts of monitored objects have changed and the revision monitoring is
enabled, then the changed texts are shown in italics.
41.8.4 Evaluation of revision data in the report script
41.8.4.1 Overview through the DocHeader.dll

In the program code, the revision information is transferred to the DocHea-
der.dll library, from where it can be called.
In reports, this dll is already available through the predefined variable DocHdr
(this means, you need not code the line set DocHdr = CreateObject
(DocHeader...)):
Set RevObj = DocHdr.RevisionObject(Blatt, 1)
If Not RevObj Is Nothing Then
ErstDatum = RevObj.CS.Login
If Not RevObj.CS.User Is Nothing Then
Ersteller = RevObj.CS.User.Name
End If
End If
Provided at least one revision was already created, the CS object can be
accessed via RevisionObject. CS stands for "CreationStamp", i.e. the cre-
ation timestamp. Each document automatically receives a CreationStamp. In
the CS object, two pieces of information are stored: Login, that of the actual
timestamp, and User, this is the user logged into the database.
The following functions are available in the DocHeader.DLL for the revision
table:
RevisionTableIndex(<RevLine>)
RevisionTableDescription(<RevLine>)
RevisionTableDate(<RevLine>;<RevColumnNr>)
RevisionTableUser(<RevLine>;<RevColumnNr>)
<RevLine> Stands for the table row number.

<RevColumnNr> Stands for the table column number (created,
inspected, released).

Revisions Effect of revisions on reports
<RevColumnNr> Is optional – if not specified, the last column (99) is

accepted.
The "Document(As Object)" and "RevisionTable-Length(AsLong)"

properties must be set before. The "RevisionTable-Length" property is
used to determine how many rows the revision table should display.
In addition, the "DocumentGroup(As Object)" property can be set to query
the document group table.
Suppressing open revisions during output in the report

If a new revision is created, then an “Asterisk revision” appears in the revision
table in the properties window of a document.
Use the following expression in the options script of the crp template file, and
the "asterisk" revision is not displayed in the revision table of the report:
DocHdr. RevisionTableWithoutStarRevision = True
41.8.4.2 Generating MaxRevisionIndexOf / Revision index
Old technique
RevisionIndex, RevisionLabel
These two functions cannot correctly evaluate the objects that are checked
with content comparison. If you evaluate revision data in the report and use
"Content (text)" as comparison basis, then these two functions must be
replaced by MaxRevisionIndexOf.
Function scope of MaxRevisionIndexOf

Objects can be queried to check whether they belong to a revision:
• Open revision; object changed
An asterisk is displayed (= affiliation to the current open revision).
• Open revision; object changed; then revision released
The objects are assigned to the last completed revision.
• Only closed revisions available; object changed
An asterisk is displayed (= affiliation to a revision still to be opened).

Creating MaxRevisionIndexOf with the "Generate revision index" command

If you select a text in the report template, then the | CREATE REVISION INDEX
mouse menu is now available.
This command creates a new Script type of text field. The following row is
created in the script:
Text = MaxRevisionIndexOf ("Text1")
"Text1" is the name of the text for which the mouse command was called. If
the name of the reference text is changed later (e.g. with the | RE-ESTABLISH
UNIQUENESS OF NAMES function), then this text row must be adjusted, too.
The MaxRevisionIndexOf text field must be directly on the left of the text
field to which it refers. If not, then you see a red line, which stretches from
MaxRevisionIndexOf to the text field with the matching name.
Please note: The MaxRevisionIndexOf function was already available in ear-

lier versions through script. The new feature here is that this function is avail-
able with the right mouse button. If the MaxRevisionIndexOf function was
already used before, without placing the corresponding text field on the left
next to the reference text, then this old data is now marked with the red line,
too.
In lists, you can use the revision index by taking an object query and generat-
ing a column with MaxRevisionIndexOf.
Determining revision index

Checkboxes can be placed on reports. If you click such a checkbox, this trig-
gers a change event and the report is considered as changed from the revision
point of view. The MaxRevisionIndexOf function considers these check-
boxes on reports.
41.8.4.3 Checking manual details on user and date

During the revision process, the date is assigned to the Revision step label
in the default setting and the user to the Revision step description .
Alternatively, the user can manually enter a label and a description for the
revision step.
In the latter case, if you have entered a date in the label and a user name in the
description manually, it might seem as if the date and user stamp were auto-
matically entered (pointer on date and user).
Use a script to check whether date and user were entered by the system or an
entry was made manually and only looks likes a system entry:

Revisions Rights administration for revisions
OwnLabel and OwnDescription at blank check OwnLabel <> "".
41.8.4.4 Functions for "Revisioning"

In the Comos Kernel documentation, you will find various useful functions
when you search for the keyword "Revision".
41.8.5 Miscellaneous
Safety query during revisioning

During the revisoning process, the documents must be first evaluated. This
necessitates write rights for all documents to be revised. In short: None of the
documents must have been opened by another user with write right before or
in between.
If that indeed happened, then an appropriate response is displayed in the
object list (also called "info list"). The revisioning process is cancelled, i.e. is
not carried out for any of the documents.
Checkboxes
Checkboxes too can be placed on reports. If you click such a checkbox, this
triggers a change event and the report is considered as changed from the revi-
sion point of view.
41.9 Rights administration for revisions

There are three object rights that are important for revisions: "Create revi-
sion", "Check revision" and "Release revision".
The easiest way to establish a rights administration for revisions is by giving
these rights to a user for a specific branch. The user’s rights then also apply to
the documents located in this branch.

Revision tab/ Revision table Revisions
In the following example, a user has the following rights to the "T1" plant:
These rights also apply to all documents located below the "T1" plant (only
original documents, not reference documents) – as long as nothing else is set
in the lower levels. In our example, the user can generate a new revision and
carry out the test steps, but may not carry out the final release.
Please note: To be able to edit revision step label and revision step descrip-
tion, you now need revisioning rights.
41.10 Revision tab/ Revision table

The "Revision table" term originated because the revision information is
shown in the form of a table in the Comos interface:
In this view, a revision table is the list of all revisions created for this object.
Technically, though, the revision information is not saved in the form of a
table, but with the help of objects. Each row in the revision table represents
many objects. The individual columns mean:

Revisions The first revision/ opening a report for the first time
• Index
SECTION 41.4: THE "INDEX" OF A REVISION
• Label, Description
These columns control an invisible "Revision carrier".
SECTION 41.1.2.1: THE "REVISION CARRIER".
• Created by, Inspected by, Released by (Text can vary)

These columns represent the individual revision steps. Number and names
of the revision steps are defined by the "Revision elements".
SECTION 41.1.2.2: THE REVISION ELEMENTS / REVISION STEPS.
• Revision archive
The "Revision archive" is a print file in Tiff or PDF format. In a document
group, the "Revision archive " column is always blank, as the archived files
are only saved for the individual documents.
SECTION 41.5.6: REVISION SETTINGS: REVISION ARCHIVE (PRINTER DRIVER).
Carrying out revision

See Quickstart Basic, chapter Revisions.
41.11 The first revision/ opening a report for the first

time
A revision is used to distinguish between and to document processing states.
Subsequently, a revision is more than simply printing a document and more
than simply archiving it: A revision must also make differences visible.
Differences presuppose that there is something to compare. The first revision
has no preceding revision. Therefore, the first revision is the revision that is
"somewhat different" than all other revisions.
The following examples require that the Revision monitoring project option
is enabled, i.e. it is set to (1) or (2).
• Document without external files
These are mainly evaluation reports. After being opened for the first time,
these reports automatically get an * revision even if the report was empty.
But in comparison to “nothing”, even “empty” is a change.
• Documents with external files
If these documents are opened for the first time, then Comos expects you to
save them. Even if nothing was changed. This operation is no longer
required the next time you open the documents.
The reason for this is, that the external file is generated only at the time of

Programming notes Revisions
opening it for the first time and thus must be saved. If you don’t save the
document at this point, then the external file is not (yet) available.
After saving the document for the first time, it gets an * revision, even if the
document was not modified in any way.
• Group revisions
Properties of the document group, System data tab: the "Revision of all
documents " option is disabled.
During the first group revision, all documents participate in the revision
although they were not changed. Unchanged documents are excluded only
during the subsequent group revisions, as required by the option.
• Package revisions
Before the first package revision, all documents in the package must be
opened and saved once (even if there are no changes). If revisioning is
carried out for the first time and without opening and saving the documents,
then, depending on the circumstances (project options, document types
used), it can happen that a new * revision is automatically opened directly
after creating the revision.
Switching between the general revision methods

If you are switching between the "Timestamp" and "Content (text)" revision
methods, then the first revision is not consistent after the switch. See
SECTION 41.5.5: SWITCHING BETWEEN CONTENT COMPARISON AND TIMESTAMP COMPARI-
SON.
41.12 Programming notes

Evaluating revision data in the report
See SECTION 41.8.4: EVALUATION OF REVISION DATA IN THE REPORT SCRIPT.
Controlling revisions
• CDevice @Revision, Scriptblock OnRevisionRelease
Fired: When revision is released. The Script is located at the base object of
the revision.
Script help (Question mark icon on the top right of the Script Editor): In the
Script help, you will find the following examples on the Examples tab:
– Copy the last released revision file to the TMP folder and open it there.
– Find out about the user from the last checked-in element
• Elements of a revision, Scriptblock OnRevision
Fired: When revision step is executed.

Revisions Data synchronization/ Updating
RevisionMaster.dll
RevMode property at RevisionInfo. Here you define which revision informa-
tion to return.
1 = Project revision (Default) [this refers to @Project]
Here, this refers to the layer.
0 = Plant revision [this refers to @NameSystem]
Here, this refers to the released area.
Using this property, you can also specify for reports which revision informa-
tion is to be displayed.
IsRevisionAllowed (document)
Only for the Document class and the Document group class. Specifies
whether the next revision step is allowed.
41.13 Data synchronization/ Updating
41.13.1 Data synchronization between open interfaces

Normally, Comos always synchronizes the data of all open windows. If an
object description is changed and saved in an object query, then this change
becomes immediately visible in any open property window of the object.
For technical reasons, this data synchronization works only partially with
revision information.
If a report is open and simultaneously the property window of this document
is open, this causes update problems in both directions.
Example
If you were working in the open report, so that as consequence the “created”
revision step was reset, then the open properties window would only be par-
tially updated: for example, the Revision commands icon would not be up
to date.
If you continued to work, this would lead to subsequent errors. The properties
window is updated after closing and reopening it.
Obviously, there are no errors with a pure read access. But if you are to work
with the revision data or the revisions, then a user may only open either the
report or the properties window of the report. But not both together.

Checklist Revisions
41.13.2 Updating reports
For technical reasons and for performance reasons, not all components of a
software are actually up-to-date at the same time. That is why, even in the
Microsoft Explorer, you have the "Refresh" function.
Comos strikes a balance here. All important information is refreshed automat-
ically. The somewhat less important information must be updated manually
in case of doubt.
In connection with revisions, this applies to the "Revision bar", for example.
The Revision bar is a table in the report with details on the last revisions. This
table is not automatically updated each time the revision information changes.
If you would like to ensure that the report is up-to-date (e.g. because you need
a valid printout), then press the [EVALUATE] icon.
For more detailed information on this topic, please ask innotec for the
"Updating revision data " working paper.
41.14 Checklist
1. Existence of the Revision tab
1.1 Document
Base object must have Revision type .
(The "Revision type " field must not be set to "None ".)
1.2 Document group
Naming convention must be fulfilled.
Base object of document group must have Revision type .
(The "Revision type " field must not be set to "None ".)
2. Display the Revision tab
As soon as a Revision tab is activated (selected and thus moved to the
front), the followingis verified:
2.1 Evaluate "Revision type ":
The base object is searched in the base data project, and determined
by the revision type.
2.2 Under this base object, all Elements (e.g. Created, Inspected,
Released) must be set to Virtaul : 1 times ;
2.3 The element names must consist of numbers smaller than 99.
2.4 The number of the last element from the revision carrier must be
"99".

Revisions Checklist
If any of these requirements are not met, then a warning message is

displayed.
Documents: if the document is referenced both in the @NameSystem and
the @Project document group branch, the two option fields for the
project/plant revision are displayed.
3. Generating the revision ("Generate")
An asterisk revision is generated manually, i.e. a Comos object is created
that "carries" the revision. No revision element is checked in. This object
is invisible in the Navigator.
Document group: Additional check on whether all included documents
have the same resvision CDevice as the document group.
Document group: A group must not remain in "Create" status. Therefore,
for a document group, the first revision step is carried out automatically
(mostly: "Create").
Revision monitoring: By activating an option, the asterisk revision can be
automatically created by the revision monitoring.
4. The first revision step "Create "
The first element must be checked in; the relevant comparison point must
be set. But since the Comos object for the revision already exists, the
CreationStamp is "outdated". To ensure that the Comos object always has
a current CS:
4.1 The object of the "open" revision must be deleted.
4.2 A new revision object must be generated
4.3 The revision step is carried out (the first revision element is checked
inh)
4.4 The label is checked for uniqueness
– In "PDF file at first step ": The print setting of the PDF printer is
checked. If there is no problem: The PDF revision file is printed.
– Project/Plant revision: If not yet available, an asterisk revision is
generated for the plant revision.
5. All intermediate revision steps
The stamps (revision elements) are checked in. Their number is based on
the defaults of the revision base object. Each revision step gets a
description and a label. The labels are checked for uniqueness.
Otherwise, no monitoring takes place.

Storage of revision files Revisions
6. Last revision step (Name: 99):

The last element is checked in; the relevant comparison time is set.
Revision monitoring: By activating an option, the release can be
monitored by the revision monitoring.
If changes are detected, then all revisions steps carried out until now will
be deleted (the revision elements disappear), and no print process takes
place. The revisioning must be restarted, beginning with the first revision
step "Create".
In addition, the label is checked for uniqueness.
In end print ("PDF file at first step " disabled): If all prerequisites for the
release are met, then search for the currently selected revision printer
(Project options: "Revision archive ") and check the print settings.
Provided that the printer is found and the settings are correct, a TIFF or a
PDF file is generated.
41.15 Storage of revision files

A separate document folder is created for each project in the database folder.
Below a project branch there is a Revisions folder, in which all revision files
are created.
If you are working with working layers, then the corresponding intermediate
levels are available, but at the last node of the hierarchy tree you will again
find a Revisions folder.

Languages (localization) General
42 Languages (localization)
42.1 General
42.1.1 Language areas in Comos
42.1.1.1 The program interface (interface language)
Scope
• The interface of Comos itself (menubar, Comos status bar, etc.)
• The interfaces of all the dialog windows (but not always the contents, see
below)
• The informatory notes or warnings
• The tooltips (the small yellow memo-like notes that appear when the mouse
“hovers” above a point).
• The PDF help (if there are help files in this language).
See SECTION 42.2: INTERFACE LANGUAGE.
Application
It is not possible to translate the interface itself into another language or to
change the existing entries.
42.1.1.2 The database (project language)

This concerns objects in the database. Virtually all the texts that had been
input by a user can be translated:
• Descriptions (Description, Description2, Description3), see also
SECTION 42.1.3: TECHNICAL BACKGROUND.
• Attribute values (Value, XValue)

• Fixed report texts
• Column headings for queries
• Help texts and tooltip texts of the attributes
• List fields and memo fields

General Languages (localization)
In principle, names and labels are excluded from translation. Names must be
unique at all times and also remain exactly the same over the course of time,
since objects are identified with the aid of the names. Labels are used for
labelling systems and must therefore remain exactly the same over the course
of time.
Nonetheless, it is possible to set a system of alias labels within the labels and
thus to cover the requirements for another language.
All texts are switched over within the Navigator; in addition, the object texts
are of course shown in the selected other language in all the dialog windows
as well. Thus when you display objects in the Bulk processing dialog win-
dow, the texts of these objects are displayed in the set project language within
the dialog window. See SECTION 42.3.1: SWITCHING LANGUAGES / LANGUAGE MANAGE-
MENT.
Application
There are a number of different options to translate the project data itself into
other languages or to convert existing entries. See SECTION 42.4: TRANSLATION OF
PROJECT DATA.
42.1.1.3 Template files

As a rule, a report is made up of at least two constituent parts: the information
that had been taken from the database and the information that is entered in
fixed form in the template file (crp file).
Scope
Selection of a template file in accordance with the selected project language.
Application
See SECTION 42.5: LANGUAGE-DEPENDENT SELECTION OF TEMPLATE FILES.
42.1.2 Combination of language areas
Areas can be combined as desired, but normally all participants would choose
to work in the same language.
The selected settings relate to the relevant workstation, i.e., another worksta-
tion with different settings can work in parallel on the same project. This is
not surprising as far as the interface goes, but each workstation can also
choose a separate and different language for the project language; and this

Languages (localization) Interface language
even if there is common access to the data. This property of Comos makes it
possible for multinational participants to work together on joint projects (Glo-
bal Engineering) in their own respective languages.
42.1.3 Technical background
The Description fields are managed internally as a “Memo field”. The length
of this text fields thus depends on how long a memo field is in the type of data-
base being used.
If you work with different languages within Comos, then all the texts of the
various languages are stored invisibly in the same field. Although the transla-
tions are invisible (until you change the language), the translation nonetheless
does of course take up a part of the field length. By using type Memo it is also
possible to translate very long texts into various languages without exceeding
the maximum permissible text length.
42.2 Interface language

Click | FILE | LANGUAGES:
The language of the interface in Comos can be changed while the program is
running. However, all open documents and Properties windows are closed.
If the switch to the other language is not carried out completely, then you have
to close Comos and open it again; this updates everything completely.
42.3 Project languages
42.3.1 Switching languages / language management
The contents of the database can be set to any language that can be displayed
under Windows NT as long as the languages have been set up in the relevant
project and the corresponding translations exist in the database.
42.3.1.1 Language management (Languages tab)

Language management is opened by:
| PROJECT PROPERTIES,
Languages tab, options field: Support languages .

Project languages Languages (localization)
In this example a number of different languages have already been set up.
Rights administration
You can only work on the Languages tab if you have the “Write ” object
right and the “Project options ” function right for the project. If either of
these rights is missing, then everything up to the switching of the User cur-
rent language is turned off.
User current This allows the setting for the DB current option to be
overruled for this session. If Comos is closed and opened
again, then the default setting of the DB current option
takes effect again.
DB current All workstations see the database texts of this project in
the selected language.
Primary The primary language is the language in which input
language takes priority over input from all other languages. If an
entry in the primary language is changed, then all previ-
ous translations of this entry into other languages are
regarded as invalid. See The primary language, P. 42-7.
Country code Languages are often identified by a country code. How-
ever, the input is not evaluated internally but is made
freely available to the customer. The Country code col-
umn only permits numeric input, while Comos of course
strips off any leading (padding) zeroes.
Country code 7 is reserved: It is used to manage the var-
ious languages that use Cyrillic characters. See below for
further details.
Description A freely selectable text to describe the input.

Languages (localization) Project languages
Decimal The decimal separator separates the whole part of the

delimiter number from the decimal fraction. In Germany the
decimal separator is a comma, thus 1,1 m = 1 m and 10
centimeters. In British and American usage the decimal
separator is a period (full stop), thus 1.1 m = 1 m and 10
centimeters. Any desired character can be input here and
used instead.
Group The group separator is used for the typographical
delimiter sub-division of numbers. In Germany this is a space as a
rule, sometimes also a period (full stop), thus resulting in
100 000 m or 100.000 m. In British and American usage
this is a comma, thus resulting in 100,000 m. Any desired
character can be input here and used instead.
42.3.1.2 Mouse-menus on the Languages tab
Current database Sets the DB current option to the language shown

language in the line.
Current interface Sets the User current option to the language
language shown in the line. Thus the setting for the DB cur-
rent option can be overruled for this session. If
Comos is closed and opened again, then the default
setting of the DB current option takes effect again.
Primary language The primary language is the language in which
input takes priority over input from all other lan-
guages. If an entry in the primary language is
changed, then all previous translations of this entry
into other languages are regarded as invalid.
[Default entries] New, Copy, Paste, Cut, Delete,

| NEW
When a new language is set up with | NEW, then the
following entry is offered for the country code:
highest previous number +1.
If no Description had been input, the following is
input automatically as the setting:
“Language<Country code> ”.
Country code 7 is reserved: It is used to manage the
various languages that use Cyrillic characters. See
below for further details.
| DELETE
Entries in the language management should in gen-
eral not be deleted. See below for further explana-
tions.
Accept settings from The previous entries are deleted after a yes/no
base project prompt and the languages that had been defined in
the base project are offered.
Translation Opens a small dialog window with which you can
translate the Description of this entry into the
other languages that had already been set up.
Properties Opens the Properties window of the management
unit of the language. In principle, all fields can be
changed that were also available when the entry
was created with | NEW.
Accepting languages from the base project

Please note: The language management of the base project should
always be taken over in a planning project.
Then right-click in the dialog window and select | ACCEPT SETTINGS FROM BASE
PROJECT.
Reason: In Comos the order in which the languages were originally set up (not
the order of the country codes, but in actual fact the order of the entries them-
selves) is important: the translations are arranged one after another in this
order.

Languages (localization) Project languages
Thus if English was in the second position, then the English texts (transla-
tions) will also be physically written in the second position in the database.
This sequence of the translated texts does not change later, not even if the
order of the entries is changed in the language management. If the order of the
languages in the language management is to decide the sequence, then the lan-
guages will be mixed up. Example:
The following order had been set in the base project:
1. German 2. English 3. French.
The following order had been set in the planning project:
1. German 2. French 3. English
If you now switch over to English in the planning project, then all the transla-
tions from position 2 are read and displayed – and they are in French for the
data from the base project. You thus see all the entries in French on the Base
data tab.
Tip: As long as no new texts have been translated, you can still correct any
management entries that had been input incorrectly. To do this, you can also
use the | ACCEPT SETTINGS FROM BASE DATA command, since language entries
that had been created manually in the planning project can be deleted with this
function. However, if texts have already been translated, you are not permit-
ted to change the management entries of the languages any further.
Setting up languages
Right-click in the dialog window and select | NEW.
When a new language is set up with | NEW, then the following entry is offered
for the country code: highest previous number +1.
If no Description had been input, at times the following is input automati-
cally as the setting: “Language<Country code> ”.
Country code 7 is reserved: It is used to manage the various languages that use
Cyrillic characters. See below for further details.
You can change the country code at any time.
The primary language

The primary language is the language in which input takes priority over input
from all other languages. If an entry in the primary language is changed, then
all previous translations of this entry into other languages are regarded as
invalid.
You can revise at any time the translations of a specific language (that is not
the primary language) and all the other translations remain valid.

However, if you change the entry of the primary language, the other transla-
tions can no longer be valid, since the initial text to be translated has changed.
Please note that any change in the primary language – and this also includes
minor grammatical or spelling corrections – leads to all the other translations
of this text (but not of all texts) being marked as invalid. The invalid texts are
not displayed any longer, but instead the new input of the primary language is
displayed. In other words: You will then see the entries of the primary lan-
guage in another language, if the primary entry has not been changed or trans-
lated yet.
Example: Primary language: German. Other languages: English, French
Entry in German: “Dies ist Deutsch.”
Entry in English: “This is English.”
Entry in French: <blank>
The entry in German is changed to: “Dies ist Neu-Deutsch.”
Effect:
English: The entry in the primary language is displayed. In other words: If
English has been set in the project properties, in the example given you will
see the new German text: “Dies ist Neu-Deutsch.”
French: A question mark (?) and the entry of the primary language are dis-
played: “? Dies ist Neu-Deutsch.”
Cyrillic characters
Comos can also display Cyrillic characters. An entry with country code 7
must be input in the project properties on the Languages tab to do this. Coun-
try code 7 is mandatory, but the description of the language can be anything
you want.
Please note that you will most likely have to install a special keyboard driver
and also change over the active language of the PC.
Please note that this functionality only support the input of Cyrillic characters.
It is not possible to convert to or from Cyrillic characters for existing texts.
Deleting languages
Entries in the language management should in general not be deleted.
Reason: In Comos the order in which the languages were originally set up (not
the order of the country codes, but in actual fact the order of the entries them-
selves) is important: the translations are arranged one after another in this
order.

Languages (localization) Translation of project data
Thus if English was in the second position, then the English texts (transla-
tions) will also be physically written in the second position in the database.
This sequence of the translated texts does not change later, not even if the
order of the entries is changed in the language management, nor if a language
is deleted.
As long as the Properties window of the project has not been closed yet, you
can create new entries and delete them again at once without any risk. But the
entry may no longer be deleted once you have confirmed the window with the
data.
42.4 Translation of project data
42.4.1 Translating attributes
The translation of attribute values, lists and memo fields is very simple in
principle: Simply switch to the corresponding language and input the requisite
texts.
42.4.1.1 Procedure:
The Text entry must be selected from the General tab in the Type field for
the attributes.
• Select a language from the project properties.
• Input the desired information.
• If you change the current language, and if there is no entry yet for the chosen
language, then a question mark (?) and the entry of the primary language are
displayed:
“?Dies ist ein deutscher Text.”
• This untranslated text of the primary language that is displayed serves as a
translation aid. But from a technical point of view it is not essential to input
an exact translation in the other (foreign) language.
Mark the placeholder text “Dies...” and overwrite it with a new entry.
• If you change the entry of the primary language, the entries of all the other
languages become invalid and are deleted.
If you do not wish to translate memo fields, lists or attributes, you can change
over the type to Alphanumeric on the General tab. This type is not affected
by the language management and therefore displays the same entry for all lan-
guages.

Translation of project data Languages (localization)
42.4.1.2 Technical background

Fundamentally speaking, this procedure functions for all attributes that pos-
sess a Value or an XValue and for which the type can be set to Text.
The entries for the various languages are written one after another in a data
field, separated internally by a space. Depending on the project language, the
correct constituent part is read and displayed from this character string.
However, it does not always make sense to select type Text. The attribute
Edit (Min Value Max) has its own range check, in which values are com-
pared. If this was changed here to Text (which is possible, from a technical
point of view), then the values would be compared on an alphanumeric basis
– which is very seldom meaningful. (For example, 2 is greater than10).
In other words: the attribute Edit (Min Value Max) could be used in the
translation process, technically speaking, but as a rule it would not make any
sense.
Another example is the attribute File selection . This attribute is used to
make an external file available. Since the path to the external file is saved as
Value , you could give another path for each language. But please note that in
this case you may not change the file entry for the primary language, since this
would result in all the entries of all the other languages being deleted.
42.4.2 Translate “description” (object language translation)
This dialog window allows the translation of the description of indi-

vidual objects by the user while the program is running.
Mark an object and select | EXTRA | LANGUAGE TRANSLATION| OBJECT LAN-
GUAGE TRANSLATION from the menu bar:

The dialog window is initially blank. The languages are displayed in the
above window in the same way that they had been input in the Properties win-
dow of the project on the Languages tab (see SECTION 42.3.1: SWITCHING LAN-
GUAGES / LANGUAGE MANAGEMENT). The current language (User current ) is
shown bolded. That is German in the above example.
The project is always the first item displayed in the dialog window. Drag an
object into the dialog window with the mouse.
Pic. 42-1: The language translation object after an object had been set
You can also enter several words in the field, separated by spaces (as above).
Spaces at the end of the entry are trimmed off when you confirm the input.
Please note: An “object” does not necessarily need to be only a “device”; thus
attributes or documents are also objects, for example. With all of these you
can input and translate a description.
The object is now made available in translated form in the other languages.
Incorrect entries can also be edited in this way.
42.4.2.2 Editing multiple objects one after another

A larger number of objects can be translated quickly by using drag & drop.
Use the mouse to drag a new object to the Language translation object dialog
window and fill in the fields. Drag another object into the dialog window, but
without pressing the [OK] button. Confirm with [OK] once all the entries have
been completed.
42.4.2.3 Relationship between base objects and planning objects

Please note: Normally, objects inherit the description of the base object. This
also applies to translations of the description. If you have changed the trans-
lation in a planning object with this tool, then the connection to the description
of the underlying base object is lost.
In other words: If a planning object was edited with the above tool, then edit-
ing the translation with respect to the underlying base object will no longer
have any effect on this planning object.

For technical reasons this applies to all translations of the object together. If
you change the English description for a planning object, then all the lan-
guages of this object are checked in, also German, French, etc.
This has a bad effect visually: Only those translations that had been input
manually are valid from now on. In the following example there are four lan-
guages, all with inherited texts:
If you now input a translation in a language, then all inheritances for this
object from the base object are deleted and you will see blank fields in all the
other languages:
This effect has a technical reason and cannot be avoided.

Fundamentally speaking, texts should be translated where they were
created in the original! This means as a rule in the base data, and not
in inherited fields there either, but in the base object in which an attribute, etc.,
had been created.
42.4.3 Translation of multiple objects
This function simultaneously translates the description for several

planning objects, even when the program is running. The tool is based
on an object query.

If the corresponding object query had been created in base data branch
@System -| @O -| @Trans , then the query and not the old dialog window
is opened when the Extra | Translation | Multiple Objects menu command
is used.
This query collects together all the texts to be translated under Comos:
• descriptions (Description, Description2, Description3)
• attribute values (Value, XValue)
• fixed report texts
• column headers of queries
• help texts and tooltip texts of attributes
The prerequisite for the correct use of the new query is the input of the local
ID (Language.LCID) for Comos languages.
See SECTION 24: OBJECT BROWSER regarding the basic functions of an object
query.
Select | EXTRA | TRANSLATION| MULTIPLE OBJECTS from the menu bar:
Columns
Object type : Here is the system type of the object that was found.
Object : Supplies the FullLabel of the object.
Property : This shows which property of the object is being translated.
Sub-object / Addit. key : Many structures in Comos are multi-level and
require an additional key to be able to call up all the required information.
Example: range attributes. The extended values of the range attributes must
be called up via an “index”. This index is held in the Addit. key column.

Search technique
Only first level

Only objects of the first subordinated hierarchical level are displayed.
Recursive
Objects of all the subordinated hierarchical levels are displayed.
You are given the following selection when you open the objects types
drop-down field:
Editing multiple entries simultaneously

You can make a multiple selection from the results list with the aid of the
<Ctrl> key and the mouse together. Input a new text in one of the Language
fields and confirm with [Appy ]. All the marked objects are now given this text.
If you have marked objects in the list that previously had a different text, the
Language entry fields are greyed out but can still be edited as usual.
Relationship between base objects and planning objects

The inheritance mechanism takes effect with this tool as well, see
SECTION 42.4.2.3: RELATIONSHIP BETWEEN BASE OBJECTS AND PLANNING OBJECTS.

42.4.4 Translation of ComosDB
This function exports all descriptions and all attributes of type Text to
Access 2000. There the translation is carried out, which can then be
reimported with this function.
You can only use this tool if Access 2000 is installed on the same PC.
42.4.4.1 Interface of the dialog window

Select | EXTRA | TRANSLATION| PROJECT.. on the menu bar:
The following functions are available here:

[SHOW DATA] Opens an Access 2000 mdb and opens there a table
with a translated project and displays the data. No
import operation is carried out.
You can only view that data that also belongs to the
current project.
The database from which you wish to view data may
not be opened within Access. Otherwise no tables
would be offered for selection for security reasons.
[NAVIGATE] Both objects that can be displayed within the Naviga-
tor (planning or base objects, etc.) as well as objects
that do not appear within the Navigator (standard
tables) appear in the table. The [NAVIGATE] command
only functions for objects that can be displayed in the
Navigator.
Mark a line (= an object) in the list. If you now execute
this command, the marked object is displayed at the
left in the Navigator.

[EXPORT] Exports the contents of a project into an Access 2000

database. This is done by creating within the database
a table with the name of the project to be exported.
Multiple projects can be exported into a database,
which is then made available with the corresponding
names. A yes/no safety prompt appears if a database
that already exists was selected and if there is already
a table of the same name.
You can create a new database simply by entering a
new name. The ending mdb is appended automatically.
Please note: An export operation is very time-consum-
ing. An export operation can take up to several hours
in the case of large projects.
Please note: An export operation generates large vol-
umes of transferred data on a network. We recom-
mend that you carry out export operations at times
when the network is not loaded heavily.
[IMPORT] Imports a project from an Access 2000 database. The
imported project must match the current project that
has been opened, otherwise you are given a warning
message and the import operation is not initiated.
The cursor keys [|<][<] and [>][>|] near the Navigate field in the table make
it possible to jump to the beginning or end of the table or to move line by line.
42.4.4.2 Carrying out an export operation

Open the project that you wish to export to Access. It is not possible to export
from one project into another project.
Scope of exporting
Fundamentally speaking, only information that belongs to the current project
is exported. Thus if a planning project is exported, the objects of the Base
data tab are not exported unless you have created local base objects, which
are of course exported.
The same applies to the standard tables. When the base project is exported,
then only those standard tables that had also been created in the base project
are exported; many central lists are located within the system project.

Somewhat less obvious is this relationship in the case of planning objects.

When a planning object is created, the planning object inherits information
from the base object. If the planning object is edited manually, this informa-
tion is checked in and now belongs to the planning project. This also applies
here to information that is of interest in connection with the translation: the
Text and Value fields.
In other words: As long as the text or description had not been changed in the
case of a planning object or if a text had been input for an attribute, the objects
do not appear in the data that is exported.
The following information appears in the exported data (if it has been checked
in):
Base and planning • Description

objects The text from the Description field of the
Properties window.
Attributes • Description
The text from the Description field of the
Properties window
• Value
The input in the Value field in the case of an
attribute of type Text .
• Lists and memo fields:
Description
Properties window
Description
columns
The values (inputs) are not exported and are
processed directly in Comos. See SECTION 42.4.1:
TRANSLATING ATTRIBUTES.

Standard tables • Description

Properties window of the standard table itself
• Description
The text from the Description field of the entry
in a standard table
The values (inputs) in an entry of a standard table
are not exported
Application
Mouse-click on [EXPORT] and select a database or else create a new database.
You can create a new database simply by entering a new name. The ending
mdb is appended automatically.
Confirm in the dialog window regarding the number of languages.

Confirm in the dialog window at the beginning of the export operation:
Pic. 42-2: The export operation begins as soon as you have confirmed this message
Please note: An export operation is very time-consuming. An export
operation can take up to several hours in the case of large projects.
Please note: An export operation generates large volumes of trans-
ferred data on a network. We recommend that you carry out export
operations at times when the network is not loaded heavily.
The status of the export operation is displayed in the dialog window:
Pic. 42-3: Progress bar for the export

You are given a confirmation when the export operation has been completed.
After an export operation has been concluded, a table appears on the screen
and allows you to check the data records.

Minor changes can now be made directly in this table. When you close the
dialog window with [EXIT], the changes that had been made are saved in the
Access 2000 table that had been created as part of the export operation.
The table is set up as follows:
OBJ Name The name of the object.

BWX A detail that indicates what kind of text to be translated is
in this line. Currently the following details are shown:
• Description
A text from the Description field of a Properties
window
• Value
An input for an attribute of type Text .
[Multiple A column appears for each language that had been
columns] created in the project properties.
Larger changes should be made at the Access level in the interests of effi-
ciency.
The table in Access is set up as follows:
TAB_NAME Internal information, do not change. This is the name

of the table in which this information is stored within
Comos.
PRO_UID Internal information, do not change. This is the
unique identification key of the object.
OBJ_UID Internal information, do not change. This is the
unique identification key of the object.
OBJ_NAME Internal information, do not change. The name of the
object.

BWX Internal information, do not change. A detail that indi-

cates what kind of text to be translated is in this line.
Currently the following details are shown:
• Description
A text from the Description field of a Properties
window
• Value
An input for an attribute of type Text .
CASEVALUES Internal information, do not change.
CASEXVALUES Internal information, do not change.
COLLISION Internal information, do not change. Here is stored
the information as to whether there are any
inconsistencies between the source and the target.
ORIGINAL Internal information, do not change.
CHANGED Internal information, do not change.
[Multiple Input your translations in these columns.
columns,
depending on the
number of
languages]
42.4.4.3 Carrying out an import operation

[IMPORT] writes the data back into the Comos database.
In the table of the Translation of ComosDB dialog window there now
appear in addition to the columns that have already been described above
three new ones: Collision , Original , Changed.
Please note: An import operation is very time-consuming; even
more time-consuming than an export operation. An import opera-
tion can take up to several hours even in the case of medium-sized
projects.
Please note: An import operation generates large volumes of trans-
ferred data on a network. We recommend that you carry out export
operations at times when the network is not loaded heavily.

Languages (localization) Language-dependent selection of template files
A “YES” in the Collision column indicates a problem when writing back the
object. The description of this object has changed in the time between export-
ing and importing.
The description was “OO rotary button” at the time of the export, but in the
meantime it had been changed to “Rotary switch”. In order to reduce the risk
of false entries in the database at this point, the Comos data of this object is
not changed, but the changed description is displayed in the Changed field,
however.
“No” means that there were no problems and that the translated text for this
object was entered in the Comos database. The translations are now available
to Comos.
The Original column contains the description texts of the database objects at
the time of the export operation, and the Changed column has the descrip-
tions of the database objects whose designation had changed between the
times of exporting and importing and thus caused a data collision.
However, you can still make minor corrections now in the dialog window.
42.5 Language-dependent selection of template files

As a rule, a report is made up of at least two constituent parts: the information
that had been taken from the database and the information that is given in
fixed form in the template file (crp file).
If both the interface and the language of the database are switched over, then,
for example, an Evaluation Report can nonetheless include elements from
other languages that originated from the template file.
In Comos there is now the option to use another template file that depends on
the selected project language.
The language-dependent selection of template files is currently supported for
Evaluation Reports and Interactive Reports.
Creating the crp files

If you wish to set up the template files so that they are language-dependent,
you must first create template files in the various languages. This step is
unavoidable, since the template files contain fixed texts, and by definition
fixed texts cannot be changed by the software.
Example: An Evaluation Report has the name ar_an1_terminals.crp.
You create an additional template file for English within the Report Manager.

Exclusions Languages (localization)
In order for Comos to be able to find the various template files, create them
all within one and the same directory and insert at a point in the file name that
you determine the country code for which the template file is to be applicable.
The country code must match the details given in the project properties, see
SECTION 42.3.1: SWITCHING LANGUAGES / LANGUAGE MANAGEMENT:
If “49” was selected for German and “44” for English, then the two crp files
are now called:
ar49_an1_terminals.crp
ar44_an1_terminals.crp.
In the next step, Comos needs to find out at which point within the file name
you inserted the country code. You could also have written
ar_an1_terminals49.crp instead. Do this by creating a help file that has a
placeholder at the corresponding point. This help template file can be com-
pletely blank, the only thing that matters is the file name:
ar%L%_an1_terminals.crp
Creating a report template that accesses the help template file

Create a new report template in the base project and select the template file:
The report template can be used in the usual way.
42.6 Exclusions
The following information is not translated:
Description for revisions and revision steps
The “Description” of a revision or revision steps is not translated. Instead, the
description is written to the primary language and is displayed identically in
all languages.

Designer (2D-drawings) General operation of the interface
43 Designer (2D-drawings)
The Designer is primarily used within Comos at the following points:
In base objects, see SECTION 45: SYMBOL-DESIGNER.
For report templates, see SECTION 46: REPORT DESIGNER.
In interactive reports, see SECTION 47: DESIGNER AS INTERACTIVE REPORT.
43.1 General operation of the interface
43.1.1 Copy/Move
Copying objects via keyboard commands
Copy [Ctrl] [Insert] [Ctrl] [C]

Paste [Shift] [Insert] [Ctrl] [V]
When an object is copied, it is not simply dropped with the Paste
command but instead it “sticks” to the mouse cursor and must be
positioned by mouse-clicking.
Cut [Shift] [Delete] [Crtl] [X]
Copying objects with the mouse

• Mark an object
• Press the [Ctrl] key and
• drag a copy to the desired location with the left mouse button.
Copying across reports

When an object is copied at a report and inserted in another report, you can
also select the | PASTE AT ORIGINAL POSITION command from the mouse menu.
The result is that the object is pasted at the same coordinates as those of the
original report.

General operation of the interface Designer (2D-drawings)
43.1.2 Zoom / Move
Zoom function via the mouse

The Zoom function can enlarge any area within the working area by a factor
of up to 800%.
• Press the [Ctrl] + [Alt] keys and the left mouse button, and
• drag with the mouse a frame to enclose and select the area to be enlarged.
No marking frame is shown when moving if the magnification is more than

200%.
Fit to window size

• Press the [Ctrl] + [Alt] keys and
• click once on the sheet with the mouse.
This combination of [Ctrl] key + [Alt] key and left mouse button functions
regardless of which tool is currently activated.
Zoom all
• Press the [Ctrl] + [Alt] keys and
• click once in the document with the left mouse button.
This functions zooms alternately between the entire document and an imagi-
nary bounding rectangle drawn around all the elements.
The second option, an imaginary bounding rectangle, also comprises all the
report elements lying outside the document area.
Moving the cutout section in the working area

The working area of the report can be moved back and forth just like a piece
of paper that you are working on:
• Press the [Alt] key and the left mouse button,
• and grab the working area at one point
• and then move it in any desired direction.
This combination of [Alt] key and left mouse button functions regardless of
which tool is currently activated.

43.1.3 Placing with drag & drop
Placing objects
The interactive reports are used in a completely intuitive way. If you wish to
use an object, simply pull it onto the plan with a drag & drop operation:
Preview with drag & drop

A preview appears when an object is dragged onto a report. This preview is
not identical to that of the final display of the object on the report (for exam-
ple, the %N texts are missing in the preview), but it gives you a good idea of
what the object will look like in the report.
Attributes via drag & drop

In addition to objects, attributes can also be placed by drag & drop:
Interactive report
The attribute can only be dragged onto the report if the owner has already
been placed. A symbol is generated, into which an %N text is placed.
Report template
A text of type Item-Property is created when an attribute is dragged onto a
report template. The user can determine for himself or herself which property
is displayed. In addition, the user can determine whether or not to allow the
attribute to subsequently be modified on the interactive report.

Symbol Designer
Each attribute is displayed as a fixed %N text.
Base objects via drag & drop

Base objects can be fetched from the Navigator, or simpler still, from the base
objects icon bar:
Planning objects are created automatically when base objects are pulled onto
an interactive report with drag & drop:
• The planning objects are created in specific applications for particular
technical fields under the document, for example FD, to some extent also
P&ID and IT.
• In all other cases the planning objects are created “next to” the document.
• The new planning objects can also be created in a completely different
branch if you are working with “pointers”. If, for example, there are
documents in the document view and these possess a unit pointer (i.e. the
pointer to a units view/tab), then the new planning objects are created
underneath the unit (and thus on the Units tab and not on the Documents
tab).
43.1.4 Placing templates
See SECTION 49.5: TEMPLATES concerning the administration of templates

1. Open an interactive report and select from there the mouse context-
sensitive command | Place template .
2. You are given a Navigator that also includes a preview window.
You can toggle between the base project and the current project. In
addition, you can toggle between the Units tab and the Locations tab.
The “@Template” branch is displayed on the relevant tab.
3. The relevant marked template is displayed in the preview window.
(Please note: as explained above, with interactive reports each copying
node may only contain one report.)

4. The [OK] button starts the copying process. The template “sticks” to the
mouse pointer.
5. Depending on the previous settings, either the template can be positioned
freely or else the positioning has been partially or completely stipulated
beforehand.
6. Depending on the previous settings, the planning objects are also created
in the Navigator after the template has been placed.
43.1.5 Standard toolbar
Evaluate document
Evaluates the document, whereby “document” also refers to symbols.
Print
Prints the current template file with all pages at the Windows default printer.
The page orientation is automatically adapted to suit the format of the tem-
plate file.
Printing report sections

• Adapt the zoom to fit the document.
• Mark a number of objects within the visible area.
• Then press the Print button. Select the Marking option in the following
dialog window at the bottom left.
The result is that the marked objects (and only those) are printed to fill the
page for the selected zoom ratio (meaning that they are not to scale). The page
ratio is retained.
Save
If you input a name that is the same as that of an existing template file, this
existing template file is overwritten without any prompts appearing.
Only Report Designer: Save as
Saves the report as a crp file in the desired folder.

Cut, copy, paste
The standard Windows functions
Undo / restore
This function can undo most actions by one step or else repeat the step in
question.
Zoom and move
Zoom: Drag a frame with the mouse. The frame is enlarged to fit the available
space. The entire area is displayed again if you mouse-click on the working
area.
Move sheet: The worksheet can be moved.
Variable zoom: Click on the desired point in the working area and hold down
the mouse button. Slowly drag the mouse downwards (enlarge) or upwards
(reduce).
Zoom in on objects: The working area is enlarged until all the objects that had
just been placed on the working area are visible. The entire area is displayed
again if you mouse-click again.
Layers
The layers can be made visible or hidden here, see SECTION 43.4: LAYERS IN
REPORTS.
Construction
Makes it easier to design solid bodies.

• Lines and dimensional objects not only snap to the grid but also to the grab
points of the objects. The grab points are shown in the form of a gray dot.
• The option “Expanded construction” is available in addition with the Line
tool.
Construction (design) mode can be switched on and off either by the mouse
menu or via the icon bar.
Start mode for Report Designer: switched off.
Start mode for Symbol Designer: switched on.

Designer (2D-drawings) The design tools
Bird view
Opens a small window in which the entire report is displayed.

A white color shows which part of the overall area is visible within the report
window. This colored area can be moved with the mouse in the bird’s-eye
view and thus the visible area of the report can be moved as well.
Grid
Determines the snap-to grid. All symbols, lines and texts are always placed on
the points of the grid, even if the grid is not visible. The symbols have a
“placement point” that only very seldom coincides with the top left-hand cor-
ner of the symbol.
New plans have as a rule a base grid of 4 mm, and a base grid of 2.5 mm is
also used to some extent in old plans.
The grid is ignored if the Shift key is pressed.
Zoom functions
Changes the zoom factor in fixed steps.
43.2 The design tools
43.2.1 The Identifier tool
Objects can be marked, moved and copied with the aid of the Iden-
tifier tool.
You can drag a frame with this tool, in the usual way for operations under
Windows. All objects that are within or on this frame are marked. Marked
objects are shown in a different color, usually a shade of pink.
Individual selections can be made by means of the [Ctrl] key and the left
mouse button. In this way an individual object can also be unmarked from a
marked group.
If only a single object is marked, a second mouse click activates the grab
points. If some of the objects are covered, click again on the same point to
address an object that is “deeper”.

The design tools Designer (2D-drawings)
43.2.2 The Line tool
The lines are aligned to the grid points.

The lines are not aligned to the grid if you hold down the Shift key
while drawing.
43.2.2.1 Line parameters

Opens the Line parameters dialog box to set the parameters for the lines.
Name
Each object can be addressed by a script via the name. For this reason the
names must be unique.
P1, P2
X-coordinates and Y-coordinates of the start and end points.
Width
Line thickness in mm.
Line type
Standard line type in Windows, e.g.
0 = default (continuous)
1 = continuous
2= ⎯ ⎯
3= ⎯ -
Layer
If layers have been set up for the document, a layer can be selected here and
the drawing element allocated. Layers are usually already available within
Symbols.
There is the associated “Layers” button on the Icon bar, see SECTION 43.4: LAY-
ERS IN REPORTS.
Label
Report Designer: The identification key is set automatically and cannot be
input manually. If the “No cell delimiter” option has been set, identification
key GR is input.
Symbol Designer: An identification key can be input manually.
Changes in the values are visible at once.

Change lines with the mouse

1. Mark the line with the Identifier tool.
2. Click on the line a second time (two separate clicks, not a double-click!).
The line is given grab points at its ends, and these can be shifted individually
with the mouse.
You can draw polylines by setting the starting point with a mouse click and
clicking on the subsequent points with the left mouse button as appropriate.
Conclude the procedure by clicking with the right mouse button.
43.2.2.2 Lines: expanded design (construction) mode

You can also activate the additional switch Expanded construc-
tion for lines (design mode is likewise activated for the worksheet).
The result:
• Lines are aligned to other objects (vertically, parallel). The objects used for
alignment are shown in yellow.
• Lines remain within the origin within an angle of 10° (they thus do not
diverge from the vertical or horizontal until after an angle of 10°). This
function only applies to graphic lines and not to connecting lines.
• The following fields are active for the second and subsequent points of the
line:
Location of the last point in the X-direction.
Location of the last point in the Y-direction.
Absolute angle, can be edited after placing the second point.
Object length, can be edited after placing the second point.
Transposes the starting point of the line.
Terminates the action.
43.2.3 The Circle tool
Circle and circle segment design
Opens the draw circle expanded tool palette.

2-point circle design, mid-point, radius.
3-point circle design. Circle design in the mathemat-

ical sense: the first two mouse-clicks determine at
which imaginary tangents the circle lies, the third
mouse-click determines the distance of the mid-point
from the imaginary tangents.
3-point arc, mid-point, arc point 1, 2.
3-point arc, arc point 1, 2, 3. Circle design in the
mathematical sense.
Rounding tool
Radius input. A radius can be entered before the first

mouse-click is made; the corresponding circle then
“sticks” to the mouse pointer and the next mouse-
click merely determines the mid-point.
Also serves as a stamper function.
Editing circles
The usual Properties window can be opened by double-clicking.
Grab points in the circle are highlighted by means of two separate mouse-
clicks. Using these grab points, you can not only change the mid-point and the
radius but also split up the circle and draw segments instead. Each circle
includes an input point for splitting, plus an additional splitting point for each
tangential or intersection point with another graphic object.

43.2.4 Placing text
43.2.4.1 Text defaults

The default values are set before placing the text parameter. In order
to set them, activate the text tool. A textfield and [...] control are
added in the icon bar. Press [...] to open the Text parameter dialog, where
you can then enter the default settings:
Font Type on the Font field or click on the [...]

button. The Font dialog field appears.
Here you can input values for the font,
font style, size and display.
Color Field Text
inside The color settings that are made here
apply to the text itself.
Field Background
outside The settings that are made here apply to
the background of the text frame.
The Transparent switch must be turned
off to allow the color of the text back-
ground to be seen.
Transparent On The background is transparent, thus the
selected background colors are not visible.
Any text, or lines under the text, is visible.

Off The background is not transparent, thus

the selected background colors are visible.
Any text, or lines under the text, is not vis-
ible.
Soft On The text is placed at a short distance from
the text frame.
Off The text is placed without any spacing.
Alignment Select the relevant button to determine the
position (alignment) of the text within the
text frame. If there is no text frame, the
text is aligned about the placing point.
Layer If layers are available: assign a layer to the
text.
43.2.4.2 Text properties

If a text parameter has been placed, call the | PROPERTIES mouse-context menu
to open its Text parameter dialog window. This dialog window comprises
more functions than the Text parameter window in which the defaults were
set before placing the text parameter.
Texts are interpreted in different ways in reports and symbols.
Text properties in Report Designer:
see SECTION 46.3.1.2: TEXT PROPERTIES.
Text properties in Interactice Reports:
see SECTION 47.1.4.2: TEXT PROPERTIES.
Text properties in Symbol Designer:
see SECTION 45.3.1.2: TEXT PARAMETER: PROPERTIES.
43.2.5 Hatching
This tool functions with the following objects:

• Circles, circle segments
• Closed figures made up of lines (“polylines”)
Allocate hatching
• Select an object (circle, polygon) and click the “Hatching“ tool.

• Confirm with [Return].
Edit or fill hatching

• Once hatching has been allocated, you can select the hatching with two
separate mouse-clicks and access the properties with the right mouse button.
• There you can determine how far apart the lines of the hatching are to be or
change over to fill.
43.2.6 Transforming
Opens expanded transformation mode.
Move (with or without copy)
• The move vector is set with the first and second mouse-clicks.
• The objects to be moved are selected with the third and subsequent mouse-
clicks.
The move operation is carried out by clicking on the tick button on the far
right.
Alternative:
Input of the X-coordinates to determine the shift vec-
tor.
Input of the Y-coordinates to determine the shift vec-
tor.
Number of copies of the selected object, either
selected from the drop-down menu or by inputting
whole positive numbers (integers).
Rotate (with or without copy)
• Input an angle of rotation.

• The first mouse-click on the report determines the point about which the
rotation is to be made.
• The next and subsequent mouse-clicks determine which objects are to be
rotated.
The move operation is carried out by clicking on the tick button on the far
right.

Alternative.
Number of copies of the selected object, either selected from the
drop-down menu or by inputting whole positive numbers (inte-
gers).
Mirror (with or without copy)
• The first two mouse-clicks determine the mirroring axis.

• The next and subsequent mouse-clicks determine which objects are to be
mirrored.
The operation is carried out by clicking on the tick button on the far right.
Alternative.
Number of copies of the selected object, either selected from the
drop-down menu or by inputting whole positive numbers (inte-
gers).
Scaling (with or without copy)
The reference point is determined by clicking with the mouse.

Scaling factor in the X-direction.
Scaling factor in the Y-direction.
Input of the number of copies.
Execute the selected action.
Distort
•All objects on the report that have connectors are only moved if all the
connectors lie within the selection polygon.
• Objects that have no connectors (such as freehand circles) are only loved of
the bounding rectangle around symbols is completely within the selection
polygon.
• Texts that can be moved on their own are not taken into consideration.
Example: if a motor has a text, within which there is the name of the motor,
and if this text can be moved freely, then it makes no difference whether or
not the text lies within the selection polygon.

Designer (2D-drawings) Status bar
• In the case of report objects that are genuinely going to be stretched (such
as connections and potentials), the grab points are still determined
nonetheless and these are moved as required (if not all the grab points are
within the polygon). In other words: with these objects the portion that lies
within the selection polygon and is stretched is determined.
Align
Select with the first mouse-click the object to which the alignment is to be
made. Draw with the second mouse-click a frame that encompasses the
objects to be aligned.
43.2.7 Toggling Design mode
Button pressed: Design mode is activated.
• The lines and the report origin are shown when in Design mode.
• In addition, the object shells are displayed and not the object results.
Example: In the case of a list, the list object is displayed (a frame with a
cross), not the results of the list calculation.
• All the tools are shown.
If Design mode is deactivated, the worksheet automatically switches over to

display mode. In this case the object results are displayed to the extent that this
is possible (a number of results only appear once you have also clicked the
[ABC] Reevaluate document button). Many of the tools are inactive.
43.3 Status bar

Coordinates display
When you open the Report Designer, an Interactive Report or the Symbol
Designer, the coordinates of the mouse pointer are shown in the Comos status
bar.
When a tool is used that snaps to the grid, then the coordinates shown are not
of the current position of the mouse pointer but of the grid point actually being
used. You can carry out design work adequately via this display of the coor-
dinates if user a somewhat coarser grid.

Layers in reports Designer (2D-drawings)
43.4 Layers in reports
43.4.1 Setting up layers for reports
Standard layers in reports

Layer 1: Pipes
Layer 2: Planning objects
Layer 3: Graphic elements
Layer 4: Sub-documents (reports that had been placed on other reports by
means of drag & drop)
The mouse commands |Edit | In the foreground and | In the background
sort the relevant report object only within “its” layer in the foreground or in
the background as applicable.
Setting up additional layers

The definition of layers for interactive reports is done in @System @D Data
@GRAPHICS.
Syntax:
@Graphics | @Layers | (plan type) | (layer number)
Numbers for the layers can be selected from within the range from 1 to 999,
whereby the range 251 to 255 is used internally by the system and may not be
used or changed.
The switch with the caption Visible , name: VISIBLE is located on the Gene-
ral tab of the base objects layer. The switch controls the setting as to whether
or not the objects of a layer are to be visible initially. (Additional information:
You can toggle specific layers on or off during a work session. But these user-
defined settings are not saved.)

MultiCRP.exe Objective
44 MultiCRP.exe
44.1 Objective
MultiCRP.exe is a utility program for the bulk processing of Evaluation
reports. The program is located in the \bin sub directory of the Comos direc-
tory.
The program searches and replaces text expressions. Two methods of opera-
tion are possible here:
• Manual search for specified texts
This search and replace function operates in the options script and/or in the
script of the report items (objects that are placed on the report).
• Automatic search for duplicate names
This search only includes the name fields of the report items.
44.2 Selecting reports

First search for a folder in the top left area:
Please make sure that you address only Evaluation reports. This particularly
applies if the “Recursive ” option is enabled and/or the “Selected only ”
option is disabled. In that case, many files can be accessed.
Recursive
The subfolders are included in the search as well. In the “Folder ” column, the
subfolder in which the report was found is displayed.

Manual search and replace MultiCRP.exe
Please note: If the Recursive option is enabled, then the search can take very
long. The current search can be ended with [Esc].
Layout
On the Layout tab, a preview of the report appears. The Layout tab is
refreshed only if you switch to the “Source code ” tab and back.
Thus, if you select a report in the result list, thus displaying it on the Layout
tab, this report will remain visible even if another report is selected in the
result list. The new report is visible only after toggling.
44.3 Manual search and replace

Search
Select one or more reports and enter a search text in the Search field. Click
[SEARCH].
If a result was found, then the corresponding text block appears in the Source
code tab and details in which report and which item the text was found is dis-
played:
While the search is in progress, no other text can be entered in the Search
field. You must first cancel the search. Then you can enter a new search text
and start the search with [SEARCH].

MultiCRP.exe Re-establish uniqueness of names
Replace
Single replacement
One of the entries on the Source code tab is marked. Click [REPLACE]. The
text is replaced and you automatically jump to the next entry.
At this moment, the reports have not been saved yet. You can undo your
changes by closing multicrp.exe. If you want to keep them, click [SAVE].
All reports changed until now are saved.
Replace all
The [REPLACE ALL] button replaces all occurences of the search term in all
selected reports.
44.4 Re-establish uniqueness of names

When items are created in Evaluation reports (i.e. texts, lists etc.), the first
thing that is checked is if these items have identical names.
Identical names often cause difficult technical problems. One problem could
be that scripts can no longer address the items clearly (because the items are
exclusively identified by their names and not by a UID or something similar).
Some Comos functions also require unique names, like the content-based
revisioning.
Innotec recommends to give all items of a report a unique name.
If some items are not named uniquely, then these appear in red in the Report
Designer:

Re-establish uniqueness of names MultiCRP.exe
The Evaluation reports are presented accordingly in multicrp.exe:
The [RE-ESTABLISH ...] button corrects these items. To do that, the highest
name of all items on the report is determined. All items with duplicate names
receive a new name, based on the following name scheme: <highest name
+1> ... <highest name +n>.
Please note: All items with duplicate names are renamed. Thus, the “Re-estab-
lish“ function in multicrp.exe is different from the same function in the Report
Designer.
As described above, in the Report Designer, you can also identify which items
have duplicate names. If you right-click an item marked in this manner, you
get the context command | RE-ESTABLISH UNIQUENESS OF NAMES.
However, the current object is not changed by means of this mouse command
(i.e. the object at which the mouse context menu is called)! All other items
with duplicate names receive a different name, but this one item remains
unchanged. However, as all other items get a different name, there is no
longer any duplicate for the current item and all items are unique.

Symbol-Designer Background: types of diagrams
45 Symbol-Designer
This chapter contains additional information on the Symbol Editor. You
should already have read SECTION 43: DESIGNER (2D-DRAWINGS).
45.1 Background: types of diagrams

Please note that symbols are specific to the „drawing type“. In other words: a
symbol is exclusively displayed for the „drawing type“ for which it had ben
created.
A row appears on the Symbols tab of the base objects for each „drawing
type“ that had been created. The „drawing types“ are created within the sys-
tem project in standard table @SYSTEM | @DRW_TYPE <drawing type>.
The entire work flow thus comprises the following steps:
• The administrator must first of all create a drawing type:
@SYSTEM | @DRW_TYPE <drawing type>.
• Interactive Report templates must be created for this drawing type. There is
the corresponding call in the option script of the report:
SymbolType = "<drawing type>". (Without brackets.)
• A symbol must be created in the base objects on the corresponding row in

the Symbols tab.
• An Interactive Report with the report template created above must be
created.
• Now the base object (and / or a planning object that has been derived from
it) can be dragged onto the Interactive Report and the symbol is displayed.
45.2 General rules for designing symbols

Default settings
Symbols must have a line thickness, a point of origin, a grid and, if text items
are used, a font size.
The following minimum sizes are recommended: 0,35 for the line thickness
and 9 pt for the font size. Generally, the font size for device tags and descrip-
tions should be 9, and that for contact points should be 7.

General rules for designing symbols Symbol-Designer
There should be very little or no deviations in the line thickness and font size
of the various symbols, since this may negatively affect the quality of the
printout. This is not a Comos problem, it is due to the technical limitations of
printers (printer resolution, conversion of lines whose line thickness cannot be
displayed etc.).
Colors should be used with much care: many printers do not support color
printing.
The text font-style Italic should not be used, since Comos automatically ital-
icizes text items in certain cases, and as such unexpected errors may occur if
Italic is used within symbols.
The grid spacing as well as the point of origin must be adjusted to the connec-
tors on the symbol, otherwise it will be difficult to connect the symbol auto-
matically. For example, if the connectors are not accurately positioned on the
grid and diagonal connections are not allowed. The point of origin should then
be located on the first connector.
Layers and labels

Although not mandatory from a techical point of view, the integral parts of a
symbol should have a layer and a label. In Comos, many functions require a
layer and a label (e.g. for making symbols invisible on a report, modifying and
moving them together etc.). If you do not use any of the functions requiring
layers and labels, you should nevertheless create a unique layer and label in
advance. Select a name that is specific enough, so that later on you do not
want to use this name for another purpose.
If you already know for which purpose the layer and the label will be used,
you are recommended to select self-explanatory names.
Remember that Comos assigns names that are used on the system, so make
sure you do not choose Comos system names. See SECTION 45.5.1: SCRIPTHEADER
COMMANDS.
Required space
As regards the space required for a symbol, take special note of text variables.
The length of the text output by a text variable depends on the planning data
and can vary considerably.
In this context, you should especially be aware of multilingual text items,
since the length of a text items varies depending on the language being used.

Symbol-Designer Toolbar
Hierarchy
Normally, the deeper you are in the object hierarchy, the more detailed a sym-
bol will be.
In this case, a basic symbol is created further up in the object hierarchy. Fur-
ther down the hierarchy, the basic symbol is defined in more detail. As a result
of that, the symbol gets checked-in and the inheritance chain breaks off. If the
basic symbol is changed afterwards, these changes are not passed on to the
objects that defined the symbol in more detail.
Therefore one can try to break down the symbols into separate units in some
cases: use text scripts to load additional symbols or symbol parts.
However, the text script may not be changed at a deeper level in the hierarchy,
otherwise inheritance would then break off again.
Loading symbols from a standard table

Symbols can be placed in standard tables. If that is the case, managing the
symbols becomes more complex: the base objects no longer have a symbol
preview. In order to find out which symbols belong to which base objects, you
have to open the standard tables and compare them with the appropriate base
objects.
Giving preference to drawn symbols

Even a symbol that was created by means of the drawing tools in the Symbol
Editor is later (i.e. behind the scenes) translated into a script. Nevertheless,
there is a difference between symbols that are created using the Symbol Editor
and those created directly by writing a script (see SECTION 45.5: SYMBOL SCRIPT):
If a symbol is created via scripting, it should not be changed graphically at a
later point in time, otherwise the inheritance chain of the script will break off.
Therefore, you are highly recommended to use Comos text variables instead
of scripts to generate variable texts. See SECTION 45.4.1: TEXT FUNCTIONS.
45.3 Toolbar
45.3.1 Properties of a text (text parameters)
Toolbar of the Editor, tool: Text

Toolbar Symbol-Designer

When you activate the Text tool you can set within the Text parame-
ters dialog window templates for all new texts. See SECTION 43.2.4: PLA-
CING TEXT.
45.3.1.2 Text parameter: properties

| PROPERTIES
Right-cklick onto a text to its Properties window:
Most of the options correspond to the options available in the dialog in which
the parameter defaults are set (compare SECTION 43.2.4: PLACING TEXT.)
New:
Multilingual checkbox
In dependence on the currently active language, different texts can be output
for the text parameter. If you activate the Multilingual option, a text field
appears for each language that was set up within the current project. The des-
ignation of the language that is currently being used is shown in bold.
If you make a selection from the list on the left (by double-clicking or by
pressing the [->] button), this is always transferred to the uppermost field.
After that you can transfer the text into the other fields by using the Copy and
Paste functions and so modifying the text there.
Moveable :

Symbol-Designer Toolbar
• Activated:
The text parameter receives the label specified by Label and can be moved
by means of its grab points.
• Deactivated:
The text parameter receives a label that signalizes that the parameter may
not be moved. See Label .
Label :
Internally used to identify text parameters. In a symbol, all text parameters
with the same label share one grab point and can only be moved together.
• “Automatically”: The label is created automatically.
Moveable activated: “e”+ random number between 1 and 100
Moveable deactivated: module-dependent label is created, identifying the
text parameter as unmoveable (P&DI: “nv”, EMR: “eZ”)
• If a standard table was created for the current diagram type (base project:
@SYSTEM|@CLASS|[Name of the diagram type]), the labels entered there
are available in the pull-down menu.
• Empty label: Text parameters without label cannot be moved.
Background information:
The labels are processed sequentially in the symbol script. This means, a label
is valid until a new label is set. For placeholder text parameters (*V*P texts)
this often means, that the label set for the text placeholder is “overwritten” by
the label of the additional graphic identified by the placeholder.
Dropdown menu Angle :
Compare The “Properties” tab, P. 46-10.
Checkbox “Apply instantly ”“:
Compare General window area, P. 46-8.
Selection area Text functions / Sub-symbols / Connectors
See SECTION 45.4.1: TEXT FUNCTIONS; SECTION 45.4.2: SUB-SYMBOLS; SECTION 45.4.3:
CONNECTION POINTS.
45.3.2 Set origin
The origin of a symbol determines how the symbol is placed on the grid of a
report. The origin should thus be placed so as to line up with the connection
points of the symbol.

Properties of a text Symbol-Designer
45.4 Properties of a text
45.4.1 Text functions
45.4.1.1 Overview
Please note that the text functions are specific to the drawing type.
It is stipulated in the standard tables of the base project of the default version
supplied which functions are offered in the interface for the relevant drawing
type.
From a programming point of view, the functions are usable quite indepen-
dently of the standard table. However, if the standard table is deleted, the
functions in the input help for the text function are no longer displayed.
The text functions require that the names of the tabs, the attributes,
the properties, etc., are entered accurately. Take great care with the
spelling.
Legend:
• x/x This function has been implemented and is supported by the interface
for this type of diagram.
• x/- This function has been implemented but is not offered for selection by
the interface for this type of diagram, but it can still be used manually by
inputting the correct syntax.
Text functions/list @IRF_DETAIL @IRF_RI @IRF_SLINE

ALLMYREFERENCES x/- x/- x/-
ANSI1 x/- x/- x/-
ANSI2 x/- x/- x/-
BLTPFD x/- x/- x/-
COMOSDEVSPEC x/x x/x x/x
COMOSELMSPEC x/x x/x x/x
COMOSSEGSPEC x/- x/- x/-
COMOSSPEC x/x x/- x/x
DETAILREFERENCE x/- x/- x/-

Symbol-Designer Properties of a text

DEVALLDESCRIPTION x/- x/- x/-
DEVCONTACT x/- x/- x/-
DEVDESCRIPTION x/x x/x x/x
DEVFUNCTION x/x x/x x/x
DEVGUNIT x/- x/- x/-
DEVICE x/- x/- x/-
DEVICE.FULLNAME x/- x/x x/-
DEVLOCATION x/x x/- x/x
DEVLOCATION1L x/- x/- x/-
DEVNAME x/x x/x x/x
DEVPOSITION x/x x/- x/x
DEVSIGNALDESCRIPTION x/- x/- x/-
DEVTYPE x/x x/- x/x
DEVTYPEL x/x x/- x/x
DEVTYPEW x/x x/- x/x
DEVUNIT x/x x/- x/x
DEVUNIT1L x/- x/- x/-
DEVUNITPOSITION x/x x/- x/x
ELEMENT x/- x/- x/-
ELEMENTS x/- x/- x/-
ELM..CO x/x x/- x/-
ELM..CP x/x x/- x/x
ELM..DS x/x x/- x/-
ELM..LABEL x/x x/- x/x
ELM..VW x/x x/- x/x
FROMDOC x/- x/- x/-


FROMDOCOBJ x/- x/- x/-
FUNCTION x/- x/- x/-
MAINDEVICE x/- x/- x/-
POSITION x/- x/- x/-
POTALLDESCRIPTION Only for potential links
POTDESCRIPTION Only for potential links
POTLOCATION Only for potential links
POTNAME Only for potential links
POTUNIT Only for potential links
RACK x/- x/- x/-
REFCHAIN x/- x/- x/-
REFERENCE x/x x/- x/x
REFMASTER x/- x/- x/-
REFSIMPLE x/- x/- x/-
REPORTSCRIPT x/- x/- x/-
REQUIREMENT x/- x/- x/-
RQMT x/- x/- x/-
RQMTS x/- x/- x/-
SLOT x/- x/- x/-
TODOC x/- x/- x/-
TODOCOBJ x/- x/- x/-
USERFUNCTION x/x x/x x/-
45.4.1.2 AllMyReferences
Example / Syntax:%N AllMyReferences%

This text function stipulates in the form of a text block all the placement loca-
tions of the object (covering all types of diagrams):
45.4.1.3 Ansi1
Example / Syntax:%N Ansi1%
Text function Ansi1 initiates a search for the next object of the “Function”
class within the hierarchical object structure. The first letter of the Label of
the hierarchically superordinate function is output and prefixed to the object
name (if no label has been allocated, the name is used as an alternative):
45.4.1.4 Ansi2
Example / Syntax:%N Ansi2%
Text function Ansi2 initiates a search for the next object of the “Function”
class within the hierarchical object structure. The Label of the hierarchically
superordinate function is output from the second letter onwards. If no label
has been allocated, the name is used as an alternative:

45.4.1.5 BltPfd
Example / Syntax:%N BltPfd%
This text function serves for contact mirror symbols to stipulate where and on
which diagram the switching elements are placed (sheet / path). Here is an
example for a contactor on document SLP2 with contact mirror and links to
the contacts:
The links to the individually placed switching elements are implemented via
the Reference, P. 45-28 text function. Here is an example for a contactor on doc-
ument SLP1 with a link to contactor K2:
45.4.1.6 ComosDevSpec
Example / Syntax:%N ComosDevSpec(“Section”, “Attribute”, “Property”)%
Section Name of the tab at the object

Attribute Name of the attribute on the tab
Property Property of the attribute
-Value
-DisplayValue (display value)
-PhysUnit (physical unit)

The Value , DisplayValue and PhysUnit parameters of the associated main

device (MainDevice ) can be output at the symbol via this text function. Text
function ComosDevSpec is obsolete and will not be supported in future. New:
text function ComosSpec, P. 45-13.
Application example:
45.4.1.7 ComosElmSpec
Example / Syntax:%N ComosElmSpec(“Section”, “Attribute”, “Property”)%

-Value )

The Value , DisplayValue and PhysUnit parameters of the associated main

device (MainDevice ) can be output at the symbol via this text function. Text
function ComosElmSpec is obsolete and will not be supported in future. New:
Application example:
Pic. 45-1: ComosElmSpec: output of the current value with unit
45.4.1.8 ComosSegSpec
Example / Syntax:%N ComosSegSpec (“Section”, “Attribute”, “Property”)

-Value
Parameters Value , DisplayValue and PhysUnit of the segment of the associ-

ated piping can be output at the symbol by means of this text function. Text
function ComosSegSpec is obsolete and will not be supported in future. New:

45.4.1.9 ComosSpec
Example / Syntax:%N ComosSpec(“Section”, “Attribute”, “Property”,
“Unit”, “Class”, [“Description”])%
Function ComosSpec offers more comprehensive output options than do
either ComosDevSpec or ComosElmSpec and it should therefore be used for
preference. Differing from what is shown in the selection mask, it supports the
Properties parameters Value , DisplayValue , Range2 , Range3 , the Units
parameter PhysUnit and, optionally, the Description parameter Description .

Property Selection of the property of the attribute to be dis-
played:
-Value
-Range2 (output upper and lower limiting value)
-Range3 (output upper and lower limiting value
and current limiting value)
Unit Selection as to whether a physical unit is to be out-
put:
-None
Class Selection of the object from which the data is to be
taken:
-Own
-MainDevice (associated main device)
Description Optional parameter D, stipulates the object descrip-
tion of the output if this had been input beforehand

Pic. 45-2: Possible forms of output with text function ComosSpec
Pic. 45-3: ComosSpec: output in the report
45.4.1.10DetailReference
Example / Syntax:%N DetailReference%
Text function DetailReference supplies the information on a placing of the
object on detail diagrams. This function is used in Design plans, for example,
so as to retain at the object a link to the location of the depiction in the circuit
diagram:
Pic. 45-4: DetailReference: output in the report
45.4.1.11DevAllDescription
Example / Syntax:%N DevAllDescription%
This text function supplies the description of the Maindevice (main device).
45.4.1.12DevContact
Example / Syntax:%N DevContact%
Outputs the label of the connected ComosConnector.
45.4.1.13DevDescription
Example / Syntax:%N DevDescription%

This function output the description of the MainDevice that is intrinsic to the
main device (and has thus been checked in, for example), while display of the
inherited designations is suppressed. Here is an example for the output of
DevDescription in the report before and after checking in:
Example DevDescription
45.4.1.14DevFunction
Example / Syntax:%N DevFunction%
This function initiates a search for the first attribute in the TD (Technical
Data) section of the object that has both a value and a unit. Sorting is done
alphabetically.
Output is only produced if an attribute that meets the conditions is found.
Open the TD tab of the planning object and allocate values for the attributes
that were created (0 for capacitance and resistance in our example):
Pic. 45-5: DevFunction: output in the report
45.4.1.15DevGUnit
Example / Syntax:%N DevGUnit%

This function supplies the full label of the object with regard to the segment
and document by making use of the AliasFullLabelWithoutFolder (see also the
Comos Core reference) and GUnit functions (see also the Comos Core refer-
ence).
45.4.1.16Device
Example / Syntax:%N Device.<property>%
This text function makes it possible for an experienced user to have direct
access to a wide variety of different types of information about the current
object and in addition about all the objects that are connected to it structurally.
In order to be able to use the wide variety of options offered here
correctly and to the full, a considerable knowledge of programming
in VB Script and for the Comos object class Device (see also the Comos Core
reference) is required.
45.4.1.17Device.FullName
Example / Syntax:%N Device.FullName%
Text function Device.FullName supplies the full name of the object while tak-
ing into consideration the complete object superstructure. Folder objects are
excluded.
Pic. 45-6: Example of unit structure
Pic. 45-7: Output of FullName at the object

45.4.1.18DevLocation
Example / Syntax:%N DevLocation%
This function allows the automatic output of the relevant current installation
locations of objects at the symbol in the specific form set by the project
parameters by making use of the AliasFullLabelWithoutFolder function (see
also the Comos Core reference).
Pic. 45-8: Drag & drop of the location in the Properties mask of the planning object
The LOCATION field is created in the Properties mask planning object BSP-
DevLocation as a result of the drag & drop operation and the location object
is input with its full name. At the same time a link to the unit or location
respectively is input in the respective unit or location branch:
Pic. 45-9: Automatically generated location description of the object in the diagram
45.4.1.19DevLocation1L
Example / Syntax:%N DevLocation1L(X)%
This function is the “location marker” for DevUnit1L, P. 45-21 and allows the
automated output of a specific portion of the name of the place of installation
of the reference object at the symbol. Parameter X , either in integer or string

form, determines the hierarchy level whose name is to be output, starting from
the top (project layer = level 0). Folder objects are not included in this reck-
oning.
Pic. 45-10: Installation location structure of the example object
Pic. 45-11: Text functions in the Editor and output in the report
45.4.1.20DevName
Example / Syntax:%N DevName%
This function outputs the current designation of the planning object with
regard to any alias structures that may exist in the way that had been set
beforehand at the selected point by the project parameters.
Pic. 45-12: Text function DevName in the Symbol editor and in the diagram

45.4.1.21DevPosition
Example / Syntax:%N DevPosition%
Text function DevPosition supplies the full designation of the first position in
the hierarchical superstructure of the current object by making use of the
MainDevice function, Alias structures, segments and documents are taken
into consideration during this operation.
Pic. 45-13: Text function DevPosition in the Symbol editor and in the diagram
45.4.1.22DevSignalDescription
Example / Syntax:%N DevSignalDescription(Index)%
Text function DevSignalDescription supplies the description of the signal that
is located on the connector specified by the index. If no index has been stipu-
lated, the first signal that is found is taken into consideration.
45.4.1.23DevType
Example / Syntax:%N DevType%
This text function determines the value of attribute HSD.M001 (article num-
ber from the manufacturer data) and outputs this at the specified point.
Pic. 45-14: Text function DevType in the Symbol editor and in the diagram
45.4.1.24DevTypeL
Example / Syntax:%N DevTypeL%
This function evaluates the wire cross-section LQ that had been created under
the SYS Specification tab by making use of the MainDevice function and then
displays the result.

Pic. 45-15: SYS tab
Pic. 45-16: Text function DevTypeL in the Symbol editor and in the diagram
45.4.1.25DevTypeW
Example / Syntax:%N DevTypeW%
Evaluates the wire type LT that had been created under the SYS Specification
tab by making use of the MainDevice function and then displays the result:
Pic. 45-17: Text function DevTypeW in the Symbol editor and in the diagram
45.4.1.26DevUnit
Example / Syntax:%N DevUnit%
Text function DevUnit stipulates the current unit superstructure of the object
with due regard to the incorporation of a comparison of the superstructure
between the object and the diagram on which it is placed. Placement objects
and folder objects are not taken into consideration in this operation.

Pic. 45-18: Unit superstructure of BSP-DevUnit
Pic. 45-19: Text function DevUnit in the Symbol editor and in the diagram
45.4.1.27DevUnit1L
Example / Syntax:%N DevUnit1L(X)%
This function is the “units marker” for DevLocation1L, P. 45-17 and allows the
automated output of a specific portion of the name of the place of installation
of the reference object at the symbol. Parameter X , either in integer or string
form, determines the hierarchy level whose name is to be output, starting from
the top (project layer = level 0). Folder objects are not included in this reck-
oning.
45.4.1.28DevUnitPosition
Example / Syntax:%N DevUnitPosition%
Text function DevUnitPosition stipulates the current object superstructure in
the same way as for DevUnit , but in this case also taking placement objects
into consideration.

Pic. 45-20: Unit superstructure of BSP-DevUnitPosition
Pic. 45-21: Text function DevUnitPosition in the Symbol editor and in the diagram
45.4.1.29Element
Example / Syntax:%N Element.<Property>%
This text function makes it possible for an experienced user to have direct
access to a wide variety of different types of information about the current
object and in addition about all the objects that are connected to it structurally.
45.4.1.30Elements
Example / Syntax:%N Elements(Index)%
This text function evaluates the Elements Collection of the reference object
by means of the Comos EnObs function. In this case the Index parameter can
be an integer (position in the collection) or a string (“name”).

45.4.1.31Elm..CO
Example / Syntax:%N Elm..CO<n><X>%
Text function Elm..COnX outputs the FullLabel of the connected device of the
Xth contact point of the nth element.
Valid values for n {1-999}, X {a(A)-z(Z)}
At this point the capitalization (upper / lower case: a/A) of the contact param-
eters is irrelevant, as can be seen in.
Pic. 45-22: Text function Elm..COnX in the Symbol editor
Pic. 45-23: Connection of devices to connectors 002, 003
Pic. 45-24: Output of FullLabel of the connected device
45.4.1.32Elm..CP
Example / Syntax:%N Elm..CP<n><X>%
Text function Elm..CPnX outputs the label of the Xth contact point of the nth
element.

Pic. 45-25: Text function Elm..CP in the Symbol editor and in the diagram
45.4.1.33Elm..DS
Example / Syntax:%N Elm..DS<n><X>%
Text function Elm..DSnX outputs the description of the Xth contact point of
the nth element.
Pic. 45-26: Text function Elm..DS in the Symbol editor and the results in the diagram
45.4.1.34Elm..Label
Example / Syntax:%N Elm..Label<n>%
Text function Elm..Labeln outputs the label of the nth element.
Valid values for n {1-999}.
Pic. 45-27: Text function Elm..Label in the Symbol editor and in the diagram

45.4.1.35Elm..VW
Example / Syntax:%N Elm..VW<n>%
Text function Elm..VWn stipulates the placement position of the element of
the object itself or one of its accessory parts. The values to be input can
optionally either be whole numbers (n {1-999}), or the corresponding label in
string form (“..”).
The variant with numeric parameters limits the search for the ele-
ment to the Element object class, the variant in string form is class-
independent, on the other hand.
This function serves as a cross-reference to elements that are not placed
directly on the object. This can be displayed at the other point on the same dia-
gram or on other ones.
Pic. 45-28: Text function Elm..VW in the Symbol editor
Pic. 45-29: Text function Elm..VW before and after positioning of the element
45.4.1.36FromDoc
Example / Syntax:%N FromDoc.<>%
This function is used to implement links between different diagrams. From-
Doc supplies the starting document of the link. For further information see the
Comos Core reference: IComosDDocument.
45.4.1.37FromDocObj
Example / Syntax:%N FromDocObj.<>%

This function is used to implement links to objects placed in documents.

FromDocObj supplies the starting object of the link. For further information
see the Comos Core reference: IComosDDocObj.
45.4.1.38Function
Example / Syntax:%N function%
This function checks whether an RO_function (Dev) function has been
defined in the options block of the report template.
If it has, the return value of this function is used and displayed.
Example function in the options block:
function RO_function (Dev)
RO_function = Dev.Fullname
End function
If this function does not exist, the Specification tab of the reference object is
evaluated and the string located in attribute “FD.F100” at the symbol is out-
put. If this attribute does not exist, or if the string is blank, the name of the
reference object is output at the end without any numeric portions. (Is used as
designatory text for measurement function symbols).
45.4.1.39MainDevice
Example / Syntax:%N MainDevice%
Obsolete. Still provided for compatibility reasons, but should not be used any
longer! New: text function Device, P. 45-16.
45.4.1.40Position
Example / Syntax:%N Position%
This function checks whether an RO_position (Dev) function has been
defined in the options block of the report template.
If it has, the return value of this function is used and displayed.
Example function in the options block:
function RO_Position (Dev)
RO_Position = Dev.Fullname
End function
If this function does not exist, a search is made within the hierarchical super-
structure for the first function object or placement object, and in this case only
the owner structure is taken into consideration. If a corresponding object was

found, then a check is made to see if the owner of the object that has been
found is a document. In this case the AliasLabel of the object is output at the
symbol. If this had not been set, the label or the name are used as appropriate.
If the owner of the object that had been found is not a document, the Alias-
Fulllabel is output in the same way as for the previous item. In this case the
type of display that can be set by means of the RI.TXTMOD attribute at the cur-
rent object is taken into consideration.
45.4.1.41PotAllDescription
Example / Syntax:%N PotAllDescription%
This text function operates solely on potential links and supplies the full
description of the associated potential.
45.4.1.42PotDescription
Example / Syntax:%N PotDescription%
This text function operates solely on potential links and supplies the descrip-
tion of the associated potential.
45.4.1.43PotLocation
Example / Syntax:%N PotLocation
This text function operates solely on potential links and supplies the location
of the associated potential.
45.4.1.44PotName
Example / Syntax:%N PotName%
This text function operates solely on potential links and supplies the name of
the associated potential.
45.4.1.45PotUnit
Example / Syntax:%N PotUnit%
This text function operates solely on potential links and supplies the unit of
the associated potential.

45.4.1.46Rack
Example / Syntax:%N Rack(“Parameter”)%
Text function Rack calculates the slot that has been assigned to the reference
object and outputs the data to the symbol. Possible optional parameters to con-
trol the output are:
• - L (AliasLabel)
• - D (Description)
• - N (Name).
Pic. 45-30: Location structure for example Rack-Slot
Pic. 45-31: Output at the symbol and in the diagram
45.4.1.47RefChain
Example / Syntax:%N RefChain(Page)%
Text function %N RefChain( Page)% offers the option of a "chain link" to
objects that are located within the same OwnerCollection . The parameter
Page can take values 1(left) or 2 (right).
45.4.1.48Reference
Example / Syntax:%N Reference%
Text function %N Reference% offers the option of a cross-reference from ele-
ments to their main objects (MainObject ). The placement location of the Main-
Objects of the element is out in the form stipulated by the project parameters.
This MainObject can be displayed at another point on the same diagram or in
other ones.

Please note that the Reference text function at the symbol of the element of
the MainObjects must be created!
Pic. 45-32: Text function Reference in the Symbol editor and in the diagram
45.4.1.49RefMaster
Example / Syntax:%N RefMaster(Type)%
The %N RefMaster(Type)% text function offers the option of a master link to
all objects in the OwnerCollection (Art = “O”) or to all own elements (type =
“E”).
45.4.1.50RefSimple
Example / Syntax:%N RefSimple%
This text function evaluates Comos data from connections and creates a ref-
erence string to the target of the link. This function finds application in the
connection symbols if there are any broken connections and open connec-
tions.
45.4.1.51ReportScript
Example / Syntax:%N ReportScript.functionname%
This text function evaluates the options script of the report template. The
functions stored there can be called up and evaluated by means of ReportS-
cript.functionname.
45.4.1.52Requirement
Example / Syntax:%N Requirement[Index]%
This text function has the option of an optional index, either as an integer or
in string form, to access the elements of the reference object and to output the
implementation of same. If the index is missing, the text function supplies the
reference object with the requisite implementation.

45.4.1.53Rqmt
Example / Syntax:%N RQMT%
This text function supplies the device request of the reference object in the
same way as for Requirement, P. 45-29.
45.4.1.54Rqmts
Example / Syntax:%N RQMTS<Index>%
A short form for Requirement, P. 45-29, but in this case with mandatory input for
the index.
45.4.1.55Slot
Example / Syntax:%N Slot (“Parameter”)%
The Slot text function calculates the current location at which the reference
object can be found and outputs this (compare this with the Rack, P. 45-28 text
function). Possible optional parameters to control the output are:
• - L (AliasLabel)
• - D (Description)
• - N (Name).
45.4.1.56ToDoc
Example / Syntax:%N ToDoc.<>%
This function is used to implement links between different diagrams. ToDoc
supplies the target document of the link. For further information see the
Comos Core reference: IComosDDocument.
45.4.1.57ToDocObj
Example / Syntax:%N ToDocObj.<>%
This function is used to implement links between objects placed on docu-
ments. ToDocObj supplies the target object of the link. For further informa-
tion see the Comos Core reference: IComosDDocObj
45.4.1.58UserFunction
Example / Syntax:%TextScript.UserFunction1%

For free application. Up to three different user-specific script functions can be

stored per in the Text column of the Symbols tab under the designations
UserFunction1-3 . In this case an object is transferred as a parameter to the
function, by which access is provided to all the methods and properties of the
Comos Device and Document classes (read-only for BMKVisible ).
correctly and to the full, a considerable knowledge of program-
ming in VB Script and for the Comos object classes (see also the
Comos Core reference) is required, see also the Comos Core reference: ICo-
mosDDevice; IComosDDocument.
Pic. 45-33: Text function UserFunction1
Pic. 45-34: Example for UserFunction1
Pic. 45-35: Planning object structure and UserFunction1 output in the diagram
The user-specific %N texts are not restricted solely to UserFunction1-3,
Any desired functions can be executed in a script by means of TextS-
cript.<Functionname>%. The “<Functionname>” function (without brack-
ets) must then exist in the script.

45.4.2 Sub-symbols
Sub-symbols DETAIL RI SLINE

TEXT SYMBOL x/- x/x x/-
ELEMENT x/x x/x x/x
ATTRIBUTE x/x x/x x/x
BASE OBJECT x/- x/x x/-
45.4.2.1 Text symbol

Example / Syntax:*V*P TEXTPKT1*
Used in diagrams of type RI.
Example / Syntax:*V*P TXTPOINT*
Used in diagrams of type DETAIL.
These functions make it possible to create at the selected insertion point a for-
matted block with expanded output texts and graphics. This block is stored in
script form in the object in the Text column of the Symbols tab. The main
advantage of this functionality lies in the fact that is possible to easily reuse
the blocks once they have been created and suitably parameterized, they can
be saved at any desired location as a file, and from there they can be inserted
into other objects for further use.
Theoretically speaking, it is conceivable that you could set multi-
level nesting in the symbol architecture by means of these text
symbol capabilities. But please note that as a result it could take
considerably longer to set up the symbols and there could also be a risk of a
memory overflow.
45.4.2.2 Element
Example / Syntax:*V*P E:<Element name>*
This function allows the output of element symbol graphics. The parameter is
the name of the element. (System-generated texts of the elements do not give
any results at this point, since the reference object is always the owner of the
element.)
Example / Syntax:*V*P*E Symbol <Element label>

Please note: In contrast to *V*P E:<Element name>* the label must be passed
as parameter, not the name!
45.4.2.3 Attribute
Example / Syntax:*V*P S: <Tab>.<Attribute>*
This text function allows the output of attribute-dependent additional graphics
at the selected location. The additional graphics are located in a standard table
at the object and are addressed by means of the function parameters:
Tab Name of the tab at which the attribute is

located
Attribute Name of the attribute to be displayed
The following picture shows the atrribute section and selection attribute at the
object:
The following picture depicts the selection of the attribute to be displayed at

the planning object:
This picture shows the output of additional symbols via the attribute:

45.4.2.4 Base object

Example / Syntax:*V*P CD: <Base Object>*
This function allows the integration of additional graphics by means of the
base object structure. The SystemFullName of the base object serves as the
parameter, whereby the individual hierarchy levels are each separated by a
period (full stop) (for example: @[email protected]).
Usually a type of diagram that is like a symbol is used, but optionally it is also
possible to make use of a form of display from another type of diagram, to
which the “|” and the type of diagram are appended to the SystemFullName
(for example: @[email protected]|RI1).
The advantage of this variation is that you can access templates that had been
set up previously and stored in a Comos object while in operation. In this case
individual, automatically-generated planning object symbols can be created
according to the relevant current object properties.
45.4.3 Connection points
Connection points DETAIL RI SLINE

CONNECTION POINT x/x x/x x/x
45.4.3.1 Connection point

Example / Syntax:%N <Connection point name>%
This function makes it possible to create connection points with the following
properties in the first step:
• can be connected, label visible (Con1)
• can be connected, label not visible (Con2)
In the VB script these connectors have the corresponding labels ekP (visible)
and ek0 (invisible).

Pic. 45-36: Display in the Symbol editor

If descriptive or label texts that can be moved freely are to be created, the
desired texts can be allocated to existing connectors by the selection of:
• cannot be connected, label visible (Con2)
• cannot be connected, label not visible (Con2).
In the VB script these texts have the corresponding labels ek1 (Label) and ek2
(Description).
Pic. 45-37: Display in the diagram

If two correctors were incorrectly programmed with the same name in the
symbol script as the result of a mistake by the user, the error will be caught by
Comos: the duplicated connector is ignored (not created).

Symbol script Symbol-Designer
The texts for connection points can also be input in symbols without the %N
syntax. In other words: if a text has the “eK ” label, it makes no difference at
all whether you write CP1 or %N CP1%. However, for reasons of clarity and
consistency, it is recommended that you make a decision to use one or other
style throughout a project.
Please note that mistakes in programming (connectors with the same names)
can also cause problems at other points that cannot be caught beforehand by
Comos.
45.5 Symbol script

Please note that the creation of your own user scripts requires a con-
siderable knowledge of and experience with VB script program-
ming and of Comos object classes. Errors in scripts can lead to a
loss of data and system crashes!
Switch to the Symbols tab and mouse-click on the [S] button to write a sym-
bol script:
45.5.1 ScriptHeader commands
Script default commands Meaning

Function Geometrie Calls up the drawing function and transfers
(Param) the reference object.
ResetToDefaults Restores the default settings.
Header.Class = “eKP“ - Connection point, label visible, can be
used.
Header.Class = “eK0“ - Connection point, label not visible, can be
used.
Header.Class = “eK1“ - Connection point, cannot be connected,
only text output of the connector label.

Symbol-Designer Symbol script

Header.Class = “eK2” - Connection point, cannot be connected,
only text output of the connector
description.
Header.Class = “NOE” Classification only used in P&ID
documents, which prevents any changes
within the reports to the color and line
thickness of objects drawn subsequently.
Header.Class = “nv” Cannot be moved.
Texts of the same Header.class can only be moved together.
Header.Layer = " " Stipulates the drawing layer, layers > 200
are only displayed on the monitor.
Header.Color = Stipulates the display color in RGB mode,
RGB(r,g,b) numeric values between 0-255 for the colors
red (r), green (g), blue (b).
Header.LineTyp = " " Stipulates the line type:
1-continuous,
2-dashed,
3-dotted
Header.Width = " " Stipulates the line thickness.(In mm)
Set Pm = Coord ( X,Y) Stipulates the X- and Y-coordinates of point
Pm.
DrawArc Pm, Pn, Po Draws an arc that is determined in the
mathematically positive sense (ccw) through
three points:
- mid-point
- starting point
- end point.
DrawCircle Pm, Pn Draws a circle with Pm as mid-point and Pn
as point on the periphery of the circle. The
radius is the distance between Pm and Pn.
DrawLine Pm, Pn Draws a line between Pm and Pn.


DrawText Pm, “String”, Draws “String” as text with Pm as anchor
x, y point, x, y as justification.
x, y {0,1,2}
“String” can include text or text functions to
generate sub-symbols (see Sub-symbols, P. 45-
32).
45.5.2 Tips & tricks
45.5.2.1 Security
Calling up the Geometrie (PARAM) function can either transfer an object of
the Device/CDevice class or else nothing, depending on where it enters the
programming layer. If no Device or CDevice was transferred, queries to
objects and their properties that require a Device or CDevice can cause pro-
gram crashes. These can easily be avoided if you use the following script rou-
tine (example Device) by default:
Function Geometrie (PARAM)
ResetToDefaults
'Header declarations
If Not Param Is Nothing

If Param.SytemTypename = "Device"
'
'Here is the desired code
'
End If
End If
End Function
45.5.2.2 Container
Direct access to Reportlib-class “Object” and its methods can be undertaken
by means of variable “Container”. Using the following lines of script code:
If Not Container Is Nothing Then
DrawText p16, container.ComosDocument.Fullname, 1, 1
End If
the name of the report documents that had been placed on the object could be
output directly, for example.

45.5.2.3 CurrentTrans
Using the variable CurrentTrans (part of GeoEngine) gives you access to the
current symbol transformation, i.e., you can determine the following proper-
ties:
• Rotation
• Mirroring
• X/Y scaling
• Moving.
CurrentTrans supplies an object of the Reporlib.NTrans class. The
Assign3 method is the most efficient:
Sub GetTrans(Trans, Angle , ScleX, ScleY, Reflect ,x, y)
rf = IIf(Reflect, -1, 1)
a11 = rf * (Cos(Angle) * ScleX)
a12 = -Sin(Angle) * ScleY
a21 = rf * (Sin(Angle) * ScleX)
a22 = Cos(Angle) * ScleY
Trans.Assign3 a11, a12, a21, a22, x, y
End Sub
Example of a call for double scaling in both x and y and also mirroring:
GetTrans CurrentTrans, 0, 2, 2, True, 0, 0
45.5.2.4 Demo script for fill areas

On the basis of the following sample script, there is here a demonstration of
the complete or partial filling of areas in the Symbol Editor.
The symbol script begins with the Geometry (PARAM) standard function call,
restoring the default settings and giving the instructions for drawing layer,
line thickness and line color.
Function Geometry (PARAM)
ResetToDefaults
Header.Layer = "2"
Header.Width = 2
'Set line color to black
Header.color = RGB(0,0,0)
'Coordinates for triangle

Set p1 = Coord(10,-15)
Set p2 = Coord(10,0)

'Coordinates for red triangle

Set p6 = Coord(-15,20)
Set p7 = Coord(0,0)
'Additional coordinates for line

'Draw line
DrawLine p7,p8
At this point the fill color (e.g. blue) of the polygon to be filled must be stip-
ulated, since the CreatePath function will otherwise use the currently valid
color setting as the fill color.
Set p = CreatePath
If you wish to have a different color for the bonding lines of the object, the
color is input at this point (e.g., green).
The line drawing commands DrawLine( ) variables (e.g. ln1-4) must be

assigned in order to be able to use the AddElement function later.
'Draw green triangle
Set ln1 = DrawLine(p1,p2)
The fill polygon is stipulated by means of the AddElement function. If the

object (a rectangle in the case of this example) is only to be filled partially,
then the number of polygon elements is to be selected correspondingly so that
a polygon area is defined by at least 3 points joined together by lines. Creat-
Path fills polygons that are not enclosed up to the imaginary line connecting
the first and last polygon points. The graphic effects can be tried out by com-
menting out the individual AddElement instructions in this sample script.
'Stipulate polygon fill
'p.AddElement ln1
'p.AddElement ln2
p.AddElement ln3
p.AddElement ln4

A new fill color (such as light gray) is designated here and a new polygon is
defined:
'Stipulate fill color for triangle
Set p1 = CreatePath
The color for the bounding lines is now defined (for example, red), the line
drawing command variables are assigned again, and the AddElement function
to create the polygon is used multiple times until the Geometrie (PARAM)
function is terminated correctly by the End Function instruction.
'Draw red triangle

'Stipulate polygon fill
p1.AddElement ln5
p1.AddElement ln6
p1.AddElement ln7
End Function
The result should look like the following:
45.5.2.5 User-defined grab points

User-defined grab points can be generated very easily in the following way if
you follow the general syntax carefully:
Set Variable = Grab(Name,x,y,persistent,[Type],[Grid])
Variable Any desired variable (such as g1)

Name Designation of the grab point. (String)
x X-coordinates. (Double)
y Y-coordinates. (Double)
Persistent Stipulates whether the system is to store the new item.
(Boolean)

Type 0 = normal (default)

1 = origin
2 = rotate
3 = scale
Grid Determines the snap precision of the grab point (in mm)
Examples:
• Set g1 = Grab(“Lu”, 0, -2.5, true)
This is used to create a new movable grab point at the coordinates
(0, -2.5).
• If g1.x <> 0 or If g1.y <> -2.5 ...
Query as to whether the coordinates of the grab point have changed.
45.5.2.6 GetAllPropertiesAndMethodsByObject
Using the Workset.Lib.GetAllPropertiesAndMethodesByObject
(ComosObj) function, you get a collection that includes all the names of the
properties and method of the referenced Comos object.
These keywords are also transferred to the Script editor. Consequently the
Script editor recognizes the Comos variables and marks them in color. In this
way it is possible to avoid any possible problems due to the unintended or
incorrect use of Comos variables by the user.
45.5.2.7 Deactivating the scaling and rotation grab points

The scaling and rotation grab points can be influenced by definition of a glo-
bal variable (outside the Geometry function) in the Symbol script:
DisableScaleGrab = true
No scaling is possible via the grab points.
DisableRotationGrab = true
No rotation is possible via the grab points.
DisableXYScaleGrab = true
It is not possible to have different scaling for the X- and Y-axes.
Example:
'Changed on 19.02.03 by user BERNDK

'DisableScaleGrab = true
DisableRotationGrab = true
DisableXYScaleGrab = true
Function Geometry (PARAM)
ResetToDefaults
Header.Layer = "2"
Header.Width = 0.1
Header.LineTyp = 1


Report Designer Background: Types of diagrams
46 Report Designer
See also SECTION 43: DESIGNER (2D-DRAWINGS)!
Open Report Designer:
• | EXTRA | REPORT DESIGNER or
• | OPEN in the mouse menu for report templates or
• | OPEN DOCUMENT TEMPLATE in the mouse menu for Reports.
46.1 Background: Types of diagrams

Please note that reports are specific to the type of diagram. In other words, a
report is typically created for a specific type of diagram.
If an object is dragged onto a report, then logically only one symbol can be
displayed at the position where the object has been placed. The report must
“choose” one from all the symbols that have been created with the various
types of diagrams.
Fundamentally, a report can of course also display symbols from different
types of diagrams. You could place a list on a report and output one after
another the various symbols of an object within the list. But in actual planning
work with interactive reports objects are placed and exactly one symbol must
be displayed within this placing. The options script specifies which symbol
that is, see SECTION 46.4.2.79: SYMBOLTYPE (STRING).
46.2 General operation of the interface

See SECTION 43: DESIGNER (2D-DRAWINGS).
46.2.1 Toolbar
Control page display via a drop-down list

Switch between the pages or else create a new page.
Elements that are created on page 0 (the so-called “master page”) appear on
all the pages.
If you select a page and place elements on this page of the report template,
these elements will also only be output on this page when the report is run.

General operation of the interface Report Designer
46.2.2 Context-sensitive mouse menus
46.2.2.1 Insert object

| EDIT | PASTE OBJECT
Opens a dialog field that can be used to insert OLE objects:
Create new
This list offers all the programs included within the Windows Registry.
Create from file
A file can be selected here. Programs not included in the Registry can also be
linked in here.
Display As Icon
Off (template): The program is started in the background and you can work
within the report as if the report had the capabilities of the program that had
been started. The results are also displayed directly in the report.
On: The program is started. You cannot see the results in the report, all you
can see is the program icon.
Application
We recommend that you turn off the Display As Icon check box. When you
confirm this with [OK], first of all an external program is started up in the
background. Once you have completed your inputs, simply mouse-click out-
side the editing frame on the report. The external program is terminated and
its inputs are displayed.
Double-click on the inserted object to subsequently edit it.

Report Designer General operation of the interface
Properties
The | PROPERTIES command is available once you have marked the inserted
object. In this way you open the OLE document parameters dialog win-
dow:
Name
Each object can also be addressed via a script by means of the name. For that
reason the name should be unique.
P1, P2
The X- and Y-coordinates of the top left and bottom right points. If a coordi-
nate is changed, the object is stretched or squeezed accordingly.
Evaluation Sequence
Determines in what sequence the objects are to be evaluated.
This determines in what order the individual report items are to be calculated.
Since it makes no difference at all for the majority of objects in what order
they are calculated, Eval-Sequence only provides a rough rule for the
sequence: All objects with EvalSequence 0 are calculated before all report
items with EvalSequence 1, and so forth. No order of calculation is applied to
objects with the same EvalSequence number.
Scale
Self-explanatory.
Edit in Comos
If this option is deactivated, the object cannot be opened and edited within
Comos.

General operation of the interface Report Designer
Size
Always in the original size: The object protrudes over the edge of the frame if
necessary. With this option the frame cannot be changed in size, since the
frame is simply ignored.
Reduce: The frame determines the maximum size and the object is reduced to
fit as required.
Enlarge or reduce: The frame determines the maximum size and the object is
always optimally sized to fit within the frame when the frame is changed.
46.2.2.2 Import / export scripts

| EDIT | COPY ALL SCRIPTS TO THE CLIPBOARD
The scripts are copied from all the objects and transferred to the Windows
Clipboard. The Clipboard can be loaded into any text editor or word processor
that you wish and there edited. If the edited version is copied back to the Clip-
board, the script can be transferred back to the correct objects with the aid of
the next command.
| EDIT | PASTE SCRIPTS FROM THE CLIPBOARD
Only appears once the scripts have been transferred. Transfers the edited
script back to the objects.
46.2.2.3 Correction function

| EDIT | CORRECT... OLD TEXTS
It could happen in earlier versions that the edit property (Edit (general) or
Attribute ), with which texts could also be changed within the planning
project, could be accidentally transferred to objects for which this property
was irrelevant. Functionally speaking, this did not cause any problems, but
this could create unwanted visual effects such as green text fields.
If the | CORRECT OLD TEXTS WITH EDIT-OCX command is executed, the edit
property is deleted in the case of texts for which it is not relevant or needed.
Text types Script or Item, Property are not changed.

Report Designer General operation of the interface
46.2.3 Options: worksheet parameters and script
Settings that involve the entire worksheet can be made by means of the Opti-
ons :
Grid
Print
On: the grid is superimposed on the report when it is printed.
Off: the grid is not printed.
Display
On: the grid is superimposed on the report when it is displayed.
Off: the grid is not displayed (but is still used).
Gap
Select from the drop-down list a size for the grid spacing or input a value from
the keyboard. Grids can be specified with up to four decimal places to permit
more precise conversion into other units of measure.
Document size
It is possible to input X for the width and Y for the height in the document size
area if no master report was stipulated. If a master report is used, this then
determines the size and inputs that are possible.
Settings
[TEXT]: The dialog box for the text parameters opens here. Select a Type and
stipulate the properties. The selected Type is offered as a template if the Posi-
tion text function is used.
[LINE]: These entries are regarded as templates when a new line is drawn.

The toolbar Report Designer
Master report
Selects the template file of a master report. The master report is a template file
that is used in many ways. Example: A template file is created with a com-
pany-specific header and footer, to give an example. This template file is
locked.
Master reports can also be incorporated in a relative way by means of “..\”.
A new template file is created and the previously created file is inserted to act
as the master report.
The master report can thus be incorporated into several template files. Typi-
cally a “child frame” is created within the master report, this being the space
that is left as a working area for the “independent” template file. This is done
by moving the upper left-hand point of the “independent” template file onto
the upper left-hand point of the child frame in the master report. All the ele-
ments of the current report are correspondingly moved as well at the same
time.
[ Script area]
A script that is to apply to the entire report template is input in this field. This
includes, for example, global variables or the system calls for the user inter-
faces of interactive reports.
These variables can be accessed in a script of the report with Report. as a pre-
text. Example: Report.RpVar accesses variable RpVar in the options.
The Document size and Master report fields have a logical relation: When
a master report is selected, a template file becomes a “child report”. Fre-
quently an area. The size stipulated for the template file within the Document
size field should match the size of the area to be used in the master report.
46.3 The toolbar

See also SECTION 43: DESIGNER (2D-DRAWINGS).
46.3.1 Placing texts
Toolbar of the Designer, tool: Text

Report Designer The toolbar
46.3.1.1 Text Defaults

When you activate the Text tool, you can set the defaults for all new
texts in the Text parameters dialog window. See SECTION 46.3.1: PLA-
CING TEXTS.

“Text” is an overall term within the Report Designer for all the possible
options affecting the input or output of text. In addition to static text such as
the address of a company, this also covers script text for programming.
| PROPERTIES
If you right-click on a line, you can open the Text parameters dialog win-
dow via the | PROPERTIES mouse menu command:
The following text types are offered:

• ReportObject-Property
SECTION 46.3.1.4: TYPE “REPORTOBJECT-PROPERTY”
• Expression
SECTION 46.3.1.5: TYPE “EXPRESSION”
• Script
SECTION 46.3.1.6: TYPE “SCRIPT”
• Item-Property
SECTION 46.3.1.7: TYPE “ITEM-PROPERTY”

• Fixed
SECTION 46.3.1.8: TYPE “FIXED”
• Attribute
SECTION 46.3.1.9: TYPE “ATTRIBUTE”
Tabs:
for all types: General and Properties
type-dependent: various switch tabs.
Type “fix” excepted, the final text of the text variable is determined both by
the type of the variable and the “object of the report”.
In many case the desired result can be achieved in a number of different ways.
The Name property of the “object of a report” can be addressed directly via
ReportObject-Property ; this works in exactly the same way as using
Expression ReportObject.Name. The same result can be achieved as well,
but with rather more effort, by using a script. The user can choose for himself
or herself which types of text are better for a particular situation.
You can stipulate with | OPTIONS which type of text is to be offered as a tem-
plate when a text is placed.
A text is placed by dragging a text frame from the top left to the bottom right
by means of the Text tool. The result is that a placeholder text is visible (the
text frame is not visible initially). If no text frame is drawn by dragging but
the text is only to be placed by mouse-clicking, the text is given an invisible
“placement point”. The text can be marked by means of a mouse-click in the
(initially invisible) text frame or on the placement point.
46.3.1.3 Properties window
General window area

Top:
Pull-down menu Type: For information on the various types refer to the sub-
sequent chapters.
Bottom:
Checkbox “Apply immedeately ”
All settings that are done after activating this checkbox are immedeately
applied in the Report Designer. The report does not need to be re-evaluated
before the results of the settings can be seen.

The “General” tab

Name
Each object can also be addressed via a script by means of the name. For that
reason the name should be unique.
P1, P2
The X- and Y-coordinates of the top left and bottom right points. If a coordi-
nate is changed, the object is stretched or squeezed accordingly.
Eval-sequence
Determines in what sequence the objects are to be evaluated.
This determines in what order the individual report items are to be calculated.
Since it makes no difference at all for the majority of objects in what order
they are calculated, Eval-Sequence only provides a rough rule for the
sequence: All objects with EvalSequence 0 are calculated before all report
items with EvalSequence 1, and so forth. No order of calculation is applied to
objects with the same EvalSequence number.
Edit-OCX
Whether or not this option can be set depends on the type of text.
Possible values:
• Edit (general) : Selection field with editing option.
• Specification value : In the case of subsequent editing, the value of the
attribute is edited in all cases, regardless of which property was input.
The Property field can remain blank for the Edit-OCX Attribute value .
The property that had been input is displayed when the report is
evaluated. The entry changes into the attribute value when editing after
the report has been evaluated.
• Edit (query)
• Not editable : Selection field for the value, without editing option.
Re-evaluate per page
If a text variable is placed on the All pages “master page”, the value appears
on each page of a multi-page report. However, the value is only generated
once and the output is the same on all the pages.
If the text value is to be recalculated on each page, the Reevaluate per page
field must be marked.

The most frequent use for this option is for output of the current page number:
place the text in the template file on All pages . Select Expression as the
Type and edit the field of the PageNr expression. The Re-evaluate per
page option is to be marked on the General tab. The current page number
then appears on each page.
The “Properties” tab

This tab is identical for all types:
Most of these options correspond to the options provided in the dialog win-
dow in which the defaults are set, see SECTION 43.2.4: PLACING TEXT.
The following options are new:
Angle :
Rotates the text around its placement point. If the text is rotated by means of
the mouse, then the new angle is automatically written to this attribute.
Options group “Display mode ”:
Group of radio buttons:
• “Show text unchanged”: The complete text is displayed as it was entered in
the Texparameter dialog.
• “Cut oversized texts”: Text that protrudes from the text frame is cut.
• “Fit oversized texts”: The font size is adjusted, so that the text fits into the
given text frame.
• “Wrap too long texts”: Line wraps are inserted to be able to display the
whole text.

Checkbox “Adjust height automatically”: In addition, the text frame is scaled

to include the complete text.
The Change tab

The rear tab changes according to the Type selected. The corresponding
explanations are given in the following section.
46.3.1.4 Type “ReportObject-Property”

Each report must have a “report object”. The ReportObject possesses various
properties that can be addressed, depending on the object type. A number of
the most frequently used properties are offered by a drop-down list:
• Name
• Description
• Value
• DisplayValue
Apart from these properties, which exist for virtually all object types, any
other ones can also be input. In that case the user must ensure by himself or
herself that the property being addressed also exists in the ReportObject. In
other words: you should know beforehand to which object type the ReportO-
bject belongs. For example, if a unit is set as a “report object”, the property
CDeviceFullName that outputs the path to the base object of the ReportObject
can be addressed.
The result is output as text in the report.
46.3.1.5 Type “Expression”

This type of text is frequently used to call up key objects that are not linked
with the “report object”, for example:
• Date
• PageNr
• MaxPageNr
• GlobalPageNr
The drop-down list offers you as an example a number of properties of the

ReportObject object (in day to day use it might be quicker to call up these
properties as text type ReportObject-Property ):

• ReportObject.Name
• ReportObject.Description
• ReportObject.Value
• ReportObject.DisplayValue
46.3.1.6 Type “Script”

With this setting it is possible to write code for more complex instructions.
For that reason there must be a syntactically correct instruction here (such as
Text = ReportObject.Name).
The code can also extend over several lines.
Example 1:
Dim User
Set User = ReportObject.Workset.GetCurrentUser()
Text = User.Name
Here Text does not represent a variable, but is instead the output function for
text.
Example 2:
Dim Uservar
Set Uservar = ReportObject.Workset.GetCurrentUser()
if Not Uservar is Nothing Then
Text = Uservar.Name
else
Text = "Undefined!"
endif
Example 3: Text allocations

A function that is often used in a script is the allocation of properties to the
predefined text output function Text. Here are a number of examples:
Text = ReportObject.Unit
Supplies the unit of the object.
Text = ReportObject.CDevice.Manufacturer.Description
Supplies the description of the maker.
Text = ReportObject.Ordertext
Supplies the ordering text of the object.
Text = ReportObject.Fullname()
Supplies the name of the superordinate object and of the object itself.

Text = ReportObject.CDevice.BackPointerDevices.Item(1). Name

Supplies the first device of the same device class within the entire project, or
more precisely, the last device. The list is scanned starting from the end.
Text = ReportObject.Owner.Name
Supplies the name of the superordinate object.
Text = ReportObject.Owner.Owner.Name
Supplies the name of the object that is superordinate by two hierarchical lev-
els.
Example 4: Change static texts

Static texts of text type Fixed can have a value assigned directly with the aid
of a script.
The report is accessed with the “ReportDocument” expression. A text that has
been placed on a report has a name such as “Text5”. The text can be addressed
with this name. The following syntax applies:
ReportDocument.Item("Text5").Text = "Example text"
46.3.1.7 Type “Item-Property”

It is possible to access and change the properties of objects via the report with
the aid of these text types. (Text types ReportObject-Property or Expres-
sion only allow read access.)
The following edit fields can be filled in on the Item tab:
Item An object must be input as an item, this
being, for example, an attribute, a planning
object, etc.
Property The property to be input or selected must be
one that can be edited, such as Name,
Description, Value, DisplayValue.
A simple example makes the principle clearer:

Item ReportObject
Property Description
Edit-Ocx Edit (general)

Colored marking of the text frame: the frame is shown in green in the template
file if it involves types of text that can be edited within the planning project.
If the report is opened within the planning project (or if the template file is
evaluated) the description of the “report object” is displayed. The description
can be overwritten with keyboard input, the new description that has been
input is saved within Comos. A new description is allocated to the object
within the planning project.
46.3.1.8 Type “Fixed”

A text of type Fixed is purely static, example being captions, headings, com-
pany details, etc. The contents of the text window are displayed in the report
exactly as input.
On the Text tab you can enter translations of this text for various languages.
46.3.1.9 Type “Attribute”

Dialog-controlled output of attributes. In this, an attribute that has already
been defined within the project is accessed. Logically enough, this function
presupposes that the report template has already been connected with an
object by means of the | ROBJECT menu.
In the event that an attribute of type Text is accessed (Properties window of
the attribute, General tab, Type field: “Text”), the dialog window only
shows the Format max. length edit field, in which you can input the maxi-
mum number of characters allowed. If the text is longer than that, it is trun-
cated and “...” is displayed.
The dialog window is somewhat more complex in the event that an attribute
of type Numeric is accessed:

Field/Option Sub-value Meaning

Object Opens the Define object path win-
dow.
Attribute Opens the Select attribute Explorer
window, in which you can mouse-click
on an attribute.
Index
Unit Current unit Uses from the units group the unit that
is current at the time.
Default unit Uses the unit that had been defined in
the units group as the default setting.
SI unit Selects from a units group (such as
temperature) the international
conversion unit (in the case of temper-
ature: Kelvin).
Other unit Makes it possible to select one of the
other units from the units group.


Defines the number of decimal places.
The value is rounded off after 6. For
example, in the case of four decimal
places: 1.12345 is rounded off to
1.1234; 1.12346 is rounded off to
1.1235.
Decimal Windows Uses the separator defined as the
separator default default within Windows. The Windows
default differs according to the lan-
guage used, for example.
, Uses the comma (German default).
. Uses the period (full stop) (American
and British default).
Exponential Transforms the value into an exponential function if...
format
Do not use -
For value ... the value is within the user-defined
range range of values (e.g., greater than
Exp5).
For max. ... the display of the value exceeds the
characters maximum characters length (number
length of characters). This option is useful if
only a fixed number of characters is
available for the display of lists.
Always use Always.
Allow value If this Explorer window has not been
input activated, it is also not possible to input
any values if an attribute of type Edit or
Edit/Combo was selected.
Any attribute within the project can be selected. When the Explorer window
is opened for the first time, it can be seen as the initial starting basis for the
“report object”. You can now maneuver to any point within the project from
this initial starting point.

When you mouse-click on this initial starting basis, the linked objects are dis-
played in the right-hand window area:
These can be “owners”. These can be subordinated objects (which are also
called “child objects” in the dialog window).
Double-click on one of the objects in the Go to window in the left-hand win-
dow and the “parent objects” and “child objects of this object are displayed:
You can undo any inputs made by selecting an entry from the list in the right-
hand window and selecting a new child object from there.
Normally the Script tab should not be used with text type Attribute .
For advanced users: The “GetSpecOwner” function can also be modified
manually within the automatically generated script. This gives you the option
to set as you wish the owner of the attribute and also any other parameters.
(for example, so as to create XValue lists that can be edited).
46.3.2 Switch / Options switch
These design elements are primarily used in Evaluation Reports and

serve as a form of display of an attribute.

46.3.2.1 General tab

Self-explanatory.
46.3.2.2 Properties tab

Can be edited : the element can be changed within the report.
Value : 0 = turned off in the settings;
Value : 1 = turned on in the settings.
46.3.2.3 Type “ReportObject-Property”

Each report must have a “report object”. The ReportObject possesses various
properties that can be addressed, depending on the object type. A number of
the most frequently used properties are offered by a drop-down list:
• Name
• Description
• Value
• DisplayValue
Apart from these properties, which exist in almost all object types, any other
one can also be input. In such a case the user must ensure by himself or herself
that the property being addressed actually exists in the ReportObject. In other
words: you should already know to which object type the ReportObject
belongs. For example, if a unit is set as a “report object”, the CDeviceFull-
Name property that yields the path to the base object of the ReportObject can
be addressed.
The result is output as text in the report.
46.3.2.4 Type “Expression”

This type of text is frequently used to call up key objects that are not con-
nected with the “report object”, as for example:
• Date
• PageNr
• MaxPageNr
• GlobalPageNr

The drop-down list offers you as an example a number of properties of the

ReportObject object (in day to day use it might be quicker to call up these
properties as text type ReportObject-Property ):
• ReportObject.Name
• ReportObject.Description
• ReportObject.Value
• ReportObject.DisplayValue
46.3.2.5 Type “Script”

With this setting it is possible to write code for more complex instructions.
For that reason there must be a syntactically correct instruction here (such as
text = ReportObject.Name).
Several lines of program code can also be input at this point.
Please see SECTION 46.3.1.6: TYPE “SCRIPT” for some examples.
The report is accessed with the “ReportDocument” expression. A text that has
been placed on a report has a name such as “Text5”. The text can be addressed
with this name. The following syntax applies
ReportDocument.Item("Text5").Text = "Example-Text"
46.3.2.6 Type “Item-Property”

Unlike with the same setting for text fields, only read access is possible here.
For that reason no Edit-OCX is input either here.
Item
An object must be input as an item, this being, for example, an attribute, a
planning object, etc.
Property
The property to be input or selected must be one that can be edited, such as
Name, Description, Value, DisplayValue.
46.3.3 Determining the working area / setting the origin
This function is used when a master report is created. An area can be

drawn in within the master report that is to be reserved for the “child
report”. The placement point is used if no area was stipulated for the child
report. The placement point can easily be recognized by two green concentric
circles.

Keep within the area intended to be used for the child report. If you work in
the child report outside this area (which is technically feasible), this can cause
graphic overlapping between elements of the master report and of the child
report.
Only one area for child reports is possible per master report.
Determine the area to be used for the child report as follows:
• Press the Define working area / Set point of origin button.
• Mouse-click on a point within the report.
• Draw a rectangle (invisible) while holding the mouse button down. The
upper left-hand point of the placement area is at the same time also the
placement point.
Within the master report the area reserved for the child report is shown with
a green cross-hatched frame. Within the child report the area reserved for
the master report is shown with red cross-hatching, as a mirror image, as it
were.
• Alternative:
If only the placement point is to be moved, click once on the working area.
The placement point has a special significance: it determines the new origin
of the child report. In other words: the upper left-hand point of the working
area of the child report is moved to the placement point.
The remaining area for the child report only has a visual function.
The area cannot be moved with the mouse! You have to repeat the procedure
again if you are not satisfied with the results.
The child report and the master report should match each other. If the place-
ment point is moved, the entire child report is moved. Ensure that no elements
of the child report are pushed over the edge as a result. We recommend that
you check the child report if the placement point is moved or changed.
46.3.4 Place Windows metafile
The import function for Windows metafiles is especially useful for the
importing of AutoCAD files. The AutoCAD files must have been
exported beforehand in WMF format within AutoCAD to be able to do this.
To place a Windows metafile:
• select the Place WMF picture button,
• drag out the placement frame,

• switch to the Identifier tool

• and right-click on the placement frame. Now you can input the file name.
There are three tabs in the dialog window: General , Script and AutoCAD .
The General tab
Field/Option Sub- Meaning

value
Name Any object can be addressed by a script via
the name. For that reason the name should be
unique.
P1 1st field, X-coordinates and Y-coordinates of the top
2nd field left-hand point of the placement frame.
P2 1st field, X-coordinates and Y-coordinates of the bot-
2nd field tom right-hand point of the placement frame.
WMF file Opens an Explorer window to allow a WMF
name file to be selected.
Scaling Always The picture protrudes beyond the placement
in frame, possibly on two sides.
original
size...
With The picture is stretched to fit the frame.
stretch-
ing
Without The picture is not stretched or distorted and
stretch- protrudes beyond the placement frame, pos-
ing sibly on one side. The zoom factor of the pic-
ture is determined on the basis of the height
or width of the frame.
Reduce The picture is automatically zoomed without
if... stretching unitl it fits in the frame.
The Script tab

Not required for WMF files as a rule.

The AutoCAD tab
Mapping Determines the file type with AutoCAD

regarding line thicknesses, etc. Comos sup-
ports AutoCAD line thicknesses by the sim-
ulation of the corresponding AutoCAD
mappings read from .PCP files.
No
map-
ping
Default Use the mapping file specified in the PCP
map- file for default... field. The Default map-
ping ping setting applies to the entire report, and
hence also for all placed metafiles.
Current Use the mapping file specified in the PCP
map- file for current... field. Each placed metafile
ping can possess its own current mapping file.
PCP file for Using [->], the PCP file that is to be used as
default... a template for the entire report can be
selected.
PCP file for Using [->], the PCP file that is to be used
current... especially for the placed metafile can be
selected. The field becomes active when
Mapping is toggled to Current mapping .
Show colors Template is activated. If this options field is
deactivated, the drawing is only shown in
black and white.
46.3.5 Place picture frame

This tool is used to incorporate bitmaps. This makes it possible to
output within reports any symbols and bitmaps that had been loaded
with LoadPicture ("Name") (or made available via Comos).
If you are familiar with the syntax, the Place text function can be used
directly and this does not require the Place attribute function. However, the
latter has the advantage that any possibility of syntax errors is automatically
excluded.

46.3.6 Place list
This function places a list frame and thus determines the space that is
to be taken up by a list for preference. The list frame behaves here in a
similar way as it would within CAD systems: if information sticks out beyond
the list frame, it is still displayed nonetheless.
A list always consists of a list frame and a sub-report.
46.3.6.1 Place list frame

A list frame has two fixed conditions that must be taken into consideration:
the placement point and the direction of expansion.
All the elements of the list frame are set out starting on the basis of the place-
ment point.
The placement point is set by the position at which you started to drag out the
list. (The list should always be dragged out from the top left to the bottom
right, since most of the functions expect that the placement point is at the top
left.) In other words: the placement point determines the absolute position,
relative to which the elements of the list are placed. If a position of -10 mm, -
10 mm is specified for an element, it would be drawn 10 mm to the left of and
10 mm above the placement point in the diagram.
The direction of expansion determines the size in the direction in which the
list is to be set out. If the list frame is created with the normal direction option
(from top to bottom), the height is the direction of expansion.
The relationship of the sub-report to the direction of expansion of the frame
of the list is used as the factor when a page break is made. For that reason the
frame of the list should always be an exact multiple of the sub-report. If the
normal option was used: If the sub-report is 10 mm high and the frame of the
list is 80 mm high, the sub-report could be called up for up to a maximum of
ten times before a page break was made.
• Press the Place list button.
• Draw with the mouse and the button held down a rectangle from the top left
to the bottom right. Ensure that the list is made in this direction and not vice
versa.
In the template file the list is displayed by a dashed frame with two diagonal
lines.
• Switch to the Identifier tool and mouse-click once on the frame of the list.

• Right-click once on the frame of the list.
Lists can only be created above a specified minimum size. This prevents the
accidental creation of lists of size “0”. The list can be reduced in size once it
has been created.
A list must be at least of size 15x15 for a 5 grid. In general, that is three rows.
If the list is to be only two rows high, it can be reduced in size later. Mouse-
click once on the list frame and use the grab points at the corners and in the
middle of the delimiting lines.
46.3.6.2 List parameters (properties of the list)

In the List parameters dialog window you have three tabs available: Gene-
ral , Rows and Script .
46.3.6.2.1 General tab

value
Name Any name, but it must be unique.
P1 1st field X-coordinates of the top left point.
2nd field Y-coordinates of the top left point.
P2 1st field X-coordinates of the bottom right point.
2nd field Y-coordinates of the bottom right point.
Direction Direction in which the list frame with the
sub-reports is to be filled.
Size variable Option for a list that is used within a sub-
report. The option permits each row of
the list to take up a variable amount of
space in the superordinate list.
In a “normal” template file the space that
a list is allowed to take up is determined
exactly. A page break is made if the con-
tents of the list require more space.

46.3.6.2.2 Rows tab
Collection
Edit field:
This stipulates which “collection” applies to the list or is to be used. Report-
Object is offered as a template value.
File name
The file name of the template file with the sub-report. As usual, mouse-click-
ing on [...] opens the Explorer window.
Object query
This option uses the definition of a default query as the source of the list. See
SECTION 46.3.1: PLACING TEXTS regarding the default queries.
46.3.6.2.3 Script tab

A small script example is shown as an example to provide help with inputting:
' Public Variables

Dim n1 Variable n1 is created
Sub OnCreate () Event is triggered when the list is
created

For i = 1 to Col.Count Variable Col must of course be

' Set Public Variables specified by the use, e.g., a col-
' referenced from Sub/Row- lection. The length of the collec-
' Report as ReportObject.n1 tion is queried with Count.
n1 = Col.Item(i).Name The elements are called up one

' OR =========== after another from the collection
' Set ItemObject used as and the name is queried.
' ReportObject in Sub/Row-
' Report as
ItemObject = <somename>.CRp The template file of a sub-report

' Set a different Filename is called up. This call overwrites
' per Row any details on the Rows tab.
Filename = <somename>.CRp
EvalOneRow The sub-report is executed with

next “EvalOneRow”.
End Sub
Using parameter SetLineWrap in the list script makes it possible to determine

for sub-lists that these have breaks at the frame of the sub-list and not at the
frame of the “Level 0 list”, this being the list that is at the top of the hierarchy.
If the sub-report contains a value that can be edited, the EvalOneRowObject
Spec, "" command must be used:
EvalOneRowObject Spec, "" Spec is any desired variable. Since

the command expects two parame-
ters, but only one is required here,
the , "" transfers a “Nothing” for
the second parameter.
A list can make use of various sub-reports (row reports). Since only one sub-
report can be specified on the Rows tab, a script must be used to make use of
multiple sub-reports.
An entry in the Rows tab has no meaning if a sub-report (row report) is stip-
ulated within the script.
A sub-report is input with the keyword Filename, e.g.:

Filename = "Liste1_Z1.CRp"
It is important to note that the extension “CRp” must be included as well. The
example also demonstrates a convention that is useful for the management of
the template files: the name of the list (or of the template file with the list)
should be given before the underscore, and after the underscore there should
be a label for the row report with a sequential number.
46.3.6.3 Create sub-report manually

Technically speaking, there is no difference between a “normal” template file
and a sub-report. The difference lies in the use and thus the design of template
files. A sub-report has:
• as a rule a small working area, mostly only one row high (5 mm for a 5 grid),
• as a rule one or more text fields with which the values of the list can be
output,
• no master report. In the case of sub-reports the master report is ignored if
one is stipulated. If applicable, you can resort to making use of the
techniques of sub-reports to use a master report in a sub-report as well.
Within the sub-report you can access variables of the list frame, as follows:
• define Sub onCreate() with Dim variables on the Script tab of the list
frame outside the procedure,
• assign values to the defined variables within procedure Sub
onCreate()e.g. with at a For... next loop,
• use text type ReportObject-Property within the sub-report, and
• input as the property the name of the defined variable in the Property field.
Lists in sub-reports
A sub-report can in turn include a list (or any other object of the Comos
Report Manager). This list is often anchored directly to the bottom edge of the
working area and called up with the Size variable option.
This option allows the list to make use of the space of the superordinate list
frame in a variable way.
Often it is desired that a list that has been placed in the sub-report is oriented
towards the list frame of the sub-report and not towards the list frame of the
Evaluation Reports in terms of the space requirements. A row break is gener-
ated in the subordinated list frame by means of the SetLineWrap command

(see the next section). This means that the subordinated list frame is set up
again instead of the superordinate list frame and the list does not leave the area
of the stipulated space within the subordinated list frame.
Example for a list

To list the name and description of all the devices of a unit:
• Use as the sub-report a template file that includes two text fields of type
ReportObject-Property . The text fields include the instructions Name and
Description on the Property tab.
• The Collection field of the list frame can remain blank (the template
ReportObject. can remain as it is)
• Script in the list frame:
Dim Name
Sub OnCreate ()
SetLineWrap
Set Col = ReportObject.ScanObjectsbyClass("Device")
For i = 1 to Col.Count
Name = Col.Item(i).SystemFullname
EvalOneRow
next
End Sub
The desired unit must of course be set as the “report object”.
46.3.6.4 Automatically generate sub-reports

1. A new report template is created in the base project on the Documents
tab in the CRP Report templates folder. A template file is allocated to
the report template in the usual way, for example, a blank template file
from folder Reports\MasterReports.
2. Create one or more object queries in the base objects.
3. Mouse-click on the report template and use the | NEWS OBJECT context-
sensitive mouse menu. On the System tab assign to the new object one
of the object queries that had been created.
4. Switch to the planning project and create an Evaluation Report. On the
Report tab assign to the report the report template that had just been
created.
5. Right-click on the Evaluation Report and use the | OPEN DOCUMENT
TEMPLATE command. Create a list in the template file. Select the list and
select | PROPERTIES.

6. Switch to the Rows tab in the properties of the list.

Default row option:
Automatically generates a display of the results of the query.
Option “Generate title ”: When the results of a query are displayed in the
Evaluation Report, the text from the column header appears as a title row
at the top of the list of results in the object query.
Option File name:
Here you can use a row report for the title row and three grouping layers
respectively in the case of grouped object queries.
The first edit field controls the appearance of the title row above the filled
row report.
The following three edit fields control the appearance of grouping layers
1, 2 and 3. The groupings are set within the object query itself: | DRAFT
| SORTING/FILTER.
7. The “ReportObject ” or “Project ” options: Determine where the object
query is to begin with the evaluation. The ReportObject is stipulated in
the Properties window of “Evaluation Reports” on the Report tab in the
Object field.
8. Open “Evaluation Report”. The object query is executed and displayed
automatically.
You can also copy the object query and insert it into the planning project
under the Evaluation Report (do not change the name when doing this).
You can modify the local copy as you wish.
46.3.7 Place sub-report
A sub-report includes default parts of reports that are used again and
again in this particular context. This avoids having to input the infor-
mation again from scratch each time.
The difference between master reports and sub-reports lies in the logical hier-
archy of the linked template files:
Master Template
report file 1

Template
file 2
Template Sub-report
file X 1
Sub-report
2
A master report is thus the subordinated “clip” for template files, a template
file is the superordinate “clip” for sub-reports.
The sub-report must be called up at least once to become active so that the
contents can be displayed. The easiest way to do this is if there is at least the
following entry on the Script tab:
Sub OnCreate ()
SetItemObject = ReportObject
End Sub
Place sub-report
• Press the Place sub-report button.
• Draw with the mouse and the button held down a rectangle from the top left
to the bottom right. Ensure that the sub-report is made in this direction and
not vice versa.
In the template file the sub-report is displayed with a double frame.
• Switch to the Identifier tool and mouse-click once on the frame of the sub-
reports.
• Right-click once on the frame of the sub-reports.
The General tab

value

Name Any desired name, which must be

unique.
P1 1st field X-coordinates of the top left-hand point.
2nd field Y-coordinates of the top left-hand point.
P2 1st field X-coordinates of the bottom right-hand
point.
2nd field Y-coordinates of the bottom right-hand
point.
Size variable This option is not required as a rule.
The SubReport tab
File name The file name of the template file of the sub-
report. As usual, mouse-clicking on [...]
opens the Explorer window.
Item Here yo can stipulate which “item” (an item
is a special object type) is to apply for the
sub-report or which is to be used. The Repor-
tObject template value can be retained, even
if an object is not called up actively.
The Script tab

Here you can define variables that are to be used in the sub-report or also input
into complex programs. The following text should be input as a minimum,
since otherwise the sub-report is not displayed:
Sub OnCreate ()
EvalOneRow
End Sub
46.3.8 Graphic objects
“Graphic objects” in reports are objects that have no counterpart in the data-
base and only exist within the report. In other words, lines, circles and the like.
How to place a graphic object:

• Press the Place graphical object button.

• Drag out a frame with the mouse
• Switch to the Identifier tool
• Right-click on the frame.
The result is that you get an Object Parameter dialog window. This window
includes the General , Rows and Script tabs.
The General tab

value
Name Any desired name, which must be
unique.
P1 1st field X-coordinates of the top left-hand point.
2nd field Y-coordinates of the top left-hand point.
P2 1st field X-coordinates of the bottom right-hand
point.
2nd field Y-coordinates of the bottom right-hand
point.
Direction As a rule this option is not required here.
Variable size As a rule this option is not required here.
Note also that all report objects can be addressed by name within scripts. You
can use self-allocated names in scripts.
Note that you should drag out the frame from top left to bottom right. Other-
wise errors can arise concerning the placement point of the frame: the pro-
gram always expects the placement point to be at the top left. If you made the
frame in some other way, then, for example, objects will be drawn outside of
the frame on the basis of the starting point as the placement point.
The Rows tab

It is not required here.

The Script tab

On this tab is listed the script by which the graphic is to be drawn and a sym-
bol is to be accessed. There are two applications for this: script-oriented draw-
ing and script-oriented access to the symbols of the base devices.
Script-oriented drawing
Sample script for the Script tab:
Dim g Although not strictly necessary

from a technical point of view, vari-
ables should always be declared
within the sub-routine.
Sub OnCreate()
set g = GeoEngine(True) Assignment of the drawing object to
the variable.
g.Header.Layer = "2"
g.Header.Width = 0.3 Line thickness
g.Header.Class = "@@@"
Set p1 = g.Coord(0,5)
g.DrawLine p1, p2 Start and end points for a line.
g.DrawLine p3, p4
Set p5 = g.Coord(7,15.5) Arc segment:

Set p6 = g.Coord(8,15.5) 1st coordinates: mid-point (X,Y)
Set p7 = g.Coord(8,15.5)
2nd coordinates: 1st segment point
g.DrawArc p5, p6, p7
3rd coordinates: 2er segment point
A circle is drawn if the 2nd and 3rd
End Sub coordinates are the same.
The coordinates are based on the bottom left-hand point of the frame.
Script-oriented symbol access

Sample script for the Script tab:

' Public Variables

Dim Sym
Sub OnCreate()
set sym =
reportobject.devsymbols.item ("DETAIL") Assignment of the
gengeometrie sym.script, nothing symbols for the type of
diagram
End sub Output of the variables.
An object can be trans-
ferred with the second
parameter.
This assignment assumes that the object of the report includes a symbol for
type of diagram “Detail”. Any other object can be used instead of reportob-
ject, but then the corresponding path must be set with the set command.
46.3.9 Place attribute
The Place attribute button opens an interface so that attributes that

had already been created can be selected.
The attribute must be of type Numeric .
Normally the results are translated into a text field of type Expression . If you
are familiar with the syntax, the Place text function can be used directly and
this does not require the Place attribute function. However, the latter has the
advantage that any possibility of syntax errors is automatically excluded.
If the Can be edited option is activated for a DisplayValue , a text field of
type Item-Property is used.
How to place an attribute:
• Press the Place attribute button.
• Select the settings from the following dialog box

:
Pic. 46-1: Place attribute

Attribute for Object Accesses an attribute of an object. In
the script syntax this option is of
equal importance to key term OSpec.
Project Accesses an attribute of the project.
In the script syntax this option is of
equal importance to key term PSpec.
Document Accesses an attribute of a document.
In the script syntax this option is of
equal importance to key term DSpec.
Text All The three text fields for Value, Des-
cription and Unit are placed.
Value A text field for DisplayValue is

placed.
Editable This option allows user input in
interaction with the Value property.
Description A text field for Description is
placed.
Unit A text field for Unit is placed.
Tab The tabs that are available for the
object are displayed.

Script options in reports Report Designer
[Display field] The attributes that are available on

the tab are displayed.
• Mouse-click on a point in the report.

• Drag out a frame with the mouse with the button held down.
The area is displayed in the template file as a green area.
• Switch to the Identifier tool
• Right-click on the green area. You will see the usual tabs.
46.4 Script options in reports

If this option is activated, the corresponding script editor displays at the point
of the error the object that possesses the defective script.
Under certain circumstances a change of project also takes place within the
base project.
Now the user can correct the script error directly or query the properties of the
object. The global variables can also be queried.

Report Designer Script options in reports
46.4.1 Overview of script options
Script option Variable type

ANSIWIRINGRADIUS (DOUBLE) Double
APPLICATION (STRING) String
AUTOCONNECTEXTERNOBJECTS (BOOLEAN) Boolean
AUTODISTRIBUTETERMINALS (BOOLEAN) Boolean
AUTOLOOP (BOOLEAN) Boolean
AUTOLOOPCABLES (BOOLEAN) Boolean
AUTOLOOPCONNECTORLAYERS (LONG) Long
AUTOLOOPDEBUG (BOOLEAN) Boolean
SECTION 46.4.2.9: AUTOLOOPFACTOR (LONG) Long
AUTOLOOPFILTER (STRING) String
AUTOSAVEDOCUMENT (BOOLEAN) Boolean
AUTOSTARTLOOP (BOOLEAN) Boolean
CABLEOBJECTVERSION (LONG) Long
CHECKDOCOBJECTS (BOOLEAN) Boolean
CHECKIOCONSISTENCY (BOOLEAN) Boolean
COBJECTFULLNAMEFORPIPE (STRING) String
CONCESSIONRI (BOOLEAN) Boolean
CONNECTIONHOOK (DOUBLE) Double
CONNECTIONLINEMODE (STRING) RW, R, W
CONTACTMIRROR_X (DOUBLE) Double
CONTACTMIRROR_Y (DOUBLE) Double
COPYCONNECTIONDEPENDENTOBJECTS Boolean
(BOOLEAN)
CUTLINEWIDTH (DOUBLE) Double

DEFAULTIDRECTSFORSYMBOLS (BOOLEAN) Boolean


DELETEMODEPFD (BOOLEAN) Boolean
DIMENSIONSYMBOL (STRING) String
DIMENSIONTEXTHEIGHT (DOUBLE) Double
DIMENSIONUNIT (STRING) String
DRAWPIPECONNECTORSYMBOL (BOOLEAN) Boolean
DRAWPIPEENDSYMBOL (BOOLEAN) Boolean
DRAWPIPEENDSYMBOLFORSEGMENT Boolean
(BOOLEAN)
DRAWTERMINALSIDEMARK (LONG) Long

ENABLEBUTTONANSICABLE (BOOLEAN) Boolean
ENABLEBUTTONOBLIQUE (BOOLEAN) Boolean
ENABLEBUTTONSPLINE (BOOLEAN) Boolean
ENABLEPAGING (BOOLEAN) Boolean
ENABLEPROCESSCONNECTION (BOOLEAN) Boolean
ENABLEPROCESSCONNECTIONACTOR Boolean
(BOOLEAN)
ENABLEPROCESSCONNECTIONSENSOR Boolean
(BOOLEAN)
ENABLESYNCHRONIZENAVIGATOR Boolean
(BOOLEAN)
EXFCONFORMABLE (BOOLEAN) Boolean

GENERALSCALEFACTOR (DOUBLE) Double
LISTMASTER (BOOLEAN) Boolean
POTENTIALPROLONGATION (DOUBLE) Double
PREFERREDDIRECTION (STRING) String
QUADRANTOFFSETLEFT (DOUBLE) Double
QUADRANTOFFSETTOP (DOUBLE) Double


QUADRANTSIZEX (DOUBLE) Double
QUADRANTSIZEY (DOUBLE) Double
QUADRANTSTARTCHRX (STRING) String
QUADRANTSTARTCHRY (STRING) String
QUADRANTSTEPX (INTEGER) Double
QUADRANTSTEPY (INTEGER) Double
RESTOREREFERENCESAFTERCOPY Boolean
(BOOLEAN)
SCALEFOROBJECTS (BOOLEAN) Boolean

SECTOROFFSET (INTEGER) Long
SECTORSIZE (INTEGER) Long
SHOWCONNECTEDWITH (BOOLEAN) Boolean
SHOWCONNECTIONINFO (BOOLEAN) Boolean
SHOWLINEMODECONTROL (BOOLEAN) Boolean
SHOWSYMBOLBAR (BOOLEAN) Boolean
SIDEVIEW_X (DOUBLE) Double
SIGNALLEFTX (DOUBLE) Double
SIGNALRIGHTX (DOUBLE) Double
SIGNALSLOTCOUNT (DOUBLE) Double
SIGNALSLOTHEIGHT (DOUBLE) Double
SIGNALTOPY (DOUBLE) Double
SIGNALWIDTH (DOUBLE) Double
SIGNALWIDTH1 (DOUBLE) Double
SIGNALWIDTHGRAPHIC (DOUBLE) Double
SIGNBYEMPTYREFERENCE (BOOLEAN) Boolean
SNAPPRECISION (DOUBLE) Double


SORTNEWOBJECTSINCATEGORIES Boolean
(BOOLEAN)
STDPIPEFLAGNOCOLOR (BOOLEAN) Boolean

STDPIPENOREFLECT (BOOLEAN) Boolean
SUPPRESSREFERENCE (BOOLEAN) Boolean
SYMBOLTYPE (STRING) String
UNIT
VGBCONNECTIONLENGTH (DOUBLE) Double

WORKINGBACKUPTIME (DOUBLE) Double
XXDOCPROGID (STRING) String
46.4.2 Reference of the script options
46.4.2.1 AnsiWiringRadius (Double)

Example / Syntax:AnsiWiringRadius = 5
Values > 0 stipulate the curve radius in millimeters in the case of rounded cor-
ners for connections, the linking points are not shown. “0” means no ANSI
display, the linking points are shown.
46.4.2.2 Application (String)

Example / Syntax:Application = “FUP”
The basic type of report template is stipulated with this allocation, possible
types are ELO, FUP, PFD.
46.4.2.3 AutoConnectExternObjects (Boolean)

Example / Syntax:AutoConnectExternObjects = True
Permits the creation of semi-open connections in “AutoConnect” mode.

46.4.2.4 AutoDistributeTerminals (Boolean)

Example / Syntax:AutoDistributeTerminals = True
If set to “True”, in “AutoConnect” mode the terminals are automatically dis-
tributed equally over the “area”.
46.4.2.5 AutoLoop (Boolean)

Example / Syntax:AutoLoop = True
“True” creates menu item “PLACE AUTOMATIC” in the context-sensitive mouse
menu (right mouse button).
46.4.2.6 AutoLoopCables (Boolean)

Example / Syntax:AutoLoopCables = True
Automatically creates cables to connections if automatic connection has been
set. This function can be deactivated with the “False” setting, (Default value:
“True”).
46.4.2.7 AutoLoopConnectorLayers (Long)

Example / Syntax:AutoLoopConnectorLayers = 2
Permits object collection via the layer functionality (working areas). Possible
values are currently 0 (for all), 1 (only ELO, default), 2 (only SLine) and com-
binations.
46.4.2.8 AutoLoopDebug (Boolean)

Example / Syntax:AutoLoopDebug = True
Allows the outputting of debug texts if set to “True”.
46.4.2.9 AutoLoopFactor (Long)

Example / Syntax:AutoLoopFactor = 5
Determines in “AutoLoop” mode the spacing between individual objects
within the area. Default value: 5 (factor x grid in mm).
46.4.2.10AutoLoopFilter (String)
Example / Syntax:AutoloopFilter =

46.4.2.11AutoMarkAsChanged (Boolean)
Example / Syntax:AutoMarkAsChanged = True
Enhanced function for AutoWatchRevisions (Boolean), P. 46-42, see the additional
details given there.
46.4.2.12AutoSaveDocument (Boolean)
Example / Syntax:AutoSaveDocument = True
Determines whether to save the document without further prompting when it
is closed.
46.4.2.13AutoStartLoop (Boolean)
Example / Syntax:AutoStartLoop = True
“True” starts up automatic placing and connection when a new report is
opened for the first time.
46.4.2.14AutoWatchRevisions (Boolean)
Example / Syntax:AutoWatchRevisions = True
See also SECTION 41: REVISIONS.
„AutoWatchRevisions is the basic function, AutoMarkAsChanged the
enhanced function.
Revision monitoring of reports is activated by means of AutoWatchRevisi-
ons,but no report objects are marked when they are modified.
This change marking is activated by means of AutoMarkAsChanged.
Template value when neither AutoWatchRevisiones nor AutoMarkAsChan-
ged exist within the script: False.
Compatibility: If AutoMarkAsChanged = True has been set, then Auto-

WatchRevisiones is automatically set to True as well.
Interaction with the project option Revision monitoring

Project option Revision monitoring set to None (i.e., deactivated):
AutoWatchRevisiones then has no effect by itself. Nonetheless, you can
make changes manually and in addition you can activate the AutoMarkA-
sChanged variable, which then switches on revision marking within the
report. In other words: If something has changed in the report since the last
revision step, then in this case it will be marked in the report.

Project option Revision monitoring activated (any option):

This report is not affected by the revision monitoring function if Auto-
WatchRevisiones has been set to “False”. You can thus exclude a report
from the revision monitoring function by using this project option if this had
been activated within the project options.
46.4.2.15CableObjectVersion (Long)
Example / Syntax:CableObjectVersion = 1
Old RoCable objects are created with drag & drop if this is set to 1, while a
setting of 2 creates new ones.
46.4.2.16CheckDocObjects (Boolean)
Example / Syntax:CheckDocObjects = True
If set to “True”, automatic checking of all the objects placed on a report starts
up when the report is opened and the results are displayed in the “Document
analysis” message box. This functionality can be switched off with the
“False” setting. This is desirable if there is a large number of objects on the
report, as this will reduce the time needed for the report to load.
46.4.2.17CheckIOConsistency (Boolean)
Example / Syntax:CheckIOConsistency = True
Switches on the input/output consistency check in FixDependencies in func-
tion diagrams so as to prevent incorrect allocations.
46.4.2.18CObjectFullNameForPipe (String)
Example / Syntax:CObjectFullNameForPipe = „@1RI|@V10|@A"
This makes an assignment of the base object for piping on the report.
46.4.2.19ConcessionRI (Boolean)
Example / Syntax:ConcessionRI = True
The “True” setting prevents changes to the connection logic of Comos con-
nectors when objects are placed on this report. This is used when Comos
objects and their connections to one another have already been entered in

other documents and in the database and these objects are to be displayed in
further diagrams without have any effect on the information that is already
stored in the database.
46.4.2.20ConnectionHook (Double)
Example / Syntax:ConnectionHook = 2
Determines the type of display and the size of connection points. “0” creates
a connection point, numeric values > 0 create connecting hooks with the cor-
responding size in millimeters.
46.4.2.21ConnectionLineMode (String)
Example / Syntax:ConnectionLineMode = „RW“
Determines the type of connecting lines.
ConnectionModeTypes:RWread / write (default value)
RRead-only
WWrite-only
46.4.2.22ContactMirror_X (Double)
Example / Syntax:ContactMirror_X = 0
Determines the X-position of the contact mirror (value in mm).
46.4.2.23ContactMirror_Y (Double)
Example / Syntax:ContactMirror_Y = 20
Determines the Y-position of the contact mirror (value in mm).
46.4.2.24CopyConnectionDependentObjects (Boolean)
Example / Syntax:CopyConnectionDependentObjects = True
Only for internal use.
46.4.2.25CutLineWidth (Double)
Example / Syntax:CutLineWidth = <Parameter>

Determines the cutout width in millimeters when pipes cross over each other
on diagrams of type PFD.
46.4.2.26DefaultIdRectsForSymbols (Boolean)
Example / Syntax:DefaultIdRectsForSymbols = True
If this is set to “True”, it is only necessary to mouse-click in the close prox-
imity (bounding rectangle) of the object on the diagram in order to mark it.
The object must be touched directly if “False” is set (this is the default value).
46.4.2.27DeleteModePFD (Boolean)
Example / Syntax:DeleteModePFD = True
This option detainees the deletion mode for PFD diagrams. If it is set to
“False”, then only the objects on the diagram are deleted and the database
entries are not affected. If it is set to “True”, then both the graphic objects and
the corresponding database entries are deleted (after a warning prompt!).
46.4.2.28DimensionSymbol (String)
Example / Syntax:DimensionSymbol = “Arrow”
This instruction specifies the dimensioning of the symbol to be displayed.
Possible values: arrow, circle, dot, slash. (Default = arrow).
46.4.2.29DimensionTextHeight (Double)
Example / Syntax:DimensionTextHeight = <Parameter>
Default = 5. Height of the dimension text in mm. If another unit has been input
in DimensionUnit, then the unit input here in DimensionTextHeight is still
used in mm and is then converted into the other unit of measure. The param-
eter can have any desired number of decimal figures in the Double variable
value range, the decimal separator depends on the country setting.
46.4.2.30DimensionUnit (String)
Example / Syntax:DimensionUnit = <„Parameter“>
This instruction determines the text size is to be specified by DIMENSIONTEXT-
HEIGHT. The parameter can accept the values mm, cm, m, inch .

46.4.2.31DrawPipeConnectorSymbol (Boolean)
Example / Syntax:DrawPipeConnectorSymbol = True
Toggles the display of the piping link symbols on or off when the piping
crosses over page boundaries. (Default = True).
46.4.2.32DrawPipeEndSymbol (Boolean)
Example / Syntax:DrawPipeEndSymbol = True
Toggles on and off the display for piping end symbols. (Default = False).
46.4.2.33DrawPipeEndSymbolForSegment (Boolean)
Example / Syntax:DrawPipeEndSymbolForSegment = True
Toggles on and off the display for piping segment symbols for newly created
piping. The toggling of the display can alternatively be done for all piping via
the context-sensitive mouse menu as well.
46.4.2.34DrawTerminalSideMark (Long)
Example / Syntax:DrawTerminalSideMark = <Parameter>
Determines whether and on which output device the terminals page marking
is to appear. Possible parameter values: 0, 1, 2.
0 = Display on the screen, is not printed as hard copy.
1 = Display on the screen and is also printed as hard copy.
2 = Neither displayed on the screen nor printed.
46.4.2.35EnableButtonANSICable (Boolean)
Example / Syntax:EnableButtonANSICable = True
“True” inserts the toggle button for ANSI cable display into the toolbar of the
report.
46.4.2.36EnableButtonOblique (Boolean)
Example / Syntax:EnableButtonOblique = True
“True” inserts the “Oblique” checkbox into the toolbar of the report in
enhanced connection mode. The tick in the checkbox makes it possible to
draw non-rectangular connections.

46.4.2.37EnableButtonSpline (Boolean)
Example / Syntax:EnableButtonSpline = True
“True” inserts the “Spline” checkbox into the toolbar of the report in
enhanced connection mode. The tick in the checkbox makes it possible to
draw any type of splines desired.
46.4.2.38EnablePaging (Boolean)
Example / Syntax:EnablePaging = True
If set to “True”, this function means that the “Navigate to previous / next ”
buttons in the icon bar of the report are offered. The Comos sorting of the doc-
uments is used.
46.4.2.39EnableProcessConnection (Boolean)
Example / Syntax:EnableProcessConnection = True
Determines whether a process device can be created or changed.
(Default = False).
Background: a connection is created automatically within Comos when a
function (measurement function or actuating function) is docked onto piping.
This connection can be provided with additional objects: a nozzle can be
inserted automatically in the case of a measurement function, and a valve in
the case of an actuating function. These forms of automation cease if the
option is set to True and the corresponding objects have been prepared within
the functions.
Please note that this form of automation can be controlled even more finely
with the aid of EnableProcessConnectionActor and EnableProcessCon-
nectionSensor. If one of these two options is set, then the general option
EnableProcessConnection may not be used.
46.4.2.40EnableProcessConnectionActor (Boolean)
Example / Syntax:EnableProcessConnectionActor = True
Determines whether a process device for an actuating function can be created
or changed (e.g., in the case of measuring function connections).
(Default = False).
Background: see EnableProcessConnection.
If this option is used, then the general option EnableProcessConnection
may not be used.

46.4.2.41EnableProcessConnectionSensor (Boolean)
Example / Syntax:EnableProcessConnectionSensor = True
Determines whether a process device for a measuring function can be created
or changed (e.g., in the case of measuring function connections).
(Default = False).
Background: see EnableProcessConnection.
If these options are used, then the general option EnableProcessConnection
may not be used.
46.4.2.42EnableSynchronizeNavigator (Boolean)
Example / Syntax:EnableSynchronizeNavigator = True
If script option EnableSynchronizeNavigator = True is in the options
script of a report template, the object (device) selected within the report is
likewise selected in the Navigator and vice versa. (Default = False).
46.4.2.43EXFConformable (Boolean)
Example / Syntax:EXFConformable = True
A number of special points should be noted concerning export into the EXF
format. You can stipulate via this script option that reports must conform to
the exf format. Among other things, that causes a change of behavior in the
case of objects with associated texts. These can no longer be moved by using
the grab points but must be given fixed defined positions. (Default = False).
46.4.2.44GeneralScaleFactor (Double)
Example / Syntax:GeneralScaleFactor = 1
All of the objects placed on the report are automatically scaled with this fac-
tor. Main area of application: a symbol was drawn for a grid (for example, a
4 mm grid) and is now to be used on another grid as well (for example, a 5
mm grid). In the above example you could increase all the symbols in size
with a scaling factor of 1.25 so that the placement points and connectors of
the symbols also fit in cleanly on this new grid. (Default = 1).
See also ScaleForObjects.
46.4.2.45ListMaster (Boolean)
Example / Syntax:ListMaster = True

Only for internal use! (Default = False).
46.4.2.46PotentialProlongation (Double)
Example / Syntax:PotentialProlongation = 20
Used in the case of potentials so as to modify the potential line by the stipu-
lated value in millimeters on the pages of the potentials where the label has
been switched off. Positive values lengthen the line and negative values
shorten it.
46.4.2.47PreferredDirection (String)
Example / Syntax:PreferredDirection = “X”
If the direction of connection cannot be identified by the system without any
ambiguity, this parameter stipulates the preferred direction of connection
(X = X-direction, Y = Y-direction) in “CONNECT AUTOMATIC” mode.
46.4.2.48QuadrantOffsetLeft (Double)
Example / Syntax:QuadrantOffsetLeft = 10
Determines the X-coordinates for the starting calculations. This functionality
belongs to the group of path and zone variables for all diagrams of type
“ELO” or “FUP”. (Parameter values are absolute values in millimeters.)
46.4.2.49QuadrantOffsetTop (Double)
Example / Syntax:QuadrantOffsetTop = 10
Determines the Y-coordinates for the starting calculations. This functionality
belongs to the group of path and zone variables for all diagrams of type
“ELO” or “FUP”. (Parameter values are absolute values in millimeters.)
46.4.2.50QuadrantSizeX (Double)
Example / Syntax:QuadrantSizeX = 50
Quadrant size in the X-direction. This functionality belongs to the group of
path and zone variables for all diagrams of type “ELO” or “FUP”. (Parameter
values are absolute values in millimeters.)

46.4.2.51QuadrantSizeY (Double)
Example / Syntax:QuadrantSizeY = 50
Quadrant size in the Y-direction. This functionality belongs to the group of
path and zone variables for all diagrams of type “ELO” or “FUP”. (Parameter
values are absolute values in millimeters.)
46.4.2.52QuadrantStartChrX (String)
Example / Syntax:QuadrantStartChrX = “1”
Starting value for the designation of the first quadrant (X-direction). Valid
values: 0-9, A-Z. This functionality belongs to the group of path and zone
variables for all diagrams of type “ELO” or “FUP”. (Parameter values are
absolute values in millimeters.)
46.4.2.53QuadrantStartChrY (String)
Example / Syntax:QuadrantStartChrY = “A”
Starting value for the designation of the first quadrant (Y-direction). Valid
values: 0-9, A-Z. This functionality belongs to the group of path and zone
variables for all diagrams of type “ELO” or “FUP”. (Parameter values are
absolute values in millimeters.)
46.4.2.54QuadrantStepX (Integer)
Example / Syntax:QuadrantStepX = 1
Determines the step width for the calculation of paths and zones of type
“ELO” or “FUP” in the X-direction. (Default value = 1).
46.4.2.55QuadrantStepY (Integer)
Example / Syntax:QuadrantStepY = 1
Determines the step width for the calculation of paths and zones of type
“ELO” or “FUP” in the Y-direction. (Default value = 1).
46.4.2.56RestoreReferencesAfterCopy (Boolean)
Example / Syntax:RestoreReferencesAfterCopy = True

If set to “True” (default value), all the objects placed on the report and their
references are checked and created from scratch in the database as applicable
after a copying process in the case of interactive reports.
46.4.2.57ScaleForObjects (Boolean)
Example / Syntax:ScaleForObjects = False
If the command is set to “False”, the symbols on the report always remain at
100% of the original size (original scale), if the | OPTIONS | SCALE mouse com-
mand is used in the report.
The default setting is True and this value also applies if the command is not
available. In the default setting the symbols are thus increased or reduced in
size if the scale of the report is changed.
This options script variable can be toggled off for individual symbols. This is
done with the doScale = True command in the symbols script.
46.4.2.58SectorOffset (Integer)
Example / Syntax:SectorOffset = 0
Stipulates the offset when setting sectors. The setting of the PreferredDirec-
tionoption determines whether zone sectors (X) or path sectors (Y) are to be
calculated.
46.4.2.59SectorSize (Integer)
Example / Syntax:SectorSize = 0
Stipulates the width of the sectors for standard sheets that have been split up.
46.4.2.60ShowConnectedWith (Boolean)
Example / Syntax:ShowConnectedWith = True
Default = False. Stipulates whether information on the partner connector is to
be displayed at the current connector of the connection. If set to True, a sym-
bol that is to be displayed at the connection point is searched for in the @Con-
nection table, separately for each type of diagram.
46.4.2.61ShowConnectionInfo (Boolean)
Example / Syntax:ShowConnectionInfo = True

If set to “True”, connection information is automatically displayed at cables.

The prerequisite for this is that there is the entry INFO in pick list
@System |@Connection . This entry can be stored in the script related to the
type of diagram, which is then called up automatically. Application examples
are wires numbers in circuit diagrams or cable designations in single line dia-
grams. (Default = False).
The command applies to the EE module and the P&ID module.
46.4.2.62ShowLineModeControl (Boolean)
Example / Syntax:ShowLineModeControl = True
Allows display of the selection box with the types of connections.
(Default = False).
46.4.2.63ShowSymbolBar (Boolean)
Example / Syntax:ShowSymbolBar =True
Toggles the display of the symbol bars on and off. (Default = True).
46.4.2.64SideView_X (Double)
Example / Syntax:SideView_X = 25
Determines the spacing in the X-direction between the symbol (object) origin
and the overall view drawing in space assignment plans, the unit of measure
is mm, no display if the value = 0.
46.4.2.65SignalLeftX (Double)
Example / Syntax:SignalLeft_X = 8
Determines the left-hand boundary of the signal symbols on diagrams of type
“FUP”. (Default = 8)
46.4.2.66SignalRightX (Double)
Example / Syntax:SignalRight_X = 8
Determines the right-hand boundary of the signal symbols on diagrams of
type “FUP”. (Default = 288).

46.4.2.67SignalSlotCount (Double)
Example / Syntax:SignalSlot_Count = 25
Determines the possible number of signal placeholders on diagrams of type
“FUP”. (Default = 22).
46.4.2.68SignalSlotHeight (Double)
Example / Syntax:SignalSlot_Height = 20
Determines the size of the signal placeholder and thus the signal symbol size
in millimeters in the Y-direction on diagrams of type “FUP”. (Default = 8).
46.4.2.69SignalTopY (Double)
Example / Syntax:SignalTop_Y = 15
Determines the upper starting position of the signal placeholders on diagrams
of type “FUP”. (Default = 12).
46.4.2.70SignalWidth (Double)
Example / Syntax:SignalWidth = 40
Determines the display size of all the signal symbols in the X-direction on dia-
grams of type “FUP”. (Default = 48).
46.4.2.71SignalWidth1 (Double)
Example / Syntax:SignalWidth1 = 15
Determines the display size of the front signal symbol part in the X-direction
on diagrams of type “FUP”. (Default = 16)
46.4.2.72SignalWidthGraphic (Double)
Example / Syntax:SignalWidthGraphic = 10
Determines the display size of the rear signal symbol part in the X-direction
on diagrams of type “FUP”. (Default = 8).
46.4.2.73SignByEmptyReference (Boolean)
Example / Syntax:SignByEmptyReference = False

If set to “False”, no texts are output if links are blank. (Default = True).
46.4.2.74SnapPrecision (Double)
Example / Syntax:SnapPrecision = 1
Determines the snap precision of objects on the diagram. (Default = 0.9). Doc-
uments imported from other programs can have very small terminal radii that
are very close to each other and components that are densely packed together.
Since SnapPrecision decides, among other things, when connectors are to
be regarded as joined, it is advisable to reduce the factor in such cases (e.g.
0.5).
46.4.2.75SortNewObjectsInCategories (Boolean)
Example / Syntax:SortNewObjectsInCategories = True
Initiates the sorting of new Comos objects in adjacent category folders.
(Default = False).
46.4.2.76StdPipeFlagNoColor (Boolean)
Example / Syntax:StdPipeFlagNoColor = True
Toggles on and off the color display for the default piping flag.
(Default = False).
46.4.2.77StdPipeNoReflect (Boolean)
Example / Syntax:StdPipeNoReflect = True
“True” switches off the mirroring (reflection) of piping flags when the direc-
tion of flow is reversed. (Default = False).
46.4.2.78SuppressReference (Boolean)
Example / Syntax:SuppressReference = True
“True” suppresses the output of cross-references to connections in the ELO
application. (Default = False)
46.4.2.79SymbolType (String)
Example / Syntax:SymbolType = “Detail”

This setting determines which type of symbol display is to be used. See the
pick lists in system project ...\@System\@DRW_Type for possible additional
settings.
46.4.2.80Unit
The setting Unit = 0 or Unit = 1 in the options script of a report template deter-
mines which unit of measure (mm or inches) is to be used when working in
all derived reports. All the decimal places to be taken into consideration were
increased to four to improve the precision of conversion operations.
Please note that the unit setting only applies to the report template itself and
those reports based on it, but not for reports to be loaded, such as row reports,
child reports or sub-reports.
When converting to “inch” units (Unit = 1) the entry for the page
size, the grid, all the coordinates and the heights and widths
of graphic objects on the report are automatically converted. Angles are basi-
cally calculated on the basis of 360 degrees.
AutoCAD objects can also be imported if they use “inch” units. Vice versa,
reports using “inch” units can also be exported as AutoCAD drawings.
The values can also be input as points (“pt”) for graphic report objects (line,
circles, etc.). Nonetheless, the input is then converted into the current system
of units for the report (mm or inches) and is also saved as such. If you make
an input in points, close the Properties window and open it again, the value
will no longer be in points but is displayed in the current unit.
46.4.2.81VGBConnectionLength (Double)
Example / Syntax:VGBConnectionLength = 15
Used in function diagrams as per VGB to stipulate the length of the visible
part of the first connection element of a signal. Value inputs yield the display
length in mm, 0 shows the full length. If the input exceeds the maximum per-
missible display size, only the maximum possible size is displayed.
46.4.2.82WorkingBackupTime (Double)
Example / Syntax:WorkingBackupTime = 15
Controls the interval (in minutes) in which the document is automatically
saved.
Default: 5 minutes; 0 switches the auto-save function off.

Functions in reports Report Designer
46.4.2.83XXDocProgID (String)
Example / Syntax:XXDocProgID = “ProjectName.ClassName”
Given the prerequisite that “IReportXDoc.dll” has been implemented before-
hand, a user-defined DLL can be called up in this way.
46.5 Functions in reports
46.5.1 Functions for Text and List scripts
The functions below can be used in both Text and List scripts.
46.5.1.1 Property ComosDocument As Object

Returns the document object in the Navigator tree.
46.5.1.2 Property AutoMarkAsChanged As Boolean

Controls the appearance of the text in the report
TRUE: Text appears in italics if the the latest revision is edited
FALSE: No change in text appearance.
46.5.1.3 Property EvalForEveryPage As Boolean

Determines how the text is to be evaluated. Settings are made from within the
Text parameter window.
TRUE: Text is evaluated separately for each page in the report
FALSE: Text is jointly evaluated (just once) for all the pages in the report.
46.5.1.4 Property EvalSequence As Long

Determines the sequence in which texts and lists are to be evaluated.
46.5.1.5 Property ItemObject As Object

With lists: ItemObject sets the ReportObject of the Rows report.

Report Designer Functions in reports
46.5.1.6 Property KeepScriptRunning As Boolean

Determines whether the Option-Script should remain active or not
TRUE: The Option-Script remains active (interactive reports)
46.5.1.7 Property Layer As Long

Sets a layer for the object. The layer can either be switched on or off.
46.5.1.8 Property LineType As Long

Specifies the line type (e.g. 2 for dashed lines)
46.5.1.9 Function MainComosDocument() As Object

Returns the document object in the Navigator tree.
46.5.1.10Function MainReportDocument() As Document

Returns the main document - the main report file.
46.5.1.11Function MasterReportDocument() As Document

Returns the master document, i.e. the master report file.
46.5.1.12Property Name As String

Returns the name of the element (i.e. the report item, e.g. Texts and Lists).
46.5.1.13Function ParentReportDocument() As Document

Returns the hierarchically higher report (report file).
46.5.1.14Property Report As Object

Provides access to the Option-Script of a report.
46.5.1.15Function ReportDocument() As Document

Returns the report file itself.

46.5.1.16Property Script As String

Returns the script of report items such as Text and Lists.
46.5.1.17Property SystemTypeName As String

Returns the systemtypename of the report item (e.g. for Texts, “Text“ and for
Lists, “Lists“)
46.5.1.18Sub ToBack ()
Sets the report item in the background
46.5.1.19Sub ToFront ()
Sets the report item in the foreground
46.5.1.20Property Visible As Boolean

This property controls the visibility of report items such as texts.
TRUE (default): Text is visible
FALSE: Text is invisible
46.5.1.21Property X1 As Double
Gets and sets the value for the X1 coordinate
46.5.1.23Property Y1 As Double
Gets and sets the value for the Y1 coordinate
Gets and sets the value for Y2 coordinate

46.5.2 Functions for List scripts only
46.5.2.1 Direction As Long

Specifies the direction of the List.
46.5.2.2 Function EvalOneRow() As Long

Controls the execution (call and evaluation) of a Row report.
46.5.2.3 Function EvalOneRowDocument( RowObject As Object,

FileName As String, ComosDocument As Object) As Long
Controls the execution (call and evaluation) of a Row report, in this case,
RowObject is the ReportObject of the Row report
FileName is the file name of the Row report
ComosDocument is a document object in the Navigator tree.
46.5.2.4 Function EvalOneRowObject( Object As Object, RowDocName

As String) As Long
Controls the execution (call and evaluation) of a Row report, in this case,
Object is the ReportObject of the Row report
RowDocName is the file name of the Row report.
46.5.2.5 Function EvaluatedRowCount() As Long

Returns the number of executed Row reports.
46.5.2.6 Function EvaluatedRowDocument( Index As Long) As

Document
Returns the evaluated document (i.e. the report file) with the given Index.
46.5.2.7 FileName As String

Gets and sets the name of the file.

46.5.2.8 Function NewPage() As Long

Creates a new page and returns the corresponding page number.
46.5.2.9 RowDocument As String

Gets and sets the file name of the document.
46.5.2.10Sub SetLineWrap()
Enables lists to always retain their positions, even in subsequent pages within
sub reports.
Gets and sets the value for the Y1 coordinate
Gets and sets the value for Y2 coordinate
46.5.3 Functions for Text scripts only
The following functions can only be used in Text scripts.
46.5.3.1 Align As String

Controls the alignment of the text.
46.5.3.2 Angle As Double

Returns the angle in which the text appears.

46.5.3.3 BackColor As OLE_COLOR

Gets and sets the value of the background color for texts.
46.5.3.4 Clip As Long/Boolean

This property is of type Long, but due to special internal settings, used as
Boolean.
TRUE: Trims texts that are too long.
46.5.3.5 FIT As Long/Boolean

Due to special internal settings, used as Boolean.
TRUE: Reduces the size of long for them to fit in the given field.
46.5.3.6 ForeColor As OLE_COLOR

Gets and sets the color of the text.
46.5.3.7 Function MaxPageNr() As Long

Returns the page number of the report.
46.5.3.8 Function MaxRevisionIndexOf( ItemsNames As String) As String

Returns the highest revision index of the objects with the given text names,
e.g. in the function MaxRevisionIndexOf (“Text1, Text2, Text3“), Text1,
Text2 and Text3 are the names of the text fields.
46.5.3.9 Function ScriptObject( ) As Object

Returns the Option-Script of a report.
46.5.3.10 SoftAlign As Long

Controls the distance between the text and the text field boundary.
Returns the value “-1“ for Soft
Returns the value “0“ for hard/transparent.

46.5.3.11 text As String

Gets and sets the text.
46.5.3.12 Transparent As Long/Boolean

Controls text transparency. As a general rule, used as Boolean
TRUE: Text is transparent - the background color of the text is not visible
FALSE: Text is not transparent - the background color of the text is visible.
46.5.4 Functions for all scripts
The functions below can be used everywhere.
46.5.4.1 Sub OutPutDebugString(s As String)

Outputs the given string (s) in an output window.
46.5.4.2 Property Report As Object

Returns the Option-Script
46.5.4.3 Property ReportObject As Object

Gets and sets the ReportObject.
46.5.4.4 Function CallScriptLib( CDevFullname As String, FuncName As

String, [Param1], [Param2], [Param3], [Param4], [Param5],
[Param6], [Param7], [Param8], [Param9], [Param10])
This function serves the purpose of calling a script function that is written in
a CDevice.
CDevFullname is the SystemFullName of the CDevice containing the written
function
FuncName is the name of the function
Up to 10 parameters can be entered

46.5.4.5 Function DocHdr() As Object

Returns an object in which functions within the file “DocumentHeader.dll“
can be accessed.
46.5.4.6 Property Document As Object

Returns the document object.
46.5.4.7 Function GlobalPageNr() As Long

Returns the current page number with regards to the corresponding docu-
ments.
46.5.4.8 Function DSpec( Chapter As String, OrgName As String) As

Object
Returns the attribute/specification of the document
Chapter is the name of the tab
OrgName is the name of the attribute/specification
46.5.4.9 Function OSpec( Chapter As String, OrgName As String) As

Object
Returns the attribute/specification of the report object
Chapter is the name of the tab
OrgName is the name of the attribute/specification
46.5.4.10Sub Output( s As String)

Outputs the entered String (s) in an output window during report execution.
46.5.4.11Property PageNr As Variant

Returns the current page number.
46.5.4.12Property Project As Object

Returns the current project.

46.5.4.13Property ReportObject As Object

Returns the report object.
46.5.4.14Function RevisionIndex( PltObject As Object) As String

Returns the current revision index of the given object (PltObject) in the doc-
ument.
46.5.4.15Function RevisionLabel( PltObject As Object) As String

Returns the label of the current revision for the PltObject in the document.
46.5.4.16Function RevisionTableDate( RevLineNr As Long,

RevColumnNr As Long) As String
Returns the revision date
RevLineNr is the row number of the revision (specifies the revision by itself)
RevColumnNr is the column number of the revision
46.5.4.17Function RevisionTableIndex( RevLineNr As Long) As String

Returns the index of the revision
RevLineNr is the row number of the revision
46.5.4.18Property FirstPageNr As Long

Returns the first page number of the document.
46.5.4.19Property ReportObject As Object

Gets and sets the report object (ReportObject).
46.5.4.20Property RevisionTableLength As Long

Sets the start row for the evaluation of the revision
As a general rule, it starts from the latest (most recent) revision.

46.5.4.21Function RevisionTableUser( RevLineNr As Long,

RevColumnNr As Long) As String
Returns the user name of the revision
RevLineNr is the row position of the revision
RevColumnNr is the column number of the revision.
46.5.4.22Property Specs As Object

Returns an given attribute (i.e. a specification)
Can be accessed via <tab name> + “.“ + <attribute name>
Example / Syntax:Specs .K1.SP1
K1 is the tab name(i.e. the name of the tab)
SP1 is the name of the attribute


Designer as Interactive Report Toolbar
47 Designer as Interactive Report
47.1 Toolbar
The following buttons are only available when an Interactive Report is edited.
These buttons do not exist either in the Report Designer or in the Symbol
Designer.
47.1.1 The Connection tool
The Connection tool automatically searches for connection points of

the objects on the report. The behavior of the connectors is explained
according to the types of diagrams.
Open connections are not allowed under any circumstances and are shown as
an inconsistency (marked in red). See the types of diagrams regarding excep-
tions.
You can also make multiple connections in parallel.
When you click on the Connection tool, a drop-down menu with the numbers
from 1 to 5 appears in the menu bar on the right. Select from the menu the
desired number of parallel connections.
• The connection points of Comos objects are “magnetic”: the Connection
tool automatically snaps to a connection point within a specified radius
around the connection point.
This automatic snapping of a wire to the connection points can be
deactivated by pressing the <Ctrl> key while moving the mouse.
• The grid points of an Interactive Report are “magnetic”: the Connection tool
automatically snaps to a grid point. This automatic snapping of a wire to the
grid points can be deactivated by pressing the <Shift> key while moving the
mouse.
• The <Ctrl> key and the <Shift> key can be pressed simultaneously so that
this automatic snapping of the cursor to the grid can be completely
deactivated.

Toolbar Designer as Interactive Report
47.1.2 Types of lines and graphic properties of lines
47.1.2.1 User-defined line sample (USERLNTYPE)
47.1.2.1.1 Basic principle

A type of line is made up of the following constituent parts:
• The symbol, also called the line sample
• The sample length
• The line thickness and line color
• The description
Comos makes available a wide variety of predefined types of lines. These
types of lines used in Comos are distinguished by technical area, application,
etc. Standard table USERLNTYPE is available if self-defined types of lines
are still required nonetheless.
Please note that in Comos all user-defined line samples are managed exclu-
sively in the common standard table USERLNTYPE.
Regardless of which type of diagram or in which module you are working,
(P&ID, EE, Logical Diagram, etc.): USERLNTYPE is the collector for every-
thing and from which the user-defined line samples are “fetched”. User-
defined line samples are created here, and only here.
No relation to types of diagrams

Please note that this standard table works in complete isolation of the type of
diagram. The type of diagram is only taken into consideration later. For that
reason the drop-down field Diagram type at the bottom edge of the standard
table also has no significance:
• The first symbol that was found by Comos for this entry in USERLNTYPE
is always used. Any additional symbols that had been defined are ignored.
• In other words, there may only be one symbol for each entry (each row) in
standard table USERLNTYPE so as to avoid any misunderstandings. It
makes no difference at all in what type of diagram the symbol had been
created.

Depending on the version of Comos, the Diagram type field is empty in

this standard table so that you create a symbol “irrespective of diagram
type”. This makes it even clearer that the type of diagram is completely
unimportant at this point.
47.1.2.1.2 Structure of standard table USERLNTYPE

Name
A unique number that is greater than 1000 (e.g. 1001). The numbers under
1000 are reserved for system use and may not be used.
Description
Is ignored.
Symbol
Required on any type of diagram (or without type of diagram).
Value1
Any name you wish.
Value2
Sample length in points related to a grid of 1. Example:
- If the sample length was set to “4” in Value2 and the grid was also set to 4,
then a line sample extends from precisely one grid point to the next one.
- If the sample length was set to “4” in Value2 and the grid was only set to 1,
then a line sample extends over four grid points.
Value3
Details on the input.
0 or no details (input value): mm
1: inch.
47.1.2.1.3 Digression: Symbol structure

There must be one symbol per row in the list in standard table USERLN-
TYPE. There are the following peculiarities in addition to the rules already
given on creating symbols:
1. Always align to a horizontal connection
Proceed on the basis of a horizontal connecting line as the starting point.
Thus if there was only a vertical line in the symbol, then a horizontal
connection would only consist of a series of vertical lines one after
another.

This also applies to vertical connections! A vertical connection is nothing

more than a rotated horizontal connection. If the horizontal connection
was not continuous, then the vertical connection also cannot be drawn as
continuous.
In other words, vertical lines in the symbol can never lead to a continuous
line in the report, regardless of the direction in which the connection is
drawn.
2. Take the origin into consideration
The origin of the symbol is likewise of importance. If a symbol is created
for the line type, then a virtual box that consists of all the objects drawn
in the symbol and the origin is generated. This virtual box is the area that
is placed in turn when the line is drawn in the report.
In other words, it is not just the elements that are drawn that make up the
symbol. The origin is included automatically. If the origin is not located
on one of the drawing elements, then the symbol to be placed will be
correspondingly larger and will contain more empty space!
When the connection is drawn, the symbol (that was designed as the line
type) is placed with the origin at the start of the connection. The origin
should thus as a rule be located on the far left-hand edge of the symbol. If
the origin is on the right in the Symbol Designer, the line then protrudes
out to the left beyond the connection point.
3. Consider sample length (Value2)
You must ensure for yourself that the sample length is as long or longer
than the symbol is wide. Consider also the position of the origin when
doing this, since this is automatically included as well with the entire
symbol!
4. Line thickness
The user can select the line thickness later, regardless of the line type. If
this is to function, no fixed thickness may be assigned to the lines in the
symbol.
When a line is drawn in the Symbol Designer, a thickness is assigned
through this drawing of the line. This line thickness that had been
assigned automatically must be removed again
When the Symbol Designer is closed, the drawing is converted into a
script. This symbol script must be reworked. Do this by mouse-clicking
on the [S] button at the lower end of the standard table:

Delete the following lines in the script (example):

ResetToDefaults
Header.Layer = "2"
Header.Width = 0.5
These lines mean:

ResetToDefaults
Thus all the graphic settings are reset to the defaults. The default is:
Width: Windows default, usually 0.1.
Color: Black
Style: Continuous
Font: Arial 7.
This command must be removed, since resetting to the defaults also
overwrites any manual settings that may have been made by the user in
the report.
Layer
A layer combines a number of graphic objects together so that these
objects can be edited together. The same applies here as well, namely, that
the layer should be set in the report and not in the symbol.
Width
This is the line thickness. When this appears, it is a fixed value that can
no longer be changed manually by the user. Admittedly the user can, for
example, still call up the Graphic properties dialog within the report
and select a setting there. But it will have no effect.
Please note that if you have experience in creating symbols, you can
achieve useful effects with settings such as “Header.Width” and similar
commands. For example, you can assign a fixed thickness to part of the
symbol and leave other parts freely definable so that the user can set this
in the report.
Remainders of the line

Each symbol has a sample length. However, in many case the length of the
connection is not an exact multiple of this sample length. A “remainder” is left
over. This remainder is “filled in” with a continuous line at the left and right
ends of the connection.
These remainders can always be modified via the graphic settings, since Hea-
der.Width and the like explicitly only affect the symbol but not automati-
cally-generated constituents such as these remainders.

Thus if you had “Header.Width = 0.5” in the symbol and the user wanted
to choose another thickness, then this user input would only affect the remain-
ders.
47.1.2.2 Diagram-type-specific line types (LINETYPES)

All the modules in Comos provide the option to make available the line sam-
ples created within USERLNTYPE according to the type of diagram. This is
not the only way in which USERLNTYPE can be used; but this option is
available everywhere and should therefore be used as described below.
Create a standard table for each desired type of diagram:
@SYSTEM | @LINETYPES | <Diagrams types list>
Thus, for example:

@System
-| @LINETYPES
-| Detail
-| Detail_ANSI
-| RI
etc.
Please note that the name of the standard table must match exactly the dia-
gram type of the report. Check this by opening the report template and search-
ing for the entry SymbolType = "...".
Example:
@SYSTEM | @LINETYPES | RI1 belongs to SymbolType = "RI1".
Structure of standard tables @LINETYPES | <Diagrams types list>

Name = any desired name
Description This text appears in the Line types drop-down field, see below
in the section “Example of the effect”.
Symbol Is not evaluated. The symbols must come from USERLNTYPE.
Value1 Must match the entry in the Name field in USERLNTYPE.

Example of the effect

Assuming that diagram type DETAIL is to be considered in the LINETYPES:
• Mark a connection in an Interactive Report.

• Right-click on the connection and select:
| OPTIONS | GRAPHIC PROPERTIES
• Mouse-click in the following dialog window in the Line types drop-down
menu.
The line types defined in the DETAIL standard table are made available in
addition at the end of the drop-down menu:
47.1.2.3 Connector-specific line types

In this case a connecting line that begins or ends at a specific connector auto-
matically has a specific line type allocated to it.

A Type is defined in the Properties window of a connector:
You can see within Comos which types of connectors are available.
A ConnectionType[TYPE] standard table for each connector type is located
in the system project. [Type] is to be replaced by the relevant type name of the
connector:
Structure of standard table ConnectionType[TYPE]

Name : Any unique name.
Description : These texts are offered as the Sub-type in the Properties win-
dow of the connector.

Example. The values from ConnectionTypeE...
...appear in the drop-down menu:
Symbol : Is not evaluated. The symbol is supplied from the line type that was
stipulated in Value3 .
Value1 : The actual name of the sub-type. The connector types are handled
under this designation. You would also get this text if you queried the sub-
type in the object debugger.
Value2 : Line thickness. The settings in the symbol (Header.Width) take pri-
ority. In addition, there can be peculiarities in specific areas.
Value3 : Designation of the line type. The line type can originate from
USERLNTYPE or else can be called up from Comos’s own line types, see,
for example SECTION 47.1.2.4.2: STRUCTURE OF @1RI|1|J AND @1RI|1|K. In this case
the Comos lines must not have been defined before in @1RI | 1 | J or in
other standard tables. Instead, you can call up the Comos line types at once in
Value3 if you know the code name.
Value4 - Value6 : RGB colors of the line.
Value7 : Layer of the lines.
47.1.2.4 Line types in P&ID
47.1.2.4.1 Overall systemology

The following explanations apply to reports with the options script entry
Application = “PFD”. The connections are displayed in the following order:

For a pipe
1. Special color: Red for inconsistent always wins out over the others.
2. Administrator default or user setting: Setting on the RI Display tab
before placing the pipe.
3. Manual setting at the pipe or in the report at the connection.
The following applies for the administrator default or user setting as per
point 2 and point 3:
– Please note that the menus at the pipe and in the report are not
completely identical. The diagram-type-specific line types are of course
available as well in the report.
– Please note that different colors are offered in the Properties window for
the pipe and in the report. Selection is done from a standard table in the
Properties window of the pipe. Selection is done from the Windows
colors in the report.
If you have to select a color within the report, the information “Windows
color” is shown in the Properties window of the pipe.
If a color was selected in the Properties window of the pipe, then a grey
color appears in the report in the graphic properties of the connection.
The following are available for user selection:
– Standard table @1RI|1|J
– Plus: User-defined lines that were transferred from USERLNTYPE into
@1RI|1|J
– Plus: User-defined lines in @SYSTEM | @LINETYPES | <Planart-

Liste>
In the case of an action line (deviceless P&ID connection)

2. Administrator default: Line type of the connector as described in
SECTION 47.1.2.4.3: CONNECTOR-SPECIFIC LINE TYPES.
3. Default value for deviceless connections

4. User selection of the line type in the report (mouse menu)
The following are available for selection by the user:
– Standard table @1RI|1|K
– Plus: User-defined lines that were transferred from USERLNTYPE into
@1RI|1|K

– Plus: User-defined lines in @SYSTEM | @LINETYPES | <Planart-

Liste>
47.1.2.4.2 Structure of @1RI|1|J and @1RI|1|K

Name Any. The order of the list is determined on the basis of the name. This
also determines the order in which the line types are offered to the user.
Description This text appears in the Line types drop-down field.
Symbol is ignored. The code in the Value1 field solely determines the line
type.
Value1 This code determines the line type. There are the following options:
Code name Main purpose in use

[1 - 10] Predefined Windows lines. Here 1, 2, 3, 5, 8, and 9 are
different lines, the others are repetitions. It makes no
difference whether you input “1” or “001”.
[11 - 99] LogoCAD lines
[100 - 115] P&ID pipes
[116 - 117] Action lines
[118 - 120] P&ID pipes
[128 - 399] P&ID pipes
[400 - 412] EE connections, currently not used
[413 - 999] Reserved
[1000 - ] User-defined line types corresponding to USERLNTYPE.
Value2 - Value10 Are ignored.

Please note that if there is an invalid value in Value1 field, such as a text, then
under certain circumstances the entire line design function no longer works
and no line types can be allocated to the connections.
Please note that the entries in USERLNTYPE can be used in two different
ways in P&ID:

• You can make an allocation on the basis of the type of diagram via
LINETYPES. These line types are then available for both pipes and action
lines.
• In standard tables @1RI|1|J and @1RI|1|k you can directly call up an entry
from USERLNTYPE. These line types are then only available either for
pipes or for action lines.
Both the above options can be used in parallel. Thus the same line type can be
offered several times.
Since the designation of the line type is not taken from USERLNTYPE but
is defined in the standard table that accesses USERLNTYPE, the same line
type can thus have different designations.
In other words, the user probably would not notice that two different entries
ultimately refer to the same line type.
47.1.2.4.3 Connector-specific line types

Connector-specific types of lines can be defined in P&ID if:
• there is an action line (a deviceless P&ID connection)
• At least one connected component possesses the following connector type:
Single line with one of the following sub-types
– Action lines or
– Medium
There is a standard table ConnectionType[TYPE] in the system project for
each connector type. Since connector-specific lines are only possible in P&ID
for connector type Single line , only standard table ConnectionTypeI is
required.
Peculiarities
The details are only used at the point in time when the connection is created
on the report. For that reason all the graphic settings of the connection can also
be changed retrospectively.
Value3 : Designation of the line type, see SECTION 47.1.2.4.2: STRUCTURE OF
@1RI|1|J AND @1RI|1|K.
Value8 to Value10 : Are ignored.
47.1.2.4.4 Old versions

ReleaseDB, project System :
@SYSTEM | @LNTYPE.

@SYSTEM | @LNWIDTH.
These lists are not used for the functions described above and only exist for
reasons of backward compatibility.
47.1.2.5 Lines in EE
The following explanations apply to reports with the options script entry
Application = “ELO”.
The display of connections is done in the following order:

2. Line type of the bridge
3. Administrator default: Line type of the connector as described in
SECTION 47.1.2.3: CONNECTOR-SPECIFIC LINE TYPES.
4. Default value of the connection (continuous)

5. User selection: Line type in the report (mouse menu)
If you mouse-click on a connection in an EE report, you are given the
following line types to choose from:
Continuous
Dashed
Dotted
Dash-dot-dash
Long dash
Short dash
This list use Windows defaults and cannot be changed.
• Plus: Diagram-type-specific lines (LINETYPES)
See SECTION 47.1.2.2: DIAGRAM-TYPE-SPECIFIC LINE TYPES (LINETYPES).
47.1.2.5.1 Connector-specific line types

Connector-specific line types can be defined in:
Connector diagrams
Peculiarities
Value2 : Line thickness. The line thickness can no longer be changed manu-
ally. If there is no input, the default setting is 0.35.
Value3 : Designation of the line type, see SECTION 47.1.2.4.2: STRUCTURE OF
@1RI|1|J AND @1RI|1|K.

Value4 -Value6 : RGB colors of the line.

Value7 : Layer of the lines.
47.1.3 The Assign object tool (Identifier tool)
This tool is used to retrospectively modify objects within an interactive

report. The following options, among other things, are available:
• Automatically,
• change base object,
• change planning object,
• make a break in a connector.
Simply drag the desired new object with the Object tool onto an object on the
drawing area. The object in question in the Interactive Report changes color.
If another base object or a planning object are allocated, then the symbol dis-
play in the plan changes correspondingly. Connections are retained as far as
possible.
47.1.4 Text tool

If the Text tool is activated, you can set defaults for all new texts in the
dialog window Text parameter .
See SECTION 43.2.4.1: TEXT DEFAULTS.

Font Type on the Font field or click on the [...]

button. The Font dialog field appears.
Here you can input values for the font,
font style, size and display.
Color The color settings that are made here
apply to the text itself.
Angle Angle of the text in relation to its place-
ment point. If the text is rotated by means
of the mouse, the new angle is automati-
cally entered in this field.
Soft On The text is placed at a short distance from
the text frame.
Off The text is placed without any spacing.
Alignment Select the relevant button to determine the
position (alignment) of the text within the
text frame. If there is no text frame, the
text is aligned about the placing point.

Placing a template on a report Designer as Interactive Report
Path text Only in EE reports.

Interactive reports of the EMR module
often have a invisible checker pattern that
is used for better orientation. in this pat-
tern, the columns are designated as
“paths”, the rows as “zones”. Creates a
text that is output in the description of the
report objects of a path.
Apply Activated: all settings are applied
immedeately immedeately. No [RE-EVALUATE] is neces-
sary.
47.2 Placing a template on a report

ing!
47.3 Placing a report on a report

Reports can be placed on reports. (A number of rules must be followed when
doing this, concerning the type of plan, etc.)
The connection to the placed report is retained. If the positioned report is
changed, the positioning of this change will also be visible after the next
refresh.
You can find the | OPTIONS command in the mouse menu by right-clicking on
the control triangle at the top left in the placed report:
• In this dialog window it is possible to change the positioned document for

another one by dragging another object into the Document field. The exact
coordinates can be input.

Designer as Interactive Report Editing properties
|CONVERTING PLACED DOCUMENT

The connection to the positioned report is broken and changes are not trans-
ferred any longer. On the report there are now individual objects and connec-
tions that only react individually to changes. In other words: if the objects are
modified in the Navigator, the changes are transferred to the report. But
changes in the original positioned report are not transferred any longer.
47.4 Editing properties

If you mouse-click in the Interactive Report on an object that also exists as a
planning object, then three text edit fields for name, label and description
appear at the top in the report:
An exclamation mark [!] appears on the right when you input a text. The input
is only accepted once you have clicked on the exclamation mark or pressed
<Return>. Until you have clicked on the exclamation mark, the input can be
undone by pressing [Esc] for each text field and the original text is restored.
47.5 Mouse menu

| Settings
| FIXED
This object cannot be changed, regardless of which connections exist to other
objects. This option is the default setting for newly placed objects.

Mouse menu Designer as Interactive Report
| SEARCH TEXT
The Search conditions dialog window opens when you call up the Search
text setting:
If this option is used with planning objects, the objects then only continue to
function as placeholders. They are shown in red in the Interactive Report.
The object changes depending on a planning object in the Comos tree struc-
ture. Example:
Assume that an object that is to act as a template for a motor is placed on an
Interactive Report. M1 is input for the search text, for example. When the
report is created in the planning project, an attempt is made to find a motor
with the name M1. The object that had been placed originally is replaced
when a valid object is found.
Base object The name of the placed object is input in this text field.
If the search text does not lead to a valid result, the
original object that had been placed continues to be
displayed.
Object This field allows you to set up a search text quickly.
An object can be pulled on the field by means of drag
& drop. The Number of hierarchical levels and
Search text fields are filled in automatically when a
valid object is found.

Designer as Interactive Report Copying and inserting on a report
Start object for Document : A valid object is sought, starting from the
text search document.
Unit : A document can have a cross-reference to a unit.
The Unit option jumps to the referenced unit and
attempts to reference a valid object relative to it.
Location : A document can have a cross-reference to a
location. The Location option jumps to the referenced
location and attempts to link a valid object relative to
it.
Number of hier- Gives the number of levels to jump upwards, begin-
archical levels ning from the starting object.
Search text Here you input the name of the object that is to replace
the object that had been placed originally.
47.6 Copying and inserting on a report

ing!
47.7 Installation plans

Installation plans make it possible to illustrate electrical installations (such as
building electrical systems) in Interactive Reports. The objects are corre-
spondingly shown in color in the report.
47.7.1 Attributes
The setting of graphic attributes in IT plans is controlled via the “IT ” tab.
47.7.2 System templates and Standard tables
System project: Standard tables @SYSTEM | @DRW_Type, plan type RI_IT

Electrical installation .

ANSI plans Designer as Interactive Report
47.7.3 Automatic rotation
In the case of base objects for installation plans, the “AutoAlign - Automatic
rotation” attribute is located on the “SYS - System information ” tab. If this
option is activated, planning objects that are located on this base object are
rotated, automatically with respect to the nearest available line or symbol. The
lines or symbols can also run obliquely, the object is made to match the
oblique angle.
47.7.4 Scaling symbols
If script option ScaleForObjects = False has been set, individual objects

can be scaled by entering DoScale = True in the symbol script for the base
objects. See also SECTION 46.4.2.57: SCALEFOROBJECTS (BOOLEAN).
47.7.5 Scale
You can find the OPTIONS | SCALE command in the middle of the right mouse
menu. This reduces the size of the display of the symbols on the report.
47.7.6 Oblique connections
Applicable to: installation plans, P&ID plans

If the EnableButtonOblique = True option had been set in the
options script of a template file, the “Oblique” checkbox appears in
the corresponding reports with the Connection tool. Oblique connec-
tions are permitted as well if the checkbox is activated, meaning that the auto-
matic right-angle function has been deactivated.
47.8 ANSI plans
47.8.1 ANSI cables
EnableButtonANSICable = True
If the option EnableButtonANSICable = True had been entered in the

options script of a template file, then the additional icon ANSI cables
appears in the corresponding Interactive Reports.

Designer as Interactive Report ANSI plans
This tool allows multiple connection lines to be grouped together graphically.

Thus all the connection lines remain unbroken. Note that this functionality
does not work with oblique connections.
Operation
• Click on the ANSI cables icon.
• Draw a horizontal or vertical line with two mouse-clicks. This line fulfils
two functions:
The starting point of the line is the point through which the grouped cables
run.
The horizontal or vertical length of the line determines the lengths of the
grouped area.
• After the second mouse-click, which determined the end of the line, the
mouse cursor changes into a marking pointer. Drag out a selection frame or
mark the cables with <Shift> + mouse-click.
• Confirm with <Return>.
If the grouped area is to run in the middle of the connections, then the line
must be made through the middle:

ANSI plans Designer as Interactive Report
If the line is drawn at one point, the grouped area also passes through it:
Ungrouped grouped cables

Since all the connections are to remain unbroken, you can simply switch a line
into manipulation mode with two separate mouse-clicks. Grab points appear
at the corner points:
The bent line can be placed again as desired with the aid of the grab points.

Standard tables of base projects SO1
48 Standard tables of base projects
48.1 SO1
48.1.1 @1PE Process Engineering
48.1.1.1 AE Aspen Units

Application: In the import base objects
Name Unique string,
also the same as the ASPEN name
Value 1 Any value. The same as the NestedName of the Comos

attribute.
Value 2 - Not used.
Value 10
@1PE |PO |SIM Simulation objects...

|BLC
|STR
|SUB
48.1.1.1.1 DELTA-T Aspen units

“DELTA-T” is the name of an attributes group in ASPEN.
Effect: First of all Comos checks when importing whether there is a further
standard table whose name matches one of the groups of attributes to be
imported underneath “AE Aspen Units”. If that is the case, then the special
standard table that is located underneath is used instead.
This allows you to have different mappings of the Comos attributes for indi-
vidual ASPEN groups.
Example: In Comos, temperatures and temperature differences are managed
in separate attributes, both of which possess the unit “C”. For that reason there
is an entry “C” in “AE Aspen Units” which accesses attribute T01.10. T01.10
is responsible for the temperature. In standard table DELTA-T underneath it
there is likewise an entry “C”, which accesses attribute T03.10. T03.10 is
responsible for the temperature.

SO1 Standard tables of base projects
48.1.1.1.2 HEAD Aspen units

See DELTA-T.
48.1.1.2 CA Attributes-Catalog
Application: @1PE |DS |@Y CA Attributes-Catalog
The name of the standard table is the same as the name of the attribute.
48.1.1.3 EQ Equipment
Application: @1PE |DS |@Y CA Attributes-Catalog.
The name of the standard table is the same as the name of the attribute.
48.1.1.3.1 ND0227 - ND0229 TEMA character

TEMA belongs to the topic “Heat exchangers”.
Name Unique string.
Value 1 Unique value.
Value 2 Aspen: Import
Value 3 Pro/II Import
Value 4 Hysys Import
Value 5 HTRI Import
Value 6 HTFS Import
Value 7 HTFS Export
Value 8 - Not used.

Value 10
48.1.1.4 HE HTFS Physical Units

As for SECTION 48.1.1.1: AE ASPEN UNITS.

48.1.1.5 IO Import Options

Stream objects and column objects (among others) are imported during an
import operation. The structure is as follows:
[-]- Stream object MSSIM
|
[-]- Stream components MAPSIM
[-]- Column object COLSIM

|
[-]- TRSIM
|
[-]- Stream components MAPSIM
48.1.1.5.1 ND0931
Application (example): base data
@1PE |DS |@O Documents |PRZ ProII, IP Import paths tab.
This attribute is evaluated if you click on the [IMPORT] button on the
ID Import Data tab.
Effect: in MAPSIM, a varying number of attributes are imported on the
“Component data ” tab. The smaller the number of attributes that are
imported, the more quickly the import operation is completed.
Only bulk : the substance portion is only imported into group “Total”.
mole fractions : the substance portion is also input into the other groups.
48.1.1.5.2 ND0932
Application (example): base data
@1PE |DS |@O Documents |PRZ ProII, IP Import paths tab.
This attribute is evaluated if you click on the [IMPORT] button on the
ID Import Data tab.
not imported : only the COLSIM column objects are created.
trays/stages without compositions : COLSIM and TRSIM are created.
trays/stages & compositions : COLSIM, TRSIM and MAPSIM are created.
Please note: MAPSIM can only be switched off under the column. MAPSIM
is always imported under the stream.

48.1.1.6 NORM ANSI/DIN Catalog

Self-explanatory.
48.1.1.7 SYS System
48.1.1.7.1 1 Graphic representation
E Symbol inscription
Is used internally.
H Line widths
Is used internally.
I Colors
Specifies the colors of PFD/P&ID objects.
Name Unique string,
also controls the order of the list in the user selection.
Value 1 Any value. The same as the Logocad color code.
Value 2 - Not used.

Value 10
Sample application: @1PE |PO |SO |PS |RI Color.

Peculiarity:
The value “- 1” means that the user has set a Windows color manually. The
Windows color code is stored internally. In that case the color that had been
assigned to the object on the Interactive Report applies.
You can switch over at any time to one of the fix color values managed in this
standard table. In addition, this value corresponds to the Logocad color code.

J Logocad line types

These are the line types that are available in PFD/P&ID diagram types.
Name Unique string,
also controls the order of the list in the user selection.
Value 1 This code defines what pattern the line type has.
Value 2
Value 3
Value 4 - Not used.
Value 10
This is used, for example, in base object PI|EN|D|03|01|Z1 Z Pipe

segment| @A Z , tab RI options tab, attribute LNTYPE .
Value1 main assignments:
Code name Main purpose and application
[1 - 10] Predefined Windows lines. Here 1, 2, 3, 5, 8, and 9 are
various lines, the other are repetitions. It makes no
difference whether the notation “1” or “001” is used.
[11 - 99] LogoCAD lines
[100 - 115] P&ID pipes
[118 - 120] P&ID pipes
[128 - 399] P&ID pipes
[400 - 412] EE connections, currently not used
48.1.1.7.2 @NC Naming convention

This standard table controls the naming of important folders and attributes.

Thus, the corresponding folders cannot simply be renamed in the planning

data. A correspondingly named folder can only be recognized in the planning
data if a new name has been entered in this standard table.
Also applies for the major attributes.
48.1.1.7.3 @UNITSYSTEMS Unit systems

Is used internally.
48.1.1.7.4 BOOL
Only used for internal purposes. Checkboxes are initialized with the aid of
these standard tables.
48.1.1.7.5 ND0208 Routing status

When a process stream is to be displayed in CM, it is transferred into a dummy
pipe which is then routed. This pipe routing can fail at various points, for
example already at the process stream. When the pipe routing is checked, a
check is also made as to whether the stream can be routed and the result is
input at the stream on the SYS tab. In this way you can still check later
whether a failed routing of the dummy pipe may already have failed when
routing the stream.
48.1.1.7.6 NSYS Standard system

Toggles the NSYS attribute between ANSI/DIN for objects via the SYS tab.
Example:
PE |PO Process objects|EQ Equipment, System tab.
48.1.1.7.7 SY0001 Object classes

Identifies the PE objects. Thus the same mechanism as the sub-class of
objects.
48.1.1.8 TD Technical data

Application: PE |DS |@Y CA.
The name is also the name of the attribute.
48.1.1.8.1 ND0238
Controls the 3D pumps template:
Base project, planning view, @Template |PE |02 |04.

Is only evaluated in 3D (CM).
48.1.1.8.2 ND0250
Controls the 3D valves template:
Base project, planning view, @Template |PE |02 |08.
Is only evaluated in 3D (CM).
48.1.1.9 XX Other
48.1.1.9.1 TRAYSYMBOLTYPE
Application: Section of the column, whether the section is shown with or
without the floor (this only changes the symbol and not the planning data).
48.1.2 @1RI / RI catalog
48.1.2.1 1 Presentation
48.1.2.1.1 E Symbol description

Is used internally.
48.1.2.1.2 J / Logocad line types

These are the line types that are available in P&ID diagram types. They are
used, for example, in base object [PI|EN|D|03|01|Z1 Z Pipe segment| @A
Z , RI options tab, attribute LNTYPE .
48.1.2.1.3 K / Line types for action lines

These are the options for an action line.
See SECTION 47.1.2.4: LINE TYPES IN P&ID.

48.1.2.2 3 Device data
48.1.2.2.1 P Function
A Function processing / C Location of measurement indication

This is evaluated in the script of P&ID measuring functions. Controls the dis-
play of a measuring function in diagram type RI_ANSI. See also
SECTION 57.4.8.2: BASIC SYMBOL.
48.1.3 @3D 3D/ISO Catalog
Is used internally.
48.1.4 @3DCM Catalog 3D
The standard tables that are used in Viper: Conceptual Modeller are managed
here.
48.1.5 @EXF
Is used internally.
48.1.6 @IRF_<diagram type> z.B.: @IRF_DETAIL
This table contains the predefined variables (%N texts) that can be selected in
the text function of the Symbol Designer, see SECTION 45.4: PROPERTIES OF A TEXT.
In the base objects, a symbol should be designed for all (required) diagram
types. In other words, this symbol is also only available for this diagram type.
Different %N texts are made available, depending on the diagram type for
which the symbol was created.
As far as programming is concerned, these functions can be used indepen-
dently of the standard table. However, if the table is deleted, then the func-
tions are no longer displayed in the input help of the text function.
Value1 specifies the identification key of the text function, and Value2 the
layer .

48.1.7 @Local
The local standard tables of attributes are stored here. The name of the stan-
dard table is at the same time the UID of the attribute. These standard tables
may not be edited here, but only at the specified attribute.
48.1.8 @SYSTEM / Tables for Comos
Please note: the standard tables in this branch are used for internal system
purposes and are evaluated by the program code. The tables may not be dele-
ted, extended or changed.
48.1.8.1 @SYSTEM | @AREA / Sheet area

This list is used as follows: base object @Y Catalog attributes | CHP
| SYSTEM , | SYS tab, attribute AREANAME .
Sheet areas control where objects are drawn on Interactive Reports that had
been created automatically.
Value 1 is offered as a standard table at the AREA objects
Value 2: toggles field-control view
48.1.8.2 @SYSTEM | @BRIDGESYMBOLS / Bridge symbols

Normally the @BridgeType, which supplies icons, is evaluated. For example,
for export operations you can use these symbols instead.
Terminal plans
The table connects symbols for bridge objects with the associated icons via
keys. The keys are fixed.
48.1.8.3 @SYSTEM | @CLASS | <diagram type> / Header classes

Underneath the @SYSTEM | @CLASS node there are standard tables that
store the identification keys for symbol texts of a specific diagram type. The
standard table must have exactly the same name as the diagram type.
Name : identifies the list entry internally within Comos
Value1 : the ID
Symbol texts on Interactive Reports can be edited through their identification
keys.

48.1.8.4 @SYSTEM | @CONNECTION / Connection

This standard table contains symbols (with %N texts) for reference breaks for
EE/I&C.
48.1.8.5 @SYSTEM | @IMP_ARROW / Implementation arrows

This standard table contains symbols for diagram type RI ; to select another
diagram type call the context-sensitive menu from the Diagram type column
header.
48.1.8.6 @SYSTEM | @LINETYPES | <diagram type, list> / Line types

The line types that had been created in @SYSTEM | @USERLNTYPE can
be made available for all the modules through standard tables in a way that is
specific to the diagram type. The name of the list must exactly match the dia-
gram type of the report. For further information see SECTION 47.1.2.2: DIA-
GRAM-TYPE-SPECIFIC LINE TYPES (LINETYPES).
48.1.8.7 @SYSTEM | @MASK / Masks (default) AKZ

Contains the starting value and mask (regular expression) for the text masks
of objects that are used within AKZ (Unit labelling system).
Name = FullName of the CDevice, Value1 = mask, Value2 = starting value
The list can also be used individually. The list is checked into the project and
the values are modified accordingly.
48.1.8.8 @SYSTEM | @MASK01 / Masks (KKS)

of objects that are used within KKS (plant labelling system).
48.1.8.9 @SYSTEM | @MASK02 / Masks (ANSI metric)

of objects that are used within the US ANSI standard.

48.1.8.10@SYSTEM | @PIPECONSYMBOL / Pipe: sheet reference symbol

This standard table contains symbols for diagram type DIN 24 81 , please
select the desired diagram type from the context-sensitive menu of the Dra-
wing type column header.
48.1.8.11@SYSTEM | @PIPEENDSYMBOL /Pipe termination symbols

This standard table contains symbols for diagram type DIN 24 81 , please
select the desired diagram type from the context-sensitive menu of the Dra-
wing type column header.
48.1.8.12@SYSTEM | @PipeCutMode Pipe cut mode

This only has an effect on Interactive Reports. In the planning data, a connec-
tion on a P&ID report is represented by a three-level structure. This value con-
trols what happens in the planning data when, in a report, an object is placed
on a pipe.
48.1.8.13.@SYSTEM | @S7Classes / S7 classes

Standard table to exchange data between Comos and the Siemens Siematic
world. See SECTION 56.3: SIMATIC S7 (EXPORT, IMPORT) for more information.
48.1.8.14@SYSTEM | @UNITMAPPING / Representation of English and

metric systems
In the unit systems, imperial and metric units of a unit group can be assigned
to one another for conversion purposes. These assignments are stored in this
standard table. See SECTION 11.2.1.2: THE LOWER “UNITS” DIALOG AREA“ for more
information.
48.1.8.15@SYSTEM | @USERLNTYPE / User-defined line types

Administers the various line types that are available in Comos. Users can
specify their own line types via base standard table @SYSTEM
| @USERLNTYPE. The types that are defined here are made available
through the @LINETYPES of a specific diagram type. See SECTION 47.1.2.1:
USER-DEFINED LINE SAMPLE (USERLNTYPE) for more information.

48.1.9 ET Electrical engineering
See SECTION 59.1: BASE DATA, LISTS, TEMPLATES.
48.1.10 FP Functional engineering
The following applies for the standard tables in this branch:

• The name of the table is the same as the FullName of the CDevice for which
the table is valid.
• The symbols are not created in the standard tables. The selection of a table
entry often changes the symbol as well, but not in the usual way that the
table entry itself possesses a symbol. Instead, a graphically relevant
attribute is evaluated at the CDevice.
48.1.11 FT Fluid engineering
Belongs to the Fluid Engineering module.
48.1.12 IC Catalog I&C
48.1.12.1S Signal
48.1.12.1.1IOA System signal mode

This table is used as follows: base object Signals , | SYS tab, attribute IOA .
This list contains all the objects / symbols that there are for FDs. The symbols
themselves are not created in the standard table but instead are controlled
within the program code (in ROSignal.dll). The table may not be edited or
extended.
48.1.13 ME Mechatronic
Belongs to the Mechatronic module.
48.1.14 PI Catalog P&I
Belongs to the P&ID module.

48.1.14.1Y Attributes catalog
48.1.14.1.10 Attribute collection
1 Presentation: I Colors
The first column contains the code that is entered in the “Value 1 ” column of
the standard table.
Name R G B Description
1 0 0 0 Black
2 0 0 20
3 0 0 40
4 0 0 60
5 0 0 80
6 0 0 100 Blue
7 0 20 0
8 0 20 20
9 0 20 40
10 0 20 60
11 0 20 80
12 0 20 100
13 0 40 0
14 0 40 20
15 0 40 40
16 0 40 60
17 0 40 80
18 0 40 100
19 0 60 0
20 0 60 20
21 0 60 40
22 0 60 60
23 0 60 80
24 0 60 100
25 0 80 0
26 0 80 20
27 0 80 40
28 0 80 60
29 0 80 80

30 0 80 100
31 0 100 0 Green
32 0 100 20
33 0 100 40
34 0 100 60
35 0 100 80
36 0 100 100
37 20 0 0
38 20 0 20
39 20 0 40
40 20 0 60
41 20 0 80
42 20 0 100
43 20 20 0
44 20 20 20
45 20 20 40
46 20 20 60
47 20 20 80
48 20 20 100
49 20 40 0
50 20 40 20
51 20 40 40
52 20 40 60
53 20 40 80
54 20 40 100
55 20 60 0
56 20 60 20
57 20 60 40
58 20 60 60
59 20 60 80
60 20 60 100
61 20 80 0
62 20 80 20
63 20 80 40
64 20 80 60
65 20 80 80

66 20 80 100
67 20 100 0
68 20 100 20
69 20 100 40
70 20 100 60
71 20 100 80
72 20 100 100
73 40 0 0
74 40 0 20
75 40 0 40
76 40 0 60
77 40 0 80
78 40 0 100
79 40 20 0
80 40 20 20
81 40 20 40
82 40 20 60
83 40 20 80
84 40 20 100
85 40 40 0
86 40 40 20
87 40 40 40
88 40 40 60
89 40 40 80
90 40 40 100
91 40 60 0
92 40 60 20
93 40 60 40
94 40 60 60
95 40 60 80
96 40 60 100
97 40 80 0
98 40 80 20
99 40 80 40
100 40 80 60
101 40 80 80

102 40 80 100
103 40 100 0
104 40 100 20
105 40 100 40
106 40 100 60
107 40 100 80
108 40 100 100
109 60 0 0
110 60 0 20
111 60 0 40
112 60 0 60
113 60 0 80
114 60 0 100
115 60 20 0
116 60 20 20
117 60 20 40
118 60 20 60
119 60 20 80
120 60 20 100
121 60 40 0
122 60 40 20
123 60 40 40
124 60 40 60
125 60 40 80
126 60 40 100
127 60 60 0
128 60 60 20
129 60 60 40
130 60 60 60
131 60 60 80
132 60 60 100
133 60 80 0
134 60 80 20
135 60 80 40
136 60 80 60
137 60 80 80

138 60 80 100
139 60 100 0
140 60 100 20
141 60 100 40
142 60 100 60
143 60 100 80
144 60 100 100
145 80 0 0
146 80 0 20
147 80 0 40
148 80 0 60
149 80 0 80
150 80 0 100
151 80 20 0
152 80 20 20
153 80 20 40
154 80 20 60
155 80 20 80
156 80 20 100
157 80 40 0
158 80 40 20
159 80 40 40
160 80 40 60
161 80 40 80
162 80 40 100
163 80 60 0
164 80 60 20
165 80 60 40
166 80 60 60
167 80 60 80
168 80 60 100
169 80 80 0
170 80 80 20
171 80 80 40
172 80 80 60
173 80 80 80

174 80 80 100
175 80 100 0
176 80 100 20
177 80 100 40
178 80 100 60
179 80 100 80
180 80 100 100
181 100 0 0 Red
182 100 0 20
183 100 0 40
184 100 0 60
185 100 0 80
186 100 0 100
187 100 20 0
188 100 20 20
189 100 20 40
190 100 20 60
191 100 20 80
192 100 20 100
193 100 40 0
194 100 40 20
195 100 40 40
196 100 40 60
197 100 40 80
198 100 40 100
199 100 60 0
200 100 60 20
201 100 60 40
202 100 60 60
203 100 60 80
204 100 60 100
205 100 80 0
206 100 80 20
207 100 80 40
208 100 80 60
209 100 80 80

210 100 80 100
211 100 100 0
212 100 100 20
213 100 100 40
214 100 100 60
215 100 100 80
216 100 100 100 White
217 10 0 0 Shades red
218 30 0 0
219 50 0 0
220 70 0 0
221 90 0 0
222 0 10 0 Shades green
223 0 30 0
224 0 50 0
225 0 70 0
226 0 90 0
227 0 0 10 Shades blue
228 0 0 30
229 0 0 50
230 0 0 70
231 0 0 90
232 0 10 10 Shades cyan
233 0 30 30
234 0 50 50
235 0 70 70
236 0 90 90
237 10 0 10 Shades magenta
238 30 0 30
239 50 0 50
240 70 0 70
241 90 0 90
242 10 10 0 Shades yellow
243 30 30 0
244 50 50 0
245 70 70 0

246 90 90 0
247 13 13 13 Shades gray
248 27 27 27
249 33 33 33
250 47 47 47
251 53 53 53
252 67 67 67
253 73 73 73
254 87 87 87
255 93 93 93
48.1.15 RIDIVPOS /P&I measuring position lettering
The function %N Position is also used in the script of a symbol for a P&ID
measuring function. In addition to that, the script of the measuring function
also searches for the | RI | TEXTMOD attribute of the measuring function.
This attribute uses standard table RIDIVPOS . If the attribute is found, its
value is read and the text of %N Position is set up accordingly.
48.1.16 RIFLOWDIRSYMBOL / P&I Flow direction symbol
An obsolete standard table.
48.1.17 RILNTYPE / Pipe identification
An obsolete standard table.
48.1.18 RIST / Substance stream properties
Is used internally.
48.1.19 RK Pipe class
Is used internally.

Standard tables of base projects SO1_EXT
48.2 SO1_EXT
48.2.1 eCl@ss
Since eCl@ass works with a large number of attributes, a separate base

project was created in which the corresponding standard tables and base data
are made available:
Dialog window Open project , base project SO1_Ext .

SO1_EXT Standard tables of base projects

Designing databases (customizing) Definitions
49 Designing databases (customizing)
49.1 Definitions
49.1.1 Relationship between base objects and planning objects
Base objects
Base objects are templates for planning objects. You can only edit base
objects if you possess the Base data function right. It is entirely up to you to
decide in how much detail the base objects – i.e., the templates – are to be cre-
ated. The more precisely you design the templates (the base objects), the more
you need to determine the “properties”.
Base data
The totality of the base objects is called the base data. The base data is dis-
played in the Navigator on its own “Base objects” tab. When base data is cre-
ated within the planning project, we talk of “local base objects”, see
SECTION 49.1.2: LOCAL BASE OBJECTS. If base objects are created within the base
project, then they are called “global base objects”.
The base project

Although the Base objects tab is visible in all projects, nonetheless
you should not change most of the objects that are visible there. The
reason: Most of the base objects are in the base project and can only be
changed there. Use the | OBJECT IN BASE PROJECT context command to switch to
the base project.
Comos is supplied together with a sample database in which a variety of base
objects have been prepared beforehand. Please note that some of the prepre-
pared base objects are purely administration objects that should not just be
deleted.
Inheritance of properties to the planning objects

Planning objects inherit the preprepared properties of the base objects. There
the preprepared properties are supplemented with planning data. In this way
the planning object is developed into a precisely specified characteristic form
of the underlying base object.

Definitions Designing databases (customizing)
49.1.2 Local base objects
Base objects are normally created within the base project. Fundamentally
there is the option to create local base objects in the planning project. Stay
within the planning project and switch to the Base objects tab.
Call: Right mouse button | NEW BASE OBJECT
The local base object is distinguished from the base objects of the base project
by a blue globe.
Mixed structures
It is technically possible, but not advisable, to mix local and global base
objects. If local base objects are located underneath global base objects, cer-
tain operations can cause the database to balloon in size. If, for example, the
| COPY STRUCTURE function is used, the global base objects are duplicated in
the form of local base objects.
The same effect happens if a project is sourced out and connected again with
the base project after being sourced out. The branches of the tree, that previ-
ously only partially contained local base objects, are then completely dupli-
cated as local base objects. If you wish to undo this duplication, the original
local base objects have to be sorted again (tediously), and the newly created
base objects have to be deleted.
In order to prevent this, local and global base objects should always be placed
in completely separate branches of the tree. If structures from the global base
objects are required, a global base object can be linked with a local base object
via the Reference field.
Mixed structures are not allowed in the case of documents. Documents can
only be created under a base object if the base object is within the project that
has just been opened.
49.1.3 The tree structure: Hierarchies
All the objects lie within a tree-type structure. An object lying underneath is
called a “child object”; an object lying above is called the “parent object”.
This tree-type structure is of major importance and especially for base objects,
since this structure is used to transport information in a simple way (see the
next section).

Designing databases (customizing) Creating new base objects
There are a number of views to make the tree-type structure somewhat easier
to understand. In particular, the options “Folder ”, “Group ” and “Structure ”
are useful, and also the “visible for all users ” option. All these options are
explained below, see SECTION 12.2: “SYSTEM” TAB.
49.1.4 Information transfer: inheriting
We explained above that planning objects take over the information (“proper-
ties”) of the base objects. But this is not the only method to pass on informa-
tion within Comos.
In particular, (almost) all the information along the base data tree is inherited
for the base objects.
In other words: All subordinated base objects are automatically given all the
information (“properties”) that was defined at the superordinate object (the
“owner”). In this way the density of the information increases as you go
deeper into the base data tree.
For further information please see SECTION 7: INHERITANCE.
49.2 Creating new base objects

Creating a new base object is as important as creating a new tree node in the
hierarchical structure.
• Switch to the desired project, usually the base project.
• Now mark the level under which you wish to create a base object.
Call: Right mouse button | NEW BASE OBJECT
49.3 Database adjustment

This tool undertakes a number of tasks for the administrator concerning
administration of the base objects. Example: base objects that are vital within
the system are stored in Comos 7.0 under the @System branch. Although the
older base objects structures are supported as well in Comos 7.0, we most
emphatically recommend changing over to the new system for managing the
base objects. Only the new system will be supported in future versions of
Comos.
The database adjustment now transfers the old structures to the new struc-
tures. The Administrator can decide individually for each base object whether
it is to be incorporated into the new administration scheme.

Database adjustment Designing databases (customizing)
The entries that have already been executed are dimmed (greyed out) in the
Database adjustment dialog window.
Comos Version 7.0
Adjust Standard tables

Open the Standard table window via Administrator |Base data |Stan-
dard tables
The @CLASS | DETAIL and @USERLNTYPE standard tables are created in the
base project under @SYSTEM. The @DRW_TYPE standard table is updated in the
system project under @SYSTEM.
3D Electrical engineering
The GD Geometry tab is created with attributes under @Y Catalog attribu-
tes | ET Electrical engineering |General Chapters (tabs).
Electrical engineering circuit diagram

The EBD and HSD tabs are created with attributes under @Y Catalog attri-
butes | ET Electrical engineering |General Chapters (tabs).
Create status objects

Create the object @Status together with the default elements under @System
|@D. Any status objects that had already been created are not overwritten, only
the missing objects are created.
Document groups: Expanded options

Assigns the System information tab to an object in the Documents group .
See SECTION 40.2: PREPARING THE BASE DATA OF DOCUMENT GROUPS concerning doc-
ument groups.
Procedure:
Please do not use a general documents group base object for the conversion.
If a general documents group base object is used, this creates the problem that
now all the documents groups posses the System information tab. However,
this tab can only be used meaningfully in the @NameSystem branch.
First of all a documents group of its own should be created, whose sole task
is to act as a base object for the conversion.
After the conversion this base object must be allocated to the planning
projects of the @NameSystem-documents group.

Designing databases (customizing) Preallocating connectors
Electrical engineering drilling diagram

The BHD tab is created with attributes under @Y Catalog attributes
| ET Electrical engineering |General Chapters (tabs).
Set up system structures

This menu item opens up an additional dialog window in which you can select
individually which objects are to be created in the base objects.
Background: in future base objects will be managed in Comos under @Sys-
tem.Base objects that had been at another position within the base data should
be collected here as well. Setting up the System structures tool supports the
Administrator in this: base objects are created or transferred.
49.4 Preallocating connectors
49.4.1 Preparing wires
49.4.1.1 Specific wires

Connectors can be preprepared in such a way that a cable / wire has already
been allocated when the planning object is created.
To do this, the cable that the wires relate to must be created as an element of
the base object. The base object has the example name “Test” in the following
description.
Open the Properties window of the base object. (If necessary, switch to the
base project). Switch to the Elements tab. The cable must exist as an object,
a link is not enough. Therefore you must select the | NEW command from the
context-sensitive mouse menu
Now open the Navigator and search for the desired type of cable. Please note
that cables are set up in two stages. You must open up down to the lowest level
of the tree to get to the right level. Drag the cable into the Reference field
and confirm with [OK].
Activate the Connectors tab for the next step. Open the Properties window
of a connector by using the context-sensitive mouse menu.
Search in the Navigator for the cable that had been created. If the default
setting of the Navigator is active, you can find the cable in the Detail window
when you click on base object “Test”. Open the tree-type structure of the
cable.

Preallocating connectors Designing databases (customizing)
You can now select one of the wires and drag it into the Cable index field .
In addition, the selected is displayed on the Connectors tab in the Connec-
tion via column.

If a planning object is created on the basis of this base object, the wires are
visible on the Connectors tab in the Connection via column. But since the
connection has not been made yet, the wires are marked as unconnected by
means of a cross with a question mark.
49.4.1.2 Non-specific wires (only with virtual elements)

Non-specific wires can also be used within virtual elements.
Open the “Test” base object and switch to the Elements tab. Create a new
element with | NEW from the context-sensitive mouse menu. This element
contains the virtual option (1 times , N times or default ). A base object, such
as an indicator, can be assigned to the element via the Reference field.
Now open the Properties window of the virtual element and switch back to the
Elements tab. Create an element, and this element within the element is
given a cable as the base object. Confirm with [OK].
The Properties window of a connector is opened on the Connectors tab of
the virtual element (in this case the indicator).
Now search within the tree-type structure for the cable that was created under-
neath the indicator. Drag the cable (not a wire) onto the Cable index field.
The name of the cable and an asterisk as a placeholder for the wires appears
in the field: @L.4 x 0,75.*

If the object is created within the planning project, in this example the object
“Test”, the planning object contains an “indicator” virtual element. The indi-
cator can be created via the | CREATE or | CREATE N functions. The first free
wire in the cable of the indicator is automatically searched for and input.
49.4.2 Preparing logical potentials
Connectors can be prepared in such a way that the allocation of a logical

potential already exists when the planning object is created.

Designing databases (customizing) Preallocating connectors
Basic principle: Create an element that has the same name as that of a connec-
tor. The program determines that the two “belong together” due to the simi-
larity of the names.
In detail:
The base object has the example name “Test” in the following description.
base project). Switch to the Elements tab. The logical potential must exist as
an object, a link is not enough. Therefore select the | NEW command from the
context-sensitive mouse menu.
Class Device
Name Name of the connector, e.g. CP1
Label Any
Sub-class Log. potential
virtual Off

When the planning object is created, the connection is given the logical poten-
tial with the same name if a logical potential has not already been set.
In order to see the result on the Connectors tab, the Log. potentials column
must first be made visible by means of the context-sensitive mouse menu.
Logical potentials support the NestedLabel function.
Effect: If a signal is under a fuse, for example, the potential label is placed
ahead of the label for the fuse.
49.4.3 Preparing signals

Connectors can be prepared in such a way that the allocation of a signal
already exists when the planning object is created.
Basic principle: Create an element that has the same name as that of a connec-
tor. The program determines that the two “belong together” due to the simi-
larity of the names.
In detail:
The base object has the example name “Test” in the following description.

Templates Designing databases (customizing)
base project). Switch to the Elements tab. The signal must exist as an object,
a link is not enough. Therefore select the | NEW command from the context-
sensitive mouse menu
Class Signal
Label Any
Sub-class -
virtual Off

When the planning object is created, the connection is given the signal with
the same name if a signal has not already been set
The result is visible in the Detail window: The connector includes the infor-
mation on the signal.
49.5 Templates
49.5.1 Definition
Templates can be any desired Comos objects.

Sole prerequisite: The objects must be organized in a specific way.
Templates have three advantages:
• They can be used as often as you wish without having to set them up from
scratch each time.
• Templates can be used intuitively by users. If the templates have been
organized correctly, it is almost impossible to use them incorrectly.
• Each application is saved. The applications that have been created from the
templates can be found quickly and edited together. For example, decision
tables and object queries evaluate the “applications”.

Designing databases (customizing) Templates
Copies from the “@Template” branch are given a pointer to indicate from
which template they originated (“backwards pointer”). This makes it possible
to locate all the applications of a template and to make use of change functions
that apply to them all if required. Here it does not matter how the copy was
produced (see below).
49.5.2 Organizing / preparing templates
1. “@Template”
Templates must be located under the “@Template” root node. An
individual “@Template” branch is managed for the unit view and the
location view respectively.
2. Template project is superfluous
The data can be stored as before in a template project, provided that the
data is also located there under a “@Template” branch. It is not necessary
to keep the data separate in base data projects and template projects.
3. Closed template structure
Templates only take over the hierarchical structures as well as the “inner
references”. References that “stick out” of the template block are lost
without any further notification. Templates must therefore always form
an enclosed whole underneath a “template node”.
4. Interactive Reports as templates (including document excerpts)
In the case of Interactive Reports the objects that are located on the
reports also belong to the template. (Document excerpts are also
organized such that the excerpt is created as a separate Interactive
Report.)
Preparing templates by means of drag & drop

You can simply copy an object or a branch from the “@Template” branch and
paste it.
Preparing templates by means of the | New mouse command

The Template reference must have been set at the base object on the System
tab to do this. This base object is then pasted into another base object as an
“element”.
49.5.3 Structure / retaining the structure
Please note: There may be only one Interactive Report under the template
node!

Templates Designing databases (customizing)
The owner of the report must be copied as a whole so that the objects are cop-
ied together onto the report. In other words, the owner of the report is the tem-
plate node.
If there are several reports under the template node, the program would not
know which report is to be copied and there would be a data collision.
The Create option is evaluated for a base object that possesses the pointer to
the template:
• The Block option: All the objects from the folder for the template are raised
by one level. Terminals are attached as required to existing terminal strips
of the same name. The folder is removed.
• All other options: The structure of the copied objects is retained.
49.5.4 Determining the positioning
Each template includes the required information on how it is to be placed.

This information is the location of the origin on the template:
X <> 0 and Y <> 0: Template can be placed freely as desired.
X = 0 and Y = 0: The template is placed with the origin on the origin of the
report.
X <> 0 and Y = 0: The template can only be moved along the X-axis.
X = 0 and Y <> 0: The template can only be moved along the Y-axis.
Use the | OPTION | SET ORIGIN command from the mouse menu to set the origin
accordingly.
49.5.5 Variants
Special points regarding components and devices in the “ELO” application

and for signals in the “FD” application.
If a report is in the Template branch, then the SETTINGS | OPTIONAL mouse
menu command is available for selected symbols. Symbols that had been
labelabeled accordingly are shown on the planning page in gray and with a
line through them if no device is available (variant control in the case of
reports). This mechanism does not affect the templates themselves but instead
the documents that are located in the template branch. Here the symbols
behave in the usual way: If there is no device the object is shown in red and
the connections to the symbol remain connected. Optional objects on the plan-
ning page are neither printed nor exported as DXF.

Designing databases (customizing) Labeling systems
49.5.6 Using templates
See SECTION 43.1.4: PLACING TEMPLATES regarding the use of templates.
49.6 Labeling systems

Labelabeling systems are a standard way of labeling all the objects of a unit.
Well-known labeling system are the [German] Units and Apparatus Labeling
System (in German, AKZ) or the [German] Power Station Labeling System
(in German, KKS).
A new labeling system should be created on the basis of the following
scheme:
1. Create a base object as “base”. For example, a new base object is

created underneath @U Unit or
@L Location .
2. Paste elements in the new base The labeling system is set up by

object by using drag & drop or means of the elements.
create as new.
3. Paste the base created in step 1. This object is pasted into the plan-
above into base object @J ning project via the mouse menu.
Project by using drag & drop.
Steps 1 - 3 are to be repeated for each labeling system.
Re step 1.
Initially a New base object of type Unit is pasted into the base project under-
neath base object @U unit (Alternatively, a location is used as the base.). This
object is used in addition as the topmost level of the labeling system, and at a
later point in time the base object will be referenced to it.
The unit is given:
• Any desired name, such as “Test”,
• Any desired description, such as “Test labeling system”,
• The Option Create mode option controls how narrowly the user must
comply with the labeling system. If the Normal option had been selected,
the default options New object etc., are also available to the user.
Deviations are thus possible.

Labeling systems Designing databases (customizing)
If the Elements option was stipulated, only objects that had been created
on the Elements tab are available. This means that deviations are
impossible.
Re step2.
The Elements tab is brought to the front.
Default method: Fetch a base object by using drag & drop

Use drag & drop to pull a base object onto the Elements tab of the unit. The
new element is automatically given the following settings:
• Virtual, n-times
The setting Virtual 1 times or N times makes it possible to stipulate
how many times the element (meaning the object of the unit) may be
created.
• Dereferenced
The dereferenced option is only available if the object was opened via the
Elements tab. This option is not visible if the object was opened via the
tree-type structure.
Dereferenced changes the inheritance structures: If an object was created
within the planning project on the basis of this base object, only the Name ,
Label , Description and Number fields are taken over. All the other
properties are skipped.
When the planning object is created, the information that was derived from
the dereferenced base object is lost: If a change is made later on the planning
page to any one of these four properties, it only takes effect on newly created
planning objects (i.e., those created after the dereferencing).
Instead, the link of the planning object to the base object refers one level
further: The base object that is created at the dereferenced base object as a
reference becomes the new base object of the planning object.
Alternative: Create new elements

Create new elements via the | NEW mouse command. The following elements
are given:
• A name. The name is part of the labeling system. If the plan was to describe
all the sub-units with the abbreviation SUBU, the name must be given
accordingly. Later, when multiple sub-units are created within the planning
project, a sequential number is automatically appended to the abbreviation.
• Any desired description.
• The unit option Normal or Elements .

Designing databases (customizing) Labeling systems
• The setting Virtual 1 times or N times .

• If applicable, the dereferenced option.
The following levels of the labeling system

The next level of the labeling system is created by opening the Properties win-
dow of an element (by right-clicking on it to open the context-sensitive mouse
menu) and pulling elements over by using drag & drop or else by creating
them from scratch with | NEW.
The Elements Create mode can be selected at this level as well. If you select
the Elements Create mode for all the levels (that are likewise represented by
the elements), it is not possible to deviate from the labeling system.
Since elements can be created in turn within the relevant elements themselves,
the labeling system can be set up to be of any desired depth. This means that
it is possible to use all the usual methods for the management of base objects.
If a structure had already been set up earlier and it is to be used now without
any changes, this can be brought over by using drag & drop.
Re step3.
Open the Properties window of the @J Project base object and switch to the
Elements tab.
Drag onto the tab the base object that forms the basis of the labeling system
and which you had created earlier in step 1.
Alternatively, create a new element with the following details:
• A name. The name of this element is displayed later within the planning
project and should therefore be meaningful. If you plan to use a company-
specific labeling system, then a possible choice would be the company name
and a sequential number.
• Any desired description.
• The creation mode Normal or Free .
If the Free mode was selected, the topmost level of the labeling system
must be a unit (or a location): In the planning project the first object in the
mouse menu of the project object must be a unit (a location). Other objects
are not offered to choose from on the project level if they had been created
as elements of @J Project .
• You can determine by means of the Virtual 1 times or N times setting how
many times the element (meaning the labeling system) may be created.

Alias for labels Designing databases (customizing)
The labeling system that is created is made available to users in the planning
project via the context-sensitive mouse menu. The labeling system that had
been created under step 3. above is offered at the project level.
49.7 Alias for labels
49.7.1 Objective
The Alias technique is used to map one labeling system to another labeling
system.
That means: A project is planned with one labeling system, and then a second
labeling system is to be used for the planning data, however without changing
the original data.
To achieve this, the object structure of the project is rebuilt in an @ALIAS
branch. The objects in this @ALIAS branch have references to the original
objects. Their only purpose is to provide an alternative labeling system.
49.7.2 Precondition
Workset.UseAliasForLabelFunctions = True
The AliasLabel script commands can only be executed if this property is
True .
See SECTION 49.7.3.4: STEP 4 and SECTION 49.7.4: EFFECT.
49.7.3 Application
49.7.3.1 Step 1
The project is planned as usual, using the desired labeling system.
49.7.3.2 Step 2
Create an @ALIAS branch in the planning view:
Units tab and/or Locations tab, project root: | NEW| NEW UNIT or
| NEW| NEW LOCATION
Name of the new object: @ALIAS (mandatory!)
Effect:

Designing databases (customizing) Alias for labels
– Units tab or Locations tab

All object with system type Device automatically get an additional
reference field. In scripts, this reference field is accessed by means of the
Alias property.
In the user interface, the reference field is labeled as follows:

– For objects that will be created in the @ALIAS branch (see Step 3):
Original
– For the originals: Alias
The reference fields are empty at first. They will be set in Step 3. (See
SECTION 49.7.3.3: STEP 3.)
– Comos Menu bar

A new icon is added, toggling on and off the Alias functionality. (See
SECTION 49.7.3.4: STEP 4.)
49.7.3.3 Step 3
Rebuild the object structure of the original data under the @ALIAS branch,
and assign references to their originals:
– For unit “W1”, for example, an alias “PA” is created by calling the
| NEW| NEW UNIT command from the mouse context menu. Then the tag from
the alternative labeling system is entered into the Label property of the alias

Alias for labels Designing databases (customizing)
object.
The following picture shows a simplified example of an original project
structure and its @ALIAS counterpart:
– Next, set a pointer at the alias object, referencing the corresponding original.
To do this, drag the original unit onto the Original reference field of the
alias unit.:
In the properties of the original, a pointer to the alias object will

automatically be assigned to the Alias reference field.
In addition, the references are shown in the Navigator (with “~” to signal the
alias relation). As long as both objects reference each other in their Alias
property, the | NAVIGATE| ALIAS and | NAVIGATE| ORIGINAL commands are
available in the mouse context menu.
The planning-relevant data (connectors, properties etc.) continue to be main-
tained at the originals. Thus, the alias objects only have a pointer and a diffe-
rent label. The exact hierarchy levels of the original data rebuilt in the
@ALIAS branch (only units/ locations or also devices) depend on the con-
crete requirements.

Designing databases (customizing) Alias for labels
49.7.3.4 Step 4
Activate the Alias functionality. This is done either
1. by Script:
Workset.UseAliasForLabelFunctions =True
2. or via the Comos user interface:
If an object named @ALIAS is located in the planning view directly
beneath the project root, the [A] icon is shown in the Comos Menu bar
(tooltip: Alias for label (Setting will not be saved) ):
The setting will not be saved. It is only valid as long as the project is open.
The default value when opening a project: False.
49.7.4 Effect
If Workset.UseAliasForLabelFunctions = True the following applies:

If one of the AliasLabel script commands defined in the Comos-DLL is
invoked for an object (“Object_A”), the Alias property of “Object_A” is eva-
luated.
If the object referenced in this property (“Object_B”) in turn has an Alias
reference to “Object_A”, the AliasLabel command is executed for
“Object_B”.
In other words: If the method is invoked at the original object, the label of the
alias object is evaluated. If the method is invoked at the alias, the label of the
original is evaluated.
If the Alias property is empty, or if “Object_B” does not reference
“Object_A”, the method is invoked for “Object_A” instead.
Tip
It might happen that you want to invoke an AliasLabel command at an ori-
ginal, but by mistake you are at the alias object already – thereby retrieving
the label of the original instead of the alias.
To avoid this, call the IsAlias() function prior to the respective AliasLabel
call. The function verifies whether an object is located in the @ALIAS
branch.

Categories Designing databases (customizing)
49.7.5 “AliasLabel” script commands
The Comos-DLL contains the following functions and properties:
IComosBaseObject
– Function AliasFullLabel
– Function AliasFullLabelWithoutFolder
– Function AliasRelativLabel
– Function AliasRelativLabelWithoutFolder
– Function AliasSignedLabel
– Function IsAlias
IComosDDevice
– Function AliasLabel
– Function AliasNestedLabel
– Function AliasNestedLabel2
– Function AliasULFullLabel
– Function OldAliasFullLabel
– Property Alias
IComosDWorkset
– Property UseAliasForLabelFunctions
A detailed description of these commands is given in the “Reference - Comos

Kernel” documentation.
49.8 Categories
Category handling: Planning objects are automatically sorted in folders after
being created.
Objects of class Unit or Location are prepared in the base data. The objects
must have the following settings:
• Sub-class Category

Designing databases (customizing) Categories
• Creation mode must be set suitably.

– Free : The category can accept all objects.
– Sub-elements : The category only accepts objects that had also been
created in the category object on the Elements tab.
If a base object is placed on the report, then the folders are searched in order
until one is found in which the planning object can be stored. For that reason
the category folders should have names that bring these folders into a mean-
ingful order.
Objects can also be sorted into categories which are parallel to the document
with the aid of the script option in report template SortNewObjectsInCate-
gories. If the document itself is under a category, sorting is also done without
the option.
49.8.2 Application example EE/I&C
In an EE sub-unit (usually a sub-cabinet) the | CATEGORY entry is selected

from the context-sensitive mouse menu. The various category folders are now
created automatically.
In the topmost category Documents an entry such as | CIRCUIT DIAGRAM is
selected from the context-sensitive mouse menu.
Base objects are dragged onto the circuit diagram. It makes no difference
whether the base objects were dragged from the Base objects tab or whether
they originated from a symbol bar.
The planning object that is now created is automatically allocated to the
appropriate category. Any existing planning objects are not moved if they
have been placed on the report.
49.8.3 Application examples P&ID
• The Allocation button in P&ID is used to transfer objects into the unit tree.
When the unit is allocated, a check is made to see whether these objects may
be pasted underneath the unit. If not, the subordinated units are searched
through until one is found, underneath which the object may be pasted.
Subordinated units are searched through recursively so as to take into
account multi-level structures (such as in the German KKS system, for
example).
• The objects are created within Comos PT Viper.

New document: report template Designing databases (customizing)
• If the attribute “RI.CATEGORY_NAME ” exists at the P&ID object, the

correct sub-unit is not determined via Create mode but instead the contents
of this attribute are interpreted as a relative unit name (with the “.” as
separator).
The system then attempts to determine a unit that is underneath the selected
unit and which complies with this naming convention.
49.9 New document: report template
49.9.1 Overview
Documents of type “report template” constitute the interface between the tem-
plate files and the reports. There are two types of report templates:
• Report template (evaluation)
• Report template (interactive) .
Document type
Both templates are based (as ultimately all documents in Comos are) on a doc-
ument type. The document types are administered through ADMINISTRATOR
| BASE DATA | DOCUMENT TYPES, see SECTION 11.3: DOCUMENT TYPES.
• Evaluation template: type ComosMasterIReport .
• Interactive template: type ComosMasterReport .
Properties of both document types:

Designing databases (customizing) New document: report template
Name ComosMasterIReport / ComosMasterReport

You can either select the name from the drop-
down list or else enter it manually. Since it is a
keyword, spelling and case-sensitivity must be
followed exactly.
Description The description specifies the text that is dis-
played in the Type selection menu of the New
object window. A blank entry is displayed if no
description is entered.
Program name ComosRprtMgr
Opens the Report Designer if the document type
document is to be edited.
File extension CRp
Files are identified on the basis of their file
extension. The default extension CRp should
not be changed.
Mode 0 - external file
The 0 option is required because the report tem-
plates are stored externally and not in the data-
base. Do not change the option.
Document base object

Generally there is also a base object Document with the following values:
Type Document
Name @O
Label Document
(Any desired description of your own can be
entered instead of “Document”.)
Description Document
(Any desired description of your own can be
entered instead of “Document”.)

New document: report template Designing databases (customizing)
As always, there can also be more specialized base objects underneath @O.
The structure of the base data entirely depends on the company-specific
requirements.
This base object does not necessarily need to exist in order to be able to create
templates. However, it is an indispensable aid if report templates are to pos-
sess specification tabs.
Managing reports
Report templates are managed in the base project on the Documents tab,
preferably in document group @REPORTS .
49.9.2 Creating a new document of type “report template”
Use the mouse menu to select the New document command. Select the entry
Report template (evaluation) or Report template (interactive) as appli-
cable from the Type pulldown list.
The dialog window changes once you have made a selection: the Report and
Revision tabs are removed and a Report template tab becomes available
instead.
Base object of the report template
When a base object of type Document is available, you can find the corre-
sponding entry in the Base object edit field. You can change the default
value by dragging another base object onto the Base object edit field by
using drag & drop. The associated specification tabs are then made available
to you as well.
Enter the desired details on the General tab and then switch to the Report
template tab.
You then require a template file for the next step. There are two possible
options:
1. You have already created a template file by using the Report Designer.
Call the template file by clicking on the button with three dots on it that
is next to the Template file dialog field. The file selection window Open
report at... then opens.
Select a template file (you can recognize it by the .CRp file extension) and
confirm by pressing Open .
2. Creating a new report template

Designing databases (customizing) Creating ready-made reports
2.1 Otherwise you should click on the [EDIT] button in the bottom left-
hand corner of the Report template tab. The Report Designer is
opened and you can create a template file within it. Once you have
created the template file, close the Report Designer and return to the
Report template tab.
2.2 The template file that you have just created can be called in the same
way as described above by pressing the [...] button.
Please note: do not confuse the template files for Evaluation Report templates
and those for Interactive Report templates! A template file for an Interactive
Report contains additional script code that could cause errors in an Evaluation
Report.
In order to help you distinguish between the two types of template files, we
recommend that you append a unique label (such as _IR) to the name of report
templates for Interactive Reports.
Object of a report template

Pull an object onto the field by using drag & drop.
49.10 Creating ready-made reports
49.10.1 Create report
Right-click on an object in the Navigator and select the | NEW

| NEW DOCUMENT command.
If documents have been preprepared at the base objects, these can be
addressed in the script with OrgDocument.
The object (the unit, the location) under which the report is created is called
the “owner”.
The default setting in the New... dialog window is Report (evaluation) . If
applicable, change the type to Report (interactive) .
Name
Think carefully before filling in the Name dialog field. If you follow certain
conventions, a report that you create automatically creates a link on the Docu-
ments tab, see SECTION 40.6: AUTOMATIC REFERENCE CREATION regarding this. You
can fill in the other dialog fields on the General tab as you wish.

Creating ready-made reports Designing databases (customizing)
Report tab
Dialog field Report template:
Select the desired report template from the tree structure and confirm with
[OK]. The window is then closed.
Report object
The “report object” is the basis from which all active and automatic functions
of a report are executed, for example, a table in which the attributes are read
and displayed. A report that does not possess an “object” cannot exist: The
specified object determines the entries of the automatic elements of a report.
There are three possible ways to specify an object:
1. Object = owner
When a new report is created, first of all the position (the unit, the
location) is entered as object. Since the position (the unit, the location)
that is created under the report is also the “owner” of the report, Report
object = Owner is shown in the dialog group.
2. Object from template
If an “object” had already been provided in the report template, the entry
Object from template can is found in the dialog group.
3. Setting objects manually
In this case, only the Object entry is included in the object group. You
must set an object manually, by:
• going to the Units or Location tab and copying a unit or location via the
mouse context menu. If you now click on the [SET] button, the data of the
copied object is inserted into the three fields.
• Alternatively you can use drag & drop to pull a unit or a location directly
onto one of these three fields.
You can delete the entries with the aid of the [DISCONNECT] button.
Interactive Reports are not primarily intended to evaluate an individual object
but instead to contain objects. Hence you can normally leave the default set-
ting Report object = Owner unchanged. If it should be necessary, the object
can be set manually in exactly the same way as in an Evaluation Report.
You can define an object manually at any time and thus replace the default
settings “Object = owner” or “Object from template”. The default appears
again if you release an object that had been set manually.

Designing databases (customizing) Creating ready-made reports
Since a distinction is made in Comos between the “owner” and the “object of
a report”, you can organize these reports entirely on the basis of your own
requirements. You can summarize reports hierarchically into groups and
nonetheless still give each report an individual point of reference.
Buttons
The four buttons have the following functions:
• [OPEN]
The report is opened and evaluated, and the results are displayed.
• [PRINT]
This button only becomes active once a report template has been set. It
evaluates the object and prints the report at the Windows default printer. The
page orientation is set automatically according to the format of the report.
• [AUTOCAD EXPORT]
Is used to export an AutoCAD file. See SECTION 35.1: EXPORT.
You can initialize the dialog window with a refresh if the buttons are not
active even though a report template and an object have been set. Do this by
selecting the | FILE | UPDATE menu.
49.10.2 Documents under the base object of the document group
Theoretically speaking, planning documents can also be created in the base

object of a Document group . Later these are offered in the | NEW mouse
menu of the document group.

Creating ready-made reports Designing databases (customizing)
However, this option should only be used with caution, since structuring the
data this way will easily be at the the expense of clarity.
The usual way is create various Document base objects and to use these as
base objects for the report templates:

Base objects of the release database @Local instance
50 Base objects of the release database

The following overview explains the systemology and the basic structures of
the release database for Comos PT. Special objects are explained in the rele-
vant section, and the corresponding cross-references make access easier. The
database can be expanded or modified at any time without prior notice.
50.1 @Local instance

This branch is only available if local instances have been created, see
SECTION 20: INSTANCES (REDUCING THE NUMBER OF OBJECTS).
50.2 @1EA standard catalog EE

See SECTION 59.1.1: DEVICES (PLANNING OBJECTS).
50.3 @1EB standard catalog ANSI

These base objects contain for the most part only those symbols that are
required for the Detail_ANS plan type.
50.4 @1EI standard catalog IE

The base objects for the Electrical Installation module. The base objects con-
tain the symbols for the RI_IT plan type and the required attributes.
50.5 @1EM standard catalog I&C

@1EM is the standard catalog for all predefined objects of the instruments and
control systems area. The structure of this standard catalog is comparable with
the structure of the @1EA catalog. Refer to that for further information.
50.6 @1FP standard catalog FD

@1FP is the standard catalog for the functions, modules and controllers of the
Function Diagrams area. Example: Function logic (AND link, OR link). The
structure of this standard catalog is comparable with the structure of the
@1EA catalog. Refer to that for further information.

@1PE standard catalog PE Data Base objects of the release database
Detailed information is given in SECTION 65.4: CONTROL SYSTEM AT THE FUNCTION

DIAGRAM.
Function diagrams require in addition signals, for which there is a branch of

their own, see SECTION 50.21: @S SIGNALS.
50.6.1 @Template
Here are the base objects with which templates are made available. This
branch thus fulfills the same task as SECTION 50.22: @ TEMPLATE.
50.7 @1PE standard catalog PE Data

@1PE is the standard catalog for all predefined objects of Process Technology
area. The structure of this standard catalog is comparable with the structure of
the @1EA catalog. Refer to that for further information.
50.8 @1RI standard catalog Plant and Piping Design

@1RI is the standard catalog for all predefined objects of the Plant and Piping
Design area. The structure of this standard catalog is comparable with the
structure of the @1EA catalog. Refer to that for further information.
50.9 @3D 3D planning
50.9.1 @A Attributes
The attributes required for 3D planning. This branch thus fulfils the same
function as SECTION 50.25: @Y ATTRIBUTES CATALOG.
50.9.2 @AXIS
Axis objects are design aids. You can then align other objects to the axis
objects.
50.9.3 1 Components
The standard catalog for base objects to be placed in 3D.

Base objects of the release database @C Costs hookup
50.9.4 2 Data catalog
These objects are not placed but contain administration information.
50.9.5 3 Pipe classes
These objects are not placed. Pipe classes control the interaction of 3D object
with respect to a pipe class.
50.9.6 4 Structural steelwork
The standard catalog for structural steelwork objects to be placed in 3D.
50.9.7 5 Assemblies
Details and templates. This branch thus fulfils a similar role as does
SECTION 50.25: @Y ATTRIBUTES CATALOG.
50.9.8 9 Other
Administration objects, primarily for control of the display in 3D models.
50.10 @C Costs hookup
50.10.1 @01 Costs hookup accessory
Makes available the attributes by which evaluations can be made within

EE/I&C concerning hookup costs.
50.11 @F Functions
The function describes the measuring or actuating task and the processing
function at a position. It corresponds to a “measuring function” in the P&ID
scheme. Synonym: Comos actuating function.
Various objects are created under this heading to covering measuring prob-
lems. The objects are created without the Request option and contain ele-
ments that were created with the Request option.
The branch contains headings in compliance with DIN 19227 and with ANS.

@G Document Groups Base objects of the release database
50.12 @G Document Groups

Detailed information is given in SECTION 40.2: PREPARING THE BASE DATA OF DOCU-
MENT GROUPS.
Logical unit within the Comos Document tab. If the unit view or location
view is linked with a document group, then documents that are created on the
basis of a specific naming scheme are automatically referenced in a document
group. The base object for document groups also controls whether all the doc-
uments of a group are to be jointly given a sequential index number.
50.13 @J Project
Detailed information is given in SECTION 5.5: THE PROJECT PROPERTIES.
This object controls how information and objects are made available to the
user on the Units , Locations and Documents tabs throughout the project.
This is done by pasting either Specifications or Elements tabs to @J.
In the example database underneath @J there are specialized objects that
serve as templates for a specific module. It is therefore recommended that you
do not use @J itself as the base object of the project, but instead an object
lying underneath it.
These elements are located on the Elements tab, which are likewise made
available when the user right-clicks on the blue globe (which symbolizes the
the project).
Thus labelling systems can also be set up within Comos in this way.
50.14 @K Routing / ducting

Detailed information is given in SECTION 59.2.2.5: SUMMARIZING CABLES IN CABLE
CHANNELS / ROUTES.
A cable route / duct is used to summarize cables between two locations into a
spatial group.
50.15 @KD Catalog data PE

Here attributes are collected that are available for C&I objects across projects.
Thus @KD fulfils a similar function to SECTION 50.25: @Y ATTRIBUTES CATALOG.
Currently the information from @KD is used for example by the pipes:

Base objects of the release database @L Locations
• The pipe dimensioning branch lying underneath it is offered on the

Technical data tab via the Pipe selection dialog field.
• The materials catalog is offered on the Technical Data tab via the Material
selection dialog field.
50.16 @L Locations
As a rule, the location or place of installation of a technical device or fitting.
Frequently the term is used more widely and is understood as a functional
allocation.
Structures for labeling systems are also created here, and are then used in
SECTION50.13: @J PROJECT (or a specialized sub-object).
Structures for category handling are also created here (automatic sorting of
planning objects).
50.17 @M Maintenance
As a rule the maintenance interval or a special note concerning the mainte-
nance of a device or unit are entered here.
This contains objects for C&I and FEED. These objects make available
attributes that are required for the input of test data.
50.18 @O Documents
A document is the interface by which the desired electronic document can be
incorporated. A document can thus be a CAD drawing, a report, a table, a text
document, etc.
Reports that are used later in the planning are for the most part controlled by
the report and not from these base objects. However, the base objects are
responsible for the text masks (and thus also for automatic referencing) and
for special attributes that are required in individual cases.
50.19 @P Position
A position designates a process control or process technology task. A position
consists as a rule of a position object (which is used as the folder), a function
and a converter, a signal and an actuator.

@Q Actions: Decision tables and queries Base objects of the release database
In the default database the functions of @F for measuring points @P have

already been pasted in the form of an element onto the Elements tab.
50.20 @Q Actions: Decision tables and queries

Example objects of the Action class are created here.
50.20.1 @Q Actions | SC Script
The script libraries are stored in this object. As opposed to all the other objects
of the @Q branch, SF functions may not be deleted, since report scripts could
refer to this object.
50.21 @S Signals
Detailed information is given in SECTION 65.3: INPUTS AND OUTPUTS (SIGNALS).
A signal designates the information unit that is processed further in function
diagrams and signal flowcharts, for example, “ON”, “OFF”. It illustrates the
input and output of the process control.
In addition, function diagrams make use of functions, modules and control-
lers, see SECTION 50.6: @1FP STANDARD CATALOG FD.
50.22 @ Template
If planning objects are used as models for additional planning objects, then
these are called templates. In Comos these planning object templates are made
available with the aid of base objects. This has the advantage that these tem-
plates can also be available in the mouse menu, for example.
The base objects provided here thus relate via a “template link” to planning
objects on the Units and Locations tabs.
50.23 @U Units
A group of functionally-linked technical devices or fittings or else the topmost
logical grouping that appears to be meaningful to the user within the technical
area. Labeling systems are often created by means of units.

Base objects of the release database @Device views
Structures for labeling systems are also created here and are then used in
SECTION 50.13: @J PROJECT (or a specialized sub-object).
Structures for category handling are also created here (automatic sorting of
planning objects).
50.24 @Device views

This is an alternative view of the data that “only” contains linked objects. This
base object class forms the device devices by area in alphabetic letter catego-
ries as per DIN and current for technicians. Under this level there is a corre-
sponding link to a device in the structure under the device base object.
50.25 @Y Attributes catalog

Here attributes that are so general they can occur with many of the objects are
collected here. If attributes are prepared here, they can be called up later in the
Properties window of an attribute on the General tab in the Catalog attri-
bute field.
There are three basic categories:
• A branch in which the tabs are collected; the tabs then contain the attributes.
(Default)
• A branch in which individual attributes are collected.
• A branch in which tabs and attributes are collected on the basis of eCl@ss
rules.
50.26 ASPEN Import attribute

This object imports simulator data from Aspen. See also SECTION 51.4.1.5.1:
“...|AXSI ASPEN XML SIMULATION IMPORT”.
50.27 eCl@ss 4.0

As a rule, there is more than one way to organize the data. This fact also
applies to the standard catalogs in electrical engineering, consequently there
is also the eCl@ss 4.0. catalog in addition to the @1EA catalog.
The @1EA catalog uses on average only six to eight attributes per (manufac-
turer) device and is oriented towards ECAD.

FT Fluid technology Base objects of the release database
The eCl@ss 4.0 catalog uses a great many attributes per device, up to a hun-
dred.
The eCl@ss 4.0 catalog is an excerpt from the eCl@ss catalog. This excerpt
is eCl@ss section 27 (process control technology).
There are no links between the @1EA and @1EC EE catalogs. We thus recom-
mend using one of the two standard catalogs as the basis for further planning
and not to mix the objects.
50.28 FT Fluid technology

Formerly @1HP standard catalog Hydraulic/Pneumatic.
@1HP is the standard catalog for all predefined objects of the Hydraulic/Pneu-
matic area. The structure of this standard catalog is comparable with the struc-
ture of the @1EA catalog. Refer to that for further information.
50.29 GF Graphic symbols

Base objects that are used several times and thus are collected here, and so are
available to all the areas.
50.30 Import
Most of the import interfaces working on an object basis are collected here.
50.30.1 @DXF
See SECTION 35: AUTOCAD (IMPORT, EXPORT DXF).
50.30.2 @EXF
See SECTION 62: EPLAN (IMPORT/EXPORT EXF).
50.30.3 @PDS
See SECTION 39: OTHER INTERFACES.

Base objects of the release database Pro II Simulation objects
50.30.4 VNS
See SECTION 39: OTHER INTERFACES.
50.31 Pro II Simulation objects

These objects import simulator data from Pro II.

Pro II Simulation objects Base objects of the release database

FEED – Interfaces to simulators Scope
51 FEED – Interfaces to simulators

Structure
This section contains the following information:
– Scope of the interface import
– Preconditions that must be met to be able to make an import into Comos
– Structure and configuration of the base data and standard tables
– Customizing of the standard import
– Sequence of the import operation from a technical point of view
(administrator’s point of view)
– Sequence of the import operation from the user’s point of view
The following sections are of interest for users whose base data has already
been preprepared by the administrator as desired and who only require a quick
introduction so as to get up to speed with operation of the interfaces:
– SECTION 51.1: SCOPE
– SECTION 51.2.1.2: INITIAL PLANNING STRUCTURE IN COMOS
– SECTION 51.6: APPLICATION / USER INTERFACE.
The remaining sections are of relevance for administrators or advanced users.
Since the technical implementation of the import and its course are similar in
all the simulator interfaces from the user’s point of view, the three interfaces
are dealt with together when possible. Any special points relating to a partic-
ular interface are referred to at the appropriate point.
51.1 Scope
Comos defines interfaces to the simulators Aspen Plus, PRO/II and HYSYS.
The interfaces import objects from the simulators into Comos without chang-
ing the source file.
The mapping of the object attributes between the simulator and Comos is
defined in the Comos DLLs (standard import) and is based on the formats
stipulated by the simulator.
However, the standard import can be extended or modified by the user
through the use of VB scripts. (See SECTION 51.5: MODIFICATION OF THE STANDARD
IMPORT.

Preconditions FEED – Interfaces to simulators
51.2 Preconditions
51.2.1 Comos
51.2.1.1 General settings and preconditions

– Comos version 8.2,
Licenses: CM, PE
– Database: StandardDB from the installation CD
– Properties of the planning project:
Tab Links :
– Project structure : @J|@PE Predefined FEED structure
– Base data : S01
Otherwise, no special settings are required.
– Base data/standard tables:
The base objects and standard tables that are relevant for the import are
introduced in SECTION 51.4: BASE DATA, ATTRIBUTES, STANDARD TABLES.
51.2.1.2 Initial planning structure in Comos

Tab Process : The import can be done in various planning structures:
• Default structure: Import into a process unit
(the basis of this documentation)
• Import into a process
Default structure
In order to start the import, the following object structure must exist already
in the planning view:
Project root
- Process
- AMA Components
- APU Process Units
- PU Process Unit
- PFD.1 PFD
- AEQ Equipment
- APS Process Streams
- AXX Miscellaneous

FEED – Interfaces to simulators Preconditions
- SIMD Simulation Data

- ...
- ...
The import starts in the SIMD Simulation Data folder, in which import
objects that control the import are created.
The import objects are nested:
• import the main case: import object of the first level (parent)
• import the subcases: import objects of the second level (children)
The run cases are nested in the form of run case objects (equipment: Equip-
ment Cases, process streams: material streams, components) underneath the
PFD objects that are created in the second import step. The objects for the
main case and the subcases are located in parallel to one another.
Object structure in the Navigator:
This planning structure is made available via the | NEW context-sensitive

mouse menu if a link to @J|@PE Predefined FEED structure was set in
the project properties on the Links tab.
The base object of the process unit is configured in the StandardDB in such a
way that the level listed above and a PFD diagram are created automatically
when creating the process unit.

Preconditions FEED – Interfaces to simulators
Alternative planning structure

It is also possible to select the following planning structure:
Project root
- Prosecc
- AMA Components
- APU Process Units
- PU Process Unit
- PFD.1 PFD
- AEQ Equipment
- AXX Miscellaneous
- SIMCASE Simulation Case 1
-
If the StandardDB is used, this structure must be set up manually.
The import starts likewise in the SIMD Simulation Data folder. However,
first of all a SIMCASE object is created in the folder for each run case that is to
be imported. An import object is then created underneath the SIMCASE object.
The import objects are thus located parallel to one another (siblings).
This documentation will not go into any further detail on the alternative plan-
ning structure.
51.2.2 Simulators
51.2.2.1 Versions
– Aspen Plus: Aspen Plus 10.x
– PRO/II: PRO/II 6.01 and higher
– HYSYS: HYSYS 3.1 or 3.2
These versions are to be installed with the relevant valid licenses, since oth-
erwise not all the data is written into the export file under certain circum-
stances and is correspondingly not imported.
51.2.2.2 Aspen Plus: options for XML nodes

In order for Comos to be able to create specific sub-objects in the course of an
Aspen import operation (for example, column trays and components), the
XML source file must possess the XML nodes listed below.

FEED – Interfaces to simulators Preconditions
These XML nodes exist automatically if particular options have been set in
Aspen Plus:
– B_TEMP:
This XML node is required to create simulation objects for trays (TRSIM)
underneath simulation objects for columns (COLSIM). It is located
underneath XML node BlockRadfrac.
Up to now we do not know of any import option that prevents the node from
being created.
– X:
This XML node is required to create components simulation objects
(MAPSIM) underneath TRSIM objects. It is located underneath XML node
BlockRadfrac.
Up to now we do not know of any import option that prevents the node from
being created.
– MOLEFRAC:
This XML node is required to create MAPSIM objects underneath material
stream simulation objects (MSSIM). It is located underneath the
StreamMaterial XML node .
If it is not available, ensure that the Fraction basis: Mole attribute has been
activated in Aspen Plus. It can be found under Setup / Report Options /
Stream :
– ComponentsMain
This XML node is required to create the CompCalc simulation object
(CCSIM), underneath which the simulation pure components are located. It
is located underneath the XML root node. If it does not exist, ensure that the

Technical sequence FEED – Interfaces to simulators
attribute list for component IDs, formulas and names has been activated.
This attribute can be found in Aspen Plus via Setup / Report Options /
Property :
51.2.2.3 Mapping of units between Aspen Plus and Comos

AAspen and Comos units must be allocated to ensure that the Aspen values
are imported correctly into Comos.
This is done via standard table @1PE|AE:
The Name column contains the Aspen Plus units as they are defined in XML
in the “unit” attributes of a node. The Value1 column contains the Name of
the allocated Comos unit, just as the name is defined in the Comos unit sys-
tem.
Additional standard tables are defined underneath this standard table, with the
aid of which a differentiation is made between Aspen Plus units that belong
to multiple unit groups (the unit groups are defined in XML via the “domain”
attribute). The name of this list corresponds to the name of the domain
attribute (for example, @1PE|AE|HEAD).
During an import, first of all the lists underneath @1PE|AE are evaluated, then
@1PE|AE.
51.3 Technical sequence

The import operation is controlled by an import object. The import settings
are made via its Properties window and the individual import steps are started.
The import operation is always done for a specific run case. In the default
planning structure an import object is created first of all for the main case
(import object of level 1, parent). Under this import object additional import
objects (level 2, children) can be created, through which the subcases are then
imported.

FEED – Interfaces to simulators Technical sequence
51.3.1 Importing the main case
51.3.1.1 Import object level 1

The import object of level 1 is created underneath the SIMD Simulation
Data folder.
Which import object is created depends on the simulator from which data is
imported. However, the user interface and configuration are almost identical
for the individual interfaces.
Creating the import object

Aspen Plus:
Via the | NEW| AXSI ASPEN XML SIMULATION IMPORT mouse menu of the
SIMD Simulation Data folder or by dragging the base object into the folder.
PRO/II / HYSYS:
The import object is created by dragging the source file (prz file or hsc file
as applicable) in the Comos Navigator onto the SIMD folder. It is recom-
mended that you create the file as a copy and not as a link.
The document that has been created in this way automatically refers to the file
to be imported.
Specifying the import source

Aspen Plus Import:
Tab “ID| Import Data ”, “ND0123| Import file ”: select the source file. It
must involve an xml file that possesses the structure described in
SECTION 51.2.2.2: ASPEN PLUS: OPTIONS FOR XML NODES.
PRO/II / HYSYS:
The source file is set automatically in the case of drag&drop.
Setting the run case

Each import operation is done for a specific run case. Only case-specific data
is imported during the import operation, with the exception of the pure com-
ponents.
Therefore, the name of the imported run case (= main case) must be entered
for the import object of level 1:
Tab “ID| Import Data ”, “ND0140| Design Case ”.
The attribute must not be left blank, since otherwise it would not be possible
to create any PFD objects in the second import step.
Default value of the main case: DESIGN

The run case is of importance in the second import step:

• So-called “Equipment Cases” are created underneath the PFD equipment,
both for the specified run case and also for the default run cases DESIGN, MIN
and MAX.
Equipment Cases are objects that store the case-specific data of the
equipment (process data).
• Material streams are created underneath the PFD process streams. The
material streams manage the case-specific data of a process stream. They
thus fulfill the same function as the Equipment Cases for the PFD
equipment. In addition, the components are located underneath them, i.e. the
case-specific substance data:
• The PFD streams and the PFD equipment that are created in the second
import step take over their case-specific information from their run case
objects (by linking of the attributes).
See the following below for more detailed information on the configuration
of case-specific base objects:
• Equipment Case:
SECTION 51.4.2.2: “@1PE|PO|EC EQUIPMENT CASE”
• Simulation material stream:

SECTION 51.4.1.3.2: “...|MSSIM MATERIAL STREAM SIMULATION OBJECT”
• PFD material stream:

SECTION 51.4.2.5: “@1PE|PO|SO|MS MATERIAL STREAM”
• Simulation components:
SECTION 51.4.1.4.3: “...|SIM|SUB|MAPSIM COMPONENT SIMULATION OBJECT”
• PFD components:
SECTION 51.4.2.3: “@1PE|PO|SO|MAP COMPONENT POINTER”

Configure tab “Import options”

Edit group “Paths ... ”:
As a rule these have already been preconfigured in the base data. They must
be set before calling the second import step.
Edit groups for object-specific and simulator-specific import options:
As a rule these have already been preconfigured in the base data. They must
be set before calling the first import step.
More detailed information on the individual attributes and their possible val-
ues can be found in the section concerning PRO/II import objects, Tab “IP
Import Options”, P. 51-49.
Detailed information
See the following below for more detailed information on the configuration
of the import base objects and their use in the planning view:
• Aspen Plus:
Configuration: SECTION 51.4.1.5.1: “...|AXSI ASPEN XML SIMULATION IMPORT”
User interface: SECTION 51.6.1: APPLICATION: ASPEN PLUS IMPORT
• PRO/II:
Configuration: SECTION 51.4.3.1.1: “...||PRZ PROII SIMULATION IMPORT”
User interface: SECTION 51.6.2: APPLICATION: PRO/II IMPORT
• HYSY:
Configuration: SECTION 51.4.3.1.2: “...|HYSYS PRO/II SIMULATION IMPORT”
User interface: SECTION 51.6.3: APPLICATION: HYSYS IMPORT
51.3.1.2 Step 1: Starting the import

When an import is made into Comos, the objects of the simulator are not con-
verted directly into the type of Comos objects with which the user carries out
further operations within Comos (so-called “PFD objects”). Instead, so-called
“simulation objects” are created first of all underneath the import object.
In this documentation, the term “simulation object” relates to these
Comos objects and not to the objects of the simulator.
The simulation objects come from the @1PE|PO|SIM branch. (More detailed
information on the structure and administration of this branch can be found in
SECTION 51.4.1: “@1PE|PO|SIM SIMULATION OBJECTS”.)

Information from the simulation run

In the first import step the following information from the simulation run is
written to the import object:
Tab “ID| Import Data ”:
• “ID.ND011| Description simulation run ”
• “ID.ND0119| Date simulation run ”
• “ID.ND0120| User information ”
• “ID.ND0121| User ID ”
• “ND0294| Aspen version ” (only available for an Aspen import)
• “ID.ND0122| Log text ”:
Entries regarding possible errors or incorrect configurations are written to
this attribute during the import operation
Assignment source objects / base objects

The following applies for each object stored in the source file:
• Comos reads from the source file the class name of the object to be
imported.
• After that, Comos searches underneath @1PE|PO|SIM for a base object for
which the following applies:
Attribute value from ID.ND0056 (Aspen Plus) or ID.ND0057 (PRO/II) or
ID.ND0790 (HYSYS) respectively matches the class name of the source
object.
(See SECTION 51.4.1.1: PROPERTIES OF THE SIMULATION OBJECTS, section Tab
“ID| Import Data”, P. 51-23 regarding the configuration of these attributes in the
base data view.)
The search is stopped as soon as Comos has found a suitable base object. A
simulation object that is based on this base object is created in the planning
view. The simulation object is given the same Name as in the simulator.
Exception:
For the pure components and components, the base object is not searched
under @1PE|PO|SIM, but instead a specific base object is always used. (See the
following section.)
Step 1: Pure components and components

Comos reads from the source file which pure components and components are
to be imported.

The pure components are created underneath the CompCalc Simulation

object. @1PE|PO|SO|MAS|MA0000 Component, the object for “blank” pure
components, is always used as the base object for the pure components. (Can-
not be customized. The pure components library must be located in branch
@1PE|PO|SO|MAS.)
The base object of the simulation pure components created this way is not
located in the simulation branch. Despite that, the simulation pure compo-
nents can be considered as simulation objects, since no actual pure compo-
nents are created.
The components are created underneath the simulation objects for material
streams. (Compare Setting the run case, P. 51-7.) The simulation object
@1PE|PO|SIM|SUB MAPSIM is always used for the components. (Cannot be
customized).
More detailed information on the pure components library can be found in
SECTION 51.4.2.4: “@1PE|PO|SO|MAS COMPONENTS”: PURE COMPONENTS LIBRARY, and
on the components simulation object in SECTION 51.4.1.4.3: “...|SIM|SUB|MAPSIM
COMPONENT SIMULATION OBJECT”.
Step 1: Extending the default

The standard import can be extended. In order to modify the first import step,
the following functions must be extended at the base objects of the desired
simulation objects on the Script tab:
• Aspen Plus import:
in UserScriptBlock1 the functions AspenImport() and
AspenImportDone()
• PRO/II import:
in UserScriptBlock2 the functions ProIIImport() and
ProIIImportDone()
• HYSYS import:
in UserScriptBlock3 the functions HYSYSImport() and
HYSYSImportDone().
More detailed information on this is given in SECTION 51.5: MODIFICATION OF THE

STANDARD IMPORT.
51.3.1.3 Step 2: Creating the Comos PFD objects

PFD objects are created for the simulation objects. These objects are used in
the actual planning work, for example, when working on the PFDs.

Objects are created for the equipment items and the process streams, and then,
underneath them, the objects that store the case-specific data.
Insertion path
The import object determines underneath which objects the PFD objects are
created:
• Tab “IP| Import data ”, attribute “ND0116| Import into process unit ”:
If this attribute is blank, the objects are sorted automatically underneath the
process unit in which the import object is located, otherwise under the
process unit referenced in ID.ND0116 .
• The exact place of creation underneath the process unit is likewise set by
means of the import object:
Tab “IP| Import options ”, attributes ND0260A to ND0260C .
(See Tab “ID| Import Data”, P. 51-32 and Tab “IP Import Options”, P. 51-33 regarding
the configuration of these attributes.)
The import objects are preconfigured in such a way within the StandardDB
that the PFD objects are sorted automatically into the folders underneath the
current process unit (process streams, equipment), and in the case of pure
components, into a folder that is parallel to the process unit.
Assignment simulation object / PFD object

Each simulation object has a PFD base object assigned to it in the base data
via the “ID.ND0060| CDevice ” attribute. The base object that is referenced
there is used to create the PFD object in the second import step.
Once the second import step has been completed, the simulation objects for
material streams and equipment are given a reference to their PFD counter-
parts: via the “ID.ND0059| PFD Object” attribute.
If an equipment simulation object possesses an assembly pointer, the PFD
equipment object is not created but instead the entire assembly is created.
Links to all the PFD objects of the assembly group are stored internally within
the system at the equipment simulation.
These references are evaluated, for example, when importing a further run
case.
Vice versa, the PFD objects are also given direct or indirect references to
“their” simulation objects:

• PFD equipment
Via the Equipment Case objects under the PFD equipment:
Tab “TD| Mechanical Data ”,
Attribute “ND0054| Equipment from simulation ”.
• Equipment Case of an PFD equipment object: Reference to the equipment
simulation object
• Equipment Case of a PFD assembly object: Reference to the PFD
equipment object. Reference to the equipment simulation object via its
Equipment Case.
• PFD material streams:
Tab “GSD| General Stream Data ”, attribute “ND0015| Stream from
simulation ”.
• PFD components:
Tab “PD| Component Data ”, attribute “ND0139| Material from
simulation ”.
You can navigate between the objects by means of the Properties window of
the objects. Example:
Process streams and material streams

In Comos the case-specific data of a process stream is managed in material
stream objects. Material streams thus fulfill the same function as do Equip-
ment Cases for the PFD equipment.
In the second import step a PFD process stream is created for each simulation
material stream. The process stream is given the same name as its simulation
material stream.

The material streams are then created underneath the process stream. The fol-
lowing material streams are created for each simulation material stream:
• The main case entered at the import object via the “ID.ND0140| Design
Case ” attribute.
DESIGN has been preconfigured as the main case in the StandardDB.
Name of the PFD material stream = Name of the main case.
• If the database has been configured correspondingly: The default run cases.
Preconfiguration in the StandardDB:
• If the main case equals DESIGN: In addition also the default material
streams MIN and MAX.
• If the main case does not equal DESIGN: In addition also the default
material streams DESIGN, MIN and MAX.
Step 2: Pure components and components

In the second import step the pure components and components from the sim-
ulation folder are converted into PFD objects. In the StandardDB the PFD
pure components are created underneath the AMA Components folder, and the
PFD components underneath their material streams.
1. Create PFD pure components
First of all, Comos verifies whether a matching pure component already exists
underneath the process.
It is checked whether in the planning view in the AMA Components folder
there is a pure component for which the following applies:
one of the values of the “ISD.ND0013| Name from simulation ” attribute
equals the Name of the simulation pure component.
The pure component already exists: No new pure component is created.
No matching pure component exists yet: Comos searches in the pure compo-
nents library for a base object for which the following applies:
one of the values of the “ISD.ND0013| Name from simulation ” attribute
equals the Name of the simulation pure component.
If the search is successful, a PFD pure component that is based on this base
object is created in the AMA Einzelstoffe folder. The PFD pure component
is given:
• the same Name as its simulation pure component
• the Description of the pure component base object

• the values of the “ISD.ND0013| Name from simulation ” attribute from

the base object. The assignment of the pure component/component is done
on the basis of these values.
If the search is fruitless, the “blank” pure component MA0000 component is
used. The PFD pure component is given the same Name as its simulation pure
component; the Name value is also assigned to the Description and the
“ISD.ND0001| Material name ” and “ISD.ND001| Name from simula-
tion ” attributes.
The pure components library is always used in the interface import. The pure
components library must be located underneath node @1PE|PO|SO|MAS.
(See ...MAS|MA[number], P. 51-42 regarding the configuration of ISD.ND0013 .)
2. Create PFD components
In order to create PFD components for the components from the simulation
folder, base object @1PE|PO|SO|MAP is always used in the interface import.
(See SECTION 51.4.2.3: “@1PE|PO|SO|MAP COMPONENT POINTER” regarding the con-
figuration.)
The PFD component is given a reference to its simulation component (see
above). The values of the “PD| Component data ” tab are taken over from
the referenced object via dynamic linking of attributes.
The Description of the PFD component and the values of the “SD| Pure
component data ” tab are only set once a pure component has been assigned
to the component. See next point.
3. Assign PFD components to PFD pure components
Comos checks whether a matching pure component is located in the AMA
Components folder in the planning view. (Basis of the assignment: see
SECTION 51.4.2.3: “@1PE|PO|SO|MAP COMPONENT POINTER”). If it does not find any
such pure component, the PFD component cannot be created.
If a matching pure component is found, the PFD component is given a link to
the pure component on the “SD| Pure component data” tab ,
“SD.ND0048| Component” attribute. The base object MAP is configured in
such a way that the values of this tab are taken over from the referenced object
(i.e. of the pure component).
In addition, the component takes over the Description of the pure component
and is given an implementation pointer to the pure component. In this way a
reference to the component (and vice versa) appears underneath the pure com-
ponent.
This simplifies the data management and gives a clearer overview of the data.

Assemblies: columns
If the simulation column possesses an assembly pointer, a check is made
within the standard import as to which of the assemblies located underneath
the specified node is suitable for this column. (If an assembly of its own was
added, the standard import must be extended in such a way that the new
assembly is included in the checking as well.)
In the case of the assemblies that had been predefined in the StandardDB, one
section (base object @1PE|EQ|08|COS|CTS) is created automatically under-
neath the column and one tray (base object @1PE|EQ|08|COS|CTS|TRA)
underneath the section.
The other trays must be created manually via the | NEW mouse menu of the
section.
All the trays must be connected with the column trays from the simulation
folder. This is done manually and via the Equipment Case objects of the trays.
Connectors of the equipment objects

The “ID.ND0065| Connectors ” list attribute is evaluated in order to cor-
rectly create and join the connectors of the PFD equipment objects in the sec-
ond import step.
This attribute controls:
• The allocation of the virtual connectors of the simulation object to the
connectors of the PFD object: via “ND0066| PFD connector ” and
“ND0067| Simulation connector ”.
It can be preconfigured in the base data view (for example, when the
assembly pointer is set).
• The assignment between the connectors of the PFD object and the
connectors of the connected process stream: via
“ND0068| Connected to ” and “ND0069| Via connector ”.
Can be modified manually before the second import step. (Switch the
connectors if the switching that had been selected automatically does not
give meaningful results.)
See Tab “ID| Import Data”, P. 51-25 for further details.

Step 2: Extending the standard import

The standard import can be extended. In order to modify the second import
step, the following functions must be extended at the desired simulation base
objects on the Script tab:
UserScriptBlock4: SimulatorImport() and SimulatorImportDone().
(See SECTION 51.5: MODIFICATION OF THE STANDARD IMPORT.)
51.3.1.4 Steps 3 and 4: Placing the objects

As a reminder: It is assumed that you will work with the prepared planning
structure. That means that there is only one PFD diagram underneath the pro-
cess unit, which was created automatically together with the process unit. The
PFD equipment that is created in step 2 is located in the AEQ Equipment
folder, and the PFD streams are in the APS Process Streams folder.
Note:
• The simulation objects are used as the starting point for the search for
objects to be placed. The objects to be placed could therefore also be located
in another node and would nonetheless still be placed automatically.
• If necessary, several diagrams can be created and the equipment – and hence
also the process streams – distributed across different diagrams.
Aspen Plus import

Only step 3 exists: [PLACE PFD STREAMS]
Via: import object: ID.BUTTON3
Places the PFD process streams of the process unit on the PFD diagram:
Comos proceeds as follows:
– Comos retrieves the value of the “ID.ND0059| PFD Object ” attribute for
each simulation material stream underneath the import object, hence the
reference to the assigned PFD process stream.
– It is verified with which equipment the PFD process stream collected this
way are connected (by evaluating their connector information).
– For each connected equipment item it is checked whether it has been placed
on a diagram. (Only the first DocObj is evaluated.)
A process stream must therefore be connected with at least one equipment
item that has been placed on a PFD diagram in order to be placed by means
of [PLACE PFD STREAMS].

– If that is the case, the process stream is given a DocObj for the same
diagram.
– However, the process stream is only displayed on the diagram and taken into
the drawing header once its “SYS.ND0154| Visible in mass balance on
PFD ” attribute has been activated.
– If the equipment with which a process stream is connected has been placed
on various diagrams, then the process stream is segmented and the segments
are placed on both diagrams. In addition, a page reference is added.
Since Aspen Plus does not write the coordinates of the equipment, the equip-
ment must have been placed manually beforehand. (See SECTION 51.6.1: APPLI-
CATION: ASPEN PLUS IMPORT, section Step 3: Placing the PFD streams, P. 51-81 for the
recommended procedure.)
PRO/II import and HYSYS import operations

Step 3: [PLACE PFD EQUIPMENT]
Via: Import object: ID.BUTTON3
Default: Automatically places the PFD equipment on the first PFD diagram
located underneath the process unit.
Alternative: In order to be able to place the equipment on a diagram other than
the first one, a link to the desired diagram must be set at the import object: in
the “ID.ND0249| Import into Document ” attribute. (For example, if you
are working with another planning structure than the one prepared in the Stan-
dardDB via the project structure.)
Comos proceeds as follows, in detail:
– The system checks whether BUTTON3 had been pressed for an import
object of the first level or for an import object of level 2. In the latter case
Comos navigates to the relevant level 1 import object.
– Comos evaluates the “ID.ND0059| PFD Object ” attribute of each
simulation object (Equipment simulation objects and Simulation Sub-
objects) underneath the import object. If the PFD equipment that is
referenced there does not yet have a DocObj, it is placed on the target
diagram.
– When placing, Comos makes use of the coordinates that were exported by
PRO/II or HYSYS respectively.

– If one of the equipment simulation objects (BLC objects) possesses a link to

an assembly, the PFD template of the assembly is pasted into the PFD
diagram, and at the coordinates specified for the equipment simulation
object. The PFD template of the assembly is deleted afterwards.
If the equipment is to be distributed over various diagrams, this must be done
manually.
In the case of a very large PFD you can, for example, first place all the equip-
ment automatically on a diagram and subsequently distribute the individual
equipment items manually on other diagrams.
Step 4: [PLACE PFD STREAMS]
Import object: ID.BUTTON4
Default: Automatically places the PFD process streams on the first PFD dia-
gram that is located under the process unit.
Alternative: Reference another target diagram at the import object via
“ID.ND0249| Import into document ”.
Comos proceeds as follows in detail:
– Comos navigates to the import object of level 1.
– Comos determines for all simulation streams underneath the import object
with which PFD equipment they are connected. (Details on this are given in
SECTION 51.4.1.3.2: “...|MSSIM MATERIAL STREAM SIMULATION OBJECT”.)
– The streams are placed on the same document as their connected equipment.
As a rule, the connected equipment is located on one diagram – namely on
the diagram on which it had been placed in step 3.
However, if parts of the equipment had been placed manually on another
diagram, it can happen that the equipment with which a stream is connected
is located on different diagrams. The stream is segmented and the segments
are placed. A page reference is added on the diagrams.
– However, the process stream is only displayed on the diagram and taken into
the mass balance once its “SYS.ND0153| Visible in mass balance on
PFD ” attribute has been activated.
– If a stream has not been connected, it is not placed.

51.3.2 Importing subcases
51.3.2.1 Import object level 2
Creating the import object

An import object of level 2 must be created for each additional run case, as a
child of the import object of the main case.
Aspen Plus import:
• Base object |@1PE|PO|SIM|XXSI|AXSI1Aspen XML simulation Import
(Case)
• In the StandardDB this object is available in the | NEW mouse menu of the
import object of level 1.
PRO/II / HYSYS:
• The same base object as for the import object of level 1.
• Simply use drag&drop to pull the new import file onto the import object of
level 1. An import object of level 2 is automatically created as a child.
Configuring the import object

In the same way as for the configuration of the import objects of level 1.
Please note:
• Tab “ID| Import Data ”:
• Enter the name of the subcase:
“ID.ND0140| Design Case ”
• Pro/II, HYSYS:
“ID.ND0116| Import into process unit ” and
“ID.ND0249| Import into document ”:
If an import is to be made into another process unit or onto another
diagram than the default diagram.
Should be identical to the configuration at the import object of level 1.
• Tab “IP| Import options ”:
• Edit group “Paths ... ”:
Should contain the same path details as for the import object of level 1.
• Object-specific import options, simulator-specific import options (the
latter only for PRO/II):
If necessary, select the desired settings that differ from the preconfigured
defaults.

51.3.2.2 Step 1: Importing the data

Import the file by pressing the [Start IMPORT] button (attribute
ID.BUTTON1 ).
• General information from the simulator is written to the import object (date
of the simulation run, etc., in the same way as for the import object of level
1) and entries for possible errors or incorrect configurations.
• Simulation objects are created underneath the run case import object.
51.3.2.3 Step 2: Creating the run case for PFD objects

Aspen Plus:
Via the [CREATE NEW CASE] button (attribute ID.BUTTON2 ).
PRO/II / HYSYS: Via the [CREATE PFD OBJECTS] button (attribute
ID.BUTTON2) or the context-sensitive mouse menu | CREATE PFD OBJECTS.
Comos checks whether the objects that are located underneath the run case
import object had already been imported for another run case. Not only the
import object of level 1 is searched when doing this, but also all the other
import objects of level 2 that are located parallel to the current import object.
The checking is based on identical names.
Equipment:
• A simulation object with the same name exists already. Thus the equipment
has already been imported. A new run case (Equipment Case) is created
underneath the PFD object that is referenced at the simulation object (same
Name is used as specified at the import object).
• A simulation object with the same name does not exist yet. The equipment
is imported for the first time.
Result: A new item of PFD equipment is created and underneath the
equipment the new run case (Equipment Case).
Material streams and components:
• A material stream simulation object with the same name exists already. The
associated PFD objects (process stream and material stream) had already
been created during the import of another run case. The “older” material
stream simulation object possesses a reference to this PFD material stream.
Result: The PFD material stream for the current run case is created in
parallel with the referenced material stream. It is given the Name of the run
case that was entered at the import object.
The PFD components are created underneath the material stream.

Base data, attributes, standard tables FEED – Interfaces to simulators
• A material stream simulation object with the same name does not exist yet.
The material stream is imported for the first time.
Result: A new PFD process stream is created. The process stream is given
the same name as the simulation object of the material stream.
The PFD material stream is then created underneath the process stream, and
under it in turn also the PFD components.
Pure components:
• The pure component already exists in the AMA Components folder
(regardless of whether it had been imported or created manually):
No new pure component is created. Nothing further is done, since pure
components do not involve case-specific information.
• The pure component does not exist in the AMA Components folder: The pure
component is created in the folder.
51.4 Base data, attributes, standard tables

The base objects that are relevant for the interfaces are located on the Base
objects tab, branch @1PE Process Engineering.
Structure of node “@1PE Process Engineering”

@1PE Process Engineering
-...|DS Data structures:
Document base objects, attributes and tabs catalog
Project defaults node for preparation of the
planning structure
-...|PO Process objects
Equipment, stream objects, run caseobjects, objects
for the interface import
-...|US Unit system
Categories for the automatic sorting of objects in the
planning structure (see SECTION 49.8: CATEGORIES for information
on the definition and administration of categories )
The following sections restrict themselves to the structure and administration
of the sub-nodes that are of immediate importance for the simulation import.

FEED – Interfaces to simulators Base data, attributes, standard tables
51.4.1 “@1PE|PO|SIM Simulation Objects”
Purpose
The base objects for the simulation objects that are created in the first import
step must be located in branch @1PE|PO|SIM. It is not permitted to change the
name of this branch.
If you wish to create your own branch of simulation objects, it must have the
name @1PE|PO|SIM. The branch supplied in the StandardDB must be
renamed.
Structure
The following structure objects are located on the first level underneath
@1PE|PO|SIM:
@1PE|PO|SIM
- @1PE|PO|SIM|BLC Equipment Simulation Objects
- @1PE|PO|SIM|STR Stream Simulation Objects
- @1PE|PO|SIM|SUB Simulation Subobjects
- @1PE|PO|SIM|XXSI Simulation Import objects
The actual simulation objects are located underneath the structure objects.
The following section introduces the properties of simulation objects in gen-
eral. The exact structure of the simulation objects and the properties of special
simulation objects or deviations from the general properties are covered in the
following sections.
51.4.1.1 Properties of the simulation objects

Since the base objects underneath @1PE|PO|SIM are simulation objects, their
names end with the syllable xxxSIM. This naming is optional and is used
solely to provide better orientation within the base data.
Tab “ID| Import Data”

The simulation objects that are located underneath the structure objects all
possess the “ID| Import data ” tab.
“ID| Import data ” provides the following attributes:
• “ND0056| Aspen name ”, “ND0057| ProII name ”, “ND0790| HYSYS
name ”:
Specifies which class from the simulator the base object is assigned to. The
simulation object/object mapping from the source file is done on the basis
of the string that is entered here (compare SECTION 51.3.1.2: STEP 1: STARTING THE
IMPORT).

The attributes can contain multiple designators, separated from one another
by commas and without blank spaces. The spelling of the designator must
be identical to that used in the simulator.
Mandatory fields. Must be set in the base data view.
• “ND0058| Relative path ”:
Specifies where the associated PFD object is to be created in the second
import step. However, it is not evaluated by the import operation. During an
import from a simulator the PFD objects are always created as specified at
the import object via the IP Import options tab, ND0260A to ND0260C
attributes. (Compare Tab “IP Import Options”, P. 51-33.)
• “ND0059| PFD object ”:
Is set automatically during the second import step. References the PFD
object that is created for this simulation object in the second import step.
You can navigate to the PFD object by means of the [NAVIGATE] icon.
• “ND0060| CDevice ”:
Determines which base object is to be used to create a PFD object for the
simulation object. You can navigate to the PFD base object by means of the
[NAVIGATE] icon.
Mandatory field. Must be set in the base data view.
Other form of use:
See SECTION 51.4.1.3.1: “...|CCSIM COMPCALC SIMULATION OBJECT”.
@1PE|PO|SIM|BLC supplements the “ID| Import data ” tab t inherited from
@1PE|PO|SIM with additional attributes (see SECTION 51.4.1.2:
“@1PE|PO|SIM|BLC EQUIPMENT SIMULATION OBJECTS”).
Tab “SYS System”

Attribute “SY0001| Object class ”
Assigned standard table: @1PE|SYS|SY0001 Object classes.
Is not evaluated during the import operation. Can be employed by the user in
scripts for internal purposes, such as when searching for all objects of a par-
ticular class, for example.
Inheritance source of the attributes

Most attributes are inherited directly from the attributes catalog
(@1PE|DS|@Y). However, tabs from the tabs catalog are also used in addition,
and in some cases the inherited tabs are extended as well.

Edit mode of the attributes

The following applies for the attributes of the ...|SIM node:
As a rule, attributes whose values are imported from the simulator possess the
edit mode “Values in XML (Limited functionality) ”.
This edit mode is not absolutely essential, but it should be selected, so that the
data can be imported more quickly (the attribute values are stored in an XML
string, the attribute is not checked in).
Caution: This mode restricts the functionality of the attribute (for example,
linking is not possible any longer).
Compare “Values in XML limited functionality)”, P. 16-7.
Scripts
Each object underneath @1PE|PO|SIM defines functions on the Script tab that
determine what is to be done with this object during the first and second
import steps.
In the StandardDB there is a command in the functions that calls the standard
import function. This call should not be deleted. However, the functions can
be extended with commands of their own and the standard import operation
is thus modified.
The invocation of the standard import may only be deleted if the standard
import function is to be disabled completely for this object and an import
operation of your own is to be defined on the Script tab by means of the
scripts.
More detailed information on modifying the standard import can be found in
SECTION 51.5.3: SIMULATION OBJECTS.
51.4.1.2 “@1PE|PO|SIM|BLC Equipment Simulation Objects”

This branch holds simulation objects that are made up of multiple PFD
objects; for example, a column, a compressor, or a heat exchanger (formerly
called “block simulation objects”).

The BLC objects extend the “ID| Import Data ” tab with additional attributes
from the attributes catalog:
Attributes that are filled with data from the simulator in the first import step:

• ND0061| X :
X-coordinate of the placement point from the flowchart of the simulator.
Remains blank in the case of an Aspen Plus import operation.
• ND0062| Y :
Analogous to ND0061 .
The following attributes are relevant for the second import step. Default val-
ues should be prepared in the base data view that can then be modified as
required in the planning view:
• ND0065| Connectors :
List that allocated the virtual connectors imported from the simulator to the
connectors of the PFD object, and also allocated the connectors of the PFD
object to those of the connected PFD process stream.
• Columns “ND0066| PFD connector ” and
“ND0067| Simulation connector” :
Allocated the connectors of the PFD object (I1, I2, ..., O1, O2, ...) to the
connectors from the simulator (F1,F2, ..., P1, P2, ...). (F = Feed, P =
Product)
Can be configured in the base data view. (In the StandardDB: Only for
columns and heat exchangers).
As a rule, is set if an assembly pointer was set. In that case it is necessary
to take into consideration that some of the connectors are no longer
available for the process streams because they have already been
connected to objects from the assembly.
Default arrangement in the planning view if nothing has been input at the
base object:
I1/F1, I2/F2, ..., O1/P1, O2/P2, ...
If the object from the simulator possesses more connectors than had been
prepared at the PFD object, dynamic connectors for the missing
connectors are created in the second import step.
• Columns “ND0068| Connected to ” and “ND0069| Via connector ”:
Determine for each connector of the PFD object with which process
stream and via which connector it is connected.
Is set automatically in the first import step. Can be modified manually
before the second import step. (Switch the connectors if the switching that
had been selected automatically does not give meaningful results.)
• “ND0254| PFD assembly ”:

Is evaluated in the second import step.

Reference to a folder from the template branch of the base project,

underneath which multiple assemblies (= copy templates) had been
prepared.
Based on the data that were imported with the simulation object, Comos
checks which of the assemblies prepared in the StandardDB in the specified
folder is the appropriate assembly, creates the objects of this assembly, and
connects them in the way that had been defined in the assembly.
If an assembly of your own was added to the preconfigured assemblies, the
second import step must be modified (via SimulatorImport() and
SimulatorImportDone()) in such a way that this assembly is also included
in the checking.
• “ND0934| Disable expansion ”:
Activated: Prevents the “ND0254| PFD Assembly ” attribute from being
evaluated. No assembly is created, but only the equipment object that is
referenced in “ND0060| CDevice ”.
Can be set in the planning view.
Other tabs
Which other tabs are available and which attributes they possess depends on
the equipment simulation object in question. (Example: tabs from COLSIM
Column Simulation Object: “PD| Process data ” and
“TPA| Pumparounds ”.)
In the planning view, the attributes of the tabs are set by the first import step.
The assignment between the source attribute and the Comos attribute is hard-
coded in the relevant import DLLs. However, this assignment can still be
modified by means of scripts. (See SECTION 51.5: MODIFICATION OF THE STANDARD
IMPORT.)
51.4.1.3 “@1PE|PO|SIM|STR Stream Simulation Objects”

Structure of this node:
@1PE|PO|SIM|STR
- @1PE|PO|SIM|STR|CCSIM CompCalc Simulation Object:
- @1PE|PO|SIM|STR|MSSIM Material Stream Simulation Object:
51.4.1.3.1 “...|CCSIM CompCalc Simulation Object”

Base object for the simulation object underneath which the pure components
are collected in the planning view in the first import step.
A special point in comparison with the other simulation objects:

• Tab “ID| Import Data ”, attribute “ND0060| Base object ”:

Value: @1PE|PO|SO|MAS|MA0000 Component
The simulation pure components are created underneath the CCSIM object
in the first import step. The base object @1PE|PO|SO|MAS|M0000
Component from the pure components library is always used as the base
object for the simulation pure components. (See “...|MAS|MA0000 Component”,
P. 51-41.)
However, the CCSIM object can also be used outside automated interface
imports. Since no PFD counterpart is required for the CompCalc simulation
object in the second import step, you should then input here which base
object is to be used for the simulation pure components.
For this reason it must be possible to edit the attribute, even if a manual
change is not considered by the interface import documented in this chapter.
• Tab “ID| Import Data ”, attribute “ND0059| PFD Object ”:
Since no PDF object is created in the second import step for the simulation
object, the attribute remains blank.
• Tab “SD| Substance data ”: This is not used any longer.
51.4.1.3.2 “...|MSSIM Material Stream Simulation Object”

Base object of the simulation objects for material streams that are created in
the first import step.
Only the case-specific data of the process streams is imported from the simu-
lator. In Comos this data is stored in material stream objects. Underneath each
material stream, in turn, the components are located that contain the compo-
nent data of the run cases.
Import of the main case:
Multiple PFD objects (the PFD process stream, PFD material streams for the
imported run case and for the default run cases) are created during the second
imporet step for each MSSIM object. More detailed information is given in
SECTION 51.3.1.3: STEP 2: CREATING THE COMOS PFD OBJECTS.
Importing a subcase:
As a rule, the new PFD material stream is created underneath the matching,
already existing process stream. More detailed information is given in
SECTION 51.3.2: IMPORTING SUBCASES.
Properties
• Name
The PFD process stream that is created in the second process step takes over
the name of the simulation stream.

Is evaluated when importing a subcase. If another material stream with the

same name had already been imported, it is not necessary to create a new
process stream in the second step.
• Tab “ID| Import data ”:
“ID.ND0059| PFD object ”:
Is evaluated when importing a subcase. If a simulation stream of the same
name exists already, the “new” material stream is created underneath the
process stream referenced at the “older” simulation stream in this attribute.
Otherwise see SECTION 51.4.1.1: PROPERTIES OF THE SIMULATION OBJECTS.
• “SYS| System ”
“SY0001| Object Class ”:
Value: Material Stream Simulation (is set in the base data).
• Tab “GSD| General stream data ”:
“ND0134| From ”, “ND0135| To ”:
Is set automatically during an import. It contains the name of the equipment
from the simulator with which the stream is connected.
Is evaluated in the fourth step during an import from PRO/II and HYSYS,
in order to find out with which PFD equipment the stream is connected.
• Remaining attributes:
The stream data. They are set during the import operation.
51.4.1.4 “@1PE|PO|SIM|SUB Simulation Subobjects”

Simulation objects that are created underneath other simulation objects. For
example, column trays, material stream components, heating curves. New
tabs are added, depending on the object.
51.4.1.4.1 “.|SIM|SUB|HCSIM Heating Curve Simulation Object”

Simulation object for heating curve data. In the second import step the PFD
heat exchanger receives references to the simulation heating curves. The data
of the heating curves is used for calculating the heat exchanger via an import
operation and afterwards is imported into Comos.
See SECTION 51.4.2.1.3: “...EQ|04|HEX HEAT EXCHANGER”.
51.4.1.4.2 “...|SIM|SUB|LHCSIM LNG Cells Simulation Object”

Cells that are created underneath the LNG block object.

51.4.1.4.3 “...|SIM|SUB|MAPSIM Component Simulation Object”

Base object for the component simulation objects that are created underneath
the simulation objects for material streams in the first import step (compare
Step 1: Pure components and components, P. 51-10). It is not possible to set another
base object through customizing.
The object possesses the following properties:
• Name :
In the planning view: The same as the name of the component from the
simulator.
The name of the simulation component is used in the second import step to
assign a pure component to the associated PFD component. See
SECTION 51.4.2.3: “@1PE|PO|SO|MAP COMPONENT POINTER”.
• Tab “ID| Import Data ”,

Attribute “ID.ND0060| CDevice ”:
• In order to convert the simulation components into PFD components, the
base object @1PE|PO|SO|MAP Component Pointer is always used during
an interface import operation.
Reason: PFD components should be created in the second import step, to
which a PFD pure component is assigned automatically. The MAP objects
are needed for this purpose.
• However, the MAPSIM object can also be used outside of the automated
interface import. In that case it is necessary to input manually which base
object is to be used in the conversion.
For that reason it must be possible to edit the attribute, even if a manual
change is not taken into consideration by the interface import operation.
• Tab “PD| Component Data ”:
• New tab (not available at @1PE|PO|SIM).
• “ND0139| Material from simulation ”: Remains blank
• The remaining attributes: These are set during the import operation in the
planning view.
• The attributes of the tab are inherited from the attributes catalog.
Simulation components of the column trays

If the import options were set correspondingly, trays are created underneath
columns in the first import step, and simulation components underneath the
trays.

These components are likewise based on the MAPSIM object. However, they
are not converted into PFD components in the second import step.
51.4.1.4.4 “...|SIM|SUB|TRSIM Column Tray Simulation Object”

Column trays are only imported if the import options were configured corre-
spondingly (see Tab “IP Import Options”, P. 51-49).
The simulation trays are created automatically with the following names:
Tray[counter].
Properties
• Tabs “GSD| General Stream Data ”, “LPH [number]| Liquid phase
[number] ”, “SPH| Solid phase ”, “VPH| Gas phase ”, “TR| Tray :”
These are set during the import operation.
The values of these tabs can also be taken over by the Equipment Case of
the PFD tray after the second import step. For this, the Equipment Case
receives a reference to this simulation tray. (See SECTION 51.4.2.2.3:
“...|EC|08|CCS|TRAEC TRAY LAYOUT (GENERAL)”.)
• Tab “SYS| System ”:

“SY0001 Object Class ”:
Value: Simulation Tray (set in the base data view).
51.4.1.5 “@1PE|PO|SIM|XXSI Simulation Import objects”

The import objects for the Aspen Plus import operation (import object level 1
for the importing of the main case, import object level 2 for the importing of
the subcases) are located underneath this node.
In contrast to the other objects that are managed underneath ...|SIM, these two
objects are created before the first import step is carried out and are not con-
verted into PFD objects.
51.4.1.5.1 “...|AXSI Aspen XML Simulation Import”

Base object for the import object of level 1.
Function:
Imports the main case. The base object defines the user interface through
which the import runs and makes the import functionality available.
Creation in the planning view:
In the SIM Simulation Data folder, context-sensitive mouse menu
| NEW| AXSI ASPEN XML SIMULATION IMPORT.

Currently it is not possible to carry out an import operation by using

drag&drop.

This tab controls the individual import steps. Its attributes come from the
attributes catalog.
Exception:
Attributes ID.BUTTON1 to ID.BUTTON3 . These attributes are created at the
AXSI import object.
The following attributes must be configured in the base data:
• “ND0140| Design case ”:
• Enter the main case.
DESIGN: Preconfigured as the main case in the StandardDB:
Where necessary, enter another value.

The main case and the default cases (DESIGN, MAX and MIN) are
created (underneath the PFD equipment: Equipment Case objects,
underneath the process streams: material streams).
• Should not be left blank in the base data.
Reason: If the attribute is blank in the planning view, no PFD objects can
be created.
• BUTTON1 to BUTTON3 :
Possess in the StandardDB an OnClick() script that initiates the relevant
import step of the standard import operation. The script should not be
deleted. (Sole exception: the standard import operation is to be replaced
completely by an import script of your own.)
If necessary, the OnClick() script can be extended by calls of your own.
Compare SECTION 51.5.2: IMPORT OBJECTS: BUTTON1 TO BUTTON4.
The following attributes are set by the user in the planning view:
• “ND0123| Import File ” (Mandatory field):
The Aspen Plus XML file must be selected here. A link to the source file is
created.
The file should have the structure described in SECTION 51.2.2.2: ASPEN PLUS:
OPTIONS FOR XML NODES.

• “ID.ND0116| Import in Process Unit ” (optional):

If the PFD objects in step 2 are cto be reated underneath a process unit other
than that of the direct owner structure. (Only necessary, as a rule, if you are
not working with the predefined planning structure that has been provided
in the StandardDB.)
The following attributes are filled in the planning view with data from the
simulation run during the first import step:
• “ID.ND0120| User information ”
• “D.ND0121| User ID ”
• “ND0294| Aspen version ”
• “ID.ND0122| Log Text ”:
Entries regarding possible errors or incorrect configurations are written here
during the import operation.
Tab “IP Import Options”

The tab is inherited from the tabs catalog: @1PE|DS|CC|CUT|CIE|ASPEN|IP
Import options.
The attributes of the tab have been preconfigured in the StandardDB with the
values given below, but these can also be set in the planning view as well.
• Edit group “Path... ”:
Specifies precisely where underneath the process unit the PFD objects that
are created in step 2 are to be located. The pathing is relative to the SIM
Simulation Data folder.
“../” corresponds to the command: one level higher in the hierarchy.

• ND0260A : determines where the pure components are to be created
Value: ../../../AMA
• ND0260B : determines where the equipment is to be created
Value: ../AEQ
• ND0260C : determines where the process streams are to be created
Value: ../APS
• Edit group: “Object specific import options ”
• ND0932 : Determines whether or not the data of the objects located
underneath the column is to be imported as well. See SECTION 51.4.3.1.1:
“...||PRZ PROII SIMULATION IMPORT”.

51.4.1.5.2 “...|AXSI1 Aspen XML Simulation Import (Case)”

Base object for the import object of level 2.
Function:
Imports a subcase.
Creation in the planning view:
Underneath anAspen Plus import object of level 1.
Properties and configuration:
By and large, in the same way as for the ...| AXSI import object.
Deviations:
• “ID.ND0140| Design Case ”: Blank in the base data view. Is set in the
planning view, at the latest before the second import step ([CREATE NEW
CASE]) is executed.
• If the objects are imported into another process unit than the one under
which the import object is located: Enter the same process unit as the one
set at the import object of level 1.
• Only two import steps: “ID.BUTTON1| Start import ” and
“ID.BUTTON2| Create new case ”.
Possess an OnClick() script that initiates the relevant import step of the
standard import in the same way as for the Aspen Plus import object of level
1 (see SECTION 51.4.1.5.1: “...|AXSI ASPEN XML SIMULATION IMPORT”).
Compare also SECTION 51.5.2: IMPORT OBJECTS: BUTTON1 TO BUTTON4.
• Tab “IP| Import options ”, edit group “Path ... ”: Should contain the same
path details as for the import object of level 1.
51.4.1.5.3 “...|SIMCASE Simulation Case”

Only of importance if the alternative planning structure is utilized.
See Alternative planning structure, P. 51-4.
51.4.2 PFD objects
Terminology
It is necessary to distinguish between PFD objects in the narrower sense and
in the broader sense.
Only the objects for the equipment and for process streams are placed on a
PFD diagram (and hence are provided with graphic information). Equipment
and process streams are PFD objects in the narrower sense.

The other base objects that are introduced in the following sections are only
to be regarded as PFD objects in the broader sense.
They are created in the second import step ([CREATE PFD OBJECTS]) and fulfill
the function of data containers. The data stored in them relates to the equip-
ment and the process streams respectively, which is why they are also created
underneath these objects (and to some extent pass data on to them). The sole
exception: pure components. They are administered separately in the planning
view, but likewise have a relation to the PFD objects through their implemen-
tation pointers to the components.
51.4.2.1 “@1PE|PO|EQ equipment”

The base objects of the PFD equipment are located in this branch. When
importing from a simulator, the PFD equipment is created in the second
import step.
51.4.2.1.1 Properties general
Symbols
A symbol for diagram type PFD must exist on the Symbols tab.
Elements
Most of the objects possess the following elements on the Elements tab:
• PFD Equipment (BLC objects): sub-objects (components, accessories)
• Equipment Case objects:
• An Equipment Case element for the main case and the subcases
(edit group Virtual : N times ).
Must exist for the simulation import.
• If default run cases are required:
One Equipment Case element each for the default run cases DESIGN, MAX
and MIN (edit group Virtual : Off or Default )
• Base objects: from the corresponding sub-node of ...|PO|EC (set up in the
same way as ...|PO|EQ)
• Equipment Rating object:
Object that stores the case-specific dimensions of the equipment. Must be
created manually.
Base object: from the corresponding sub-node of @1PE|PO|ER (set up in the
same way as ...|EQ)
Edit group Virtual : N times

Linked attributes
Tab “TD| Mechanical data ”:
Attribute “TD.ND0301| Equipment Case ”:
• Here you determine the active run case. All the Equipment Case objects that
are located underneath the equipment are offered.
The attributes of the “TD| Mechanical data ” and “PD| Process data ”
tabs are linked with the Equipment Case that is selected here, and their
values are taken over from the active Equipment Case.
• The OnChange() and FillCombolist() scripts that were prepared in the
StandardDB at the attribute must not be deleted.
• In the simulation import, the attributes of the Equipment Case are linked in
turn with those of the simulation object.
Tab “SYS| System”

Provides the attributes for the object class (SY0001) and for changing the unit
system (NSYS), for example.
The tabs are inherited from the tabs catalog.
51.4.2.1.2 “...|EQ|02|COL Column”

Base object for a PFD column.
Tab Elements :
• EQ|08|COS Column Section:
• Edit group Virtual : N times
• A structure, underneath which the various column sections are prepared.
The section must be created manually.
Note:
If the column is created via an assembly, then one section is created
automatically underneath the column, and one tray is created underneath
that section. (See also Assemblies: columns, P. 51-16.)
See also:
SECTION 51.4.2.1.7: “...|EQ|08 COMPONENTS |COS COLUMN SECTION” and
SECTION 51.4.2.1.5: “...|EQ|08 COMPONENTS|CCS|TRA TRAY LAYOUT (GENERAL)”.
• Equipment Case objects for columns.

See SECTION 51.4.2.2.2: “...|EC|02|COLEC”.

51.4.2.1.3 “...EQ|04|HEX Heat Exchanger”
Tab “PD| Process Data 1”

ND0266c , ND0266c1 , ND0266c2 :
A maximum of three simulation heating curves (cold).
ND0266h , ND0266h1 , ND0266h2 :
A maximum of three simulation heating curves (hot).
The references to the simulation objects of the heating curves are set in the
second import step. In an HTRI export, the data of the heating curves is used
in order to calculate the heat exchanger. When it is reimported into Comos,
this information is written directly into the PFD heat exchanger.
51.4.2.1.4 “...|EQ|04|LNG Heat Exchanger”

Base object for a PFD LNG heat exchanger.
Has a cell as element: Base object ... |EQ|08|CELL, edit group Virtual : N
times .
Differing from, for example, the situation for a column, PDF cells are created
automatically as well for the cells of the simulation object in the second
import step.
The connection information is administered via the cells and not via the LNG
heat exchanger.
51.4.2.1.5 “...|EQ|08 Components|CCS|TRA Tray Layout (General)”

Base object for a tray.
If a column is created via one of the assemblies predefined in the StandardDB,
a column section is created automatically underneath the column, and a tray
is created underneath that section. Additional trays must be created by using
the | NEW mouse menu.
From its active Equipment Case the PFD tray takes over the values of the fol-
lowing tabs: VPH, LPH, PD and TD.
51.4.2.1.6 “...|EQ|08 Components|CELL LNG Heat Exchanger Cell”

Base object for the cell of an LNG heat exchanger.
In contrast to, for example, column trays, PDF cells are created automatically
for the cells of the simulation object in the second import step.
The connection information is administered via the cells and not via the LNG
heat exchanger.

51.4.2.1.7 “...|EQ|08 Components |COS Column Section”

A structure, underneath which the various column sections are prepared.
...|CTS Column Tray Section
Elements of the section:
• A tray
Base object: ...|EQ|08|CCS|TRA Boden, edit group Virtual : N times
• A mapping table, by means of which the attributes of the simulation column
are taken over. (Edit group Virtual : Off )
The section possesses no run cases and no simulation counterparts.
Simulation import:
If the simulation column possesses a pointer to one of the assemblies pre-
defined in the StandardDB, the section is automatically created together with
the column via the assembly, and a tray is created underneath the section.
51.4.2.2 “@1PE|PO|EC Equipment Case”

Container that stores the case-specific data of the PFD equipment.
Structure of the branch: Analogous to @1PE|PO|EQ.
A number of attribute values are passed on from the active Equipment Case
to its PFD equipment (via linked attributes). See Linked attributes, P. 51-36.
51.4.2.2.1 Properties general

Attribute “ND0054| Equipment from simulation ”
A reference to the associated simulation object is set automatically when cre-
ating the Equipment Case during the second step of the simulation import.
(Exception: ...|TRAEC)
The properties of the simulation object are passed on to the Equipment Case
via a mapping table (tabs “TD| Mechanical Data ” and
“PD| Process data ”).
Tab “SYS| System ”:
The same function as with equipment.
Elements:
• Mapping table (edit group Virtual : Off )
• Rating Cases (edit group Virtual : N times )

51.4.2.2.2 “...|EC|02|COLEC”
Base object for the Equipment Cases of the column.
51.4.2.2.3 “...|EC|08|CCS|TRAEC Tray Layout (General)”

Base object for the Equipment Cases of trays.
Attribute “ND0054| Equipment from simulation ”:
During a simulation import the reference to the underlying simulation tray
must be set manually.
The Equipment Case takes over for the simulation trays the values of the fol-
lowing tabs: VPH , LPH , PD and TD .
51.4.2.3 “@1PE|PO|SO|MAP Component Pointer”

Base objects for PFD components. The PFD components are created in the
second import step as counterparts for the simulation components. It is not
possible to use a different base object for the PFD components in the interface
import.
The PFD components are created underneath the PFD material streams. Two
references are set when they are created for the purposes of better data man-
agement:
• To their simulation component (PD.ND0139 ), from which the values of
the “PD| Component data ” tab are inherited (see below).
• To their pure component (SD.ND0048 ), from which the values of the
“SD| Pure component data ” tab are inherited (see below).
Comos proceeds as follows to assign a pure component to the PFD compo-
nent:
Comos takes the name of the referenced simulation component and checks
whether there is already a pure component in the AMA Components folder for
which the following applies:
One of the names entered in the “ISD.ND0013| Name from simulation ”
attribute is identical to the name of the simulation component.
If no matching pure component is found, the PFD component is not created.
(See also Step 2: Pure components and components, P. 51-14.)

Properties
Name :
Automatically generated via the text mask at the base object
Description :
The same as the description of the assigned pure component.
Implementation :
The pure component that is assigned on creation. Is set automatically. It is
identical to the object that is referenced underneath SD.ND0048 .
Tab “PD| Component data ”:
• “PD.ND0139| Material from simulation ”: Link to the underlying
simulation component. Is set automatically on creation.
Note:
The MAP object can also be used outside of the simulation import. In that
case the user must be able to set the attribute manually. However, that does
not make any sense in a simulation import; you should not replace the
reference that is generated automatically.
• The remaining attributes of the tab are linked with the simulation
component that is referenced in PD.ND0139 , the values are taken over
automatically from there:
• Properties window of the attribute, Link tab:
Link type : By linked object
Specification name : PD.ND0139
Specification : Name of the attribute from which the value is taken over.
Value : Dynamic
Before version 8.2: Static (compare SECTION 51.4.2.6: “@1PE|PO|SO|PS
PROCESS STREAM”)
• Tab General :
Edit mode : normal
(It is possible to set new values manually, the linking is then broken)
Tab “SD| Pure Component data ”:
• “SD.ND0048| Component ”: Link to the assigned PFD pure component.
Is set automatically on creation.
Note:
The note for PD.ND0139 .

• The other attributes of the tab are linked with the pure component that is
referenced in SD.ND0048 , its values are taken over automatically from
there.
Configuration of the attributes:
Analogous to tab “PD| Component data ”, and in addition:
• Tab Link : Always get linked value : activated
• Tab General : Edit mode : Not editable (value set by script)
(It is possible to set new values manually)
Here are located attributes for specifying the object class (SY0001 , value:
Material Pointer) and for changing the unit system (NSYS ).
The tabs are inherited from the tabs catalog.
51.4.2.4 “@1PE|PO|SO|MAS Components”: Pure Components Library

The pure components library must be located in this node.
“...|MAS|MA0000 Component”
In the planning view this “blank” pure component is used in both the first and
the second import steps.
MA0000 is always used in the first import step, when importing a file from a
simulator to create the simulation pure components. (Compare Step 1: Pure com-
ponents and components, P. 51-10.)
The simulation pure component takes as its name the name that the pure com-
ponent had in the simulator.
MA0000 is also used in the second import step, if Comos cannot find a match-
ing pure component in the pure components library for a simulation pure com-
ponent. (Compare Step 2: Pure components and components, P. 51-14.)
The name of the simulation pure component is entered at the PFD pure com-
ponent in the following properties:
• Name
• Description
• Attributes ISD.ND0001 and ISD.ND0013 .

...MAS|MA[number]
In the planning view these pure components are used in the second import
step, when a simulation pure component is to be converted into a PFD pure
component for the first time. (An explanation is given in Step 2: Pure components
and components, P. 51-14 as to what happens if the pure component exists
already.)
Comos reads the name of the simulation pure component and checks whether
there is a pure component underneath @1PE|PO|SO|MAS for which the follow-
ing applies:
One of the names entered in “ISD.ND0013| Name from simulation ” is
identical to the name of the simulation pure component. (The attribute can
contain multiple designators, separated by commas and without blank spaces,
whose spelling is identical to that of the name in the simulators. The attribute
must already have been set in the base data.)
If such a pure component is found, it is created in the planning view in the AMA
folder underneath the process unit.
If no such pure component is found, Comos uses the “blank” MA0000
Component object. (See “...|MAS|MA0000 Component”, P. 51-41).
51.4.2.5 “@1PE|PO|SO|MS Material Stream”

The PFD counterpart to the simulation material stream.
Stores the case-specific data of its process stream. Is created automatically
during the import operation in the second step:
• Import of the main case:
The material stream for the main case is created together with its process
stream and the default run cases. More detailed information is given in
SECTION 51.3.1.3: STEP 2: CREATING THE COMOS PFD OBJECTS.
• Import of a subcase:
As a rule, only the PFD material stream for the imported subcase is created,
underneath the already existing process stream. More detailed information
is given in SECTION 51.3.2: IMPORTING SUBCASES.
Properties
Name :
The name of the run case that had been input at the import object
(ID.ND0140 )
Class : Position
Subclass : material stream

Reference to the assigned simulation material stream:

Tab “GSD| General Stream data ”, attribute “ND0015| Stream from
Simulation ”, this is set automatically during the second import step.
Here are located the attributes for specifying the object class (SY0001 , value:
Material stream, set in the base data view) and changing the unit system
(NSYS ) (set in the base data).
Linked attributes:
The values of the “GDS| General stream data ”, “LPH [number]| Liquid
phase [number] ”, “SPH| Splod phase ”, “VPH| Vapor phase ” tabs are
taken over from the assigned simulation material stream.
Link types: “Via linked object ” and “Via mapping table ”:
• “Via linked object ”
Properties window of the attributes:
• Tab Link :
Link type : Via linked object
Specification name : GSD.ND0015 (stream from simulation)
Specification : Name of the attribute of the object that is referenced in
GSD.ND0015 .
Value : Dynamic
Before version 8.2: static (Advantage: orange switching, not taken over
automatically)
The following option can be activated in the project property:
Tab Options , options group “Static link ”, checkbox “Change from
dynamic to static on first change ”:
This reactivates orange switching
• Tab General :
Edit mode : Editable - normal
(Values can be overwritten, and then the link is broken.)
• “Via mapping table ”

• Properties window of the attributes, tab Link , Link type : Via mapping
table
• Mapping tables are entered as elements on the Elements tab (base object:
@System|@O|@Mappingtable).

• The mapping tables then define which attribute of the PFD material
stream is linked with which attribute of the simulation material stream.
The process stream in turn obtains the values of its “ASD| Actual stream
data ” tab from the material stream. See SECTION 51.4.2.6: “@1PE|PO|SO|PS PROC-
ESS STREAM”.
51.4.2.6 “@1PE|PO|SO|PS Process Stream”

Base objects for PFD process streams.
These are created automatically in the second import step:
• Import of the main case:
A process stream is created for each simulation material stream underneath
the import object. The process stream is given the name of the simulation
material stream.
The PFD material stream for the main case and additional material streams
for the default run cases are created underneath the process stream. (See also
SECTION 51.3.1.3: STEP 2: CREATING THE COMOS PFD OBJECTS.)
Further information as to which run cases can be created underneath a

process stream and how the process stream needs to be configured for this
is given in: Tab “Elements”, P. 51-44.
• Importing a subcase:
A new process stream is only created if a simulation material stream with
this name is imported for the first time. (See also SECTION 51.3.2.3: STEP 2:
CREATING THE RUN CASE FOR PFD OBJECTS.)
Tab “System”
Name :
The same as the name of the simulation material stream
Class : Position
Subclass : Pipe
Tab “Elements”
The following elements must be created:
• An element for a material stream with the following properties:
• Option Virtual equals N times .
• Base object link: to |@1PE|PO|SO|MS Material Stream
This element is required to create the main case and the subcases.

• If default run cases are desired: At least one element for a default material
stream.
Three default run cases (DESIGN, MIN and MAX) have been
preconfigured in the StandardDB.
Properties:
• Option Virtual : Off
The material streams are created automatically together with the process
stream
• Base object link to |@1PE|PO|SO|MS Material Stream
• An element for segmentation of the process stream must exist:
• Name : SEG
• Class : Element
Subclass : Pipe
• Option Virtual equals N times
Tab “Connectors”
Two connectors of type P&ID must be prepared here:
• Input, Name: I1
• Output, Name O1.
Tab “ASD | Actual Stream Data”

Contains the case-specific data of the process stream. The data is taken over
from the material stream by means of attribute linking; to be more precise,
from the material stream of the run case that is currently active
(“ASD.ND0126| Active Material Stream (Case) ”).
Properties of the remaining attributes of the tab:
• Tab Link :
• Link type : via the Navigation assistant,
• Object navigation : DynLinkECEQNav
• Parameter : “ASD.ND0126, [name of the linked attribute]”]
• Value : Fully dynamic
• Tab General :
• Edit mode : Editable - normal
(The values can be set manually, and then the link is broken)

Tab “Material Stream List”

If a base object has the Class “Position”, with Subclass “Pipe”, the Material
stream list tab is automatically made available on the Configuration tab of
the base object.
The base object for process streams is configured in the StandardDB in such
a way that the tab is displayed in the planning view.
The tab is based on a query and reads important data from all the material
streams that are located underneath the process stream.
The material stream of the active case is shown bolded in the list.
Tab “RI| Presentation”

This tab controls the graphic display of the process stream on the diagram.
Most of the attributes are provided with standard tables (from the
@1PE| SYS| 1 Graphical Representation branch).
“LNTYPE | Line type ”:

Standard table: @1PE| SYS| 1| J Logocad Line types
“LYNETYPE2 | Parallel Line type ”: alternative line type
Standard table: See LINETYPE
To delete the type that was set: press the DEL key.
“BREADTH | Line width ”:
Standard table: @1PE| SYS| 1| H Line widths
“BREADTH2 | Line width ”:
Standard table: See BREADTH
“COLOR | Line color ”:
Standard table @1PE| SYS| 1| I Colors
“COLOR2 | Line color ”:
Standard table: See COLOR
“OFFSET | Clearance ”: Clearance between LYNETYPE2 and LYNE-
TYPE ; Default: in mm
Edit field, type: numeric
Inherited from the tabs catalog.
“SY0001 | Object class ”:
Value: Process stream

“ND0154 | Visible in mass balance on PFD ”:

Must be activated so that a process stream is placed on the PFD and incorpo-
rated into the mass balance in step 4 [PLACE PFD STREAMS] (Aspen Plus: step
3).
See also SECTION 51.3.1.4: STEPS 3 AND 4: PLACING THE OBJECTS.
Tabs “RP| Routing Parameters” and “TD| Mechanical Data”
These tabs are of importance when working in 3D space or for cost estima-
tion.
These are inherited from the tabs catalog.
51.4.3 “@1PE|DS Data Structures”
The following sub-nodes are of importance for the import interface.
51.4.3.1 „@1PE|DS|@O Documents“
51.4.3.1.1 “...||PRZ ProII Simulation Import”

Class : Document
Base object for the import object of levels 1 and 2 of the PRO/II interface.
This base object defines the user interface that controls the import operation
and makes the import functionality available.
The document with which the import operation is executed in the planning
view must be of document type ProII . Then it automatically possesses a link
to this base object and thus to the required import functionality.
The document must be created underneath the SIM Simulation Data folder,
either by using the |NEW context-sensitive mouse menu of the folder or by
means of drag&drop:
• | NEW mouse menu:
The user must select the source file on the ProII tab.
• Drag&drop:
Move the source file from a Windows Explorer window into the SIM folder
by using drag&drop:
File format: prz

Precondition:
In the StandardDB a base object has been prepared underneath the
@System|@D|@DocumentTypeMapping node whose name is the same as the
file ending of the PRO/II simulator (hence PRZ) and which possesses a base
object link to @1PE|DS|@O|PRZ.
Effect:
The document is created automatically; the link to the source file is set
automatically (the user can decide whether to use a copy or whether a link
is to be set up).
The source file is referenced automatically on the PROII tab

This tab controls the individual import steps.
It functions in the same way as the tab of the Aspen Plus import object (see
SECTION 51.4.1.5.1: “...|AXSI ASPEN XML SIMULATION IMPORT”).
The tab differs in the following ways from the Aspen Plus import object:
• There is no attribute for the import file (it is referenced on the ProII tab)
• ID.BUTTON1 and ID.BUTTON2 :
As for the Aspen Plus import object, but with its own OnClick()script.
• ID.BUTTON3 : Place PFD Equipment
(This step does not exist in the Aspen Plus import operation.)
• ID.BUTTON4 : Place PFD Streams
As for the Aspen Plus import object, but with its own OnClick() script.
• The names of buttons BUTTON1 to BUTTON4 may not be changed, since
the OnMenuCreate()script of the import object uses these names.
• “ND0140| Design Case ”:
Unlike with the Aspen Plus import, in a PRO/II import there is no base
object for the subcases. Instead, the PRO/II import objects are nested.
• Import object of level 1 (main case):
Enter the main case.
The main case and the default cases (in the StandardDB: DESIGN, MAX
and MIN) are created (underneath the PFD equipment: Equipment Case
objects, underneath the process streams: material streams).
• Import object of level 2 (subcase)
A subcase is created.
• DESIGN is preconfigured as the main case in the StandardDB.

• This attribute should not be left blank, since otherwise the PFD objects
cannot be created.
• No attribute for the number of the PRO/II version that is used.
In contrast to the Aspen Plus import object, the the PRO/II import object has
the following attribute:
• “ID.ND0249| Import into document ”:
If the PFD objects are to be placed on another PFD in steps 3 and 4 than on
the PFD that had automatically been created underneath the process unit.
Can be set by the user in the planning view (optional)
Tab “IP Import Options”

The tab is inherited from the tabs catalog: @1PE|DS|CC|CUT|CIE|PRZ|IP
Import options.
The attributes of the tab are preconfigured in the StandardDB with the values
given below, but they can also be set in the planning view.
• Edit group “Paths ... ”:
Specifies underneath which objects the PFD objects that had been created in
step 2 are to be located.
More detailed information is given in SECTION 51.4.1.5.1: “...|AXSI ASPEN XML
SIMULATION IMPORT”.
• Edit group: “Object specific import options ”

• “ND0932| Column trays/stages ”:
Specifies whether or not the data of the objects located underneath the
column is to be imported as well.
not imported : Only the data of the column itself is to be imported; the
data of the associated trays and components is not imported.
trays/stages without composition : The data of the column and trays is
imported. The data of the components is not imported.
trays/stages & composition : The data of the columns, the trays and the
components is imported.
(Default)
• “ND0931 Stream tray/stage compositions ”:
Specifies which attributes on the “PD| Component data ” tab are to be
imported for the simulation components.
Does not exist: Comos calculates the values.
only bulk mole fractions :
Edit group Total : “CD0121| Molar fraction ” imported.

mole fractions of all phases :

Edit group Total : “CD0121| Molar fraction ”,
Edit group Vapour phase : CD0121v ,
Edit group Bulk liquid phase : CD121I1 ,
Edit group Liquid phase 2 : CD121I2 imported
bulk fractions and flows :
The entire edit group Total is imported (CD0061 , CD0062 , CD0120 ,
CD0121)
• Edit group “Pro/II import options” :
• “ND0933| Calculate Stream properties ”:
Activated (default, recommended)
The simulator is activated once again and the stream properties are
recalculated. Any stream properties that are missing in the source file are
calculated and likewise imported.

Attribute “SY0001| Object class ”
Stored in standard table @1PE|SYS|SY0001 Object Classes.
This attribute is not evaluated during the import operation. It can be employed
by the user in scripts for internal purpose, for example when making a search
for all objects of a particular class
51.4.3.1.2 “...|HYSYS PRO/II Simulation Import”

Class : Document
Base object for the import object of levels 1 and 2 of the HYSYS interface.
This base object defines the user interface through which the import operation
is controlled and makes the import functionality available.
The document via which the import operation is executed in the planning
view possesses document type General document and must have a link to
this base object on the General document tab.
The document must be created underneath the SIM Simulation Data folder:
simply move the source file from a Windows Explorer window into the SIM
folder by using drag&drop. File format: hsc.
Precondition: In the StandardDB a base object has been predefined under-
neath the @System|@D|@DocumentTypeMapping node whose name is identi-
cal to the file extension of the HYSYS simulator (hence HSC) and which
possesses a base object link to @1PE|DS|@O|HYSYS.

Effect: The document is created automatically on using drag&drop, and the

link to the source file is set automatically (the user can decide whether to use
a copy or whether a link is to be set up).
Alternatively, the import object can also be created by using the | NEW mouse
menu of the SIMD folder.

This tab controls the individual import steps. It functions in the same way as
the tab of the PRO/II import object. (Compare the section on the PRO/II
import object, section Tab “ID| Import Data”, P. 51-48).
The tab differs in the following points from the PRO/II import object:
• ID.BUTTON1 and ID.BUTTON4 :
Own OnClick() script.
Tab “IP| Import Options”

The tab is inherited from the tabs catalog: @1PE|DS|CC|CUT|CIE|PRZ|IP
Import options.
The tab functions in the same way as the tab of the PRO/II import object, but
it has fewer attributes.
Compare the section on the PRO/II import object, see section Tab “IP Import
Options”, P. 51-49.

In the same way as for the PRO/II import object.
51.4.3.2 “@1PE|DS|@Y CA Attributes Catalog”

Attributes catalog for process technology. Most of the attributes of the simu-
lation and PFD objects originate from this node.
51.4.3.3 “@1PE|DS|CC Tab Catalog”

This branch defines tabs that are then used and extended in the objects that are
involved in an import operation.

Modification of the standard import FEED – Interfaces to simulators
51.4.4 Standard tables
@1PE Process Engineering:

The standard tables that are relevant for import operations are located in this
branch. The tables that have been predefined in the StandardDB may not be
deleted but can be extended if desired.
The following standard tables are of special importance for simulation import
operations:
@1PE|AE Aspen Units

Assigns Aspen Plus measurement units to Comos measurement units.
Compare Mapping of units between Aspen Plus and Comos, P. 51-6.
@1PE|AE|DELTA-T Aspen units for domain DELTA-T

An Aspen Plus unit can belong to multiple unit groups. (Unit groups are
defined in XML via the “domain” attribute.) This table lists the Aspen Plus
units that belong to the DELTA-T unit group.
@1PE|AE|HEAD Aspen units for domain head

Analogous.
51.5 Modification of the standard import
51.5.1 Overview
Functions controlling the exact sequence of the import operation are defined
on the Script tabs of the following objects: The base objects of the import
objects, the base objects of the simulation objects and the buttons that start the
import steps.
In the StandardDB these functions only call the standard import operation.
However, the standard import can be modified by extending the functions via
script. That way, one can, for example, import attributes that are not consid-
ered by the standard import, or change the way the attributes are mapped in
comparison to the standard import.
In the script, the usual Comos script functionalities are available to the full
extent (for example, retrieving attribute values).

FEED – Interfaces to simulators Modification of the standard import
SECTION 51.5.2: IMPORT OBJECTS: BUTTON1 TO BUTTON4 and SECTION 51.5.3: SIMULA-
TION OBJECTS give an overview of which functions have been defined at which
objects, which functions are involved, and what the call of the standard import
looks like.
The remaining sections describe how to extend the standard import operation.
51.5.2 Import objects: BUTTON1 to BUTTON4
On the ID Import Data tab, the import objects have four buttons (Aspen
Plus: 3 buttons) that start the individual import steps.
Each of these buttons has an OnClick() script that controls the import step in
question.
The following commands within the OnClick() script start the standard
import:
• PRO/II and HYSYS:
• ID.BUTTON1:
Workset.lib.pe.Simulation.StartImport ThisObject
Starts the first import step.
StartImport() creates an instance of ProIICOMImport, calls its
Import() operation and passes the CDevice of the import object as
parameter. See Note, P. 51-65.
• ID.BUTTON2:
Workset.lib.pe.Simulation.CreatePFDObjects ThisObject
Starts the second import step.
• ID.BUTTON3:
Workset.lib.pe.Simulation.PlaceObjectsOnPFD1 owner.owner,
Nothing
Starts the third import step.
• ID.BUTTON4:
Workset.lib.pe.Simulation.PlaceStreamOnPFD1 owner.owner
Starts the fourth import step.
• Aspen Plus: Import object level 1 (...| AXSI)
• ID.BUTTON1:
If GetSpecOwner.SystemTypeName = "Device" Then
File = owner.Specifications.Item("ND0123").value
If File<>"" Then
If right(File,3) = "xml" Then

Set SI = createObject("ComosAspenXMLImp.AspenXMLI
mp")
SI.Import GetSpecOwner
End If
End If
End If
Creates an instance of AspenXMLImp, calls its Import() function, and
thus starts the first import step. (Compare Note, P. 51-58.) The import object
is passed as parameter.
• ID.BUTTON2:
The same as for PRO/II / HYSYS.
• ID.BUTTON3:
owner.Workset.lib.pe.PlaceStreamOnPFD owner.owner
Starts the third import step.
• Aspen Plus: import object level 2 (...| AXSI1)
• ID.BUTTON1:
Set PEMod = CreateObject("ComosPEModul.PEModul")
PEMod.CreatePFDCase owner.owner
Starts the first import step.
• ID.BUTTON2:
Set PEMod = CreateObject("ComosPEModul.PEModul")
PEMod.CreatePFDCase owner.owner
Starts the second import step.
If necessary, the scripts can be modified by means of additional commands.
However, they should not be deleted unless the standard import function is to
be replaced completely by an import function of your own.
However, the actual modification of the standard import function takes place
in the user script blocks of the simulation objects.
51.5.3 Simulation objects
51.5.3.1 Overview
Each object underneath @1PE|PO|SIM defines multiple functions on the
Script tab. These functions control what happens to this object during the first
two import steps.

The start of the function body calls the standard import function for the object.
The standard import function can be extended in the subsequent lines (see
SECTION 51.5.4: ASPEN PLUS: CLASS ASPENNODE, SECTION 51.5.5: PRO/II: CLASS PROIIN-
ODE and SECTION 51.5.6: HYSYS: CLASS HYSYSNODE).
This allows you, for example, to change the attribute mapping so that it differs
from the one in the standard import, or to import new attributes.
The call for the standard import operation should not be deleted.
Exception: The standard import operation should not be executed at all for
this object but is replaced completely by a script that is defined in the function.
This involves the following functions:
• [SimulatorName]Import(Node As Object):
This function is called for each simulation object shortly before the end of
the first import step. See SECTION 51.5.3.2: IMPORT().
A reference to the node object of the simulation object is passed as
parameter.
In this function you can add scipt that imports attributes that are not
considered by the standard import. These attributes must be available at the
simulation object and its corresponding PFD object. If that is not the case,
they must be created in the base data beforehand.
If you want to modify the attribute mapping defined in the standard import,
you should first add a script that undoes the value assignment carried out in
the standard import dll, before reassigning the attributes as required.
In both cases the following applies: In order to pass the modification of the
standard import on to the PFD objects, the attribute linking between
simulation object and PFD object must be adjusted accordingly (link type:
linked object or mapping table). If new attributes were added, you may also
need to modify the report templates of evaluation reports that should work
with these attributes.
• [SimulatorName]ImportDone(Node As Object):
This function is called once the Import() function has been executed for all
the simulation objects. It is responsible for post-calculations.
A reference to the node object of the simulation object is passed as
parameter.
Example: Conversion of the molar density in mass density.
See SECTION 51.5.3.3: IMPORTDONE().
• SimulatorImport(DevSimObj As IcomosDDevice):

This function is called for each simulation object in the second import step.
A reference to the import object is passed as parameter.
See SECTION 51.5.3.4: SIMULATORIMPORT().
• SimulatorImportDone(DevSimObj As IcomosDDevice):
This function is called once the SimulatorImport() function has been
executed for all the simulation objects. It is responsible for post-
calculations.
A reference to the import object is passed as the parameter.
See SECTION 51.5.3.5: SIMULATORIMPORTDONE().
51.5.3.2 Import()
• Aspen Plus:
UserScriptBlock1: Function AspenImport(Node)
Invoking the standard import:

Workset.lib.pe.AspenSimulation.import node
• PRO/II:
UserScriptBlock2: Function ProIIImport(Node)

If ThisObj.SystemType = 13 Then
Workset.lib.pe.Pro2Simulation.import ProIINode, Name
Else
Workset.lib.pe.Pro2Simulation.import ProIINode,
CDevice.Name
End If
• HYSYS:
UserScriptBlock3: HYSYSImport(Node)

Workset.lib.pe.HysysSimulation.Import node, Name
Else
Workset.lib.pe.HysysSimulation.Import node, CDevice.Name
End If
51.5.3.3 ImportDone()
• Aspen Plus:
UserScriptBlock1: Function AspenImportDone(Node)


Workset.lib.pe.AspenSimulation.ImportDone node
• PRO/II:
UserScriptBlock2: Function ProIIImportDone(Node)

Workset.lib.pe.Pro2Simulation.importdone ProIINode
• HYSYS:
UserScriptBlock3: Function HYSYSImportDone(Node)

Workset.lib.pe.HysysSimulation.ImportDone node, Name
Else
Workset.lib.pe.HysysSimulation.ImportDone node,
CDevice.Name
End If
51.5.3.4 SimulatorImport()
All interfaces:
UserScriptBlock4: Function SimulatorImport (devSimObj)

Set SimulatorImport =
Workset.lib.pe.simulator.Import(devSimObj)
51.5.3.5 SimulatorImportDone()
All interfaces:
UserScriptBlock4: Function SimulatorImportDone (devSimObj)
Standard import:
Set SimulatorImportdone =
Workset.lib.pe.simulator.importdone(devPFDObj,devSimObj)
51.5.4 Aspen Plus: Class AspenNode
The first two import steps can be modified via class AspenNode from the
ComosAspenXMLImp.dll.
Background:

An instance of AspenNode is created for each simulation object during the

import operation. This instance is a temporary object that serves as a link
between Comos (the target object, = the simulation object) and Aspen Plus
(the source object, = the XML node) and is only available during the import
operation.
In addition, the import functions that had been defined on the Script tab are
called for each simulation object during the standard import operation (see
SECTION 51.5.3.1: OVERVIEW). In these calls the AspenNode instance created for
the simulation object is passed as parameter.
The import calls can be extended via the functions and variables of the
AspenNode instance, thus modifying the standard import function for the first
two import steps.
The following section only covers the new import control of AspenNode.
Note
In the AspenXMLImp.dll there is also a second class: class AspenXMLImp.
This class is instantiated in the OnClick() script of the ID.BUTTON1 button of
the Aspen Plus import object (compare SECTION 51.5.2: IMPORT OBJECTS:
BUTTON1 TO BUTTON4). Next, the following function of the AspenXMLImp
instance is called in the script:
Function: Sub Import(ByVal devSimulator As IComosDDevice):
This function starts the import operation. A reference to the Aspen Plus
import object is passed as the parameter (hence an instance of CDevice
@1PE|PO|SIM|XXSI|AXSI or @1PE|PO|SIM|XXSI|AXSI1).
Result of the call: The simulation objects are created underneath

devSimulator and an instance of AspenNode is generated for each simulation
object.
51.5.4.1 Properties
ComosDevice
Public ComosDevice As IcomosDDevice
Pointer to the simulation object whose script is executed at thr moment. (On
the Script tab this is identical to the ThisObj command.)
Example:
Node.ComosDevice.spec("PD.CD0055").Value

Reads the value of attribute PD.CD0055 of the current simulation object.
AspenXMLNode
Public AspenXMLNode As MSXML.IXMLDOMNode
Pointer to the current XML source node. The declaration as

MSXML.IXMLDOMNode points to the standard Microsoft XML library.
Through this you have access to numerous XML default properties, such as,
for example:
• AspenXMLNode.SelectSingleNode(ByVal nodename as String)
Selects a particular node via the name and returns the node.
Example:
Can be used to check whether or not a particular node exists.
If Not Node.AspenXMLNode.SelectSingleNode("TSINP_SSTG") Is
Nothing
Then
…
End If
• AspenXMLNode.NodeName As String
Returns the name of the current XML node as a string.
Example:
Can be used to execute code only for a particular node.
If Node.AspenXMLNode.NodeName = "BlockRadfrac" Then
…
End If
IsLogActive
Public Property IsLogActive() As Boolean
Allows you to turn the log texts on and off. This way, the administrator can
determine which error or warning messages are to be included in the log text.
Example:
Activate the log text while a sub-object is being created. If the required XML
sub-node does not exist, an error message is written to the log text.
Node.IsLogActive = True
Node.CreateSubObjects "B_TEMP", "Stage", "Tray"
Node.IsLogActive = False

51.5.4.2 Read()
Public Function Read(ByVal strAspenXMLAttribute As String,
ByVal strComosSpecName As String)
As Boolean
Reads a single value from an XML node and writes it to a Comos attribute.
XML values defined by “*” (no value or default value) are skipped during the
import operation.
Parameter “strComosSpecName”
Type: String
Name of the target attribute.
Parameter „strAspenXMLAttribute“
Type: String
A combination of:
Name of the XML node + a more precise definition of the source value.
The definition of the source value can be made up from several blocks:
• “domain”:
Defines the unit group
If the source value involves a numeric value with a unit, a “domain”
attribute must exist at the XML node. The attribute must be part of the more
detailed definition of the source value.
Exception:
Multiple unit groups exist in one node. In that case “domain” has the value
“MultiDomain” and is not specified in the definition of the source value.
• Dimension:
An XML node can have a one dimensional or a multi-dimensional data
field. The individual dimensions are defined via sub-nodes. Each dimension
possesses a collection of “items”.
If one item was determined for each dimension, the associated value can be
determined from the “Value” sub-node.
This results in the following notation for strAspenXMLAttribute:
[XMLNodeName](domain:[value], [NameDimension_1]:[value from
“items”],[NameDimension_2]:[value from “items”], ...)

The precise definition of the source value is optional and depends on the struc-
ture of the XML node. The round brackets are mandatory. They are also
required if the definition of the source value is dispensed with. The text in
square brackets must be replaced by the specific values.
If one dimension is unspecified, Comos cannot determine which value is to be
selected. A log entry is made.
A number of examples are given below. The target attribute is PD.CD4711 in
all the examples.
No definition of the source value is required
• Name of the XML node: MW_LIQ

• The node does not have a “unit” attribute, and hence no “domain” attribute.
• In addition, the node does not have a data field but instead only a single
value. Thus there are also no dimensions.
The definition of the source value is thus dispensed with entirely.
Function call:
Node.Read "MW_LIQ()", "PD.CD4711"
Definition of the source value for a one-dimensional data field
• Name of the XML node: TEMP_OUT

• Attribute “domain”: exists
Value: TEMPERATURE
• Dimensions: one dimension
SUBSTREAM: value from “items”: MIXED

Function call:
Node.Read "TEMP_OUT(domain:TEMPERATURE, SUBSTREAM:MIXED)",
"PD.CD4711"
Definition of the source value for a multi-dimensional data field
• Name of the XML node: HMX

Value: MultiDomain -> multi-dimensional data field
• Dimensions: two dimensions
SUBSTREAM: Value from “items”: MIXED
Domain: Value from “items”: MASS-ENTHALP
Function call:
Node.Read "HMX(SUBSTREAM:MIXED, Domain:MASS-ENTHALP)",
"PD.CD4711"
51.5.4.3 ReadArray()
Public Function ReadArray
(ByVal strAspenXMLAttribute As String,
ByVal strComosSpecName As String)
As Boolean
Reads from an XML node a one dimensional data field and writes it to the
XValues of a Comos list attribute. XML values defined by “*” (no value or
default value) are skipped during the import operation.

Parameter strComosSpecName
Type: String
Name of the Comos list attribute.
Parameter strAspenXMLAttribute
Type: String
Analogous to the strAspenXMLAttribute parameter of Read(). The sole dif-
ference:
One dimension remains undetermined. It does not matter which dimension
that is.
If two or more dimensions are not specified, the function call is under-deter-
mined. If all the dimensions have been determined, then Read() would be the
correct function call.
Examples
• Name of the XML node: HT_FROM_TOP2

Value: LENGTH
• Dimensions: two dimensions
NPOINTS and Stage
• Case 1: NPOINTS undetermined
• Function call:
Node.ReadArray "HT_FROM_TOP2(domain:LENGTH, Stage:3)",
"PD.CD4711"
• Result: Two values are written into the XValues of list attribute
PD.CD4711, and in our example they are the values from stage 3.

• Case 2: Stage undetermined

• Function call:
Node.ReadArray "HT_FROM_TOP2(domain:LENGTH, NPOINTS:2)",
"PD.CD4711"
• Result: Eighteen values are written into the XValues, and in our example
they are the values from NPOINTS 2.
51.5.4.4 CreateSubObjects()
Public Function CreateSubObjects
(ByVal AspenXMLNodeName As String,
ByVal AspenXMLSubNodeName As String,
ByVal NamePrefix As String)
As Boolean
This function creates a new simulation object underneath the current Comos
Device, provided that the simulation object that is to be created does not exist
already (checking is based on identical names):
AspenXMLNodeName:
Name of the XML sub-node underneath which you can find the names of the
new objects.
AspenXMLSubNodeName:
Name of the sub-node of the second order (child of the sub-node that had been
defined via AspenXMLNodeName). This name determines which CDevice is
used for the creation (“XYZ”). The values of this node determine how many
objects are created and what names they have.
NamePrefix:
Any desired combination of alphabetical letters that is prefixed to the object
name.
Example:
Node.CreateSubObjects "X", "COMPONENTS", "C_"
51.5.4.5 XMLValueExists()
Public Function XMLValueExists(ByVal XMLInfoStr As String) As
Boolean
Checks whether a particular XML attribute has a particular value.

XMLInfoStr:
Name of the XML attribute and the value that is being checked, as a string.

The following notation is used:

“Name_XMLNode(AttributeName:AttributeValue)”
Example:
Can be used to only execute commands if a particular value is present.
bValueExists = Node.XMLValueExists("DUTY_OUT2(HCURV_NO:2)")
51.5.5 PRO/II: Class ProIINode
The first two import steps can be modified via the ProIINode class from the
Pro2Lib601.dll.
Background:
An instance of ProIINode is created for each simulation object during the
import operation. As is the case with AspenNode, this instance is a temporary
object that serves as a link between Comos (the target object) and PRO/II (the
source object) and that is only available during the import operation.
In the same way as for the Aspen Plus import operation: The import functions
that had been defined on the Script tab (see SECTION 51.5.3.1: OVERVIEW) for each
simulation object are called in the first two import steps and the ProIINode
instance that had been created for this simulation object is passed as parame-
ter.
The import calls can be extended by means of the functions and variables of
the ProIINode instance, thus modifiying the standard import function of the
first two import steps.
The functions and variables of the ProIINode class are introduced in the fol-
lowing sections.
Note
In the Pro2Lib601.dll there is also a second class: The ProIIComImport
class.
This class is instantiated in the OnClick() script of the ID.BUTTON1 button of
the ProII import object (compare SECTION 51.5.2: IMPORT OBJECTS: BUTTON1 TO
BUTTON4). Next, the following function of the ProIICOMImport instance is
called in the script:
Function: Sub Import(ByVal ObjSimulator As IComosBaseObject):
This function starts the import operation. A reference to the PRO/II import
object is passed as parameter (cast to its IComosBaseObject base type).

Result of the call: The simulation objects are created underneath

ObjSimulator and an instance of ProIINode is created for each simulation
object.
51.5.5.1 Properties
ComosDevice
ComosDevice As IComosDDevice
The target object (simulation object).
Pro2Objects
Pro2Objects As Dictionary
The source objects. This involves a collection of PRO/II objects that each rep-
resent an interface of an overall object.
Thus, multiple PRO/II objects are converted into just one Comos object.
Pro2File
Pro2File As Object
Pointer to the PRO/II file object from which the data is to be imported.
(Not: The file written from PRO/II and made available in Comos as a copy via
link!)
For example, if you need more data for the current object than is read by the
standard import function.
Pro2Server
Pro2Server as Object
Pointer to the PRO/II File Server. This allows queries to the file to be
imported.
CompCalcDev
CompCalcDev As IComosDDevice
Pointer to the CompCalc simulation object, underneath which the pure com-
ponents were collected.

isStream As Boolean
Returns TRUE if the current has the PRO/II class “Stream” or is a temporary
stream.
MaterialCDev As IComosDCDevice
MaterialCDevice As IComosDCDevice
Pointer to the base object that is used for all the components:
@1PE|PO|SIM|Sub|MAPSIM Component Simulation Objects
(It must not have any other value.)
Pro2Components As Collection
Reference to a collection of ComosDDevices that is located underneath the
CompCalc simulation object.
51.5.5.2 Read()
Function Read
(ProIIClassName As String,
ProIIAttributeName As String,
ComosSpecName As String,
[index As Integer = -999])
As Boolean
Reads a single value from PRO/II and writes it to an attribute of the Comos
object that is managed by the ProIINode instance.
Parameter:
• ProIIClassName:
Determines from which of the objects that are referenced in Pro2Objects a
value is to be read.
• ProIIAttributeName:
Identifies the source attribute from which the value is read.
• ComosSpecName:
Identifies the target attribute of the object that is refernced in ComosDevice .
Notation: “NameOfTab.NameOfAttribute”
• Since some values in PRO/II do not have a measurement unit, the
measurement unit of the starting value can be passed in the function call.
This is done by appending the string “/NameComosMeasurementUnit” onto
ComosSpecName, whereby the name of the Comos unit of measure is passed
exactly as it had been defined in the Comos unit system.

Example:
Unit group Molar Volume: Name “M62”
Unit: Cubic meter/Kilomol, Name: “M62.25”
Parameter ComosSpecName: “SPH.CD0199/M62.25”
• index:
Optional. Makes it possible to read a value from an array.
Example
Node.Read "SrBulkProp", "SolidCritVolume", "SPH.CD0199/M62.25"
51.5.5.3 ReadArray()
Function ReadArray(ProIIClassName As String,
ProIIArrSizeAttributeName As String,
ComosSpecName As String)
As Boolean
Reads a one dimensional field from PRO/II and writes it into a list attribute in
Comos.
Parameters:
• ProIIClassName:
Identifies the object from whose source data field values are read.
• ProIIArrSizeAttributeName:
Specifies the name of the attribute that contains the value of the source data
field.
Blank string: No value is passed.
• ProIIAttributeName:
Identifies the source data field.
• ComosSpecName:
Analogous to Read(). The attribute must be of type “List”. The name of the
column into which the data field is written must be passed as well.
Notation:“NameOfTab.NameOfAttribute.NameOfColumne”
Example:
Node.ReadArray "SideColumn", "NumberOfPumparounds",
"PumpAroundTrayFrom", "TPA.ND0081.ND0072" 'Pumparound
'from tray

51.5.5.4 ReadArrayToFewSpecs()
Function ReadArrayToFewSpecs
ProIIArrSizeAttributeName As String,
ComosSpecNames As String)
As Boolean
Reads a one dimensional field from PRO/II and writes it into multiple
attributes of the Comos object that is managed by the ProIINode instance.
Parameters:
ProIIClassName, ProIIArrSizeAttributeName and ProIIAttributeName:
Analogous to ReadArray().
ComosSpecNames:
Contains the name of the target attributes. They are passed in a string, sepa-
rated by commas.
This function is used if values are stored in a data field in PRO/II that is split
into two data fields in Comos.
Example:
Node.ReadArrayToFewSpecs "HcurveCalc", "NumberOfPoints",
"CriticalPresLV", "HC.ND0114.CD0015v,
HC.ND0114.CD0015l/P11.32" ' Critical Pressure
51.5.5.5 ReadSI()
Function ReadSI
As Double
Returns the value of an attribute from PRO/II as a numeric value. The func-
tion is called if, for example, you need the value within control flow struc-
tures.
There are differences between PRO/II and Comos in the use of SI standard
systems. If there is a difference, then the SI standard system used by Comos
is taken as the basis. This means that the value of the unit specified by the
PRO/II standard system is converted into the unit specified by the Comos
standard system.
Parameters: See Read().

51.5.5.6 GetComosSpecArray()
Function GetComosSpecArray(ComosSpecNames As String,
ComosSpecCount As Integer)
As String
Help method.
Parameters:
• ComosSpecNames As String:
Comma-separated list of Comos attributes.
• ComosSpecCount As Integer:
Number of attributes that are passed in ComosSpecNames.
Return value:
String array: Each field contains one of the attribute names that were passed
in ComosSpecNames.
51.5.5.7 Functions that are used internally

ProIINode possesses additional functions that are only called internally and
which have no application in the modification of the import.
Here is a brief overview.
ReadMainComp()
Function ReadMainComp
As Boolean
Reads a value from PRO/II and writes it to a sub-object (component) of the

CompCalc planning object.
Parameters: The same as for Read().
ReadStreamComp()
Function ReadStreamComp
As Boolean

Writes data to a component link underneath a material stream. The component

link is created if it does not exist already. The objects that are created are
based on @1PE|PO|SIM|SUB|MAPSIM.
Parameters: The same as for Read().
ReadTempStream()
Function ReadTempStream(StreamID As String)
It is possible to create virtual streams in PRO/II. A call of this function

imports a virtual stream into Comos:
First of all the stream is created in Comos underneath the object to be called
and then the data is imported in the same way as for a normal material stream.
ReadTrayStreams()
Sub ReadTrayStreams()
If this function is called at a column, an object is created underneath the col-

umn for each tray (with name prefix “Tray”).
The created objects are instances of @1PE|PO|SIM|SUB|TRSIM.
51.5.6 HYSYS: Class HYSYSNode
The first two import steps can be modified via the HYSYSNode class from the
HYSYSImport.dll.
Background:
An instance of HYSYSNode is created for each simulation object during the
import operation. As with AspenNode, this instance is a temporary object
that serves as a link between Comos (the target object) and Aspen Plus (the
source object) and is only available during the import operation.
Analogous to the Aspen Plus import: The import functions defined on the
Script tab are called for each simulation object in the first two import steps
(see Overview, P. 51-54) and the HYSYSNode instance created for the current sim-
ulation object is passed as the parameter.
The import calls can be extended via the functions and variables of the
HYSYSNode instance and the standard import function modified for the first
two import steps.
The functions and variables of the HYSYSNode class are introduced in the fol-
lowing sections.

Note
In HYSYSImport.dll there is a second class: This is class HYSYSImport.
This class is instantiated via the OnClick() script of the ID.BUTTON1 button
of the HYSYS import object (compare SECTION 51.5.2: IMPORT OBJECTS: BUTTON1
TO BUTTON4). Subsequently, the following function of the HYSYSImport
instance is called in the script:
Function: Sub Import(ByVal objSimCase As IComosBaseObject):
This function starts the import operation. A reference to the HYSYS import
object is passed as parameter (cast to its IComosBaseObject base type).
Result of the call: The simulation objects are created underneath objSimCase
and an instance of HYSYSNode is created for each simulation object.
51.5.6.1 Properties
ComosDevice
ComosDevice As IComosDDevice
The target object in Comos.
Components
Components As Object
Link to the components of the active FluidPackages from HYSYS.
HYSYSObject
HYSYSObject As Object
The source object.
NodeType
NodeType As eNodeType
A variable that is only used internally to identify the HYSYS types.
SpecLog
SpecLog As IComosDSpecification
Reference to ID.ND0122: The attribute at the import object to which the log
text is written.

The property is used to control the output during the import operation.
XPos
XPos As Double
X-coordinate of the object in the HYSYS PFD.
YPos
YPos As Double
Y-coordinate of the object in the HYSYS PFD.
51.5.6.2 HYSYSClass()
Function HYSYSClass() As String
Reads the HYSYS class name from HYSYSObject.
51.5.6.3 LiquidPhase1()
Function LiquidPhase1() As Object
Calls a simulation material stream.

If HYSYSObject involves a stream, this function returns the LiquidPhase1
object of the HYSYS stream. The phase data can be read from the object.
51.5.6.4 LiquidPhase2()
Function LiquidPhase2() As Object
In the same way as for LiquidPhase1().
51.5.6.5 Read()
Function Read(strSpecName As String, hyAttribute As Variant,
[strHYSYSUnit As String], [strParam As String])
Reads a single value from HYSYS and writes it to an attribute of the Comos
object managed by HYSYSNode.
strSpecName:
Target attribute

Application / user interface FEED – Interfaces to simulators
hyAttribute:
The HYSYS object.
strHYSYSUnit:
Optional
The value that is passed here is set as SI unit. Then the value is converted into
the unit that has been set for the target attribute.
If a number is passed: The value of the HYSYS object is multiplied by this
factor.
Blank: The default unit for this HYSYS object type is determined and used.
strParam:
Optional
Only if the target attribute is a list. The index for setting the XValue.
51.5.6.6 ReadPhase
Sub ReadPhase(strchapter As String, hyFluidPhase As Object)
Calls a simulation stream object. Writes phase tabs to streams.

hyFluidPhase:
For example, by calling LiquidPhase1().
51.5.6.7 VapourPhase()
Function VapourPhase() As Object
Analogous to LiquidPhase1().
51.6 Application / user interface

The import operation is controlled via the properties of the import objects,
“ID| Import data ” tab.
The following operation sequence presupposes that the base data has already
been prepared as desired.
It is assumed that the planning structure that has been predefined in the Stan-
dardDB is to be used and that only one PFD diagram (that had been created
automatically together with the process unit) exists underneath the process
unit:
- Project root

FEED – Interfaces to simulators Application / user interface
- PR1 Process_Example
- ABS Boundary Streams
- AMA Components
- APU Process Units
- PU001 Process Unit_Example1
- PFD.1 PFD diagram
- AEQ Equipment
- AXX Miscellaneous
Starting point: The SIM Simulation Data folder underneath the process
unit.
The import is always done for a particular run case. In the default planning
structure, an import object is created first of all for the main case (the import
object of level 1). Then, additional import objects (level 2) can be created
underneath the level 1 import object, which then import additional run cases.
See SECTION 51.3: TECHNICAL SEQUENCE for more detailed information regarding
the technical background to the configuration of the base data.
51.6.1 Application: Aspen Plus import
Creating the import object of the level

Context-sensitive menu of the SIM Simulationsdaten folder: | NEW| AXSI
ASPEN XML SIMULATION IMPORT:
The import object has the SystemType Device (CDevice:

@1PE|PO|SIM|XXSI|AXSI).
Currently it is not possible to carry out an import operation by using

drag&drop.

Open the Properties window of the import object and select the
“Import Data ” tab:
Specifying the import file

Select via “ID.ND0123| Import file ” [...] the XML file that is to be imported:
Currently there is only the option to create a link to the source file (not a
copy).
Setting the import options

Among other things, the object-specific import option is set on the “Import
options ” tab.
If the import options should deviate from the preconfigured ones:
Open the Properties window of the import object, “Import options ” tab:

• “Stream/tray/stage compositions ”:
Determines for simulation components which attributes are imported to the
PD Component Data tab.
• “Column trays/stages ”:
Determines whether only the data of the column is to be imported, or the
data of the column and the trays, or else the data of the column, trays and
components.
If a different setting is required for an import operation than the one that had
been preconfigured by the administrator, this must be set before the first
import step.
However, in most cases it will not be necessary to change the settings here.
Step 1: Starting the import

Press the [START IMPORT] button. Simulation objects are created underneath
the import object for the objects from the import file. However, as a rule these
objects do not need to be edited any further:
The following properties of the import object are filled with information from
the simulation run:
• “D.ND0120| User information ”
• “ID.ND0121| User ID ”
• “ID.ND.0294| Aspen version ”

Entries regarding possible errors or incorrect configurations are written to

“ID.ND0122| Log text ” during the import operation.
Step 2: Creating the PFD objects

If you are not working with the planning structure predefined in the Stan-
dardDB, you must determine underneath which process unit the PFD objects
are to be created before carrying out the second import step.
Import object, “Import Data ” tab, link field “Import into process unit ”:
If this link is left empty, the process unit is used underneath which the import
object is located.
If another main case than the one preconfigured at the base object of the
import object is to be created, then its name must be entered:
“Import data ” tab, “Design Case ” attribute:
Enter the desired run case, for example, TEST.

This property must not be left blank.
Preconfiguration in the StandardDB: value = DESIGN.
DESIGN is created as the main case. In addition, the default run cases MIN and
MAX will be created but remain blank.
Other value: for example, TEST

The specified run case is imported as the main case. The default run cases
DESIGN, MIN and MAX are created as well but remain blank.
Select the [CREATE PFD OBJECTS] button on the “Import Data ” tab. PFD
objects are created for the simulation objects.
Result:

• The PFD equipment and PFD process streams are created.

If the base data administrator has retained the default configuration of the
import object, the PFD objects are sorted automatically into the folders
underneath the process unit:
The PFD equipment is given the same name as that of the simulation object.
The PFD process stream is given the same name as that of its simulation
material stream.
• Block equipment, for example a column:
If the administrator has configured the base data correspondingly, an entire
assembly is created automatically. (For example: column, heat exchanger,
pump, valve and vessels). The PFD objects are automatically connected
with one another as is specified in the assembly.

• Case objects (Equipment Cases) for the main case and the default run cases
are created underneath the equipment. They are given the same names as the
cases:
• Material streams for the main case and the default run cases are created
underneath the process streams. The material streams correspond to the run
cases of the equipment and are given as their Name the names of the cases:
• The components are created underneath the material stream that had been
input at the import object as the main case (“Import data ” tab,
“ND0140| Design Case ”).
Components also contain case-dependent data.
Each component has a pointer to its associated pure component:
You can use the context-sensitive mouse menu of the component to navigate
to its pure component: | NAVIGATE| IMPLEMENTATION.

• If the base data administrator has retained the default configuration of the
import object, the pure components are created underneath the process unit,
in the AMA Components folder:
References to the components that have been assigned to a pure component

are displayed underneath each pure component:
You can navigate to the components by means of these references.
Step 3: Placing the PFD streams

Before this step can be executed, the equipment must have been placed man-
ually on the PFD diagram underneath the process unit:
When placing the equipment, it is necessary to distinguish whether or not the

PFD object is part of a PFD assembly.
Part of an assembly:
• The equipment simulation object created in step 1 has a reference to a PFD
assembly (“Import data ” tab, “ID.ND0254| PFD Assembly ” attribute).
Comos uses the assembly to create the necessary PFD objects in step 2.

• A copy of the PFD template predefined in the base project underneath the
assembly is created at the same time as the PFD objects. This copy is stored
underneath the equipment simulation object.
• The entire template can be placed in one step by dragging any desired item
of PFD equipment that is part of the assembly onto the PFD diagram:
The copy of the PFD template is deleted afterwards. Thus the collective
placing function is not made available twice.
Without assembly:
• The equipment simulation object has no reference to a PFD assembly. The
PFD equipment must be dragged manually from the Navigator onto the PFD
diagram.
After placing the equipment, the connected process streams are also placed
automatically via [PLACE PFD STREAMS] if the following applies: On the Sys-
tem tab of the process stream, the SYS.ND0385 Visible in mass balance
attribute must be activated.
Streams whose connected equipment has not been placed are not placed,
either.
Streams whose connected equipment is located on different diagrams are seg-
mented:

The segments are placed, each with a page reference to the other diagram:
Importing subcases
In order to import another run case than the one specified in the initial import
(i.e. the main case), create an import object for a run case (import object level
2) underneath the import object of level 1:
Call the context-sensitive mouse menu of the import object level 1, | NEW
| AXSI1 ASPEN XML-SIMULATION IMPORT (CASE):
Open the properties of the run case import object and select the “Import
data ” tab:

Set the import file and enter the name of the new run case, for example
TEST_2.
If the import options should differ from the preconfigured import options, you
must switch to the “Import options ” tab and change the settings. (In the same
way as for the import object of level 1, see Setting the import options, P. 51-76).
Then return to the “Import Data ” tab and select [START IMPORT].
The file is imported and simulation objects are created underneath the run
case import object. General information from the simulator (date of the sim-
ulation run, etc.) and entries regarding possible errors or incorrect configura-
tions are written to the import object .
Select the [CREATE NEW CASE] button:
Comos checks whether the objects located underneath the run case import
object have already been imported for another run case. For this, not only the
import object of level 1 is searched, but also all other import objects of level
2 that are located in parallel to the current import object. The check is done on
the basis of identical names.
Equipment:
• The equipment has already been imported once. Result: The associated PFD
object already exists and a new case (Equipment Case) is created underneath
the PFD object.
• The equipment is imported for the first time. Result: A new item of PFD
equipment is created and underneath the equipment the new case
(Equipment Case).
Material streams and components:
• The material stream has already been imported for another run case. Result:
The associated PFD process stream exists already and underneath it is the
corresponding PFD material stream.
The material stream for the current run case is created in parallel with the
existing material stream. It receives the same name as the current run case.
The PFD components are created underneath the material stream.
• The material stream is imported for the first time. Result: A new PFD
process stream is created. The process stream receives the name of the
simulation object of the material stream.
A PFD material stream is created underneath the process stream and
receives the same name as the current run case.
The PFD components are created underneath the PFD material stream.

Pure components:
• The pure component already exists in the AMA Components folder
(regardless of whether it was imported or created manually):
No new pure component is created. Nothing else is done, since pure
components do not contain case-specific information.
• The pure component does not yet exist in the AMA Components folder: The
pure component is created in the folder
51.6.2 Application: PRO/II import
Creating the import object of level 1

Drag the desired .prz file from the Windows Explorer onto the SIM
Simulation Data folder. An import object of level 1 is created automati-
cally:
The user is asked to decide whether to use a copy or whether a link is to be set
up. It is recommended that you create a copy (select [YES] in the dialog win-
dow):
The import object automatically points to the file.

The import object is a document with a base object link to @1PE|DS|@O|PRZ.
(See SECTION 51.4.3.1.1: “...||PRZ PROII SIMULATION IMPORT” regarding the configu-
ration of this base object.)

It has multiple context-sensitive mouse menu commands:
| PROPERTIES:
Opens the Properties window of the document.
• Tabs General and ProII :
General properties that are set automatically by using drag&drop. For
example, on the PROII tab you can find the path to the import file.
• Tab Specifications :
Tabs that control the import operation. As a rule, the base object has already
been preconfigured by the administrator. However, sometimes it is still
necessary to make some changes manually.
For example, object-specific and simulator-specific import entries can be
made on the “Import option ” tab (see Configuring the import options, P. 51-86).
| OPEN:
Starts the simulator. (This has the same effect as double-clicking on the
import object.)
|START IMPORT,
| CREATE PFD OBJECTS,
| PLACE PFD EQUIPMENT ,
| PLACE PFD STREAMS:
Start the individual import steps. They are called in this order.
The import steps can also be started in the Properties window, via the buttons
of the same names on the “Import data ” specifications tab.
Configuring the import options

If you want to use other import options than the ones preconfigured by your
adinistrator:
Open the Properties window of the import object, “Import options ” tab:

“Object specific import options ”:
• “Stream/tray/stage composition ”:
Determines which attributes are to be imported for the simulation
components (on the “PD| Component Data ” tab).
• “Column trays/stages ”:
Determines whether only the data of the column is to be imported, or the
data of the column and the trays, or the data of the column, trays and
components.
“Pro/II import options ”:
Checkbox “Calculate Stream Properties ”:

Activated (default, recommended):
The simulator is activated once again and the stream properties are
calculated again. Any stream properties that are missing in the source file
are calculated and likewise imported.
Step 1: Starting the import

Now start the first import step via the context-sensitive mouse menu or the
Properties window: | START IMPORT.
Simulation objects are created underneath the import object for the objects
from the import file. However, as a rule it is not necessary to edit these objects
any further.
The import object is filled with data from the simulation run. In addition,
entries regarding possible errors or incorrect configurations are written to the
import object: “Import Data ” tab.
(Compare SECTION 51.6.1: APPLICATION: ASPEN PLUS IMPORT, section Step 1: Starting
the import, P. 51-77.)

Step 2: Creating the PFD objects

If you want to create another main case than the one preconfigured at the base
object of the import object, enter its name in:
“Import data ” tab, “Design Case ” attribute:
For example, enter Test as name of your run case.

The “Design Case ” attribute may not be left blank.
Preconfiguration in the StandardDB: value = DESIGN.
Of the preconfiguration is not changed: DESIGN is created as the main case. In
addition, the default run cases MIN and MAX are created.
Other value: For example, Test
The specified run case is imported as the main case. The default run cases
DESIGN, MIN and MAX are created as well, but remain blank.
If you do not work with the planning structure predefined in the StandardDB,
it is also necessary to determine underneath which process unit the PFD
objects are to be created:
Import object, “Import data ” tab, “Import into process unit ”. (In the same
way as for the Aspen Plus import operation, compare Step 2: Creating the PFD
objects, P. 51-78)
Now the | CREATE PFD OBJECTS command can be executed.

PFD objects are created for the simulation objects.
See Step 2: Creating the PFD objects, P. 51-78 for a more detailed listing of the PFD
objects that are created in this step.

In the Navigator, the results of the second import step can, for example, look
as follows:
Step 3: Placing the PFD equipment

The | PLACE PFD EQUIPMENT command automatically places the equipment
that were created in step 2 on the first PFD diagram located underneath the
process unit.

You can also place the equipment on another diagram. To do this, a reference
to the desired diagram must be set at the import object on the “Import Data ”
tab at the “Import into Document ” property:
(For example, if you are working with another planning structure than the one
preconfigured in the StandardDB via the project settings.)
Comos uses the coordinates exported from PRO/II for the placing.
Step 4: “Place PFD streams”

The | PLACE PFD STREAMS command places the process streams that were cre-
ated in step 2 onto the same PFD diagram as the connected equipment.
Usually this is the first PFD diagram located underneath the process unit.
If a different target document was specified at the import object (tab “Import
data ”, “Import into document ” attribute), then the process streams are
placed there.
The following algorithm is used when doing this:
• Comos determines for each simulation material stream with which PFD
equipment it is connected.
• The PFD process stream is placed on the same PFD diagram as its assigned
equipment and is included into the mass balance – provided that its
“SYS.ND0154| Visible in mass balance on PFD ” attribute has been
activated.
• Thus, a process stream that has not been connected is not placed.
• Likewise, a process stream whose connected equipment has not been
connected is not placed.
As a rule, the connected equipment is located on one diagram, namely on the
diagram on that it had been placed in step 3. However, if parts of the equip-
ment were placed manually on another diagram, it can happen that the equip-
ment with which a stream is connected is located on different diagrams. The

stream is segmented and the segments are placed. A page reference is added
on the diagrams. (In the same way as for an Aspen Plus import, see Step 3: Plac-
ing the PFD streams, P. 51-81.)
Importing subcases
Proceed as follows to import an additional case in addition to the main case:
Create a second import object underneath the import object of level 1.
This is done by simply dragging the prz file that contains the new run case
from a Windows Explorer window onto the import object of level 1:
As was already the case when creating the import object of level 1, the user is
asked to decide whether to use a copy or whether a link is to be set up. It is
recommended that you create a copy.
An import object of level 2 is created underneath the import object of level 1:
The import object that is created in this way automatically points to the file
that was dragged from the Explorer. It is based on the same base object as the
import object of level 1 and possesses the same properties.
If required, you can change the import options preconfigured by your adinis-
trator. (The configuration is similar to that of the import object of the main
case, see Configuring the import options, P. 51-86).
Now the first import step can be executed: Call the context-sensitive mouse
menu of the import object and select | START IMPORT.
The file is imported and simulation objects are created underneath the import
object. General information from the simulator and entries regarding possible
errors or incorrect configurations are written to the simulation objects.

The following properties must be set on the “Import data ” tab before execut-
ing the second import step:
• The new run case must be input in the “Design Case ” attribute:
Default value set in the StandardDB: DESIGN.

• If you are not working with the planning structure tspecified by the project
settings, you must also specify underneath which process unit the new run
case is to be created:
“Import into process unit ”
Here, the same process unit should be input as at the import object of level 1.
Now call the second import step: | CREATE PFD OBJECTS.
If an object is imported for the first time, then the corresponding PFD object
is created as well. If an object had already been imported for another run case,
only the run case object is created underneath the associated PFD object. (In
the same way as for the import of a subcase from Aspen Plus, see Importing sub-
cases, P. 51-83.)
The remaining import steps (| PLACE PFD EQUIPMENT and | PLACE PFD
STREAMS) only need to be called if, with regard to the main case, new equip-
ment or process streams were imported.
If the objects are to be placed on a diagram other than the first diagram located
underneath the process unit, this diagram must have been specified before-
hand by means of “Import into document ”. The setting should match that at
the import object of level 1.

51.6.3 Application: HYSYS import
Creating the import object and determining the import file

Analogous to PRO/II (Creating the import object of level 1, P. 51-85). Only in this
case you must select an .hsc file, of course.
The import object is a document with a base object link to
|@1PE|DS|@O|HYSYS.
Configuring the import options

Analogous to PRO/II import (Configuring the import options, P. 51-86). However,
here there is only the Composition stream/tray/stage object-specific
import option and no simulator-specific import option.
Step 1: “Start import”

Analogous to PRO/II (Step 1: Starting the import, P. 51-87).
Step 2: “Create PFD objects”
Analogous to the PRO/II import (Step 2: Creating the PFD objects, P. 51-88).
Step 3: “Place PFD equipment”

Analogous to PRO/II (Step 3: Placing the PFD equipment, P. 51-89).
Step 4: “Place PFD streams”

Analogous to PRO/II (Step 4: “Place PFD streams”, P. 51-90).
Importing subcases
Analogous to PRO/II (Importing subcases, P. 51-91).


PE and CM modules General notes on templates
52 PE and CM modules
52.1 General notes on templates

Templates can be any desired Comos planning objects.
Sole prerequisite: The objects must be organized in a specific way. See
SECTION 52.2: PREPARING 3D / CM TEMPLATES FROM SCRATCH for details on how they
should be organized.
Templates have three advantages:
They can be used as often as you wish without having to set them up from
scratch each time.
Templates can be used intuitively by users. If the templates have been orga-
nized correctly, it is almost impossible to use them incorrectly.
Each application is saved. The applications that have been created from the
templates can be found quickly and edited together. For example, decision
tables and object queries evaluate the “applications”.
52.2 Preparing 3D / CM templates from scratch

Templates must be located in the “@Template” root node on the Process tab
in the SO1 (Base object ) project. How to prepare 3D / Conceptual Mode-
ler (CM) templates, for example templates that can be used to convert PFD
objects to 3D objects, will be described in a series of steps:
52.2.1 Creating the unit to contain P&ID and 3D objects
• Open the SO1 Base objects project and click the Process tab in the
Navigator.
• Within the Navigator tree, expand the @Template Copy templates node,
and then expand the PE Process Engineering node.
• The PE Process Engineering folder contains a node “02 P&ID+CM
Templates“ consisting of different types of equipment folders:

Preparing 3D / CM templates from scratch PE and CM modules
• Based on the equipment template type, select the appropriate equipment

folder and create a PFD equipment object hierarchically below it.
For example, to create PFD equipment object for a vertical vessel:
– First expand the 02 Vessel node and right-click the 01 Vertical
vessel folder and select |New |New Object :
– Next, assign the newly created object an appropriate base object; drag
the base object from the node @1PE|PO|EQ (e.g. for a vertical vessel,
drag “@1PE|PO|EQ|03|VES|VES01 Vessel“ ) into the Base object
field in the properties window of the newly created object.
• Then create a new unit (to contain the 3D objects) under the newly created
PFD equipment object by right-clicking the object and selecting |New
|General |New Object, and assigning it the base object
“@1PE|US|FI|TMP|EQT Equipment Template.“ This creates the unit
EQT1 Equipment Template under the PFD equipment item.
• It is mandatory to rename the unit to @PEASSEMBLY .
Having created the unit to contain the 3D objects you can now start placing
objects (to prepare the template) in the 3D Model space as described in the
Comos CM manual.
52.2.2 Placing 3D objects in the Model space
Dragging 3D objects from the Navigator onto the Model space

• Mark the node “CM Template for CM“ below the @PEASSEMBLY unit
in the Navigator and click |Viper | Conceptual Modeler on the Comos
toolbar to open the 3D Model space.
• You can now start designing the template by placing and grouping 3D
objects in the Model space. By default, the 3D objects to be used are located
in the “@3D Viper“ node on the Base Objects tab.

PE and CM modules Preparing 3D / CM templates from scratch
For example, the vessel and cone objects shown below can be used to design
the template for a vertical vessel:
Using the DimLen object to group 3D objects in the Model space

After placing the objects you want in the Model space, you can now use the
DimLen object ( located on the Base data tab, in the node |@3D |1 |@ACC
Miscellaneous objects) to group the objects to enable you to handle (e.g.
shorten or lengthen) the multiple objects as a single object (i.e. not as separate
objects).
Please see the Comos CM manual in the section “User-Defined Dimension
Objects“ for a detailed explanation on how to use the DimLen object to group
multiple objects.
The following illustration shows user-defined grab points on the vessel and
cone objects that can be used to stretch the objects together:
Having grouped the 3D objects together in the Model space, the next step is
to link the PFD objects to 3D objects as described in SECTION 52.2.3: CREATING A
MAPPING TABLE AND LINKING PFD OBJECTS TO 3D OBJECTS.

52.2.3 Creating a Mapping table and linking PFD objects to 3D objects
To establish links between the PFD equipment and the 3D objects for the tem-
plate by means of a Mapping-table:
• Create a Mapping-table object under the CM node containing the 3D
objects. To do this, select and right-click the CM node and select |New
|@Mappingtable :
• Double-click the newly created Mapping-table to open it to start

establishing static links between PFD attributes and 3D attributes.
• Link PFD and 3D attributes: first browse through the Navigator and drag the
attribute of the 3D object (i.e. the target attribute) into a field under the
Specification column in the Mapping-table. Next, drag the PFD (source)
attribute (typically from the Mechanical data tab) into the corresponding
field in the Source object column:
• Having linked attributes, confirm with [Apply] or [OK].

• (Optional): Please note: The “Function “ column in the upper section of
mapping-table list window can be used to write functions to evaluate
attributes by means of arithmetical operations. Before using the “Function “
column, you are recommended to first drag the attribute to be used for the
evaluation onto the Source specification column in the lower list window,
because its name (which is the variable name ) is required to write the
function. Next, drag the 3D attribute onto the specification column in the
upper list window and use the variable name of the source attribute (as
displayed in the “Variable name “ column) to write a formula in the
“Function “ column. For example, if the variable name of the source
attribute is “CD07 “ and you want to write a function to enable the 3D
attribute to double its value, then the formula will be s(“CD07“) * 2 .

PE and CM modules Preparing 3D / CM templates from scratch
52.2.4 Linking the DimLen object to PFD objects
After creating and setting the DimLen object as described earlier, it can be
linked to PFD attributes in the same way as other 3D objects, but the main
point to take note is that the DimLen object groups many different objects
together, and its dimensions (e.g. length) are only controlled by the target
attribute XV002. Thus, to link the length of the DimLen object to a PFD
attribute, use the PFD attribute as the source attribute and XV002 as the target
attribute for the mapping table.
52.2.5 Connector mapping
The next step involves the mapping of PFD and P&ID as well as CM connec-
tors. The PFD connectors must be mapped onto the P&ID connectors (mostly
found in nozzles) to enable them to be represented correctly upon conversion
from PFD to P&ID. In addition, connector mapping is an essential require-
ment for the Auto-routing facility in Comos FEED CM.
52.2.5.1 PFD -> PID connector mapping

• Open the properties window of the @PEASSEMBLY unit shown below
and click the PFD/PID Connecting Mapping tab:
Please note: Each of the “I “ and “O “ fields (e.g. I1, I2, 03 and 04) on the
PFD/PID Connecting Mapping tab actually represents a particular PFD
object connector, for example, the I1 field shown above represents the I1 PFD
connector shown below:

• Drag each nozzle connector from the P&ID object (under the PID node in
the Navigator) into the corresponding “I “ or “O “ fields on the PFD/PID
Connecting Mapping tab to map the P&ID and PFD connectors in
question.
For example to map a P&ID nozzle connector to a PFD connector I1, simply
drag the P&ID connector from the Navigator into the I1 field as shown below:
Please note: As a general rule, P&ID objects do not directly possess connec-
tors, but their connectors can be accessed from attached nozzles. Thus, unlike
PFD connectors, nozzles must be placed on the P&ID objects before being
able to access their nozzle connectors, also known as P&ID connectors.
The additional connector fields (001 to 014) are for user-defined or newly cre-
ated connectors. They can be used in the same way as the “I “ and “O “ fields.
• Click [OK] or [Apply]. You’re done!
To correctly prepare 3D templates make sure you follow all the steps
described under SECTION 52.2: PREPARING 3D / CM TEMPLATES FROM SCRATCH.
• To make the prepared 3D templates available to all users, you need to follow
the steps described in SECTION 52.4: AVAILABILITY OF P&ID AND 3D TEMPLATES.
52.2.5.2 PFD -> CM connector mapping

To map PFD and CM connectors:
• Open the properties window of the @PEASSEMBLY unit and click the
PFD/CM Connecting Mapping tab:

PE and CM modules Preparing P&ID templates
• Drag each nozzle connector from the 3D object (under the CM node in the
Navigator) into the corresponding “I “ or “O “ fields on the PFD/CM
Connecting Mapping tab as shown in the illustration below:
• Click [OK] or [Apply]. You’re done!
52.3 Preparing P&ID templates

P&ID templates can be used to convert PFD objects into P&ID objects. They
are also required for the Auto-routing facility in Comos FEED CM.
To prepare P&ID templates:
• Create a new @PEASSEMBLY unit to contain the P&ID objects in the
same way as described in SECTION 52.2.1: CREATING THE UNIT TO CONTAIN P&ID
AND 3D OBJECTS.
• Expand the @PEASSEMBLY node and double-click on the document PID

P&ID Template :
• Use the equipment symbols on the symbol bar of the document to design the
equipment template. Note that you can also use base objects located in the
the “PI |PI EN Piping and Instrumentation“ node to design the templates.
• Change to the Navigator and move the objects/equipment that are
automatically created parallel to the PID document (i.e. at the same
hierarchy level) to lie under the “PID Template for PID“ node.
• Save the P&ID template.

Availability of P&ID and 3D templates PE and CM modules
• The last step involves the mapping of PFD and P&ID connectors. This can
be achieved in the same way as described in SECTION 52.2.5: CONNECTOR
MAPPING
52.4 Availability of P&ID and 3D templates

Having created the P&ID and 3D templates, they need to be made available
to all users. They can be accessed from the mouse menu of the corresponding
PFD planning objects.
Please note: You can skip this section if the newly created templates can be
chosen by right-clicking the PFD equipment (in the AEQ folder within a pro-
cess unit) in the Navigator and choosing “Select Template“ .
When a template has been prepared for a particular PFD object, it can be made
available to all users as follows:
• Click the Base objects tab in the Base project, and go to the base object for
the PFD object in question located in the @1PE |PO |EQ node. For
example, the base object for a PFD vessel is located in the node @1PE |PO
|EQ |03 |VES|VES01.
• The next step involves creating the query object (under the desired PFD
base object) that will be used to search for and filter the templates. If the
base object contains no query object, create one under the PFD base object
(in this case, VES01) by selecting and right-clicking the object and
selecting |New |New query |Standard |Planning objects:
Please note: The query object must be given the name “@Templatelist.“

PE and CM modules Preparing 3D templates using existing ones
• Open the query object and assign it a suitable Start object and Base
object. Suitable Start objects are located at |@Template |PE |02 | , on
the Process tab. For example, the following illustration shows the Start
object for a vertical vessel:
Suitable Base objects for the query object are located at |@1PE |PO |EQ,
on the Base objects tab. For example, the Base object for a vessel is illus-
trated below:
52.5 Preparing 3D templates using existing ones

An easier way of creating 3D / CM templates is by making use of other tem-
plates. For example, to prepare the 3D template for a horizontal vessel using
another 3D vessel template:
• Open the SO1 Base Objects project and click the Process tab.
• Expand the nodes |@Template |PE |02 |02 |01 Vertical Vessels:

Preparing 3D templates using existing ones PE and CM modules
• Make a copy of the VES002 vertical vessel in the 01 Vertical Vessels

folder. That is, copy and paste the VES002 vessel in the 01 folder, and give
it a meaningful description, e.g. Example Vertical Vessel as shown
below:
• Expand Example Vertical Vessel node and select the

the
@PEASSEMBLY object and click the Viper |Conceptual Modeler menu
to view existing vessel template in the Model space:
• You can now expand the @PEASSEMBLY node to view the 3D objects in
the Navigator tree:
• Having viewed the existing 3D template, depending on the new template to

be created, you can either delete all objects in the Model space (i.e. the
objects underneath the @PEASSEMBLY Vertical Vessel node) and place

PE and CM modules The PE base object structure
and group new objects in the Model space using the dimension object, or
you can simply delete the objects you do not need and then add new ones
before grouping them together.
• Having placed and grouped the objects in the Model space, the next step is
to establish links between the PFD objects and the 3D objects in the Model
space by means of a mapping table, as explained in SECTION 52.2.3: CREATING
A MAPPING TABLE AND LINKING PFD OBJECTS TO 3D OBJECTS and SECTION 52.2.4:
LINKING THE DIMLEN OBJECT TO PFD OBJECTS.
Please note: If the mapping table in the existing template is still available (i.e.
if it has not been deleted), you cannot create a new one. You simply need to
use the existing mapping table to link the PFD and 3D objects.
You’re done! The newly prepared template is automatically available for all
users.
52.6 The PE base object structure
52.6.1 PE root node

In the base project, on the base objects tab, the root node for PE objects is
@1PE Catalog PE Data , which is subdivided into categories such as CN ,
DS , PO and US .
In the Navigator, objects that can be assigned to planning objects (in the Base
objects field of the planning objects) appear in dark red while those that can-
not be assigned are pink in color. On the System tab, in the Creation option
section, the option “Normal“ is only enabled for objects that can be assigned.
52.6.2 CN Nomenclature Catalog node
This node contains the names and descriptions of all the base objects and tabs
that are used in the PE module. Thus the CN node can be used to refer to the
meanings/descriptions of PE objects. Before creating a new object or tab in
the PE module, it is strongly recommended that the objects and tabs should
first be created in this node to avoid duplicate object names.
52.6.3 DS Data Structures node
It is subdivided into different categories such as CA Attributes Catalog,

Tabs Catalog and other essential base objects.

The PE base object structure PE and CM modules
52.6.4 CA Attributes Catalog
All attributes that are in the PE module are (or should be) in this node. It is
strongly recommended that the attributes should first be created in this node
to provide unique attribute names. Furthermore, attributes that are created in
this way can be edited just once (i.e. at one point) and the changes take effect
wherever the attribute is being used.
On the context menu of a PE attribute, the command |Navigate |Catalog
Attribute leads to attributes of the sub-nodes of CA - in the nodes CD, ND or
SY.
– CD Chemical and Physical Data: Contains numerical attributes, so all
attributes with numerical data (with/without units) should be created here.
– ND Names, Descriptions, Numbers: For textual attributes such as text
fields for remarks and descriptions.
– SY System Attributes: Contains very special attributes. For technical
reasons these attributes should not be modified.
– Q1 Query CD: Offers quick search and query facilities for all attributes in
the CD node. For example, it can be used to find out about the description
and units of an attribute.
– Q2 Query ND: Similar to Q1 Query CD, but meant for the attributes in the
ND node.
52.6.4.1 CC Tabs Catalog

All tabs that are in the PE module are (or should be) in this node. In the same
way as with attributes, it is strongly recommended that the tabs be first created
in this node to ensure that the tab names are unique within every object cate-
gory.
The tabs of the PE objects (e.g. Equipment, Process, Process Unit, Material
stream) are divided into object-specific categories. For example, the tabs of
an equipment are located in the node |CEQ Equipment Tabs, those of a pro-
cess stream are in the node |CPS Process Stream Tabs, etc. This makes it
possible to quickly locate all the tabs, and it offers a much degree of flexibility
in the way the tabs are named and described.
52.6.4.2 MT Mapping Tables

It contains the mapping-tables for equipment, material streams and P&ID
pipes.

PE and CM modules The PE base object structure
– MTQE: Mapping-table to establish links between simulation equipment

and Comos equipment.
– MTMS: Mapping-table to establish links between simulation material
streams and Comos material streams.
– MTPI: Mapping-table to establish links between process streams.
52.6.5 QU Queries
It contains queries for objects such as attributes, documents, and planning

objects.
52.6.5.1 REM Remarks

It provides a base object for the Remarks attribute.
52.6.6 PO Process Objects
This node contains all the equipment, simulation objects and stream objects
that are used in the PE module.
52.6.6.1 EQ Equipment
The base objects for all PFD equipment are found in this node.
52.6.6.2 SIM Simulation Objects
This node contains the base objects for all simulation objects. It is subdivided
into BLC, STR, SUB and XXSI:
– BLC: Base objects for all common simulation objects such as columns,
valves, heat exchangers, pumps and reactors are found in this sub node.
– STR : Contains base objects for stream simulation objects and the
CompCal simulation object.
– SUB : Contains base objects for simulation sub objects, for example,
MAPSIM for material pointer simulation objects, and TRSIM for column-
tray simulation objects.
– XXSI : Contains the base object for the Aspen import simulation object.
For detailed information see SECTION 51.4.1: “@1PE|PO|SIM SIMULATION OBJECTS”.

Tips for administrators on PE objects PE and CM modules
52.6.6.3 SO Stream Objects

The SO node contains base objects for process stream and material stream
objects and their components, e.g. material pointers and materials. It also con-
tains base objects for the components of a block diagram, e.g. balance
streams, balance stream flags, Input/Output material arrow and process units.
52.6.7 US Unit System
It contains the predefined unit structure of the PE module.
52.7 Tips for administrators on PE objects
52.7.1 Tips on process units
To ensure that the process units in the block diagram are automatically added
to the APU folder of the process, the following conditions must be fulfilled:
• Click the Base Objects tab of the Base objects project (S01), and go to
@1PE |US |FI |PR Process . In the properties window of PR Process ,
on the System tab, in the Creation mode section, make sure
Subelements is switched on.
Note that the base object whose Subelements must be switched on is the
base object (i.e. the process) hierarchically above the block diagram in ques-
tion.
• Also switch on Subelements in the Creation mode section of the folder
(in this case, APU All Process units ):

PE and CM modules Tips for administrators on PE objects
Please note: the folder in question is the folder beside (i.e. at the same hierar-
chical level as) the block diagram.
• On the System tab of S01 |@1PE |US |FI |PR |the folder in question, the
fields Class and Subclass must have the entries Unit and Category
respectively.
• The process unit must be an element of this folder.
• In the Options window of the block diagram template,
SortNewObjectsInCategories must be availabe, and it must be True.
52.7.2 Tips on balance streams
The base objects for balance streams and balance stream flags are located at
@1PE | PO | SO | BS, and @1PE | PO | SO | BSF respectively.
52.7.3 Tips on equipment
For all equipment

The link between the maximum and minimum temperature and pressure val-
ues of a process stream and the design values on the Design Data tab of the
connecting equipment, as mentioned in the “Comos FEED Quickstart Guide“
chapter „Equipment Properties“: „8.2.3 Max. and min. design tempera-
ture/pressure“, can be controlled by the script function GetDisplayValue()
in the specifications CD0123, CD0124, CD0125 and CD0126.
Columns and compressors

The number of stage objects (for compressors) and the number of column sec-
tions that appear in the Navigator as mentioned in the “Comos FEED Quick-
start Guide“, chapter „Equipment Properties“: section „8.3.1 Compressor-
specific features“, and section „8.3.3: Column“, can be influenced by the
script Sub Onchange() in the ND0051 specification (for columns), and the
ND0034 specification (for compressors).
52.7.4 Tips on material stream attribute links
In the “Comos FEED Quickstart Guide“ chapter „All Process Streams

(APS)“: section 9.4.1: Linking material stream attributes we explained how to
establish links between material stream attributes. After the source value is
moved into the target field, a mapping table appears in the target material

Tips for administrators on PE objects PE and CM modules
stream. In the example below, if the DESIGN Temperature field is the source
field, and the MAX Temperature is the target field, then the mapping table
will appear under the MAX material stream as illustrated below:
The query for the Material stream list tab is located in the base project SO1
| @System | @0 |@PE | MSL.
Alternatively, a local copy MSL_Local can be created from within a planning
project in |@System |@0 |@PE |MSL_Local

Isometric module Defaults and definitions
53 Isometric module
With the Isometric module, you can create different types of piping isometrics
that serve as basis for prefabrication or erection (construction isometrics,
spools). When generating an isometric drawing, a 3D pipe model is calculated
in the background. The module works with pipe classes.
All examples and explanations are based on the StandardDB supplied with the
installation CD, example project COMOS_ISO Engineering example.
53.1 Defaults and definitions

The following prerequisites must be met for using the Isometric module:
Licenses
You must have a license for the Isometric module (available from Version
8.2). The license includes all 3D functionalities that are needed to calculate
the 3D pipe model in the background.
As the module works with the Pipe Parts Catalog (PPC), you must also have
a PPC license.
Database
In already existing customer databases, the pipe parts catalog (PPC) must
have been imported.
Pipe classes
With the help of the component catalog included in the pipe parts catalog,
pipe classes should have been prepared. The pipe classes are also managed in
the pipe parts catalog.

Defaults and definitions Isometric module
The following figure explains the interaction between pipe classes, PPC and
isometric drawings:
Planning procedure
Different planning procedures can be used when creating piping isometrics.
At present, Comos assumes the following planning procedure:
The isometric drawing is created based on the previous planning data, e.g.
using a P&ID diagram and a mounting diagram. Then it is computed. Finally,
it can be viewed in the 3D space.
An alternate planning procedure would be to base the isometric drawing on a
Comos P&ID process flow diagram. In this case, the P&ID objects must have
been linked with the PPC in advance. In the basic planning, the design engi-
neers use P&ID objects that are connected in the background with PPC
objects. The P&ID drawings can then be transported to the 3D space and from
there can be mapped to an isometric drawing. (For detailed information on the
linking between P&ID and PPC, see user documentation FD Interaction bet-
ween P&ID and PPC, P&ID and 3D.)
Project properties
The following settings must be made in the planning project:
Tab Links :
– Attribute Project structure : @J| @G Project settings, general
Simplifies the design of the planning structure. On the Unit tab, creates a
structure where category objects are automatically available under the sub
unit, which automate and simplify the management of components.
Category 03 Pipes: Collects all pipes. An isometric drawing is offered in
the mouse context menu of the pipes.

Isometric module Defaults and definitions
– Attribute Base data : SO1 Base project
Tab Module options| Process engineering :

– Library object for pipe : PI|EN|D|03|01
Library object for pipe branch : PI|EN|D|03|02|01
If no base object references are entered here in the planning project, the
software automatically takes the values set in the base project. (Please Note:
Since this does not involve inheritance, the references entered in the base
project are not visible in the user interface of the planning project.) The
references specified above are set in the StandardDB. The values can be
overwritten by the settings in the pipe classes (see SECTION 53.8.6: REMAINING
TABS).
The remaining attributes of the tab need not be set for the planning
procedure described in this documentation.
Tab Module options| Pipe classes/Viper :
– Definition of norm : @3D|@PPC|@Standardization Characteristics
– Definition of pipe classes : @3D|@PPC|@01
– Standard catalogs : @3D|@PPC|@CatStd
– Standard table “Nominal width” : @3D|01|05
– Symbol bar “Pipe class” : @3D|@Menu
– Rating for grid routing : @3D|2|AR|01
If no base object references are entered here in the planning project, the
software automatically takes the values set in the base project. (Please Note:
Since this does not involve inheritance, the references entered in the base
project are not visible in the user interface of the planning project.)

Base data, lists, templates Isometric module
If the structure of the base data differs from the structure of the StandardDB,
other objects must be referenced accordingly.
Miscellaneous
Moreover, the base data must be prepared by the administrator according to
the project requirements.
For detailed information, see SECTION 53.3: REPORT/ DATA SHEET.
The planning on which the isometric drawings are based should have been
completed.
53.2 Base data, lists, templates
53.2.1 | PI| EN| D| 03 Pipe
In the P&ID planning and when constructing a piping isometric drawing, you
must work with a three-level pipe structure. This pipe structure was explained
in detail in SECTION 57.2.1: PIPE STRUCTURE.
The base objects of the top two levels are managed under this node.
In SECTION 53.7: PIPE STRUCTURE FOR PIPING ISOMETRICS, you will find information
on the base object of the third level that is used in piping isometric drawings,
as well as isometric-specific deviations as regards the first and second level.
53.2.2 “@3D” branch
53.2.2.1 “@3D| @Menu”

Under this node, the base object icon bar of the isometric drawing is managed.
The base object icon bar is used to determine the preferred piping components
and to place piping components on the isometric drawing.
To include a new component type in the icon bar, create a new base object
under this node that has a base object reference to a concrete component of
the desired type.
As Name enter the first digits of the function code of the desired component
type (check the standard table |@3D|01|BC|01|03 Functionscode). The
function code is five-digit. The positions that remain unspecified are filled
with “XXX”. To add this base object to the base object icon bar, select | VIEW
| MENU BAR /SYMBOL BAR | SYMBOL BARS | CREATE DOCUMENT DEFINED from the
Comos menu and then add it to the @Sb_Pipeclass symbolbar.

Isometric module Base data, lists, templates
The icon is added to the icon bar. In the isometric drawing, it used to place
those components of the selected pipe class whose function code begins with
the numbers set as Name .
Example:
Function code for general elbows:
21XXX
Function code for concrete elbows:

21300 Angle elbow
21400 Segment elbow
21500 Return elbow
...
If the menu bar is managed in another branch, this branch must be referenced
in the project properties, Module options | Pipe classes / Viper tab, under
“Pipe class” Symbol bar .
53.2.2.2 “@3D| @PPC| @01 PipeSpec”

Piping isometrics work in a pipe class oriented way. The pipe classes (or “pipe
specs”) are represented through base objects that are managed within the pipe
parts catalog (PPC).
If the pipe classes are managed in another branch, this branch must be refer-
enced in the project properties, Module options | Pipe classes / Viper tab,
in the attribute Definition of pipe classes .
To generate a new pipe class, create a new base object under
@3D| @PPC| @01 PipeSpec. The properties of the pipe class are then set in
the Pipe class management dialog window from the ADMINISTRATOR menu
bar:
Usually, many planning projects will use the same pipe classes. Therefore, the
pipe classes are maintained centrally in the base project. If the settings
required in a planning project deviate from the settings in the base project, the
following should be done: Generate a local base object in the planning project
by copying the pipe class used otherwise, then customize this local pipe class
accordingly. Such a local copy can be easily generated through in the Pipe
class management.
For detailed information on the structure of the Pipe class management, see
SECTION 53.8: PIPE CLASS MANAGEMENT.

The tabs that the

pipe class base objects inherit from
@3D| @PPC| @01 PipeSpec are usually set in the Pipe class management
dialog window. Therefore, these tabs are likewise explained in SECTION 53.8:
PIPE CLASS MANAGEMENT.
53.2.2.3 “@3D| @PPC| @CTS Part Components”
53.2.2.3.1 Structure
The component catalog is structured according to standard systems:
- | @3D| @PPC| @CTS Part Components
- | @3D| @PPC| @CTS| 01 General Components DIN Metric

- | @3D| @PPC| @CTS| 02 General Components ANSI Imperial
- | @3D| @PPC| @CTS| 03 General Component Parts High Pressure
Metric
The basic structure of these three branches is almost identical. Here, as an

example, the metric catalog | @3D| @PPC| @CTS| 01:
The catalog is divided by component types. For better orientation, e.g. when
working with the Object Debugger, the name structure is based on the func-
tion code of the components.

Example:
Base object @3D| @PPC| @CTS| 1| 54| 55| 1| 01| B| 0010
[][]-Relief valve-DIN 3202/T2-PN 10-St 35.8 I
Function code 55130
The catalog exclusively contains manufacturer devices.
53.2.2.3.2 Technical background

All components that are placed on an isometric drawing must be 3D-capable.
Reason: The isometric drawing is calculated by a 3D model that runs in the
background.
Moreover, the components must have specific tabs, without which some of
the automatic report functions of the isometric drawing will not work.
The pipe parts catalog acquired through the PPC license meets this require-
ment. Therefore, in the StandardDB, all components placed on an isometric
drawing come from the PPC.
If you want to extend the PPC or create a separate catalog, the new objects
must have these tabs as well.
If the PPC is extended, the tabs are usually inherited and are automatically
available. You can then customize them if needed.
If you built a new catalog, get the necessary tabs from the branch @3D| @Y
Catalog specifications| CHP| PP Tabs Piping and
@3D| @PPC| @Standardization Characteristics and customize them if
needed.
53.2.2.3.3 Designing symbol

The graphic symbol that you see when you place a component on the isomet-
ric drawing is composed of several components.
Example: Symbol of a valve:

First of all, naturally from the component symbol itself. Sub symbols are
added to this symbol:
• Symbol for contact faces and connection types
Which symbols are added is defined in the component properties: By means
of the Symbols tab and through specifications on the GD 3D Geometry
tab, to which standard tables are assigned in which, in turn, scripts for
graphic symbols are defined.
Where these sub symbols will be added to the component symbol is
controlled by the component base object – by defining connector points for
the sub symbols.
• optional: tag symbols, e.g. position numbers
• optional: other text variables, e.g. *V*P E:Z (insertion point for the valve
drive).
Anchor points for tag symbols

A *V*P text with the identification key SX must be placed in the component
symbol, e.g.: *V*P SX:SYSISO.GT1*.
The *V*P text specifies:
• which specification of the component references the base object of the tag
symbol to be used (for position numbers, e.g., SYSISO tab, GT1
specification; there, a reference to the tag symbol for position numbers must
have been set).
• where the tag symbol will be added to the component symbol (the insertion
point is identical to the point of origin of the text variable).
If a *V*P text with corresponding key is missing, the tag symbol is automati-
cally placed in the center of the symbol.
Connector points
Connector points are defined in the component symbol. The connector points
determine where other symbols will be added – for example, the symbols of
connection types and the contact faces, but also of dimensions.
Following types of connector points are available:
1. Logical connector points: CX[Number]
Purpose: Logical connector points correspond to the connectors in the
planning objects. Each logical connection of a symbol on a report thus has
a counter part in the planning object. Logical connector points are
required when data is to be transferred from one object to another object.

As a rule, the components that are placed on the isometric drawing do not
themselves define logical connectors. Instead, they define placeholder
connectors. The symbols inserted at these placeholder connections then
define logical connectors. (See Example: Blocking valve, P. 53-9.)
Exception: All components (except pipes) must have a logical connector
point for the point of origin (CX0). CXO has no direct equivalent in the
Navigator and is used when setting graphic symbols, e.g. when setting a
dimension.
2. Physical connector points: CP[Number]
Purpose: To define connector points for graphic report elements (e.g.
dimensions). They exist only on the report, not in the Navigator.
Please note: No pipes can be connected to CP connectors.
Are addressed on the isometric drawing with Ctrl or Shift.
3. Placeholder connectors: C#[Number]
These connectors are needed to add additional symbols to the symbol of
the component, e.g. symbols for connection types and contact forms.
If a C# connector on the isometric drawing is not connected, the user can
move it with its grab point. Through that, pipes and elbows can be
extended from their unconnected end:
4. Dynamic connector points: CY[Number]

Only in pipes. They are generated dynamically, e.g. if a pipe is connected
with a branch, and are not predefined in the base object symbol.
You can generate as many dynamic connectors as you want. The dynamic
connector points are created in the database as logical connectors.
Example: Blocking valve

1. Configure the base object of the tag symbol.

See SECTION 53.2.3.1: “|@ISO|A TAG SYMBOLS”.

2. Configure the standard table for contact faces
In the StandardDB: |@3D|01|06 Contact faces
Scripts for symbols of contact faces are stored in this standard table. The con-
tact face contains purely graphical information.
If necessary, select the row of the desired contact face and customize its sym-
bol for the ISO diagram type.
Example: Contact face Form C:
Note:
All symbols (component, contact face, connection type) must be drawn in
non-rotated presentation (0°).
3. Configure the standard table for connection types
In the StandardDB: |@3D|01|BC|02 Connection types
Scripts for symbols of connection types are stored in this standard table.
If necessary, select the row of the desired connection type and customize its
symbol for the ISO diagram type.
Example: Flanged end connection type:
Point of origin of CP# Point of origin of CX#
The flanged end has two connector points:

• CP#:
Connector point for dimensions

• CX#:
Connector point for the secondary component, which is defined through the
connector table and is created when placing the primary component.
4. Base object of the blocking valve: Configure symbol:
Base object of the blocking valve, Symbols tab: Open the Symbol Designer
and design the component symbol for diagram type ISO :
Add logical connector point for the point of origin:
Add connector points at which the connection types and contact faces will be
inserted:
Marked in the above picture: The insertion point (point of origin) of the sym-
bol added via placeholder C#2.
Insert the *V*P text for tag symbol:
Marked in the above picture: The insertion point (point of origin) of the tag
symbol specified by means of the text variable.

Below you can see a schematic overview of the connector points and sub sym-
bols that will be inserted through these points.
5. Base object of the blocking valve: Configure properties:

SYSISO tab:
In the specification specified by means of the *V*P text, set the reference to
the base object of the tag symbol. On the Symbols tab of this tag object, a
symbol for diagram type ISO must have been prepared (see SECTION 53.2.3.1:
“|@ISO|A TAG SYMBOLS”).
Tab GD 3D Geometry :
Specification “VC14 Contact face 1 ”, “VC24 Contact face 2 ”, ...:
The standard table for contact faces must have been assigned to this specifi-
cation (|@3D|01|06 Contact faces). Select the desired contact face.

Specification “VC13 Connect type 1 ”, “VC23 Connect type 2 ”, ...:

The standard table for connection types must have been assigned to this spec-
ification (|@3D|01|BC|02 Connection Types). Select the desired connec-
tion type.
(Number of specifications = Number of placeholder connectors)
6. Place the blocking valve on the isometric drawing
When the valve is placed on the isometric drawing, the following takes place:
• A 3D object is created in the background. By means of the 3D connector of
the underlying 3D object, the isometric drawing determines which
connection direction the individual connectors have.
• Contact faces:
Contact faces are assigned to the placeholder connectors:
C#1 -> VC14 Contact face 1
C#2 -> VC24 Contact face 2 , etc.
For each contact face: The contact face symbol is tilted in the respective
connection direction and is placed with its point of origin on the C#
connector of the component.
• Connection types:
Connection types are assigned to the placeholder connectors:
C#1 -> VC13Connect type 1
C#2 -> VC23 Connect type 2 , etc.
For each connection type: The connection type symbol is tilted in the
respective connection direction and is placed with its point of origin on the
C# connector.
• Connected components:
• By means of the Connector table of the Pipe class management, it is
determined if connector components are to be created and if yes, which
ones (e.g. gasket and counter flange).
• On the isometric drawing (graphic):
The logical connector points (CX#) defined at the symbol of the
connection types are connected with the logical connector points of the
connected components.
• In the Navigator (database-side):
The connectors (CX1, CX2) prepared atthe base object of the valve will
be joined with the connectors of the connected component.

7. Result on the isometric drawing:
53.2.2.3.4 Tabs
The components must have specific tabs to support the basic functionality and
extended functions of the isometric drawing.
The required tabs are prepared under:
@3D|@Y Catalog specifications|CHP|PP Tabs Piping and
@3D|@PPC|@Normierung Characteristics
The base objects from the component catalog inherit these catalog tabs. The
inherited attributes are then configured at the base objects.
53.2.2.3.5 “FT Fabrication”

Specifications PL1 Adjusting length up to PL<N> (in the StandardDB: up
to PL4 ).
These specifications store the adjusting size of a component (i.e. of its legs).
The value is set in spool documents. See Set adjusting length, P. 53-53.
53.2.2.3.6 “GD 3D Geometry”

Catalog tab: @3D| @Y|CHP|PP|10 up to ...|91

Provides the component with the 3D geometry. For all 3D-relevant attributes,
the 3D mode must be activated: Properties window of the specification, tab
Link , 3D Mode: On .
The specifications on this tab must be available, so that the 3D model is gen-
erated correctly in the background of the isometric drawing.
Some specifications (nominal diameter, connection type, etc.) are also impor-
tant as regards the pipe class management.
Miscellaneous
• VSTD System standard :
Assigned standard table: @3D|01|NSYS System standards
When switching from one standard system to another one, this specification,
in combination with the |@3D|@PPC|@Normierung node, ensures that the
values of the 3D attributes are converted correctly.
• UseSymbolOnly In the report: only use request symbol :
Not relevant for isometric drawings; only relevant if PPC objects are already
used in the background during the P&ID planning phase. See the
documentation FD Interaction P&ID - PPC - 3D.
• VPCL PCL :
Mandatory field. Assigns the object to a pipe class.
3D mode: On
• VFLG Flange standard system :
3D mode: On
• WMF : Drawing for the component dimensions
Display type: Image selection
“General” input group

• GD.VGEO Geotype
Mandatory field. The attribute is evaluated when the drawing procedure that
generates the component in the 3D model is invoked.
3D mode: On
• GD.VFCD Function Code
Mandatory field. Assigns the object to a group of similar objects. Is used
during pipe class allocation and for identifying an object type in the code.
Assigned standard table: @3D|01|BC|01|03 Function code

3D mode: On
• LAYER Layer
Optional. Determines a group of objects that are displayed and hidden
together in the 3D space. Assigned standard table: @3D|00|Layers Levels.
3D mode: On
• VCOL Color
Optional. Determines the color with which the component is shown in the
3D space.
3D mode: On
• Unified Code :
3D mode: On
“Nominal diameter/ Connect type straightway” input groups

Component-dependent. Separate input groups for main passage (pipe run) and
the branch. Are, for example, evaluated in the Pipe class management (con-
nector table, branch table).
• “VC11 NW1 ”: Nominal width 1
“ VC21 Nominal diameter 2 ”, ...
Assigned standard table: @3D|01|05 DN Nominal Pipe Size
• “VC12 NominalPress 1 ”, “VC22 NominalPress 2 ”, ...
Assigned standard table: @3D|01|04 PN Nominal pressure
• “VC13 Connect Type 1 ”, “VC23 Connect Type 2 ”, ...
Assigned standard table: @3D|01|BC|02 Connection types
Scripts for the connection types are stored in this standard table. On placing
the component, the script from the selected entry of the standard table will
be evaluated, so that the connection type is added to the component symbol
(see SECTION 53.2.2.3.3: DESIGNING SYMBOL).
• “VC14 Contact face 1 ”, “VD24 Contact face 2 ”, ...
Assigned standard table: @3D|01|06 Contact faces
Same as the connection types
• “VD13 Bolting ”, “VD23 Bolting ”, ...
Assigned standard table: @3D|01|BC|03 Bolting types
3D mode: On

“General Geometric Description” input group

Specifications for diameter, length, part length and CompAngle etc.
3D mode: On
“Additional and Alternative Connect Description” input group

3D mode: On, provided that the specification is calculated on generating the
3D model.
Controlling the menu dynamically

Each component base object can have a VSUI specification, type: Input field.
In the XValues of VSUI , the names of other specifications are entered. When
a component is selected on a report, the XValues of VSUI are read and the
specifications entered there are added as fields in the VSUI bar of the report.
In the StandardDB, the specification is not placed on the tab; it can only be
viewed and configured via the Navigator.
53.2.2.3.7 “SYSISO System Information”

Catalog tab: @3D|@Y|CHP|PP|A0 General tabs|SYSISO
With the help of the attributes of the SYSISO tab, isometric-specific func-
tions are controlled in the interactive report.
All specifications for the tag symbols must be located on this tab.
“Pos no. Isometric” input group

SYSISO.GT[Number] Practice [Number]
On the isometric drawing, tag symbols can be added to the component sym-
bols. (For more detailed information on tag symbols, see SECTION 53.2.3.1:
“|@ISO|A TAG SYMBOLS”.)
The specifications from this group define which base objects are to be used to
generate the tag symbols.
The base objects of the tag symbols are located in branch @ISO|A Tag sym-
bols.
Where the tag symbol will be added on the component symbol is determined
by a *V*P text. (See Anchor points for tag symbols, P. 53-8.)
“SYSISO.IPOS Position no. ”

Stores the position number of the component. Since this specification is

accessed by the system, the position number must not be saved in another
specification, nor must this specification be renamed.
Use:
The position number is read on the isometric drawing in the bill of material.
In addition to that, the following tag symbols from the StandardDB also read
the value that is saved in the SYSISO.IPOS attribute of their associated com-
ponent:
|@ISO|A|06 Position number, ...|09 Welding points, ...|01 Seals.
Generation:
The position number can be set manually (usually on the base data) or by the
system (in the report template: PositionNrAutoOn = TRUE). More on this in
SECTION 53.2.3.1.4: “...| 01 SEAL”, “...| 06 POSITION NUMBER”, “...| 09 WELDING POINT”.
Can also contain the value of the specification VDM.N.N4 BTRN (see
SECTION 53.2.2.3.9: “VDM DATA SHEET”).
“Measurement rules Isometric” input group

SYSISO.DIM2 Measurement type 1,
SYSISO.DIM3 Measurement type 2 ,
SYSISO.DIM4 Measurement type 3
Various dimension types are defined for isometric drawings. When dimen-
sions are generated automatically (through the mouse context menu |DIMENSI-
ONS |CREATE of the isometric drawing), these specifications will be evaluated.
They determine if a dimension will be generated for this component, and if
yes, which anchor points they have.
Which specification is evaluated for which mouse context command is con-
figured in the Options script of the report template:
Through the DimLevels variable. (See DimLevels, P. 53-30.)
The following notation is used for defining the anchor points:
-: Continuous dimension line

0, 1, ...: Anchor point is connected to the logical connector
Number CX0 (point of origin), CX1 etc.
P1, P2, ...: Anchor point is connected to the physical connector
Number CP1 etc.

Example:
@3D|@PPC|@CTS|1|21|1|01 WeldElbows:
SYSISO.DIM3 : -0-
SYSISO.DIM4 : P1-0-P2
If these specifications are missing or are blank, the anchor points are set in
dependence on the connection types (see SECTION 53.2.4.2: “|@3D|01|BC|02 CON-
NECTION TYPES”).
For more information on managing and generating dimensions as well as their

preconfiguration in the StandardDB, see the Quickstart Isometric documenta-
tion.
53.2.2.3.8 “VTX Texts”

Catalog tab: @3D|@Y|CHP|PP|A0 General tabs|VTX
These attributes are configured by the base data administrator in the base
object project, generally by means of TValue calculation formulae. These for-
mulae dynamically determine such attribute values that are assigned only dur-
ing the construction phase (e.g. the nominal pipe size of a pipe or the building
angle of the pipe bend). These formulae are then evaluated in the planning
project.
53.2.2.3.9 “VDM Data sheet”

Catalog tab:
@3D|@PPC|@Normierung|CatTab|VDM|1 for DIN and ...|2 for ANSI and
...|3 High pressure METRIC|...
List specification “V NomPipeSize Dependent Table ”:
• Manages properties of the component in dependence to the nominal
diameter.
• Column N BTNR :
The component number that was entered for the nominal diameter currently
set for the device is written to the “SYSISO.IPOS Position no. ”
specification if:
• the SetPositionNr function is available at the base object of the tag
symbol |@ISO|A|06 Position number, UserScriptBlock1.
• in the options script of the report template: PositionNrAutoOn = FALSE

53.2.3 “|@ISO” node
53.2.3.1 “|@ISO|A Tag symbols”

Tag symbols can be added to a component on the isometric drawingsometric
drawing, and map additional information on this component.
The base objects of the tag symbols have the Data set class, None sub class.
Objects of this class can be placed on a drawing and will be saved as report
element; however, objects of this class are not available in the Navigator in
the planning view.
53.2.3.1.1 Creating tag symbols

Tag symbols can be created in two ways:
• Manually: Drag the base object of the desired tag symbol from the
Navigator onto the isometric drawing.
Prerequisite:
Base object of the
tag symbol, ISO ISO tab,
ISO.DRAGGING_ENABLED specification:
Not available or set to TRUE.
Recommended setting:
deactivated for ...|01, ...|06, ...|09 (default in StandardDB).
• By means of the mouse context menu of the isometric drawing:
If the report template, the properties of the isometric drawing and the base
objects of the components are configured accordingly, the tag symbols can
be created (and deleted) by means of the mouse context menu of the
isometric drawing:
|LABELING SYMBOLS|CREATE|... and ...|DELETE|...
(See GraficalTexts, P. 53-33, 53.2.3.5: “|@ISO|O|ISO DOCUMENTS”
SECTION and
SECTION 53.2.2.3.7: “SYSISO SYSTEM INFORMATION”.)
The StandardDB is configured in such a way that the tag symbols for
position numbers, welding points and gaskets can be created via the mouse
menu. The mouse menu can be extended so that the other tag symbols can
be created with it as well.
In the symbol of the allocated component, a text variable is used to specify
where in the component symbol the tag symbol will be added. If this variable
is missing, the tag symbol is always placed at the center. (See Anchor points for
tag symbols, P. 53-8.)

53.2.3.1.2 Configuring base objects

Define form and content of the symbol at the base object of the tag symbol.
Form:
• Symbols tab, ISO drawing type:
The tag symbol is defined here.
• “ISO ISO ” tab, “ISOMETRIC Display isometrically ” specification
Deactivated: The symbol is always shown from front.
Activated: The symbol is rotated in space. The alignment of the tag symbol
can no longer be changed with its grab point.
Available for:
...|01 and ...|09: If created with the mouse menu.
...|02 and ...|05: If the tag symbol is placed on an object that has the Pipe
geotype (specification GD.VGEO).
Content:
• Symbols tab: ISO drawing type:
With a text variable that determines which specification of the component
is evaluated by the tag symbol.
• “ISO ISO ” tab, “BOMKEYENABLED Consider compression ”
specification:
Only relevant for ...| 01 Seal, ...|06 Position number and ...|09
Welding point. See SECTION 53.5: TAG SYMBOLS FOR POSITION NUMBERS.
53.2.3.1.3 Modifying tag symbols

The distance and the position to the component can be adjusted with the grab
points of the tag symbols. Right-click twice on the symbol and drag the
square, gray grab point to the desired location:
The tag symbol remains connected with the symbol of its component. When
the component is moved, it will be moved along with it.

53.2.3.1.4 “...| 01 Seal”, “...| 06 Position number”, “...| 09 Welding point”

See SECTION 53.5: TAG SYMBOLS FOR POSITION NUMBERS.
53.2.3.1.5 “...|02 Equipment”

With the %N text below, reads the description that was entered for the allo-
cated device on the VTX Text tab:
%N ComosDevSpec('VTX', 'VST01', 'displayvalue')%
Is not available in the StandardDB in the mouse context menu of the isometric
drawingsometric drawing. Must be created manually. Can only be placed on
pipes.
53.2.3.1.6 “...|03 Flow direction”

Must be created manually in the StandardDB. Can be placed only on pipes.
ISO tab, Isometric specification: activated
The flow direction arrow is automatically aligned into the flow direction:
53.2.3.1.7 “...|04 Mounting tags”

Reads the position number:
%N ComosDevSpec('SYSISO', 'IPOS', 'displayvalue')%
53.2.3.1.8 “...|05 Nominal diameter/Pipe class”

Must be created manually in the StandardDBStandardDB. Can be placed only
on pipes.
Reads the current nominal diameter and pipe class set at the component:

DN %N ComosDevSpec('GD', 'VC11', 'displayvalue')% / RK %N

ComosDevSpec('GD', 'VPCL', 'displayvalue')%
53.2.3.2 |@ISO| B Constr. symbols
53.2.3.2.1 “...|01 Wall breakthrough”

Symbol for a vent.
Class : Data set
Subclass : None
Can be rotated in space:
ISO tab, ISOMETRIC specification: activated.
53.2.3.3 “|@ISO|C Spool symbols”

The base object for the spool marks is in this branch:
@ISO| C| 01 Spool mark
The following pages explain how to configure the base object of the spool
mark.
Working with spool marks on the isometric drawing and interaction between
isometric drawing and spool documents are described in SECTION 53.6: SPOOLS.
“General” tab
Class : Data set
Subclass : None
Effect:
The spool mark is created only as report element, not in the Navigator.
“ISO ISO” tab

This tab has the following specifications:
• “DRAGGING_ENABLED Permit drag&drop”:
Controls whether the tag may be dragged from the base data onto the
diagram.
Must be at FALSE, since spool marks should be created from the mouse
context menu only.

• “AUTO_MANUFACTORING Create installation diagram automatical-

ly”:
Is checked when the spool document created for this spool mark is opened
for the first time.
TRUE:
For each piping component that is located on the spool document, it is
checked whether the base object of this component is an owner of a
fabrication document (definition of fabrication diagrams: By means of
specification ISO.FTZ_TEMPLATE, see below). If yes, the fabrication
diagram is copied into the planning view under the component.
FALSE:
The fabrication drawings must be created manually. Select a component on
the spool document, mouse context menu, |FABRICATION DRAWING|CREATE.
Default: FALSE
• FTZ_TEMPLATE Template for installation diagram:
On automatic creation and deletion of fabrication drawings, only the
documents whose report templates are located under the document group
folder referenced here are considered.
In the StandardDB:
@CRp|@ISO|PBT Device drawings
The PBT.1 Fabricationdraw report template is prepared under this
document group.
See ISO.AUTO_MANUFACTORING.
• FunctionCodeRanges Function code range:
Input field that is evaluated when generating the spool mark by means of the
mouse context menu of the isometric drawing. It defines which components
are valid boundaries (stop components) of a closed construction drawing.
The components are identified by their function code.
Both individual function codes and function code ranges can be entered.
Example: “31000-32999;41100;41210-41230”
An overview of the function codes is given in the following standard table:
@3D |01 Piping|BC Basic lists|01 Components|03 Functionscode
• ISOMETRIC Display isometrically:

Must be at FALSE, so that you can recognize the direction of spool marks
better. The mark is not rotated in space, rather is always depicted from front.
• REFLECT_ALLOWED Permit mirroring:
Must be at TRUE. Otherwise, the spool direction can no longer be adjusted
on manually moving a mark.

• SpoolDocTemplate Template for Spool:

Reference to the report template that is used for the spool documents.
Value:
CRp|@ISO|PISO.3 Isometric DIN A3
“Symbols” tab
In the StandardDB, a symbol is prepared for a spool mark for the ISO drawing
type.
The symbol is always added at the physical connection points (CP connectors)
of the components defined as start and end component.
53.2.3.4 “@ISO|D|01 Check symbols”

This object can be “appended” to any object on the isometric drawing. Then,
all check-relevant information is stored under the check object, e.g. check
reports.
On the report, check objects behave similar to tags. However, unlike “regular”
tags, an object is generated in the database (in the Navigator) and a DocObj
beneath it. Prerequisite for this:
General tab,
Class = Data set
Subclass = Component
“ISO ISO” tab

DRAGGING_ENABLED Permit drag&drop
Checkbox must be activated, since otherwise the check object cannot be
dragged from the base data onto the diagram.
ISOMETRIC Display isometrically : not relevant.
“Symbols” tab
ISO drawing type: Define a symbol for the check object. Insert any text vari-
ables that display more exact information on the object with which the check
object will be linked.
53.2.3.5 “|@ISO|O|ISO documents”

Base object for isometric drawings (construction isometrics and spools).

“GT GT” tab

Specification GT1 , ..., GT6 : Relevant in the context of tag symbols.
Type : input field.
The text entered here is read in the options script of the report template and is
offered in the mouse context menu of the isometric drawing, under
| LABELLING SYMBOLS|CREATE| .... .
What happens when the mouse context menu is called is determined in the
options script of the report template, with the GraficalTexts variable. See
GraficalTexts, P. 53-33.
“BOM BOM” tab

Specification BOM1 , ..., BOM8 :
Are evaluated in the bill of material script. The bill of material is sorted by the
component groups entered here.
Type : Input field.
“SPOOLS SPOOLS” tab

Specification SPOOLSIGN Spool mark :
Reference to the base object for spool marks. (Is read when the |SPOOL|SET
SPOOL MARK command is called in the mouse context menu of the isometric
drawing.)
See SECTION 53.6: SPOOLS.
“SYSISO SYSISO” tab

NA_ANGLE Angle for North sign :
Self-explanatory. Assigned standard table: |@SYSTEM|@NORTHARROWANGLE.
NORTHARROW North sign :
Determines the display of the north arrow. Assigned standard table:
|@SYSTEM|@NORTHARROW.
SLOPEINPUTTYPE Type of slant input :
Self-explanatory. Assigned standard table: |@SYSTEM|SLOPEINPUTTYPE.
See SECTION 53.4: SLOPE.
The Isometric module uses standard tables from the following branches:

• |@SYSTEM:
The tables from this branch must not be deleted, extended or changed.
• |@3D 3D/ISO Catalog:
The tables here must not be deleted. However, some can be extended.
The standard tables that are of special significance for the Isometric module
are described in the following chapters.
53.2.4.1 “|@3D|01|PC|01|03 Functionscode”

Helps in pipe class allocation and identifying an object type in the code.
Name :
Equals Value1 .
Description :
Appears in the dropdown menu.
Value1 :
The function code. Must be five-digit.
Value2 and Value3 :
Used internally.
Is used as part of the Isometric module:
When defining a pipe class (SECTION 53.8.2: “DEVICES” TAB), in the component
properties SECTION 53.2.2.3.6: “GD 3D GEOMETRY”, when defining the stop com-
ponents for spools (SECTION 53.2.3.3: “|@ISO|C SPOOL SYMBOLS”).
53.2.4.2 “|@3D|01|BC|02 Connection Types”

Column Name , Value1 to Value4 :
Used within the system or reserved for internal use (Value2 column). The
values entered here must not be changed.
Column Value 5:
Define anchor points for the dimensions (component length). Physical con-
nector points are entered here.
Column Drawing type :
In this column, symbol scripts for connection types have been defined for the
ISO diagram type. See SECTION 53.2.2.3.3: DESIGNING SYMBOL.
Columns Value6 to Value10 :
Available for free use.

53.2.4.3 “|@3D|01|06 Contact faces”

Columns Name , Value1 to Value3 :
Used within the system or reserved for internal use (Value2 column). The
values entered here must not be changed.
In this column, symbol scripts for contact faces have been defined for the ISO
diagram type. See SECTION 53.2.2.3.3: DESIGNING SYMBOL.
Columns Value4 to Value10 :
Available for free use.
53.2.4.4 “|@SYSTEM| @NORTHARROW”

Symbol scripts for different representations of the north arrow on the isomet-
ric drawing are available here.
Column Value1 :
The value that is used internally.
The standard table is assigned to the base object of the isometric drawing,
SYSISO tab, NORTHARROW specification.
53.2.4.5 “@SYSTEM|@NORTHARROWANGLE”
Determines the angle of the north arrow on an isometric drawing.
Column Value1 :
The value that is used internally.
The standard table is assigned to the base object of the isometric drawing,
SYSISO tab, NA_ANGLE specification.
53.2.4.6 “@SYSTEM|SLOPEINPUTTYPE”
Defines the following three types of slope details: Percentage, Degree, Ratio
Columns Name , Description , Value1 : Used internally by the system.
The standard table is assigned to the properties of the isometric drawing ,
SYSISO tab, SLOPEINPUTTYPE Type of slant input specification.

Isometric module Report/ Data sheet
53.3 Report/ Data sheet
53.3.1 Report template
Construction isometrics and spool isometrics use the same report template in
the StandardDB:
Base project, Documents tab:
CRp|@ISO|PISO.3 Isometric DIN A3.
General properties of the report template

Type : Report template (interactive)
Base object : @ISO|O|ISO Documents
Tabs
See SECTION 53.2.3.5: “|@ISO|O|ISO DOCUMENTS”.
53.3.2 Configure report template
The following variables are available in the options script:
Application
Application = ISO
Enables the basic functions.
D3toIsoAutoOn
D3toIsoAutoOn = TRUE
Generates an isometric drawing from a 3D drawing. Must be at False, if you
are going from an isometric drawing to 3D.
SymbolType
SymbolType = “ISO”
Sets the diagram type.
IsoEnabled
IsoEnabled= TRUE
Switches the Connection tool to the technology required for the isometric
drawings.

Report/ Data sheet Isometric module
SymbolRotationByDimension
Initial situation:
Mark a dimension by right-clicking twice. Its grab points will be displayed.
At the same time, the dimensions and components framed by it will be
marked.
SymbolRotationByDimension = TRUE
If you change the alignment of the selected dimension with its round green
grab points, this also changes the alignment of all symbols for which the fol-
lowing applies:
• the symbols are framed by the selected dimension (components and
dimensions) and
• the symbols have the same alignment as the selected dimension.
Use the round gray grab point, to only rotate the originally selected dimen-
sion.
SymbolRotationByDimension = FALSE
The framed components do not rotate.
DimLevels
Evaluated when generating dimensions automatically (mouse context menu
of the isometric drawing: |DIMENSIONS|CREATE|...).
Standard configuration in the DB:
Dim DimLevels(3)
DimLevels(0)="SYSISO.Dim" & "|" &"1;2"
DimLevels(1)="SYSISO.Dim" & "|" &"3"
DimLevels(2)="SYSISO.Dim" & "|" &"4;5"
Effect of the script:

• The dimension types defined in Comos are assigned to the dimension levels.
• Main dimension/Level 1 (DimLevels(0)):
Type 1: Space offset dimension, Type 2: Length, pipe
• Part dimensions Level 2 (DimLevels(1)):
Type 3: Position dimension
• Part dimensions Level 3 (DimLevels(2)):
Type 4: Length, component, Type 5: Length, connections
• The components can have specifications defining the anchor points for the
dimension types.

The script determines which specification will be evaluated if the mouse

context menu is called for the corresponding dimension level.
The StandardDB is configured in such a way that the SYSISO.Dim[Number]
specification is used. These specifications are already available in the base
data (see SECTION 53.2.2.3.7: “SYSISO SYSTEM INFORMATION”).
More information on dimensions is given in the Quickstart Isometric docu-
mentation.
MainDimensionAutoOff
MainDimensionAutoOff = TRUE
If False:
The dimension types assigned to the dimension level 1 are created automati-
cally when drawing the pipes (in the StandardDB: length of pipe, space offset
dimension, coordinate tags).
DimensionTextHeight
DimensionTextHeight = 4.0
Determines the font size of the dimension values.
PositionNrAutoOn
Is evaluated when the following tag symbols are generated on the construction
isometric drawing via the mouse context menu (these tags all read the position
numbers of their component):
@ISO|A|01 Seal, ...|06 Position number and ...|09 Welding point
If separate report templates are to be used for construction isometrics and

spools, PositionNrAutoOn must be set to FALSE in the spool template. Oth-
erwise, in certain cases, the position numbers generated before by the con-
struction document will be overwritten by the spool document.
As long as such tag symbols exist on the isometric drawing, the position num-
bers are also displayed in the bill of material.
• PositionNrAutoOn = TRUE:
For all components that have no tag symbol yet, position numbers are
generated automatically. If a component already has a position number, it is
overwritten.
The numbers are written to the following specification of the components:
SYSISO.IPOS Position no.

If the compression key is activated, components with the same key receive
the identical position numbers. See BOMCompressionKeys, P. 53-32.
• PositionNrAutoOn = FALSE:
(Default)
The position numbers are issued by the user (either in dependence on the
nominal diameter, or the same number for all nominal diameters).
For detailed information on the tag symbols see SECTION 53.2.3.1.4: “...| 01 SEAL”,
“...| 06 POSITION NUMBER”, “...| 09 WELDING POINT”.
When the variable must be TRUE and when FALSE, is described in

SECTION 53.5.3: GENERATION MODES FOR POSITION NUMBERS and SECTION 53.5.4: POSSI-
BLE CONFIGURATIONS.
PositionDefaultStartNr
Start number for the automatic generation of position numbers (Default = 1).
Is equal for all number ranges (tag symbols for position numbers, welding
points and seals).
PositionDefaultStep
The increment for the automatic generation of position numbers (Default = 1).
Is equal for all number ranges.
PositionIsMissingAliasNr
Number that is entered in the bill of material if a component does not have a
position number. (e.g. -999)
BOMCompressionKeys
Defines a compression key for the bill of material entries. That is, components
that have identical values in the specifications defined here, will be summed
up in one row in the bill of material.
If PositionNrAutoOn = TRUE, the compression key can also have effects on
the automatic generation of position numbers (see below).
In the options script, the following compression keys are already preconfig-
ured:
• Pipe class, nominal diameter and designation:
Dim BOMCompressionKeys(3)
BOMCompressionKeys(0) = "GD.VPCL|VALUE" ' Pipe class
BOMCompressionKeys(1) = "GD.VC11|VALUE" ' Nominal diameter
BOMCompressionKeys(2) = "VTX.VST03|MEMO" ' Designation

If PositionNrAutoOn = TRUE, all components with identical compression

key have the same position number.
• Position number:
Dim BOMCompressionKeys(3)
BOMCompressionKeys(2) = "SYSISO.IPOS|VALUE" ' Position no.
Attention: For this compresion key, PostionNrAutoOn must be = False.

The setting of the options script can be overwritten at the base objects of the
tag symbols. That is, components can be removed from the compression
through the base objects of the tag symbols ...| 01 Seals, ...|06 Position
number and ...|09 Welding point. See SECTION 53.5: TAG SYMBOLS FOR POSITION
NUMBERS.
The configuration options available in connection with the position number

are described in SECTION 53.5.4: POSSIBLE CONFIGURATIONS.
GraficalTexts
The script below controls:
• Which tag symbols are offered in the mouse context menu of the isometric
drawing.
• When one of the mouse menus is called: Which specification of the
components will be evaluated to determine the base object of the tag
symbol.
• Which label the report element of the tag symbol receives for system
internal usage.
Dim GraficalTexts(5)
GraficalTexts(0) = "SYSISO.GT1" & "|" &

Document.Spec("GT.GT1").Displayvalue & "|" & "Type=Position"

Document.Spec("GT.GT2").Displayvalue & "|" & "CON=1;
Type=Weld"

Document.Spec("GT.GT3").Displayvalue & "|" & "CON=1;
Type=Gasket"

Document.Spec("GT.GT4").Displayvalue

Document.Spec("GT.GT5").Displayvalue

The script provides Comos with the following information:

• Document.Spec("GT.GT1").Displayvalue:
The display value entered at the base object of the isometric drawing in the
stipulated specification is offered in the mouse context menu. Must be
configured accordingly.
• SYSISO.GT1:
If one of these mouse context command is called, Comos verifies for each
component that placed on the isometric drawing whether it has a
specification of the same name (type: reference) on the SYSISO tab.
The specification must contain a reference to the base object of the desired
tag symbol. A DocObject of the tag symbol is created and its symbol script
is executed.
• [Label]=[Value]:
Label used by the system, specifying the DocObject created more precisely.
For position numbers: DocObject of “Position” type.
If separate report templates are to be used for construction isometrics and
spools, GraficalTexts must be commented in the spool template.
53.3.3 Working with the isometric drawing
Construction isometrics
The following topics are described in the Quickstart Isometric documenta-
tion:
• Create an isometric
• Structure of an isometric drawing:
Menus, Construction are, Bill of material, Drawing header
• Draw pipe run:
Preparatory steps/preferred components, draw in axis direction and in
special direction, set branch
• Place components:
Preparations/preferred components, eccentric components, fittings, branch
components, special components, connection components
• Enter component data
• Dimensions:
Dimension types, dimension levels, manually or automatically create
dimensions, fully define isometric drawings, calculate the isometric
drawing

• Create tag symbols

• Optimize geometry
• Isometric drawing to 3D
For information on setting slopes: see SECTION 53.4: SLOPE.
Information on generating position numbers: see SECTION 53.2.3.1.4: “...| 01
SEAL”, “...| 06 POSITION NUMBER”, “...| 09 WELDING POINT”.
Spool documents
See SECTION 53.6: SPOOLS.
53.3.4 Bill of material
In the StandardDB, the report template is configured in such a way that a bill
of material is automatically shown on the isometric drawingsometric drawing.
The structure of the bill of material varies depending on the configuration of
the report template.
The bill of material contains all bill of material relevant components that were
placed on the isometric drawing.
Excluding a component from the bill of material

Select the component and in the mouse context menu, select | BILL OF MATE-
RIAL RELEVANT| NO. The information is saved for the component DocObject.
“Pos” column
This column reads the position number stored at the component in
SYSISO.IPOS.
If the position number is blank, the error number entered in the option script
is mapped (PositionIsMissingAliasNr).
This also applies if in the options script, the PositionNrAutoOn variable is at
TRUE. Thus, updating the bill of material does not lead to generation of a posi-
tion number for components that still have no position number.
“Quantity” column
Shows the number of components. If no compression key is activated, “1” is
always entered here.
For pipes: Reads the pipe length from the GD tab. If the compression key is
activated, the length of the pipes summed up in one row are be added up.

Slope Isometric module
“Designation” column
The text entered at the components in the VTX.VST03 Designation text
specification appears here. This specification will usually be set in the base
project by the base data administrator, generally using TValue calculation for-
mulae.
These formulae dynamically compute the values of specifications that are s
pecified only during the construction phase (e.g. the nominal pipe size of a
pipe or the construction angle of a pipe bend). These formulae are then eval-
uated in the planning project.
Compression key
In the options script of the report template, you can determine which specifi-
cations to use as compression keys. All components that have the same values
for these specifications will then be summed up in one row in the bill of mate-
rial (e.g. pipe class, nominal diameter and bill of material designation). The
bill of material becomes shorter and clearer.
Classifying list by component types

In the StandardDB, the report template is configured in such a way that the
bill of material is sorted by component types. All components of the same
type will be listed under the corresponding heading.
Updating bill of material

The bill of material is re-evaluated as soon as the isometric drawingsometric
drawing is opened or the icon [REEVALUATE DOCUMENT] is pressed.
53.4 Slope
Definition
A pipe with slope is a pipe in X/Y direction with such a slight inclina-
tion/slope in the Z-axis that it still classified as a horizontal pipe, and not as a
pipe drawn in a special direction.
Creating slope and entering value

A slope can be defined only for horizontal pipes (drawn in X/Y direction).
The slope is defined for dimensions of level 1 (main dimension):
• Select the dimensions of level 1 that are to receive a slope.

Isometric module Slope
• Mouse context menu | OPTIONS| SHOW SLOPE:
The menu exists only for dimensions of level 1.

Result:
• The slope is displayed for the dimensions:
• Direction of slope:
Is indicated by an arrow. The slope is always shown at that end of the
dimension line into which the slope goes.
The dimension was created with the mouse context menu:
Direction of slope is the same as the pipe construction direction.
The dimension was created manually:
Direction of slope is the same as the dimension construction direction.
• Value of slope.
As initial value “0” is entered (no slope).
• A text field G is shown in the menu bar of the isometric drawing. Enter the
slope and confirm with [!]:
Depending on the settings of the isometric drawing (Properties: SYSISO

tab, “SLOPEINPUTTYPE Type of slant input ” specification), the slope
is specified in percentage (Default), in degree or by entering a ratio.
Which detail is active can be identified by the sign that is added to text field
label (G % , G° , G/ ).

Slope Isometric module
• The length of the dimension is not changed by the slope, as the dimension
is a projection onto the pipe level.
The concrete value of the slope must be entered separately for each dimen-
sion:
• Select dimension.
• Enter the slope value and confirm with [!].
Maximum value (not parameterizable):
Percentage: 17.632 %
Degree: 9,999 °
Ratio: 17,632/100
• The new value is shown next to the old one:
0%->10%
Changing the slope direction

The slope direction is changed by changing the sign.
Example:
The isometric drawing was calculated with the [CALCULATE] icon, the pipe
runs along the Y-axis. Slope direction: left to right:
Direction change:
• Select dimension
• Enter the new value and place a minus sign before the value (e.g. “-5”).
Confirm with [!]:

Isometric module Tag symbols for position numbers
• The slope direction is turned around. I.e. the arrow now points in the other
direction and the slope is displayed at the other end of the dimension.
To clarify that the old value had another direction, a minus sign is placed
before the old value.
• On calculating the isometric drawing, the new value is written to the
dimension:
• During calculation, Comos conducts a consistency check. Inconsistencies in

slopes are detected, e.g. if two dimensions were drawn for a pipe branch,
and they have an opposing slope. The calculation is cancelled, an error
message is displayed and the dimension with the inconsistent slope is
marked in red.
53.5 Tag symbols for position numbers
53.5.1 Overview
The tag symbols with the following base objects all read the position number
of their component:
• @ISO|A|01 Seals
• ...|06 Position number
• ...|09 Welding point

Tag symbols for position numbers Isometric module
This is done in the symbol of the tag object, by evaluating the following text
variable:
%N ComosDevSpec('SYSISO', 'IPOS', 'displayvalue')%
The position number of the component must be saved in SYSISO.IPOS , as

this specification is accessed also on system side.
As soon as the IPOS value changes, the value that is in the tag is updated as
well.
These tags should only be created via the mouse context menu. To do that:
• the options script of the report template, the base objects of the components
and the properties of the isometric drawingsometric drawing must be
configured accordingly (see GraficalTexts, P. 53-33 ).
• at the base object of
the tag symbol, ISO ISO tab,
ISO.DRAGGING_ENABLED specification:
Must be deactivated.
General information on tag symbols in SECTION 53.2.3.1: “|@ISO|A TAG SYMBOLS”.
53.5.2 Allocated components
When the tag symbols are generated via the mouse context menu, they are cre-
ated for the following components:
• ...|06 Position number:
Is generated for all components that are placed on the isometric drawing,
have a DocObj in the Navigator and are bill of material relevant. Following
components thus get no tag:
• Components that were set to not bill of material relevant.
• Some components that, on placing another component, were
automatically created with it through the connector table.
Example:
A flange is placed on a pipe on the isometric drawing, both components
have a butt weld end as connection type. The pipe class is configured in
such a way that the pipe and the flange are linked with one another
through a welding.
Result: The welding is created in the Navigator under the flange, but
receives no independent DocObj, rather hangs on to the DocObj of the
flange. (It is selected automatically with the flange) The welding receives
no tag symbol with the base object 06 Position number.

If the welding was dragged onto the isometric drawingsometric drawing

from the symbol bar , it would have an DocObj of its own and therefore
would receive a tag symbol.
• ...|01 Seal:
Is generated only for components that are placed on the isometric drawing
and whose function code is in the range 42000 to 42999. Whether the
component has a separate DocObj and is bill of material relevant does not
matter.
• ...|09 Welding point:
Is generated only for components that are placed on the isometric drawing
and whose function code is in the range 45100 to 49999. Whether the
component has a separate DocObj and is bill of material relevant plays no
role.
53.5.3 Generation modes for position numbers
The position numbers on the components can be generated in different ways:

automatically or manually, as well as with or without compression key.
Note:
The selected generation mode should not be changed in the middle of the
project, as this can lead to additional work during data maintenance (post-pro-
cessing of position numbers).
53.5.3.1 Automatic vs. manual generation

automatic:
• Report template: PositionNrAutoOn = TRUE
• If the tag symbols are created from the mouse context menu, Comos verifies
for each component if the component already has a tag symbol on the
drawing:
The component already has a tag:
The value entered in IPOS is read. If IPOS is empty, the tag remains empty,
too.
The component has no tag:
A new position number is generated (possibly already existing IPOS value
is overwritten). A tag symbol is created. The tag reads the number.

• A separate number range is managed for the three tag symbols. However,
all number ranges use the same rules for generating the numbers, i.e. they
have the same start number and increment (see PositionDefaultStartNr, P. 53-32
and PositionDefaultStep, P. 53-32).
• The component from the beginning/end of a pipe run was selected when
calling the context menu:
The components of the complete pipe run are numbered, beginning with the
selected component. Branches are excluded.
• A component connected to a branch component was selected when calling
the context menu:
Only that part of the pipe run that is between this component and the
beginning/end of the pipe branch is numbered (away from the branch).
• No component selected (context menu is called for the isometric drawing):
all the components on the isometric drawing are numbered.
• The same applies to automatic deletion (mouse context menu |LABELING
SYMBOLS|DELETE|...).
• If the compression key is activated, components with the same key receive
the same position number. (See SECTION 53.5.3.2: COMPRESSION KEY.)
manual:
• Report template: PositionNrAutoOn = FALSE
• The user enters the number at the component assigned to the tag symbol
(into the specification SYSISO.IPOS). Usually, this will be done in the base
data.
Special case:
The position number is issued manually, but depending on the nominal diam-
eter.
Prerequisites:
• PositionNrAutoOn = FALSE
• Component properties, VDM Data sheet tab: In the nominal pipe size
dependent table (specification V ), a component number is entered for the
nominal pipe size currently selected at the device (N4 BTNR column).
• Base object of ...|06 Position number, tab Scripts: USerScriptBlock1
The SetPositionNr()function provided in the StandardDB is available.
The script evaluates the component number that is entered for the current
nominal pipe size at the allocated component and writes it into the
SYSIOS.IPOS specification:

Sub SetPositionNr (Device)
' Task: Read the position number from a table and

' place in GD.IPOS
Set ev = Workset.SpecEval
'Read spec for nominal width1

specName = "GD.VC11"
Set sp = Device.spec(SpecName)
DN1 = ev.Eval (sp, sp.Value)
If DN1 = "" Then
MsgBox "No nominal width placed"
End If
' Here is the table to evaluate for reading the

' Position number
SpecName = "VDM.V"
'msgbox Sp.value
stop
'Column "BtNr" read

Set sp = sp.Specifications.Item(4)
'Read position number = Read cell from "BtNr" column and

'"Nominal width" row
s = ev.Eval (Sp, Sp.getXValue(DN1-1))
'stop
If s <> "" Then
specName = "SYSISO.IPOS" ' Get spec for position number
sp.Value = Clng(s) ' Place the position number on Spec
End If
End Sub
53.5.3.2 Compression key

With the options script of the report template, you can issue a separate posi-
tion number for each component or use a compression key.
As regards the tag symbols, the compression key is only important if the posi-
tion numbers are generated automatically (Report template: PositionNrAu-
toOn = TRUE).
If PositionNrAutoOn is at FALSE, the compression key is only important for

the bill of material.

Activating compression key

Components that have the same values in predefined specifications receive
the same number during the automatic generation of the position numbers. In
addition, they are summed up in the bill of material in one row.
• Prerequisite:
Options script of report template, BOMCompressionKey: set. (See
BOMCompressionKeys, P. 53-32.)
• Exception:
The compression key can be disabled for individual tag symbols. See
Deactivating compression for individual base objects, P. 53-44 .
Deactivating compression key

On automatic generation of the position numbers, all components receive a
separate number (and will be listed in the bill of material separately).
Prerequisite:
Report template, options script: BOMCompressionKey: commented.
Deactivating compression for individual base objects

If the compression is activated in the report template, you can still exclude
some tag symbols from the compression:
Base object of the required tag symbol,
Properties, ISO ISO tab, BOMKEYENABLED Consider compression
specification:
deactivated (default: activated).
Effect:
All tag symbols based on this base object will be excluded from the compres-
sion.
In this way, you can, for example, deactivate the compression for welding
points and gaskets, but compress all other components.
Note:
If the compression is deactivated in the option script, it is not possible to acti-
vate it for individual tag symbols by means of this checkbox.
53.5.4 Possible configurations
As not all combinations are practical when configuring the position number,
some recommendations here.

PositionNrAutoOn = TRUE:
• Case 1:
• Report template: BOMCompressionKey:
Pipe class, nominal pipe size and designation set as compression key.
• To keep the example simple, it is assumed that all placed component
groups have the same pipe class, nominal pipe size and designation
respectively.
• Base objects of tag symbols ...|01, ...|06, ...|09:
ISO ISO tab, specification BOMKEYENABLED = True
Result:
• ...|01: all gaskets: 1
• ...|09: all welding points: 1
• ...|06: all pipes: 1, all bends: 2, all T-pieces: 3, ...
• Case 2:
Pipe class, nominal pipe size and designation set as compression key.
• It is assumed that all placed component groups have the same pipe class,
nominal pipe size and designation respectively.
• Base objects of tag symbols ...|01, ...|09:
ISO ISO tab, specification BOMKEYENABLED = FALSE
• Base object of tag symbol ...|06:
ISO ISO tab, specification BOMKEYENABLED = TRUE
Result:
• ...|01: first gasket: 1, next gasket: 2, ...
• ...|09: first welding point: 1, next welding point: 2, ...
• ...|06: all pipes: 1, all bends: 2, all T-pieces: 3, ...
• Variations for case 2:
Like case 2, but only ...|01, only ...|06 or only ...|09 excluded from
compression. Or the compression is deactivated completely.
PositionNrAutoOn = FALSE:
• Case 3:
SYSISO.IPOS as compression key.

Spools Isometric module
• At the components managed by ...|01 and ...|09, position numbers are

entered in the SYSISO.IPOS specification (in the base data) (-> equal
for all nominal widths).
• At the components managed by ...|06, nominal width dependent position
numbers are entered (in VDM.V.N4 BTNR ).
• The SetPositionNr script is available at ...|06.
Result:
• ...|01 and ...|09: All receive the preconfigured numbers.
• ...|06: The nominal width dependent numbers are set and read as position
numbers.
• In the bill of material, all components with identical position numbers are
summed up in one row.
• Case 4:
SYSISO.IPOS as compression key.
• One number for all nominal widths:
Nominal widths are entered at the components managed by ...|01, ...|09
and ...|06 (in the base data) (in SYSISO.IPOS ).
At ...|06, the SetPositionNr script must be commented, or the nominal
width dependent table must be blank.
Result:
• ...|01 and ...|09: All receive the preconfigured numbers.
• ...|06: The global number is read.
• In the bill of material, all components with the same number are summed
up in one row.
53.6 Spools
Purpose
Spool documents are derived from construction isometrics. They divide a
construction isometric drawingsometric drawing into fabrication units. The
units can then be given to service providers for implementation.
The construction isometric drawing remains the quality-relevant construction
document. It must be fully completed (i.e. fully calculated) and is locked
when generating the first spool mark.

Isometric module Spools
Note:
Technically, through detours, it is possible to make certain changes even after
generating the spool marks. Therefore, it is recommended to stick to the work-
flow described in this documentation and not to use all functions offered in
Comos (e.g. don’t use | UNLOCK mouse context menu).
Before generating a spool document, you create spool marks that define for
which area of the construction isometric document the spool applies.
53.6.1 Spool marks
53.6.1.1 Create spool marks

In the first step, generate spool marks. The marks determine for which fabri-
cation section the document will be generated. To do that, select a component
(pipe or piping component) on the isometric drawing, call the mouse context
menu and select:
|SPOOL|SET SPOOL MARK:
Determining base object for spool marks

The base object on which the spool marks are based is determined by the
properties of the construction isometric drawing:
SPOOLS tab, SPOOLSIGN Spool mark specification
In the StandardDB:
Reference to the base object |@ISO|C Spool symbols|01 Spool mark
For administration of the base object of the spool marks see SECTION 53.2.3.3:
“|@ISO|C SPOOL SYMBOLS”.

Determining the boundaries of a closed construction piping

When you call the ...|SET SPOOL MARK command, Comos automatically
searches for the natural boundaries of the selected component, to be more pre-
cise: for the boundaries of the closed construction piping to which the compo-
nent belongs.
The boundaries of the closed construction piping are defined by a specifica-
tion at the base object of the spool marks:
Tab ISO ISO , Specification FunctionCodeRanges .
The function codes of the components rated as stop components are entered
there. (For configuration of the specification, see SECTION 53.2.3.3: “|@ISO|C
SPOOL SYMBOLS”.)
Starting with the selected component, Comos begins to search for the next
stop components, i.e. for the components whose function code is included in
ISO.FunctionCodeRanges:
• First it is checked if the selected component is a stop component. If yes,

spool marks are set on the physical connectors of the component.
• If the selected component is not a stop component, the linked components
are checked, until a stop component or another spool mark is found for each
connection direction.
• If no stop component is found in a direction, the end of the pipe run is used
as end.
When a stop component is found, the entire component is always included in
the mark.
Thus, as many spool marks are generated as stop components are found.
Since in most cases two stop components will be found, the term “spool pair”
is used below to designate the spool marks belonging together. However,
cases in which more than two spool marks are generated (e.g. T-piece
selected) are also to be covered by this term.
Setting properties of the marks

After calling the context menu, the Set spool mark dialog opens:

Name
Generated automatically: “S[counter]”. Can be changed, but must be unique.
Is used as name of the relevant spool document.
Description
Can be selected freely. Is saved as Description 2 of the relevant spool docu-
ment.
After saving with [OK], the spool marks will be displayed on the diagram.
They always point in the direction of their allocated connector (i.e. from the
connector to the centre of the component).
A message box opens in which the user must explicitly confirm the generation
of the marks (or cancel it).
Status of construction isometric drawing

As soon as one spool mark has been generated for an isometric drawing, the
complete isometric drawing is set to ReadOnly.
For commenting, the user may still draw simple graphics and texts (via the
menu bar of the isometric drawing: Icons for [LINE], [ARC], [TEXT]).
The isometric drawing can be processed again only after all its spool marks
and spool documents are deleted.
Example
The command |SPOOL|SET SPOOL MARK is called for a pipe. The inlet of the pipe
is not linked, the outlet is connected to a flange.
In the base object of the spool mark, flanges are defined as stop objects:

53.6.1.2 Moving spool marks

As long as no spool document has yet been generated for a spool pair, the
marks can still be moved manually and the fabrication unit can be extended
as needed:
Select a mark and move it while holding down the left mouse button.
The marks can only be placed on physical connectors. If you touch such a con-
nection point, the connection point is colored and its component turns yellow.
The mark rotates in the direction in which the connector goes:
The mark can be connected with any component. Limitations on the function
codes that exist during the automatic creation via the mouse context menu are
lifted.
Intersections with other fabrication units are identified and prevented auto-
matically.
If the spool marks are moved manually, it can happen that a mark no longer
points in the right direction. The direction can be rotated by means of the
mouse context menu of the mark (see next chapter).
53.6.1.3 Controlling spool marks

The following commands are available in the mouse menu of a spool mark:
|SPOOL|...

• ...|DELETE
The spool pair is deleted. If there is a spool document for the marks, it is
likewise deleted.
In addition, the fabrication drawings of the components placed on the spool
document are deleted. (To be more precise: All documents that are located
beneath these components and that have the same report template as the one
referenced at the base object of the mark in the ISO.FTZ_TEMPLATE
specification.)
• ...|CREATE DOCUMENT
A spool document is created under the construction isometric drawing.
Document properties: see SECTION 53.6.2.2: PROPERTIES OF THE SPOOL DOCUMENT.
• ...|ROTATE MARK
Is called after manually moving the mark so that it no longer points in the
right direction.
The specification ISO.REFLECT_ALLOWED must be activated at the
base object.
• ...|HIGHLIGHT
The components placed on the spool document are marked yellow. Helps in
checking.
• ...|PROPERTIES
The properties of marks (Name, Description) will be opened.
53.6.2 Spool document
53.6.2.1 Creating spool document

Select a spool mark and in the mouse context menu select |SPOOOL|DOCUMENT
GENERATE:
A spool document is generated under the construction isometric drawing. All

components that are located between the mark and its counterpart are placed
on the document.
Document properties: see next chapter.

53.6.2.2 Properties of the spool document

Base object:
@ISO|O|ISO Documents
For administration of the base object see SECTION 53.2.3.5: “|@ISO|O|ISO DOCU-
MENTS”.
Report template:
As specified at the base object of the mark in the ISO.SpoolDocTemplate
specification.
In the StandardDB: The same report template as for the construction isometric
drawing (|CRp|@ISO|PISO.3 Isometrie DIN A4).
Name :
Same name as the mark
Description :
Same description as of the report template.
Description 2 :
Same description as of the marks.
The spool document is blocked. I.e. no construction relevant changes can be
made.
However, with the tools of the menu bar, you can place free text and free
graphics to place comments.
53.6.2.3 Content of spool document

The document is filled with content when opened for the first time. It con-
tains:
• all components that are framed by its spool marks (regardless of whether
they are relevant for the bill of material or not)
• a bill of material
• all dimensions with values stipulated by the construction isometric drawing:
• Coordinate tags for the start and end points
• All dimensions of levels 1, 2 and 3
• For all components: Tag symbols for position numbers, gaskets and welding
points

53.6.2.4 Editing the spool document

On the spool document, you can:
• specify the adjusting length of the placed components
• if needed, customize the graphical presentation of the dimension and tag
symbols (construction relevant properties not concerned)
• place pure graphic information for addition/comment (with the tools for free
text and free graphs)
Set adjusting length

The adjusting length is set by selecting the dimension of the required compo-
nent.
The adjusting length can be set if:
• the dimension dimensions an individual component or a leg of a component
• the measured component has the tab FT Fabrication with the specification
PL<Number> , with
• Dimension = Length of component: <Number> equals 1
• Dimension = Leg length of component:
<Number> equals the number of the logical connector, to which the
dimension is set.
If this is the case, the dimension data is shown in the menu bar (deactivated)
and a text field PL<Number> , in which the user enters the adjusting length.

Example: Bend
Length for the second leg of a bend: from CX0 to CX2 -> the bend must have
a specification FT.PL2 . In the menu bar, the PL2 field is offered:
In the field, enter the adjusting length for the leg and confirm the value with
[!].
Permitted values: >0 and 0
• Value >0:
On the spool document, the adjusting length is written to the dimension in
following notation: <Length>PL=<adjusting length>
• Value “0”:
No adjusting length set; the old adjusting length is deleted

Purely graphical manipulations of symbols

If needed, the symbols of dimensions and tag symbols can be manipulated.
However, only purely graphical manipulations are allowed:
• Move dimension text
• Change alignment
• Change distance to component
To do this, call the context menu |OPTIONS|UNLOCK for the dimension / tag
symbol. The symbol can now be manipulated with the grab points.
Finally, the symbol must be locked again with |OPTIONS|LOCK.
Inserting comments
Use the tools for free text and free graphics to add comments on the document
(from the menu bar of the spool document: Icons for [LINE], [ARC], [TEXT]).
53.6.2.5 Fabrication documents
Automatic creation
Prerequisites:
• At the base object of the spool mark, the specification
“ISO.AUTO_MANUFACTORING Create production drawing
automatically ” must be activated.
• At the base object of the spool mark, a reference to a document group must
be entered:
Specification “ISO.FTZ_TEMPLATE Template for installation
diagram ”.
All templates benath that document group are rated as fabrication drawing.
When opening a spool document for the first time, Comos checks for all com-
ponents placed on the spool whether there is a fabrication drawing under their
base objects.
If such a document is found, it is automatically copied beneath the component
in the planning view.
For administration of specifications see SECTION 53.2.3.3: “|@ISO|C SPOOL SYM-
BOLS”.
Manual creation
In the Navigator, from the mouse context menu of the component.

Pipe structure for piping isometrics Isometric module
Automatic deletion
When you delete the spool document or the spool marks, all fabrication draw-
ings of the components placed on this spool are deleted as well.
53.7 Pipe structure for piping isometrics

Comos stipulates a three-level pipe structure. The pipe structure is described
in SECTION 57.2.1: PIPE STRUCTURE.
When working on a piping isometric drawing, observe the following devia-
tions from the structure and work flow described in that section:
Level 1
The pipe object of level 1 must be created manually. It is not created automat-
ically when using the Connection tool.
Generally, you proceed as follows:
First create the pipe object, then, beneath it, the isometric drawing.
If required, the isometric drawing can also be created beneath another owner.
The pipe object must still be created manually (also possible in the Select
owner dialog window that pops up when creating a new pipe run with the
Connection tool).
Level 2
The pipe branches must be generated manually (in the Select owner dialog
window).
They are not created automatically when drawing with the Connection tool.
As a rule, you will create a separate pipe branch for each pipe run that you
draw on the isometric drawing.
However, the pipe branches are never placed on an isometric drawing! They
are merely used as owners of the concrete pipes and placed components gen-
erated while drawing. See Level 3, P. 53-56.
Level 3
If you are working with the Connection tool on an isometric drawing, concrete
objects are generated: pipe bends, welded, flanged or screwed on pipes etc.
These concrete objects are the counterparts of the abstract segments from the
P&ID drawings. They, too, must have a pipe branch as owner.

Isometric module Pipe class management
As only concrete pipes are generated while drawing the pipe run, the user
must explicitly determine which pipe branch to set as owner. To do that, the
Select owner dialog window opens automatically.
If necessary, the pipe branch can also be created in the dialog window (under
the pipe object under which the isometric drawing is located).
The base objects of these concrete objects come from the PPC:
@3D|@PPC|@CTS|1|10 pipe.
Example structure in the planning view

The following is an example of the pipe structure in the Navigator:
53.8 Pipe class management

Isometric drawings function in a pipe class oriented way. The pipes placed on
the isometric drawingsometric drawing are assigned to a pipe class and so are
the pipe components.
The base objects of the pipe classes are managed under the following node:
| @3D| @PPC| @01 PipeSpec.
(See SECTION 53.2.2.2: “@3D| @PPC| @01 PIPESPEC”.)

The pipe class properties are set in the Pipe class management dialog win-
dow.
If you want only a brief overview of the Isometric module, you can simply
skip the following chapters.

Pipe class management Isometric module
53.8.1 Opening the Pipe class management and selecting a pipe class
Opening the Pipe class management

Select the Comos menu | ADMINISTRATOR| BASE DATA| PIPE CLASSES or the icon
[PIPE CLASSES] from the Administrator icon bar:
The Pipe class management dialog opens.
Loading a pipe class

Drag the required pipe class directly from the base data to the Pipe class
field. The pipe class is loaded.
Or choose the pipe class with the [...] button.
In the latter case, the Load pipe class dialog opens first.
Depending on the project requirement, here either select a pipe class created
in the base project, or a pipe class created locally in the planning project:
The local pipe class is usually a copy of a pipe class from the base project, cus-
tomized to the special requirements of the project.
Creating local copy

Such a copy can be generated in two steps in the Load pipe class dialog:
1. Tab Base object project : Select the required pipe class and call the
| COPY mouse context menu.

2. Tab Engineering project : Select the @01 node and call the | PASTE mouse
context menu.
A local base object is generated, which is a copy of the base project pipe
class.
Structure of the“Pipe class management” dialog

After loading a pipe class, its properties are displayed in the Ppe class
management dialog:
The upper part of the dialog shows which pipe class is selected. You can
switch between pipe classes any time (with the [...] button or using
Drag&Drop from the Navigator).
In the lower part of the dialog, there are several tabs that define the pipe class
properties.

53.8.2 “Devices” tab
On this tab, you see which components are included in the pipe class and in
which nominal pipe size range the components are available. Within one pipe
class there are usually several components of the same type that have been
defined for the same nominal pipe size:
53.8.3 “Branch table” tab

Depending on the nominal pipe size, the branch table defines which branch
component is to be used when a branch is set. For each combination of nom-
inal pipe sizes there is a standard table by which the administrator defines
which component is to be created for this combination of nominal pipe sizes.
The branch table only shows the components currently selected for the nom-
inal pipe size combinations :
• with name (Checkbox: Show names activated):

• or using a letter code (Checkbox deactivated):
Setting branch components for several pipe nominal size combinations at the
same time
To assign values for several combinations of nominal pipe sizes in one step,
press down the left mouse button and drag it over the cells you want to change.
The cells are selcted. Then right-click and select the desired branch compo-
nent from the mouse menu.
Changing color or letter code

To change the color or letter code, right-click in the table and select the
| LEGEND mouse context command:
A dialog opens where you can assign the letters and colors:

Default branch
If no branch is determined for one of the nominal pipe size combinations,
Comos places a t-piece and the connector components of the t-piece defined
in the connector table.
53.8.4 “Connector table” table
The Connector table defines which secondary components are created

together with the primary component on placing a primary component. It
enables Comos to automatically generate the matching connector components
while drawing a branch or while placing a pipe component. The components
need not be placed and configured manually:
The connector table is divided into two sections:

• The upper section contains a data matrix that lists all connection types
available in Comos and determines the default preferred components that
are generated when the various connection types meet.
If you place a primary component on the isometric drawing without first
determining the preferred components, the components entered here are
created as secondary components.
• The lower section contains a list that defines which additional objects are to
be generated when special components are created. The component is
always created with the secondary components specified in this list,
regardless of the set of preferred components. In the StandardDB, a T-piece
with its connected components is entered here .

When a primary component P is placed on the isometric drawing, Comos goes

to the GD 3D geometry tab of P to determine which connection types the
object has as inlet and outlet. Then Comos checks with which object C pri-
mary component P is to be connected, and also determines the connection
types of object C.
The combination of connection types then determines which component is
created as secondary component S: Comos goes to the upper connector table
and looks up which component was defined as the default preferred compo-
nent. Next, Comos checks if the user has specified a preferred component for
the component type of the default component (via the symbol bar). If he has,
that component is used as preferred component. If the user has not specified
a preferred component, the default preferred component is used.
If the component P is included in the list of special components from the
lower Connector table, the secondary components specified in this list are cre-
ated (objects S1, S2,...). The list precisely specifies which components are to
be used. If other components are currently set as preferred components, this
is of no importance.
Comos checks the connection types of all the secondary components (S1, S2,
...). Similarly, the connection type of the components they are going to be con-
nected to are checked (C1, C2, ...).
Based on the upper Connector table, another secondary component S11 is
then inserted between the secondary component of the special component and
the component linked with it.
Example: Placing a t-piece on a pipe branch

A pipe with base object @3D|@PPC|@CTS|1|10|11|1|01|B|0010
[][]-Seamless pipe-DIN 2458-Row 1-St 37.8 III was placed on the
isometric drawing. The pipe has butt weld ends as connection type:
A t-piece with the base object @3D|@PPC|@CTS|1|71|1|01|B|0010

[][]-Tee A-DIN 2615/T2-St 35.8 I is placed on the pipe. The T-piece has
butt weld ends as connection type, too.

In pipe class Beispiel (Engl: Example), the list of special components speci-
fies that weld neck flanges are to be connected to the butt weld ends of each
t-piece starting with function code 711. Not only the component type is spec-
ified, but also the exact weld neck flange base object:
The weld neck flange entered in the StandardDB in the lower list has a butt
weld end as connection type and a flange end with the contact face E.
When you place the T-piece on the pipe, Comos first checks if secondary
components are entered for the T-piece in the lower connector table. As the
function code of the placed T-piece begins with 711, this is the case.
Then, Comos checks the connection types of all participating components.
With the help of the upper connector table, Comos then determines which
other secondary components need to be created.
The following steps are carried out when the the tee is connected to the pipe
through its first inlet:
– Check T-piece:
Inlet 1 has a butt weld end as connection type. A weld-neck flange (=
weld-neck flange_1) is to be connected to the inlet.
– Check weld-neck flange_1:
The inlet has a flanged end with form C, and the outlet has a butt weld end.
The exact base object of the weld-neck flange is specified by the lower
connector table.
– Check the pipe: has a butt weld end as the outlet.
– The following connection types meet:
• Butt weld end (t-piece) – butt weld end (weld-neck flange_1)
Result: create weld (welding_1) -> current preferred component used
• Butt weld end (pipe) – flanged end form C (weld-neck flange_1)
Result:
Create counter-flange (weld-neck flange_2) -> current preferred
component used
• Join weld-neck flange_2 with weld-neck flange_1:

Flanged end, form C (weld neck flange_1) – flanged end, form C (weld-
neck flange_2)
Result:
Create flat gasket -> preferred component used
Butt weld end (weld-neck flange_2) – butt weld end (pipe)
Result:
Create weld (welding_2) -> preferred component used
53.8.5 “Test” tab
The Test tab works together with a query. With the help of the query, you get
a quick overview of whether a component type is included in the pipe class
with a specific nominal width.
Simply select a function code and the nominal pipe size and the pipe class is
searched automatically:
53.8.6 Remaining tabs
The remaining tabs are defined at the base object of the pipe class, and contain
general information on the pipe class properties.

From the | @3D| @PPC| @01 PipeSpec node, the pipe classes inherit the fol-
lowing tabs:
• C1 Dimension and C2 Use limit : fill as needed.
• C3 Remark : self-explanatory
• GD Geometry :
• GD.VFCD Function Code : Set the Pipe Class entry.
• GD.CPIPEOWNER Base object for pipe and
GF.CSTREAM Base object for pipe branch :
The pipes and pipe bends etc. included in the pipe classes and placed on
the isometric drawing must be located under an owner structure that
corresponds to the Comos pipe structure.
These two attributes can define other base objects for the first and second
level of the pipe structure, than what is defined in the project properties
(on the Module options | Process engineering tab).
As default, the same base objects are entered here as in the project
properties of the base project.

Overview Comos PT
54 Overview Comos PT
SECTION 55: CROSS-MODULE PT TOOLS
SECTION 56: INTERFACES PT
SECTION 57: P&ID MODULE
SECTION 58: TOOLS FOR EMR
SECTION 59: ELECTRICAL ENGINEERING
SECTION 60: REQUEST AND IMPLEMENTATION
SECTION 61: PRODUCT DATA AND MANUFACTURER DEVICE
SECTION 62: EPLAN (IMPORT/EXPORT EXF)
SECTION 63: DIAGRAM TYPE DESIGN
SECTION 64: I&C SUB-MODULE
SECTION 65: LOGICAL DIAGRAMS / FUNCTIONAL DIAGRAMS

Overview Comos PT

Cross-module PT tools Signal management
55 Cross-module PT tools
55.1 Signal management

The Signal Manager offers quick access to all signals that had been cre-
ated within a project.
Call | EXTRA | DETAIL | SIGNAL MANAGEMENT
A dialog window with a list area and a command area opens up. Use drag &
drop to pull an object, such as the project – symbolized by the globe – into the
list area:
The result is that all the signals that are in the tree structure underneath this
object are displayed:
The Signal management interface

The columns in the list area have the following meanings:
below The signal is underneath this object.
Name Name of the signal
Description Description of the signal
IO Input/Output variant
Type Type of the signal

Signal name matching Cross-module PT tools
The dialog elements in the command area have the following meanings:
Name A new name can be input here.
Label A new label can be input here.
Descr. A new description can be input here.
In/Out Changes the input/output variant of the signal.
Dropdown list A signal type can be selected from the drop-down list.
change Changes the signal by setting the values specified in
the command area.
The navigation function in the Signal Manager

The Signal Manager offers a number of navigation options that allow you to
get information on the marked signal.
• Call up by right-clicking on the marked signal | NAVIGATE | OBJECT
The signal is called up within the Navigator.
• Call up by right-clicking on the marked signal | NAVIGATE | BASE OBJECT
The base object of the signal is displayed within the Navigator.
• Call up by right-clicking on the marked signal | NAVIGATE | DOCUMENTC
| NAME OF THE DOCUMENT
Thus the Interactive Report containing the signal is displayed in the
Navigator.
55.2 Signal name matching

See SECTION 64.7.1.6: SIGNAL NAME MATCHING.
55.3 Assignment Manager

This tool matches the elements from planning objects against the templates
from the base objects.
Background: As part of the administrative tasks (import/export, synchroniza-
tion, etc.) it can happen in the event of incorrect operation that a planning
object possesses more elements than it should according to the base object.
In the simplest case, you just have to copy a number of the elements on the
planning side and insert them again under the same owner. Please note: Only
elements that had been checked in can be copied.

Cross-module PT tools Assignment Manager
Example: Cards with channels are to be used in the cabinet layout. The chan-
nels are created on the cards on the Elements tab.
The Create mode of the cabinet has been set to Elements .
The Virtual mode of the elements (of the cards) has been set to Off .
Application:
Drag a planning object into the Under object field.
Objects appear in the lower list if there are more checked-in elements within
the planning object than the base object had provided for.
Mark one or more objects and right-click on them.
| ALLOCATE AUTOMATICALLY
If this is possible, the channels of other cards are allocated.
| CREATE UNDER NEW OWNER
A new card planning object is created and the marked channels are allocated.
Any existing implementations are retained.

Assignment Manager Cross-module PT tools

Interfaces PT ECAD data (import)
56 Interfaces PT
56.1 ECAD data (import)

Comos can import “ECAD” data.
See SECTION 58.2: IMPORTING ECAD COMPONENTS.
56.2 Eplan data transfer (import ExF)

See SECTION 62: EPLAN (IMPORT/EXPORT EXF).
56.3 Simatic S7 (export, import)
56.3.1 Scope
In Comos there is an interface to export objects from and import objects to the
Siemens tool “HW Config” (= Hardware Configuration). This includes the
“symbols” of the Simatic project.
This transfer of data also includes the hierarchical structure.
The schematic drawing of the entire system from HW Config and the graphic
illustration of the Simatic objects are not transferred. Comos has its own form
of display for the Simatic objects, which stays close to the form of display
used at the moment in HW Config.
The interface is bidirectional and is based on the command interface (COM
interface). Consequently data transfer is only possible on workstations on
which both Comos and SIMATIC S7 or PCS7 respectively are installed.
56.3.2 Creating the basic structure of the planning data in Comos

The most important Simatic objects have already been set up beforehand in
the Release database from Comos. These objects are located in @1EA catalog
EE -| A Assemblies -| SIEMENS AG.

Simatic S7 (export, import) Interfaces PT
Create a Simatic base object. An object such as this would be called “Station”
in HW Config. All the additional selection options for this object can be found
in the context-sensitive mouse menu:
• The cards are in the Analog modules and Digital modules menus.
• The racks and the Profibus parts are in the ZZZ accessories menu.
Create data transfer (exchange) object

The data exchange object has already been set up beforehand in the mouse
menu in the Release database:
The data transfer object in a customer database must be prepared as described

in SECTION 56.3.8.1: DATA EXCHANGE OBJECT and then created manually under the
Simatic base object.
56.3.3 Configuring Simatic objects in the planning data
56.3.3.1 Name of the objects (plausibility checks)

When Simatic objects are created in Comos, then a default name is given,
which is often a number. This name is compared during an export operation
with the unique index in HW Config, see SECTION 56.3.8.2: ALLOCATION OF COMOS
PLANNING OBJECTS AND S7 OBJECTS.

Interfaces PT Simatic S7 (export, import)
For that reason the name cannot be chosen freely, since the index in
HW Config follows strict rules, the so-called plausibilty checks. Thus as a
rule a power supply occupies slot 1 and the CPU occupies slot 2 within a sta-
tion.
If there is a difference between the Comos name of the object and the permit-
ted index in HW Config, the object cannot be exported and the export opera-
tion is terminated.
56.3.3.2 Generally applicable attributes
Manufacturer data tab

Siemens has of course already been entered into the manufacturer data. In
addition, the Part number field should be filled out, since the part number
corresponds with the order number in HW Config and thus makes possible the
unique allocation of the Comos object and the HW Config object. See also
SECTION 56.3.8: TECHNICAL BACKGROUND.
56.3.3.3 Cards (Assemblies)
Create cards and channels

Within the mouse menu of the station there are also the Analog modules and
Digital modules menus, among other things. If a card of this type is created,
then the channels are automatically created as well:
The channels are identified by means of addresses. These addresses are con-
figured in the Properties window of the card on the Addresses tab.

Addresses tab
In HW Config the addresses are managed in blocks of 8 and written with the
notation x.y. Thus y runs from 0 to 7; the next channel is incremented before
the decimal point and starts again from 0. The numbering thus runs 1.0, 1.1,
1.2 ..., 1.7, 2.0, etc.
This notation is also called “byte/bit notation.”
The inputs and outputs are each counted separately.
In Simatic the part before the decimal point (the tens level or the “byte”) can
be set manually. The “start address” is set in this way. This option exists in
Comos as well. The input start and output start input fields are located on
the Addresses tab:
The end addresses of the inputs and outputs are then found automatically.
The relevant input start and output start fields are compared when the
objects are imported or exported. The relevant program generates the actual
channel addresses.
However, in many cases the two fields described above are left blank. In that
case HW Config generates the addresses itself.
Technical implementation
Comos object Module (= card), Addresses tab, input start field
(ADR.AdrIn)
exchanges data bidirectionally with
Simatic object Module, Addresses tab, input start field.
Comos object Channel (element of a card), Addresses tab, output start
field (ADR.AdrOut)
Simatic object channel, Addresses tab, output start field.

Auto-correction in HW Config and notification

HW Config checks whether the addresses are permitted when exporting.
Incorrect addresses are corrected at once. The corrected addresses are notified
back to Comos even while the export is taking place and input there into the
planning data. In other words, it is possible that Comos data will also be mod-
ified during an export operation.
56.3.4 Exporting to HW Config
Double-click on the data exchange object. You will see the following inter-
face:
S7 Project
First select into the project that you wish to export the data to by means of the
[...] button:
In the next step you must make a selection in the Station field. There all the
stations in which there is the selected S7 project are offered:
In practice, the project often contains only one station and thus the Station
field can be ignored, since this one (and only) station is input anyway.

Alternatively, you can also create a new S7 station by means of the [NEW] but-
ton. The new station is available in HW Config after it has been created.
If you had created a new S7 project in the previous step, you have to create a
new station at this point, since new projects are empty.
Last of all, mouse-click on the [EXPORT CONFIGURATION] button. A progress
bar appears. All the information on the export operation is shown on the PRO-
TOCOL tab:
All messages arising from the export operation are shown if it did not run
without problems or errors. Section SECTION 56.3.8: TECHNICAL BACKGROUND
describes a number of typical application errors that would prevent an export
operation from running properly.
Please note: Both the part number (SECTION 56.3.8.2: ALLOCATION OF COMOS PLAN-
NING OBJECTS AND S7 OBJECTS) and the S7 class of the objects must be set for the
export operation(SECTION 56.3.8.3: EXPORTING COMOS PLANNING OBJECTS (ALLOCATE
S7 OBJECT CLASS)). HW Config expects both pieces of information. The corre-
sponding details have already been prepared beforehand in the base data in the
Release database from Comos.
56.3.5 Importing from HW Config
Create a data transfer object under a S7 base object if there is not one already.
Open the data transfer object.
Mouse-click on the [IMPORT CONFIGURATION] button.
The details as to what actions took place while the import operation was run-
ning are given on the PROTOCOL tab.

56.3.6 Direct start from Simatic tools
[SYMBOL EDITOR]
Opens the Siemens Symbol Editor tool and loads the list of symbols for the
Simatic project.
Please note: The term “symbols” is used in Simatic with a different meaning
from when it is used within Comos. “Symbols” are a symbol for an address.
For that reason we also speak of symbolic addresses instead of “symbols”
within Comos. See SECTION 56.3.3.3: CARDS (ASSEMBLIES) regarding symbolic
addresses.
[HW CONFIG]
Opens the Siemens HW Config tool and loads the project
56.3.7 Comparing / Deleting objects
There is the [COMPARE CONFIGURATION] button in the Properties window of the

data exchange object.
This button compares all the Comos data of the station with all the
HW Config data of the station. Changes cannot be made either in Comos or
in HW Config.
The result is written to the PROTOCOL tab.
When making a comparison you will also find objects that exist in one pro-
gram and not in another. This is generally due to deleted objects.
Once you have identified the deleted objects, you must then delete them man-
ually at the relevant other point so as to reconcile the two sets of data. Dele-
tions are not made automatically, for safety reasons.
56.3.8 Technical background
56.3.8.1 Data exchange object

The export and import operations are carried out by means of a base object of
class Action . In the standard Release database from Comos this object is
located in @Q Action -| EX Data exchange -| PCS7 data exchange.
This object can be transported into the customer database by copying across
projects.
However, it is simpler to do the following:
• Create a new object of class Action , sub-class Import in the base data.

• Mouse-click on the ProgID icon and input the following text:

ComosS7DExchg.S7DExchg
The data exchange object must later be located in the planning data under-
neath the object of the Simatic station.
56.3.8.2 Allocation of Comos planning objects and S7 objects
Comos names for the HW Config index

In Comos all objects are identified by means of a unique name. In HW Config
the name is not unique and can in principle be chosen as you wish. Instead,
objects in HW Config are given an “index” that is unique when it relates to
the relevant owner. The index has various names, depending on the object:
• Rack: Number of the rack
• Module: Number of the slot
• DP Slave: Bus address
(is given in HW Config in the Profibus setting in the “Parameters”
column)
The Comos name is linked with the HW Config index to ensure a unique allo-
cation of the objects. Example: The Name of a card is used in Comos to deter-
mine the rack in HW Config.
Comos description for HW Config name

The Comos field Description is compared with the Name field in
HW Config.
Exception: Symbolic addresses for channels. See SECTION 56.3.8.6: ALLOCATING
SYMBOLIC CHANNEL ADDRESSES.

56.3.8.3 Exporting Comos planning objects (allocate S7 object class)

The allocation of the S7 object class is done via the S7 class drop-down field
on the |Specifications |System tab:
This field controls what sort of S7 object is involved. If you are using the cur-
rent Release database from Comos, this field has already been set correctly. It
may be necessary to set a corrected value in older databases. The correct value
should be set in the base data and then it should no longer be possible to set it
in the planning data.
Please note: When exporting from Comos, the order / part number must be set
as well as the S7 class, as described in the next section.
56.3.8.4 Creating objects for each order number / part number

Comos planning objects must be created when importing new S7 objects.
Since it is not permissible to have planning objects without a base object, the
base objects to be used must be determined when importing new S7 objects.
The same applies when Comos data is to be exported to HW Config: new
objects must be created in this case as well.
The Simatic order numbers form the basis of the new objects.
In the Comos base data there must be an attribute within which the Simatic
order numbers can be input. You can determine via the Settings dialog win-
dow which attribute contains the Simatic order numbers.
The Comos Part number field on the Manufacturer data tab (HSD.M001) is
used for this purpose in the Release database.
A Start object should still be set so that it is not necessary to search through
the entire Comos base data for objects with matching part numbers. If a start
object has been set, then a search is only made for a matching base object,
base objects located elsewhere are not found.
Comos uses the X unknown module base object if a base object with a suit-
able part number cannot be found. But no importing at all is carried out if this
base object cannot be found either.
Please note: When exporting from Comos, the S7 class must be set as well as
the order / part number, as described in the previous section.

Special case: rack

Three question marks (???) are entered as a joker sign in the part numbers for
the racks in the Comos base data. This joker sign is used instead of the number
in which the length of the rack is to be input.
It is not necessary to have an actual length in HW Config if an object of class
Rack is created.
If you are working in Comos with actual racks, then the data in HW Config
must be prepared accordingly beforehand. A concrete Comos object (i.e.,
without a question mark, and with length details in the part number) cannot
be exported if there is only the general object with the question mark in
HW Config.
56.3.8.5 Addressing channels in Comos

Properties window of a card, Addresses tab, Address mode field: The
entry By byte.bit should always be selected here because HW Config only
addresses in this way. If another entry was to be selected, then another address
for a channel would be output in Comos on reports than the one that is in
HWE Config.
Addresses in the Navigator

[CHANNEL ADDRESS -> LABEL] button
Determines the channel addresses from all the above information and trans-
fers this information into the Labels of the channels. In this way you can see
in the Navigator what address a channel has.
56.3.8.6 Allocating symbolic channel addresses

Channels have an address in HW Config and can also possess an additional
symbolic address. A symbolic address is simply referred to as a “symbol” in
HW Config.
A comment can be input as well as the address in their corresponding fields.
In Comos there is the Symb.address field. (SYS.MA11) on the System
information tab in the Properties window of a channel.
If a text is input here, then this text is also input in HW Config in the Symbol
column. And vice versa; a symbolic address from HW Config is input in
Comos in the Symb.address field.

Interfaces PT Triga (up to 1.04)
Comos object channel, general field Description
Simatic object Symbol, Comment column.
No comments
Special case when importing Simatic objects into Comos: If the Comment
column of the Simatic symbol is blank, then the text from the Symbol column
is written into the Comos Description field.
In other words: If the Comment field is blank, then the general rule from sec-
tion Comos description for HW Config name, P. 56-8 is used accordingly instead. (In
this case the texts in the Comos Description field and in the Comos
Symb.address field are identical.)
56.4 Triga (up to 1.04)

See Help files prior to Comos 8.2.
56.5 VNS import

56.6 Triga document (from V.3.0)

56.7 Metzner Triathlon

See SECTION 63.2.6: INTERFACE: METZNER TRIATHLON.

Metzner Triathlon Interfaces PT

P&ID module Base data, lists, templates
57 P&ID module
57.1.1 PI Piping and instrumentation
The branch PI Piping and instrumenation contains devices and admin-

istration objects that are only required for piping and instrumentation:
All the devices included in this node possess specific basic properties that are
explained in the section SECTION 57.1.1.1: BASIC STRUCTURES PI|PI EN.
In addition, there are objects that bring in additional properties and capabili-
ties. These special objects are described individually in the following sec-
tions.
57.1.1.1 Basic structures PI|PI EN
57.1.1.1.1 Labeling
The sorting does not directly comply with the standard, but instead attempts
to offer the most important departments of 26004 and 2401. In other words,
the catalog in PI does not make up a closed labeling system that can be used
at once.
In addition, most of the base objects possess ID characters in compliance with
the standards 26004 and ISO 10628. (Formerly: DIN 28004/DIN2481)

Base data, lists, templates P&ID module
57.1.1.1.2 Symbol
All simple devices possess one or more symbols on the Symbols tab. As a
rule, diagram types “RI ”, “RI1 ” and “RI2 ” are provided with symbols:
RI: Main area of use in process flow diagrams.

RI1: Main area of use in power stations / DIN 2401.
RI2: Main area of use in chemical plants / DIN 28004 and new: ISO 10628.
These symbols can be modified as required. Please note that the symbols are
inherited hierarchically downwards.
The diagram type symbols initially gave a fixed size and are optimized for one
grid and one scale. Nonetheless, the symbols can also be used in reports with
a different grid and scale through the use of various options.
Each symbol has a placement point that is used for the positioning on the grid.
The placement point only seldom occurs at the top left-hand corner, but
instead is created such that the connectors fall within the grid.
Text symbol
Many of the @1RI branches already possess a “text symbol” at the topmost
level.

This text symbol is inherited by all lower base objects but it is not evaluated
in all base objects. It is only evaluated for those base objects that call up the
text symbol by means of *V* P Textpkt1*. Otherwise see SECTION 45.4.2.1:
TEXT SYMBOL regarding the technical side of text symbols.
The P&ID text symbol outputs the following information as a rule:

• The position of the device
If you look at the script of the text symbol, you can find a header with blank
details:
Header.Layer = "10"
Header.Class = "e72"
Layer “10” is any desired number and is only used to bundle specific items of
information. Any other layer that is desired could also be input. Depending on
the individual data structure, it is necessary to take care that you do not acci-
dentally use a layer here that is to be used in some other way.
Header “e72” is any desired description and is only used to bundle specific
items of information. Any other layer that is desired could also be input. But
please note that certain headers are reserved for internal system use. Thus, for
example, Header.Class = “eZ” means that the text cannot be moved.
57.1.1.1.3 Connectors and auxiliary connectors

Whether or not a P&ID object possesses connectors depends on the purpose
of the application. Auxiliary objects, such as stirrers, for example, do not have
connectors.
In P&ID there are two ways of connecting objects:
• The connectors are not joined directly but are linked by means of a pipe
(connection by means of a device).
• The connectors are joined directly by means of so-called action lines
(connection without a device).
Auxiliary connectors are possible, but are hardly ever used in practice.
In the P&ID area the connectors in addition transport data. The attributes use
a link of type “Via connection” for this purpose. For example, substance data
is transported in this way:

Standardfall
Objekt1
The “target attributes” of the substance
Objekt2
data search via connector I1 for an
object, and from the SD tab of this
SD Stoffdaten SD Stoffdaten object they take the value of the corre-
sponding attribute (operator is “=”).
Spec01 Spec01
statische Verknüpfung
In the standard database linked
attributes are labelled via the connector. A corresponding tooltip appears
when the mouse cursor hovers over an edit field:
When the cursor settle in the edit field and you press F1, then details on
exactly how the link is defined appear in addition.
Measuring functions work somewhat differently in this respect, see
57.4: FUNCTIONS.
SECTION
57.1.1.1.4 General attributes and calculated attributes

Each device has its own special attributes on the Specification tab. The
attributes are inherited further in a hierarchical way and are supplemented by
additional ones or are modified at each level if required.
Attributes that can be used centrally are also administered centrally. There is
the “@Y Catalog” for this purpose:
@Y Catalog attributes
57.1.1.2 @RI-B labeling symbols P&ID
57.1.1.2.1 All
@1RI catalog P&ID |– @RI-B
Class: Data

These objects do not constitute planning objects but are only to be found on
the report. The objects of this branch belong to pipes and must be placed in
such a way that a connection is made to a pipe.
The menu for pipes is offered in the mouse menu.
Attributes: Options tab

Graphic mirroring permitted
On: If the text flag is connected to a pipe and the direction of flow of the pipe
is reversed, the text flag is reversed as well.
Automatic rotation permitted
On: The symbol follows the course of the pipe. If the pipe is vertical, then the
symbol is also vertical, and so on. The text within the symbol are automati-
cally rotated in a meaningful and appropriate direction.
In this case manual rotation has been switched off. The rotation grab point is
still there, but the rotation does not take effect and the flag always jumps back
to the direction stipulated by the pipe.
Automatic co-selection permitted
On: Only takes effect if the text flag is connected to a valve or fitting. If the
text flag is torn off and then the valve or fitting is selected, the text flag is not
selected as well.
Text flags without direct contact with the pipe

The text flag is also allowed to be torn off after docking onto the pipe. The
logical connection is retained and the text flag continues to output information
on the pipe.
Alternatively, the text flag can be positioned freely from the very beginning.
The connection to the pipe is then made as follows:
Select pipe, mouse menu | Copy
Select text flag, mouse menu | Connect with.
57.1.1.2.2 RW Revision clouds

A revision cloud is likewise a purely graphic piece of information. Unlike the
other base objects in @RI-B, a revision cloud does not belong to a pipe. This
object has a large number of freely movable grab points with which you can
shape the “cloud” in such a way that all the desired objects are grouped visu-
ally.
A revision cloud has no effect on the Comos revision.

57.1.1.2.3 @RIGRAFIK Graphic symbols P&ID
01 Pipe break
A base object for a graphic break. Drag the base object onto the pipe (the pipe
turns yellow):
Two grab points appear when you single-

click twice on the break. The grab point that
is on the arm of the break (here the left-
hand grab point), makes the break symbol
itself larger or smaller.
The grab point on which the pipe lies (here
the right-hand grab point) increases the distance between the break.
You can remove the break by single-clicking on the break and then selecting
[Del].
The pipe is retained as a whole in the database, but is segmented. I.e. segments
are created underneath the pipe object You notice the segmentation when you
mouse-click on the pipe: only the area up to the break is still marked in the
report.
02 Page reference
This allows connections that go across pages to be collected together visually
at one place in the report.
1. Create a page reference on the first report.
2. Create a page reference on the second report.
Thus you do not use an object on two different reports (as you would do
with pipes), but instead each report has its own object page reference.
3. The pipes are connected to the page reference object on each of the
reports. If not enough connection points are visible, you can drag out the
symbol to make it bigger. Do this by single-clicking twice on the symbol
of the page reference. A grab point appears in the bottom right-hand
corner:

Additional connection points appear on each of the pages if you want to

make the symbol bigger by dragging it out.
4. Now open the Properties window of one of the page references and there
open the Specification | Reference tab.
Drag the other page reference object in the field To Drawing reference :
Page references are thus allocated as pairs.

When you update the reports, details on the relevant counterpart are now
given in the page reference symbols.
Base objects @F Detail to @R Hose

These objects segment a pipe and are used to give additional information on
a pipe.
Please note that this does not involve valves or fittings, instead, these objects
are intended to provide an additional description of the pipe in purely graphic
form on the report. If an object from @F to @R is created from the base data,
then a planning object is indeed created but it has no attributes at all.

Objects from @F to @R often do not even have connection points.
57.1.1.2.4 @RISYMBOL
These base objects possess symbols that are called up in the symbols of
@V2 Fittings.
57.1.1.3 @1RI | @ST Nozzles

Nozzles are used to connect pipes to objects or objects to pipes.
Nozzles are only used in the P&ID module, since objects in the PFD (and
“PE”) modules in Comos are managed without nozzles.
Technical data tab

Information on the nozzles themselves is collected here.
Substance data tab

Information on the media to be transported is collected here. Many of these
attributes are linked and pass on their information concerning the connected
components.
GD Geometry tab
Is only required for 3D mode.
Use nozzles
The nozzle object must be created as an element to allow objects to be pro-
vided with nozzles. Do this by opening the Properties window of the object
(for example, of the vessel) and there check the Elements tab.
Nozzles can be created on the report by one of the two following methods:
• Recommended: Make a connection to the object on the report and then a
dialog window appears. One option in this dialog window is to create a
nozzle.
• Alternative: Select the Navigator in the mouse menu and then drag the
nozzle onto the report. Please note: If a nozzle is created in the Navigator,
then it is always aligned to the right initially. If the nozzle is to point in
another direction, it must first be rotated. Only then can the nozzle be placed
on the object.

57.1.1.4 @1RI | V2 Fittings

In Comos no distinction is made between general fittings and special position-
ers. The fittings are prepared in such a way that they can also be used as posi-
tioners. Positioners belong to actuating functions, see SECTION 57.4: FUNCTIONS.
57.1.2 Unit structure
57.1.2.1 General
A number of different unit structures have been defined in the standard data-
base. Depending on which project structures had been selected from the prop-
erties of a planning project (Links tab, Project structure attribute), these
unit structures are then made available in the planning view through the | NEW
mouse menu of the project root.
The unit structures are located in the base data under the following branches:
• Installation/ Building/ Production according to EN/DIN:
PI| EN| U| A| 01 Installation/Building/Production
• Installation/ Building/ Production according to ANSI Standard:

PI| ANSI| U| A| 01 Installation/Building/Production
• Installation (AKZ):
@U| AKZ| AKZ01| ?? Plant
• Unit acc. to KKS:

@U| AKZ| 0 Complete installation
The structures according to EN and ANSI follow the usual planning structures
of the chemical industry.
57.1.2.2 Reports and administration objects underneath the unit structure

Reports that are required for the planning and objects that simplify the plan-
ning have been provided within the unit structure. This applies primarily to
the structures according to EN and ANSI, which (apart from a few reports) are
structured identically, and also for the AKZ structure, which from a certain
hierarchy level onwards possesses the same administration objects as do the
structures according to EN and ANSI.
Structures according to EN and ANSI

• PI| EN| U| A| 01 Installation/Building/Production and
PI| ANSI| U| A| 01 Installation/Building/Production:

Here are a number of Evaluation Reports. Apart from the signals list (see
SECTION 64.5.1.2.6: “PFPA.1 SIGNAL LIST AND PFPA.2 SIGNAL LIST (HARDWARE)”) this
involves lists whose report templates are located in the base project under
CRp| PI| PPB Device, label lists.
• PI| EN| U| A| 01| 01 Main unit and PI| ANSI| U| A| 01| 01 Main
unit:
P&ID reports can be created in the structures underneath the main unit.
• PI| EN| U| A| 01| 01| 01 sub-unit and PI| ANSI| U| A| 01| 01| 01
sub-unit:
– P&ID reports are created underneath the sub-unit.
– A number of folders (“categories”) are created automatically
underneath the sub-unit when the sub-unit is created.
The category function produces a clearer structure for the planning

objects, for example, by automatically collecting in a folder all the pipes
that had been placed on a P&ID report. This is explained in more detail in
SECTION 49.8: CATEGORIES.
The EE/I&C Engineering folder is not required until the I&C planning,
as a rule. The positions are created underneath it, and the functions are
created underneath them in turn. All that P&ID planners have to do is to
place the functions on a P&ID diagram: if you then input a function code,
a position is created automatically for the function, and both are moved
into the EE/I&C folder by means of the category function. Compare also
SECTION 57.3.2: CREATING POSITIONS; there is more information on the topic of
the EE/I&C folder in SECTION 64.2.1.1: FOLDER “EE/I&C ENGINEERING”.
– Placement overview “QDev010 objects with DocObj”
This query in the mouse menu of the sub-unit is an example of how you
can collect information.
Class:
The default setting is Pipe , but you can also set it to All, for example.
Start object:
The sub-unit is automatically set as start object.

P&ID module Pipes
Placing filter
There is a [PLACING FILTER] in the symbol bar of the query. Here you
should input diagram type RI2 (RI 10628). After that you can switch
between ALL, PLACED and UNPLACED in the placing filter.
Application example: you search through all the objects that have not
been placed yet and distribute them on the reports.
AKZ structure
Folders that inherit from the same base objects as those of the structures
according to EN and ANSI are likewise created automatically underneath
level 6 (@U| AKZ| AKZ31 00 Sequential number).
57.1.3 @P Positions
See SECTION 57.3: POSITIONS for more detailed information.
57.1.4 @F Functions
See SECTION 57.4: FUNCTIONS for more detailed information.
57.2 Pipes
57.2.1 Pipe structure
57.2.1.1 Overview
Comos stipulates a three-level pipe structure. The P&ID module and the Iso-
metric module differ from each other in the third level:
- Pipe
- Pipe branch
- P&ID: Segment, Isometric: concrete pipe object
As a rule, these objects are generated when using the Connection tool in an
Interactive report, and are automatically created in the Navigator in the plan-
ning view.
On placing a component on a pipe run in the diagram, the pipe run is divided,
the details of the devision depending on the settings in the component (See
SECTION 57.2.2: SEPARATING PIPES WITH COMPONENTS.)

Pipes P&ID module
Below you can see examples of the three-level pipe structure:

P&ID structure
Iso structure
Since pipes are normally generated during the P&ID basic planning, the base
objects for the Comos pipe structure are located in the |PI Piping and
instrumentation node in the StandardDB.
Exception:
When constructing pipe runs on an isometrics, the objects that are created at
the third pipe level come from the Pipe parts catalog (|@3D|@PPC|@CTS Part
components).
The following sections explain the pipe structure from the point of view of
P&ID planning. Deviations regarding the construction of pipe isometrics are
described in SECTION 53.7: PIPE STRUCTURE FOR PIPING ISOMETRICS.
57.2.1.2 First level: Pipe

Base object: | PE| EN| D| 03| 01 Pipe
Class : Position
Subclass : None
Creation option : normal
Creation mode : Free
At the top level of the pipe structure is an object for a pipe. This object is a
container that manages the actual pipe objects (pipe branches and segments).
It exists only in the Navigator and is not placed on diagrams. It is created auto-
matically, as soon as you draw on a diagram with the Connection tool.

P&ID module Pipes
In the planning data, the pipe is the owner of the pipe branch. It can contain
as many pipe branches as necessary.
Elements tab:
Objects that are typically created under a pipe should be prepared on this tab.
That is, a pipe branch should be entered as element of the pipe (see
SECTION 57.2.1.3: SECOND LEVEL: PIPE BRANCH). This way even reports (e.g. an Iso-
metric) can be made available in the planning view.
57.2.1.3 Second level: Pipe branch

Base object:
|PE|EN|D|03|02|01 Z Pipe branch or
...| 02 Pipe (KKS)
Class : Position
Subclass : Pipe
Connectors tab:
An input I1 and output O1 of type P&ID. The connectors must be named I1
and O1!
Elements tab:
A segment must be prepared on this tab to be able to work on P&ID diagrams
(see SECTION 57.2.1.4: THIRD LEVEL: PIPE SEGMENTS (P&ID))!
The pipe branch is generated automatically when you work with the Connec-
tion tool on the P&ID. In the planning view, the pipe branch must be located
under a pipe. If there is no pipe yet, it is created automatically.
Pipe branches remain placed on the diagram until objects of the third pipe
level are created underneath them (for example by placing a component and
thus segmenting the pipe branch, see SECTION 57.2.2: SEPARATING PIPES WITH COM-
PONENTS).
57.2.1.4 Third level: Pipe segments (P&ID)

Base object: | PE| EN| D| 03| 02| SEG Segment
Name: SEG (must not be changed!)

Pipes P&ID module
Class : Element
Subclass : Pipe
Virtual : N times
Inheritance mode : Active
Connectors tab: See pipe branch
The base object of the segment is entered on the Elements tab of the pipe
branch.
Pipe segments are created when you place a component with the
“SYS.PIA602| Pipe cut mode: Segment separative ” attribute value on a
pipe branch on a P&ID diagram. They are created below the pipe branch and
are connected with the component through their connectors.
Segments are abstract objects that represent a logical view of the pipe.
When working on an isometric, however, Comos does not create segments on
the third level of the pipe structure, but concrete pipes (welded, flanged or
screwed on etc.) and uses other base objects accordingly. See SECTION 53.7: PIPE
STRUCTURE FOR PIPING ISOMETRICS.
57.2.1.5 References to the base objects of the pipe structure

Which base objects are used for the first and second level of the pipe structure
is determined in the project properties, tab Module options| Process engi-
neering :
Library object for pipe : |PE|EN|D|03|01 Pipe
Library object for pipe branch : |PE|EN|D|03|02|01 Z Pipe branch
If nothing is entered here in the planning project, the references from the base
project are used automatically.
Attention:
If you work with pipe classes, these settings can be overwritten in the base
object of the pipe class, on the GD Geometry tab.

P&ID module Pipes
57.2.2 Separating pipes with components
When you draw a line on a P&ID diagram with the Connection tool or place
a pipe via the base object icon bar, a pipe object is automatically created in the
Navigator and under this, an object for a pipe branch. The pipe automatically
becomes the owner of the pipe branch. When fittings are placed on the pipe
branch, pipe branch is separated (or “cut”).
The components that are placed on a pipe can have different separation
modes. Depending on the pipe cut mode, new pipes and pipe branches or seg-
ments are created on placing the component:
SYS.PIA602 Pipe cut mode
Possible values:
• Segment separative :
Case 1: The component is placed on a pipe branch; there are no segments
yet.
Effect: Two segments are created under the pipe branch. The component is
connected with the segments through its connectors.
Case 2: The component is placed on a segment.
Effect: A second segment is created. The component is connected with the
segments through its connectors.
• Pipe branch separative :
Parallel to the pipe branch on which the component was placed (or, if the
component was placed on a segment: parallel to pipe branch of that
segment), a second pipe branch is created. This second pipe branch and the
original pipe branch (or the second pipe branch and the segment) are
connected with the component through their connectors.
• Pipe separative :
A second pipe is created parallel to the owner pipe of the pipe
branch/segment on which the component was placed, and under it, a pipe
branch. This second pipe branch and the original pipe branch/ segment are
connected with the component through their connectors.
Redundant segments are automatically deleted. E.g.: If a segmenting compo-
nent is deleted, the segments are deleted as well.
57.2.3 Optical interruption on the report
Do not confuse the segmentation / separation of pipes and the so-called “opti-
cal interruption”. The latter refers to the fact that a pipe is optically interrupted
on the report to improve the clarity of the drawing.

Pipes P&ID module
Example:
A vertical and horizontal pipe overlap. For the horizontal pipe, call
|OPTIONS|TO FOREGROUND from the mouse context menu.
The vertical pipe is shown interrupted on the diagram, but is not changed in
the database:
57.2.4 Graphical properties of pipe objects
<RI.BREADTH> : Line width

<RI.COLOR> : Line color
The value “-1” is entered in the attribute if a color is set manually.
Internally, the Windows color code is saved.
The color that was assigned to the object on the Interactive report applies.
However, the color value can be reassigned in the attribute at any time.
This value corresponds to the Logocad color code and is taken from the
appropriate standard value table.
<RI.LNTYPE> : Line type
For P&ID pipe objects, the representation of the pipes changes in the
Interactive reports if the transported medium is changed. To do that, the
property window of the pipe must be opened and the “Line type” must be
selected on the “Presentation” tab.
Please note: The “Line type” from this tab is not identical with the “Line
type” in the mouse menu when the pipe symbol is selected in the
Interactive report.
For pipes without separate Comos objects, the following applies:
All graphical attributes are saved in the Interactive report.

P&ID module Positions
Increase processing speed (Disable Script)

If the separation of pipes is relatively slow, then check if the script is required.
In the base data, the base object of the pipes is searched and the segment ele-
ment (Name: SEG) is selected in the Elements tab. The property window of
the element segment is opened and the Script tab is selected. There, you will
find a Connect Script that is not always needed. If possible, you can create a
pipe base object, for which this script is not always called.
57.2.5 Pipe tags
Text tags (pipe tags) describe connections.

The pipe tag is defined as text symbol on the Symbols tab of the Pipe base
object.
The StandardDB has a base object for text tags: @V12 pipe information. The
base object is of “Data record” type and generates a tag when it is dragged
onto an Interactive report. If the tag is dragged onto a pipe, then “docking”
takes place.
57.3 Positions
57.3.1 General
Positions are created in P&ID. They designate positions related to process or
control tasks. The position object serves as the folder, under which functions
and reports are located. In addition, vessels have been created with class Posi-
tion (sub-class Equipment ) in the standard database.
A P&ID position is described by:
• Class: Position
• Sub-class: None
Structure of the base objects

In the standard database:
@P Position
• ...| 01 Positions/metering point acc. to DIN / IEC

| 0 General positions
| 1 Density
...

Positions P&ID module
• ...| 02 Measurement: general position

• ...| 03 Positions/metering point acc. to ANSI
| A Analysis
| B Burner, Combustion
...
The following objects have been predefined underneath the positions:
– Measurement functions
– actuating functions
– neutral functions (and general functions according to ANSI)
– PDAF.1 Position sheet
– PFFA Functional diagram
– PFSM Position diagram (01 ... EN/DIN and 02 Measurement: PFSM.2
Position diagram, 03 ... ANSI: PFSM.1 Position ANSI)
Additional objects have been predefined underneath the positions according

to DIN/EN:
– PFA.04 Position diagram, single line
– PQAC.1 Loop, Check protocol
– Search objects
– 04 Assembly groups (functions with signals)
– 05 FD Assembly groups (functions with signals and FD blocks)
These objects are available in the planning view through the | NEW mouse
menu of the position. However, many of the objects are not required until the
I&C planning. More details on these objects are given in SECTION 64.2.1.2:
“@POSITION”. See also SECTION 57.1.4: @F FUNCTIONS for more information on
functions.
57.3.2 Creating positions
Automatically
Sometimes positions are created automatically by Comos. This is done in the
following cases:
• Placing a function with a function code:
A function is placed directly on a P&ID diagram. (Directly = your base
object is placed on the diagram either by using drag & drop from the

P&ID module Positions
Navigator, Base objects tab, or via the symbol bar; the function is not
created first in the planning view in the Navigator.) Result: The function is
created underneath the diagram.
If you now input a function code into the function, a position of the
corresponding type is created underneath the diagram. The function is
moved to underneath the position.
• Copy all:
All functions on a P&ID diagram that are located under a position are copied
and inserted back on the diagram. The result is that the newly created
functions are created underneath a new position.
(If you only copy a partial quantity, the functions are inserted underneath the
old position.)
• [ASSIGN OBJECT] in mode Define owner :
If you select a function on the P&ID diagram and assign a new owner to it
by means of the [ASSIGN OBJECT] icon button (mode: Define owner ), the
following objects are moved to underneath the new owner:
– the position that the function is located under
– all objects located underneath the position.
If the function had been located directly underneath a P&ID diagram and
did not as yet possess a position, first of all a position is created underneath
the assigned owner and then the function is moved to underneath the
position.
Manually
Positions can also be created manually in the Navigator by using the | NEW
mouse menu of the EE/I&C Engineering folder. See SECTION 57.1.2.2: REPORTS
AND ADMINISTRATION OBJECTS UNDERNEATH THE UNIT STRUCTURE regarding the
EE/I&C Engineering folder.)
The objects that have been predefined underneath the individual positions dif-
fer slightly.
57.3.3 Data flow of positions
All the attributes of the following tabs:

• EX020 Ex-protection
• IC030 E&IC options
• IC020 Environmental conditions

Functions P&ID module
of a position are statically linked with the corresponding attributes of the sub-
unit. These details are required later for selection of the signal. When a posi-
tion is created, all the static links are automatically updated (once only) by
Comos PT.
The attributes on these tabs are relevant in the I&C planning phase. They are
almost purely of an informational nature and do not trigger any automated
functions. See also SECTION 64.2.1.2.2: TABS / ATTRIBUTES.
“E&IC options”: attributes “EMS102 H,L” and “EMS103 +,-”

Only one of the two attributes can be selected. The attribute shows to the user
whether the high and low state was input in the label with “H, L ” or “+, - ”.
As yet no automatic warning is given if this setting had been made incorrectly.
57.4 Functions
57.4.1 General
The function describes the measurement or actuating task and the processing
function(s) in a position.
• Class : Function
• Sub-class :
• Instrumentation : describes a P&ID function
• Actuator : An object with this Actuator sub-class separates the pipe in
drag & drop.
• Actuator/Insertion : An object with this sub-class segments the pipe.
• Creation mode : free
• Creation option : normal
Functions are not created as a request (System settings tab, Option
Request ), this means that they are not implemented later. However, they
contain elements that can be created with the Request option.
In Comos the following four methods define a function in greater detail:
• The display of its symbol
• Measurement function: the function code (type of measurement function),
which leads to a base object change
• the number of process connectors, and

P&ID module Functions
• the attributes of the function,

Which attributes appear depends on the change of the base object. In
particular, the component of the sub-class is swapped.
57.4.2 Structure of base objects
You can find the functions underneath the @F Function node in the Comos
standard database. The following functions have been predefined under this
node for the following standards:
• ... | A1 Functions acc. to EN/DIN
| 01 Measurement functions
| 02 Actuating functions
• ... | A2 Functions acc. to ANSI

| 01 Measurement functions
| 02 Actuating function ANSI
• ...| A3 Functions acc. to KKS

| 01 Measurement function
See SECTION 64.2.1.3: “@F FUNCTIONS” for more information on functions and the
objects to be created underneath them.
57.4.2.1 Level “@F|A<number>”: neutral functions

If functions of levels A1 are created in the planning view, then as “placehold-
ers”, because a more detailed specification of the function (function type:
measurement or actuating function, maybe which function code) either has
not been done yet or is not intended. These functions are designated as neutral
or general functions. They are replaced by more concrete functions in the I&C
planning at the latest.
A function of this level has no function code. If one is input, this does not
result in a change of base object.
If a function of this type is connected with the process on a diagram, it is not
given a process connector.
There are various Evaluation or Interactive Reports underneath functions of
this level and the following levels. However, as a rule they are not required
until in the I&C planning. See SECTION 64.5: I&C REPORTS.

57.4.2.2 Levels “@F|A<number>|01 Measurement function” and “... |02

Actuating function”
Functions possess a function type from this level onwards. See Attribute
“FunctionType Function type”, P. 57-24.
...| 01 Measurement function

If you work with unit structure Installation/Building/Production acc. to
EN , ... acc. to ANSI or acc. to AKZ , the measurement functions Local
measuring , Control and watch centrally together with Controlling and
monitoring at local point are offered in the Navigator under a position
through the | NEW mouse menu (alternatively, these functions are selected
from the predefined symbol bar of the P&ID diagram). In the base data they
are located under the following node:
@F | SE Structure elements for functions | 01 Measurement
functions
and inherit from measurement function @F | A1 | 01 Measurement
functions and @F | A2 | 01 Measurement functions respectively.
A measurement function with this base object does not initially possess any
function code. If it is placed on the diagram and connected with the process,
it is not given a process connector (and hence also no new tabs), as is the case
with the measurement functions of the levels underneath it.
If you input a function code, a change of base object takes place from this
level onwards. If the function had been connected with the process before the
function code was input, it furthermore gets a process connector afterwards.
See also SECTION 57.4.5.1: CREATING A PROCESS CONNECTOR.
The objects in branch @F| A1 Functions acc. to EN/DIN comply with
DIN 19227.
On this level of the unit structur according to KKS you can find a structure
that improves the bundling of the underlying measurement functions.
...| 02 Actuating functions

This base object is a structure underneath which the base objects of actuating
functions that can be created concretely are collected.
In the standard database numerous structures have been predefined under the
functions from this level onwards. These structures are then made available in
the planning view by mans of the | NEW mouse menu of the functions. How-
ever, they are not required until the I&C planning stage and hence they are
covered in the I&C section. See also SECTION 64.2.1.3: “@F FUNCTIONS”.

57.4.2.3 Levels underneath “@F|A<number>|01 Measurement function” and

“... |02 Actuating functions”
The “concrete” functions, which are a prerequisite for the actual I&C plan-
ning, start with this level.
Measurement functions:
These possess a function code. Base objects for measurement functions have
been predefined without a process coupling, with one process coupling or
with two process couplings. See SECTION 57.4.5.6: NUMBER OF PROCESS CONNEC-
TORS.
Actuating functions:
Concrete actuating functions (2-port valve, 3-port valve, etc.) are offered.
57.4.2.4 “@F| SE Structure elements for functions”
“@F| SE| 01”, “..| 02” and “...|04”

The functions created here inherit from the functions underneath nodes
@F| A1 and @F| A2. They are elements of the positions that had been created
in the @P branch (through the Elements tab of the positions). The result is that
they are offered in the planning view through the | NEW mouse menu of the
position.
See SECTION 57.4.2.2: LEVELS “@F|A<NUMBER>|01 MEASUREMENT FUNCTION” AND “...
|02 ACTUATING FUNCTION”.
@F| SE| 98 Function elements ANSI loop

These function elements are the inheritance source of the function elements
under @F| A2 Functions acc. to ANSI| 02 Actuating function ANSI.
@F| SE| 99 Structure elements for template

The actuating function that had been created here inherits from that under
@F| A1| 02| 01. It can be used as the base object for the modules for func-
tions that are created in the base project.
57.4.2.5 “@F| Y Attributes catalog”

Most of the Specifications tabs and most of the attributes of the functions are
collected in this node. However, a number of tabs and attributes of functions
are created in the ET and PI branches.
In addition: the E&IC options specification tab and its attributes, which exist
in the units and positions, originally came from this branch.

More details in the sections on the relevant tabs.

Caution: the SubReports for the configurable I&C reports are also prepared
here. See SECTION 64.5.1.1: CONFIGURABLE I&C REPORTS.
57.4.2.6 “@F| Z Structures (create new/assembly groups)”

These are used in the I&C planning. See SECTION 64.2.1.3.6: “@F| Z STRUCTURES
(CREATE NEW/ASSEMBLY GROUPS)”.
57.4.3 Tabs / attributes
57.4.3.1 “SYS System information” tab

This tab contains two groups of attributes:
• System settings I&C: these belong to the preparation for the I&C planning
(see “SYS System information” tab, P. 64-8).
• Function settings P&ID : belong to the base data administration of the
P&ID planning. They are covered in the following sections.
Attribute “FunctionType Function type”

The attribute shows whether it involves a measurement function, an actuating
function or a neutral function.
The attribute can be queried by means of: specs.FD. F100.value.
If this attribute does not possess a value – meaning that the user had left the
field blank, a query does not return a blank string but instead device.name
(in other words, the name of the planning object).
Attribute “PCC Component for process coupling”:

Determines the process connector with which the function is created when
connecting with the process device (a pipe, as a rule) on a P&ID diagram
(inline device, nozzle or valve). A parameter must be set for this in the options
script within the template.
See SECTION 57.4.5.5: AUTOMATICALLY CREATE PROCESS COUPLING for further infor-
mation on this.
In the standard database the tab originally comes from the following collec-
tion of tabs:
@F Functions | Y Attributes catalog| 1 Tab collection
| SYS System information | 08 Functions | SYS System informa-

tion.
The attributes of the tab originally come from branch ET | Y Attributes
catalog | 0 Attribute collection | 01 System.
57.4.3.2 “RI Presentation” tab

Contains two options groups. The first controls settings that are always shown
on the P&ID diagram (line thickness, color, etc.).
The second group includes optional forms of display that only exist for dia-
gram type RI2, and are used for example by reports R+I EN 10628 :
1. ICF200 Optional: Graphic for relevant adjustment :
If this attribute is selected, the following sub-commands are offered on
the diagram in the mouse menu under the | GRAPHICAL SETTINGS
command:
• ...| SAFETY-RELEVANT (GRAPHIC):
Sets the value of attribute ICA110 Safety-relevant (graphic) of the RI
Presentation tab.
This is stored with a base standard table from the IC branch. If this
attribute is selected, the “Safety-relevant” graphic is shown as well on the
diagram.
• ...| CALIBRATION PROOFED MEASUREMENT:
Sets the value of attribute ICA103 Calibration proofed measurement
of the Request and security tab. This is stored with a base standard
table from the IC branch; it functions in the same way a ICA110 .
• ...| QUALITY/ENVIRONMENT RELEVANT:
Sets the value of attribute ICA101 Quality-/ Environment relevant of
the Request and security tab. This is stored with a base standard table
from the IC branch; it functions in the same way as ICA110 .
2. ICF201 Optional: Alarm diagram :
This is stored with a base standard table from the IC branch. If this
attribute is selected, the values that were input on the RI Presentation
tab are shown in attributes ICF202 , ICF202a , ICF292a2 , ICF202b ,
ICF202b1 and ICF292b2 .
On the one hand, these attributes can be set through the Properties window of
the function. (Caution: it is not sufficient to only activate the attributes for the
additional graphics. The Optional: Graphic for relevant adjustment
attributes and Optional: Alarm diagram tabs must also be activated!)

On the other hand, you can also select the function on the P&ID diagram and
set it by means of the mouse menu.
See Additional text variables, P. 57-39 for a more detailed description of the func-
tioning of the optional attributes.
tion of tabs:
| RI PI Presentation | 01 PI Presentation Measurement function
| RI Presentation and ...| 02 PI Presentation |RI Presentation for
ANSI functions respectively and ...| 03 PI Presentation Actuating
function | RI Presentation.
The attributes of the tab originally come from branch @F | Y Attributes

catalog | 0 Attribute collection| 03 Options/Representation.
Exception: ICA110 Safety relevant (graphic) comes from branch

@F| Y| 0| 04 Function data.
57.4.3.3 “IC110 Function data measuring point” and “IC110 Function data
actuating point” tabs
These tabs exist in functions from the base object level @F| A <number>
| 01 Measurement function and ...| 02 Actuating function onwards.
The most important attributes of this tab are:
• ICF100 Function : Identifies which function is involved. The specification
returns the Displayvalue or nothing, if no value has been set.
• ICF102 Output and handling and ICF101 Process with : Saves the
graphical settings of the symbol. Alternatively, this can also be set in the
P&ID diagram through the | GRAPHICAL SETTINGS context-sensitive mouse
menu. Compare SECTION 57.4.8: DISPLAY ON THE DIAGRAM and SECTION 57.4.3.2: “RI
PRESENTATION” TAB.
• CProcess Number of process connectors : Determines the number of

Substance data and Process connector tabs; only exists for
measurement functions. Compare SECTION 57.4.5.6: NUMBER OF PROCESS
CONNECTORS.
Fill in the other attributes on the basis of your technical knowledge. In addi-
tion, the tab also shows a number of attributes that cannot be changed; these
are given as background information.
Fewer attributes have been predefined in the actuating functions than is the
case with the measurement functions.

tion of tabs:
| IC110/210 Functions (F)| IC110 Function data| 02 Measuring
point| IC110 Function data measuring point and ...| 03 Actuating
point| IC110 Function data actuating point respectively.
The attributes of the tab originally comes from branch @F | Y Attributes

catalog | 0 Attribute collection | 01 Function data.
57.4.3.4 “PI01x Substance data” and “IC22x Process connector” tabs
57.4.3.4.1 General
These tabs are only created when the function is given a process connector.
See SECTION 57.4.5.1: CREATING A PROCESS CONNECTOR.
The number of process connectors controls how many tabs for substance data
and how many process connectors the function possesses.
“Substance data” tab

A number of the attribute values of the Substance data tab of a function are
taken from the Substance data tab of the connected pipe branch. See
SECTION 57.4.5.4: PROCESS COUPLING ACTUATING FUNCTION and SECTION 57.4.5.4: PRO-
CESS COUPLING ACTUATING FUNCTION.
Since in the course of actual planning work the substance data is input in the
P&ID stage, the base data is created in the PI branch:
| PI | Y P&ID Catalog attributes | D Catalog | 02 PI catalog
tabs| PI010 Substance data | 13 Substance data measurement
function| PI010
The attributes come from branch | PI| Y| D| 01 Catalog attributes.
“Process connector” tab

On the Process connector tab, the function takes some of the attributes
from the connected pipe branch, Technical data tab. . See SECTION 57.4.5.3:
PROCESS COUPLING FOR MEASUREMENT FUNCTIONS and SECTION 57.4.5.4: PROCESS COU-
PLING ACTUATING FUNCTION.
In the standard database the tab originally comes from the following node:

@F Functions | Y Attributes catalog | 1 Tab collection

| IC110/210 Functions (F) | IC210 Process connection
data| 01 Measurement function and ...| 02 Actuating function.
The attributes come from @F Functions | Y Attributes catalog | 0

Attribute collection| 02 Process connection data.
57.4.3.4.2 Measurement function with process coupling nozzle

If a function with a nozzle as process coupling receives a process connector,
the following new Specification tabs are created:
PI01<number> Substance data <number>
IC22<number> Process connector <number>.
The number of process connectors controls how many tabs the measurement
function possesses for substance data and process connectors .
The numbering of the tabs is incremented if there are multiple connectors.
57.4.3.4.3 Measurement function with process coupling inline device

Flow measurements possess an inline device as process coupling. If a flow
measurement is given a process connector, then among other things the fol-
lowing new Specification tabs are created:
• Process connector P1(P+)
• Process connector P2(P-)
• Substance data 1
The number of these tabs is fixed and cannot be increased, in contrast to that
of the other measurement functions.
57.4.3.4.4 Actuating function

Actuating functions receive a process connector directly upon being created
in the Navigator - and hence among other things the following tabs:
• 2-way valve
Process connector P1(P+)
Process connector P2(P-)
• 3-way valve
Process connector P3

• 4-way valve
Here P+ stands for the inlet and P- for the outlet. The number of these tabs is
fixed and cannot be increased, unlike with the other measurement functions.
57.4.3.5 'Process connection data” tab

Regardless of how many process connectors a function has, it only possesses
one Process connection data tab.
Only actuating functions and measurement functions that have an inline
device as process coupling possess this tab. In the case of actuating functions,
the tab is created directly with the planning object, but with measurement
functions with an inline device only once they get a process connector. Com-
pare SECTION 57.4.5.1: CREATING A PROCESS CONNECTOR.
The following attributes inherit their values by means of a static link from the
connected pipe branch:
ICP109 Operating temperature, valid and ICP110 Operating pressure,
valid .
The remaining values are input at the function.
In the standarddatabase the tab originally comes from:
@F Functions | Y Attributes catalog | 1 Tab collection
| IC110/210 Functions (F) | IC210 Process connection data
| 02 Actuating function| IC220 Process connection data.
The attributes come from @F Functions | Y Attributes catalog | 0

Attribute collection| 02 Process connection data.
57.4.4 Function code
The function code of a function can be input in one of two ways:

Open the Properties window and input the code in the Label text field:

Input in the diagram

Select the function on the diagram. Text fields appear at the top edge of the
report. The middle text field contains the label. Input the code here.
Effect of entering the function code:

There is a change of base object, depending on the code.
BSP: A function that possesses base object @F| A1| 01 Measurement
function and does not have a process connector receives the function code
“PI”. The function automatically gets a new base object: F| A1| 01| P
Pressure.
Regarding the actuating function, the function code has a purely informa-
tional character. There is no change of base object.
You can tell from the E&IC Options tab of the position or subunit whether or
not alarms with +/- or H/L are to be input. (No automatic mechanisms in the
event of discrepancies, see “E&IC options”: attributes “EMS102 H,L” and “EMS103
+,-”, P. 57-20.)
57.4.5 Process coupling and process connector

A function is connected to the process by means of a process coupling. Thus
each functions neetd a process connector. The process coupling is either a
nozzle, a valve or an inline device.
57.4.5.1 Creating a process connector

To be able to connect a function to the process, the function needs a process
connector. The process connector is implemented with the means of several
tabs that are created with the function:
• PI01x Substance data
• IC22x Process connector
• IC220 Process connection data .

The tabs store information on the process connector. To a certain extent this
information is obtained automatically, through a controlled transfer of data
(see SECTION 57.4.5.2: DATA FLOW).
How many of these these tabs a function exactly possess, depends on how
many times it is connected with the process.
Actuating function:
The tabs are generated directly upon creation of the planning object in the
Navigator. The number of tabs depends on the concrete actuating function and
is strictly defined for this.
Measurement function:
The measuement function must have a function code, else the process connec-
tor cannot be created. In contrast to the creation process for actuating func-
tions, the user must “initiate” the creation of the tabs by connecting the
function with the process on the diagram or else by incrementing the number
of process connectors through its Properties window. See also SECTION 57.4.5.6:
NUMBER OF PROCESS CONNECTORS. The number of tabs is fixed in the case of mea-
surement functions with an inline device, but is variable for measurement
functions with a nozzle.
See SECTION 57.4.3.4: “PI01X SUBSTANCE DATA” AND “IC22X PROCESS CONNECTOR” TABS
and SECTION 57.4.3.5: 'PROCESS CONNECTION DATA” TAB for more information
regarding the tabs.
57.4.5.2 Data flow

The data that was input at the device on the Substance data and Technical
data tabs during the P&ID planning (for example, a pipe branch) is also
important for the function to some extent. A controlled transfer of data is used
in Comos to pass on this data to the function.
Caution: The following applies to enable the data (substance data and process
data) to flow:
• Actuating function: Must be connected to the process. As was explained
above, actuating functions do already possess the tabs for substance data
and process connectors when they are created in the Navigator, but of course
no data can be exchanged without an actual connection to the process.
• Measurement function: Must possess a function code. Must possess a
process connector (see above) and must be connected to the process (for the
same reasons as the actuating function).

“Update connected devices”

Depending on the version of the database, the information is passed on over
several stages. Examples:
• Pipe branch -> Nozzle -> Measurement function.
• Pipe branch -> Valve,
Pipe branch -> Actuating function.
In these cases it is important that the question “Update connected devices?”
prompted by Comos is answered with “Yes”. Reason: the discrepancy warn-
ing (“orange switching”) always only shows the discrepancies at the first
level. None of the following objects detect that there is a discrepancy in the
data flow.
Update connected devices later on

If the connected components were not updated directly, this can also be done
later on.
1. Comos automatically detects discrepancies between the linked attributes
of the first level and of the data source (e.g., the pipe branch).
Please note: No attribute values have been taken over as of this point in
time. Comos only compares if the relevant values at the pipe branch differ
from those of the process coupling.
2. The corresponding attribute fields with discrepancies – not all! – are
shown in orange:
3. Right-click in a free area of the tab and select the | UPDATE STATIC LINK
menu.

4. The attributes match again and the attribute fields are switched back to
white.
It is, of course, not absolutely necessary that the data is transferred one to one.
You can also enter your own values; discrepancy with respect to the data in
the process coupling will then be indicated by means of the orange switching.
The flow of data is done at the attribute level. Please note: This involves two
attributes, in which only the contents are matched/compared!
The units of the linked attributes do not need to match one another. The values
are converted automatically.
Once the nozzle has been updated, the orange switching also appears in the
measuring function.
57.4.5.3 Process coupling for measurement functions

Measurement functions either use a nozzle or an inline device as process cou-
pling:
Nozzle Inline device
57.4.5.3.1 Connection via nozzle

PI| PI Pipe and Instrumentation | EN | E Elements | O4 Nozzles
+ Connections
Used with:
All measuring functions except flow measurements (“F”)
Please note: Nozzles are created in the unit structure underneath the pipe
branch, not below the function.
Data flow of substance data

The nozzle possesses a Substance data tab. The pipe branch passes on the
substance data to the nozzle, from where it is taken over in turn by the mea-
surement function.
Data flow of process data

The Process connector tab of a measuring function inherits information
from the nozzle, Technical data tab, which in turn inherits it from the pipe
branch, Technical data tab.

57.4.5.3.2 Connection through inline devices

ET I&C, Electrical Engineering| D Devices | B B Transmitters,
sensors| A B Sensors | IC B Structured at elements
(channel)| F B Flow, flow rate
Used with:
Function code “F” - flow measurement
The inline device is created underneath the measurement function.

The measurement function always takes the substance data directly from the
pipe branch.

Measurement function, the Process connector tab inherits information
from the pipe branch, Technical data tab.
57.4.5.3.3 Switching process connectors

Nozzle, System tab, PCC Alternate library object attribute
Inline device, System tab, PCC Alternate library object attribute
Effect:
The | CHANGE PROCESS CONNECTOR command appears in the context-sensitive
menu. When you select this command, the nozzle is replaced by the inline
device or vice versa.
57.4.5.4 Process coupling actuating function

Connection through a valve
PI Pipe and Instrumentation | EN Pipe and Instrumentation
| D Catalog P&ID | 04 Valves | 60 Valves
respectively PI| ANSI| D| 04| 60 Valves.
Used with:
All actuating functions
The valve is created underneath the actuating function or else is moved there
as soon as it is connected with the actuating function.

Both the actuating function and the valve take the substance data directly from
the pipe branch.


The Process connector tab of the actuating function inherits information
from the pipe branch, Technical data tab.
Valve, the Technical data tab likewise inherits information from the pipe
branch, Technical data tab.
57.4.5.5 Automatically create process coupling

When a function is placed on the diagram and connected with the process, a
process coupling can be created and connected with the function, all fully
automatically. Exactly which process coupling is created is determined in the
base object of the function on the System information tab by the PCC Pro-
cess coupling attribute.
The following parameter must be set in the options script of the report tem-
plate to ensure that the process coupling is automatically created:
EnableProcessConnection = TRUE.
The automatic creation of the process coupling can also be set separately for
measurement functions and actuating functions:
• Only for the creation of measurement functions:
EnableProcessConnectionSensor = True
• Only for the creation of actuating functions:

EnableProcessConnectionActor = True
In the case of measurement functions the process coupling is automatically

connected not only visually on the diagram but also with the function through
its connectors. That is not so in the case of the actuating function. (The reason
for this is that the valve still needs to be prepared further and be given a drive
unit. The function then needs to be connected with the drive unit.)
57.4.5.6 Number of process connectors

The number of process connectors is fixed in the case of flow measurements.
(They are connected to the process by means of an inline device.) The number
of process connectors has also been fixed for actuating functions.
However, a measurement function with a nozzle as process coupling can
change the number of process connectors that it has. The number of process
connectors determines how many PI01x Substance data and IC22x Pro-
cess connector tabs the measurement function possesses. Furthermore, the
measurement function changes its base object along with the number of pro-
cess connectors.

Example: base objects for measurement functions for density according to

EN/DIN:
@F| A1| 01| D Density: measurement function with process connector
...| 1 Density: measurement function with a process connector
...| 2 Density: measurement function with two process connectors
When you create the measurement function in the Navigator through the
| NEW mouse menu, a measurement function with base object @F| A1| 01| D
Density is created, but as yet no connectors have been prepared for it, and
hence no PI01x Substance data or IC22x Process connector tabs either.
If the function subsequently receives a process connector, it changes its base
object to @F| A1| 01| D| 1 Density and is given the Substance data and
Process connector tabs.
There are two ways to increase the number of process connectors:
• Automatically (when connecting)
If a measurement function is connected on the P&ID report, Comos checks
whether an additional process connector is required. If so, then it is created
automatically. The base object changes automatically (in the case of one
connector, to base object @F| A1| 01| D| 1 Density).
• Manually through the Properties window of the function
Specification tab: Function data measuring point ,
Attribute: Number of process connectors
The base object changes automatically after the saving.
Please note that in both cases the measurement function must possess a func-
tion code.
57.4.6 Connectors
The standard database has been prepared in such a way that initially the func-
tions are created without connectors. The connectors are only created once the
function is joined on the P&ID diagram with the process coupling (by means
of the Connector tool or the Docking function). See SECTION 57.7.5.2: WORKING
IN THE P&ID DIAGRAM. In this case Comos decides automatically what type of
connector is to be created.
The following applies: The function always takes the type of connector from
the object that it has been connected to. The type of connector determines
what kind of connecting line is to be drawn.

Caution: In the standard database there is no option to connect the functions

in the planning view for I&C engineers who only work in the Navigator! Your
administrator must modify the database in such a way that the functions
already possess the desired connectors when they are created in the Navigator.
Example:
A measurement function is connected to a pipe on a P&ID diagram. A nozzle
is created automatically as process coupling. The nozzle possesses a connec-
tor of type P&ID . The function is also given a P&ID connector and both
objects are joined through the connectors by a data line.
Special cases:
• A measurement function is connected with an actuating function; both
functions have not been connected until then and hence do not possess any
connectors: now connectors of type Single line. Simple effective line (=
action line) are created in both functions.
• On an Interactive Report of the PFD or P&ID modules, objects are
connected. One object has a connector with subtype Simple effective line
(= action line) and the other obeject a connector with subtype Medium .
Nonetheless, both objects can still be joined. The result is that an action line
is created.
“I” connector
Connectors with type P&ID are given the name “I” and hence are often known
synonymously as “I” connectors. Two connectors of the type that have been
joined together are connected with a solid line. See also SECTION 57.7.4: DATA
LINES AND ACTION LINES.
“W” connector
Connectors with type Single line. Simple effective line (= action line) are
given the name “W” and hence are often known synonymously as “W” con-
nectors. They are used to manage action line connections. These are connec-
tions between functions and devices that influence the process. They are
shown with a dotted line.
If there are several connectors of the same type, their internal numbering is
incremented (“W1”, “W2” and “I1”, “I2” respectively“).
See SECTION 57.7.4: DATA LINES AND ACTION LINES for more information concerning
connecting lines.

Finding connected objects

As opposed to other objects of object class “Device”, connected objects for
functions (object class “Device”, sub-class “Function”) are not searched for
through the “OwnConnectors” collection but instead through the “AllConnec-
tors” collection.
Connectors in I&C
In the I&C section the connectors are used in addition to transport signals and
data. To do this, the Signal from owner option must have been activated in
the Properties window of the connectors. See SECTION 64.7.1.4: CONNECTOR:
SIGNAL OF OWNER.
57.4.7 Allocating symbols
Corresponding to the type of diagram, symbols need to be assigned to the base

object of the function. This is done on the Symbols tab of the function base
object. You can either assign a symbol from the symbol library or design a
symbol yourself (using the Symbol editor). When working in the P&ID mod-
ule, symbols of the relevant P&ID diagram types should be available (depend-
ing on which standard you are working to).
%N texts for function symbols

Variable text for symbols are created by means of %N texts. In the base
objects of the example database the instrumentation symbols possess the fol-
lowing %N text:
%N I1% to %N I4%:
Determines the possible connecting points at the symbol for connectors that
have been allocated automatically. (Automated I and W connectors are not
implemented by means of text variables and hence are not visible here.)

%N Device.Label % and %N Position %:

Display variables that are replaced by the designation of the actual planning
object on the system side when the symbol is placed on a document. For that
reason the exact spelling is critical in all text functions. Blanks or spaces must
not be left out, for example.
Additional text variables

The above illustration shows only one of the possible variables (shown in
color). Caution: In the standard database, these text variables have only been
predefined in diagram type RI2 .
*V*P S:RI.ICF201*:
Evaluates attribute ICF201 Optional: Alarm diagram , which is stored with
base standard table IC| Y| 0| 02| ICF201 Alarms, which only contains
the values TRUE and FALSE. If TRUE then the following script is evaluated:
ResetToDefaults
Header.Class = "eS2"
Set p1 = Coord(0,8.75)
Font.Height = 7
DrawText p1, "%N ComosDevSpec('RI', 'ICF202a2',
'DisplayValue')%", 0, 1
Font.Height = 7
DrawText p2, "%N ComosDevSpec('RI', 'ICF202a',
Font.Height = 7
DrawText p3, "%N ComosDevSpec('RI', 'ICF202',
Set p4 = Coord(0,-3.75)
Font.Height = 7
DrawText p4, "%N ComosDevSpec('RI', 'ICF202b',
Set p5 = Coord(0,-6.25)
Font.Height = 7
DrawText p5, "%N ComosDevSpec('RI', 'ICF202b1',
Set p6 = Coord(0,-8.75)
Font.Height = 7
DrawText p6, "%N ComosDevSpec('RI', 'ICF202b2',
End Function

*V*P S:RI.ICF200*:
Evaluates attribute ICF200 Optional: Graphic for relevant adjustments ,
which is stored with base standard table IC| Y| 0| 02| ICF200 Graphic,
which only contains the values TRUE and FALSE. The following script is
processed if TRUE:
ResetToDefaults
Set p1 = Coord(0,0)
Font.Height = 6
DrawText p1, "*V*P S:RI.ICA110*", 0, 1
Set p2 = Coord(3.75,0)
Font.Height = 6
DrawText p2, "*V*P S:IC010.ICA103*", 0, 1
Set p3 = Coord(7.5,0)
Font.Height = 6
DrawText p3, "*V*P S:IC010.ICA101*", 0, 1
End Function
If the attributes are set to TRUE (meaning that the attributes have been
selected), then the subsymbols for alarm displays and relevance displays
respectively can be displayed in the diagram through scripts that are stored in
the standard tables:
• Alarm displays:
RI Presentation tab of the function: ICF201 Optional: Alarm diagram
is selected and values are input in the attributes for alarms (ICF202 ,
ICF202a , ICF202a2 , ICF202b , ICF202b1 , ICF202b2 ).
• Relevance displays:
RI Presentation tab: ICF200 Optional: Graphic for relevant
adjustments is selected. In addition, attribute ICA110 Safety relevant
(Graphic) is set to “Yes” and
IC010 Request and security tab: attributes ICA101
Quality/Environment relevant and ICA103 Calibration proofed
measurement are set to “Yes”.
The attributes can also be set in the P&ID diagram from the mouse menu:
| GRAPHICAL SETTINGS | ... See also SECTION 57.4.3.2: “RI PRESENTATION” TAB.
See SECTION 45: SYMBOL-DESIGNER for more information on sub-symbols.

57.4.8 Display on the diagram
The following forms of display have been predefined in the standard database.
57.4.8.1 Neutral function

Functions whose base objects stored directly under the @F Functions level
(for example, @F | A1 Functions acc. to EN/DIN), so-called neutral func-
tions, are displayed as follows:
Function code:
Is taken from the label (Label). Since this is empty for neutral functions, the
Name is displayed.
Device label:
As a rule, only the name of the position and of the function are displayed. The
Fullname of the position with unit or subunit is only displayed if the flow
sheet has been allocated to another plant or to another unit/subunit than the
function.
57.4.8.2 Basic symbol

The display of a function on the diagram is controlled by:
The IC110 Function data measuring point and Function data actuating
point tabs:
Attributes ICF101 Processing with and ICF102 Output and operation .

The symbol on the diagram is adapted automatically, depending on which

attributes had been set:
• Shared display/control
That is “type 4” according to DIN
• PLC
That is “type 5” according to ANSI
• Primary location
That is “type 4” according to ANSI
The attributes can be set in one of two ways:
1. Properties window
The display of the function on the diagram is controlled through the
Properties window of the Specification tab Function data function.
2. Mouse menu
The attributes that are responsible for display are set with the mouse
menu of the diagram:
Select the function on the diagram, | GRAPHICAL SETTINGS| OUTPUT AND
HANDLING mouse menu and ...| PROCESS WITH.

57.4.8.3 Optional graphics

In the case of measurement functions, optional sub-symbols can be shown for
the alarm and relevance displays in addition to the basic symbols:
The optional graphics are set through:

• the Properties window of the function:
Relevance display: RI Presentation and IC010 Request and security
tabs.
Alarm display: RI Presentation tab
• mouse menu of the P&ID diagram:
Select the function and activate the desired form of display from the mouse
menu by means of | GRAPHICAL SETTINGS.
See SECTION 57.4.3.2: “RI PRESENTATION” TAB and Additional text variables, P. 57-39 for
more information concerning this.
57.4.9 Scripts
The following scripts have been input at the base object of a function on the
Script tab:
“Connect”
Call: when joining the connectors, thus, for example, when connecting the
function on the P&ID.
Task:
Measurement function: Connect only calls up the SetCDev function from
UserScriptBlock1. Please note that if a function is connected with a process
device (pipe, piece of equipment), the process connector is automatically gen-
erated and connected dynamically. Thus in this case Connect is called up as
well.
Actuating function: Connect calls up ConnectedObjectAsChild. An “I” con-
nector or a “W” connector is created at the function, depending on the context.

Compare SECTION 57.4.6: CONNECTORS.
“DisConnect”
Call: when disconnecting two connectors. If the number of process connec-
tors is thereby reduced, then the connectors are separated as well. Thus Dis-
Connect is called up as well. Only with measurement functions.
Task:
DisConnect calls up function SetCDev from UserScriptBlock1.
Commenting of line 4: Workset.Lib.Elo.DelChapterByConIndex
"PI010",Connector
Safety prompt for a case in which measurement and actuating functions have
been mixed (there are separate branches in the Release DB). “PI010” is the
substance data of the actuating function. This tab is not required for the mea-
surement function and can be dispensed with.
“OnEditOk”
Call: when the [OK] or [ACCEPT] buttons are pressed in the Properties window.
Only for measurement functions.
Task:
Measurement function: OnEditOk only calls up function SetCDev from
UserScriptBlock1.
“OnReferencedByDevice”
Call: when creating the function and at each change of base object.
Task:
Measurement function: when the function is created, it takes the first letters
of the label of the position and thus becomes a suitable measurement function.
If a mask is defined for the label at the base object, the mask wins out.
After that, SetCDev is called up from UserScriptBlock1. The base data can
be simplified in this way: The same neutral functions are always located
underneath the positions and the appropriate measurement function is created
as a result of automatically taking over the label (and the subsequent change
of base object in UserScriptBlock1).
Actuating function: Analogous to the measurement function, but here the
actuating function takes the first letters of the label of the position and
appends a “V” onto them.

“UserScriptBlock1”
Measurement function:
Call:
1. If the label has been changed. The label is taken over into attribute
ICF100 Function . This attribute is queried in SetCDev.
2. If the number of process connectors has been changed. The process connec-
tors are controlled by the CProcess number of process connectors
attribute.
Task:
1. The script determines which position base object becomes the owner of the
function (in the case of functions according to EN/DIN: @P|02, for functions
according to ANSI: @P|03 etc.).
2. The script passes on the label and the number of process connectors to the
SetCDevBySpecs function. The result is that there is a change of base object
if necessary:
The label has determines which base object underneath @F Functions
| A1 Neutral function | 01 Measurement functions will be used for
the function planning object.
The number of process connectors then controls whether the direct successor
is used or whether to go one level deeper.
Example for density:
Label “D”; process connectors not set or “0”:

Base object 01 Measurement function | D Pressure
Label “D”; process connectors “1 ”:
Base object 01 Measurement function | D Density | 1 Density
Label “D”; process connectors “2 ”:
Base object 01 Measurement function | D Density | 2 Density
Actuating function:
The script determines which base object becomes the owner of the function
(see above).

Vessels P&ID module
“UserScriptBlock2”
Task: Inserts the following attributes into the mouse menu for the functions:
ICF101 Processing with
ICF102 Output and operation
57.5 Vessels
PFD vessels can possess hierarchically subordinated objects, such as nozzles.
(These objects are also hierarchically subordinated in the Navigator, under-
neath the vessel.)
If the vessel is marked on the diagram, then all the objects of the diagram that
are hierarchically subordinated are automatically marked as well. (“Auto-
matic multiple selection”)
If an automatic multiple selection is made, the “Properties” mouse menu com-
mand continues to be available. The command opens the properties of the ves-
sel.
The properties of the hierarchically subordinated object are available if the
subordinated object itself has been marked (individually).
In the Comos standard database vessels have class Position , sub-class Equip-
ment . (See also SECTION 57.3: POSITIONS regarding positions.)
57.6 Templates and definitions
57.6.1 Project settings - Module options tab
Base object for In the Base object for Pipe/streams field you can
Pipe/streams stipulate project-wide which base object is to be
allocated to the pipes or streams. This option can then
be redefined in individual cases by an allocation in
script form in the options block of the report
template. This then applies for all reports that are
based on this template.
Syntax:
CObjectFullNameForPipe =
"Obj.SystemFullName"
Example:
CObjectFullNameForPipe = "@1PE|OB|10|BL"

P&ID module Templates and definitions
implementation This involves a system setting that cannot be

Name changed, one which determines the key term by
which the implementations of a PFD are marked as
belonging together.
Disable The Switch off automatic generation of Comos
automatic connectors option turns the automatic creation of
generation of connectors on and off. If the option is selected, no
Comos connectors are generated when, for example, pipes
connectors are connected with devices or vessels on the report.
Global Comos variables

Incorporation of a rotation correction factor for PFD symbols when opening
a P&ID document. Activation is only possible if you have produced a global
Comos variable, with the script debugger, for example. Procedure:
1. Drag the project (the blue globe) into the script debugger (here position
A)
2. Create a script with the following line:
A.workset.globals.CorrectRIRotation
Comment: The activation is turned off when Comos is ended.

Incorporation of a scaling correction factor for PFD / P&ID symbols when
loading a P&ID symbol script in the Symbol menu section. Activation is only
possible if you have produced a global Comos variable, with the script debug-
ger, for example. Procedure:
1. Drag the project (the blue globe) into the script debugger (here position
A)
2. Create a script with the following line:
A.workset.globals.RiConversionScale = 0.8
Comment: The activation is turned off when Comos is ended.
57.6.2 Report templates
SetPipeFlagOnCreate
BOOLEAN, Default = FALSE. If TRUE, the default pipe flag is displayed
automatically on generating a pipe.

Templates and definitions P&ID module
57.6.3 Properties of a P&ID report
If blank P&ID reports open relatively slowly (five seconds or longer), you
should check the following setting:
Properties window of the report, deactivate the “Substance stream bar - appa-
ratus“ tab and the “With apparatus head“ and “With substance stream bar“
options (no tick should be visible).
57.6.4 Attributes for pipes
Certain options such as line thickness, color, line type or also the position in
the substance stream bar can be controlled by means of attributes. This is done
by creating a Specification-tab (under the base objects) with the name “RI”
that contains specific attributes.
For pipes this would be, for example:
BREADTH
Type of Display Edit
Description Line thickness
Name BREADTH
Value [List]
Format, length, unit -
Type Numeric
Standard table @LOGO_BREADTH
Edit mode Can be edited - normal
Base specification @3 |@RI |@PIPE |RI |BREADTH
Table 57-1: PFD / P&ID attribute BREADTH
COLOR
Description Color
Table 57-2: PFD / P&ID attribute COLOR

P&ID module Templates and definitions
COLOR
Name COLOR
Value [List]
The value “- 1” is input into the attribute if a
color is set manually. The Windows color code
is stored internally. The color that had been allo-
cated to the object on the Interactive Report then
applies. The color value in the attribute can of
course be reallocated at any time. This color
value corresponds to the Logocad color code
and is taken from the corresponding standard
table of values.
Type Text
Standard table @LOGO_COLOUR
Base specification @3 |@RI |@PIPE |RI |COLOR
Table 57-2: PFD / P&ID attribute COLOR
LNTYPE
Description Line type
Name LNTYPE
Value [List]
Type Text
Standard table @LOGO_LNTYPE
Base specification @3 |@RI |@PIPE |RI |LNTYPE
Table 57-3: PFD / P&ID attribute LNTYPE

Templates and definitions P&ID module
PS
Description Position in the substance stream bar
Name PS
Value [List]
Type Alphanumeric
Standard table @AppKpf
Base specification @3 |@RI |@PIPE |RI |PS
Table 57-4: PFD / P&ID attribute PS
@IRF_RI
To manage the text functions that are made available in the Symbol editor.
@LOGO_BREADTH
Line thickness
@LOGO_COLOUR
Colors
@LOGO_LNTYPE
Line types
@PIPECONSYMBOL
Page reference symbol for pipes
@PIPEENDSYMBOL
Pipe end symbols
@CONNECTIONTYPEI

P&ID module Using P&ID
When a data line is generated, the graphic properties for the line are read from
the standard table for system project @ConnectionTypeI. Changes in the stan-
dard table do not affect data lines that have already been created, but only new
ones that are created from then on. The values are given in the table in the fol-
lowing order:
Value1= Label (subtype of type single line)
Value2= Line thickness in mm
Value3= Line type
Value4 to Value6= RGB colors (order: R-G-B)
@1RI |I Presentation |I Colors

In the standard database there is standard table |@1RI |I Presentation
|I Colors, in which the automatic colors of PFD / P&ID objects are stipulated.
Pipes also make use of this entry.
Please note:
All objects placed on PFD / P&ID reports that have counterparts that were
created in the Comos database underneath the report (for example, when base
objects are dragged directly onto a PFD / P&ID report), are shown in blue.
Otherwise the color displayed is the one that was stipulated in the properties
on the Display tab.
57.7 Using P&ID
57.7.1 Importing AutoCAD data
AutoCAD drawings can be imported into a P&ID report simply by pulling

them onto the report with drag & drop.
57.7.2 Process units
Process units are organizational units that are used to resolve a user-defined
process technology task.
Pull the process units onto the diagram with drag & drop. The process units
are symbolized with captioned boxes.
Open the properties window to change the name that had been generated auto-
matically:

Using P&ID P&ID module
• Right-click on the object.

• Select the | PROPERTIES mouse menu.
• Enter a meaningful description for use in Name .
The size of the symbols for the process units can be changed.
57.7.3 Defining streams
Substance streams are managed as Comos objects and possess as such all the
usual properties (attributes, connectors, etc.). Substance streams are thus
aligned objects, they begin at the first mouse-click point, end at the second
mouse-click point and are given a direction arrow (direction of flow).
57.7.4 Data lines and action lines
If a function is connected with an object, only deviceless connections are cre-

ated (connections of group “data line” or “action line”).
Whether a data line or an action line is created depends on the type of connec-
tor of the object that is used to join the function. The following applies:
• Action line: this is created between two connectors of type Single line.
Simple effective line (= action line).
• Data line: this is created between two connectors of type P&ID , or of type
Single line. Medium .
See SECTION 57.4.6: CONNECTORS regarding the connectors of a function.
If a measurement function is connected to a device by means of a data line,
the direction of the line is always from the device to the measurement func-
tion. If an actuating function is connected, on the other hand, the user must
check for himself whether the connection points in the right direction.
If two objects are connected on an Interactive Report of the PFD or RI mod-
ules, and one object has a connector of subtype Simple effective line and the
other one of subtype Medium , then these objects can be connected neverthek-
ess. As a result an action line will be created.
When creating a deviceless connection, the graphic properties for the line are
read from the standard table of system project @ConnectionTypeI. See
SECTION : @CONNECTIONTYPEI.

57.7.5 Working with functions in the planning view
57.7.5.1 Overview
First of all the function needs to be created. Functions can be created within
the Navigator in two ways:
1. Mouse menu of a position according to DIN/IEC: | 04 ASSEMBLY GROUPS
(FUNCTIONS WITH SIGNALS)
This menu creates measurement functions with signals. (This menu item
will usually be used if functions are still missing at the beginning of the
I&C planning phase.)
2. Mouse menu of a position according to DIN/IEC: | 01
MEASUREMENT FUNCTIONS, | 02 ACTUATING FUNCTION and | 03
NEUTRAL FUNCTION or the corresponding menus of a position according to
ANSI:
Measurement functions and actuating functions, plus neutral functions,
are made available here.
The function is created in the Navigator underneath the position.
See SECTION 57.3.2: CREATING POSITIONS regarding the creation of positions.
In both cases, the function still needs to be equipped with a function code and
needs to be connected to the process. This is done by linking the function to a
process coupling by means of process connectors. Place the relevant function
on a P&ID report or alternatively you can work within the Navigator.
In the case of actuating functions it is also necessary to take into consideration
whether the associated actuating device still needs to be created.
Alternatively, the function can also be created directly on the P&ID diagram.
See SECTION 57.3.2: CREATING POSITIONS.
57.7.5.2 Working in the P&ID diagram

See SECTION 57.4.8: DISPLAY ON THE DIAGRAM regarding the display of functions in
P&ID diagrams.
Measurement function
Open the P&ID diagram that is located underneath the subunit and drag the
function from the Navigator onto the diagram by using drag & drop. Link the
function with the process by means of the Connector tool.

If the administrator has prepared a process coupling at the base object of the
function as part of the preparation for the project (see SECTION 57.4.5.5: AUTOMA-
TICALLY CREATE PROCESS COUPLING), the process coupling is automatically created
as well when the function is connected (nozzle, or inline device in the case of
flow measurements). The function and the process coupling are automatically
joined with one another through their connectors (see also SECTION 57.4.6: CON-
NECTORS).
The result of the connection: new tabs are created at the function, on which
the data regarding the process connector is saved, See SECTION 57.4.5.1: CREA-
TING A PROCESS CONNECTOR and SECTION 57.4.5.2: DATA FLOW.
A solid objectless line is created – a so-called “data line”. The connection

always goes from the process coupling to the measurement function. (If they
were connected in the opposite direction, the line is turned around automati-
cally.)
Actuating function
The same applies to the actuating function: the process coupling (= valve) can
be created automatically when connecting with the process. But since the
valve still needs to be prepared further, the following procedure can be used:
• Drag the desired valve from the icon bar of the diagram, if it does not exist
there, from the base data onto the diagram. Valves are located under the
following branch in the base data of the standard database:
PI Pipes and instrumentation| EN | D Catalog P&ID| 04
Valves| 60 Valves, respectively PI| ANSI| D| 04| 60 Valves
• Select the valve on the diagram and prepare it further by using the
| GRAPHICAL SETTINGS mouse menu. Provide the valve with a drive (select
one from the | GRAPHICAL SETTINGS| ACTUATOR mouse menu):
The valve and the drive are created in the Navigator underneath the report.
• Next, create the actuating function. In the standard database, no icons for
actuating functions have been predefined in the icon bar of the P&ID report.
Thus simply click on the desired position in the Navigator and select an

actuating function by using the | NEW mouse menu of the position. The
actuating functions are sorted within the menu by the valves that are to be
created underneath them:
Alternatively, you can also switch to the base data tab of the Navigator and
drag a suitable base object onto the diagram from under branch @F| A1| 02
Actuating function (or @F| A2| 02 Actuating function ANSI
respectively) by means of drag & drop.
• Join the actuating function with the drive unit of the valve on the diagram
by using the Connector tool. A dotted objectless line is drawn – a so-called
“action line”.
Caution: you need to check for yourself whether the connection points in the
right direction.
The objects are automatically connected in the database as well through
their connectors. See also SECTION 57.4.6: CONNECTORS.
The result of the connection is that the function now possesses a process
connector. See SECTION 57.4.5.1: CREATING A PROCESS CONNECTOR and
SECTION 57.4.5.2: DATA FLOW.
After connectin actuating function and valve, the valve and its drive are
moved underneath the function in the Navigator.
57.7.5.3 Working only in the Navigator

Connecting a function with the process only through the Navigator is some-
what more complicated than the method using the P&ID diagram.
Creating a process coupling

First of all you need to create the process coupling underneath the function.
The process couplings of measurement functions are located in the base data
under the following branches:
• Nozzle: PI| EN| E| 04| 01| 02 Nozzle for pipe, respectively
PI| ANSI| E| 04 | 01 | 02 Nozzle for pipe
• Inline device: ET| D| B| A| IC| F Flow, flow rate.

In the case of actuating functions the process couplings are under:

• PI Pipe and instrumentation| EN | D Catalog P&ID | 04

Valves| 60 Valves, respectively
PI| ANSI| D| 04| 60 Valves
The valves have been configured in such a way that they can also be used as
actuating devices.
Open an additional Navigator and create the process coupling by dragging the
desired base object onto the Units tab, beneath the function.
The standard database has been predefined in such a way that the valves can
also be created by using the | NEW mouse menu of actuating functions:
Actuating function: prepare valve

The required attributes are set in the Properties window of the valve, Acces-
sories tab. In addition, a drive unit still has to be created underneath the
valve. In the standard database drive units have already been predefined in the
| NEW mouse menu of the valve:
Their base objects are located under:

PI| EN| E| 01 Y actuators for valves and PI| ANSI| E| 01 Actua-
tors for valves respectively.
Connecting and creating process connectors

Next, the measurement function and the process coupling, respectively the
actuating function and the drive unit need to be connected to one another. This
is done through the connectors of these objects. The connectors must already
have been created beforehand by the administrator in the base data. See also
SECTION 57.4.6: CONNECTORS.

The result of the connection: new tabs are created in the function, storing the
data on the process connector. To some extent, these tabs receive the data
from the process. See also SECTION 57.4.5.1: CREATING A PROCESS CONNECTOR and
SECTION 57.4.5.2: DATA FLOW for further information.
The number of process connectors increases with each connection that is

made. See also SECTION 57.4.5.6: NUMBER OF PROCESS CONNECTORS.
57.7.6 Opening process units / further level
The individual processes can be run once the basic flow sequences have been
described in the form of process units and substance streams.
Open a process unit by double-clicking on it.
The result is that you are given a new diagram on which only the selected pro-
cess unit can be seen. The incoming and outgoing parts are shown by broad
arrows:
The incoming and outgoing parts are shown. For

that reason the superordinate substance stream
should already have been created.
All the elements can be positioned within the process unit, these being process
units, substance streams, instrumentation.
Once you have completed all the inputs, close the window by clicking on the
Close symbol (a cross) and reply with Yes to the Save query.
Whether or not the objects on the inside of a process unit are displayed at the
higher level depends on the object used or the setting. However, the objects
on the inside of a process unit can only be changed when the process unit is
opened by double-clicking on it.
57.7.7 Hierarchical structure of the P&ID planning data
When base objects are dragged onto a P&ID, the planning objects that are
generated as a result are initially located underneath the report. However, on
a long term basis the planning objects ought to be sorted to make up a mean-
ingful structure.

57.7.7.1 Object assignment
Allocate a new storage location in general

• Mark the objects in P&ID
• Select the “Assign object” tool
• Drag a frame around the objects
• Pull a unit from the planning data onto the marked objects by using a drag
& drop operation.
The result is that the marked planning objects underneath the report are
removed and sorted under the unit.
Thus the hierarchical structures of P&ID planning data are often set up on the
basis of the “Unit | Class” scheme (for example, in the KKS [German power
station labelling scheme]): here the topmost levels are units and sub-units, fol-
lowed by a structural level “Sequential number”, and then the object or device
classes depict the subsequent levels in the tree structure.
The various modes of the “Assign object” tool are documented in Quick Start
P&ID.
57.7.7.2 Categories
Labelling a unit as a “category”
With the help of “Categories”, components can also be divided automatically
into these classes instead of just being assigned globally to a unit. Categories
fundamentally use two items of information: specific units are labelled as cat-
egory and specific objects are given a fixed item of information, this being the
category that they would belong to.
There is the sub-class “Category” for class Unit. A unit will only be treated
as a category if it possesses this sub-unit, otherwise it will not be.
Stipulate within the objects which base object they will belong to
An attribute is created in the base data for the P&ID base objects:
Categorie_Name
Input in this attribute the name of the unit / category that the object is to belong
to.

P&ID module Interfaces
57.7.8 Search strings and cross references
Search strings can be created and executed for pipes and pipe segments that
display planning objects. Use the | SETTINGS | SEARCH TEXT mouse menu to get
to the screen.
Measurement functions and data lines (multiple connections without objects)
can be connected to one another through cross-references if you create on
each page the corresponding connections that are open on one side. Subse-
quently these can be selected and called up via the | CONNECT | MARK popup
menu, and the other connection is allocated via | CONNECTION CONNECT WITH...
These connections can be broken as usual with | BREAK ...
57.7.9 Expand graphic options
The GRAPHIC OPTIONS mouse menu can be used in a user-defined way if the
corresponding variable has been defined by a script in the base object.
For example:
DIM ADDTOGRAFICALPARAMETERRI (4)
ADDTOGRAFICALPARAMETERRI (0) = “AUSLEGUNG.RI_VENTA”
ADDTOGRAFICALPARAMETERRI (1) = “AUSLEGUNG.RI_ARMSTELLV”
The result is that the corresponding attributes appear in the mouse menu. You
can find further examples under valves and fittings in the example database.
57.8 Interfaces
The interfaces can be addressed via the corresponding base objects:
@1PE | US | FI |SIMD Simulation Data
| Aspen Simulation and
| Pro II Simulation.

Interfaces P&ID module

Tools for EMR RUPLAN import
58 Tools for EMR
58.1 RUPLAN import

This documentation will soon be available.
58.2 Importing ECAD components

Importing partial stocks of data from the ECAD catalog into existing or new
Comos objects.
Prepare import
The import operation is based on the control table in the base project
@1EA Catalog EE | Import
that you can open via | ADMINISTRATOR | BASE DATA | STANDARD TABLES.
The attributes from ECAD are allocated to the Comos attributes in this stan-
dard table. There is no technical necessity for a 1-to-1 matching. The standard
table is made up as follows:
Column 1: Name
Each row of the standard table requires a unique name, but it does not matter
what the name is. As a rule, the name of the attribute is used here.
Column 2: Description
This stipulates how the Comos attribute is to be described, i.e., which entry is
to be given in the “Description” field. Please note: This column is not updated
automatically. If the descriptions of the attributes are changed, the new
descriptions must be input here manually. In any case the value in this column
is solely used for information purposes, the import procedure also functions
if incorrect entries were made here.
Column 3: Symbol
(Not used for ECAD import. In general, a symbol that is used for the Comos
object can be created here.)
Column 4: Value1
Full name of the Comos attribute used in the import (including the name of
the tab). The Comos attributes are in the base project in:
@Y Catalog spezifications |ET Electrical engineering
|1 General chapters
Column 5: Value2
Name of the allocated ECAD attribute.

Importing ECAD components Tools for EMR
Column 6 and subsequently: Other imports that have no meaning for ECAD.
If necessary, you can adapt the this list to meet the requirements of a particular
company.
Preconfigured import
When text files are created in ECAD format, each line of text has an initial
marker (“tag”). The following tags are recognized and imported:
• NO (main components)
• TD (technical data)
• ZB (accessories); can be controlled via options, see below for more details.
• DD (= attributes under manufacturer on the Product Data tab)
K1 data records (channels) are also imported. The following types of
channels are recognized to date: COIL, MAIN, AUX, PRIM, SEC, UNI and
PCL.
Making the import

Use the | ADMINISTRATOR | BASE DATA| ECAD COMPONENTS IMPORT command
to open the following small dialog window:
File
Select a vrg file.
Target
Set within the Target field by drag & drop underneath which branch the data
is to be created. In other words: You must import one block of manufacturer
devices at a time under the relevant branch for the request object. New objects
are created underneath this target node or else the attributes are updated in the
case of existing objects.

Tools for EMR Change per rule: name / label
The import procedure (adapting the data structure and the attribute values) has
been set up in such a way that the import function can also be used to update
data that has already been imported.
The options
Read accessories
Lines with the ZB tag are imported and created under the main components
(NO tag).
Accessories are devices that are available for a specific other device but are
not administered individually. Accessories are thus used as an element on the
Elements tab of another device from the „catalogs“. The main reason for
adding accessories to another device as an element is that you can thus auto-
matically create complete ordering lists.
Log all
A log file is created when an import operation is carried out. This file is
located in the same directory as that of the file to be imported. The file name
of the log file is made up of the name of the file to be imported, a sequential
number and the file extension “.pcl”. The log file is always created from
scratch each time.
Off: Only errors are logged.
On: The entire import operation is logged, giving the details of which objects
were created, what information was written into them, etc.
ASCII-ANSI character set conversion
An ASCII character set is converted to ANSI by means of the Windows rou-
tine.
The import process is shown with a progress bar display.
58.3 Change per rule: name / label

You can open the dialog window via | EXTRA | DETAIL | CHANGE PER RULE.

Change per rule: name / label Tools for EMR
The dialog window is used to automatically detect the regularities of Label

and to process them in numeric order.
You determine in the two top edit fields which objects are to be investigated
(initial quantity). An entry must be made in both fields to do this:
Owner : This field determines in which branch a search is to be made for the
objects.
Prototype : The lower field is an example and determines what kind of fields
are to be searched for.
In the simplest case you drag an object into the lower Prototype field; this
automatically sets the current owner of the prototype in the upper Owner
field.
However, in principle the two fields are independent. You can select a start
object in the Owner field and then the prototype that is entered in the lower
can be taken from a completely different branch.
At the very bottom you can see which text mask the system has determined.
These details are only given for information and cannot be changed. The
details of whether a text mask has already been defined in the base object, and
if so, which one, are given in the Base object column.
Details of which mask is used as the basis for the renumbering of the text
masks are given in the Edit mask column. In other words: Even if no details
have been given in the Base object column, an entry can be seen in the Edit
mask column. In this case the system has attempted to determine an Edit
mask by itself.

Electrical Engineering Base data, lists, templates
59 Electrical Engineering
59.1.1 Devices (planning objects)
All devices related to electrical engineering are grouped together in sorted

branch @1EA Catalog EE:
All the devices in this branch possess certain basic properties that are
explained in the following section, SECTION 59.1.1.1: “SIMPLE” DEVICES.
In addition, there are objects that bring with them additional properties and
capabilities. These special devices are explained in detail individually in the
following sections.
59.1.1.1 “Simple” devices
59.1.1.1.1 DIN labels

The devices are sorted in accordance with standard DIN 40719 and given the
corresponding letters at the first position:
@1EA Catalog EE
-| A Modules
-| B Converters
-| C Capacitors
-| D Binary elements
-| E Misc.
-| F Protective devices
-| G Generators
-| H Signaling devices
-| L Optical indicators
-| A Illuminated indicators
etc.

Base data, lists, templates Electrical Engineering
These DIN letters are also created as well for the planning objects. There is a
text mask on the System tab of the base object for this purpose. Here is an
example for a general PLC:
The letter “A” used in compliance with DIN is also used together with a count
to make up a name in a planning object.
59.1.1.1.2 Symbol
All simple devices possess one or more symbols on the Symbols tab. Dia-
gram types “DETAIL ”, “GRPLAN ” and “SLINE ” are provided with symbols
as a rule:
These symbols can be modified if required. Please note that the symbols are
inherited down the hierarchy.
The scripts may not be modified in the case of DESIGN diagram types. Here
they do not use symbols, but instead a form of automatic display calculation
for 2D design plans.
The symbols for the diagram types initially have a fixed size and are opti-
mized for a particular grid and scale. However, various options can be used
so that the symbols can also be used on reports with a different grid and a dif-
ferent scale.

Each symbol has a placing point that is used for positioning on the grid. The
placing point is only seldom at the top left-hand corner, but is created such
that the connectors lie on the grid.
Text symbol
A text symbol is created at the topmost node in branch @1EA:
This text symbol is inherited by all base objects underneath it, but it is not
evaluated in all base objects, however. It is only evaluated in the case of base
objects that call up the text symbol by means of *V* P Txtpoint*. See
SECTION 45.4.2.1: TEXT SYMBOL for more information concerning text symbols.
The EE text symbol outputs the following information:

• Device tag
• Own description
• The first attribute of the “Technical data” tab that has a unit
• Attribute HSD.001 . Where HSD is the “Manufacturer data” tab and 001
is the “Part number ” attribute.
Additional symbol / placeholder texts

*V*P CD: <Base object>*
Thus the object function allows additional graphics to be incorporated via the
base object structure. The SystemFullName of the base object is used as the
parameter, whereby the individual hierarchy levels are separated by periods
(full stops) as appropriate. Example: @1EA.A001.
Placeholders can be rotated just like any other type of text so that they are eas-
ier to read. Normally a rotation of the text in this way has no effect on the
object to be placed, and hence the object always appears in the direction of the
template.

If the rotation of the text is to affect the rotation of the object to be placed, the
following option must be activated in the project properties:
Tab Module options sub-card | Detail :
Option Consider rotation of *V* variables .

According to DIN, connectors may only have one connection. Thus in Comos
each connector can only have one counterpart connector.
In practice, it can happen that multiple connections are made to a terminal, for
example. Auxiliary connectors can be created to allow such a case to be
shown as well in the planning data.
Auxiliary connectors always relate to an existing connector. Auxiliary con-
nectors are given in the ConnectorName field with the name of the existing
connector plus a counter, such as [1], for example.
59.1.1.1.4 Attributes and calculated attributes

Each device is provided with its own special attributes on the Specification
tab . The attributes are inherited hierarchically and are supplemented or mod-
ified by additional ones at each level, if required. As an example, base object
@1EA | E Various.:
One level deeper is base object @1EA | E Various | L Illumination

system. There the attributes are extended:

Attributes that can be set centrally are also managed centrally. There is the
“catalog” @Y Catalog attributes | EE Electrical Engineering for
this purpose. The catalog attributes are only called up for EE devices:
59.1.1.1.5 Request property

The base data is prepared to the extent that the “Request and implementation”
technology can be used.
The Request property is activated at the higher levels for this purpose:
The real devices are incorporated at the “lower levels” and the Request prop-
erty is deactivated there.
Use the | ADMINISTRATOR | BASE DATA | ECAD COMPONENTS IMPORT command
to import manufacturer devices. See SECTION 58.2: IMPORTING ECAD COMPONENTS.
59.1.1.1.6 Product data

The base data is prepared to the extent that the “Product data and real device”
technology can be used.
This is done by creating Technical data attributes with the Product option
on the Specification tab. The Manufacturer attribute is relevant to the prod-
uct data on the Manufacturer data tab.
See SECTION 61: PRODUCT DATA AND MANUFACTURER DEVICE for further information
on this.

59.1.1.2 @1EA Catalog EE |- I Potentials

@1EA Catalog EE | I Potentials
Output: Potentials are not normally displayed in parts lists.
59.1.1.2.1 Logical potential

Class Device , sub-class Logical potential
Goal
A logical potential is an additional piece of information concerning an elec-
trical connection, in just the same way as the information on the wire.
As opposed to potential objects (physical potentials), potentials do not pos-
sess any connectors of their own. The information has its origin in a connector
(a protective device, as a rule). They are passed on to the connections by
means of cross-references and terminals. (This passing on of information can
be switched off by a parameter in the project options.)
Control of the extended capabilities

No extended capabilities.
Application
• Create the logical potential as a planning object.
• Open the device in the Navigator or the Properties window of the device.
• Drag the logical potential onto the connector or
drag the connector onto the logical potential.
Effect:
• The logical potential is shown at the connector within the Navigator. The
| COLUMNS | LOG. POTENTIAL mouse command on the Connectors tab in the
Properties window of the device must be used first of all. The logical
potential is displayed in the new column.
• In the diagrams the label of the logical potential appears at the potential
object (mode: read) and at all open connections.
Placing potentials on connections

There is also the alternative by which you first bring up the potentials within
the Navigator and then allocate these to a connection. For example, fuses are
always automatically provided with potentials. Thus you also have potentials
available when you create a protective switch within the Navigator.

Mouse-click on the Allocation tool (the box with the arrow pointing
downwards)...
... and drag the potential onto the connection:
You are then given all the connectors located at this potential. Only one con-
nector is available in the example, this being connector A1T1 . This one con-
nector is offered in the box.
You will of course get nothing if there are no connectors at the potential yet.
In the above example precisely one connector is available. You can simply
mouse-click on one of the connectors to produce the connection.
Please ensure that you use the Allocation tool for this.
Naming syntax
The name of the logical potential that has been set is input on the Connectors
tab in the Log. potential column. Another character can be input before the
name, this often being a minus sign. This involves a prefix, and thus the sep-
arator that was input in the project options.
An asterisk can appear after the name. The asterisk only appears for exactly
one object: the “start object”, namely, the object from which the logical poten-
tial has its origin. Thus you can tell at once whether the information about the
logical potential was only taken over (“inherited” via the connector) or had
been defined here.
Disconnect logical potential

The | COLUMNS | LOG. POTENTIAL mouse command on the Connectors tab in
the Properties window of the device must be used first of all. The logical
potential is displayed in the new column.
The logical potential can only be removed again here, in the Log. potential
column. Do this by using the | DISCONNECT mouse menu command.
Connectors / display
Logical potentials do not have any connectors, since they are not intended to
be placed on a report.
If nonetheless a logical potential is to be placed on a report, then the informa-
tion that is output at the end of the cross-reference is taken from description
@System |@Connection. If you wish to see another text or an additional

graphic or format the text differently, you then need to change the correspond-
ing entry in this description. See also SECTION 59.1.4.3.3: BASE PROJECT @SYSTEM
|@CONNECTION.
Predetermining logical potentials

Connectors can be prepared in such a way that the allocation of a logical
potential already exists when the planning object is created.
See SECTION 59.7.1.7: PROVIDING CONNECTORS WITH LOGICAL POTENTIALS BEFOREHAND.
59.1.1.2.2 Physical potential

Class Device , sub-class Potential
Goal
Physical potentials are set on the report or in the database like a busbar: as
many outlets as are wanted can be made available at any desired point, since
all of them have the same current potential.
The potential is often created under a location, since the potential has to sup-
ply the location with electricity. However, in principle a potential can be cre-
ated anywhere.

Control by Comos as soon as a base object possesses the sub-class Potential .
The name can be anything that you wish. A symbol is not created but is sup-
plied through the sub-class.
Connectors
A typical feature of potentials is that they do not have a fixed number of con-
nector points but can be connected to any desired number of devices. For that
reason potential objects are only set up with one connector and as many aux-
iliary connectors as there are to be devices to be connected to the potential are
created.
Thus auxiliary connectors are created automatically as a rule:
• Alternative 1: Create on the report a new outlet for the physical potential by
making a connection.
• Alternative 2: Drag a free devices connector onto the Connectors tab of the
potential.
Auxiliary connectors can of course also be created manually by means of the
mouse menu.

Potential chains / master-slave potentials / cross-references from potentials

There are two ways to organize potentials across reports:
• Chain
Physical potentials are initially created as a chain. Thus all the potentials are
equal. The order of the chain is stipulated in the project parameters.
• Master / Slave
Alternatively, potentials can have a “master-slave” relation. In this case all
the potentials relate to a master potential.
You can switch between these two options:

| OPTIONS...
CHAIN -> MASTER / Converts a chain into a master-slave relation-
MASTER->CHAIN ship or back again as applicable. This option
is only available for the master potential.
START OF CHAIN This potential is set at the start of the chain
with START OF THE CHAIN, the additional
members of the chain are calculated automat-
ically.
SLAVE->MASTER Specifies this slave as the new master poten-
tial.
The two options determine where the “label” is output initially.

• Master: label on the right
• Slave: label on the left
• Chain: on both sides.
Differing from the above, the label can be switched on or off at either side by
means of the mouse menu:
| OPTIONS...
LABEL RIGHT Turns on the label at the right-hand end. The
name is displayed if there is no label.
LABEL LEFT Turns on the label at the left-hand end. The
name is displayed if there is no label.

Functions PotName, PotDescription, PotUnit and PotLocation are avail-

able for cross-references for potentials. The functions work in the same way
as the DevUnit and DevName functions.
Prolongation
Potentials can have a prolongation that extends beyond the grab points. This
prolongation is controlled by the variable PotentialProlongation in the
options script of the template file. The default setting for the variables is zero.
The prolongation is only visible when the label is switched off at the relevant
line ends. Do this by marking the potential and selecting the | LABEL RIGHT
(the hook is turned off) or | LABEL LEFT command as appropriate from the
mouse menu.
Display and application on the report

The physical potential can have one or more outlets at any position, whereby
the outlets are aligned to the grid just like all the other objects. Each new outlet
requires an additional connector.
Alternative mode of display:
The potential is displayed as a point from which there is an outlet. One of the
two grab points can be dragged onto the other. In this case the display of the
left-hand label is deactivated, otherwise the two texts would be superimposed.
Adapting cross-reference symbols and cross-reference texts

The information that is output at the end of the cross-reference is taken from
description @System |@Connection. If you wish to see another text or an
additional graphic or format the text differently, you then have to change the
corresponding entry in this description. See also SECTION 59.1.4.3.3: BASE PROJECT
@SYSTEM |@CONNECTION.
59.1.1.3 K Relay, contactor

@1EA Catalog EE |– K Relays, contactors.
Goal
Application on the report as a relay or contactor, including a tabular listing of
the connector points (contact mirror).

Control by Comos:
The base object must possess the sub-class Contactor/Relay .

The name of the base object must be included in description System project:
@System | @ELO_KSP. If an object possesses the Contactor / Relay sub-
class, Comos then compares the name of the object against this list. The object
on the report is only given a contact mirror if this name can also be found in
this description.
The symbol has no special features: it draws the display of the contactor/relay
and defines the connector points.
Initialisation
The contactor/relay object has various auxiliary contacts on the Elements
tab, which are created as virtual elements . The contact mirror only becomes
visible on the diagram once at least one of the virtual elements has been cre-
ated. Do this from the mouse menu with the | CREATE or | CREATE N command.
Determining the position

Typically the contact mirror is not displayed directly next to the contactor but
at the lower edge of the sheet, for example. Thus CONTACTMIRROR_X and
CONTACTMIRROR_Y determine at what position the contact mirror is to be
inserted. See SECTION 46.4.2.22: CONTACTMIRROR_X (DOUBLE), SECTION 46.4.2.23:
CONTACTMIRROR_Y (DOUBLE).
The contact mirror can also be repositioned manually. Mouse-click once on

the object or the contact mirror. Mouse-click twice on the contact mirror (two
single-clicks, not a double-click!). The contact mirror is given grab points,
which can also include a rectangular point at the top end of the contact mirror.
Drag this grab point to the new position.
Display
The numbers and letters have the following meanings:
(6.3) Describes the sheet name and the path number, and
relates to the object that is joined to this connector. The
zone number is not specified, so this form of notation
states the column in which the object is to be found.
In the example on the left, the object is thus on page 6,
path 3.
13 The symbolized connector. The number is derived from
the designation of the connector.

Blank cross- A blank (unset) cross-reference. The text that is displayed

reference for a blank cross-reference is stipulated under Additional
options in the project properties.
59.1.1.4 O Other
59.1.1.4.1 @BB Blackbox

@1EA Catalog EE |– O Other base objects
...|- @B1 Blackbox, automatic contacts

...|- @B2 Blackbox, Comos device (from Comos 7.1)
Blackbox with automatic contacts

Goal
Blackboxes are used on reports to allow connection planning to be made
before an actual concrete device is known.
No sub-class, no symbol, no script. Control is done directly by Comos: within
the Electrical Engineering module an object is always placed as a blackbox if
there is no symbol for this type of diagram.
In other words, it is not absolutely essential to use base object @1EA Catalog
EE |– O Other base objects |- @BB Blackbox as a blackbox. All that is
required is to create any desired object of class Device and not input any sym-
bols.
If symbols exist for a number of types of diagrams but not for others, then this
object behaves as a blackbox on types of diagrams without symbols and as
prepared for within the symbol for other types of diagrams.
Application
Please note: No preview of the objects is displayed during the drag & drop
operation, since blackboxes with automatic contacts do not possess any sym-
bols. Only a cross-hair is visible while the blackbox is being moved by drag
& drop.
If the base object is dragged onto the diagram, then a planning object that ini-
tially has no connectors is generated. The connectors are generated by Comos
on the bounding line, one per grid point. If additional connectors are required,
you can drag out the blackbox to make it bigger until it covers more grid
points.

No Comos connector is generated if a connection terminates as open. A con-

nector is generated automatically if a connection terminates at an RODevice.
Naming of the Comos connectors:
Comos connectors that were generated automatically are given the following
names:
Connector on the left-hand side:
IX< No.>
Connector on the right-hand side:
OX< No.>
Connector above:
IY< No.>
Connector underneath:
OY< No.>
Whereby <No.> is not a sequential counter but is derived from the grid point.
Example: OX10 is a connector on the right-hand side of the blackbox that is
located on the tenth grid point (without the grid points of the edge).
A connector that had been generated automatically can be opened in the Nav-
igator by right-clicking on the Properties window. If a label has already been
input (as long as no implementation has been made yet), the label is also
shown at the blackbox.
Blackbox across pages:
Blackboxes are not to be used across pages.
In principle, these blackboxes (like almost all EE objects) can also be placed
multiple times across multiple sheets. A corresponding cross-reference is
shown if a connection is made on one of the reports to a grid point connector
that has already been used on another report.
However, this mode of working is not very tolerant of mistakes and should not
be used by beginners.
Blackbox with predefined contacts

Goal
This blackbox is primarily intended to connect plug-in cards. In this case there
are only connectors going in one direction exiting from the plug-in card.
By means of a symbol script.

Application
This blackbox has a symbol with four ready-made connectors. Additional
connectors are generated on the report if the blackbox is placed and drawn out
to make it bigger.
All connectors initially lie on the upper edge of the symbol, however, the sym-
bol can be rotated and thus the outgoing direction of the connectors can be
stipulated retrospectively.
No Comos connector is generated if a connection terminates as open. A con-
nector is generated automatically if a connection terminates at an RODevice.
Multiple placing:
The blackbox with predefined contacts can be continued over multiple
reports. A corresponding cross-reference is shown if a connection is made on
one of the reports to a grid point connector that has already been used on
another report.
59.1.1.4.2 @SG ID segment

...|- @SG ID segment
Goal
ID segments (label segments) are rectangular areas in circuit diagrams that
group together objects belonging to one location for the purpose of clearer
labeling that is easier to understand. This abbreviation of the texts at the
devices also covers cables (class: Device , sub-class: Cable ).
These segments are stipulated in addition as the target for the automatic plac-
ing function (“AutoLoop”).

Control by Comos as soon as a base object possesses the class Element , sub-
class Segment . The name can be anything that you wish. The symbol has no
special features: it draws the display of the segment and outputs a text.
Application
1. Pull a base object of type ID segment onto the diagram by means of drag
& drop.
2. Single-click twice on the ID segment until the grab points are visible.

3. Drag out the ID segment until it is big enough to accommodate all the
desired devices (but also only these devices) within the rectangle:
If the labelling of the segment matches the labelling of the objects within it,
the labelling of the objects is shown in abbreviated form:
Without labelling segment With labelling segment
Direction of ID segments
Please note: Segments have a “direction”! If the segment is wider than it is
tall, we talk of an x-direction segment, and if the segment is taller than it is
wide, we talk of a y-direction segment. All the segments on a diagram should
have a common "direction".
This direction is used to determine in which direction the placed elements are
to be arranged: for example, with an x-direction segment the placed elements
are arranged horizontally.

ID segments are not selected if a selection frame is dragged out with the
mouse (multiple selection).
An ID segment can also be selected by single-clicking. When making a con-
trolled individual selection with <Ctrl> + left mouse button, the order deter-
mines whether an ID segment can be marked.
Settings
Right-click to open the Properties window of the ID segment:
Label is valid for:

This options group is required in connection with abbreviated labels and has
no significance for automatic placing.
The option controls which label texts are displayed at the segment and there-
fore should be hidden at the devices.
Sheet zone
This options group is required in connection with automatic placing and has
no significance for abbreviated labels.
The name of the sheet area is used as a target during automatic placing. In
other words, Comos detects on the basis of this detail which segment the
devices are to be placed in. For that reason a sheet area name also should not
occur twice on a report. A number of names that are typical for use in EE/I&C
have already been defined in the drop-down field.
Option %N DevDescription% evaluates (OwnDescription of the base object)
for labelling segments.

59.1.1.5 W Cables
@1EA Catalog EE |– W Cables
59.1.1.5.1 Goal
Usually EE connections have no object. This means that the connectors of two
devices are directly connected together. A connection is drawn on the report,
but this connection itself has no counterpart in the database, but only the end
points of the connection have counterparts in the database through the connec-
tors.
In many cases it is necessary to define the connections more precisely. These
objects have been predefined for this purpose. Cable systems that can be spec-
ified down to the level of the wires have been provided.
59.1.1.5.2 Control of the extended capabilities

Cable systems are two-level.
1st level: Base objects with class Device , sub-class Cable
2nd level: Base objects with class Element , sub-class Wire
(wire elements and shield elements)
The sub-classes Cable and Wire have the effect that additional tabs are
shown and that RO_Cable.dll is evaluated.
Wires and shields have the same “Wire” sub-class. In principle, shields can
thus be treated as wires. In other words, “indirect shields” that are included as
shielding in the cable are used in the default libraries.
It is necessary in addition to activate the Object settings: shielding option
on the System tab so as to distinguish shields from normal wires.
Cables, wires and shields have special symbol scripts in addition.
59.1.1.5.3 Application
A cable can only be placed correctly on a report once the wires have been cre-
ated. There are two ways to get cables with wires:
• Select one of the basic cables and create the necessary wires yourself
• Select one of the fully configured cable objects in which the wires have
already been created.

Basic cable
The basic cable initially does not have any wires. You must open the Proper-
ties window and switch to the Technical data tab to create wires.
The following procedure is affected by whether you are working with a base
object or a planning object. However, a copy of the basic cable should first be
made in the base data before any new wires are created. In this way the orig-
inal basic cable thus remains unchanged.
Wire number
The total number of wires, including a grounding conductor if applicable.
Number of shields
The number of shields.
Separator
This separator is used when the Number of wires and the Cross section are
added to the Cable cross-section details.
With protective cc
Changes one of the wires that has been created into a grounding conductor.
The label is also changed.
Cross section
This is taken together with the Number of wires onto the System tab in the
Cable cross-section field.
Wire label
A number of color libraries have been prepared in branch ZZZ Other
objects. Here these are offered in the drop-down menu. The wires are cre-
ated according to the library, depending on the Number of wires . If the num-
ber of wires is greater than that of the predefined wires in the library, the
remaining wires are created numerically.

[CREATE CABLE]
Creates the wire elements on the basis of the relevant details. The details can
still be modified or supplemented later. If you mouse-click again on [CREATE
CABLE], the wires are modified or supplemented correspondingly.
Complete cable
Two cable systems have been prepared in the base data:
• VDE-compatible
Cables with stranding have also been prepared beforehand under the
0815 Telephone cables heading.
• Ölflex cables from Messrs. U.I. Lapp GmbH .

Please note: If you use objects from these cable systems, you can subse-
quently create or modify other cables or wires with the aid of the [CREATE
CABLE] button.
Calculation of cables
Once the Data options group has been filled in completely, you can then
mouse-click in the Calculation options group on the button with the question
mark (?). The loss values are then calculated automatically.
| W | ZZZ | VI Connection information

This object can be dragged onto a wire and then outputs the color, cross-sec-
tion and other information on the wire. The central constituent of this object
is in the symbol of function %N ConnectionInfo%.
%N ConnectionInfo% is then checked to see if the relevant cable information
has already been defined in the standards sheet. Identical information is then
filtered out.
See also ShowConnectionInfo.

59.1.1.5.4 Placing a cable on the report

The cable objects (not the wire objects!) are placed on the report:
The cable is shown on the diagram in the form of a dotted line.

The grab points can be activated by two single-clicks. The grab points are
used to drag out the cable symbol to be wide enough to include all the connec-
tions that are to belong to the cable:
The texts mean:
-W1 Name of the cable object.

H05V-K Label of the cable object.
1x1 Cable cross-section (number of wires x wire cross-
section)
The wires are numbered sequentially. This number is also

entered on the diagram at the intersection of the cable and the
connection:

If wires have already been set in the database, this information is retained as
far as possible, but the remaining wires are set during positioning on the dia-
gram if only part of the information has been set. Thus the free wires are allo-
cated in the due order, and more precisely, in the order in which they are
shown in the unsorted list window.
Settings for the cable symbol

The | SETTINGS mouse menu is not offered as long as the cable symbol is
grouped together with the shields. If you wish to use this mouse menu, then
you must
• single-click several times on the cable symbol. The single-clicks “run
through” the group until only the cable symbol is marked.
• remove the grouping and mark only the cable symbol.
The settings in the planning object are transferred to the System tab in the
Graphic settings options group.
59.1.1.5.5 Shields
Class Element , sub-class Wire
Display and application on the report

See SECTION 59.2.2.4: SHIELDED CABLES.
One or more shields are available, depending on whether a basic cable or a
preconfigured cable object was used. Drag the shield onto the connections in
the report.
You can activate the grab points with two single-clicks. Use the grab points
to drag out the shield until it is wide enough to include all the connections on
the report.
Connect PE grounding conductor

Shields possess a connector to the left and right respectively to which a
grounding conductor can be joined. The grounding conductor may not remain
open but must always be connected, for example, with a terminal.
No connector is shown in the planning object of the shield within the Naviga-
tor. Instead, the relevant information on the grounding conductor is given on
the Wire tab.
Additional shields
There are the following methods to create additional shields:

• Mark the cable (not the connection!) on the report and select the | NEW | SH
SHIELD command from the mouse menu. The new shield now “hooks” to the
mouse pointer.
• Open the Properties window of the cable on the Technical data tab to make
new inputs and mouse-click on [Create cable]. The new shield still has to be
placed on the report.
• Select the | NEW | SH SHIELD mouse menu within the Navigator. The new
shield still has to be placed on the report.
Moving or editing shields

If additional shields were placed on the report, these are first of all grouped
with the cable. A group of this kind can be moved or deleted, etc., as desired.
If you wish to move or delete a shield individually, then
• single-click several times on the shield. The single-clicks “run through” the
group until only the shield is marked.
• Select the relevant shield on the report and then the | GROUPING | REMOVE
command from the mouse menu. Now all the shields can be moved freely.
If you select the | GROUPING | RESTORE mouse command, all the shields are
again linked with the cable symbol.
59.1.1.5.6 Other objects

This branch has ready-defined the elements that are used in the cable systems:
wires, shield, stranding.
Stranding
The stranding is used in branch | Cables as per VDE | 0815 Fernmelde
cable.
The stranding object is used instead of a normal cable object.
59.1.1.5.7 Supporting documents

PDF file “Overview of VDE type abbreviations ”
This document comes from Messrs. Faber Kabel and contains the type abbre-
viations of cables and wires in compliance with VDE.
List of cables
Outputs the cables, including the wires.
Cable types list
Outputs the cables. The Cable length , for example, is evaluated as well when
doing this.

59.1.1.5.8 Pre-allocating wires to connectors

Properties window of a connector, Wire field. From Comos 7.1 onwards.
59.1.1.6 X Terminal strips / plug strips
59.1.1.6.1 Goal
Making terminal strips and plug strips.
Terminals and terminal strips can only be regarded as a unit in Comos. It is
meaningless to use a terminal strip without terminals, since only the terminals
can have connections. But it is also meaningless to think in terms of a terminal
without a terminal strip, since the terminal must be placed somewhere.
See also SECTION 59.7.2: STRIP TAB.
59.1.1.6.2 Control of the extended capabilities

Terminal strips are two-level:
1st level: base objects with class Device , sub-class Terminal strip
2nd level: base objects with class Element , sub-class terminal
The sub-classes Terminal strip and Terminal have the effect that Terminal-
Strip.dll is evaluated. This dll makes visible, for example, the additional
tabs.
Terminal strips and terminals can be named as desired.
Terminal strips do not possess symbols, since they are not placed on reports.
The terminals symbol has no special features: it draws the terminal and makes
the connectors available.
59.1.1.6.3 Terminal strips
Technical data tab

Number of same terminals per block
This attribute is not used by Comos itself but is provided for an ECAD import.
Configuration
This attribute is not used by Comos itself but is provided for an ECAD import.

59.1.1.6.4 Terminals
Terminals typically possess two connectors. In Comos the two terminal con-
nectors are distinguished by the “internal” (%N I %) and “external” (%N O %)
sides.
The external connector is marked in the diagram by a point:
This marking point is not defined in the symbol of the ter-

minal, but is inserted from RO_Device.dll. If you wish to turn off a marking
point, you can set options parameter DrawTerminalSideMark = 0.
By default, the internal connector is above and the external one is underneath.
This arrangement is reversed by means of the | OPTIONS | DIRECTION ROTATED
mouse command.
If a terminal strip is dragged onto a Interactive Report with an electrical engi-
neering template by means of drag & drop, then it is not the object of the ter-
minal strip that is placed but instead the next unused terminal. The procedure
creates a new terminal if a free terminal cannot be found but there are virtual
terminals available.
System information tab

There is a separator after this element
The terminal is underlined in the terminal diagram. This underlining indicates
that a separator has been inserted in the actual terminal strip after this termi-
nal.
There is a page break after this element
The report starts on a new page after this terminal.
Grid gap...
The default gap between the terminals is one grid point. The placing gap can
be changed here.
59.1.1.6.5 Bridges
Bridges connect terminals. This means that bridges can only be set within a
terminal strip. Thus there can only be connections, but not bridges, between
the various terminal strips.
Bridges can be created in the report:
SECTION 59.2.1.6: CONNECTIONS / WIRING FOR TERMINAL BRIDGES
Bridges can be created in the Properties window of the terminal strip:

SECTION 59.7.2.2: BRIDGES

59.1.1.6.6 Supporting reports
Terminal diagram (default)

Outputs the pin-outs of a terminal strip in tabular form. The pin-outs are
grouped by inside and outside.
Document properties of the terminal diagram, attributes, Settings tab:
Suppress unit / location :
There is a Label column in the terminal diagram. The unit and location of the
connected device are also output in this column. When the option is activated,
the unit is not stipulated for the devices if it is identical to the unit of the ter-
minal strip. The same applies to the location.
Output with bridge symbols :
On: Instead of icons, the graphic symbols that are defined in @Bridgesymbols
are output for the terminals. The output of bridge symbols is especially suit-
able for a DXF export, since AutoCAD has problems in working with icons.
Terminal diagram (matrix)

An alternative form of tabular display, in which primarily the columns for
Cable and Device are swapped over. Cables are handled separately and con-
nections are only handled by numbers.
Terminal diagram (graphic)

Document properties of the terminal diagram, attributes, Settings tab:
Sorting
Self-explanatory.
Output all terminals
Off: Unused terminals are filtered out.
Suppress unit / location (component)
There is a Label column in the terminal diagram. The unit and location of the
connected device are also output in this column. When the option is activated,
the unit is not stipulated for the devices if it is identical to the unit of the ter-
minal strip. The same applies to the location.
Symbolic display
This option only functions if a graphic terminal diagram is used in diagram
type GRPLAN.
On: The symbols defined on the Symbols tab are displayed on the graphic
terminal diagram.
Off: The objects are displayed in the form of simple rectangles that are made
available by Comos in this type of diagram.

Output terminal strips recursively

Normally a terminal diagram is located under a terminal strip and outputs pre-
cisely that. If this option is activated, you can then create the terminal diagram
under a unit or under a location and the terminal diagram outputs all the ter-
minal strips located there one after another.
59.1.1.6.7 Plug strips

Plug strips behave in principle in the same way as terminal strips, but cannot
be used as bridges.
59.1.1.7 ZA_1EA templates / part switching

Here there are examples to show how predefined and prewired planning
objects can with created with the aid of templates (modules).
For that reason prewired planning objects were created in the base project on
the Units tab and on the Locations tab. Each of these base objects possesses
in the Module field a cross-reference to one of the predefined planning
objects. In other words, with these objects being the placeholders for the ref-
erenced modules.
59.1.1.8 ZE_1EA elements
59.1.1.8.1 HK Auxiliary contacts

Auxiliary contacts are used in all kinds of places in @1EA, including in:
• K Relays, contactors
• Q Main power switchgear
• S Switches, buttons
• and at other places.
59.1.1.8.2 KS Terminals, plugs

Terminals and plugs that are used in the terminal strips and plug strips are pro-
vided here in ready-made form, see SECTION 59.1.1.6: X TERMINAL STRIPS / PLUG
STRIPS.

59.1.2 Structure objects, document objects
59.1.2.1 @G Document groups |S |E Structure electrical engineering

A sample structure for document groups. It is used in base object @J Project
| @E Project templates EE. The EE documents and these document
groups are prepared in such a way that automatic referencing can be done.
59.1.2.2 @J Project |@E Project templates EE

If this base object has been set for a project, then a unit, location and document
structure is made available.
59.1.2.3 @L Locations |EE Location structure EE

A sample structure for locations. It is used in base object @J Project | @E
Project templates EE.
59.1.2.4 @O Documents |EE electrical engineering

Contains the document base objects for electrical engineering.
BSL Order list

Obsolete. Predecessor for STL Parts list / order list.
DES layout plan

Obsolete. Predecessor for DVW layout plan with views.
DVW layout plan with views

See SECTION 63.2.6: INTERFACE: METZNER TRIATHLON.
GAP Devices connector plan

See SECTION 59.1.1.6.6: SUPPORTING REPORTS.
IMP Circuit diagram

Was required to import Logocad Triga 1.04.
KLP Terminals plan

See SECTION 59.1.1.6.6: SUPPORTING REPORTS.

LTV Cable routing

Output : Controls the sorting by which the list of the Evaluation Report is cre-
ated. Example: PMB List of cables, PMB.5 cable routing .
MTL Materials list

Obsolete. Predecessor for STL Parts list / order list.
SLP Circuit diagram

See SECTION 59.2.1.1: PREPARING CONNECTIONS.
SPS PLC overview

Is used in report PMA.1 PLC overview. This concerns an overview that out-
puts the addresses and connections of a PLC station.
STL Parts list / order list

See SECTION 59.6: EVALUATION (ORDER LISTS / MATERIALS LISTS / PARTS LISTS).
59.1.2.5 @U Units |BKZ |E Unit structure EE

A sample structure for units. It is used in base object @J Project | @E Pro-
ject templates EE.
59.1.3 Administration objects
59.1.3.1 @L Locations |SSE switching cabinets |BASIC | Views

See View-specific diagram types / view-specific symbols, P. 63-5.
59.1.3.2 eClass 4.0

The eClass catalog is provided to norm 4.0 as a service. eClass is not used in
@1EA. See also @Y Catalog attributes | eClass 4.0 Catalog attri-
butes.
59.1.4 Descriptions
Please note: Right at the bottom of the Descriptions dialog window there is
a Diagram type field. There you first have to switch over to DETAIL or to
one of the other EE diagram types.

59.1.4.1 Base project @1EA

This is used by base data catalog @1EA.
59.1.4.2 Base project @IRF

@IRF_Detail, @IRF_Detail_PNEU, @IRF_SLINE.
The text functions given here are made available in the Symbol Designer
when you create a text and fold out the Text functions branch from within
the text properties.
The relevant description is offered according to which type of diagram the
symbol was created for.
59.1.4.3 Base project @System
59.1.4.3.1 Base project @System |@Bridge symbols

Contains the graphic symbols that belong to the Symbolic display option of
graphic terminal diagrams. This option only functions if graphic terminal dia-
gram is used in the diagram type.
On: The symbols defined on the Symbols tab are displayed on the graphic
terminal diagram.
Off: The objects are displayed in the form of simple rectangles that are made
available by Comos in this type of diagram.
59.1.4.3.2 Base project @System |@Class | Detail

Contains the header classes that can be used in EE to set up symbols. A header
class identifies a text. Thus this text can be shown or hidden in a targeted way.
Ultimately the same can be done with the header class as with a layer. Layers
and header classes can be mixed together.
Example: Header.Class = “eBT”
eBT = electrical engineering components. If class eBT is hidden, then all
marked texts of this type are hidden, regardless of which layer they are on.
59.1.4.3.3 Base project @System |@Connection

Contains the symbols for EE connections. In other words, if a connection is
shown in EE that has a cross-reference at the end, then this description con-
trols what information appears there and how this information is formatted.

The mode of working thus corresponds exactly to the procedure by which you
draw a symbol for a device. Switch in the third column to the required type of
diagram. Do this by right-clicking on the column header and selecting the
| SYMBOLS menu from right at the bottom:
Then double-click on the symbol. You can now make the desired changes.
The “symbols” created in @System | @Connection are displayed at the con-
nection break.
The individual entries mean as follows:
LOGPOTREFERENCE: If a logical potential is allocated to a connector, then
REFERENCE is no longer output at the relevant connection, but instead
LOGPOTREFERENCE. See SECTION 59.1.1.2.1: LOGICAL POTENTIAL,
SECTION 59.2.1.4: OPEN CONNECTIONS.
PHYSPOTREFERENCE: See SECTION 59.1.1.2.2: PHYSICAL POTENTIAL.

REFERENCE: See SECTION 59.2.1.4: OPEN CONNECTIONS.
REFERENCEBRACKET: See SECTION 59.2.1.4: OPEN CONNECTIONS.
59.1.4.4 System project @ConnectionType E

Application: Properties window of a connector, field Sub-type .
59.1.4.5 System project @System
59.1.4.5.1 System project @System |@BridgeType

Application:
Properties window of a terminal strip, Strip tab, | BRIDGE/CONNECTION mouse
menu
Report, mouse menu of a connection when the connection points to a bridge.

59.1.4.5.2 System project @System |@ELO_KSP

If an object possesses the sub-class Contactor/Relay , Comos then checks the
name of the object against this list. The object on the report is only given a
contact mirror if the name is also found in this description.
59.1.4.5.3 System project @System |@WireColor

Application: In all cases where the mouse menu | COLOR mouse menu for con-
nectors or connections is offered. Examples:
Properties window of the planning objects, Connectors tab, | COLOR mouse
menu.
Report, mouse menu of a connection: | SETTINGS | COLOR.
59.1.4.5.4 System project @System |@WireCrossSection

Similar to WireColor, but here for the cross-section.
59.1.4.5.5 System project @System |@WireTypeInfo

Similar to WireColor, but here for the type info.
59.1.5 Interactive Report templates
59.1.5.1 Circuit diagrams
59.1.5.1.1 Attributes
See SECTION 59.2.1.1: PREPARING CONNECTIONS.
59.1.5.1.2 Options for EE reports

Import script options for EE reports:
Individual commands
Application = “ELO”
In this case Xdoc_Elo.dll is used.
ContactMirror_X, ContactMirror_Y
SECTION 46.4.2.22: CONTACTMIRROR_X (DOUBLE), SECTION 46.4.2.23:
CONTACTMIRROR_Y (DOUBLE)
RestoreReferencesAfterCopy
46.4.2.56: RESTOREREFERENCESAFTERCOPY (BOOLEAN)
SECTION

Controlling connections
ConnectionHook
Controls the display of the connection hook. If a connection is also a bridge,
dynamic connectors are always shown in the form of a hook, regardless of the
script entry. See ConnectionHook (Double), P. 46-44.
ConnectionLineMode
SECTION 46.4.2.21: CONNECTIONLINEMODE (STRING)
ConnectionReference
Controls the display of cross-references and potentials.
ShowConnectionInfo
SECTION 46.4.2.61: SHOWCONNECTIONINFO (BOOLEAN)
SetWireNumberByCoord
SetWireNumbersByCoord(ByVal ReportDocument As REPORTLib.Docu-
ment)
All connection end points are provided with a unique number per quadrant
(“ladder”). This information is input instead of the quadrant label if the con-
nection possesses a logical potential.
DisplayConnectedWith
Allows the automatic execution of a script at closed connections. The prereq-
uisite for this is an entry in the @CONNECTION table with the StandardValue
CONNECTEDWITH. If a script has been stored for this StandardValue, it is then
then executed.
EnableButtonSpline
See SECTION 46.4.2.37: ENABLEBUTTONSPLINE (BOOLEAN)
EnableButtonANSICable
See SECTION 46.4.2.35: ENABLEBUTTONANSICABLE (BOOLEAN)
PreferredConnectionDirection
Controls the preferred direction of connection when a connector is joined to a
connection on the report.
ShowLineModeControl
See SECTION 46.4.2.62: SHOWLINEMODECONTROL (BOOLEAN)
Paths and zones

Interactive Reports of the EE/I&C module are often split up into an invisible
checkerboard pattern to help you find your way around them more quickly.
The columns are called “paths” and the rows are called “zones”. Thus a text
can be created that is displayed in the description of the report objects of a
path.

• A text is created in a path on the Interactive Report (for example, at the top
edge of the report).
• Input the text.
• Activate the “Path text” checkbox.
• Confirm with OK, and a text frame appears.
• This frame must be dragged out to be as big as desired but should not be
wider than the path itself. All objects that are located completely within the
width of the frame (if you mentally extend the edges of the text frame
downwards) are given the path text.
Do not create two path texts within a path.
The path text only with those objects that do not have a description already.
In other words, an existing description is not overwritten.
' Path / zones variables
QuadrantOffsetTop = 0
QuadrantOffsetLeft = 0
QuadrantSizeX = 60
QuadrantSizeY = 60
QuadrantStartChrX = "0"
QuadrantStartChrY = "A"
QuadrantStepX = 1
QuadrantStepY = 1
' Path and zone calculation, variable

Dim Pfad(7)
Dim Zone(5)
Sub OnCreate
For i = 1 to 7
Pfad(i) = CStr(i - 1)
Next
For i = 1 to 5
Zone(i) = CHR(i + 64)
Next
End Sub
Variable for the output of physical potentials

RightBorder
Stipulates the initial width of a physical potential when it is placed on a report.
SignByEmptyReference
SECTION 46.4.2.73: SIGNBYEMPTYREFERENCE (BOOLEAN)

59.1.5.2 Layout plans

See SECTION 63: DIAGRAM TYPE DESIGN.
59.1.6 Evaluation report templates
The following report templates for Evaluation Reports are used in EE.
59.1.6.1 PMA
• Terminal diagram (default, matrix)
• List of connections
• List of potentials
• PLC overview
• Marshalling diagram
59.1.6.2 PPB
• Electrical consumers
• List of shields
59.1.6.3 PQA
• Wires that have no connections
• Change after a revision
• Checking the required device against the manufacturer device.
• Connector with too many connections
59.1.6.4 PPC
• Parts list

Electrical Engineering Connections
59.2 Connections
59.2.1 Graphic connections
These section covers how to drag connections onto reports and to control
them within Comos. This initially involves a form of graphic work that is
largely independent of the electrical engineering connection information such
as cross-section, color, bridges, etc.
59.2.1.1 Preparing connections

The following attributes are available if you have worked with document tem-
plate SLP Circuit diagram:
Document properties, attributes, Settings tab: Wire color , Cross-section,
Cable type .
These three fields use the descriptions WireColor, WireCrossSection and
WireTypeInfo.
If these fields have been set and no cable object has been allocated to connec-
tion on the report, the corresponding details are written to the relevant connec-
tors of the connected objects.
59.2.1.2 Dragging connections

The Connection tool is located on the menu bar of the report. This tool is
used to connect objects (components).
Please note that in addition there is also the Line tool on the menu bar of the
report. While you can use it to draw a line in purely graphic terms between
two components, this does not produce an actual connection.
You can find an illustrated introduction to the use of the Connector tool in
Quickstart EE, section “Construction (Design)”.
The Connector tool has the following basic capabilities:
• “Magnetic” connection points: the Connector tool automatically snaps to
the connector point within a certain radius around the connection point of
symbols. This automatic snapping to connector points by a cable can be
deactivated by holding down the <Ctrl> key while holding down the mouse
button and moving the mouse.

Connections Electrical Engineering
• “Magnetic” grid points: the Connector tool automatically snaps to the grid
point. This automatic snapping to grid points by a cable can be deactivated
by holding down the <Shift> key while holding down the mouse button and
moving the mouse.
• Connections can also be dragged over components, the connections being
separated and the object incorporated into the connections.
• The connections are closed when an object in the document is deleted.
• If an object is set to connections, the connections are separated, meaning
that the object is incorporated into the connections.
• The connections are changed correspondingly when components are
moved.
• Connection crossings at connection cables
Two other connections can also end at the same point when joining
connectors. A connection crossing is displayed to distinguish such a case
from a situation where a connection runs over another connection but in
purely visual form.
59.2.1.3 Parallel connections

When you mouse-click on the Connector tool, a drop-down menu with the
numbers from to five appears in the menu bar at the right. Select from the
menu the desired number of parallel connections.
This involves the selection of the maximum number of connections to be
made. The Connector tool checks the actual situation and also reduces the
number of parallel connections as necessary.
Example: If the Connector tool is set to “3” and the user starts to make a con-
nection to a motor that only has two connectors, then only two connections
are drawn and made.
The parallel connections have a preset gap from a grid point. If the grid is
made bigger, the gap of the parallel connections is correspondingly made big-
ger as well.
The Connector tool changes this gap if required.
Example: If the Connector tool is set to “2” and the user starts to make a con-
nection to a motor that has two connectors, the two connections are set pre-
cisely to the connectors of the motor, regardless of how far apart they are.

59.2.1.4 Open connections

Open connections are not allowed as a rule and are marked as “inconsistent”
(shown in red).
There are just two exceptions:
1. Component connections that are open on one side, with cross-reference.
2. Connections that are open on one or both sides, and which can be cross-
referenced (e.g. potentials).
Reference brackets
If multiple open connections point to the same target, you can set a reference
bracket:
Reference brackets can also be connected with the aid of the mouse menu in
the same way as for other connections. First select from the mouse menu the
| CONNECTION | MARK... command and then the | CONNECTION | SET... command.

Open connections with logical potential

The cross-reference symbol is swapped if an open connection possesses a log-
ical potential. Without logical potential
With logical potential:
Logical potentials without connected devices

If a connection still does not have any devices connected, a logical potential
can still be specified nonetheless. Do this by marking another potential,
selecting | CONNECTION | MARK and then allocating the connection with
| CONNECTION | CONNECT WITH....
Adapting cross-reference symbols and cross-reference texts

In all the above cases the information that is output at the end of the cross-
reference is taken from description @System |@Connection. If you wish to
see another text or an additional graphic or format the text differently, you
then need to change the corresponding entry in this description. See also
SECTION 59.1.4.3.3: BASE PROJECT @SYSTEM |@CONNECTION.
59.2.1.5 Direction of wiring
Goal
If connections are dragged onto a report, then initially all that matters is that
all the components that also to be connected physically are connected some-
where on the report.
In order to be able to do that, it is also permitted to make connections at any
desired point on the diagram to another connection.
In actuality, it is not permissible to make connections only to connectors / ter-
minals in plant design and construction. It is illegal to simply make connec-
tions anywhere to a cable.
The planning on the report can be done far more quickly if you can simply
make connections “anywhere”, but there is a gap in the information for the
actual cabling in industrial plant design.

This gap in the information can be filled by means of the “wiring informa-
tion”. For that reason the report also shows graphically at which components
a connection terminates in actuality.
Example
A simple form of motor switching with safety switches has been set up in the
following illustration. If you look at the connections of the separate safety
switch at the bottom in the illustration from a purely graphic point of view, it
is not possible to tell with which components it has been wired:
It is of course quite simple in this case, but it is a matter of the principle

involved.
A “connection hook” is attached to the contact points of
the connections to display the missing information:
Now you can see at once that the safety switch is wired
on the left to the motor (or the terminal strip before it) and on the right to the
drive unit:

Effect of the direction of wiring in the planning data

You can only tell on the report to which component a connection has been
wired. However, Comos goes further than just drawing management, and also
manages the connectors by means of the planning data. The reports and the
planning data are reconciled automatically.
Thus if an object has been wired to a specific component, then this means that
actual concrete connectors have been connected to it in the report, and also
that this has an effect on the planning data.
See also SECTION 59.2.1.8: RECONCILIATION OF DATABASE AND REPORT CONNECTIONS.
If the wiring is to be functional, free connectors must thus be available at the
components involved. (In Comos an actual concrete connector can only be
joined to just one counterpart connector.) Nonetheless, with certain compo-
nents auxiliary connectors are generated automatically as required so that a
connection can be closed.
Initial direction of wiring

Wiring hooks initially run against the direction of the characters. As an exam-
ple, a terminal X1 is connected with horn H1:
If a cross-connection is now started to this connection, the wiring then points

to X1:
Determining the direction of wiring manually

You can find an illustrated introduction to the connection hook / direction of
wiring Quickstart EE, section “Construction (Design)”. However, the princi-
ple is very simple:

• Start the connection to the other connection,

• Make the second click not a a right angle, but offset (here:
offset to the right):
• And make the next clicks in the usual way so as to continue and terminate
the connection.
If the second mouse-click is offset to the left, the wiring correspondingly
points in the other direction.
The branches of potentials normally have no direction of wiring.
Retrospectively changing the wiring

Single-click twice on the connection until the grab points become visible.
Enlarge the image until you can clearly see the wiring hook. The wiring hook
has its own round grab point, which you can simply push onto the other side
of the connection point:
Please note that this action also changes the connector pin-outs in the planning
data!
59.2.1.6 Connections / wiring for terminal bridges

See also SECTION 59.1.1.6.5: BRIDGES.
Default case: connecting terminals directly

If the terminals of a terminal strip are connected, then an “internal connec-
tion” is created initially. You can switch to various types of bridges with the
aid of the mouse menu.
The mechanisms shown below function both when the terminals are joined by
an internal connection and also when the terminals are joined by a bridge.

Example: A connection runs from terminal 1 to terminal 2
A new connection is dragged from terminal 4 to the corner:
Terminal 4 is automatically connected to terminal 2:
Finally, terminal 4 is connected to the connection line:
Comos automatically corrects the direction of the wiring. Terminal 3 is now

connected to terminal 2 and to terminal 4:
In other words: the wiring of terminal 2 and terminal 4 was removed automat-
ically.
Please note that the wiring of the terminals is done on the basis of the position
on the report. It is of no importance that the terminals in the above example
have sequential numbers. If the terminals on the report had the names 3-17-6-
1 in relation to the order, the terminals would be wired in this order.

Special case: creating bridges indirectly

Devices and terminals can also be formed by auxiliary connectors, so it sel-
dom comes to the state that a “connector is missing”.
You can make use of this capability to generate bridges indirectly and not, as
in the above example, by directly connecting and bridging the terminals.
We already stated above that you can input a direction of wiring by means of
the “connection hook”. Thus cross-connections have a preset direction for the
connection hook.
If you always connect all the devices going outwards from the terminal strip
and then create cross-connections, the wiring then points to the terminals:
1. 2.
You only need to mark the connection and to change it over to a bridge by
means of the mouse menu.
Alternatives
It is simpler to set bridges in the database. Predefined columns for bridges are
already provided there, see SECTION 59.7.2.2: BRIDGES.

59.2.1.7 Document cross-references
Goal
Document cross-references indicate on which report a connection is contin-
ued. Logically enough, document cross-references are only of interest if the
diagrams are so big that they cannot be drawn on a single report. Fundamen-
tally there are two types of cross-references:
• Cross-references from connections
• Cross-references from potentials
“Cross-references” should not be understood literally in the case of
potentials, since in a sense they “refer” back to themselves and thus make it
possible for a potential to reach across multiple sheets. See SECTION 59.1.1.2.2:
PHYSICAL POTENTIAL.
“Direction” of document cross-references

Directions are of no importance for the functional wiring of components. A
correct diagram is also correct if it is inverted.
It is of no importance for the data which document cross-references are drawn
“to the left” or “to the right”. The only thing that matters is that the document
cross-references on the report in their totality are consistent with the connec-
tions in the database.
Definition: Document cross-references can be in any desired direction, graph-
ically speaking.
For that reason both of the following drawings are valid:

Partial amounts of document cross-references

When you work with cross-references, it is not necessary to have all the con-
nections in the database drawn on the report as well. Cross-references in
Comos can run over several lines. Example: The following horn has another
auxiliary connector joined to it at connector 2
If a connection for the cross-reference is drawn on the report at connector 2,

both counterpart connectors appear automatically:
59.2.1.8 Reconciliation of database and report connections

The connections that were dragged onto the report reflect the joining of the
connectors in the database but are not identical with them from a technical
point of view. It is thus possible to have report connections without their cor-
responding counterparts in the planning data and vice versa.
Read/write mode controls the extent to which the report connections and the
joining of the connectors in the planning data are reconciled.
Write/read mode
A drop-down menu also appears when the Connector tool is called up:
• Read
The connections must be set in the database. The connection line on the
report searches for the corresponding connection in the database. The
connection line is consistent if the connection is found. With this option the
connection lines in the report have no effect on the database.
Consistent connection: blue

Inconsistent connection or
no connection in the database: red
• Read / write
As described above, if no connection was found, the connecting line
generates the connection between the objects in the database. With this
option the connecting lines write into the database if no connections had
been set in the database.
Consistent connection or
No connection in the database: black
Inconsistent connection (the connection in the database is connected with
another object): red
• Write
A connection between the planning objects is generated if no connections
were found in the database. If a connection to the object connectors had
already been input, it is deleted and overwritten. With this option the
database information is always overwritten by the diagram connection lines.
Color: green
Subsequently resetting write/read mode

This connection option can normally be switched for an existing connection
via the mouse menu:
You can use ShowLineModeControl in the options script of the Master

Report to prevent in Interactive Reports the mouse menus to switch the con-
nection mode from being visible.
Intended and unintended differences

As was explained above, the technical differences between report connections
and connections involving connectors can lead to disparities.

• Connectors are joined in the planning data, but there are no associated report
connections
In general, this is not a problem. However, there can be an inconsistency if
only some of the connections involving connectors exist as connections on
the report.
• Report connections without associated connectors
In this case the report connections are marked in red (inconsistent).
59.2.1.9 Connection-independent objects
Goal
To create a template that you can copy into the planning data and in which you
can reconcile the objects on the report with the objects in the planning data
with just a few mouse-clicks.
Implementation
The objects are marked as “connection-independent” on the report by means
of the mouse menu:
Marked objects of this type are shown in blue (synonymous with the display
of read-type connections in blue).
Example
The following example is easy to set up as a model and demonstrates the
points in question.

A horn is to be connected to a terminal.
The terminal is marked and labelled as “connec-

tion-independent” in the mouse menu.
Effect: the terminal becomes blue:
Next, the horn is joined to any desired terminal via the connectors in the plan-
ning data.
Now the horn has been connected in the planning data, but not on the report,
and the final step is to draw a connection in the report between the horn and
the terminal. The connection must have the “read” option:
Effect:
Effect: the connection-independent terminal on the report is joined to the ter-

minal from the planning data. The information on the terminals is now output
on the report. The connection on the report is consistent, since it matches the
corresponding information on the connection and the connectors in the plan-
ning data.

59.2.1.10Limitations of “connection-independent objects”

There are a number of different instances in which it is not possible to work
in the report with connection-independent objects.
Please note: The following case works on the basis of connections with the
“read” option. As a rule, there will be no inconsistency in the case of write-
type connections, since the details from the report simply overwrite the plan-
ning data until it matches.
Auxiliary connectors
Example: A device possesses a connector and an auxiliary connector. For
example, there is a connector CP1 and CP1(1) at the device; from a technical
point of view, CP1 and CP1(1) have been short-circuited.
In the default case l a connector “2” now appears twice in the Properties win-
dow on the Connectors tab, since the connector and the auxiliary connector
possess the same label. This display is consequently meaningful since it
involves short-circuited connectors from a technical point of view, and these
are treated in the same way as connectors.
Both are connected to one terminal respectively.
There are connection-independent terminals on the report and these are con-
nected with the device. The effect: Both of the connections are marked as
inconsistent on the report:
Reason:
A piece of information is missing if two connection-independent objects run
together to a short-circuited connector: Comos cannot determine which of the
connection-independent terminals on the report is to be allocated to which ter-
minal in the planning data. The planning data is correct, but Comos cannot
transfer the planning data onto the report. For that reason the connection-inde-
pendent terminals are not allocated on the report and the connections are
shown in red.

Assessment in practice:
The case described above does not occur, since in practice the terminals are
usually connected on both sides. If the second connector supplies useful infor-
mation, Comos can allocate the terminals and the data thus becomes consis-
tent:
*
X01 X02
# = Connection-dependent Objects
K2.A1
* *V == Graphical
Unchangeable Objects
connection point
K2
Disparate numbers of connections

If two connectors have been joined together in the database but only one con-
nection has been drawn on the report, then there are in fact two errors:
1. Too few connections have been drawn in the report, and
2. the connection drawn in the report cannot be allocated unambiguously to
one of the two connectors that have been joined.
Thus the following case is inconsistent:

X01
# = Connection-dependent Objects
* *V = Graphical connection point

= Unchangeable Objects
K2
You can create a similar case if you draw on the report more connections than
exist in the planning data.
Bridges
Bridges are not evaluated to produce a consistent connection logic.

Example: A light and a fluorescent lamp are connected via

terminals to the same terminal strip:
If a planning object is assigned to one of the two components (for example,

the light), then in theory a consistent logic could be set up. Starting from the
specific component, first the terminal is found, then the other terminal is
found via the bridge, and from there also the fluorescent lamp in the planning
data.
But if you try that, you will get the following result:
Reason: Bridges very often include more than two

terminals and thus are not unique. For that reason bridges are not evaluated in
the connection logic.
59.2.2 Connection information
59.2.2.1 Bridges
See SECTION 59.2.1.6: CONNECTIONS / WIRING FOR TERMINAL BRIDGES.
59.2.2.2 Logical potential

See SECTION 59.1.1.2: @1EA CATALOG EE |- I POTENTIALS.

59.2.2.3 Cables and wires / wire information without wires

EE connections on the report are not objects in themselves but only the depic-
tion of two connectors that have been joined together. If you wish to allocate
additional information to an EE connection (such as color, cross-section, Typ-
info), then there are two options available for this
• Creating a cable object
The cable is managed separately by means of a cross-reference. See
SECTION 59.1.1.5: W CABLES.
• Allocating the corresponding information to the connectors. The connectors

pass on this information to the connection.
Do this by marking the connection and selecting the following mouse menus
| SETTINGS | CROSS-SECTION
| SETTINGS | COLOR
| SETTINGS | TYPINFO
Typinfo is thus the information on the material structure and properties of the
cable; this information is managed in the form of a key.
See 59.7.1.6: CONNECTION INFORMATION FOR CONNECTORS: DIALOG WINDOW
SECTION
Technical background: The function is only offered if the selected connection

(at least connection in the case of multiple selection):
• is not a logical potential,
• is also consistent in the database is (i.e., is not shown in red on the report),
• and the connection has not been allocated to a cable.
The cable object takes priority. If wire information already exists at the con-
nectors and a cable object has also been assigned to the connections, the infor-
mation of the cable object is then evaluated and displayed.
Disconnecting wires
Wires can be disconnected in the opened Properties window of the device:
• Mouse-click on the entry in the über column and select the Wire mouse
menu.
• Select the Disconnect sub-menu.
If a counterpart connection had been set, there is the option of disconnecting

the counterpart connection, including the wire information, or of only discon-
necting the counterpart connection while retaining the wire information.

Alternatively, the wires can be disconnected in the opened Properties window

of the cable:
• Mouse-click on an entry and select the | DISCONNECT mouse menu.
Changing cable type

From a database point of view, the information on the cable is not part of the
logical chain between the devices. The information on the cable is managed
by means of a cross-reference. For that reason the cable type can be changed
at any time without needing to adapt to the devices or connectors.
If you wish to substantially retain the wires, then drag within the planning
project in the Properties window of the cable that had been created a new base
object onto the Base data tab. The wires are reallocated from top to bottom
and the information is retained if at all possible. If the new cable type has
fewer wires than there were before, then information will of course be lost.
59.2.2.4 Shielded cables

See also SECTION 59.1.1.5.5: SHIELDS.
Display and captions

A shielded cable is shown in the diagram as an oval placed flat. The wires are
automatically assigned to the connections when the shielded cable is dragged
over a connection. At the same the label for the wires (here: “2” next to the
left-hand connection and “1” next to the right-hand connection) is written next
to the connection:
The captions mean as follows:
-W7 Designation of the cable, where the minus sign is the

separator taken from the project options. This
designation can be generated automatically.
(N)YM-J Sub-type of the cable. This information is taken from
the "parent object".

10x1,5 Number and cross-section of the wires. This

information is taken from the Name field of the
object.
The wires are displayed in the database together with the allocated connec-
tions:
Changing the shielded cable

Grab points appear when you single-click twice (do NOT double-click!) on
the shielded cable:
The shield can be made broader with the aid of these grab points. Do this by
left-clicking on the dot, holding down the button and dragging the grab point
to the new position.
In addition to these three designations (-W7 , (N)YM-J and 10x1,5) a rectan-
gular point appears for each of them so that the designation texts can be
moved.
In addition, a round dot can be seen at the far left. The shielded cable can
rotated vertically with the aid of this dot.
Allocating screening / shields

Drag the shielded cable on the diagram over one or more connections.
The connection is automatically allocated to a free wire. If you wish to allo-
cate another connection that is spatially nearby on the diagram, you can sim-
ply change the width of the shielded cable.
If you wish to allocate a connection that is somewhat further away spatially
on the diagram, drag the same planning object (not an additional shielded
cable from the base objects!) a second time onto the diagram.

You can “open” the shield if the connections on the diagram are so far apart
that they cannot all be encompassed by the shield or if the connections are on
different reports, then:
• Select the shields individually (not the group)
• | SETTINGS | START OF THE SHIELDING.
(The hook should disappear.)
The result is that the rounded part at the left is removed from the diagram:
If you were to deactivate the | END OF THE SHIELDING command in addition, the
shielded cable would also be shown as open to the right. Thus you can always
tell from the diagram where the shielded cable is complete or whether it has
additional connections at another point in the diagram.
59.2.2.5 Summarizing cables in cable channels / routes

A "route" is an additional piece of information for a cable. A “route” planning
object is created in the usual way in the planning project.
The next step is to open the Properties window of the cable that is to be allo-
cated to the route. The route is dragged from the Navigator into the Properties
window of the cable (for example, onto the Name field). No change is visible
in the Properties window, but the route had been set. Check the inputs in the
Navigator:
The action is confirmed with [OK] and the Properties window is closed.

Special concerning circuit diagrams Electrical Engineering
Alternative allocation of routes

Using drag & drop in the Navigator, simply drag the route onto the cable and
release the mouse button there.

All the cables that are within it are shown in the Navigator under the route.
A “processing object” is displayed in the Navigator under the cable and under
this is the list of the routes via which the cable is led.
59.3 Special concerning circuit diagrams
59.3.1 Placing devices
The placing techniques referred to previously are used in the EE section.

Information on how to place objects can be found in Quickstart Basic or
Quickstart EE.
59.3.2 Revising and controlling devices
Modifying the display of the devices

Devices can be edited as usual in the EE section: Grab points appear when you
single-click twice on the object. In this way you can rotate the object and
move the texts.
Mouse menu | Settings
| FIXED or | SEARCH TEXT

See SECTION : | SETTINGS.
| CONNECTION-INDEPENDENT
If this option is used with planning objects, the objects then only continue to
function as placeholders. They are shown in red in the Interactive Report.
The objects change on both sides according to the dependency, for example,
via the connectors. A chain of dependencies of this type is disconnected as a
rule because an object in the chain has been redefined.
See SECTION 59.2.1.9: CONNECTION-INDEPENDENT OBJECTS.

Electrical Engineering Special concerning circuit diagrams
| LABEL VISIBLE
Turn the Device label on and off. As a rule, the device name plus the name of
the owner as used as the device tag.
Mouse menu | Graphic settings

This mouse menu only appears for objects that have predefined “additional
symbols”. A call is included in the Symbol script of the base object:
DrawText p6, "*V*P S:SYS.ADDITSYMBOL*", 0, 2
The commands change the display of the device; typically the symbol is sup-
plemented by additional graphic components (hence ”additional symbol”).
Examples: @1EA | S Switches.
59.3.3 Setting the pointer in the report / allocating information
This tool is used to retrospectively modify objects in the Interactive

Report.
This tool offers the following options, for example:
• Allocating or changing the allocation of a unit / location to an object,
• Allocating a potential to a connection
see SECTION 59.1.1.2.1: LOGICAL POTENTIAL.
• Changing the base object,
• Changing the planning object.
Simply drag the desired new object with the Object tool onto an object on the
drawing. The addressed object in the Interactive Report changes color.
If another base object or planning object is allocated, then the display of the
symbols in the diagram also changes accordingly. The connections are
retained as far as possible.
59.3.4 Identification keys in EE reports
Graphic objects in reports in the EE section can be hidden by means of their

own identification key. This has already been at a number of different points:
Mouse menu, commands | SETTINGS | DEVICE TAG VISIBLE / | GRAPHICS VISIBLE
The associated identification keys are:
Start of the shielding: “eSB”

Special points regarding layout plans Electrical Engineering
End of the shielding: “eSE”

Device tag: “eBC”
Graphic: “eGR”
59.4 Special points regarding layout plans

See SECTION 63: DIAGRAM TYPE DESIGN.
59.5 Special points regarding single line diagrams
59.5.1 Report template
Application = “ELO.SLINE”
59.5.2 Allocating ELO connectors and single line connectors
In the Properties window of connectors of types EE/I&C and Single line

there is an edit field if both EE/I&C connectors and single-line connectors are
available in a base object. With EE/I&C connectors the field is called “Single
line connectors “; and with single-line connectors the field is called
“EE/I&C connectors ”.
You can allocate precisely one single-line connector to an EE/I&C connector,
while each single-line connector can have multiple EE/I&C connectors allo-
cated to it.
All the connectors must belong to the same base object.
59.6 Evaluation (order lists / materials lists / parts lists)
59.6.1 General
Only objects that meet the following criteria are taken into the above-men-
tioned lists:
1. The objects are in a direct ownership relationship, i.e., cross-references
have not been evaluated
2. Only objects that are within the unit structure or location structure
respectively on the unit or location side respectively are evaluated

Electrical Engineering Evaluation (order lists / materials lists / parts lists)
3. A base object exists for the planning object

4. The planning object is not of type Log. potential
5. The planning object is not of type Cable
6. It owns the Mounting data tab
7. It owns the Manufacturer data tab
8. It owns the Supplier data tab
9. The property not relevant for ordering is not active
10. The Part number field is not blank
59.6.2 Settings tab
Select the Report tab and from it allocate to the Report template field the tem-
plate CRP | AWR | PPC | PPC.1 Order list / Parts list by means of the button
on the right.
Sorting by
Determines the sorting criteria that are to be used later in the list. Check the
order!
[Reset]
Deletes all previous inputs for this options group.
Output with:
Terminal strips / plug strips
Determines whether output is to be done with or without strips and terminals
/ plugs.
Accessory
Determines whether output is to be done with or without the accessory.

Evaluation (order lists / materials lists / parts lists) Electrical Engineering
Page break
Determines whether a page break is to be made when the contents of the first
of the sorting criteria change.
Unit
Selection between Yes , No or If differing with actual object .
Location
Selection between Yes , No or If differing with actual object .
List type
Determines the type of list, selection between ORDER LIST, MATERIALS LIST or
PARTS LIST.
59.6.3 Materials lists
Columns:
Item, material number, device description, manufacturer, unit price
All devices that can be ordered are listed, devices with the same part number
are grouped together for output, terminal strips and plug strips and accessories
are broken down by their own allocation and are listed.
59.6.4 Order lists
Columns:
Item, number, order number, order text, manufacturer, price, total
The order list behaves just like the materials list, but here only real devices are
taken into consideration, i.e., the ISREQUEST option must be set to FALSE.
59.6.5 Parts lists
Columns:
Item, unit, location, name, description, manufacturer, order number, device
description, price
All the items are listed individually, terminals and plugs are grouped together
under a strip, sorted by type. Accessories are sorted underneath devices and
marked as such by a “+” (plus sign) in the Item column.

Electrical Engineering Object-oriented EE planning
59.7 Object-oriented EE planning
59.7.1 Object connections (connectors)
59.7.1.1 Definition of connections

Connections are the logical cross-references of objects that have been set in
the database. Existing connections can be checked at the Connectors tab,
which is always shown when working with base objects but is only shown as
required with planning objects.
Connecting lines in the diagram are to be distinguished from connections:
connecting lines represent (database) connections, but are not identical to
them. Thus it is possible for the diagram to have (database) connections with-
out connecting lines and also connecting lines without (database) connec-
tions. The function logic only works if the (database) connections have also
been set.
Connectors always possess one of the Input , Output or Neutral states; a con-
nection without one of these states cannot exist.
59.7.1.2 Settings connections in the Navigator
Joining connectors
The idea behind this procedure is to make the connectors of both devices vis-
ible in the Navigator and then to edit them by using drag & drop.
Use drag & drop to pull a connector onto another connector.
This procedure can only used to select items individually.
Disconnecting connections using the Navigator

Mouse-click in the Navigator on one of the linked connectors and select the
| DISCONNECT CONNECTION mouse command.
Allocating connection information using the Navigator

In the Navigator a connector can be pulled onto a signal or a logical potential
by using drag & drop. The pointer is set automatically. This also functions
vice versa.

Object-oriented EE planning Electrical Engineering
Display in the Navigator

If the connectors in the Navigator are not displayed directly underneath the
owner, the full label ("FullLabel") is then displayed instead of the label
("Label"). Example: Signal; Potential.
It is not necessary to input the details of the signal behind the connector if the
connector is located directly under the signal.
59.7.1.3 Working with the Connectors tab and the Navigator

It is more convenient to open the Properties window of one of the two objects
to be connected.
Connecting by means of drag & drop

First open the Properties window of one of the two objects by using the mouse
menu (or by double-clicking). Switch to the Connectors tab.
Then select the second object in the Navigator and open the tree structure in
the Navigator until the connectors are visible.
Now one or more connectors can be pulled over by means of drag & drop:
There are two options when making a multiple selection:

1. A multiple selection is only made in the tree structure. In the Properties
window the free connectors are allocated in the due order, this being the
order in which they had been sorted on the Connectors tab.
2. A multiple selection is made both in the tree structure and also in the
Properties window. In such a case the database attempts to allocate the
selected connectors in the due order.
3. The corresponding warning message is given if the number of the relevant
connectors selected does not match. If you decide to carry out the action
regardless, the connectors are processed in due order until the smaller of
the two groups has no more connectors left.
The method of using a Properties window in connection with the Navigator
also allows for convenient sorting functions. You can control via the symbols
which connectors are to be displayed in the Properties window and sort the
list in addition.

Disconnecting connector cross-references

• Mouse-click on an entry in the Connected with column and select the
Connection mouse menu.
• Select the | DISCONNECT sub-menu.
• If you have already set the wires, you can keep the cable information with
| DISCONNECT (RETAIN WIRES).
59.7.1.4 Working with two Properties windows open

There is the option to set connectors completely without the aid of the tree
structure by using two Properties windows.
Normally only one Properties window is opened, meaning that double-click-
ing on a second object displaces the information on the first object in the
opened Properties window.
The Keep visible switch in the top right-hand corner allows you to open mul-
tiple Properties windows simultaneously.
Activate the relevant Connectors tab once you have opened both Properties
windows. Now you can use drag & drop to pull one or more connectors from
one window into another.
Fundamentally speaking, two Properties windows behave in the same way as
just using one Properties window in connection with the Navigator. However,
you now have two options available to filter and sort information. For exam-
ple, you can display only inputs in the first Properties window and only out-
puts in the second one.
This method is especially useful for two-shield solutions, since one of the rel-
evant Properties windows can be positioned on one of the two shields.
Disconnecting connectors
Connections can be disconnected in either of the two Properties windows that
are open.
59.7.1.5 Working with the “connect device” dialog window

The last option is a method that is very similar to one using two Properties
windows. Select the | EXTRA | DETAIL | CONNECT DEVICE menu. Use drag &
drop in the dialog window to pull an object into the left-hand window half and
the other object into the right-hand window half.

The order and the choice of right or left is entirely up to you. The result is that
the dialog window looks very much like two opened Properties windows.
The procedure now is exactly like that described for the previous case.
The advantage of the Connect device dialog window is that chain connec-
tions can be set more quickly or that large numbers of connections can be han-
dled: The contents of the window are changed very quickly when a new object
is dragged into the dialog window. However, it takes a comparatively long
time to exchange information in Properties windows. The Connect device
dialog window saves working time if the object to be edited is changed fre-
quently.
59.7.1.6 Connection information for connectors:

dialog window “Characteristics for connections”
This dialog window is used if you are not working with cable objects but
instead when the connection information is to be written to the connectors.
See SECTION 59.2.2.3: CABLES AND WIRES / WIRE INFORMATION WITHOUT WIRES.
Procedure
• Set a starting object by means of drag & drop.
• Write the desired texts into the edit fields
Cable type, Cross-section and Color .
• Select the desired option for Overwrite .
The dialog window writes the details into the system-internal attributes of the
connectors. (These attributes are thus not visible on a Specification tab of the
base object.)
The Wire cross-section and Wire color columns on the Connectors tab
can be made visible by means of the mouse menu. The information that had
been set in the dialog window or which had been set in the report via the
| SETTINGS mouse menu for the connections is displayed in these columns.
Connector with wire but without counterpart connection

The wire Information is managed independently of the connection
information. Thus there can be a connector in which the wire informa-
tion has been set but which nonetheless has no connection. Such a case
is indicated by a red cross with a question mark (?) on the Connectors tab.

Retrospective changes
Overwrite
The Determine information for connection dialog window can be used
multiple times on planning objects. If the option has been deactivated, the
information in all objects that had already been processed earlier is retained.
If the option has been deactivated, the information on the cross section and
color is overwritten with the new details.
Retrospective setting of a cable

If a cable object (and thus wire information) is retrospectively allocated to the
connector, the information of the cable is transferred. In other words, the
information of the cable object overwrites the information that had been writ-
ten to the connector attributes.
59.7.1.7 Providing connectors with logical potentials beforehand

Connectors can be prepared in such a way that a logical potential has already
been allocated when the planning object is created.
• Open the Properties window of the base object (change to the base project
as required).
• Change to the Elements tab. The logical potential must exist as an object,
a cross-reference is not sufficient. For that reason you should select the
| NEW command from the mouse menu.
• Input the following details:
Class Device
Label Any
Sub-class Log. potential
virtual Off
Please note: The connector and the logical potential created on the
Elements tab must have exactly the same names!

When the planning object is created, the connector is given the logical poten-
tial with the exact same name, unless a logical potential had been set already.

The Log. potentials column must be made visible by means of the mouse
menu so that you can see the result on the Connectors tab.
Logical potentials support the NestedLabel function. Effect: For example, if
there is a signal under a fuse, the label of the fuse is prefixed to the potential
label.
59.7.2 Strip tab
See SECTION 59.1.1.6: X TERMINAL STRIPS / PLUG STRIPS.
59.7.2.1 Terminal strips and terminal strips

The Strip tab groups together the connectors of all terminals located under-
neath.
Schemes
Schemes can be saved for terminal and terminal strips.
Use terminals for AutoLoop / AutoConnect

The Marshalling number attribute was formerly used when marshalling
connections. Thus terminals that belonged to the same item, for example,
were connected automatically. This functionality is to be implemented in
future via the AREA name.
59.7.2.2 Bridges
See also SECTION 59.1.1.6.5: BRIDGES.
The Connectors tab of the terminal strip is opened first of all to set a bridge.
The terminals that are to be connected by a bridge are selected on the tab:
Two categories of bridges are managed for each terminal, an internal (on the
left) and an external bridge (on the right). The internal bridge should thus
symbolize the internal connectors, namely, the connections running from the
terminal into the interior of the cabinet.

Select the mouse menu in the left-hand part of the lists window to get the
| BRIDGE (INTERNAL) menu:
And the corresponding counterpart when using the mouse menu in the right-
hand area.
The same types of the relevant bridge are offered in both menus. Each type of
bridge is symbolized by its own color:
Blue Wire bridge or also ridged bridge

Red Switching bridge, open
Green Switching bridge, closed
These predefined colors can be changed, see “Global settings for bridges, P. 59-68”.
If bridges are set and deleted repeatedly, this can lead to display problems.
Select the | UPDATE (BRIDGES) mouse menu if bridges can no longer be dis-
played for any obvious reason.
Mouse menus on the Strip tab
| CHANGE BRIDGE This option is only available if you right-click pre-

TYPE cisely on a bridge that had been created.
You can switch between the individual bridges, and
the symbol color also changes when a switch is made.
| INSERT INTO THE A bridge connector point is inserted into the marked
BRIDGE bridge. Exactly one bridge must be marked so that the
menu item becomes available.
| DISCONNECT The bridge is removed completely.
BRIDGE
| DISCONNECT A bridge connector point is removed from the marked
FROM THE BRIDGE bridge. Exactly one bridge must be marked so that the
menu item becomes available.

| (UN)MARK Marks or unmarks the selected bridge. The bridge

BRIDGE does not need to be selected fully.
The cursor must be positioned exactly on a bridge, and
then the functions in the mouse menu can be called up
by right-clicking. A marked bridge is shown in violet.
Calling up the function again unmarks the bridge.
| Group BRIDGES A single bridge that contains all the bridge connector
points is made up from several bridges of the same
type. All the bridges that are to be grouped together
must be marked.
| OPTIMIZE BRIDGES Simplifies the bridges. A bridge is deleted if there is
another bridge of the same type that the first bridge is
a subset of. The bridge information is thus not lost,
since this bridge switching likewise exists in another
bridge.
| BRIDGE- Shows the switching information for the bridge that
INFORMATION had been clicked on.
Inserting extra columns for bridges

Three columns for internal bridges and three columns for external bridges are
provided in the default settings. You should use the | COLUMNS | EXPAND
BRIDGE COLUMNS menu if you require a greater number.
Global settings for bridges

Bridges are controlled via a table in the system project. The details in this
table also determine which colors are used to display the bridges on the Con-
nectors tab.
59.7.3 Product data and real devices
See SECTION 61: PRODUCT DATA AND MANUFACTURER DEVICE.
59.7.4 Other auxiliary tools
59.7.4.1 Change by rule: name, label

See SECTION 58.1: RUPLAN IMPORT.

Electrical Engineering Other
59.8 Other
59.8.1 Translation / language management
See SECTION 42: LANGUAGES (LOCALIZATION).
59.8.2 Management of rights and licenses
The EE module requires an EE/I&C license. The EE/I&C license is used

when
1. basic operations are carried out with ELO connectors (connect,
disconnect, edit wires or potentials)
2. connectors are given signals or process the signals of the connectors
3. one of actions 1. or 2. is carried out in the Properties window of planning
objects (device)
4. an Interactive Report is opened with write access (this was so before)
5. the “Marshaling Manager“ or “Implement requirements” are opened
Please note: “Signal tracking” is read-only and does not require an EE/I&C
license.
For completeness, we will make a reminder once again at this point concern-
ing the querying of licenses: licenses are taken from the floating license for
the work session. If Comos is opened several times at a workstation, then sev-
eral licenses will also be made use of, depending on the action involved.
For reports there is the | OPEN READ ONLY command to prevent a license from
being used.

Other Electrical Engineering

Request and implementation Request
60 Request and implementation
60.1 Request
Definition of request
• Each base object can be defined as a request if the Request option in the
Properties window on the System tab has been activated.
• The Device request class is also available in addition.
Base data branch @1EA Elektrotechnik

The Request option is activated in the “higher “levels”.
The real devices are divided into “lower levels” (or in other words, with
objects that have been specified more precisely) and the Request property is
disabled there. Thus the requests and the real devices are organized in one
branch and you can distinguish these two groups from one another. An exam-
ple:
@1EA Catalog EE
-| H Indicator modules
-| L Optical Indicators
-| A Indicating lamp
-| EAO LUMITAS Manufacturer’s catalog

Request Request and implementation
-| 10-1319.1199 Incandescent lamp

-| (other deveices from the manufacturer)
-| (other manufacturer’s catalogs)
Request are created down to level A Indicating lamp. Under that level are
the manufacturer catalogs, here, for example, that of EAO LUMITAS. You can
find the manufacturer’s devices in the EAO LUMITAS catalog, here, for exam-
ple, a light bulb.
Display of device requests

Requests are given a small blue triangle in the bottom right-hand
corner. On the left is an example for a request of class Device .
Additonally, the Implementation edit field appears in the Prop-
erties window of the planning object:
Manufacturer devices (real devices)

Import: The details on the manufacturer devices change very quickly, so there
is little point providing entries in the standard database. Manufacturer devices
must be imported or else created manually in the base data.
Use the | ADMINISTRATOR | BASE DATA | ECAD COMPONENTS IMPORT command
to import manufacturer devices. See SECTION 58.2: IMPORTING ECAD COMPONENTS.
“Mixed” objects
It is not vital to first create objects with the Request option and then objects
under them without this option. Vice versa is also possible.
A number of object to handle measuring problems have been created under
the @F Functions | A General functions heading. The objects were cre-
ated without the Request option. However, the objects contain elements that
were created with the Request option.

Request and implementation Implementation
60.2 Implementation
60.2.1 Implementation phase (preparing for ordering)
The following can be implemented:

• All objects whose base objects possess the “Request ” (IsRequest) setting.
• All objects of class Device request (Device ClassDeviceSpecification).
Types of implementation
• Request on request
• Manufacturer devices on request
The ECAD manufacturer catalog (plus a number of Siemens devices)

See SECTION 58.2: IMPORTING ECAD COMPONENTS.
As a counterpart to the device requests manufacturer devices must be pre-
pared. The details on the manufacturer devices change very quickly, so there
is little point providing entries in the standard database. Manufacturer devices
must be imported or else created manually in the base data.
Examples:
ECAD catalog underneath the device requests:
@1EA Catalog EE | ... (approximately from the fourth level).
Phoenix Contact
@1EA Catalog EE | A Assemblies, subassemblies | Phoenix Contact
Siemens AG:
@1EA Catalog EE | A Assemblies, subassemblies | Siemens AG
60.2.2 The Implement request dialog window
The Implement request dialog window should be used in order to

implement manufacturer devices for device requests. Select
| IMPLEMENT REQUESTS from the | EXTRA | DETAIL menu.

Implementation Request and implementation
The Implement request dialog window uses a dialog area that can be desig-
nated as a “list window”. This area is used in a number of different dialog win-
dows. The vast majority of icons belongs to the “lists window” dialog area.
“List windows“ are no longer in use; instead, queries are used. The other icons
have the following meaning:
Display filter. If this is pressed, requests that have not

been implemented are also displayed.
Display filter. If this is pressed, requests that have been
implemented are also displayed.
The display filters are additive.
As explained above, each base object can possess the Request option. How-
ever, in most cases the base objects will possess the Device class. Select the
entry D Devices from the Class dropdown list.
The fields Start object and Base object can be set by means of drag & drop:
Drag the desired objects onto the field by using the mouse.
With Start object you determine which object is used as starting node when
searching for device requests.
The Base object field provides an additional filter to narrow down the
search.
The requests that have been found are shown in the list area, depending on
how the filter has been set. One or more objects can be marked in the list win-
dow, in the usual way.
Marked requests can now be allocated to devices from the base objects or to
the unit/location view. This can happen individually or collectively:

Request and implementation Implementation
60.2.3 Replacing or retaining a request
60.2.3.1 Project option “‘Implement request’ replaces objects”

Project properties, Module options tab, “Implement request“ replaces
objects option:
• Deactivated
-> A new Planning object is created; it is based on the Base object that was
selected as implementation of the request object. The request object receives
an implementation pointer that points to the new object.
• Activated
-> Change of base object: The Base object pointer of the Planning object
based on the request is replaced: the Planning object is now based on the
manufacturer’s object, not the request, but it is still the same object as before
(same SystemUID).
60.2.3.2 Setting the implementation pointer

The implementation pointer that has been set is displayed in the Implement
request dialog window once you have dragged a manufacturer device onto
the marked requests:

Implementation Request and implementation
If the “Implement request“ replaces object option is deactivated, a new

planning object is created for the manufacturer device. Now both the manu-
facturer device and the request object can be seen in the Navigator. In addition
to that, the edit fields in the Properties windows are set correspondingly:
Correspondingly, the edit field Request will be set in the Properties window
of the newly created object.
An implementation presupposes that the device request and the manufacturer
device are reasonably similar. In certain cases Comos does not carry out an
implementation and informs the user accordingly by means of an infobox.
Continuing the implementation

If an object receives the implementation pointer and has already been joined
to another object by means of a connector, an attempt is made to implement
the partner object as well recursively. A number of conditions must be evalu-
ated (Is the partner object of the same class? Same number of connectors?
etc.). The same also applies if the implementation is released.
60.2.3.3 Base object change

If the base object is changed, there are no special features that indicate this.
The resulting object takes over the attributes, elements and so forth of the new
base object. The elements of the object to be implemented are also checked
during the implementation. If any elements with identical names are found,
then these elements are likewise implemented, meaning that they are swapped
in the database and on the report. All placed elements for which there are no
elements of the same name in the implementation are lost in the database and
are displayed in red on the report to indicate that there are inconsistencies. If
the implementation is successful, it is not possible to tell from the objects that
have been created that they have been created as the result of an implementa-
tion.

Request and implementation Report PQA
60.2.4 Release device requests
This option is only available for Option 1: Set implementation pointer . In

the case of Option 2 all information on the original request is lost, and hence
the original state cannot be reconstructed either.
In order to release an implementation that has already been set for Option 1,
mark the object in the Implement request objects dialog window and select
the | RELEASE command from the context-sensitive mouse menu by
right-clicking.
Comos releases the implementation and asks whether the objects that have
been created are likewise to be deleted.
60.3 Report PQA

Checks the device request against the real device.

Report PQA Request and implementation

Product Data and Manufacturer Device Definition and area of application
61 Product Data and Manufacturer Device
61.1 Definition and area of application

Definition of product data
Product data constitutes the minimum amount of attributes that are required
to order a concrete product. To put it in another way: In the course of the plan-
ning a certain partial quantity of all the user inputs is used to select or describe
a manufacturer device (or “real device”) that can be ordered.
In detail, the Comos product data function area fulfills the following tasks:
1. A number of the attributes in the base data are labelled as product data-
related. The user can immediately see on the planning page which
attributes are to be filled out so that it is at least possible to place an order.
2. In addition, a template can also be input in the base data. As long as the
base object is a request, this template from the base data is only displayed
for information.
If this involves a manufacturer device in the base object, then the input
fields are given an orange background to make it clear to the user that
there has been an impermissible deviation from the ordering criteria.
3. On the basis of the product data that had been input in the planning page,
a search can be made within the existing manufacturer devices and the
user can select a concrete device from the results.
4. Alternatively, in the case of special production items (for which there can
be no existing manufacturer devices already for obvious reasons), a
manufacturer device can be created from the product data that had been
input in the planning page.
The technical basis for the use of product data is a change of base object.
1. First of all, a base object that is to serve as the basis of the request
(“prepare requests”) is configured.
2. In addition, base objects are created for the manufacturer devices. Often
this is done by importing catalogues of manufacturer devices (“importing
manufacturer devices”).
3. A planning object in which the product data-related inputs are made
(“planning work”) is created on the basis of the request base object.

Function right product data Product Data and Manufacturer Device
4. The request changes into a manufacturer device once all the required
inputs have been made:
4.1 If it involves individual or special production items in the planning
objects, then there are no manufacturer devices in the base data that
you could make a selection from. In this case the inputs in the
planning object can be used so as to create a manufacturer device in
the base data.
Although thus by definition the details in the previous planning
object and the new manufacturer device are the same, this step is
important. This step determines that the previous inputs are now
valid and relevant for ordering (“manufacturer devices created by
feedback“).
4.2 However, as a rule the manufacturer devices have already been
prepared in the base data. Comos offers from all the manufacturer
devices the partial quantity that matches the concrete planning
inputs in the product data-related attributes. The user decides for one
of the manufacturer devices offered and Comos sets this device as
the new base object in the planning object (“selection of
manufacturer devices”).
Limits
Supported CDevice Classes:
• Class Device
• Class Element
• Class Accessory
• Class Position
• Class Location
61.2 Function right product data

Preparing an order is a responsible task that should not be allowed to be car-
ried out automatically by any Comos user. In the rights management control
is exerted via the product data function right as to who may carry out the fol-
lowing actions:
• Creating manufacturer devices from the planning data by means of feedback
• Allocating one from the existing manufacturer devices (“device selection”)
Proceed as follows to grant a user this function right:

Product Data and Manufacturer Device Preparing requirements
• Mark the project, <Ctrl>+<A>

• Switch to the following dialog window on the Rights tab and activate the
Display of: Function rights option.
• Right-click on the line in which the corresponding employee or employee

group is entered and select the | PROPERTIES mouse command.
Activate the Function rights: product data option in the following dialog
window:
• Alternatively: Right-click in the white window area (not in the table) and
select the | NEW | RIGHT mouse command.
Click in the User/Group line on the [...] button:
Select the user or group as required and confirm with [OK].

Once you have got back to the Properties window, you have to continue as
described above and activate the Function rights: product data option.
Administrators automatically possess this right. See: SECTION 6: RIGHTS MANA-
GEMENT for further information on the topic of Rights Management.
61.3 Preparing requirements
61.3.1 Preparing request base objects
Activate the Request option on the System tab in the base object.

Preparing requirements Product Data and Manufacturer Device
When this option is activated, an Implementation field apppears

in the Properties window of the planning object. However, you
should not use this field when you are working with product data.
The Request/Implementation method is the older one in Comos, but is still
fully supported. The Product data: Request/manufacturer device method is
the newer one and has a considerably enhanced functionality.
61.3.2 Preparing attributes
Product data is handled as attributes. In other words: The Product data

option is used with all attributes
1. that appear both in the requests and also in the details of the manufacturer
device, and in addition
2. are required as the basis for a decision for or against a manufacturer
device.
Activating product data

Activate the Combination option on the Links tab in the Properties window
of the attribute:
Set operator
A field for the operator is made visible.
The operator stipulates what relationships between the templates in the base
object and the planning data are to be valid. The “=” character (equals sign)
was selected in the above example. This means that input in the planning data
must be exactly the same as the template from the base data so that the input
is valid.
Exactly which entries in the Operator list are available depends on the type
of display of the attribute. The operators have the following meanings:
None An input must be made on the planning page, but it does
not matter what kind of input.

Product Data and Manufacturer Device Preparing requirements
=, >, < etc. Numeric comparison between the input on the planning
page and the template.
Within, Only applicable with range attributes. The input on the
Outside planning page must be respectively within or outside the
the values of the template from the base object.
Prefix Alphanumeric comparison. The input on the planning
page must be the prefix of the template from the base
object. This is very useful with order numbers. Within
the order numbers the first digits often give type details
and the remaining digits merely add additional ordering
details.
For example, if the order number for a motor is
M4x0815, where the “M” stands for motor and the “4”
for a four-pole connector, it is then sufficient to input the
prefix “M4” on the planning page to describe the
product adequately.
Subset Alphanumeric comparison. In a similar way as for
Prefix, you only need to enter part of the template from
the base object on the planning page; but in this case the
input can be made at an desired point in the template.
Input the details for the request

The appearance of the attribute changes. A display field is inserted:
The display field for the
product data
Please note: The display field that is made visible the amount of space avail-
able for the other areas of the input field. Check the size of the input fields and
enlarge the individual areas or even the overall frame of the attribute.
Switch to work mode via the mouse menu. You can now input values into the
attribute in the usual way:
Input values
The gray display field can be seen on the far right. No inputs as such can be
made into the display field, instead the inputs are taken over from the left and
displayed.

Importing manufacturer devices Product Data and Manufacturer Device
While the user can subsequently overwrite on the planning page the Minimum
field and the Maximum field, the details in the display field remain
unchanged.
61.3.3 Controlling the display of product-related attributes
You can set via an attribute how an attribute with the Combination (= pro-
duct request) property is to be displayed on the planning page.
In this case the attribute with the name ProdReqShow must exist in the base
object on the tab with the name SYS . This attribute must be created as a Com-
bobox with three states.
0 - Display request data and real unit data
(corresponds to the previous display)
1 - Display request data
2 - Display real unit data
The Properties window is not automatically updated when switching over the
Combobox. For that reason it is a good idea to explicitly initiate an update in
the OnChange script function:
Sub OnChange()
'After editing the unit or the value
Set App = Workset.Globals.AppCommand
App.Execute "RefreshDeviceForm", ""
End Sub
See also the script function with which you can control the output of the prod-
uct data in reports: SECTION 61.7: OUTPUT PRODUCT DATA.
61.4 Importing manufacturer devices

The manufacturer devices can be created manually in the base data, but as a
rule the manufacturer devices are imported.
The base data should of necessity be set up as follows:
1. There is a central branch for each technical area. The topmost levels of
the branch are base objects with the Request option activated.
2. The manufacturer devices are located underneath the request objects
(without the Request option, of course).

Product Data and Manufacturer Device Planning work (input of product data)
The administrator imports the manufacturer devices by means of an

action object under the request objects (see SECTION 33: IMPORT VIA ACTION
OBJECTS)
Automatically creating structure branches for manufacturer details

When importing manufacturer devices there is also the option to automati-
cally create a node for the manufacturer.
Attributes with keynames in which the necessary details for the manufacturer
have already been stored must already exist in such a case. The keynames are:
ECAD Tab: HSD
Attribute name: M003

(M-zero-zero-three)
eCl@ss Tab: PA
Attribute name: AAA001
(Three times A-zero-zero-one)
eCl@ss Tab: E11

Please note: In the long term there will only be one keyname for eCl@ss.
Effect: When an import operation is started, then first of all a branch with the
name of the manufacturer is created in the base data. The manufacturer
devices are stored underneath this node point.
61.5 Planning work (input of product data)

Create the planning objects in the usual way. The product data-related
attributes can be seen at once via the additional display field:
The display field for the
product data
If templates had been input at the base object for the request, then these tem-
plates are visible:
Details for the request

Selecting a manufacturer device Product Data and Manufacturer Device
Otherwise the attribute can be edited in the normal way in the course of the
planning. The subsequent procedure to be followed depends on which type of
implementation is chosen.
61.6 Selecting a manufacturer device
61.6.1 Creating manufacturer devices by feedback
61.6.1.1 Feedback for an individual planning object

In Comos it is not absolutely necessary to first create the manufacturer
devices separately in the form of base objects so that they are already avail-
able at the time of implementation.
You can also work in the opposite way: You work with planning objects and
then use these details to create a suitable base object. Thus there is feedback
from the planning project into the base project.
Application
Make all the preparations described above.
Once all the required inputs have been made, click in the Properties
window of the planning object on the Create base object ”product
data” icon.
The icon can only be used if the user possesses the Product data function
right. In principle, this icon and the associated functionality can occur in the
case of objects of class Accessory , class Element and class Device .
Effect:
1. A base object is created in the project from which the original base object
came.
2. This new base object becomes the new basis of the planning object.
3. In this new base object the inputs that had been made for the planning
object are now taken over as the inputs.
4. The Request option is removed. A manufacturer device base object is
now allocated to the planning object, more specifically, the one which had
been created above.
5. Due to the allocation of a manufacturer device, the orange background
function now takes effect, see SECTION 61.6.3: DEVIATIONS FROM THE
MANUFACTURER DEVICE TEMPLATES (ORANGE BACKGROUND).

Product Data and Manufacturer Device Selecting a manufacturer device
Tip: Prepare manufacturer devices by means of “Create base object product

data”
This method can also be used to create smaller numbers of manufacturer
devices. Do this by inputting the desired product data, click on Create base
object “product data” , input the next product data item, and click again on
Create base object ”product data”, etc.
61.6.1.2 Feedback for a planning branch

Select the | EXTRA | CHECK: Edit product data command.
This tool serves the same purpose as the above-mentioned Create
base object ”product data” icon in the Properties window of a planning
object: There is feedback of the planning data to the base data, and base
objects are created if required.
Application
Drag a branch of a planning project or a base object into the Start field.
Effect on a branch of a planning project:
1. All the planning objects lying underneath it are searched to see if product
data had been input into them.
2. A base object is created for each planning object in which product data
had been input. This base object is then located in the project from which
the original base object came.
3. This new base object becomes the new basis of the planning object.
4. In this new base object the inputs that had been made for the planning
object are now taken over as templates.
Effect on a base object:

1. All the planning objects that had been derived from this base object are
searched to see if product data had been input into them.
2. The subsequent steps are the same.
• Due to the allocation of a manufacturer device, the orange background


61.6.1.3 Automatically creating structure branches for manufacturer details

With both methods of feedback there is also the option to automatically create
a node for the manufacturer.
Attributes with keynames in which the necessary details for the manufacturer
have already been stored must already exist in such a case. The keynames are
ECAD Tab: HSD
Attribute name: M003

(M-zero-zero-three)
eCl@ss Tab: PA
eCl@ss Tab: E11

Please note: In the long term there will only be one keyname for eCl@ss.
Effect:
When the feedback is initiated (with the “Create base object” icon in the
Properties window or the [EDIT] button dialog window, as applicable), then
1. First of all, a branch with the name of the manufacturer is created in the
base data.
2. The new base objects for the manufacturer devices are created underneath
this node point.
61.6.2 Selection of manufacturer devices
61.6.2.1 Selection with a single planning object

Click within the planning object on the Base data tab on the Search for
base data button:

The following dialog window opens:
When the dialog window is open, the planning object has already been entered
in the upper area (here: Test2).
Selecting attributes (deleting columns)

In the upper list there is a column for each product data-related attribute.
Right-click on the head of the column and then you are given the | DELETE
command, among others.
Effect: The column is removed from the list and thus the corresponding
attribute is no longer taken into consideration when searching for base
objects. The attribute remains unaffected at the planning object.
The more columns that are removed in this way (and thus reducing further the
number of attributes to be taken into consideration), the more base objects are
found.
Start search again

Searching for base objects
If columns had been deleted or inserted, the search must be carried out
again with this button. Effect: Those base objects whose attributes match the
upper selection appear in the lower list.
Display product data attributes
Restores the initial state: All columns with product data-related
attributes are made visible again.
Background: You can also delete columns from the lower list so as to get a
better overall view. (Deleting the lower columns has no other effect.) All the
deletions are undone by this button and the original state is restored.

Display attributes as in planning project

This button compares the lower list against the upper list. Thus exactly
the same columns are shown at the bottom as at the top.
Select base object

Select a base object from the bottom list and confirm with [OK].
• Due to the allocation of a manufacturer device, the orange background
61.6.2.2 Selection for a planning data branch

Select the | EXTRA | DETAIL | Device selection (product data) com-
mand. The following dialog window is based on an object query:
Controls
The upper window area is based on a “planning objects default query”.
Step 1: Determine the starting quantity

First of all a start object is set. As is usual with an object query, the number
of objects can be restricted or increased by using the various options.

Determine property
This button is not typical for an object query, but only exists in this dia-
log window. This option evaluates the “Request” property (= IsRequest).
Request : Only planning objects that possess the “Request” property appear
in the upper list.
Device : Only planning objects that do not possess the “Request” property
(IsRequest = False) appear in the upper list.
Please note: The above option does not take into consideration whether the
planning objects possess any product data-related attributes at all. Thus too
many objects can appear in the list.
Under no circumstances select the | DELETE command from the mouse menu
while in the table so as to “clean up” the list, because that action would delete
the marked objects from the database.
Use the object query filter so that any unwanted objects are no longer dis-
played.
Update planning objects
Please note: This concerns the upper button. This button also exists for
the lower list window.
Effect: When options are changed, you must update the upper list with this
button. (The list is also updated automatically, depending on the settings.)
Step 2: Select attributes

First of all, all the columns with product data-related
attributes are made visible by means of this button.
Right-click on the head of the column (not in the list!)

and then you are given the | DELETE command, among others.
Effect: The column is removed from the list and thus the corresponding
attribute is no longer taken into consideration when searching for base
objects. The attribute remains unaffected within the planning object.
The more columns that are removed in this way (and thus reducing further the
number of attributes to be taken into consideration), the more base objects are
found.
Search for base objects
Please note: This concerns the lower button. This button also exists for
the upper list window.
If columns had been deleted or inserted, the search must be carried out again
with this button. Effect: Those base objects whose attributes match the upper
selection appear in the lower list. (The list is also update automatically,
depending on the settings.)

If columns had been deleted or inserted, the search must be carried out again
with this button. Effect: Those base objects whose attributes match the upper
selection appear in the lower list
Step 3: Search for base object

First set the lower list such that the attributes that are relevant at that moment
have been set. The results can then easily be sorted and filtered by right-click-
ing on the column heads.
Display product data attributes
Restores the initial state: All columns with product data-related
attributes are made visible again.
Background: You can also delete columns from the lower list so as to get a
better overall view. (Deleting the lower columns has no other effect.) All the
deletions are undone by this button and the original state is restored.
Alternatively, the lower window can be compared with the upper one:
Display attributes as in planning project
This button compares the lower list against the upper list. Thus exactly
the same columns are shown at the bottom as at the top.
Step 4: Set base object

Click on Set base object If a suitable base object is found, then click on:
Effect: This base object is set for all the above selected planning objects.
The dialog window remains open and you can edit the next planning objects.
61.6.3 Deviations from the manufacturer device templates (orange

background)
Once a manufacturer device has been allocated, the inputs in the planning
object and templates from the manufacturer device base object are compared.
If your inputs do not match the templates that are visible in the additional dis-
play field, then the input fields are shown in orange.

Product Data and Manufacturer Device Output product data
A hint appears in the Tooltip if the mouse briefly hovers over one of the
orange input fields:
61.7 Output product data

<workset>.Lib.ProductRequestDisplayText<Spec>
This function supplies the output text of a ProductRequest attribute, whereby

individual values such as Min/Max and unit are separated by the "|" character
(vertical bar) (e.g. “100|200|cm”)
The manufacturer device data is supplied as a complete string (e.g. “100 - 200
cm”) as on the tabs.

Output product data Product Data and Manufacturer Device

EPLAN (Import/Export EXF) Background information
62 EPLAN (Import/Export EXF)
62.1 Background information
62.1.1 EPLAN structures in comparison with Comos structures
EPLAN organizes its data as follows, broadly speaking:
“Normal” base data and article base data

This sub-division broadly corresponds to the Comos scheme. In Comos as
well there is base data in the form of templates for planning data (EPLAN:
“project data”). The article base data roughly corresponds to the manufacturer
catalog in Comos.
However, in EPLAN there is a strict separation of “normal” base data and arti-
cle base data.
Not so in Comos: here the manufacturer catalog is managed within the normal
base data. For that reason “normal” base data from EPLAN is not imported
into Comos either. It is sufficient to import the article base data in Comos.
Please note; there is only one form of import for article base data. There is no
interface to transport Comos article base data to EPLAN.
Symbol files
A symbol file contains all the symbols from the relevant one of the seven sym-
bol types within EPLAN. In other words: a component can appear in a maxi-
mum of seven different types of depiction.
• Variants in EPLAN symbols
Position changes (rotations) are controlled by variants. The rotated symbol
is thus not calculated but the relevant separate symbol is created for up to
four different angles of rotation.
This is no problem when importing, since each of the variant symbols can
be used and processed further.
However, rotated symbols cannot be exported, since there is no
corresponding form for rotated symbols in EPLAN. If a rotated variant is
exported to EPLAN, the rotation is ignored completely and the base symbol
is exported. if you intend to export to EPLAN, then you should only work
with unrotated variant symbols.
• Separate management of symbols in EPLAN
In EPLAN the symbol files are kept strictly separated from the base data and
the project data. Within the project data there is only a text reference to a

Background information EPLAN (Import/Export EXF)
symbol which is then loaded at runtime.

It is different in Comos: here the symbols are part of the base objects and
thus (via inheritance) also part of the planning objects.
Plot frames
A plot frame is used to print out (plot) information. This roughly corresponds
to a Master Report in Comos.
However, document management in EPLAN is relatively limited and there
are only one or a few plot frames. Comos is different: here a large number of
reports can be used, and from a technical point of view, as many as you wish.
In Comos it is also not strictly necessary to work with Master Reports, since
a report that can be printed out can be generated.
Forms
Forms take in information and display it. The forms are used within a plot
frame and are then called plot forms. Forms are not Evaluation Reports from
the Comos point of view, despite what one might think from the name.
The EPLAN default forms are:
Cable plan
Terminal strips overview
Cable overview
Terminals connection plan
Parts list
Device list
Terminals parts list
Switch cabinet layout
Table of contents
Title sheet/cover sheet
PLC (SPS) overview
Compared to EPLAN, Comos has more options for handling information. For
example, you can collect data in object queries that is completely divorced
from any type of documentary display. Cosmos only makes a graphic repre-
sentation of the data in the reports.
Project data
EPLAN projects (i.e. planning data) fundamentally only exist in the form of
documents (“pages”). These pages contain all the planning details and also
anything from one to seven references (links) to symbol files. There is no sep-
arate form of data management such as there is in Comos in the form ofob-
jects.
In Comos there is also a document-oriented view of the planning data in the

form of the reports, but Comos reports and EPLAN pages do not match func-
tionally one to one. In SECTION 62.1.2: EPLAN PAGES IN COMPARISON WITH COMOS
REPORTS you can find a comparison of the most important properties from the
point of view of importing.
Binary files
Moreover, binary files can be managed within EPLAN. Comos can of course
manage binary files of all types, but these files cannot be imported from
Comos via the EPLAN interface. They have to be transported “by hand” to
Comos as required.
62.1.2 EPLAN pages in comparison with Comos reports
Page numbering
EPLAN projects (i.e. the planning data) fundamentally are only made up of
documents (“pages”). The identification of the planning information kept
there is done primarily through the designation of the documents; thus this
property has considerably greater importance within EPLAN than in Comos.
See SECTION : THE EXF TAB.
Page type
EPLAN pages always have an entry under “Type ”. What is meant by this is
the page type.
Type (EPLAN):
A = Circuit diagram (Logical, Interactive )
B = Free graphic (Graphic, Interactive)
C = Switch cabinet layout (Graphic, Interactive)
D = Plot frame generation (Graphic, Interactive)
E = Title sheet/cover sheet (Graphic, Interaktiv)
J = Table of contents (Graphic, Automatic)
K = Terminal plan (Graphic, Automatic)
L = Terminal parts list (Graphic, Automatic)
M = Terminal connection plan (Graphic, Automatic)
N = Cable plan (Graphic, Automatic)
O = Parts list (Graphic, Automatic)
U = Ordering list (Graphic, Automatic)
P = Device list (Graphic, Automatic)
Q = PLC page (Logical, Automatic)

R = Terminal strip overview (Graphic, Automatic)

S = Cable overview (Graphic, Automatic)
T = PLC (SPS) overview (Graphic, Interactive)
Meaning:
Graphic, Automatic - Roughly corresponds to evaluation reports.
Graphic, Interactive - Roughly corresponds to interactive reports.
Logical (Automatic / Interactive) - Roughly corresponds to logical
diagrams.
The EPLAN “Type ” often corresponds to the EPLAN “Form ”. This “Type”
or “Form” generally has no counterpart in Comos, since a sharper differenti-
ation must be made within in Comos with its considerably broader functional
scope. Instead, a combination of three factor corresponds to this “Type” or
“Form”:
• Type of diagram (or a Symbol Type in the report template)
EPLAN pages are converted into one of the DETAIL types of diagrams.
These types of diagrams are created especially for EE. Evaluation Reports
do not have any type of diagram.
• Report template
The report templates are made up of a Master Report (created from a plot
frame) and a Sub-report (created from a form).
• Document base object
Document base objects are created in @O Documents |EXF EXF import.
Document base objects for EXF possess the EXF settings tab and the
following dialog fields there:
Type of view (Comos field):
EPLAN page
Free graphic
FG switch cabinet layout
FG table of contents
Plot frame generation
RS schematic layout
Terminal module holder overview
SAPIM
NCRS
FG terminals plan
FG terminals parts list
FG terminals connection plan
FG cable plan
FG parts list

FG device list
EPLAN page for PLC
Terminal strip overview
Cable overview
Title sheet/cover sheet
PLC overview
Form :
This field is not filled in manually as a rule, but takes over the text relating
to the form used when importing the EPLAN project data. The text is passed
back to EPLAN when exporting, and then EPLAN attempts to allocate a
form on the basis of the text.
Many pages in EPLAN have a form, but by no means all. For example,
EPLAN circuit diagrams have no form, but on the other hand a switch
cabinet layout does. Whether or not an EPLAN page possesses a form
therefore does not depend on whether this page is interactive.
The EPLAN documentation explains the criteria by which EPLAN pages do
or do not possess forms.
Page size
EPLAN pages do not use DIN sizes. The page sizes must be transferred as
well when importing EPLAN pages.
In the default release database supplied with Comos there are a number of
report templates that have already been set up with valid EPLAN page sizes.
As a rule these report templates are marked with the appendage “EPlangr”.
Multi-page documents
As far as we know at the moment, there are no multi-page documents in
EPLAN. Each document thus comprises exactly one page. The ownership of
the pages can be determined on the basis of the numbering. If pages are gen-
erated automatically (by a form), then multiple separate pages are created as
required.
In Comos there are multi-page documents.
Report templates for EXF: EXfConformable

The script option ExfConformable can be set in the options script of a report
template. Effect:
• The texts of the labelling segments can no longer be moved but instead
appear at specific positions. This position of the texts is controlled by: mark
segment, right-click | PROPERTIES options group Device tag position .

• Texts of components / devices, etc. can no longer be moved but appear at

specific positions.
• The grab points are deactivated.
62.1.3 Overview of an export of Comos data to EPLAN
In principle, “normal” Comos data can also be exported to EPLAN, but this
data is then placed as images or free graphics. Thus this data can no longer be
changed or edited within EPLAN. In practise, it is virtually impossible to
organize the original Comos data in such a way that a functional and consis-
tent EPLAN project can be created with it.
If you nonetheless wish to work further with EPLAN, then proceed as fol-
lows:
• Create a special EXF project within Comos.
See SECTION 62.2: PREPARE COMOS PLANNING PROJECT.
• Export all the required base data in EPLAN:
Article base data; Symbols; Plot frame; Forms
See the EPLAN documentation, you can find a schematic overview of these
procedures in SECTION : EXPORTING ARTICLE BASE DATA FROM EPLAN, SECTION :
EXPORTING SYMBOLS FROM EPLAN, SECTION : EXPORT PLOT FRAMES FROM EPLAN,
SECTION : EXPORTING FORMS FROM EPLAN.
• Export the base data from EPLAN into Comos.

See SECTION 62.3: IMPORTING EPLAN DATA (EPLAN -> COMOS).
• Export a planning project as EXF in EPLAN.
See the EPLAN documentation, there is a schematic overview of this
procedure in SECTION 62.3.4.1: EXPORTING PROJECTS FROM EPLAN.
• Import the EXF data into Comos.
See SECTION 62.3: IMPORTING EPLAN DATA (EPLAN -> COMOS).
• Process the data in Comos
See SECTION 62.4: WORKING IN COMOS WITH (IMPORTED) EXF DATA.
• Export the modified planning data as an EXF file in Comos.
See SECTION 62.5: EXPORTING FROM COMOS (COMOS -> EXF).
• Import the EXF data into EPLAN:
See the EPLAN documentation.

EPLAN (Import/Export EXF) Prepare Comos planning project
62.2 Prepare Comos planning project

The Comos project must be linked with the following template:
@J Project |@X Project suppositions EXF.
This project template has the following peculiarities:

• A EXF Specification tab is created in the project. This EXF tab is created in
the base data in @Y Catalog attributes |EXF EXF Import| 04 Project
settings EXF.
Purpose: EPLAN projects possess project information. When importing

into Comos, this project information is read from the header of the EXF file
and written in the EXF tab. This data is evaluated again during an export
operation and is also written into the header of the exported EXF file. See
further below regarding the EXF tab.
• A unit system is ready-made in the mouse menu.
• The default document folder is ready-made in the mouse menu
• A location system is ready-made in the mouse menu
The unit system, the default document folder and the location system
originate from @J Project |@X Project suppositions EXF.
Regarding the ready-made mouse menu, see SECTION 62.4: WORKING IN COMOS
WITH (IMPORTED) EXF DATA.
The EXF tab

Page numbering
EPLAN projects (i.e. the planning data) fundamentally are only made up of
documents (“pages”). The identification of the planning information kept
there is done primarily through the designation of the documents; thus this
property has considerably greater importance within EPLAN than in Comos.
Comos documents also have a “page”, but this property actually contains only
a page number. The complex page numbering used in EPLAN is expressed in
Comos through the hierarchical structure of the planning data.
Depending on the EPLAN page numbering, the planning data created within
Comos is set up differently in an import operation:
– Overall numbering
The documents have a sequential number. This corresponds to the
procedure used within Comos of numbering documents sequentially
within a document group. Within EPLAN “sub-pages” (2a, 3B, 3.1, 3.8,
etc.) are also permitted in such a case. The overall numbering within

Prepare Comos planning project EPLAN (Import/Export EXF)
EPLAN covers from 1 to 99999. The overall numbering depends on the

criteria within a unit.
Import: The new reports to be generated are only created on the
Documents tab.
– DIN: unit (descr. location)
Apart from the page number, the unit is also used for identification. The
location is added as an additional description but does not play any role
at all for identification. In practical terms the option is thus identical to
“DIN: Only unit ”.
Import: The new reports to be generated are only created on the Units tab;
the unit structure is created accordingly.
– DIN: Unit and location
Apart from the page number, the unit and location are also used for
identification. EPLAN: Locations of the same name can also occur with
different units; in such cases it does not involve the same locations. The
numbering always starts at 1 within the locations.
Import: The new reports to be generated are only created on the Units tab,
but locations are also created underneath the units. This involves a so-
called “mixed structure” from the point of Comos.
– DIN: Only location
Apart from the page number, the unit is also used for identification.
Import: The new reports to be generated are only created on the
Locations tab; the location structure is created accordingly.
– DIN: Only unit
Apart from the page number, the unit is also used for identification. In
practical terms the option is thus identical to “DIN: Only unit (descr.
location) ”.
– KKS (German power station labelling system)
EPLAN: The KKS label made up of two characters is applied as the
superordinate sort criteria. The unit comes after that.
Type of labelling
This determines how the devices are labelled on the documents (or reports, as
applicable). EPLAN and Comos work in a sufficiently similar way to each
other in this respect. Example: If label type DIN: Unit and location was
selected for the device, then the following text is output on the report at the

EPLAN (Import/Export EXF) Importing EPLAN data (EPLAN -> Comos)
device: “= Anl1+Ort1 | Kennzeichen.“ In the case of “Anl1“, etc., this of

course involves a placeholder that is filled by the corresponding text in the
report. There are the following types of labelling:
– Device
Import: The device label is created accordingly during the import
operation. A subsequent change to this entry no longer has any effect on
existing Comos data.
Export: Is evaluated correspondingly in EPLAN. Please note: This setting
must be reconciled with Page numbering in accordance with the rules
in EPLAN! The rules currently applicable can be found in the EPLAN
manual. Example (valid as of the date of creating this manual):
Page nunbering “1 overall numbering ” allowed:
1 Overall: Without page prefixes / 2 Overall: With page prefixes
– Terminals
Import: The EPLAN setting is used on the EXF tab, but is not evaluated
in Comos.
Export: Is evaluated correspondingly in EPLAN.
– Potentials
in Comos.
Export: Is evaluated correspondingly in EPLAN.
– Project data
General details.
in Comos.
Export: Effect in EPLAN unknown.
Other peculiarities at the project level

Comos project options, Options tab:
Do not use any “Spaces ” with units of the same type. This setting cannot be
read within EPLAN.
62.3 Importing EPLAN data (EPLAN -> Comos)
62.3.1 Importing EPLAN article base data into Comos
Exporting article base data from EPLAN

You can find details of the applicable procedure in the EPLAN documenta-
tion. Roughly speaking, the procedure is as follows:

Importing EPLAN data (EPLAN -> Comos) EPLAN (Import/Export EXF)
In the EPLAN main menu: ARTICLE | MANAGEMENT

In the following window, click on DATA TRANSFER | EXPORT.
Only mark the “Individual part ” option in the “EPLAN article manage-
ment - Export ” dialog window. All the other options can be left at the
defaults. The article base data is exported as an asc file.
Importing article base data into Comos

Select ADMINISTRATOR | BASE DATA| IMPORT ECAD COMPONENTS .
See also SECTION 58.2: IMPORTING ECAD COMPONENTS.
The article base data must be imported before the planning data in all cases,
since otherwise the article base data cannot be allocated to these objects when
importing the planning data.
Often the article base data is only imported once, since as a rule the base data
remains constant for a certain length of time.
File
Here the file type must be changed to asc. After that the EPLAN file with the
article base data is selected.
Target
The following object in the default database must be set here by drag & drop:
Import |EXF Eplan | System special symbols |@A Article/Manufacturer cata-
log.
Load accessory
This option is not evaluated in the case of asc files.
ASCII-ANSI character set conversion
This option is not evaluated in the case of asc files.
Log all
If this option is activated, then all the steps of the import operation are logged,
otherwise only any errors that occur.
Comos structure of the imported data

The main level of the base data already exists under “Import |EXF Eplan | Sys-
tem special symbols |@A Article/Manufacturer catalog.“ Base objects are
created at this first level and given Specification tabs on the basis of the
imported data.
First of all, a level is created for the manufacturer and the articles follow under
it. The structure taken from EPLAN as of today is then as follows:
Import

|- EXF EPlan Import/Export

|- System special symbols
|- @A1 Article/manufacturer catalog
| 0 cannot be identified
|-...
|- A Assemblies
|- Bosch
|- 123abc article
|- ...
|- Siemens
|- 456abc article1
|- ...
|- etc.
62.3.2 Importing EPLAN symbols into Comos
Exporting symbols from EPLAN

In the EPLAN main menu: DATA TRANSFER | EPLAN-> EXF EXPORT.
In the following window, click on EXPORT | SYMBOL FILES.
Symbol files have the extension “sym” and can be written as text files with the
extension “asc”.
Import symbols into Comos

The Import/Export dialogue is in the PlugIns iconbar.
The symbol files must be imported before the planning data in all cases,
otherwise the symbols cannot be allocated to these objects when importing the
planning data. Please note: It can be necessary to call up this functionality sev-
eral times if the desired EPLAN project addresses several symbol files.
Often the symbols are only imported once, since as a rule the symbol libraries
remain constant for a certain length of time.
If the base data structure of a symbol file is to be updated, then you must
delete the corresponding base data branch in Comos and reimport the symbol
file.

The “Import symbols” tab

File
Here you can select the asc file with the symbols.
Start object
Optional. Here you stipulate the start object for an article catalogue. Here you
should input the following object in the default release database:
Import |EXF Eplan | System special symbols |@A Article/Manufacturer cata-
log.
If a start object has been set, the symbol base objects receive the correspond-
ing Specification tabs from this branch. Currently this affects the following
tabs:
EBD Mounting data
GD Geometry data
HSD Manufacturer data
LFD Supplier data
EXF
SYS System
The EXF tab in the case of symbol objects

Component type
This field offers a pick list with all the possible EPLAN components. This list
is also given the type of cross-reference of the display. The component type
also determines the allocation of the class, sub-class and “Special symbol”.
See the following.
Caption text
In EPLAN texts that originate from the “Electrical value” and “Additional
text” attributes are output under a device.
The specifications (attributes) “M11 Electrical value” and “M12 add. field”
are therefore created for it on the Comos EXF tab.
These attributes can be joined individually with other attributes by means of
links. Examples:
• In the case of a motor, with the capacity
• In the case of a fuse, with the turn-off capacity.
• In the case of other objects, with the description of the device
(OwnDescription)
Article data
In EPLAN up to 10 article numbers can be allocated to the components in the
project data.

Currently the first article number is read in Comos when importing the project
data and written in the device of the allocated symbol object in the first field
of the Article data .
Comos structure of the imported data

The symbol file is changed into the Comos structure in the course of the con-
version:
1. Central import nodes Import | EXF EPlan
Please note: The import is made into the base project in all cases, even
when a planning project has been opened! You must therefore have the
corresponding function rights.
2. Importing symbol files
One import per symbol file. The symbol files are created as base data;
thus a separate branch is created for each symbol file. If all seven forms
of display of the symbol are used within EPLAN, then seven symbol files
must correspondingly be available and you need to make the import into
Comos seven times.
However, in Comos you are not restricted to seven symbol files.
Underneath Import | EXF EPlan you can create not just seven branches
(= symbol files), but instead as many as you wish.
3. One base object per symbol
One base object is created for each symbol. A symbol holds up to 512
symbols. As a rule, placeholder objects are created for the symbols that
have not been used yet. The Name of the symbol base objects runs from
0 to 511.
The following steps are then carried out in the base objects of the
symbols:
3.1 Determine class / sub-class
The Class / Sub-class is set accordingly:
- Contacts (normally open, normally closed, etc.), component type from
[0 - 49]: class Element , sub-class None
- Coils, component type from [50 - 99]: class Device , sub-class
Contactors/relays
- Terminals, component type from [100 - 149]: class Element , sub-
class Terminal
- All other objects: Class Device

3.2 Transferring the tabs:

EBD Mounting data
GD Geometry data
HSD Manufacturer data
LFD Supplier data
EXF
SYS system
Please note: Nothing is created on the Symbols tab at this level of the
base data. Display of the symbols is only done at the level of “variants”.
4. One element object per “variant”
Up to four elements are created under the base object. Each of the four
elements thus illustrates one of the variants, with which symbols can be
displayed in rotated form within EPLAN.
A base data level is created for the variants in all cases, even if there is
only one variant.
The base data structure looks like the following if configured correctly
(example):
Import
|- DIC_WUPD symbol file
|- ...
|- 259 MMT motor with thermistor
and so on.
The following steps are then carried out in the base objects of the variants:
4.1 Allocation “Special symbols”
Contacts and terminals are identified on the basis of the label
abbreviation (S, SV, etc.). A base object with a matching name is
searched for in the “Import |EXF Eplan | System special symbols“
base data branch. If a suitable base object is found, a base object link
is set on the System tab of the variant object.
This allocation to the objects in “System special symbols“ is also needed
in order to set up a contact mirror.
The base object link breaks the hierarchical inheritance. The element-
object now inherits from the base object to which the reference (link)
points. Exception: Symbol scripts, see below.

If no base object link is set, then the variants inherit from the symbol base
object from 3 the Specification tabs taken from @A Article and the
class/sub-class.
4.2 Transferring the EPLAN symbol to the Symbols tab
A symbol script is created from the data of the ExF symbol file and
stored in Comos at the base object of the relevant element on the
Symbols tab.
This is also done if a base object reference had been set!
4.3 Setting up a naming convention
If there is the corresponding data in the symbol file, a corresponding
text mask is created on the System tab.
This does not occur in the case of a base object link.
4.4 Creating connectors
In Comos symbols must possess connectors so that they can be
connected. This is done by creating the corresponding connectors on
the Connectors tab.
This does not occur in the case of a base object link.
62.3.3 Importing plot frames
Export plot frames from EPLAN

In the following window, click on EXPORT | PLOT FRAME.
The plot frame is written to an exp file when it is exported.
Importing plot frames into Comos

The Import/Export dialogue is in the PlugIns iconbar. Plot frames are
created within Comos in the form of Master Reports.
The plot frames must be imported before the forms in all cases, since other-
wise the plot frames (or in Comos, the Master Report) cannot be allocated to
these objects when the forms are imported.
Often the plot frames are only imported once, since as a rule the templates
remain constant for a certain length of time.

The Plot frames tab

File
Here you select the exp file that contains the plot frame.
Forms to
Plot frames are converted into report templates within Comos. Here you stip-
ulate where the corresponding report templates are to be created. As is usual
within Comos, the report templates can only be created within the base
project.
A document group is already provided within the default release database
from Comos. When the EPLAN data transfer dialog window is opened, this
document group is entered as the default. However, another document group
can be set instead by using drag & drop.
PLC overview
No special plot frames are used within EPLAN for page type PLC overview .
In Comos special reports are used for PLC.
The simplest way to synchronize EPLAN and Comos here is to import the
same EPLAN plot frame twice and to import the plot frame with the PLC
overview option once. Effect:
– PLC overview deactivated: The Master Report that was created is given
the Detail type of diagram.
– PLC overview activated: The Master Report that was created is given
the Detail_2 type of diagram. In addition, the document objects and the
crp files are given the suffix “SPS” at the end of the name.
62.3.4 Importing forms
Exporting forms from EPLAN

In the following window, click on EXPORT | FORMS.
Importing forms into Comos

The Import/Export dialogue is in the PlugIns iconbar. EPLAN forms
are created within in Comos as Sub-reports and thus require a plot frame
to be created as the Master Report.
Often the forms are only imported once, since as a rule the templates remain
constant for a certain length of time.

The Forms tab

Files
A form is selected here. Each form must be imported individually.
Plot frames
Here you stipulate the Master Report that was created in SECTION 62.3.3: IMPOR-
TING PLOT FRAMES.
A Master Report is already provided within the default release database from
Comos. When the EPLAN data transfer dialog window is opened, this Mas-
ter Report is entered as the default. However, another Interactive Report tem-
plate can be set instead by using drag & drop project data.
62.3.4.1 Exporting projects from EPLAN

In the following window, click on EXPORT | PROJECT.
The EPLAN project is exported as an exf file.
62.3.4.2 General import details

• Type of diagram (or a Symbol Type in the report template)
EPLAN pages are converted into one of the DETAIL types of diagrams:
– Page types EPLAN page for PLC and PLC overview (Comos
document objects, EXF settings tab, Page type field) are given the
“DETAIL_2” type of diagram when imported,
– All other EPLAN pages are given the “DETAIL” type of diagram when
imported.
Reports to be evaluated have no type of diagram.
• Document base object
All pages receive @O Documents |EXF EXF Import |EXF Standard.
62.3.4.3 EXF tab import

File
The exf file is specified here.

Options group “Templates”

– Template
Here a plot frame that had been converted is stipulated as the Master
Report.
A Master Report is already provided within the default release database
from Comos. When the EPLAN data transfer dialog window is opened,
this Master Report is entered as the default. However, another Interactive
Report template can be set instead by using drag & drop.
– PLC template
Here a plot frame that had been converted is stipulated as the Master
Report, whereby the “PLC overview ” option had been activated when it
was imported into Comos.
A Master Report is already provided within the default release database
this Master Report is entered as the default. However, another Interactive
Report template can be set instead by using drag & drop.
– Forms
Here you stipulate the document group in which the converted EPLAN
forms are located.
A document group is already provided within the default release database
this document group is entered as the default. However, another
document group can be set instead by using drag & drop.
– Start object
Optional. Here you stipulate the start object for an article catalog. You
should input the following object here in the default release database:
Import |EXF Eplan | System special symbols |@A Article/Manufacturer
catalog.
Options group “Pages”

– All / From...to
As described above, EPLAN only recognizes single-page documents.
These single-page documents are also designated as “pages”.
All activated: All the pages of the project are imported.
All deactivated: State in the From... to fields which pages are to be
imported. In this case an exf file must already have been stipulated. The
page information is taken from this exf file and offered in a dialog
window.

– Only circuit diagrams

Activated: Within this page range only those documents that are
classified as “circuit diagrams” are imported. Currently that applies to
EPLAN pages with the label “1”.
62.3.4.4 The import process
Creation of the report

A report with all the information on EPLAN page is produced within Comos.
Creating planning objects

When the EPLAN pages are imported, the devices and any other objects
placed on them are investigated. The device possess a text that designates the
symbol belonging to it. On the basis of this text, a search is made in the Comos
base data for the symbol file and within it, for the symbol base object.
If the symbol is found, a planning object is created under the report on the
basis of this symbol base object.
Allocation of article base data and symbols

The device on the EPLAN page can additionally have up to ten different arti-
cle numbers. The first article number is written in the above symbol planning
object that has been created on the EXF tab in the first field of the article data.
This article number is compared with the Comos base data in the
@A Article/manufacturer catalog branch. If a base object with the cor-
responding article number is found there, this base object is copied under the
symbol base object. The symbol planning object is then no longer based on
the variant but instead has the article base object as base object:
Import
|- DIC_WUPZ symbol file
|- ...
|- Siemens
|- 456abc Article1

Linking the report objects

No information on links is stored within EPLAN, instead only the relative
position of the objects to one another (under one another, next to one another)
forms the basis of the links. The objects are simply connected to one another
according to their position.
This function is reproduced in Comos when importing.
62.3.4.5 Conversion of individual objects
Allocating a device tag to components

Components without a device tag are collected at a node point. A graphic allo-
cation of the components is done towards the end of the import: A line is
drawn whose height is exactly one grid point. Starting from a component
without device tag, a search is made to the left to the next device tag.
Object without device tag is element: If a suitable object with a device tag is
found, the component without device tag is shifted within the planning data
under the object with device tag that had been found. The device tag is taken
over.
Object without device tag is device: The device tag is used. (In EPLAN it is
possible to have device tags that are not unique.)
It is possible that a component cannot be allocated, in which case it remains
within the collector nodes.
Terminals
1. EPLAN terminals only possess one connector, while Comos terminals
possess two. In addition, the two Comos terminals are classified as
“inside” and “outside”.
The second terminal connector is created automatically and connected
graphically during the import operation. This is done by drawing a line
through the connector that exists and identifies the next connector (in
graphic terms) on the document.
2. A terminal strip is not input in the exf file for each terminal, but only for
specific terminals. The ExF label is not sufficiently unique to include all
the subsequent terminals of this terminal strip (up to the next terminal
strip).
For that reason the allocation of the terminals to the terminal strip is done
as follows:
This allocation is taken over if there is a unique allocation of the terminal
and terminal strip within the ExF data.
All other terminals are allocated on a purely graphic basis. This is done

by positioning the terminals on the document as stipulated within the ExF

data, after which the nearest terminal with a terminal strip allocation is
searched for horizontally to the left. (This is the same method as in the
allocation described above for the device tag.)
Contactors / coils: Normally closed contacts, normally open contacts and

changeover contacts
The names of normally open contacts, normally closed contacts, etc., are not
unique in the ExF data. For that reason the device tag is also accessed. Nor-
mally open contacts are created together with a device tag. If a coil with the
same device tag is found during the import operation, the normally open con-
tacts are shifted to under the coil (the coil becomes the owner of the normally
open contacts).
Path texts
The path texts are taken over and created as report objects. The path designa-
tion is written in the description for all objects of the path.
Screening / shielding
EPLAN cables can have several forms of shielding or screening. The location
of the screen connection can be moved.
This functionality is to be implemented in Comos.
Connector points not joined at a connection

In EPLAN connectors can exist at a connection without actually being joined.
This is not possible in Comos, since all connectors are automatically linked to
connections. The conversion still remains open concerning this point.
Connections
In EPLAN connectors are automatically joined when they are uniquely allo-
cated in graphic form (for example, vertically under one another without any
obstacles in between).
If you do not want an automatic connection of this type in a particular case,
then you have to place an “interrupter” between the connectors in question
between the two objects.
If a connection has to be “bent”, then “diversion points” must be placed, these
being objects that only go to one connection and continue on at a right angle.
All these functionalities are reproduced when importing and exporting.

Working in Comos with (imported) EXF data EPLAN (Import/Export EXF)
PE connectors
PE connectors are not uniquely marked as such in the ExF data. The conver-
sion still remains open concerning this aspect.
Potentials
Potentials are always logical in EPLAN. Comos recognizes logical and phys-
ical potentials. All potentials are created as logical potentials in an import
operation. Physical potentials are changed to logical potentials during an
export operation.
62.4 Working in Comos with (imported) EXF data
62.4.1 Ready-made labelling systems and objects
If you right-click on the globe in the Units tab or the Locations tab, a number
of objects are offered to you.
A mixed system is made available on the Units tab: sub-units and also loca-
tions can be created underneath units.
Only locations can be created on the Locations tab.
This object structure directly implements the Page numbering function
from EPLAN and may not be changed. See SECTION : THE EXF TAB concerning
Page numbering .
Please note: if you export to EPLAN, the existing object structure, in connec-
tion with the Page numbering project option, has a decisive effect on the
page numbering created within EPLAN.
In other words: If you freely plan within Comos and then transport this data
to EPLAN, then you must pay close attention to ensure that the existing struc-
ture of the planning objects matches up with the Page numbering setting in
the project.
The labelling systems are based on the base objects in Import | @EXF EPlan
Im-/Export | @EX objects under mouse menu new.
This catalogue is a copy of the Comos EE catalog but without its links and ref-
erences. This means that this catalogue always has to be maintained sepa-
rately.

EPLAN (Import/Export EXF) Working in Comos with (imported) EXF data
62.4.2 Ready-made objects in the categories
Categories are offered underneath the locations. This is purely a technical

point within Comos. Categories are automatically folders:
• Only specific objects are offered in the mouse menu of a category object.
Thus only specific objects can be created.
• And vice versa: the objects belonging to a category are automatically moved
there if they are created at another point.
62.4.2.1 Documents category
Circuit diagram
The circuit diagram has a document-specific symbol bar with the most impor-
tant symbols.
PLC cross-references list

That is a PLC overview. PLC report templates also have the scripts required
for PLC terminals. See also the PLC device box in SECTION 62.4.2.3: CATEGORY
CONTROLLER.
62.4.2.2 Terminal strips category

Terminal strips have two stages in Comos: The terminals are elements of the
terminal strip. Before the terminals can be placed, first of all a terminal strip
must be created.
Procedure:
• Create a terminal strip (special symbol -91)
• Create one of the terminals offered
• Place the terminals
62.4.2.3 Category controller
PLC device box

The PLC device box also belongs to the “special symbols”. This is displayed
as a “segment” on the circuit diagram and on the PLC cross-references list
report. The PLC device box object offers the following elements in the mouse
menu:

Working in Comos with (imported) EXF data EPLAN (Import/Export EXF)
• PLC terminal
PLC terminals can be placed both on circuit diagrams and on PLC cross-
reference lists. The PLC terminal can be regarded as a type of channel. PLC
terminals are also called “end terminals that can have cross-references”.
Terminal setting tab:
The channel address is input in the PLC address field.
The channel type is input in the Connector type field.
• Terminal
“Normal” terminals possess no address, but can be allocated to a type of
channel. The type of channel can be stipulated on the System tab.
“Normal” terminals can only be placed on circuit diagrams, not on a PLC
cross-references list.
• Plugs
As for terminals.
62.4.2.4 Cables category

Cables as per VDE and the special symbol “-93 cable” are offered here.
Special symbol “-93 cable”

Cables have two levels in Comos: The wires and screening are elements of the
cables. The cable is placed on the report, not the wires (differing from a two-
stage terminal strip!).
Procedure:
• Create a cable (special symbol -93)
• Create the wires or screening
• Place the cable on the report
Alternatively:
If only the screening needs to be displayed graphically or if you only have a
screened cable, then the procedure is as follows:
• Create a cable (special symbol -93)
• Create the shielding
• Place the shielding on the report
62.4.2.5 Category Devices

All the electrical devices are offered here.

EPLAN (Import/Export EXF) Exporting from Comos (Comos -> ExF)
Contacts (normally closed, normally open) for coils or switches

The object first has to be selected in the case of contacts that only exist as ele-
ments under the object. Example:
• Select a safety coil
• Select a contact for the safety coil
• Place the contact in the report
62.4.3 Cross-references
Objects that have been placed several times in the circuit diagram are played
with cross-references. Example: an auxiliary contact of a protective motor
switch.
If symbols possess a cross-reference of this type, then the display of the cross-
reference can be controlled within the context-sensitive mouse menu for the
symbol:
• Mouse-click on the symbol
• Right mouse button | SETTINGS | COMPONENT TYPE
• Select the type of cross-reference
62.5 Exporting from Comos (Comos -> ExF)

This section concerning exporting from Comos to EXF can only be under-
stood if you have already read the section about importing. The following
only describes those input fields and procedures that differ from those for
import operations.
The export dialogue is in the PlugIns iconbar export tab
General points regarding export

The Specification tab EXF settings is in the Properties window of the report.
Page type :
All pages are exported as “free graphics”, with the exception of pages of types
EPLAN page and PLC EPLAN page .
The EXF export tab

File
Input here in which exf file the export is to be made.

Exporting from Comos (Comos -> ExF) EPLAN (Import/Export EXF)
Start object
– Start object is a document: only this document is exported.
– Start object is a unit, location or document group: all the documents
located under it are exported. This also includes those documents that
only exist under the start object as a reference or link: the document links
are traced back to the original and this is exported as well.
– Start object is blank: all the documents of the entire project are
exported.
62.5.1 The Export symbols tab
The Export symbols tab makes it possible to export a previously imported

symbol library or a symbol library that had been created within Comos
according to the rules for EPLAN.
The EPLAN methodology regarding symbol libraries

See SECTION : COMOS STRUCTURE OF THE IMPORTED DATA.
It is necessary to pay special attention to the following points when exporting
symbol libraries:
• The Component type field must be set in a valid way on the EXF tab.
This field offers a pick list of all possible EPLAN components.
• The Label must be filled in. The symbol name is entered in the Label ; this
is the designation by which the symbol is identified within the symbol file
in terms of the contents.
LABEL COMPONENT TYPE

C Capacitors
D Delay and storage devices
E Various (lighting, heating)
F Protective devices
G Generators
H Indicator modules (optical and acoustic)
K Contactors, relays
L Inductances

EPLAN (Import/Export EXF) Exporting from Comos (Comos -> ExF)
M Motors
M6 Motor with 6 connectors
N Amplifier regulators
P Measuring and test devices
Q Main power switchgear (power switches, protective
switches
R Resistances, potentiometers
SL Normally open power contacts
S Switches
T Transformers
U Modulators, converters
V Semiconductors, pipes
W Changeover contacts
WM Changeover contacts, middle
WR Changeover contacts, right
X Terminals, plugs, sockets
Y Electrically operated mechanical devices (solenoid
valves, brakes)
Z Termination, filters, rectifiers
O Normally closed contacts
B Transducers to convert non-electrical parameters to
electrical parameters and vice versa
• The Name must be unique and should be meaningful

The symbols belonging to the standard as named as follows:
1st character: device ID character
2nd character: number of connector points

Exporting from Comos (Comos -> ExF) EPLAN (Import/Export EXF)
Example: fuses.
There is a fuse F1 and a fuse F3 in the symbol file from EPLAN. The ID
character for protective devices (fuses) is F. The number of current paths
then follows: 1 for an individual fuse (1 current path) and 3 for the 3x fuse
with three current paths
• Symbols tab:
Note the following regarding the symbol:
– It must be a quad grid.
– The connectors must be located on the grid points
The Export symbols tab

• Export to file
The file name under which the symbol library is to be exported.
• Symbol file to be exported
Root nodes of the symbol library to be exported. This field is set with drag
& drop.

Diagram type DESIGN Overview
63 Diagram type DESIGN
63.1 Overview
Diagrams of diagram type DESIGN are two-dimensional scale drawings in
which the size and location of components are shown. For this purpose, only
the external dimensions of a component and any actual connections are of
importance. DESIGN diagrams include:
• Control cabinet diagrams (so-called “design diagrams”)
• Installation diagrams
• Tray diagram (in preparation)
63.2 Control cabinets (“design diagrams”)
63.2.1 Views for design diagrams
63.2.1.1 Definition of the views

DESIGN diagrams are two-dimensional (a flat piece of paper), but are
intended to display three-dimensional objects. In order to do this, you work
with “views” on a DESIGN diagram.
View: a special rectangular point of view on the planning. Views are also
called “sections”.
In other words: in a design diagram you can view Z
the objects from the front or from the left, etc. For
this, a rectangular system of coordinates is used as Y
the basis:
In exactly the same way that a cube has six sides,
there is also a maximum of six possible different
X
views:
Front view (XZ plane)
Side view, left (YZ plane)
Side view, right (YZ plane)
Rear view (XZ plane)
Ground plan, from above (XY plane)

Control cabinets (“design diagrams”) Diagram type DESIGN
Ground plan, from below (XY plane)

But it is impossible to freely select a viewing angle and to view the planning
from “diagonally from the left and above”. This sort of “free view” is only
available in the 3D module.
63.2.1.2 Operation of views
Placing a view
From a technical point of view, a view is a “projection”. This means that it is
first necessary to calculate what exactly is visible from one point of view
because objects could be concealed by other objects.
This calculation takes time. For that reason no views are placed initially on a
DESIGN diagram. The user decides for himself whether he requires a front
view, a view from above, etc. If you are planning a simple control cabinet,
then often just one view is enough: the front view.
Therefore, the first work step in a design diagram is always to place at least
one view:
This frame is a particular view and determines the area in which you will
work. Thus it is not permitted to let any objects “stick out” out of this view
frame.
Working without views

From a technical point of view, it is also possible to work without a view hav-
ing been placed. For that purpose, the DESIGN diagram type (without a suffix
such as “DESIGN_XY”, etc.) is provided in the StandardDB. The DESIGN
diagram type displays the objects in the same way as in the DESIGN_XZ dia-
gram type (front view).

Diagram type DESIGN Control cabinets (“design diagrams”)
However, this way you lose the option to display the design diagram in Viper
3D.
It is not possible to subsequently drag a view onto objects that have already
been placed. If you started without a view, then the report must also remain
so (or else have all its contents removed).
Multiple views
It is possible to place all six views on the report. However, that will greatly
increase the time needed for calculation of the report. Thus, only four of the
six views that are possible are prepared in the icon bar for the sample reports:
Please note: Each of the six possible views (“front view”, “side view left” etc.)
may only be placed once on a report. For technical reasons a user is not pre-
vented from placing a particular view multiple times on a report, but the
design diagram will not function correctly in such a case.
Interaction between multiple views

If multiple views had been placed, then all of them are always refreshed and
updated. Thus, if a component is placed in the front view, Comos uses infor-
mation such as the dimension of this component and the dimensions of the
other components already placed etc. to calculate an automatic placing for the
other views, and also displays them immediately.
Often, this automatic placing will not exactly meet your expectations. You
then have to mark the component in the relevant views and move it to the
desired position.
Retrospectively placing views

If the views already contain objects and an additional view is placed, this new
view is initially blank. In order to fill the view that was placed subsequently,
use the following command:
Select view, mouse menu |VIEW/SLICE |PLACE OBJECTS (2 1/2 D)
Mouse menu “View/Slice”

Right-click on the frame of a view. The | VIEW/SLICE menu is in the mouse
menu. The individual commands are as follows:

| PLACE OBJECTS (2½D)

The placed components are calculated and displayed for all views. For exam-
ple: If all the views already contain objects and an additional view is placed,
this new view is initially blank. Use the above command to fill the view that
was placed later.
| SET WORKING HEIGHT
The position of an object in space is described by three coordinates. However,
if, for example, you place an object within the front view, only two of the three
coordinates have been specified: the width and height coordinates. For this
reason a depth coordinate is automatically assigned to each object placed in
the front view by means of the working height.
The working height currently set in the front view is displayed in the side
views by a vertical broken line. If the working height of the front view has
been set to 250 mm, for example, and if you place an object in the front view,
this object is placed 250 mm deep in space in the left-hand side view. The
working height can be changed in the | VIEW/SLICE| SET WORKING HEIGHT
menu.
In the same way, the side view likewise has a working height, specifying
where an object that has been placed in the side view is to be inserted within
the front or rear views.
You can also specify that the working height of one of the placed objects is to
be the new current working height. Do this by selecting the object and then
call | OPTIONS | SET WORKING HEIGHT from the context-sensitive mouse menu.
The unit for the working height is tied to the unit used in the report template
(default: mm).
The working height is managed as an attribute in the properties of the view
object: tab GD Settings, attribute WorkingZ Working depth .

Selection of views
When you select a view, the grab points of the view are displayed. In addition,
some of the other views - but not all - also receive grabs:
This is normal and has technical reasons.

Please note that the views may not be manipulated by means of these grabs,
since otherwise the edges of the view no longer lie exactly within the cube.
As a result, the design diagrams would no longer function correctly.
63.2.2 Technical implementation of views / symbols for views
View-specific diagram types / view-specific symbols

It was already explained that there can be up to six views in DESIGN dia-
grams. In other words, there can be up to six different forms of display for
each object that has been placed on the report. However, the display of objects
on a report is done by means of symbols.

For this reason objects that are used in DESIGN diagrams must possess six
different symbols. Six diagram types were created for this purpose, with each
diagram type relating to just one of the six views:
However, the symbols of these six diagram types are not created by drawing
them in the Symbol Editor. Instead they are the result of a script. If the dimen-
sions of the component are changed, the displays resulting from this are then
automatically made available as symbols.
On the Symbols tab of the base objects there aresymbol scripts for the
DESIGN...diagram types that must not be deleted.
When you place a view on a design diagram, then a corresponding @SEC-
TION...” planning object is created in the planning data underneath the report:
The main function of this view frame is to read one of the diagram types and
to display the corresponding symbol.

Base objects of the views

Each view has a base object of its own. The base objects of the views are
located in: ET |1 Modules |A Cabinet engineering |A Library
objects |V Views.
63.2.3 Administration of design diagrams
63.2.3.1 Attributes of the cabinet objects

The base data of the control cabinets is located in:
ET |1 Modules |A Cabinet engineering
63.2.3.1.1 Tab “EBD Installation data” in the case of design diagrams

All the objects that are placed on DESIGN diagrams are provided with the
EBD Installation data tab in the base data.
If the tab is missing, it can be created with the help of database adjustment,
(see SECTION 49.3: DATABASE ADJUSTMENT). To be able to use an object on a
DESIGN diagram, this tab must contain meaningful data.
“Device dimensions”
Contains the actual data of the component dimensions. Mass: This is evalu-
ated in the overall calculation of the mass.
The remaining attributes are self-explanatory.

“Mounting distance (mm) to”

The distances from other components are entered into this column. They are
evaluated on the consistency check report.
“Area for mounting (mm) from”

This is part of the online test. Activates the online test:
ET |O |PED Design diagram, tab SYS , attribute ONLINETEST .
“Design diagram settings”

• FFRAME Frame
Points to a CDevice in branch ET|Z Symbol construction . On the
Symbols tab, the CDevices each possess their own scripts that point to a
DLL in which the external contour - a rectangle - is calculated. It is therefore
not possible to create symbols of your own here.
There are a number of different variations in the StandardDB. These
variations do not differ in their external dimensions but as regards their
various points of origin and the calculation of their level (working depth).
• FGRAFIC Graphic
Here, additional graphics can be called and placed on the external contour.
The “graphic” covers the external contour. The format of the “graphic” is
one of the formats that are usual in Comos; it can be a Comos symbol, a
bitmap or a jpg. The size of the “graphic” should be matched to the size of
the external contour to produce a meaningful image.
• BACKGROUND Background
Determines the fill color of the object.
• BMKOUT Label at
Displays the label either in the symbol of the front or rear view, and at the
position that was defined in the symbol of the front or rear view.
• CP1 Conn. top/CP2 Conn bottom
These details control whether the connectors are to be displayed at the top
or bottom:
Listing: CP1;CP3;CP5 (hence without spaces!)
Wildcard, * for all at the top/ * for all at the bottom
Blank entry, - for blank
• RASTER Grid
The grid is superimposed on the design diagram as a box-like structure and
also provides snap points to place other objects.

The following options can be activated separately for the diagram (the report)
and for printing. These options are summarized as “Diagram <- Display ->
Printer ” to make it clear that the options on the left control the display in the
diagram and the options on the right the printing of the relevant information.
• Construction lines
Construction lines centered vertically and horizontally.
• Mounting distance
Dotted line around the external contour.
• Area for mounting
Dotted line within the symbol
• Drill holes
Display of the drill holes, if defined.
• M027 Mounting type/ M028 Instruction
Self-explanatory
• M029 Mounting
Controls whether another component may be placed on this one. An error
results in a warning message.
• M029A Cabinet type
Classifies an object. This attribute works together with the MKY Mounting
key tab. See ETK025, P. 63-12.
63.2.3.1.2 Tab “GD 3D”

General dimensional details for the three-dimensional display of objects. You
only get an actual 3D display if you have a Viper license.
However, this tab may not be deleted, even if you are working without Viper.
The reason for this is that the tab also contains the consistency check and
internal calculations.
Besides, the names of the attributes on the GD tab are binding.
Deactivated attributes may not be modified.
• VGEO 3D-type
Controls the displayed 3D body.
• VSUI Editable
Is only evaluated in Viper. If a specification is entered here, then an edit
field appears in Viper. Enter the specification via NestedName, for example
GD.V001.

If you wish to have a corresponding edit field on an Interactive Report as

well, the VSUI attribute must also exist on the SYS tab. Example: ET |1
|A |A |B |11 C-rail, general symbol.
• LAYER Layer
Sets a layer. If this layer is hidden in Viper, the component is no longer
visible.
• Position of origin
Controls the point of origin of the cuboid and thus also the positioning of the
cuboid in 3D.
The default is centered vertically and horizontally.
• Values for cubical objects / Values for cylindrical objects
The user must make sure that he has filled in attributes that match the 3D
type.
63.2.3.1.3 Tab “MKY Mounting key”

This tab lists the entries from standard table ETK025 , see ETK025, P. 63-12.
Here, the Name of the checkboxes must be written in the same way as the
Description in the standard table.
When mounting is done, a check is made to determine whether the cabinet
type, as it had been set in attribute EBD Mounting data :M029A Cabinet
type , belongs to the list of permitted types on the MKY Mounting key tab.
• Tab MKY Mounting key does not exist:
All cabinet types are permitted.
• Tab MKY Mounting key exists but no entry selected (the collective string
of permitted cabinet types is blank):
All cabinet types are permitted.
• Tab MKY Mounting key exists and at least one entry was activated:
Only those cabinet types that had been entered here and activated are
permitted.
The user gets an appropriate message if a prohibited cabinet type is installed.
63.2.3.1.4 Tab “BHD Drill data”

If the tab is missing, it can be created with the help of database adjustment,
see SECTION 49.3: DATABASE ADJUSTMENT. The actual data of the drill holes is
entered on this tab.
Examples: Mounting rails, mounting plates

Comos can evaluate the actual drill hole data of the installation planning by
means of an Evaluation Report. A report template is given in the base project
in branch Crp Report templates |ET |PDA Data sheets|-PDA.01.
In order to do so, the following details must be available:
Tab EBD Installation data : the Mounting instructions: Mounting type
attribute must be set to Screwed , Bolted, Pinned or Riveted .
The Evaluation Report should be located underneath the object of the mount-
ing plate. The system: The mounting rail is first of all given its own drill holes;
and after that the mounting rail transfers these coordinates to the mounting
plate.
Drill hole objects : [CREATE]
Creates planning objects for drill holes in the Navigator. However, these are
not placed automatically on the report but must be placed by the user.
63.2.3.2 Views
Each view has its own base object. The base objects of the views are located
in: ET |1 Modules |A Cabinet engineering |A Library objects
|V Views. See also SECTION 63.2.2: TECHNICAL IMPLEMENTATION OF VIEWS / SYMBOLS
FOR VIEWS.
63.2.3.3 Using third-party data

The mounting data for the components changes constantly. In addition,
changes regarding the safety clearances and distance etc. may occur. For these
reasons it is not possible to develop an exanple database.
Because of that the dimensional details of the current components, as speci-
fied by the manufacturer, must be imported into the base data by the Comos
administrator as the first step.
63.2.3.4 Standard tables
63.2.3.4.1 ET |Y Attributes catalog

The following only deals with special points.

63.2.3.4.2 0 Attribute collection: 02 Construction
ETK025
The table is used to monitor mounting in control cabinets.
Name Unique string
Description Any. This is the visible text in the Cabinet type
dropdown list.
Value 1 Relative installation height.
Value 2 Contains data for export to Triathlon.
MP = Mounting Plate; MS = Mounting Rail; BT =
Component; KK = Cable Tray.
Value 3 - Not used.
Value 10
Value = 1: cabinet frame, this is excluded from all control checks. The cabinet
frame be set to value = 1.
Value > 20 and not placed on the plate / rail. etc.: Message: Floating freely in
space. This warning message is also output in the following Evaluation
Report: base objects, ET |1 Modules |A Cabinet engineering
|A Library objects |0 Cabinet system |PQA.1 Check for consist-
ency.
Call of the following list: tab EBD Installation data , attribute

M029A Cabinet type . Example:
ET |1 Modules |A Cabinet engineering |A Library objects
|A Cabinet parts
Comparison with the “Mounting key” tab

Tab MKY Mounting key : The entries from the above standard table are listed
again on this tab. Here the Name of the checkboxes must be written in the
same way as the Description in the standard table.
See SECTION 63.2.3.1.3: TAB “MKY MOUNTING KEY”.
63.2.3.5 Report templates

Symboltype = “DESIGN”
Application = “ELO.DESIGN”

ConstructionMode = 1
In design diagrams it makes sense to work with the construction mode
(ConstructionMode = 1). This activates the extended placing points. In the
construction mode lines and dimensions snap not only to the grid but also to
the grabs of the objects.
ConnectionLineMode = “R”
Activates autorouting.
MainDocument.DrawingScale
This controls the scale of a diagram with diagram type DESIGN. Example:
MainDocument.DrawingScale = 1/10. This reduces the size of the display
of the symbols on the report. The report itself remains unchanged.
A report template has been prepared in the StandardDB:
CRP |ET | PED Design diagrams| PED.01 Design diagram
Icon bar
The icon bar is organized by means of specifiactions. The options script of the
report contains the following call:
Set SpS = Document.Specifications.Item("SYS").Specifications
etc. This calls the specifications that are located in the properties of the design
diagram on the SYS System data tab.
63.2.4 Examples
Two examples have been prepared in the mouse menu of the design diagram
(control cabinets): mouse menu of the report, |NEW |D CABINET ENGINEERING.
“01 Cabinet (example)” is suitable for beginners.
The example “51 LSC predesigned frame for PLC cabinet, type SPS 06” orig-
inates from the sample catalog for Lütze Systems:
ET |1 Modules | A Cabinet system |C Structures |L Luetze
Systems |B |S01 Cabinet, W 600

63.2.5 Using design diagrams
63.2.5.1 Creating and placing objects
Circuit diagram
In practice, the circuit diagram will be created first. Its cabling is then trans-
ported onto a control cabinet diagram. The following gives a small example
that shows how to proceed without a circuit diagram.
Planning the unit and location structure

In the simplest case you first create one unit and then one design diagram and
one control cabinet underneath this unit.
If the control cabinet and the design diagram are not located under a common
owner or if it is not possible to make a unique allocation for other reasons, you
must then specify in the control cabinet which report it belongs to:
Properties of the control cabinet, specifications tab SYS System data ,
attribute REPORT Design diagram .
The following introduces a simple example:
Do this by creating a unit and selecting |NEW |NEWS DOCUMENT from the mouse
menu of the unit. Report template ET |PED|PED.01 is given to this document.
Next. select |NEW |NEW OBJECT from the mouse menu of the unit. Assign base
object ET | 1 |A |C |C |S01 to this object.
Placing views
First of all place one or more views as described before. If, for example, the
front view is placed as the first view, it is still blank. If the left-hand side view
is placed as the second view, a dotted line then appears in the front view. This
line represents the working height of the side view. And vice versa – when the
report is refreshed, updated or saved – the working height of the front view
appears in the side view.

Once a view has been selected, the edit field Working depth appears in the
icon bar:
The associated dotted line is shifted if you enter another value and update the
report.
Cabinet parts
Next, place the cabinet frame in one of the views; the cabinet frame is auto-
matically placed in the other views at the height of the working depth of the
views.
All the required objects are prepared in the mouse menu of the cabinet frame:
Create the objects in the Navigator and then place them in the design diagram.
Please note that the display of the cabinet parts differ, depending on the view
in which the cursor is currently located. For example, the back wall should be
placed in the front view or back view because it will only be shown as a line
in the other views.
Mounting parts
The rails can be created on the report and rotated as desired. However, only
horizontal and vertical fastening makes any sense.
Tray parts
The trays can also be created on the report and rotated as desired. And here
too, only horizontal and vertical fastening makes any sense.

If a tray is placed on the edge of another tray, then the other tray lights up in
yellow:
The two trays are then connected in the planning data. In order to connect
them, CX connectors are created and then automatically joined.
If the trays have been connected correctly in this way, they will be considered
during the autorouting process.
Slotted hole
Hole objects have been predefined in the icon bar:
These hole objects have two grabs:
Use the left-hand grab to change the height of the object and the right-hand
grab to change its length . You cannot rotate it.
The slotted hole does not create a planning object but only exists on the report.
There are further graphical auxiliary symbols in:
ET |1 |A |A |D
and in
ET |Z |Z

Deleting
| DELETE| OBJECT
The object is deleted from all view of all reports and the planning data.
| DELETE| IN ALL VIEW MODES
The object is only deleted from the views of this report.
Positioning EE objects
Almost all objects of the EE catalog (ET |D Devices) may be placed on
design diagrams.
Use drag & drop to move components into one of the view frames. Many of
the components are symbolized with a captioned box. These components are
displayed in the proportions that had been specified in the data of the Instal-
lation data specifications tab: group Device dimensions , attributes Width ,
Depth , Height .
As a rule, terminal strips are displayed in full in DESIGN diagrams when
placed, meaning with both free and occupied terminals.
Effect in the planning data

The views are created underneath the report and the planning objects of the
control cabinet parallel to the report.
Differing from the usual structures, the planning objects of the control cabi-
nets have multiple DocObjects: one for each view. Thus if a design diagram
has three views then the planning objects will also have three DocObjects.
63.2.5.2 General information on operation
Placement check in the design diagram

Comos carries out automatic placement checks if the Placement online
checking? option has been activated in the Properties window of a report on
the System data specifications tab. If an object is not placed in accordance
with the placement rules, the user is informed of this by a warning. The fol-
lowing checks are made:
• Width check: checks whether the object protrudes over the dimensions of
the component on which it was placed.
• Width check with mounting area: checks whether the object lies within the
mounting area determined for the component on which it was placed.
• Mountability: checks whether the component that was placed on the object
is allowed to be mounted at all.

• Mounting key: checks by means of the mounting key whether the object is
allowed to be placed on the component.
The width, mounting area and mountability of a component are specified on
its Installation data specifications tab. The mounting key is determined
through the Mounting key specifications tab of its base object.
Selection
A typical feature of DESIGN diagrams is that various objects lie on top of one
another, depending on the relevant direction of viewing.
If you click somewhere in the DESIGN diagram, then the component that is
in the foreground is selected first of all. The next click activates the grab
points (grabs) of this component. Then comes the object lying underneath,
then the grabs of this object, and so forth.
From a technical point of view, the coordinates of the placement point are
evaluated during the selection (the so-called “Z order”). Since DESIGN dia-
grams are logically three-dimensional (even if you have activated only one
view), the placement point of an object also has a three-dimensional coordi-
nate.
The actual order of the coordinates (and hence of the objects) is evaluated. If
a user places the objects in an order that does not make sense, the selection
will also be made accordingly.
If the base data is configured correctly (for example, by means of Mounting
key ), then there will be automatic monitoring during the placement. It is
checked whether the order is permitted, and if it is not, the user is notified
accordingly. However, the placement will not be prevented.
Hiding
Objects selected in a view can be hidden in this view by using the | OPTIONS
| HIDE mouse menu. They remain visible in all other views.
If a view on the report has at least one hidden object, the view object then
offers the | VIEW/SLICE | SHOW ALL OBJECTS mouse menu.
Construction mode
If the construction mode had not already been activated by means of the report
template, then do so from the mouse menu: click on the report, | OPTIONS
| CONSTRUCTION mouse menu.
Extended placement points can be activated with the “Construction mode”
option. In construction mode lines and dimensions snap not only to the grid
but also to the grab points of the objects.

Scale
There is the | OPTIONS | SCALE FACTOR command in the mouse menu of the
report.
It is used to reduce the display of all the symbols on the report. The report
itself remains unchanged. This setting overrules the corresponding setting in
the report template.
Please note that the view objects themselves also have the option to set a scale.
Please leave the default settings unchanged, since otherwise the calculation
times will increase excessively.
63.2.5.3 Automatic routing in design diagrams

The prerequisite for routing in design diagrams is that the objects have already
been connected correctly in the planning data. That is the case if, for example,
a circuit diagram had already been created during the preliminary work.
EE objects are connected correctly if the connectors match one another. In
many cases Comos will prevent the wrong sort of connectors from being
joined at all. But sometimes Comos cannot tell at once whether the connector
logic is incorrect.
An example of connectors that have been joined correctly: a CP1 connector is
joined with a CP2 connector.
The autorouting command of the design diagram can be found in the mouse
menu of the view object: | VIEW/SLICE | AUTO ROUTING. This determines within
the view the shortest route for the cable tray made available between all con-
nectors of type EE/I&C that are joined to one another.
Autorouting functions for the following views:
• XZ (front)
• -XZ (rear)
• XY (top)
Here the cables are also placed in the tray ducts through which the routing is
to be done. In other words: the cable is entered in the corresponding attribute
of the duct in the planning data.

63.2.5.4 Interaction with VIPER (3D)
3D views
A three-dimensional display is also provided if a “2D/3D installation engi-
neering” (Viper Electrical Engineering) license is available.
Select within the Navigator the unit under which the design diagram is
located.
Click in the Comos menu on |VIPER 3D EDITOR |ELECTRICAL ENGINEERING.
Importing Viper objects

You can create 2D views that can be placed in design diagrams by using the
Viper 3D tool. If an object was placed in the 3D view, you must select the
| VIEW/SLICE | PLACE OBJECTS (2 1/2) mouse menu so that it is displayed in the
2D view as well.
63.2.5.5 Evaluation
Consistency check
The placing of components is checked by means of an Evaluation Report. A
visual collision check is possible with the “2D/3D installation engineering”
license.
Report template: |Crp |ET |PQA| PQA.13 Check for consistence
(cabinet).
The report for consistency checking has also been prepared in the context-sen-
sitive menu of the control cabinet.
63.2.5.6 Printing
Print symbol backgrounds

Symbols can be given a colored background in DESIGN diagrams. This is
especially often the case in the construction of control cabinets: the symbol to
display the control cabinet or a strip, etc., is filled with a color. The colored
backgrounds are printed as well.
Print view frame (Views)

Views are displayed and delineated by frames within design diagrams. These
frames are no longer printed as well, by default. Set the following attribute to
determine whether or not the frames are to be printed as well:

Diagram type DESIGN Installation diagrams
ET | 1 Modules | A Cabinet engineering | A Library objects

| V Views:
Specifications tab GD Settings , option PRINTVIEW Do not print view .
63.2.6 Interface: Metzner Triathlon
A design diagram that had been produced in Comos can be exported and pro-
cessed further by the Triathlon program from Metzner GmbH.
A design diagram must be created so as to be able to use this interface. There
is the SYS.SYS99 button on the design diagram.
If this base object is used, the attribute [Export -> Triathlon ] can be found in
the document.
If the button is pressed, the report information is then written in a Triath-
lon-compatible data format. Currently the attribute of the button determines
where the file is written: Properties window of SYS99 Export , tab Script ,
function OnClick(): filename = "[path details]"
The filenames are normally:
<Report name>.ABP
<Report name>.VER
The file that is written looks something like the following:

ARBEITSFLÄCHE:42000==29700==C:\Temp\Aufbauplan.ABP
FELD:4040==2600==5000==10000===@U1MA01
HUTSCHIENE:4040==6200==4830==800==0==Unbekannt==@U1==ANLAGEN
UNDEFINIERT:4040==11100==@U1|AD01
63.3 Installation diagrams

The aim of the installation engineering is to draw a primitive ground plan and
to place in it control cabinets, distributor boxes and to display their connec-
tions with one another and to the outside world.
63.3.1 Views for installation diagrams
Installation diagrams also have views, as introduced in SECTION 63.2.1: VIEWS

FOR DESIGN DIAGRAMS. But the views can only be used to a very limited extent in
installation diagrams.
The base objects of the views for installation diagrams are located in:

Installation diagrams Diagram type DESIGN
ET |1 Module |B Installation engineering |A Base objects |V

Views
However, in practice only two views are used:

ET |U |A |A |1 |@SECTION.XY (ground plan from above)
ET |U |A |A |1 |@SECTION.XZ (front view)
Only the ground plan is placed in most installation diagrams.
63.3.2 Administration of installation diagrams
63.3.2.1 Attributes of the installation diagrams

The base data for installation engineering can be found in:
ET |1 Module |B Installation engineering
ET |U Units |A Installation engineering |A Unit
63.3.2.1.1 Cable tray

ET |1 Module |B Installation engineering |A Base objects
|A Cable trays |01 Cable tray, general symbol
A cable tray is a connection between two cable insets. The base object of the
cable tray has no attributes of its own but instead is only the owner of the con-
stituent parts:
• Physical tray elements (arc, rise, line, T-piece)
• Logical tray components (ducts)
63.3.2.1.2 Arc, rise, line, T-piece (physical tray elements)

|B Tray elements
Under it is the base object for arc, rise, line, T-piece.
Tab GD 3D
The default settings should only be changed by experienced users. The group
“Values for cylindrical objects ” must be filled out if 3D type “Cylinder ”
or “Cylinder segment ” has been selected.
Tab Symbols
As stated above already, only two of the six possible views are used (plus the
DESIGN diagram type without suffix).

63.3.2.1.3 Duct (logical tray component)

|B Tray elements
Under it is the base object for a duct.
A duct is a logical constituent part of a tray. You thus cannot touch a duct,
since it is a grouping of cables in terms of contents. The cables run within it.
The duct is displayed graphically as a caption field and is responsible for the
logic of the tray system for matters such as length calculation or degree of
occupancy, etc.
Tab TD Technical data

Width, Height, Diameter
Cross section for calculation of the space required.
Dropdown list cable class
This detail for the checking of the permitted type of cable is used in the instal-
lation diagram.
Field Tray length
Calculation of the actual tray length from the placed duct elements.
Field Occupied to
Automatic calculation of the degree of occupancy. First of all, the amount of
space available is calculated from Width, Height, Diameter . Then the value
of the Required area field is read from the placed cables and added; after
that, the space required by the cables is set in relation to the amount of space
available in the duct.
List
Link attributes containing the cables that have been run in this duct (these are
created automatically!) are managed in the list.
Relation between cables and ducts

ET |D Devices |W Cables |A W Cables acc. to VDE
The following attributes in the cable objects are solely of interest for installa-
tion diagrams (evaluation in the duct): Bending radius, Cable class, Length,
Weight/Meter, Total weight.
Tab “Symbols”
Only the DESIGN_XY view is specified for the duct, since it is the only view
that is important in practice.
|D Plan view

Objects (and the mounting data of these objects for 2D/3D) required for draw-
ing the ground plan are located here. For example walls, windows, etc.
63.3.2.1.4 Cable insets

|E Cable supplies
Cable insets are objects that mark the beginning and end of a tray. Example:
cable supplies.
Tab “Symbols”
Cable supplies are also used in SLINE circuit diagrams.
63.3.2.1.5 Installation objects

|I Installation objects
Tab “SYS System data”

Symbol as drawn
No scaling on placing. Hence the object always remains the same size.
63.3.2.2 Report templates
63.3.2.2.1 Installation diagram

ET.PLH.PLH.01 Installation diagram
Creation via |NEW DOCUMENT, Report tab, template [...]
Tab “YS Settings”

The icon bar is organized by means of specifications. There is the following
call in the options script of the report:
Set SpS = Document.Specifications.Item("SYS").Specifications
and so forth. This script calls the attributes that are to be found in the proper-
ties of the installation diagram on the SYS Settings tab.
63.3.2.2.2 Circuit diagrams

ET.PFA.PFA.01 Circuit diagram
Create via |NEW DOCUMENT, tab Report , template [...]
The wiring of the control cabinets with the cable supplies is done on this
report. The report works with the single line technique (SLINE).

63.3.2.2.3 Cable assignment (evaluated)

Evaluates the cables of the unit.
63.3.2.2.4 Tray overview (evaluated)

Evaluates the cables of the unit.
63.3.3 Using installation diagrams
Example project: Comos_ASP Installation engineering (EE)

Creating your own example: Create a new unit with the base object
ET |U Units |A Installation engineering |A Unit.
Categories have been prepared for this unit. When the unit created, the cate-
gories are automatically created below the unit. Objects placed on the instal-
lation diagram are automatically sorted into the categories.
Preparation
It is difficult to implement a functional example of an installation diagram
without a detail diagram. For that reason the above-mentioned example
project also uncludes a detail diagram.
Placing views
The ready-made reports do not have a view yet. If you were to work without
a view, then the DESIGN diagram type would be used instead of the
DESIGN_<suffix> diagram types.
Hence the first step must always be to place a view, normally the ground plan
from above.
Placing objects
Now you can either assign an existing DWG drawing or draw a ground plan.
Now place a cabinet and other objects in the ground plan.
Pay attention to the working height when placing the objects. If necessary, the
corresponding height level must be set beforehand: select the view object,
|VIEW/SLICE |SET WORKING HEIGHT mouse menu. It is a good idea to first draw
all the objects for a particular height before going on to the next layer.

Connecting objects
The connector tool works differently in the DESIGN diagram type as com-
pared to when in ELO.
The report template marks all the connections as “ready-only”. Thus, when
you draw a connection on the installation diagram, the corresponding plan-
ning objects must already have been connected beforehand (for example by
drawing a circuit diagram).
If that is the case, two objects on the installation diagram can be connected by
drawing a line with the connector tool. The moment that the line is completed
by means of the right mouse button, it is automatically converted into a tray:
• Either the default tray assigned to the document is created. That way a cable
tray with arcs and lines is created, for example.
• Alternatively, a tray can also be created in the Navigator and activated
before drawing the connection (overlaid with grey). Then the elements of
this tray are used to replace the connection.
When placing individual tray elements, make sure that the elements touch
correctly (an element is shown in bright yellow) so that the connectors join
the elements.
Assigning cables
The cables have already been created in the detail diagram.
Next, drag the existing cables into the ducts. Activate object assignment in the
symbol bar for this purpose and drag a cable onto a tray. A popup appears that
offers all the ducts under the tray, then select a duct from here and the cable
is assigned.
Monitoring
The installation diagram can be monitored with the aid of the Evaluation
Reports or in the Viper Electrical Engineering 3D display.

I&C sub-module P&ID defaults
64 I&C sub-module
I&C is offered in Comos PT together with the EE module as sub-module
“I&C, Electrical Engineering (E/I&C)”. EE and I&C thus have many struc-
tures in common. If in doubt, EE provides the guiding structure. Example:
there are purely I&C base objects sorted within the EE branch in the standard
database.
The I&C sub-module offers all the objects and functions required to design
measuring points and to provide signals, channels and devices. It offers mech-
anisms for automation when creating I&C loop diagrams and possesses all the
reports and queries that are needed to monitor or print out the work. Mounting
planning has also been taken into consideration.
64.1 P&ID defaults
64.1.1 Base data
The I&C planning is based on options that had been created in the P&ID plan-
ning. Some of the base objects that are relevant in the I&C planning are hence
managed within the scope of the preparation of P&ID base data (for example,
positions and functions). We therefore refer at this point to the following sec-
tion: see SECTION 57.1: BASE DATA, LISTS, TEMPLATES.
64.1.2 Unit planning
The unit structure has already been created in the P&ID planning. See
SECTION 57.1.2: UNIT STRUCTURE for more detailed information on unit planning.
In the standard database there are numerous management objects and reports
that correspond to EN/DIN and ANSI respectively and also for the AKZ unit
structure, so as to make your work easier.
I&C engineers primarily work in the EE/I&C Engineering folder, which is
created automatically underneath the sub-unit. See SECTION 64.2.1.1: FOLDER
“EE/I&C ENGINEERING” for more information regarding this folder.

Base data, lists, templates I&C sub-module
Unit according to EN/DIN:
64.1.3 Position and functions
As a rule, positions and functions have already been completed within the
P&ID planning. In the event that any positions and functions are missing after
completing the P&ID planning, they can also be created in the I&C planning.
Creating positions: see SECTION 57.3.2: CREATING POSITIONS.
Creating functions and designing them (via function code, process coupling
and process connector): see SECTION 57.7.5: WORKING WITH FUNCTIONS IN THE PLAN-
NING VIEW.
64.2.1 Devices from other branches
64.2.1.1 Folder “EE/I&C Engineering”

Base object:
EN/DIN: PI| EN| U| A| 01| 01| 01| 04 EE/I&C Engineering and
ANSI: PI| ANSI| U| A| 01| 01| 04 EE/I&C Engineering and
AKZ: @U| AKZ| AKZ05| AA| 00| 04 EE/I&C Engineering

I&C sub-module Base data, lists, templates
If the unit structures according to DIN or ANSI that had been preprepared in
the standard database are selected in the planning view, the folder is created
automatically under a sub-unit. In the case of a unit structure according to the
AKZ it is created underneath the sub-unit of the sixth level.
These unit structures are provided if @J | @G Project settings, general
had been selected in the project options; see SECTION 64.3.1: PROJECT PROPERTIES.
The actual I&C planning is done in the EE/I&C Engineering folder. For
example, here are the positions and functions, underneath which the signals
and channels are created.
The folder is created in the planning view during the P&ID planning. Under-
neath the folder there are numerous help and administration objects to sim-
plify the I&C work. However, they are not a prerequisite for carrying out the
required I&C work steps.
The following base objects that have all been entered on the Elements tab of
the EE/I&C folder have been preprepared underneath the folder:
Positions
– In the unit structure according to EN/DIN and AKZ:
P01 Positions acc. to DIN/IEC,
P02 Measurement
– In the unit structure according to ANSI:
P02 Positions acc. to ANSI
“DO Documents folder”

Base object:
Located directly under the EE/I&C folder.
In the documents folder a number of Evaluation Reports have been prepre-
pared that are created automatically together with the documents folder in the
planning view. The folder collects position-overlapping documents (hence
documents starting with the letter “P”):
– PDAB.1 PLT position overview
– PDAC.1 PLT Position - function overview
– PDAD.1 Armature overview
– PFPA.1 Signal list and PFPA.2 Signal list (Hardware)
– PFPB List of references
– PQBA.1 PQBA List of security relevant E&IC installations

See SECTION 64.5.1.2: REMAINING I&C EVALUATION REPORTS for more information
regarding these Evaluation Reports.
– PPCB Hookup with positions
– PPCC Parts list evaluation (Mounting accessories)
– PPCE Counting Devices
See SECTION 64.8: MOUNTING CATALOG for more information regarding these
reports.
See SECTION 64.5.1: EVALUATION REPORTS for more information regarding addi-
tional I&C reports.
“Search objects”
Base object:
ET| 3| 01| 10 Search objects.
This is created automatically together with the EE/I&C folder. See

“ET| 3| 01| 10 Search objects”, P. 64-19 for more information on search objects.
“QDev1 Device with location reference”

Base object:
ET| Q| OA2| QDev003 Devices with location reference.
Can be created by means of the | NEW mouse menu of the EE/I&C folder. See
SECTION64.2.2.9: “ET|Q QUERIES, TABLES, SCRIPTS”.
Not offered in AKZ.
“QDev2 Assignment I&C Position”

Base object:
ET| Q| OA2| QDev005 Assignment I&C position
Can be created by means of the | NEW mouse menu of the EE/I&C folder. Is
only used in conjunction with the S7 interface.
Only set up in the unit structure according to EN/DIN.
“PDAE.1 Function and signal list”

Can be created by means of the | NEW mouse menu of the EE/I&C folder. (See
SECTION 64.5.1.2.4: “PDAE.1 FUNCTION AND SIGNAL LIST”)
Only set up in the unit structure according to EN/DIN.

64.2.1.2 “@Position”
64.2.1.2.1 General
As a rule, positions have already been created beforehand in the P&ID plan-
ning. See SECTION 57.1.3: @P POSITIONS regarding the structure of this branch in
the base data and regarding the properties of positions.
The following objects that are relevant for the I&C planning have been
preprepared in the base data underneath this node:
“@P Positions”
– Measuring functions, actuating functions, neutral functions (and general
functions according to ANSI):
This is only still created in the I&C planning in exceptional cases. See
SECTION 64.2.1.3: “@F FUNCTIONS”.
– ...| PDAF.1 PDAF Position sheet:

The report has by default creation mode Copy . When a position is created
in the planning view, the position sheet is thus created automatically
underneath the position. (Only one position sheet per position.) It describes
the request attribute of a position and thus helps in preparing for ordering.
See SECTION 64.5.1.1: CONFIGURABLE I&C REPORTS for more information
regarding loop diagrams.
– ...| PFFA Functional diagram:
This is only required for FD. Only one per position.
“@P| 01 Measurement”
– ...| PFSM.2 Position diagram
“@P| 03 Functions ANSI”

– ...| PFSM.1 Position diagram ANSI
“@P| 02 Positions according to DIN/IEC”

– ...| PFA.04 Position diagram, single line:
Only one diagram per position. See SECTION 64.5.2.1.3: “PFA.04 POSITION
DIAGRAM, SINGLE LINE”.
– ...| PFSM.2 Position diagram:

Sets up the loops of a position. Only one diagram per position. See
SECTION 64.5.2.1.1: “PFSM.2 POSITION DIAGRAM”.

– ...| PQAC.1 Loop, Check protocol:

Only one report per position. See SECTION 64.5.1.2.5: “PQAC.1 LOOP, CHECK
PROTOCOL”.
– ...| Search objects:

The search objects that are created here find channels that had been created
underneath the position but which have not yet been placed on single-line or
normal loop diagrams. They inherit from objects underneath ET| 3| 01|
10 Search objects | 02 Unplaced channels. See “ET| 3| 01| 10 Search
objects”, P. 64-19.
– ...| 04 Assembly groups (functions with signals):

This object is on the border between P&ID planning and I&C planning.
Normally the measuring function has already been created by the P&ID
planners and then the signal by the I&C planners.
However, if an entry is selected from | 04 ASSEMBLY GROUPS, the measuring
function is created with a signal. The object thus gives I&C planners the
option to quickly create object structures if they were missing.
The assembly groups that are created here inherit from the following object:
ET| 3| 01| 02 Assembly groups (functions with signals).
The assembly groups for signals can be expanded by the base data
administrator and adapted to your own needs. See SECTION 64.7.1.2.2: WORKING
WITH ASSEMBLY GROUPS: “ASSEMBLY GROUPS (SIGNALS WITH CHANNELS)” regarding
the functioning of the assembly groups preprepared in the standard
database.
– ...| 05 FD Assembly groups (functions with signals and FD
modules):
This is only needed in FD and inherits from: FD| D| 01| @Template| AB
FD Assembly groups.
– ...| 05 Assembly groups motor controls (only under the Electrical

Value position): see “ET| 3| 01| 03 Assembly groups (motor control)”, P. 64-19.
If the unit structure had been selected correspondingly in the project proper-
ties, these objects can be created in the planning view by means of the | NEW
mouse menu of the position.
64.2.1.2.2 Tabs / attributes

A position possesses three tabs in the standard database. The attributes of
these tabs are almost entirely only for information and do not initiate any auto-
mation functions. They are statically linked with the corresponding attributes
of the sub-unit.

The details at the tabs are required later for selection of the signal.
When a position is created, all the static links are automatically updated by
Comos PT. If changes are subsequently made to the attribute values, the
updating must be done again manually by selecting from the context-sensitive
mouse menu | UPDATE STATIC LINKS OF THE TAB.
See also “EX020 Ex-Protection” tab, P. 64-9 and “IC010 Request and security” and
“IC020 Environmental conditions” tabs, P. 64-9 of the functions.
“Ex-Protection” tab
In the standard database, the tab originally comes from the following collec-
tion of tabs:
ET | Y Attribute catalog| 5 I&C tabs| EX020 Ex-protection
| 02 Unit| EX020 Ex-protection.

catalog | 0 Attributes collection | 06 Clima-/ Security-/ Pro-
tection data.
“E/I&C options” tab

tion of tabs:
@F Functions| Y Attributes collection| 1 Tabs collection
| IC101 unit (U)| IC030 E/I&C options.
The attributes of the tab originally come from branch

@F Functions| Y Attributes catalog| 0 Attributes collection
| 03 Options/representation.
“Environmental conditions” tab

tion of tabs:
@F Functions| Y Attributes collections| 1 Tabs collection
| IC101 Unit (U) | IC020 Environmental conditions
The attributes of the tab originally come from the following branches:
• ET | Y Attributes catalog| 0 Attributes collection| 06 Clima-
/ Security-/ Protection data| ICE101 Zone/Category
• F | Y Attributes catalog| 1 Tabs collection| IC010 Unit (U).

64.2.1.3 “@F Functions”
64.2.1.3.1 General
As a rule, functions had already been created in the P&ID planning and placed
on the diagrams. This section only contains the information regarding func-
tions that is relevant for pure I&C planning. Please read SECTION 57.4: FUNCTIONS
concerning the general properties of functions.
If the project structures are incomplete at the beginning of the I&C planning,
they can easily be supplemented or updated by means of the | NEW mouse
menu. Depending on which unit structure had been selected in the project
properties, other objects are suggested here. See also SECTION 57.7.5: WORKING
WITH FUNCTIONS IN THE PLANNING VIEW regarding the creation of functions.
A number of different Evaluation and Interactive Reports are provided in the

standard database from the second @F level onwards. These reports are cov-
ered in SECTION 64.5: I&C REPORTS.
In addition, a number of structures that allow, for example, access to assembly
groups and measuring devices are provided in the standard database from the
@F| A<number>| 01 Measuring function and ...| 02 Actuating
function level onwards under the functions. (They are available in the plan-
ning view via the | NEW mouse menu.) Most of these structures possess inher-
itance sources from branch @F| Z Structures (Create new/assembly
groups) or @F| SE Structure elements for functions.
64.2.1.3.2 Display of functions

See SECTION 57.4.8: DISPLAY ON THE DIAGRAM.
64.2.1.3.3 Tab / attributes
“SYS System information” tab

tion of tabs:
@F Functions| Y Attributes collection | 1 Tabs collection
| SYS System information | 08 Functions | SYS System informa-
tion.
The attributes of the tab originally come from branch ET| Y Attributes
catalog | 0 Attributes collection | 01 System.
The tab contains two groups of attributes:

• Function settings - PI : These attributes belong to the base data

administration of the P&ID planning. See SECTION 57.4.3.1: “SYS SYSTEM
INFORMATION” TAB.
• System settings - IC : are introduced in the following.

– AREANAME Page area :
This is evaluated during Automatic Placing. See SECTION 64.6.2: AUTOMATIC
PLACING and SECTION 64.6.4.1: OVERALL CONDITIONS IN THE BASE OBJECTS:
“AREANAME”.
– ProdReqShow Data display from :

This is evaluated during selection of the product data. See SECTION 61.3.3:
CONTROLLING THE DISPLAY OF PRODUCT-RELATED ATTRIBUTES.
– MultipleUse Permit multi-placement :

A planning object is allowed to be placed multiple times on a diagram.
– NSYS System standard :
Toggles the units systems between DIN metric and
ANSI/ASME Imperial . The result: the units systems are changed and the
values are converted on the other tabs.
The attribute is stored with base data table PI| Y| 0| 0| 3D| NSYS.
“EX020 Ex-Protection” tab

tion of tabs:
ET | Y Attributes catalog| 5 I&C tabs| EX020 Ex-
Protection| 02 Units| EX020 Ex-Protection.

catalog| 0 Attributes collection| 06 Clima-/ Security-/ Pro-
tection data.
“IC010 Request and security” and “IC020 Environmental conditions” tabs

The tabs originally come from the node:
@F Functions| Y Attributes collection| 1 Tabs collection
| IC101 Unit (U)
The attributes of the tab originally come from the following branches:
• ET | Y Attributes catalog| 0 Attributes collection| 06 Clima-
/ Security-/ Protection data| ICE101 Zone/Category
• @F | Y Attributes catalog | 0 Attributes collection| 04

Function data.

The Ex020 Ex-Protection and IC020 Environmental conditions tabs are

created in the sub-unit and are inherited downwards (via static links). Thus
this property can also be modified again at each object. See “Ex-Protection” tab,
P. 64-7 and “Environmental conditions” tab, P. 64-7 for more information on the
attributes of these tabs.
The IC010 Request and Security tab is added at the level of the function
and is inherited downwards from there.
64.2.1.3.4 “@F| SE Structure elements for functions”

See the P&ID section, SECTION 57.4.2.4: “@F| SE STRUCTURE ELEMENTS FOR
FUNCTIONS”.
64.2.1.3.5 “@F| Y Attributes catalog”

See the P&ID section, SECTION 57.4.2.5: “@F| Y ATTRIBUTES CATALOG”.
64.2.1.3.6 “@F| Z Structures (Create new/assembly groups)”

Many of the structures created under the levels @F| A<number>| 01 Measu-
rement function and ...| 02 Actuating function inherit from structures
from this branch. These objects are then offered in the planning view through
the | NEW mouse menu of the functions.
Most of the objects that are created in @F| Z inherit in turn from other
branches, and as a rule from the ET branch.
“...| A1 Favorite assembly groups (signals with channels)”

There is a structure A1 Favorite assembly groups (signals with chan-
nels) under some of the measurement functions according to EN/DIN that
possess a function code. Depending on the function code, different assembly
groups are offered underneath that structure. The assembly groups are always
specially matched to the function code. All these assembly groups inherit
from the assembly groups that were created under @F| Z| A1 Favorite
assembly groups (...). These inherit in turn from the assembly groups from
branch ET|3|01| 01 Assembly groups (signals with channels).
How to work with these assembly groups is described in 64.7.1.2.2:
SECTION
WORKING WITH ASSEMBLY GROUPS: “ASSEMBLY GROUPS (SIGNALS WITH CHANNELS)”.
The assembly groups for signals can be extended by the base data administra-
tor and modified to suit your own needs. Example: inserting assembly groups
for measurement functions with other function codes.
“...| A2 Assembly groups (signals with channels)”

Assembly groups that serve as the inheritance source for the Assembly
groups (signals with channels) that had been created in branches @F| A1
Functions acc. to EN/DIN and @F| A2 Functions acc. to ANSI have
been preprepared here for a number of functions with function codes. The
assembly groups underneath @F| Z| A2 inherit in turn from base objects
from branch ET| 3| 01| 01 Assembly groups (signals with chan-
nels).
See SECTION 64.7.1.2.2: WORKING WITH ASSEMBLY GROUPS: “ASSEMBLY GROUPS (SIGNALS
WITH CHANNELS)” for more detailed information on how these assembly groups
function.
“...| D1 Favorite measuring instruments”

This offers measuring devices for measurement functions according to EN
and ANSI, separated by function code.
The measuring devices inherit from objects from branch ET | D Devices |B
Transmitters, sensors| A B Sensors| IC B Structures at elements
(channel).
See SECTION 64.2.2.5.1: “ET |D DEVICES |B TRANSMITTORS, SENSORS|A B SENSORS |IC B

STRUCTURED AT ELEMENTS (CHANNEL)“.
“...| D2 Measuring instrument”

Under this node there are structures that offer measuring devices for measure-
ment functions according to EN and ANSI, separated by function code. The
structures inherit from the structures created under ...| D1.
Differing from ...|D1 in the planning view: If you select the | NEW command
from the mouse menu for the selected function, ...| D2 offers the measuring
devices for all the function codes, while on the other hand ...| D1 offers the
measuring devices only for the function code of the selected function.
“...| Z Mounting”
These objects inherit from objects from the mounting catalog: ET| B | B
Mounting catalog. A number of measurement functions according to EN
and ANSI and actuating functions according to EN and ANSI possess ele-
ments that inherit from the objects that are created here. In this way it is pos-
sible to create mounting objects for mounting planning within the planning
view by means of the context-sensitive mouse menu. See SECTION 64.8: MOUN-
TING CATALOG.

64.2.1.4 @G Document groups

The objects under this node help you to get an overview in the administration
of the documents that are created in the course of working on the project. Doc-
ument groups are used to this end.
Document groups have been already prepared in the base project on the
Documents tab, and these follow a specific naming scheme. Document
groups that follow this naming scheme must also be created in the planning
project on the Documents tab. See “@G| S| P Structure for process engineering”, P.
64-12. Documents from the unit view and the location view that comply with
this naming scheme are then referenced automatically under the appropriate
document group on the Documents tab.
64.2.1.4.1 “@G| S Structures acc. to IEC 61355“
“@G| S| P Structure for process engineering”

If base object @J| @G Project settings, general was selected as the
project setting (see SECTION 64.3.1: PROJECT PROPERTIES), a document group can
then be created in the planning project:
Tab Documents, | NEW mouse menu of the project root.
Base object of the document group that is created:
@J| @G| @NameSystem Structure for process engineering.
The base object inherits from object @G| S| P Structure for process
engineering and has the object properties Folder .
Elements from “@G| S| P Structure for process engineering”

Underneath this document groups folder there are sub-folders, the so-called
hierarchy groups, which are input as elements of the folder. Your base object
is @G| Z Structure elements| A Hierarchy group.
The hierarchy group elements in turn have document groups that are input as
elements. The base object of the document groups is @G| Z Structure
elements| B Document group.
The inheritance mode of the elements is set to Active , and the Virtual option
is set to Off . As a result, the hierarchy and document groups are automatically
created when the document groups folder is created on the Documents tab of
the planning project.
The following sub-folders and document groups are primarily of importance
for I&C work:
• @G| S| P| PD| PDA Data sheet:

• @G| S| P| PF Function descriptions:

– PFA Survey-, block diagram
Contains the single-line displays of loop diagrams.
– PFF Function diagram
Self-explanatory.
– PFP Signal list
Self-explanatory.
– PFS Circuit diagram
Contains the PFSM sub-folder for loop diagrams. Sub-folder
PFSS Circuit diagrams can also be of interest, since the detail
planning for I&C is often done in circuit diagrams.
• @G| S| P| PP| PPC Parts list:
– PPCA HookUp
– PPCB HookUp with positions
– PPCC Parts list evaluation
• @G| S| P| PQ Quality Management, security:
– | PQA| PQAC Loop, Check protocol
– | PQB| PQBA Security relevant I&C installations
See SECTION 64.5: I&C REPORTS for more information on the reports that are ref-
erenced under this folder.
64.2.1.4.2 “@G| Z Structure elements“

Here are the base objects of the hierarchy groups and document groups.
64.2.2 Devices of branch “ET I&C, Electrical engineering“
The ET I&C, Electrical Engineering branch contains devices and

administration objects that are required both in EE and in I&C:

This section only covers the objects from the ET branch that are important for
I&C. All the devices that are described here possess specific properties that
are explained further in the following section, SECTION 64.2.2.1: BASIC STRUC-
TURES.
In addition to these there are also objects that have additional properties and
capabilities. These special objects are explained in detail in the following sec-
tions.
64.2.2.1 Basic structures
64.2.2.1.1 First level

Directly underneath “ET I&C, Electrical engineering” there are
branches 0 to 3 and branches A to Z:
The numbers from 0 to 3 have no meaning and are only used for sorting.
The letters A to Z are allocated according to the Comos “CDeviceConstants”
class constants:
A = Accessory
B = Assembly = mounting, etc.
See the “Comos Kernel ” documentation regarding CDeviceConstants.
64.2.2.1.2 DIN labels for “ET | D VDevices”

The devices are sorted according to standard DIN 40719 and are given the
corresponding initial letters:
ET I&C, Electrical engineering
-|D Devices
-| A A Assemblies, subassemblies
-| B B Transmittors, sensors
-| A B Sensors
-| B B Measuring transmitters

-| C C Condensors
-| D D Logical elements
-| E E Various
etc.
These DIN letters are also created for the planning objects. There is a text
mask on the System tab of the base object for this purpose. Here is an exam-
ple for a sensor:
Together with a counter, the letter “B” is thus used in accordance with DIN to
create the name of the planning object.
64.2.2.1.3 Symbol
All simple devices possess one or more symbols on the Symbols tab. The
main type of diagram for I&C is DETAIL_IC::
These symbols can be modified as required. Please note that the symbols are
hierarchically inherited downwards.

The diagram type symbols initially possess a fixed size and are optimized for
a grid and a scale. However, the symbols can also be used on reports with a
different grid and a different scale by using various options.
Each symbol possesses a placement point that is used for positioning on the
grid. The placement point only seldom coincides with the top left-hand cor-
ner, but instead has been created in such a way that the connectors come to lie
on the grid.
All the diagram types that are important for I&C:
DETAIL_IC
This type of diagram is only used by I&C, and primarily with loops.
RI2
I&C requires as input the functions placed in the P&ID reports.
DETAIL_JIC
US standard for E/I&C reports.
SLINE
Single line display in E/I&C reports. Resembles block diagrams.
DETAIL
The actual wiring is shown as a rule in the EE reports, hence in the DETAIL
type of diagram.
However, Interactive Reports do not play as important a role in the I&C sub-
module as in the other modules. Instead, the main emphasis is on the Evalua-
tion Reports.
Text symbol
Many objects possess a “text symbol“.
This text symbol is inherited by all base objects underneath the base object
that first defines the symbol. However, the text symbol is not evaluated by all
base objects. It is only evaluated by base objects that call the text symbol as
follows:

*V*P Textpoint*
See also SECTION 45.4.2.1: TEXT SYMBOL regarding text symbols.

The I&C text symbol outputs as a rule the following information:
• Attribute M001 Part number from the HSD tab
• Attribute M003 Manufacturer from the HSD tab
• Attribute MB03 Measuring range from the TD tab
• Name of the planning object
If you look at the script of the text symbol, you will find a header with dummy
details:
Header.Layer = "29"
Layer “29” is an arbitrary number that is only used to bundle certain items of
information. Any other layer could also be input. Depending on the individual
data structure, it is necessary to ensure that you do not inadvertently use here
a layer that has been used elsewhere.
Header “eS3” is an arbitrary designation that is only used to bundle certain
items of information. Any other header could also be input. Please note that
some headers are reserved for system use. Thus, for example, Header.Class
= "eZ" means that the text cannot be moved.

All I&C objects possess connectors. Auxiliary connectors are possible, but
are hardly ever used in practice.
In the I&C sector connectors are also used to transport signals and data. See
SECTION 64.7.1.4: CONNECTOR: SIGNAL OF OWNER.
Creating connectors for functions works in a different way to the procedure

for the other I&C objects. See SECTION 57.4.6: CONNECTORS.
Compare also SECTION 57.1.1.1.3: CONNECTORS AND AUXILIARY CONNECTORS.
64.2.2.1.5 Attributes and calculated attributes

Each device is provided with its own very special attributes on the Specifica-
tion tab. The attributes are inherited further hierarchically and are supple-
mented or modified by additional ones as required at each stage.
Centrally usable attributes are also managed centrally. There is the “Y cata-
log” for this purpose. The following branches in Y are important for I&C:

ET | Y Attributes catalog | 5 I&C tabs
ET | Y Attributes catalog | E Elements
The catalog attributes are only called up at the I&C devices:
64.2.2.1.6 Elements
You work with elements in I&C. Initially only the elements are placed on the
reports.
64.2.2.2 “ET | 3 Structures IC”

This branch contains the structures that are used in the I&C planning.
64.2.2.2.1 “ET| 3| 01 Units”

As a rule, the assembly groups and objects that are created here are entered on
the Elements tab of a base object elsewhere in the base data. In the planning
view they are available in the unit structure via the | NEW mouse menu.
The following applies for the assembly groups:
• The base object of an assembly group possesses a reference to a template
that is located on the Units tab of the base project, under the node Assembly
groups (copy templates)| IC Measuring and control engineering.
• The assembly groups and templates can be modified as required by the

administrator or extended to include new assembly groups.
“ET| 3| 01| 01 Assembly groups (signals with channels)”

Signals can be created automatically together with channels and measuring
devices and connected with one another through the assembly groups created
beneath this branch.
See SECTION 64.7.1.2.2: WORKING WITH ASSEMBLY GROUPS: “ASSEMBLY GROUPS (SIGNALS
WITH CHANNELS)” and SECTION 64.7.1.3.1: ASSEMBLY GROUPS FOR ACTUATING FUNCTIONS
for more detailed information on the mode of functioning of these assembly
groups.

“ET| 3| 01| 02 Assembly groups (functions with signals)”

This sub-menu is exactly on the borderline of the P&ID planning and the I&C
planning. Normally, the measurement functions are still created by the P&ID
planners and then the signals by the I&C planners.
However, if an entry is selected from | 04 ASSEMBLY GROUPS, the measurement
function is created together with a signal. Thus this menu enables I&C plan-
ners to quickly create object structures that had been missing.
“ET| 3| 01| 03 Assembly groups (motor control)”

The base objects that are created under this node possess references to assem-
bly groups from the base project (nodes: IC Measuring and control
engineering| C Assembly groups motor controls).
In addition, they are an inheritance source for the assembly groups for motor
control offered under position @P| 01| E Electrical value.
See also SECTION 64.2.2.2.4: “ET| 3| 99 MCC DRIVERS”.
“ET| 3| 01| 09 Position diagrams”

Two Interactive Reports have been preprepared here. One report is based on
report template PFA.04 Position diagram, single line and possesses dia-
gram type SLINE , the other is based on report template PFSM.2 Position
diagram and possesses diagram type DETAIL_IC .
The base objects for these diagrams are located in the standard database under
ET| O Documents. See SECTION 64.5.2.1: LOOP DIAGRAMS.
“ET| 3| 01| 10 Search objects”

The search objects possess the following structure:
ET| 3| 01| 10 Search object
...–| 01 Unimplemented channels, elements
......–| 01 DCS channels
.........–|...
......–| 02 Ex-protection channels
.........–|...
......–| 03 Sensor channels
......–| 04 Actuator channels
...–| 02 Unplaced channels
......–| 01 Unplaced channels (single line diagram)
......–| 02 Unplaced channels (position diagram)
...–| Z Structure: Elements, channels
.....–| 01 Structure elements

Search objects display the result of a query directly in the Navigator but are
not queries in themselves. When the search object is expanded, the query is
executed automatically and the results are displayed in the Navigator in the
form of the usual tree structure.
Some of the search objects created here are created automatically underneath
the EE/I&C Engineering folder:
The search objects are used, for example, to move control devices from the
unit view into the location view. This is done in interaction with query
ET| L| C| 1| 06| QDev001 Request implementation (by using the
implementation capabilities). See SECTION 64.7.2.3.6: IMPLEMENTATION.
Other search objects are created under positions and find any channels that
have not been placed on the loop diagrams yet.
See SECTION 64.2.1.1: FOLDER “EE/I&C ENGINEERING” regarding the EE/I&C Engi-
neering folder.
64.2.2.2.2 “ET| 3| 02 Signals”

Here there are device channels:

They are entered as elements of signals that are created underneath ET| S
Signals. They are thus offered in the Navigator through the | NEW mouse
menu of the signals.
The device channels that are created here possess base object references to
| ET | E Elements. See also SECTION 64.2.2.6: “ET |E ELEMENTS” and
SECTION 64.2.2.10: ET |S SIGNALS.
64.2.2.2.3 “ET| 3| 04 Document design”

01 Sheet area with description :
A base object of class Element , sub-class Segment .
Function: Segmentation of loop diagrams. See SECTION 64.6.4.3: SEGMENTATION
OF THE DIAGRAM.
64.2.2.2.4 “ET| 3| 99 MCC drivers”

The base objects that are created here are used in the base project in the
IC| C| 02 MCC drivers assembly group.
See also “ET| 3| 01| 03 Assembly groups (motor control)”, P. 64-19.
64.2.2.3 “ET| B Mounting”

See SECTION 64.8: MOUNTING CATALOG.
64.2.2.4 “ET| C Expense”

64.2.2.5 “ET | D Devices”
64.2.2.5.1 “ET |D Devices |B Transmittors, sensors|A B Sensors |IC B Struc-

tured at elements (channel)“
Here are the measuring devices for measurement functions according to EN
and ANSI, sorted by function code. The devices already possess channels.
64.2.2.5.2 “ET |DDevices |U U Transducers”

I&C signal converters such as measuring transmitter supply units and isolat-
ing amplifiers

64.2.2.6 “ET |E Elements”

Here are all the base objects for channels and elements:
As far as possible, the names of the elements (A,B, etc.) correspond to the
names in branch | D Catalog, where they are used as well.
The device channels only possess a System tab that describes the system and
object settings.
Definition of channels:
A defined input or output of a device, consisting of one or more connectors,
which all fulfill a task that is common to them all. In this sense the power con-
nection of a device is a channel (consisting of plus and minus) and the signal
connector is an additional channel.
A channel request connects a signal and a device. See SECTION 64.7.1.2.2: WOR-
“ASSEMBLY GROUPS (SIGNALS WITH CHANNELS)”.
KING WITH ASSEMBLY GROUPS:
In Comos channels are often created as an element, from a technical point of

view, and are then named as such in the mouse menu. Sometimes channels
also have a function description, such as “Input (analog) ”. However, often
the channels also have the designation “channel” in the mouse menu.
64.2.2.7 “ET |L Locations”

ET| L Locations| C Instrumentation & Control
This node manages the base objects of the location objects that are created on
the Locations tab in the location planning.

Structure of the node:
“ET| L| C| O Objects”
Here are the base objects. The objects under ET| L| C| 1 Structures
DIN/EC possess a base object reference to the objects that have been created
here.
“ET| L| C| 1 Structures DIN/IEC”

Structures are set up here that are then made available through the project set-
tings. The result is that they are offered to the user in the planning view from
the | NEW mouse menu.
Example:
@J| @G Project settings, general:
possesses elements that determine the subsequent location structure:
@J| @G Project settings, general
...| 102 Building
...| 01 Floor
...| R Room
...| 02 Field location
...| 02 Field location ANSI
The elements possess a base object reference to the objects created under
ET| L| C| 1 Structures DIN/EC.

The objects of the lowest location level possess among other things assembly
groups as elements. The assembly groups have a base object reference to the
assembly groups that preprepared under ET| L| C| 3 Copy templates.
“ET| L| C| 2 Structures JIC/ANSI”

The structures that are created here are available from ET| @J | @A Project
settings ANS.
“ET| L| C| 3 Templates”
The base objects preprepared here make available I&C assembly groups (via
assembly group references). The assembly groups are managed within the
base project, Locations tab: Assembly groups (copy templates| IC
Measuring and control engineering.
Examples for assembly groups:

– Base object for field distributor assembly groups (ET| L| C| 3| 04
Field distributor| 01 DIN/IEC| 03 Assembly groups):
Create a terminal strip with terminals and cable, together with a folder for
the marshalling process (field side) with terminal strip.
– Base object for assembly groups that are preprepared in the DCS rack,
(ET| L| C| 3| 01 DCS (control) | 01 Assembly groups DCS| 03
Assembly groups area overlapping):
For example, create inputs, a MC bay (control) folder with terminal strip
and a Ex-Protection folder with measuring transmitter supply units.
The points to be noted when working with the assembly groups is described
in the sub-sections regarding controllers (SECTION 64.7.2.3.5: ASSEMBLY GROUPS)
and the field distributor(SECTION 64.7.2.6.2: CREATING THE FIELD DISTRIBUTOR).
64.2.2.8 “ET |O Documents”

Each report has a report template and a base object. The base objects of the
I&C reports are located in this branch. The types of I&C reports (and their
respective base objects) are described in SECTION 64.5: I&C REPORTS.
64.2.2.9 “ET|Q Queries, Tables, Scripts”

Useful queries especially for EE and I&C have been created in this branch.
These include in particular:

“QDev002 Request implementation”

Base object: ET| Q| OA2| QDev002 Request implementation.
This query is used to implement channel requests that had initially been cre-
ated in the unit view with channels in the location view. The query is created
automatically in the location view underneath the DCS rack for this purpose.
In the unit view the search objects internally work with an instance of this
query. Compare SECTION 64.7.2.3.6: IMPLEMENTATION.
“ QDev003 Devices with location”

Base object: ET| Q| OA2| QDev003 Devices with location.
In the planning view this query is offered through the | NEW mouse menu of
the EE/I&C Engineering folder.
The query is used to prepare the field distribution: it finds all devices that are
located underneath the EE/I&C folder, shows whether they possess a location
pointer, and if so, which. Missing location pointers can be added later by
means of the query by using drag & drop or else existing pointers can be mod-
ified. (See SECTION 64.7.2.6.1: LINKING THE UNIT AND LOCATION VIEWS THROUGH POIN-
TERS.)
64.2.2.10ET |S Signals
Information on how to work with signals in the planning view is given in
SECTION 64.7.1: WORKING WITH SIGNALS.
64.2.2.10.1Base data structure

ET| S| @IEC Signals by IEC 1175:
Here are created signals that are taken from IEC 1175. The node contains both
the signals and also references to the associated device channels. They are
input as an element of the signals and are offered in the planning view in the
mouse menu of the signals. See SECTION 64.2.2.2.2: “ET| 3| 02 SIGNALS”.
ET| S| @ST Signal types:
The signals that have been preprepared here are used in KKS.
ET| S| A Action block:
This is created as an element of ET| S Signals. This is required for FD.

64.2.2.10.2Tabs / attributes
“IC310 Signal data” tab

Is to be filled out based on your technical knowledge. The attributes have no
further effects.
“SYS System data” tab

You can ignore this tab. It is only required for FD
“OPC OPC” tab

See SECTION 64.2.2.10.4: INCORPORATE PROCESS VISUALIZATION (WINCC, PVSS II).
64.2.2.10.3Scripts
The following scripts have been preprepared on the Script tab of the base
object of a signal:
OnMenuCreate / OnMenuExecute
The mouse menu of the signal is extended with these events. If the signal has
been set within a set of steps by an action block, then all the steps with which
the signal is connected are listed within the context-sensitive menu. If a step
is selected, the system navigates to the corresponding action block.
64.2.2.10.4Incorporate process visualization (WinCC, PVSS II)

Comos has an OPC Client that can address any OPC Server. The Client que-
ries the current values of signals from the Server, whcih are then stored on the
OPC tab of the signal. OPC Servers are primarily used in process visualiza-
tion. Examples of software with OPC Server:
• Siemens: WinCC
• ETM: PVSS II
64.2.2.11ET |U Units
ET|U|C Instrumentation & Control| @Template:
This node contains the base objects of the planning objects underneath which
the I&C assembly groups are created in the base project.
Structure of the branch:
ET| U| C| @Template| F Function
ET| U| C| @Template|P Position

I&C sub-module Settings and definitions
ET| U| C| @Template|S Signal
64.2.2.12ET |Y Attributes catalog

Among other things, the Specification tabs and the attributes of the functions
are collected in this node. However, some of the tabs and attributes of func-
tions are also created in the ET and PI branches.
Furthermore, the E/I&C options specification tab and its attributes, which
turn up in units and positions, originally come from this branch.
Further details are given on the relevant tabs.
A number of the subreports for the configurable I&C reports are located here
as well (see SECTION 64.5.1.1: CONFIGURABLE I&C REPORTS).
64.3 Settings and definitions
64.3.1 Project properties
The following must have been set in the properties of a project:

• Links tab, Project structure field:
@J| @G Project settings, general
Please note: When a new project is created, then as a rule the Project
structure field is set to @J and not to @J| @G Project settings,
general . Modify the project settings accordingly when creating a new
project. Among other things, the unit structures that are available for the
project are determined by base object @J| @G Project settings, general .
• Options tab, Signal tracking option
Ignore bridge connection activated.
Bridges mean the bridges on terminal strips. In later Comos versions the
function to enable signals to be transported over the bridges of the terminal
strips is made available. Currently this function has not been activated yet
and for that reason bridges still have to be ignored.
• Module options tab, Detail sub-tab
Option “Implement request” replaces objects
On: The original request objects disappear during the implementation; only
the new objects that have just been implemented are retained.
Off (recommended for beginners): The request objects are retained. Each
request object has its implementation object assigned to it by means of a link

Settings and definitions I&C sub-module
and you can navigate between the two objects. This means that there are
objects left over that have no additional function in the course of the
planning, but the actual work is easier to follow and to track later.
64.3.2.1 AREANAME
The Areaname determines where objects are to be placed in loop diagrams
when the “Automatic Placing” auto-function is used.
To this end I&C objects on the SYS System tab possess the AREANAME
page area attribute, which is assigned to this standard table.
See SECTION 64.6.4.1: OVERALL CONDITIONS IN THE BASE OBJECTS: “AREANAME”.
64.3.2.2 “ET|Y|O|S001|S001 Document types“

I&C uses “configurable reports”. This involves Evaluation Reports in which
the user can determine by himself which information is to be evaluated. Def-
inition and usage of “configurable reports” are described in SECTION 64.5.1.1:
CONFIGURABLE I&C REPORTS.
Basically, the user simply selects a series of subreports that are to be evalu-
ated. These subreports must have the same names as other objects; any typing
errors will result in the subreport not being run. The list attribute is filled in
by means of this standard table to avoid typing errors and to simplify use:
Subreports of configurable reports, S001 Realization tab
List attribute LI_001| S001_001 Description .
It is assigned to this standard table.

I&C sub-module Standard-Loop
64.4 Standard-Loop
Loop, diagrams and assembly groups for signals with channels presuppose
the following standard loop:
To ensure that they are linked together correctly (signal pointer, connectors),
the objects of an assembly group must, for technical reasons, be created in the
planning view in the same branch.
The result is that objects that are in fact used on the Locations tab are initially
created on the Units tab.
Later the objects are moved from the unit view to the location view. For this
purpose Comos uses the Detail tool “Request and implementation” and the
location pointer. More information on this is given in SECTION 64.7.2.3.6: IMPLE-
MENTATION.
See also the following regarding assembly groups:

• “ET| 3| 01| 01 Assembly groups (signals with channels)”, P. 64-18.
• SECTION 64.7.1.2.2: WORKING WITH ASSEMBLY GROUPS: “ASSEMBLY GROUPS (SIGNALS
WITH CHANNELS)”
See SECTION 64.6: AUTO FUNCTIONS OF LOOP DIAGRAMS regarding loop diagrams.

I&C reports I&C sub-module
64.5 I&C reports
64.5.1 Evaluation Reports
Evaluation Reports are offered in the planning view at various places by

means of the | NEW mouse menu: under functions, positions, the documents
folder, the EE/I&C folder, the sub-unit and the factory. You can find an over-
view of which Evaluation Reports are offered and where in the relevant sec-
tions on these objects.
64.5.1.1 Configurable I&C reports
64.5.1.1.1 List of configurable reports

A number of ready-made configurable I&C reports are provided in the stan-
dard database.
“PDAF.1 Position sheet”

• In the base data view: located under @P Positions.
• In the planning view: created automatically together with the position (since
the creation mode of the report is set to Copy in the standard database).
• Base object:
ET| O| PDA| PDAF Position sheet
• Report template:
CRp| IC| PDA| PDAF| PDAF.1 Position sheet
The PLT position sheet shows selected tabs: it describes the request attributes
of an position and is used to prepare for ordering.
“PDAA.1 Product request”

• In the base data view: Under ET | D Devices |B Transmitters,
sensors| A B Sensors | IC B Structures at elements (channel),
and ET| D Devices| U U Transducers| A U Signal converters| IC
U Separated in elements (Channels.
• In the planning view: through the | NEW mouse menu of a device request
from these branches.
• Base object:
ET| O| PDA| PDAA Request specification

I&C sub-module I&C reports
CRp| IC| PDA| PDAA| PDAA.1 Product request Device
This report lists the attributes that are required to design the device requests.
The report functions in the same way as the report Product request
Function .
“PDAA.2 Product request Function”

• In the base data view: under @F| 01 Functions acc. to DIN/EN and
@F| 03 Functions acc. to KKS.
• In the planning view: offered from the | NEW mouse menu of the function
according to EN or KKS respectively.
• Base object:
CRp| IC| PDA| PDAA| PDAA.2 Product request Function.
This report lists the attributes that are required to design the signal and the
device requests.
The function partially inherits attributes from the sub-unit. If there is a dis-
crepancy between the function and the sub-unit, the Edit fields are shown in
orange. The Product request function report only lists those attributes of a
function that are visible in the Properties window of the function. This also
applies if there are any discrepancies.
Right-click in the report on the text of an attribute to bring up a navigation
menu.
“PDAA.3 Data sheets Motor”

• In the base data view: under ET| D| M| B| 99 Induction motor, I&C
attributing.
• In the planning view: created automatically together with the induction
motor.
• Base object:
CRp| IC| PDA| PDAA| PDAA.3 Data sheets Motor

Using the Position sheet as an example, the following chapter will explain
how configurable I&C reports function. All the details apply to the other con-
figurable reports as well.
64.5.1.1.2 Overview
The position sheet is introduced in the following as an example for reasons of
easy legibility. All the details apply likewise for the other configurable
reports.
The position sheet possesses as usual a report template (this being a crp file).
Other report templates can be used within this report template, a technique
that is sometimes called “subreports”. However, it would be more exact to
talk of “subreport templates”, because reports as such cannot be used in a
report template. See also SECTION 46.3.7: PLACE SUB-REPORT for the definition of
subreports.
However, this configurable I&C report template does not use a fixed number
of “subreports”. For that reason a fixed number of attributes is not output
either.
The user (or the base data administrator) can control by means of attributes
exactly which subreports – and hence which attributes – are output, for exam-
ple on the position sheet.
A subreport of its own was created for each tab, and this outputs only the
attributes of this tab. You can set up any combination of tabs through a com-
bination of these subreports.
A Realization tab is created in the properties of the subreports. This subre-
port is used by the position sheet if the position sheet has been input in this
attribute.
Subreports are located in:
@F Functions | Y Attributes catalog | 1 Tabs collection,
and
ET| Y| 5 I&C tabs.

Depending on how you set up the usage for the individual subreports, the data
of the corresponding tabs either is or is not output on the report. All position
sheets that are based on the same position sheet report template display the
same tabs.
The use of the following reports can be enabled or disabled in the default set-
tings:
• Request attribute
• Request attribute Function
• Request attribute Motor
• PE position sheet
64.5.1.1.3 Technical implementation
Overview
Attributes are used to control the position sheet. However, attributes are only
available in a report and not in a report template. The technical implementa-
tion of the position sheet is thus somewhat more complicated than usual:
• There is the crp template for the position sheet.
• There are the report template objects for the subreports. However, these are
only required to be able to create the report objects of the subreports (see the
next item).
• There are the report objects of the subreports. The attributes are available for
control on these reports.

Position sheet: list script

First of all, the owner of the position sheet is searched for – this is the mea-
surement position – and then underneath the owner for all measurement func-
tions (ReportObject.ScanDevices("F")).
The tabs are collected from these devices. In Comos tabs are also attributes.
You thus get the tabs by searching for the attributes directly underneath the
device (the next level would then be the attributes on the tabs):
Set PLTFunction = ColPLTFunction.Item(i)
Set ColChap = PLTFunction.Specifications
Once you have the tabs, you then search for the appropriate base data
(Chap.CSpecification), and as a rule (but not compulsorily) the objects are
in a @Y branch in the base project. You take the owner of the base object that
has been found and search underneath it for a report that has the same name
as the tab (hence it also has the same name as the base object of the attribute):
If Left(SubReport.Name,len(CDevChap.Name)) = CDevChap.Name
The next step checks whether the report (and hence the subreport) is to be
used (If Report.UseSubreport(Subreport) = True Then). This test is
done in the options script, see the following section.
If the test is True, the report template from the report is then searched for and
used in the position sheet (Subreport.CDocument.FileName).
Position sheet: options script

A number of reports (and hence subreports) had already been determined in
the list script.
The following tab and attribute are searched for in the subreports:
S001 Realization tab, list attribute LI_001, attribute S001_001.

A test is made for this list attribute to determine whether it has an entry that is
the same as the name of the position sheet. The logic is as follows:
Specifications.Item(S001_001).GetXValue(i) != Document.CDocu-
ment.Name; whereby the actual programming implementation is somewhat
different, for obvious reasons.
Only exactly matching entries are permitted in this list attribute; any typing
errors means that the subreport cannot be executed. The attribute is filled in
from a standard table to avoid typing errors and to make operation easier:
<base project: standard tables>
| ET | Y Attributes catalog | O Documents | S001 Subreport
| S001 Document types
Only reports that had been entered in this standard table can be selected.
Objects of type “report template” for the subreports

It was explained above that the subreports must exist as proper reports to
allow control of the position sheet, because attributes are only available in
reports. You require the following if you wish to create reports:
• report templates (crp files) and
• objects of type “report template”.
These objects of type “report template” are not required subsequently; hence
they only exist to make it possible to create subreports as reports. The report
template is located in:
<base project, Documents tab>
CRp Templates | IC Reports I&C | ZZZ Subreports | PDA Subre-
ports for I&C
Query
The position sheet has a list of devices (as a query underneath the template)
as an auxiliary object. It lists the device requests and / or real devices of the
position. If the real devices are assigned to device requests, only the real
devices are included in the list of devices.
64.5.1.2 Remaining I&C Evaluation Reports
64.5.1.2.1 “PDAB.1 PLT position overview”

Available in:
Folder 04 EE/I&C Engineering , 01 Documents folder
Report template: CRp| IC| PDA| PDAB| PDAB.1 Position overview

Base object: ET| O| PDA Data sheets

Lists all the positions of the sub-uni:
64.5.1.2.2 “PDAC.1 PLT position - function overview”

Available in:
Report template: CRp| IC| PDA| PDAC| PDAC.1 PLT position -
function overview

Lists all the positions and functions of the sub-unit
All the attributes that can affect the display of a function are listed for func-
tions.
64.5.1.2.3 “PDAD.1 Armature overview”

Available in:
Report template: CRp| IC| PDA| PDAD| PDAD.1 Armature overview

Lists the corresponding valves and fittings of the sub-unit:
Green fields can be edited directly in the report.
64.5.1.2.4 “PDAE.1 Function and signal list”

Available in:
Folder 04 EE/I&C Engineering
Report template: CRp| IC| PDA| PDAE| PDAE.1 Function and signal
list

Lists all the functions and signals of the sub-unit:
64.5.1.2.5 “PQAC.1 Loop, check protocol”

Available under:
@P|02 Positions acc. to DIN/IEC
Report template: CRp| ET| PQA| PQA.21 Loop, check protocol

Base object: ET| O Documents

This report collects all devices. It does not list the device requests. The report
hence offers an overview of the loop from the device view. “MB” is the (Ger-
man) abbreviation for “measuring range”.
64.5.1.2.6 “PFPA.1 Signal list and PFPA.2 Signal list (hardware)”

Available in:
Folder 04 EE/I&C Engineering , 01 Documents folder and
underneath PI| EN| U| A| 01 Installation/ Building/ Production
and PI| ANSI| U| A| 01 Installation/ Building/ Production
Report templates: CRp| FP| PFP | PFPA Signal list.
Base object of both reports: @O Documents.
Lists which signals are located underneath the individual functions of the
positions. (PFPA.1: all signals underneath the EE/I&C folder; PFPA.2: only
the signals for hardware):
64.5.1.2.7 “PFPB List of references”

Available in:
Report templates: CRp| FP| PFP | PFPB Reference list| PFPB Signal
– reference list

Base object: @O Documents.

Overview of the logical diagrams on which a signal has been placed (Signal
definition : initial positioning, References : subsequent positioning):
64.5.1.2.8 “PQBA List of security-relevant E/I&C installations”

Available in:
Report template: ET| PQB| PQB.1 Security relevant I&C installati-
ons
Base object: @O Documents.

Function: self-explanatory.
64.5.1.2.9 PPC reports

See SECTION 64.8.3: DOCUMENTS FOLDER PPC PARTS LIST, HOOK UP.
64.5.2 Interactive Reports
64.5.2.1 Loop diagrams

Loop diagrams automatically depict all the loops of a position in accordance
with the Comos standard loops. See SECTION 64.4: STANDARD-LOOP.

Example: PFSM.2 Position diagram:
They possess a series of auto-functions that facilitate the work of the I&C
planner. The auto-functions are introduced on the basis of the example of the
PFSM.2 Position Diagram in SECTION 64.6: AUTO FUNCTIONS OF LOOP DIAGRAMS.
64.5.2.1.1 “PFSM.2 Position diagram”

Available in:
@P| 01 Measurement and @P| 02 Positions acc. to DIN/IEC
(only once per position)
Report template:
CRp| ET| PFSM position diagrams
Base object:
ET| O| PFSM position diagrams
Diagram type: DETAIL_IC
64.5.2.1.2 “PFSM.1 Loop ANSI”

Available in:
PFSM.1 : @P| 03 Positions acc. to ANSI
Report template:
PFSM.1 : CRp| PI_ANSI| PFS| PFSM| PFSM.2 Loop ANSI
Base object:
ET| O| PFSM position diagrams
Diagram type: DETAIL_ANS

ANSI loop diagrams have the same properties and automatic mechanisms as
those of PFSM.2 position diagrams. However, in the standard database some
of the control parameters of the options script have different values.
The main difference is that ANSI position diagrams have a horizontal align-
ment and not a vertical alignment.
64.5.2.1.3 “PFA.04 Position diagram, single line”

Available in:
@P| 02 Positions acc. to DIN/IEC
Report template:
CRp| ET| PFA| PFA.04 PFA.04 Position diagram, single line
Base object:
ET| O| PFA PFA.04 Position diagram, single line
Diagram type: SLINE

Single-line position diagrams have the same properties and automatic mech-
anisms as those of PFSM.2 loop diagrams.
Differences compared to PFSM.2: the connection between objects placed on
the diagram is shown by a single line. Since single-line loop diagrams are to
be assigned to the basic planning, they have fewer page areas than the PFSM.2
position diagram (only Field , Ex-Protection and Control system ).
Control parameter: “AutoLoopFilter” (type: string)

If objects are only to be placed on single-line position diagrams and not on
normal position diagrams, this can be set in the options script of the report
template by means of the AutoLoopFilter control parameter. See
SECTION 64.6.4.2: OPTIONS SCRIPT OF THE REPORT TEMPLATE for more details.
64.5.2.2 “PFFA Functional diagram”

This is only required for FD. The report template for this is located in the base
project on the Documents tab under CRp| FP| PFFA Functional diagram.
The base object is located under FP| O| PF| PFFA| 02 Functional dia-
gram IEC. (Sometimes also called logical diagram.)

Auto functions of loop diagrams I&C sub-module
64.6 Auto functions of loop diagrams

The auto-functions for loop diagrams are illustrated on the basis of the exam-
ple of PFSM.2 Position diagram (see SECTION 64.5.2.1.1: “PFSM.2 POSITION DIA-
GRAM”).
64.6.1 First opening of a loop diagram
Among the most important auto-functions are the commands “Automatic

Placing” (AutoLoop) and “Automatic Connecting” (AutoConnect).
They are executed automatically when the loop diagram is first opened. The
result is that all channels that belong to the signals of the position are placed
on the diagram and are connected (see Exact search algorithm, P. 64-43 for details
on the search algorithm). The diagram is created with multiple pages as
required. All object data, connectors, cables, wires and potentials, etc., are
fully retained.
If the objects lying underneath the position or if objects that are linked with
these objects are changed after the first opening, these changes are not dis-
played on the loop diagram automatically. They are only incorporated once
the following commands are called from the mouse menu:
OPTIONS | AUTOMATIC PLACING and ...| AUTOMATIC CONNECTING.
SECTION 64.6.4: CONFIGURING AUTO-FUNCTIONS describes how the automatic mech-
anisms are to be configured by the administrator.
64.6.2 Automatic Placing
Call:
When the loop diagram is first opened and also from the OPTIONS | AUTOMATIC
PLACING mouse menu of the loop diagram.
Comos handles the updating differently depending on whether you clicked on
a blank part of the diagram or else marked an object and then called up the
context-sensitive mouse menu:
• Automatic Placing was called up for the entire diagram (no selection):
Comos searches for the owner of the loop diagram, or in other words, the
position. Starting with the devices (device requests and their
implementation) located underneath the owner and using the joined
connectors, it is recursively checked with which objects these start objects
are associated. The search for placeable objects or for start objects for
placeable objects is also run on signals .

I&C sub-module Auto functions of loop diagrams
If Automatic Placing was called up after the first opening, then in addition
all the objects that had already been placed on the diagram are set as start
objects.
• Automatic Placing was called up for one or more selected objects:
Only the selected objects are used as start objects to search for the new
objects to be placed. The search is again run recursively and through the
joined connectors.
All objects that are directly or indirectly connected with the start objects are
placed on the report, in the page area specified by the name of their AREA-
NAME attribute and in the direction that was specified in the options script of
the report template (see SECTION 64.6.4.2: OPTIONS SCRIPT OF THE REPORT TEMPLATE).
The default spacing between the objects is 5 grid points, so for a 4 mm grid
that is 20 mm.
The Automatic Placing function also places terminals that are connected in
the database.
Exact search algorithm

Comos proceeds in detail as follows to find out which objects are to be placed:
1. The objects that are located parallel to the loop diagram in the Navigator
and objects located underneath these objects are searched recursively
according to the following rules:
• Device: objects located underneath the device are checked recursively; if
the device is a request that possesses an implementation, the
implementation and any objects located underneath it are checked as well.
• Element: The element and objects located underneath it are checked
recursively.
• Information objects (devices with class Data set , sub-class User
address ): are placed.
• Signal: objects located underneath the signal are checked recursively. If
the signal possesses an implementation, the implementation is placed.
• Function: objects located underneath the function are searched
recursively. If the function possesses the Fitting or Symbol sub-class, it
is placed as well.
• An object that is based on a base object with class Device request : if the
object possesses an implementation, the implementation is placed.
2. If the loop diagram is located underneath a signal that possesses an
implementation, the implementation is set as the start object.

Connections that are not evaluated

The following types of connections are ignored during Automatic Placing
(i.e., the objects behind them are not placed):
• Bridge
• Connection with potential
(the connector is joined to the connector of a physical potential)
• Connector has LogPot pointer
(the connector is provided with a logarithmic potential via a pointer or
through potential tracking)
Special cases
• Comos proceeds as follows if an object whose AREANAME attribute has
the value “Not set”:
If it involves an element, the AREANAME attribute is checked at the
MainDevice (the associated main component).
If it involves a request with an implementation, a search is made at the

implementation.
If the object is on the Locations tab or if it possesses a location pointer, the
location structure runs upwards until an area value is found.
If an AREANAME attribute is not found anywhere or if its value does not
correspond to any of the segments on the diagram, the objects are placed at
the left-hand edge of the drawing.
• If there is an area without a name, hence area = “ ”, then no objects are
placed in this area either if objects that have “ ” as the area entry are found.
The objects are treated in the same way as objects without an area entry.
• Objects whose AREANAME attribute has been set to Don’t place are not
placed, in principle.
64.6.3 Automatic Connecting
Call:
When the loop diagram is first opened or via the OPTIONS | AUTOMATIC CON-
NECTING mouse menu of the loop diagram.
All the reading connections are displayed on the loop diagram - this means
that Comos reads from the database whether two objects are joined to one
another through their connectors and displays this connection (blue connect-
ing line).

If the AutoConnectX parameter has been set in the options script of the report
template, then in addition all objects located underneath each other are joined
both graphically on the diagram and in the database, via their connectors. See
SECTION 64.6.4.2: OPTIONS SCRIPT OF THE REPORT TEMPLATE regarding AutoCon-
nectX.
If cables have already been laid in the database (having been assigned to con-
nectors by means of pointers) and if the AutoLoopCables = True variable
has been set in the options script, then these cables are placed on the report as
well.
64.6.4 Configuring auto-functions
64.6.4.1 Overall conditions in the base objects: “AREANAME”

The base objects receive on the System tab a new attribute of type Edit field :
AREANAME Page area (case-sensitive). The following standard table is
assigned to the attribute:
ET Electrical Engineering | Y Attributes catalog| 0 Attributes
collection | 01 System| AREANAME Page areas.
In the base project the attribute specifies the page area on which the object is
to be placed during Automatic Placing. If the AREANAME at a base object is
Not set , Comos proceeds as described in Special cases, P. 64-44 so as to still be
able to determine a page area on which the object can be placed. If an ARE-
ANAME attribute is not found anywhere or if its value does not correspond to
any of the segments on the diagram, the objects are placed at the left-hand cor-
ner of the drawing
Value2: AreaNumber
The Value2 of standard table AREANAME , the so-called “AreaNumber”, is
relevant when placing terminals:
If Value2 (thus the AreaNumber) is set to “99”, this area is used in AutoCon-
nect as the starting point for a number of placed terminals.
Example: Six terminals have been placed in a row on a diagram. An object
has been connected to “Terminal 1”. The object is in a line with the terminals.
An object has also been connected to “Terminal 6”. But the object is not
located on the report in a line with the terminals. The connecting line between
the terminals and the objects must be “bent” at some point. Using Value2 =

you can force the “bend” to be made within the placed terminals. Thus termi-
nals one to three could line up with the first object and terminals four to six
with the second object.
64.6.4.2 Options script of the report template

The following control parameters can be set in the options script of the report
template:
• AutoLoop (type: Boolean):
Must be set to True. This parameter controls from a central point whether
the | AUTOMATIC PLACING command option is offered in the mouse menu.
Default: False
• AutoStartLoop (type: Boolean):
AutoStartLoop = True: Automatic Placing and Automatic Connecting are
initiated at once when the report is first opened. If this script option is
missing or if it has been set to False, the functions must be initiated
manually from the mouse menu.
Default: False
AutoConnectX (type: long):
When calling Automatic Connecting, all objects that are linked through
their connectors are displayed and connected on the diagram.
AutoConnectX controls whether objects that have been placed next to one
another or under one another on the diagram are to be connected as well:
AutoConnect = 0: no additional connections
AutoConnect = 1: vertical connections
AutoConnect = 2: horizontal connections
AutoConnect = 3: vertical and horizontal connections
Default: 0
• AutoLoopFactor (type: long):
Specifies the spacing between the individual objects of an area for
Automatic Placing(factor x grid in mm).
Default: 5
• AutoLoopConnectorLayers (type: long):
Specifies through which types of connectors objects to be placed are to be
searched for.

AutoLoopConnectorLayers = 0: all types of connectors

AutoLoopConnectorLayers = 1: only ELO connectors
AutoLoopConnectorLayers = 2: only SLine connectors
AutoLoopConnectorLayers = 3: ELO and SLine connectors
Default: 0
• AutoLoopCables (type: Boolean):
AutoLoopCable = TRUE:
If cables have already been laid in the database (having been assigned to
connectors by means of pointers) , then these cables are placed on the report
as well.
Placing on the report: Fundamentally speaking, the Cable planning object
on the System tab can also possess an AREANAME field. In that case that
entry takes precedence.
In the standard database the Cable planning object has not been preprepared
accordingly and no AREANAME is available. In that case the cable is
placed centered on the first connecting segment of the two channels that
have been connected.
AutoLoopCable = FALSE:
The cables are not shown on the report.
Default: True
• AutoDistributeTerminals (type: Boolean):
AutoDistributeTerminals = True: In Automatic Connecting the
terminals are distributed equally over the area.
If False they are placed at the relevant area edge one after another with the
default spacing.
Default: False
• AutoConnectExternObjects (type: Boolean):
Allows the creation of half-open connections during Automatic Connecting.
Default: False
• AutoLoopTerminalStrip (type: Boolean)
If True then no terminals are placed on the diagram but instead directly
terminal strips.
Default: False
• AutoLoopFilter (type: String)
Comos objects that are to be placed only on a single-line loop diagram
during Automatic Placing and not on a normal loop diagram receive a
common attribute. The name of this attribute is then assigned to the
AutoLoopFilter variable in the options script of the loop diagram. If a page

area was specified through the AREANAME attribute, the objects are
subsequently placed on single-line diagrams but not on normal loop
diagrams.
• PreferredConnectionDirection (type: String)
Specifies in which direction the objects are to be placed during Automatic
Placing.
PreferredConnectionDirection = “X“: horizontal
PreferredConnectionDirection = “Y“: vertical
Default: “Y“
64.6.4.3 Segmentation of the diagram

The diagram should be split up into segments to make best use of the Auto-
matic Placing function. These segments are then input later as the target for
the placing function. From a technical point of view, the placing functions
also works without segmenting the diagram. But since the program cannot
know where an object should best be placed on the diagram, the segments are
used to control where on the diagram a device or element will be displayed.
If there are no segments, the objects are then lined up at the left-hand edge of
the diagram.
If no segments had been prepared beforehand in the loop diagram for you by
your administrator through the base data, you can do this later. In the standard
database a number of different segments have been prepared for this purpose
under the ET| 3| 04| 01 Document design branch. Use drag & drop to
pull one of the base objects onto the diagram:

There is also a more general segment, in which no description has been

entered. This segment is located in the standard database under
ET| D Devices | O O Other base objects| A O Blackboxes,
Segments| 11 O Segment.
In both cases the base objects are of class Element , sub-class Segment .
The databases are structured as a rule from customer-specific points of view.
In some of the databases the segments can be found under @E Elements -
@D Detail plan elements - segment (labelling) .
The segments are dragged out to the required size by using the grab points. If
you use an object with base object ET| D| O| A| 11 O Segment the name
of the segment is missing. (The name determines which objects are later to be
placed in this page area.) It is input via the properties of the segment. See also
Properties of a segment, P. 64-49.
Direction of a segment
Please note that segments have a “direction”!
All the segments on a loop diagram have a common “direction”. The direction
determines in which direction the placed elements are to be lined up.
The direction is controlled in the report template of the loop diagram by
means of the PreferredConnectionDirection = {X,Y} script option. If
“X” has been set, the placed elements are lined up horizontally, and vertically
if “Y” has been set.
Properties of a segment
Right-click on the rectangle to open the Properties window.
Options group Label is valid for: this is required in connection with abbre-
viated labels and is not important for Automatic Placing; the default setting
can be used. The name of the segment is entered in the Name edit field. This
name is used in the base objects as the placing target. A number of names have
already been prepared in the dropdown field, these names can be used as a tar-
get point by terminals, for example.
Once you have divided up the working area into several segments and have
allocated the area names that are required, the preparations have been com-
pleted in the diagram. Of course the prepared diagram can be used as a docu-
ment template so that in actual production work any desired number of
diagrams can be derived from this template.

Using I&C I&C sub-module
Exceeding the segment limits

If an Automatic Placing operation is executed in an interactive report and the
placing frame is too small for the number of objects, several pages are created
automatically.
If an interactive Report has more than one page as a result of this, the Delete
page mouse command is made available on the relevant last page. The com-
mand is no longer shown if only one page is left.
64.7 Using I&C
64.7.1 Working with signals
64.7.1.1 General
A signal designates the information unit that is further processed in logical
diagrams, for example, “ON” or “OFF”. It illustrates the input or output of the
control technology. The signals are taken from IEC 1175 “Labelling for
Signals and Connections”.
In Comos signals are used in addition to identify objects that belong together.
See SECTION 64.7.1.4: CONNECTOR: SIGNAL OF OWNER.
This section explains how to work with signals in Comos. It is assumed here
that you are working with the unit structure according to EN, which has been
preprepared in the standard database. See SECTION 64.1.2: UNIT PLANNING.
See SECTION 64.2.2.10: ET |S SIGNALS regarding the structure of the base objects
of signals.
See SECTION 64.2.2.10.2: TABS / ATTRIBUTES regarding the tabs of signals.
The base data has been preprepared in the standard database in such a way that
the signals can easily be created by using the | NEW mouse menu of the func-
tions. Assembly groups for signals with channels have also been preprepared
in the mouse menu to make it even easier to work with signals.
64.7.1.2 Mouse menu of the measurement function
64.7.1.2.1 Overview
Here is a brief overview of the menu entries that are available:

I&C sub-module Using I&C
• | A1 FAVORITE ASSEMBLY GROUPS (SIGNALS WITH CHANNELS)

A selection of assembly groups, especially matched to the function. Hence
this mouse menu only appears once the function has received a function
code. In earlier Comos versions these assembly groups existed as a “wiring
standard”. See SECTION 64.7.1.2.2: WORKING WITH ASSEMBLY GROUPS: “ASSEMBLY
GROUPS (SIGNALS WITH CHANNELS)”.
• | A2 ASSEMBLY GROUPS (SIGNALS WITH CHANNELS)

A collection of all assembly groups. In earlier Comos versions the assembly
groups existed as a “wiring standard”. See SECTION 64.7.1.2.2: WORKING WITH
ASSEMBLY GROUPS: “ASSEMBLY GROUPS (SIGNALS WITH CHANNELS)”.
• | B SIGNALS ACC. TO IEC 1175

A collection of all signals. This is used when signals are created manually.
See SECTION 64.7.1.2.3: CREATING SIGNALS AND DEVICE REQUESTS MANUALLY.
• | D1 FAVORITE MEASURING INSTRUMENTS
Contains a selection from the overall instrumentation, also including real
devices, among others. See SECTION 64.7.1.2.3: CREATING SIGNALS AND DEVICE
REQUESTS MANUALLY.
• | D2 MEASURING INSTRUMENTS
A complete list of the instrumentation. Contains both examples for device
requests and a number of examples for manufacturer catalogs (real devices).
See SECTION 64.7.1.2.3: CREATING SIGNALS AND DEVICE REQUESTS MANUALLY.
• | FP1 FUNCTION MODULES
Only important for FD.
• | Z MOUNTING
• | PDAA.2 REQUEST SPECIFICATION FUNCTION
This report contains ordering details. It involves a report that can be
configured by means of attributes. See “PDAA.2 Product request Function”, P. 64-
31.
64.7.1.2.2 Working with assembly groups: “Assembly groups (signals with

channels)”
Structure
The assembly groups offered in the Favorite assembly groups (signals
with channels) mouse menu are a selection of the assembly groups con-
tained in Assembly groups (signals with channels) and inherit from them.

This section thus relates to Assembly groups (signals with channels) .

However, the explanations are also valid for Favorite assembly groups
(signals with channels) .
Base objects:
• ET| 3| 01| 01 Assembly groups (signals with channels),
compare also SECTION 64.2.2.2.1: “ET| 3| 01 UNITS”
• @F| Z| A1 Favorite assembly groups (signals with channels),
compare also SECTION 64.2.1.3.6: “@F| Z STRUCTURES (CREATE NEW/ASSEMBLY
GROUPS)”.
This involves assembly groups for measurement functions. Exception: the

assembly groups created under ...| Y Actuators.
They consist of the following objects:
• A signal with an input channel (created as a request). In addition, there is the
reference of the device channel request under the signal.
• A device request with a channel request “<device> (element)”. The channel
request possesses a pointer to the signal (so that the reference is created
under the signal).
In addition, the channel request is linked by its connectors with the input
channel under the signal.
• Optional if there is the corresponding selection in the mouse menu: the
request at a measuring transmitter supply channel.
• Please note: There are no terminals in the assembly groups.
In the object view the above I&C basic structure (unit view) looks like the fol-
lowing:
Subunit / Category
-|Position
-|Measurement function
-|Signal
-|Device request

• It then looks like the following in the Navigator::
The connection between the signal and the device request is the device chan-
nel request. In the above example the device channel request is shown as
Measuring transmitter (element) .
If the assembly groups are created in the planning view, these objects are cre-
ated and connected in a way that implements the Comos standard loop. First
of all, all the objects of the assembly group are created on the Units tab. Later
a number of them are moved to the Locations tab by means of the implemen-
tation function.
Incomplete division into unit view and location view

The use of assembly groups has a peculiarity: For technical reasons, the wired
objects must be located in a common branch.
A comparison of the objects created by the automation concept against the
standard model shows the following: Objects that in fact belong to the loca-
tion view are also created underneath the signal. This includes, for example,
the input. Because of that, objects of type input are created with the Request
property; an implementation is done with objects from the location view in a
subsequent work step.
This implementation is done very quickly, because all the objects possess
unique identification keys:
• On the one hand, the objects can be identified by means of the signal.
• On the other hand, all the objects possess the AREANAME Page area
attribute on the System tab, regardless of whether they belong in the location
view or the unit view (and exactly where within it).
Siehe SECTION 64.7.2.3.6: IMPLEMENTATION.
Please note: there are no terminals in the assembly groups.

64.7.1.2.3 Creating signals and device requests manually
1. Create signal / create channel

First of all, a signal must be created by means of | B SIGNALS BY IEC 1175. The
channels must then be prepared in the mouse menu of the signal:
The mouse menus with the channels are self-explanatory. The | A ACTION
BLOCK mouse command is only of importance for FD.
Please note: a channel request must be created at this point in time, otherwise
the following automatic mechanisms do not function! The channel request
must be matched to the device channel request that is to be created. An exam-
ple is given below.
2. Create device request objects

Device request objects are made available via the mouse menu | D1 FAVORITE
MEASURING INSTRUMENTS and | D2 MEASURING INSTRUMENTS. A device request
object can consist of the basic device and one or more channels.
The devices are prepared to the extent that they bring in the elements to be
implemented (= channels). If, for example, you create an object Measuring
instrument, general , you then find underneath it the element Meas. trans-
mitter (element) . With other devices there are correspondingly other ele-
ments, often even several of them.
If a suitable signal with a channel request exists in parallel to the device
request object, the element (hence the “channel”) is then automatically refer-
enced under the signal.
Example: Creating signals, channels and device requests

• Mouse menu of folder 04 EE/I&C Engineering ,
| P01 POSITIONS ACC. TO DIN/IEC | P PRESSURE
• Properties of the position,
Label: enter PI; the measuring function that is created in the next step
inherits the label of the position - and hence automatically possesses a
function code.

• Mouse menu of the position,

| 01 MEASUREMENT FUNCTIONS | 01 LOCAL MEASURING
• Mouse menu of the measuring function,
| B SIGNALS... | 01 REGULATIONS | I CURRENT VALUE
• Mouse menu of the signal,
| 01 MEASUREMENT RECORDING CHANNELS | E1 SENSOR (ELEMENT)
• Mouse menu of the measuring function,
| D1 FAVORITE MEASURING INSTRUMENTS| P1 SENSOR | 01 SENSOR GENERAL
The channels of the unit view are later implemented (via the signals) via the
channels in the location view, see SECTION 64.7.2.3.6: IMPLEMENTATION.
3. Connecting manually
Please note carefully the input and output of the objects! If you create and
connect objects manually, it is necessary to connect the relevant objects cor-
rectly. Do not confuse the input and the output. Above all, this concerns the
terminals: here too there is an I-connector (= input) and an O-connector (=
output).
If you mix up the I-connector and the O-connector at the terminals, neither
Automatic Placing (see SECTION 64.6.2: AUTOMATIC PLACING) nor Marshalling
Management (see SECTION 64.7.3: MARSHALLING MANAGEMENT) will work cor-
rectly later.
The alignment of the terminals is as follows (O = Out; I = In)
64.7.1.3 The mouse menu of the actuating function

| A CONTROL ARMATURES
Valves are required in P&ID and exist already when the I&C planning begins.
See SECTION 57.7.5: WORKING WITH FUNCTIONS IN THE PLANNING VIEW.
| B1 ACTUATING SIGNAL
This actuating signal is identical with the actuating signal in mouse menu B2
(if you have resolved the base object references in the base data):
| B2 SIGNALS ACC. TO IEC | 01 REGULATORS | C ACTUATING SIGNAL

| B2 SIGNALS ACC. TO IEC1175

Offers the same signals as does the menu of the measurement function. See
also SECTION 64.7.1.3.2: ALTERNATIVE: CREATING SIGNALS AND CHANNELS MANUALLY.
| C ASSEMBLY GROUPS (SIGNALS WITH CHANNELS)
See SECTION 64.7.1.3.1: ASSEMBLY GROUPS FOR ACTUATING FUNCTIONS.
| FP FUNCTION BLOCK VALVE
This is only used in FD.
| Z MOUNTING
| PDAA.2 REQUEST SPECIFICATION FUNCTION
This report contains ordering details. It involves a report that can be config-
ured through attributes, see “PDAA.2 Product request Function”, P. 64-31.
64.7.1.3.1 Assembly groups for actuating functions
Structure
The assembly groups also include an assembly group for functions with func-
tion code “Y”. This assembly group can be created through the | NEW| C
ASSEMBLY GROUPS (SIGNALS WITH CHANNELS) mouse menu of an actuating
function.
It functions in the same way as the assembly groups described in
SECTION 64.7.1.2.2: WORKING WITH ASSEMBLY GROUPS: “ASSEMBLY GROUPS (SIGNALS
WITH CHANNELS)”, but consists of different objects:
• A signal with an output channel (created as a request). In addition, under the
signal there is the request for a positioner control channel and a solenoid
valve channel.
• Optional: the request for an isolating amplifier channel.
Incomplete division into unit view and location view

See the measurement functions Incomplete division into unit view and location view,
P. 64-53.
64.7.1.3.2 Alternative: Creating signals and channels manually

The mouse menus also offer the option to create the signals and their channels
manually:
• Mouse menu of the actuating function:
| NEW | B1 ACTUATING SIGNAL. This command can only be selected once per
actuating function. However, the actuating signal continues to be available

in the | B2 SIGNALS BY IEC mouse menu.

Alternative: select the desired signal directly via the | B2 SIGNALS BY IEC
mouse menu.
• Mouse menu of the signal:
| NEW | <channel> Select the channels.
64.7.1.4 Connector: Signal of owner

In Comos the signals are also used to identify objects that belong together. For
this, element requests are created underneath the signal that inherit the rele-
vant signal information. The element requests then allow the signal informa-
tion to be inherited further. The Signal of owner option of the connectors
must have been prepared accordingly so that inheriting this signal information
functions properly in all cases.
You can find the Signal of owner option in the Properties window of the con-
nectors:
If the option has been activated, the connector then inherits the signal from the
owner of the planning object that the connector belongs to. However, the term
“owner” is to be taken in the wider sense with respect to this option:
1. Direct owner
A signal passes on the signal information to the connector via
the device.
2. The owner has a pointer to a request object

The owner of the connector has a request pointer

and this request object is located underneath a sig-
nal.
In practice: This case arises if a device has been
implemented and the “Implement request“
replaces object project option has been
disabled.
3. The owner has a unit pointer to a signal
The owner of the connector has a unit pointer to
a signal.
Background: The “unit pointer” can point not
only to objects of class Unit but also to objects of
class Signal .
In this case the signal information can be passed
on via the unit pointer to the device (any desired device) and from there to the
connector.
In practice: This case arises if a device has been implemented and the “Imple-
ment request“ replaces object project option has been enabled.
4. The owner has an implementation pointer to a signal
In practice: This case arises if a signal has been
implemented Here the “Implement request“
replaces object project option has no effect at
all, because signals are never deleted
(“replaced”).
The effect of this control parameter is most obvious in the Marshalling Man-
ager, see SECTION 64.7.3: MARSHALLING MANAGEMENT.
64.7.1.5 Signal Manager

Comos menu, | EXTRA | DETAIL | SIGNAL MANAGEMENT
The Signal Manager is obsolete. If required, you can find the requisite instruc-
tions in SECTION 55.1: SIGNAL MANAGEMENT.
64.7.1.6 Signal name matching

Plugins, Icon [SIGNAL NAME MATCHING]
When signals are created within Comos, they initially receive standard
names. The signals thus initially all have the same names underneath the var-
ious positions. The names are incremented within a position.

Signal name adaptation allows you to search for all signals within a branch
and to replace the standard name of a signal with the relative name of a con-
nector.
All the positions with all the signals appear on the left-hand side:
If you mark a signal at the left, all the connectors of the position belonging to
the signal appear on the right-hand side. Both connectors that were created
directly at the position and all the connectors of all objects located underneath
the positions are listed.
The connectors are listed with their relative names. Relative = name of the
connector plus the path from the position up to the connector.
Double-clicking on a connector:
The relative name of the connector is taken over at the signal as the name. The
label of the signal is retained.
64.7.1.7 Assignment manager

When working with elements (= channels), in certain very rare situations
more elements are created than had been planned administratively. In that
case the Assignment Manager is available to deal with such elements.
If necessary, you can find the appropriate instructions in SECTION 55.3: ASSIGN-
MENT MANAGER.
64.7.2 Location planning
64.7.2.1 Planning the location structure

Create a location structure on the Locations tab:
• First create the preprepared | 102 BUILDING location object.

• The location structures | 01 FLOOR and | 0X FIELD LOCATION are available

underneath the building.
The structures are set up further by means of | 01 FLOOR. For the beginning
you can ignore the | 02 FIELD LOCATION object, since it is only required later.
• This is followed by | R ROOM, then | 0X CONTROL CABINET and the racks in
the control cabinets.
It then looks like the following on the Locations tab, for example:
The control cabinet objects and the racks contain the actual I&C structures:
CONTROL CABINET (GENERAL)
Can contain both general racks and also DCS and ex-protection racks.
CONTROL CABINET (DCS) (DCS = Distributor Control System)
This is always required. See SECTION 64.7.2.3.2: CREATING A DCS CONTROL CABINET.
CONTROL CABINET (EX-PROTECTION)
See SECTION 64.7.2.4: EX-PROTECTION CONTROL CABINET.
MARSHALLING PANEL
Objects of the marshalling cabinet have also been preprepared in the DCS
control cabinet. If that is not sufficient, this marshalling cabinet is available
as well.
Request devices and real devices are offered in the DCS rack, these being, for
example, various types of measuring transmitters, isolating amplifiers and the
like. These devices also have channels (signal transmitter elements or control
channels):

64.7.2.2 Relation of the location view to the unit view

As a reminder: within the unit planning, elements are created that, according
to the Comos standard model, belong to the location view. (See Incomplete divi-
sion into unit view and location view, P. 64-53.) Thus the following tasks must be
done:
Task 1:
The field devices (measuring transmitters, sensors, valve elements) remain in
the unit view and must be connected with the location view through the field
distributor. It is necessary to determine through a bill of quantities just how
many objects need to be wired. As an alternative, the Devices with location
query can be used.
See SECTION 64.7.2.6: FIELD DISTRIBUTOR concerning the implementation.
Task 2:
The control and signal processing channels need to be migrated from the unit
view to the location view. In doing this it is necessary to determine how many
objects need to be created in the location view: this is either done with a bill
of quantities or with the nodes created at the Units tab: SO Search objects
| 01 Unimplemented DCS channels. Compare SECTION 64.7.2.3.4: THE CARDS.
Then E/I&C objects are created in the location view and implemented on the
objects from the unit view. The objects migrate from the unit view to the loca-
tion view as a result of the implementation.
See SECTION 64.7.2.3.6: IMPLEMENTATION concerning the implementation.
Procedure
The request objects (for the measuring transmitter elements and the control-
ler) were created in the plant design. This predetermines the “start” and the
“end” of the loop.
The following workflow is suggested in this documentation: first of all, the
control system is determined and specified. The work continues in the direc-
tion of the measuring transformer: This is followed by the ex-protection, then
the marshaling process, and finally the field distribution.

64.7.2.3 Control system
64.7.2.3.1 S7 / HW config
In Comos there is an interface to import and export objects of the Siemens tool
“HW Config” (= Hardware Configuration). This includes the “symbols” of
the Simatic project.
See SECTION 56.3: SIMATIC S7 (EXPORT, IMPORT) for further information.
64.7.2.3.2 Creating a DCS control cabinet

Right-click on a room object and select the | 02 CONTROL CABINET (DCS) con-
trol cabinet object.
64.7.2.3.3 The racks

There is a command for a rack in the context-sensitive mouse menu of the
control cabinet object. Create as many racks as you need.
Often the following is done: the first rack is created as a placeholder for the
power supply of the cabinet.
The number of additional racks is determined by the number of cards (= chan-
nels) that are used. The next section explains how you can determine the bill
of quantities for the cards.
Once all the required racks have been created, you can choose the most cost-
effective control cabinet from manufacturers with which you can attain this
concrete number of racks.
Once you know specifically which manufacturer control cabinets are
required, the general control cabinet object that was created above should be
swapped. The simplest way to do this is by creating base objects for the spe-
cific manufacturer control cabinets in the base data and then assigning new
base object to the general control cabinet in the planning data.
64.7.2.3.4 The cards

The number of cards required depends on the number of inputs and outputs
that had already been created in the “Create E/I&C objects” work step. The
number can be determined in one of two ways.
1. Determining the bill of quantities

Open the bulk processing function and search in the unit view through the
sub-unit for inputs and outputs:
| EXTRA | BULK PROCESSING| BULK PROCESSING FOR PLANNING OBJECTS

Select from the Class field the Element entry. All the channel requests that
are created under the signals have class Element .
Then drag the sub-unit from the Units tab into the Start object field.
You now get a big list in the actual planning data. It can take a while until the
list is complete. The list still has to be filtered:
Navigate to the object of one of the inputs or outputs included in the list. Find
its SYS System specification tab and there the AREANAME attribute. Drag
this attribute from the Navigator into the head of the table:
A new column is inserted. This column can now be filtered: select the Control
system filter text.
If it is simply a matter of determining the number of objects, you can see how
many objects there are in the filtered list at the bottom left in the status line of
the bulk processing.
2. Search objects
As an alternative to the bill of quantities, the number of inputs and outputs can
also be determined through the SO Search objects | 01 Unimplemented
DCS channels node from the Units tab, which are automatically created
underneath the EE/I&C folder in the standard database.
Creating cards
The cards can be created once you have determined the number of channel
requests:
Context-sensitive mouse menu | NEW of the rack:

• | A REQUESTS
If you create general cards, such as | A1 ANALOG INPUTS, you must connect
the cards yourself later.
• | B ARTICLE /MANUFACTURER
An example for real devices. Here too you must connect the cards yourself
later if that had not been done already by the requests.
• | C ASSEMBLY GROUPS AREA OVERLAPPING
The assembly groups are the counterpart of the assembly groups in the unit
view. See SECTION 64.7.2.3.5: ASSEMBLY GROUPS below.
• | X TERMINAL STRIP
The | X TERMINAL STRIP terminal strip is intended as a terminal strip for the
rack. However, as a rule no terminal strips are required for the rack, and
instead you connect the I/O modules (usually designated as “inputs” and
“outputs” in the Comos data) directly with the corresponding terminal
strips.
64.7.2.3.5 Assembly groups

The assembly groups offered in the context-sensitive mouse menu of the racks
are the counterparts of the assembly groups in the unit view. If, for example,
a signal has been connected in the unit view with a measuring transmitter sup-
ply unit and an analog input, then the | 01 INPUTS | C1 ANALOG INPUTS MTS_JD
assembly group is made available for it in the location view. In detail, the
assembly groups contain the following objects:
• | 01 INPUTS
– C1 ANALOG INPUTS MTS_JD
Eight analog inputs, eight 1-channel measuring transmitter supply units,
marshalling cabinet.
– C3 DIGITAL INPUTS TSVE_JD
Sixteen digital inputs, four 4-channel isolating switching amplifiers,
potential, marshalling cabinet.
• | 02 OUTPUTS
– C2 ANALOG OUTPUTS TV_RV
Eight analog outputs, four 2-channel isolating amplifiers, marshalling
cabinet.
– C4 DIGITAL OUTPUTS TSVA_RV
Sixteen digital outputs, eight 2-channel output isolators, marshalling
cabinet.

As an example, here is the result of the C1 ANALOG INPUTS MTS_JD assembly

group:
See “ET| L| C| 3 Templates”, P. 64-24 regarding the administration of assembly

groups.
Incomplete allocation in the control cabinet

Just as for the assembly groups in the unit view, the following applies here:
for technical reasons objects that have been wired through must be located
under a common node. For that reason the assembly groups described above
also contain objects that do not belong to the control system. That applies in
particular to the Ex-Protection and MC bay (control) folders. The folders
are created in parallel to the assembly group object. The objects that are in
these folders are moved in subsequent work steps. (See SECTION 64.7.2.4.1:
MOVING EX-PROTECTION FROM THE DCS CONTROL CABINET INTO THE EX-PROTECTION CON-
TROL CABINET and SECTION 64.7.2.5: MARSHALLING CABINET.)
The assembly group is wired (the connectors of the objects in the Ex-Protec-
tion folder with those in the MC bay (control) folder). This wiring is retained
when the objects are moved.
64.7.2.3.6 Implementation
Most of the objects that have been created and edited up to now have the
“request” property. An “implementation” is now done in a first step.
The following types of implementation are possible:
• A request (concrete) is implemented at a request (general)
• A manufacturer device (“product”) is implemented at a (concrete or
general) request,

No product data has been assigned yet at this point.
Implementing individual objects

To implement an individual object, open the Properties window of the request
object and use drag & drop to pull the planning object that is to serve as the
implementation of the request object from the Navigator onto the Implemen-
tation field:
Implementing several objects

There are two ways to implement several objects at the same time without
needing to constantly change interfaces.
1. Way: The Implement requests dialog window:
| EXTRA | DETAIL | IMPLEMENT REQUESTS
First of all, a list is created from the database. In principle, that functions in
the same way as already described above for bulk processing:
• Switch to the Units tab.
• Drag the |04 EE/I&C Engineering folder into the Start object field.
• Select the Element entry as Class .
• Drag the AREANAME attribute of any desired input object into the
dialog window and filter after the Control system text.

Now switch to the Locations tab and select a suitable card from the DCS
control cabinet. Drag the card channels into the Implementation column:
• This way it is possible to implement multiple objects at the same time. Do

this by first of all marking all the objects (it is not permissible for any of
them to have been implemented already) in the Implement requests
dialog window, and then mark the same number of card channels in the
Navigator and drag them into the dialog window.
2. Way: Request implementation query :
The QDev001 Request implementation query is created automatically
underneath the rack when creating the DCS rack. Open this query and press
the [SEARCH] button.
All channels that are located in the DCS rack are displayed automatically.
The Request column shows whether or not this channel has already been
set as an implementation for a request object.
If the “Implement request” replaces object project option is enabled, the
request object no longer exists for an implemented channel. Instead the
signal is shown in such as case.
In the next step, switch to the Units tab and there open the required search
object, which in our example is the | IA DCS Input analog search object,
in the EE/I&C Engineering folder underneath the noede SO Search

object | 01 Not implemented DCS channels . All the analog DCS inputs
that exist as request objects without an implementation are now displayed in
the Navigator underneath the object.
Now mark a channel request object in the Navigator and drag it into the
query window, into the Request column of the desired implementation
object.
If the channel type of the request object matches the channel type that is
displayed in the Channel type column of the implementation object, the
implementation object is implemented at the request object. The request
object is removed from the search object.
Warning: The implementation must be confirmed by either pressing [APPLY]
or [OK] before it is actually written to the database. If it has not been saved
yet, the implementation process can be undone by pressing [CANCEL].
Multiple request objects can also be marked and assigned in one operation.
64.7.2.4 Ex-protection control cabinet

If you worked with the ready-made assembly groups from the standard data-
base in work step Creating cards, P. 64-63, you also created objects for ex-protec-
tion. For example, template C1 ANALOG INPUTS MTS_JD creates the Ex-
Protection folder with all the objects contained in it.
However, often a control cabinet of its own is set up for ex-protection, con-
taining all the devices subject to ex-protection.
Right-click on the ROOM object (or on the room object that you renamed) and
select | 03 CONTROL CABINET (EX-PROTECTION).

64.7.2.4.1 Moving ex-protection from the DCS control cabinet into the ex-
protection control cabinet
Open from within the Navigator the data structure of the Control cabinet
(DCS) object and search there for the Ex-Protection folder. Mark all the
objects in the folder (without the connectors) and select the | CUT command
from the mouse menu.
Right-click on the Control cabinet (Ex-Protection) object and select the
| PASTE command. All the wiring is retained.
You can now delete the empty Ex-Protection folder from the Control cabi-
net (DCS) object.
64.7.2.4.2 Assembly groups

Assembly groups are also available within the ex-protection control cabinet.
You can find the following objects in the mouse menu, each with details of
the relevant counterpart from the unit view:
C ASSEMBLY GROUPS | ...
C ASSEMBLY GROUPS | C1 MT Suppliers 924 (21)-> Analog input
Fundamentally speaking, this module belongs to the topic of ex-protection.
...| C2 ISOLATING AMPLIFIER EGT-005 -> ANALOG OUTPUT
...| C3 ISOLATING AMPLIFIER EG4-R (21)-> DIGITAL INPUT
...| C4 OUTPUT SEPARATOR / VALVE ED2-VN-EX2.35 (21) -> DIGITAL OUTPUT
Typically this module is only required with Ex-protection.
See “ET| L| C| 3 Templates”, P. 64-24 for the administration of the assembly
groups.
64.7.2.5 Marshalling cabinet

Create under the ROOM object (or under the room object that you renamed) a
control cabinet for the marshalling: | NEW| 04 CONTROL CABINET (MC) mouse
menu.
In the mouse menu of the control cabinet there are two ready-made bays that
you need to create:
• The first bay A BAY (CONTROL SIDE) takes the objects from the DCS control
cabinet and the objects from the ex-protection control cabinet.
• The second bay B BAY (FIELD SIDE) takes the objects into the unit view.
The marshalling is done later between these two bays.

Bay “A Control side” (location view)

First of all, the objects of the control side should be brought into bay A . An
assembly group was used in the example given above. In that case you should
open within the Navigator the data structure of the other control cabinets and
search for sub-folder 50 MC Bay (Control) :
Mark all the objects in the folder (without the connectors) and select the | CUT
command from the mouse menu. Go to the Control cabinet (MC) object and
there paste the objects that had been cut into BAY (CONTROL SIDE). The empty
folder 50 MC Bay (Control) can now be deleted.
Bay „B Bay (field side)“ (unit view)

The field side is initially empty. The field distribution is set up in the follow-
ing work step – thus producing the terminal strip for the field side, likewise
via an assembly group.
Marshalling between the bays

The marshalling cannot be done yet because the field side has not been filled
yet.
64.7.2.6 Field distributor

A field location must be created before you can start with the field distribu-
tion: do this by going to the Locations tab and creating a field location under-
neath the building that had been created in SECTION 64.7.2.1: PLANNING THE
LOCATION STRUCTURE:
| NEW | 02 FIELD LOCATION.
The field location takes in the field distribution.
64.7.2.6.1 Linking the unit and location views through pointers

First of all, all the field devices are collected at one location. This can be done
in one of two ways.
1st way: Bulk processing

| EXTRA | BULK PROCESSING| BULK PROCESSING FOR PLANNING OBJECTS
The Class field is left at the Device entry.

Drag the sub-unit from the Units tab into the Start object(s) field. You now
get a big list in the actual planning data. It can take a while until the list is com-
plete. The list still has to be filtered:
The filter can be set on the “Don’t place ” text. Since the field objects cannot
be placed on the loop diagrams, they should be managed in such a way that
the AREANAME attribute in the base data is set to Don’t place . Instead of
setting the filter, you can also search for field objects with a specific base
object, for example, base object ET|D|B|A Sensors.
On the left-hand side of the bulk processing, mark all the objects that are to
be collected together in one location.
Switch within the Navigator to the Locations tab and there search the field
location that has just been created. Drag the location object on the right-hand
side of the bulk processing into the Location field:
Effect:
All the objects in the right-hand window that are marked are given this loca-
tion as a pointer. This means that references to these objects are now collected
together in the field location, and this makes the objects easier to work with
subsequently.

2nd way: Query “QDev1 Devices with location”

Create the query QDev1 Devices with location via the mouse menu of the
EE/I&C folder. This query finds all the devices located underneath the
EE/I&C folder and shows whether they possess a location pointer, and if so,
to which location..
Next, switch within the Navigator to the Locations tab and drag the desired
field location into the Location column of a field object:
The field object is automatically given a location pointer to the field location.
A reference to the object now appears underneath the field location.
Warning: The pointer must be confirmed by pressing the [APPLY] or [OK] but-
ton before it is written to the database. If it was not saved, the setting of the
pointer can be undone by pressing the [CANCEL] button.
You can also mark multiple field objects at the same time. They then all get
the same location pointer.
64.7.2.6.2 Creating the field distributor
Determining the bill of quantities

Before you can create the field distributor, you must determine how many
field terminals are needed. This can be done by means of a bill of quantities.
The rule of thumb is as follows: you can use the number that you determined
for the measuring transducers and multiply it by 2 (because in the Comos stan-
dard model each measuring transducer uses two field terminals).

Instead of the bill of quantities, you can also use the Devices with location
query and configure the search parameters in the same way as for the bulk
processing.
Terminal strips have been prepared ready for use in the mouse menu of the
field location object:
| A FIELD DISTRIBUTOR | 01 EXI-FIELD DISTRIBUTOR and | 02 EXE-FIELD DISTRIBU-
TOR
A general terminal strip with 20 terminals.
| C1 ASSEMBLY GROUPS| 01 TERMINAL STRIP (20) and | 02 FIELD + JUMPER DISTRI-
BUTOR (20)
An assembly group with 20 terminals .
Select the ... | 02 FIELD + JUMPER DISTRIBUTOR (20) assembly group to continue
this example:
20 terminals, a master cable, and in addition a folder called 51 MC bay

(Field) will be created.
64.7.2.6.3 Carrying out the marshalling
Resolving the “MC bay (Field)” folder

This step is very simple if the assembly group has been used before.
In the 51 MC bay (Field) folder you can find a terminal strip that has been
wired to the field distributor. This terminal strip is cut out and then pasted into
the Marshaling cabinet in the B Bay (Field) bay . The wiring is thus retained.

It looks as follows in the overview:
And this is the best way to do it:

• Right-click on the 51 MC bay (field) folder and select | TEAR OFF.
• Open the Navigator tree up to the desired distributor control cabinet.
• Click in the additional Navigator on the terminal strip and select | CUT.
• Click in the Navigator on the B bay (field side) object and select | PASTE.
• The empty folder 51 MC bay(field) can now be deleted.
The marshalling cabinet has now been filled completely and can be wired
(marshalled).
2. Leading the terminal strip to the unit

The terminal strip that was created in SECTION 64.7.2.6.2: CREATING THE FIELD DIS-
TRIBUTOR under the field location is still there in the field location but it needs
to be wired to the field devices. Do this by opening the properties of the ter-
minal strip and switching to the Strip tab.

Since the field devices possess a pointer to the field location, references to the
field devices are displayed underneath the field location in the Navigator.
Click on a field device and its channel and now drag the connectors of the
device channel into the left-hand column Connected with of the Strip tab:
The connectors can also be connected directly in the Navigator: simply drag
the connectors of the channels onto the free I-connectors of the terminal strip.
Please note: The field devices and their channels should already have been
implemented at this point in time. If you wire the requests objects to the ter-
minal strip and set an implementation at the request object at a later point in
time, the implementation objects do not accept the wiring.
64.7.3 Marshalling management
Plugin bar, icon [MARSHALLING MANAGEMENT]
Principle of the marshalling manager

The marshalling manager is the logical continuation of the previous work
steps.
Measuring transducers and a request object for a controller were created under
a signal in SECTION 64.7.1.2.2: WORKING WITH ASSEMBLY GROUPS: “ASSEMBLY GROUPS
(SIGNALS WITH CHANNELS)” or SECTION 64.7.1.2.3: CREATING SIGNALS AND DEVICE
REQUESTS MANUALLY. Thus the “start” and the “end” of the loop have already
been determined. These objects under the signal inherit the signal itself (via
Signal of owner ).
In subsequent work steps the intermediate stages were completed: starting
from the “end” - the controller, the ex-protection, the marshaling panel and
the field distribution were created (SECTION 64.7.2.3: CONTROL SYSTEM,
SECTION 64.7.2.4: EX-PROTECTION CONTROL CABINET, SECTION 64.7.2.5: MARSHALLING
CABINET). Each time the objects that have just been created automatically
inherit the signal from the previous work step.

Now the loop has reached marshalling “from both sides”, and the signal infor-
mation is available “from both sides”. All the objects that are required are col-
lected in the Marshaling panel object in the bays.
The marshalling manager thus only needs to investigate one marshalling cab-
inet, where it recognizes objects with the same signals and offers these for
connection.
Procedure
Drag a marshalling cabinet into the Below object field:
The signals appear in the left-hand window area. If you click on a signal, then
the objects that possess this signal appear at the right.
All you have left to do is to click on the open connection in the marshalling
bays and to select [CLOSE].
64.7.4 Assigning product data
The “assign product data” work step belongs as a rule to EE and hence it is
described in SECTION 59.7.3: PRODUCT DATA AND REAL DEVICES. Here is just a brief
summary:
The device structure in the base data has three levels:
• Type, e.g., depending on the measurement procedure

These objects possess the Request property.

• Root objects of the manufacturer

These objects are created without the “Request” property, hence they are
real devices.
• The real devices of the manufacturer.
The request attributes are collected with the position sheet (“PDAF.1 Position
sheet”, P. 64-30) and so a manufacturer query can be prepared. If an actual con-
crete device is finally ordered, the data of this device is maintained in Comos
as well.
This is done by first of all importing the base data of the manufacturer devices
into Comos (see SECTION 61.4: IMPORTING MANUFACTURER DEVICES).
After that the product data is assigned. The Device selection (product
data) dialog is provided for the user to make a selection from the real devices.
Call:
| EXTRA | DETAIL | DEVICE SELECTION (PRODUCT DATA)
See SECTION 61.6.2: SELECTION OF MANUFACTURER DEVICES.
Alternatively, a query is started by means of the following icon in the Proper-
ties window of a planning object so that a device can be selected:

Mounting catalog I&C sub-module
64.8 Mounting catalog
64.8.1 General
The mounting planning is made considerably easier if a customer-specific

mounting catalog is available. In the standard database there is an example of
just such a catalog: ET I&C, ELECTRICAL ENGINEERING | B MOUNTING:
The catalog should be modified by the administrator to suit your own special
requests and needs.
The designations in the present mounting catalog are in the first instance arbi-
trary and should likewise be modified as required. However, the important
thing is to maintain the general structure of the catalog within the customiz-
ing. Otherwise the functionality cannot be guaranteed!

I&C sub-module Mounting catalog
64.8.2 Constituent parts
The present mounting catalog is an example for a number of mounting objects

that can be structured from any desired point of view.
Mounting objects
Mounting objects are located in the base data underneath ET| B| B Moun-
ting catalog.
Mounting objects possess a IC071 Mounting comment tab which contains

special mounting instructions. They are output in Evaluation Report PPCA
Hook Up .
Individual or collective evaluations can be made of the mounting objects. (See
SECTION 64.8.3.1: “PPCA HOOK-UP” (MOUNTING DRAWING) and SECTION 64.8.3.2: “PPCB
HOOK-UPS WITH POSITIONS”.)
Mounting objects are created underneath functions – parallel to the device

whose mounting information they encapsulate. In the standard database
mounting objects for pressure measurement functions have been provided as
an example.
Mounting accessories
Mounting accessories are located in the base data underneath ET| B| Z
Mounting accessories.

Mounting objects consist of multiple components – the mounting accessories.

Each mounting object possesses precisely those components that are required
to mount the relevant object. The components are elements of the mounting
object. In the standard database each mounting accessory is an element of the
mounting object. It is created automatically underneath the mounting object.
The manufacturer data is input on the IC070 Manufacturer data tab of the
mounting accessories.
Expense objects
Each mounting accessory possesses an expense object. The expense object is
an element of the mounting accessory and is created automatically underneath
it.
It possesses the IC080 Mounting expense tab, on which the mounting
expenses are input.
Although expense objects work together with the mounting catalog, they are
in a branch of their own on the base data side:
ET| C| Expense.
See also SECTION 64.8.4: MOUNTING EXPENSES.

Here is an example of the structure of the objects and their tabs:
Tabs or attributes that are added individually must be taken into consideration
accordingly in the Evaluation Reports.
Please note: as is usual, the base data is also set up by means of base object
references. The original tabs can thus exist in an entirely different place within
the structure tree. The simplest way to get to the originals is to use the
| NAVIGATE menu item of the context-sensitive mouse menu.

64.8.3 Documents folder PPC Parts list, Hook Up
Available in:
Base project, Documents tab,
CRP Report templates | IC Reports I&C | PPC Parts list, Hook
Up
The standard database is set up in such a way that the reports are created auto-
matically.
64.8.3.1 “PPCA Hook-Up” (mounting drawing)

This Evaluation Report is created automatically underneath the mounting
object.

64.8.3.1.1 Overview
Document PPCA Hook-Up consists of three separate areas:
2
Material lists area
Hook-up drawing
3
Field for special mounting
instructions
1. Area for the Hook-Up drawing.

Here the symbol (diagram type HOOKUP) of the associated mounting
object is displayed through a script routine of the report template.
2. Material lists area
Here the report template sets up a current material list of all the materials
used in this hook-up by means of a query using a script routine.
3. Field for special mounting instructions
Text information is displayed, for example, warning notes, special
mounting stipulations, etc. They are taken from the ICM102 Mounting
note attribute on the Mounting comment tab of the owner object
(Document.Owner) of the report, hence from the mounting object, by a
script routine of the report template.
64.8.3.1.2 Hook-Up graphic

Example: Hook-Up graphic for an electrical pressure transmitter:

The above illustration shows the graphic that was stored in the base project
within the base object of the mounting instruction for diagram type HOOKUP
on the Symbols tab. Changes to the graphic can only be made there. Details
on the operation of the Symbol editor and on symbols in script form can be
found in SECTION 45: SYMBOL-DESIGNER. The individual mounting elements are
identified by their display number, which is input manually in the Symbol edi-
tor and must match the name of the mounting elements.

64.8.3.1.3 Material list
2 2
1
3
Pic. 64-1: Material list for an electrical pressure transmitter

PIC. 64-1: shows the material list belonging to the Hook-Up, which contains all
the mounting elements, sorted by the display number entered under Name .
Identical mounting elements and the attribute values of attributes with the
same names are added. The number of identical mounting elements appear in
the Quantity column.
Pic. 64-2: Equipment expense, mounting expense and length

If attribute values and expense objects with attribute values (PIC. 64-2:) have
been assigned to the mounting elements, these appear in the list and are
totalled accordingly (PIC. 64-1:, 1, 2). In this the total prices for the relevant
Hook-Up can be determined automatically (PIC. 64-3:, 3).
64.8.3.1.4 Mounting texts

Follwing the list comes the description of the Hook-Up. The descriptive text
is taken from the description (Description) of the owner object
(Document.Owner) via the script of the report template. Next to this appear
the mounting comments that were taken from the Mounting notes attribute
from the Mounting comments tab - given that mounting comments were
input to that attribute.

Pic. 64-3: Input of mounting comments

Short texts can be written directly into the textfield of the attribute, while
longer texts should be entered in the pop-up window. The texts that have been
input there are not formatted automatically, nor are there any line breaks. It is
therefore advisable not to let the individual lines of text get too long, since
otherwise they would stick out beyond the edge of the report and not all the
text would be printed out as a result.
64.8.3.2 “PPCB Hook-Ups with positions”

This Evaluation Report is created automatically in the Documents folder of
The report automatically searches all Hook-Ups in the hierarchical sub-struc-
ture of the owner object (Document.Owner) of the document and displays
them in collected form. This summarizes Hook-Ups that are the same, mean-
ing that only one graphic and one material list appear. The various positions
appear next at the material list. The document is updated automatically, in the
same way as with all other Evaluation Reports, each time that it is opened or
else by pressing a button, and this greatly simplifies the current overview and
the output of Hook-Ups in complex unit structures.

List of positions
64.8.3.3 “PPCC parts list evaluation (mounting accessories)”

This Evaluation Report is created automatically in the Documents folder of
This document automatically searches for all Hook-Up documents in the hier-
archical sub-structure of the owner object (Document.Owner) of the docu-
ment, evaluates the parts lists that are created there, and totals up the
quantities and the expenses for equipment and mounting.
Abb. 64-1 Evaluation of the parts lists underneath the document owner

A cost control per position or also per unit can be quickly and easily produced
with this document.
64.8.4 Mounting expenses
64.8.4.1 Mounting expense object

In order to able to automatically determine mounting expenses unit or location
view wide, an expenses object is required that is assigned to each individual
object to be mounted. This object is located in the base data view under
ET | C EXPENSE | 01 HOOK-UP ACCESSORY EXPENSE. This object makes available
the Mounting expense specification tab that can be edited in the planning
view, whose Equipment expense and Mounting expense attributes are
evaluated by the reports that have already been described.
The original of the tab is located in the base data view under node
ET | Y ATTRIBUTES CATALOG | C EXPENSE | IC080 and for preference should be
edited and extended there.
64.8.4.2 Determination of quantities and expenses

This is how to proceed to achieve an automated determination of the expenses
and quantities:
1. Use a mounting catalog:
Design and configure a new catalog
or else revise the one supplied to suit your own needs.
2. Use an expense object:
The same applies here as well, you should either use the existing expense
object and modify it to suit your needs or else create a completely new one
from scratch.
3. Provide all the required elements of the mounting objects with the
necessary objects, characteristics (attributes) and values.
4. Provide the function objects with the associated mounting objects.

Interfaces I&C sub-module
5. Provide the function and position objects with the corresponding

documents (SECTION 64.8.3: DOCUMENTS FOLDER PPC PARTS LIST, HOOK UP).
The preparations listed above should be done on the base data side in the base
project so as to make them available globally (in all projects).
6. Plan your units in the planning project by using the above-mentioned.
objects.
7. Place the Evaluation Reports (PPCA-PPCC) directly underneath the
objects for which you require the evaluation for the sub-structure.
Update the report as required, and you are finished!
The result can now either be output directly or else via a printer connected to
the network.
64.9 Interfaces
64.9.1 S7/HW Config
See SECTION 64.7.2.3.1: S7 / HW CONFIG.
64.9.2 Process visualization
See SECTION 64.2.2.10.4: INCORPORATE PROCESS VISUALIZATION (WINCC, PVSS II).

Logical diagrams / functional diagrams The aim of logical diagrams
65 Logical diagrams / functional diagrams
65.1 The aim of logical diagrams

Logical diagrams, also known as function charts or function diagrams, pro-
vide a process-oriented graphic display of functions and controllers through a
form of display that is independent of the technical implementation.
For that reason a function chart is separated logically from the system envi-
ronment and communication with the environment (stipulated for the function
diagram) is done by means of defined inputs and outputs. These inputs and
outputs can be either of a logical or a functional nature. A functional input or
output thus corresponds as a rule to a measuring or control signal.
Typical areas of application for function charts are the illustration of PLC pro-
grams.
In Comos continuous function charts (CFC) are primarily used for the docu-
mentation of event-triggered systems. Under normal circumstances Comos
function charts are not intended to be used for process control; by default it is
not possible to generate controller code.
65.2 Base data and administration
65.2.1 Base object classes
Class Function
Displays the “function” planning task as an object. This class is used with
equal priority in the P&ID, EE/I&C and LD blocks, whereby the sub-classes
are not of interest in a logical diagram.
The signals are typically stored underneath the functions.
Class Functional component

Functional components are used to create a sequencer, namely, to plan the
controlling system of the functional chart. Functional chart uses the sub-
classes Action block , Step and Transition .
Class Signal
Displays the “signal” planning task as an object. This class is used with equal
priority in the EE/I&C and FD blocks.

Base data and administration Logical diagrams / functional diagrams
Base project:
• @1FP
@H|AA|AC|01 step type
Distinguishes between the initial step and the (“normal”) steps.
Application in:
@1FP | AA IEC1131-3 | AC sequencer | 01 step
Used on the Step parameters tab. Effect: Another symbol is shown by
means of graphically-relevant attributes.
@H|AA|AC|02 Priority
Application in:
@1FP | AA IEC1131-3 | AC sequencer | 02 Transition
Used on the Transition parameters tab.
@SYS ...
...@Sys | A001 | A001001 Definition mark IEC | 03 Action
block
Application in:
@1FP | AA | AC | 03
Under it is an element. The standard table on the Layout tab is used in this
element.
...@Sys | F001
Application in:
@1FP | AA | AD | A
@1FP | AA | AD | C
Is used on the Layout tab. Effect: A corresponding symbol is switched in,
depending on the setting.
...@Sys | F002 ...
| F002 | F002002001: Application in:

@1FP | AA IEC1131-3 | AD | S
Is used on the SplitRange tab, Characteristic line type attribute.
Effect: The symbol is changed, depending on the setting.
| F002 | F002_001:
Application in:
@1FP | AA IEC1131-3 | AD | C
Is used on the Regulator tab (or Controller tab), Regulator (controller)
type attribute.

Logical diagrams / functional diagrams Base data and administration
FUP Type
Application in:
@O | PF | PFPC
• @F Functions
Is used in base object @F Functions on the tabs.
• @S Signals
Is used in base object @S Signals on the tabs.
• @1EM Catalog MCR | F001 Function | ...
Application in:
@F Functions |A1 Neutral functions | 01 Measurement functions
Is used on the Function data measuring point tab.
System project
• @ConnectionTypeF Connection types function blocks
Defines the thickness and type of the connecting lines.
• @ConnectionTypeS Connection types signals
Defines the data types. Connectors are created in the base object and
selected from the Properties window of connectors of type “Signal ”. All
connectors (= data types) that are then allocated in the next step via standard
table @ConnectionPossibleS are defined here.
Example:
In @ConnectionPossibleS it states that connector ANY_DATE is allowed to
be connected to DATE, TIME_OF_DAY and DATE_AND_TIME.
In @ConnectionTypeS these four entries ANY_DATE, DATE, TIME_OF_DAY
and DATE_AND_TIME are located in a flat manner under one one another.
• @ConnectionTypeS | @ConnectionPossibleS
Supplementary list for ConnectionTypeS. Value 1 and value 2 stipulate
what is allowed to be connected.
Identical sub-types may always be connected together, even if they have
not been explicitly listed in @ConnectionPossibleS.
65.2.3 Document objects
• @O Documents | PF | PFPC
Application in:
AWR Evaluation Reports | PFP |PFPC

Base data and administration Logical diagrams / functional diagrams
65.2.4 Report templates
65.2.4.1 Ready-made report templates

AWR Evaluation Reports | PFP Signal list
These Evaluation Reports are based on preconfigured object queries that are
located underneath the relevant reports.
| IAR INTERACTIVE REPORTS | PFF
Ready-made reports for IEC. The reports have their own symbol bars. See
also SECTION 65.4.2: FUNCTION BLOCKS FOR IEC.
65.2.4.2 The options script for a function diagram
Application = “FUP”
The following entry should be made in the options script of the report tem-
plate:
Application = “FUP”
Effect:
• Drag & drop behavior
When base objects are dragged onto the report, the generated planning
objects are created underneath the report (and not in parallel, as in the EE
report).
• Endless diagrams
Function charts are endless diagrams that have been split up visually. As a
result of the splitting up (for example, into DIN A4 areas) it is easier to tell
what a hard copy printout would look like. The user then sees all the DIN
A4 sheets in order, one after another.
Whwn you draw on function diagrams, the user can to all intents and
purposes ignore this sub-division into, for example, DIN A4 sheets. The
user simply draws connections across the boundaries of the sheets. The
connection is separated into connections across the pages that have the
relevant cross-references.
Function chart-specific variables

The crp template files for function diagrams initially contain general com-
mands that are identical to the command set for detail plans. The variables that
are only required for function charts are given in section FUP Specific
variables.
''' FUP or CFC-specific variables

Logical diagrams / functional diagrams Base data and administration
SignalLeft_X = 12
SignalRight_X = 276
SignalTop_Y = 8
SignalSlot_Count = 21
SignalSlot_Height = 8
SignalWidth = 48
SignalWidth1 = 24
SignalLeft_X stipulates how many mm away a symbol is to be placed from

the left edge when placing is done to the left.
SignalRight_X likewise stipulates how many mm away a symbol is to be
placed from the right edge when placing is done to the right.
SignalTop_Y stipulates where the first slot begins.
Variable SignalSlot_Count then stipulates the number of slots.
The height of the signal symbols and the snap-to grid of the signals are stipu-
lated by SignalSlot_Height. This value should match the graphic dispay of
the slots in the crp file. It would be confusing if the slots were marked with a
height of 8 mm, but if, for example, the symbols were working with 12 mm.
The total width of the signal above all the graphic elements is defined by
SignalWidth, while SignalWidth1 defines the width of the blocks within
the page. Logically enough, SignalWidth1 must be considerably smaller
than SignalWidth.
SignalWidth1
SignalWidth
Pic. 65-1: The variables for the width of a signal symbol
Please note that some of the options script commands are only meaningful
when using automatic symbols, such as SignalWidth and SignalWidth1.
See SECTION 65.3.3: AUTOMATIC SYMBOLS FOR INPUTS AND OUTPUTS.
Standard-specific variables
There are options script commands that are used to control a specific standard.
These commands are likewise dealt with in SECTION 65.4.2: FUNCTION BLOCKS FOR
IEC and SECTION 65.4.3: FUNCTION BLOCKS FOR VGB.

Inputs and outputs (signals) Logical diagrams / functional diagrams
65.2.5 Base object libraries
@1FP | @Template
See SECTION 65.4.2: FUNCTION BLOCKS FOR IEC.
@1FP | AA IEC1131-3
See SECTION 65.4.2: FUNCTION BLOCKS FOR IEC.
@1FP | AB VGB - R 170 C
See SECTION 65.4.3: FUNCTION BLOCKS FOR VGB.
65.3 Inputs and outputs (signals)
65.3.1 The slots
The inputs and outputs of function diagrams (continuous function charts) in

Comos are organized by means of “slots”.
Slot: Placing area for a signal.
In Comos function diagrams, signals are the inputs and outputs of the control-
ling system. The signals are always placed at the left-hand or right-hand edge
of the function diagrams.
Thus the number of slots limits the number of signals (and thus the number of
inputs and outputs) that can be placed. The function diagrams are often distin-
guished between according to the number of slots so that the user can tell visu-
ally how many signals need to be placed here.
When you drag a signal of type Signal from the base objects or a planning
object onto the diagram, you are shown by means of a symbol where the
object will be placed if you release the left mouse button at that moment.
You can move the symbol as long as you hold down the mouse button: the
symbol jumps from slot to slot. With many signals you have the option to
place the signal to the left or to the right. The symbol changes according to
whether it is placed to the left or to the right.
In this way a Hardware output could also be placed as a Hardware input .
But please note that only the symbols are swapped over, while the texts are
determined by the corresponding entries at the planning object! If you have
created a Hardware Ouput planning object and then place it as Hardware
Input , the old text will continue to be shown, which might well be meaning-
less for a Hardware input .

Logical diagrams / functional diagrams Inputs and outputs (signals)
65.3.2 Diagram type-specific symbols for inputs and outputs
You can find the objects for the signals in the base data under @S Signal.
These signal objects can have a symbol of their own allocated to them. Thus
you can allocate symbols of their own to the signals for a specific type of dia-
gram such as for IEC or VGB.
Please note that the origin of the symbol must be defined in the lower left-
hand corner of the symbol so that the input/output switching and slot detection
function.
If no symbols of their own have been allocated to to the signals, then the auto-
matic symbols are used, see the next section.
65.3.3 Automatic symbols for inputs and outputs
65.3.3.1 Signals: Ready-made objects in the default database

You can find the objects for the signals in the base data under @S Signal.
These objects are all of type Signal . There is no detail class, the distinction
being made with the help of attributes. The attributes are normally collected
on the two Specifications tabs : System data and Signal data .
System data
The system data is required so that the signals can communicate cleanly with
with other Comos objects. The system data primarily includes:
• IOA Signal type linked to standard table @S Signals | S002 Signal
type.
The signal type controls the symbol in the event that the automatic signal
symbols are used, see SECTION 65.3.3: AUTOMATIC SYMBOLS FOR INPUTS AND
OUTPUTS. In addition, the signal type controls the technical functionality of
the signal.
• S02 Data types links to standard table @S Signals | S02 Data types.
The data type of the signal also determines what type of connectors can be
selected.
Signal data
In the case of the signal data, all the information that additionally describes
the signal but is not evaluated internally within the system is collected
together. Examples:
@S Signals | S003 Operand type.

@S Signals | S004 Connection type

@S Signals | S005 Signal form.
@S Signals | S006 Signal level.
65.3.3.2 Overview of the default signals
A Hardware input
This function diagram signal embodies as a rule a physical (measuring) signal
that runs into an I/O card and is further processed there by the software. These
signals are located as rule in the planning project under the position. This
means that the signal that is used in a function diagram had already been cre-
ated in the detailed planning when wiring the position.
B Hardware output
This function diagram signal embodies as a rule a physical (measuring) signal
that was sent from an I/O card and is further processed there by the software.
These signals are located as rule in the planning project under the position.
This means that the signal that is used in a function diagram had already been
created in the detailed planning when wiring the position.
C Software input
This function diagram signal usually represents a communication signal to a
higher or parallel level. Communication signals of this type are transported
over a data bus as a rule.
D Software output
This function diagram signal usually represents a communication signal to a
higher or parallel level. Communication signals of this type are transported
over a data bus as a rule.
E Variable input
A function diagram signal of type Variable is not intended to depict hardware
signals (from plant design), but instead illustrates an information module of
the controller.
F Variable output
A function diagram signal of type Variable is not intended to depict hardware
signals (from plant design), but instead illustrates an information module of
the controller.

Z Break
Break signals are used to distribute a function diagram over multiple Interac-
tive Reports. Thus the function of break signals is comparable with that of pair
references in detail diagrams.
Break signals possess a 1-to-n link: A break signal can be continued onto n
diagrams. A continued break signal can only have one source, no more or less.
65.3.3.3 Display of function diagram signals in Comos

Function diagram signals are distinguished between on the basis of the type
of the symbol and the information that is written to the symbol at the function
diagram. There are six text variables that can usually occur with a signal:
1: Device tag 3: Label 5: Element
2: Cross-Ref. 4: Descr. 6: Implement.

Pic. 65-2: The text variables for a function diagram signal
1: Device tag Device tag

The device tag is always calculated within Comos with
the AliasFullLabelWithoutFolder function, i.e., units
labelled as a folder are not taken into consideration
within the device tag. The display depends on the
separators set within the project options.
2: Cross-Ref Cross-reference
You can tell by means of a cross-reference from which
function diagram this signal was taken.
3: Label Label
If no label had been input for the object, the name is
displayed instead.
4: Descr. Description
In the default data model all the base objects of the
signals already possess a description . If no description
of its own had been input in the planning object, this
initial description (inherited from the base object) is
displayed instead.
Table 65-3: Meaning of the text variables of a function diagram signal

5: Element Element
When an implementation is made, the name of the
implemented element is entered here.
6: Implement. Implementation
If the implementation pointer in the planning object was
set by drag & drop (that is not the location pointer!),
them the corresponding details are given at this point.
Table 65-3: Meaning of the text variables of a function diagram signal
For example, a signal of type Hardware output with fully set text variables and
placed on the left on a diagram would look like the following:
7
Unit.PUnit1.Pos1. Data point 1 S5
8
FD.2/9 Signal =SP-K1
9
Pic. 65-4: Example for a function diagram signal placed on the left
The following symbol variants are provided:
Basic symbol
Hardware input, placed on the left
Hardware output, placed on the left
Software input, placed on the left
Software output, placed on the right
Variable input, placed on the left
Table 65-5: Symbol variants in the case of function diagram signals

Variable output, placed on the right
Break
Table 65-5: Symbol variants in the case of function diagram signals
Please bear in mind that the majority of signal types can be placed either to
the left or the right and then the relevant symbols are mirrored horizontally.
The positions of the text variables can be swapped accordingly.
Automatic stymbols are also controlled by means of options script com-
mands, as for example SignalWidth and SignalWidth1. See SECTION 65.2.4.2:
THE OPTIONS SCRIPT FOR A FUNCTION DIAGRAM.
65.3.3.4 Automatic connector breaks

Signals possess a number of different connector options, depending on their
type. The breaks are of a special nature here.
Breaks have a connector in their basic state. Since break can form a 1-to-n
relation, additional connectors are created at the object as required. If you
position the break signal (planning object) on a further report, an additional
connector is added in the database.
65.3.4 Navigation options
Please note that signals can also have a comprehensive range of Navigation
options in the same way as for other report objects. Right-click on the signal
and select one of the commands from the | NAVIGATE menu.

Control system at the function diagram Logical diagrams / functional diagrams
65.4 Control system at the function diagram
65.4.1 Function blocks general
65.4.1.1 Layout of the function blocks
Text variables
All function blocks contain text variables. The text variables differ according
to the symbol and can be understood intuitively: thus connectors have their
matching counterpart connectors, objects have their label and description, etc.
If you wish to know in certain situations the exact programming definition of
a text variable, just right-click on the symbol and select | EDIT SYMBOL. The
definition of the text variables, among other things, is also shown in the Sym-
bol editor .
Changing symbols locally

You can also further modify the symbols on the diagram in the usual way: you
can move and rotate the text and rotate the symbol. If the symbol is rotated
with text that has not been changed, the text is adapted automatically so that
it is not on its side or upside down.
Placing function blocks

The function blocks are sorted and can be dragged onto the report from either
the base data or the planning data.
65.4.1.2 Function blocks: Ready-made objects in the default database

There are three main groups in the base database:
AA IEC1131-3 (mathematical functions)
AB VGB - R 170 C (logical functions)
AC FBs In this branch are the function blocks with special capabilities, and in
particular the function blocks with detail logical diagrams.
Please note: The base objects AC FB are not currently included in the default
database. Please ask your customer support representative.
When these function blocks are created in the planning project, a detail logical
components report is located under the planning object. This report itself is in
turn a function diagram. The function diagram for the detail components is

Logical diagrams / functional diagrams Control system at the function diagram
automatically given the existing inputs and outputs of the function block. The
inputs and outputs can be moved as desired. The function diagram for the
detail components can be used in the usual way.
65.4.1.3 The blackbox

The default blackbox without script is located in @1EA Catalog ET | @O
Other base objects | @BB Blackbox, automatic contacts.
Many of the usual objects have already been defined beforehand in the base
data. At the beginning of the function diagram planning you perhaps may not
know yet which object you will require; in that case you can use a blackbox .
This function block has a number of special properties.
The connectors are not defined beforehand but are only created in the course
of the planning. When you come into the vicinity of the blackbox with the
connection tool, you are offered a possible connector anywhere around the
entire external side of the blackbox. When you confirm this by left-clicking,
the connector is created both on the diagram and also in the database.
As soon as you know which function block is to be installed, you can open the
properties mask of the blackbox and set a new base object. The connections
remain as they were, as far as is possible technically. For example, the number
of connectors at the blackbox must be less than the number of connector
points at the function block, since most of the predefined function blocks have
a fixed number of connectors.
65.4.1.4 Connecting function blocks

You can connect the signals and function blocks in the usual way with the
connection tool. The connector points are found automatically.
65.4.2 Function blocks for IEC
Base data
@1FP | AA IEC1131-3
@S Signals | @IEC Signals by IEC 1175

The signals are also offered in the context-sensitive menu for the function.
@1FP | @Template
Contains templates that are offered in the | NEW mouse menu.

Control system at the function diagram Logical diagrams / functional diagrams
You should think carefully about the use of templates in the function diagram,
since in practise parts of the planning structure often exist already. Thus,for
example, the signals have often already been created by the time that work
starts on the function diagram. It is necessary to prevent losing such work that
has already been done through the use of templates later.
There are ready-made report templates for IEC, see SECTION 65.2.4: REPORT TEM-
PLATES.
Options script: Symbol type = “FUP_IEC”
Connectors for IEC

The connectors of the block are marked by rectangles pointing inwards. These
additional graphics are not shown in hard copy printout.
IEC recognizes function blocks with an indefinite number of connectors.
Such blocks are also predefined in Comos with a variable number of connec-
tors: the user can determine the number of connectors flexibly. Examples:
AA IEC1131-3 |AA Default functions |400 Bit mode -401 AND
AA IEC1131-3 |AA Default functions |400 Bit mode -402OR
AA IEC1131-3 |AA Default functions |500 selection and compari-
son 505 MUX multiplexer
AA IEC1131-3 |AC sequencer |04 Simultaneous branching
This is done by means of a grab point, by which the size of the function block
can be changed. This grab point becomes visible when the symbol is marked
twice. Depending on the size, connectors are generated automatically with
grid spacing “four”.
Layout of the symbols

IEC symbols have connectors to the left and right.
Checking of automatic connections

In the case of IEC, when planning in the form of sequencer, there is an auto-
matic safety function to ensure that a step and a transition always follow alter-
nately, starting from a signal. The termination is always formed by an action
block. The system prevents any other form of switching of the objects.
There are special connectors to the base objects to this end:
Transition:
Input; step
Output; transition

Logical diagrams / functional diagrams Evaluation
Step:
Input; Transition
Output; step
Output action block
The following checks are made when connecting:
• Only identical sub-types may be connected, thus only connector sub-type
transition to connector sub-type step and vice versa.
• An input must be connected to an output, and vice versa.
Both checks together ensure that the transition and step objects must always
be used alternately. The step can then be terminated with an action block.
65.4.3 Function blocks for VGB

@1FP |AB VGB -R 170 C
Options script: Symbol type = “VGB”
Layout of the symbols

VGB symbols have connectors above and below.
VGBConnectionLength
In logical diagrams in conformity with VGB connecting lines are not pro-
duced fully. Instead, as a rule only the vertical part of the connection is pro-
duced fully and the horizontal part is marked by a hyphen.
The variable VGBConnectionLength that is input in the options script of a
report template controls the length of this horizontal line (hyphen).
65.5 Evaluation
The ready-made reports correspond to the ready-made report templates, see
SECTION 65.2.4: REPORT TEMPLATES.
65.6 Interfaces
Invensys: I/O series (Foxboro FoxCAE)
By means of base objects.

Interfaces Logical diagrams / functional diagrams
Siemens: SIEMATIC S7
See -> SECTION 56.3: SIMATIC S7 (EXPORT, IMPORT).
If S7 data had been imported into the EE/I&C, this can be processed further
in a function diagram.

PQM
66 PQM
PQM is covered in a separate documentation. For detailed information on
PQM, please open the PQM home page document from the Comos Help
menu.
Comos PQM (Project Quality Management) comprises:
• Version management DVM
Keywords: DVM, DQM, Version management, document import
See FD DVM.
• Extended User management
Keywords: USERS project, USER project, extended user management,
User objects, User planning objects
See FD Project USERS.
• Mail exchange
See FD Mail exchange.
• Dual Document Management (@Project/@NameSystem)
Keywords: Dual Document Management, @Project, Project revision, Unit
revision
See FD Project revision.
• Project management
• Meeting management
In addition, there are several functionalites that are linked to PQM (but are
licensed separately):
• eSign
See FD eSign.
• eStamp
See FD eStamp.
• Anonymous Data transfer
See FD Network login.

PQM

Index @S (base object signals) ...................... 65-7
@Sb_Pipeclass ...................................... 53-4
@SECTION ........................................... 63-6
@SETUP .......................................... 3-1, 3-6
Symbols @Setup ................................................... 6-17
"Devices with location" (query) ....... 64-61 @Status ................................................... 21-1
%N texts @StdImport ........................................... 2-11
- %N I% ............................................... 59-24 @Symbols ................................................ 2-7
- %N O% ............................................. 59-24
- standard table ..................................... 48-8 @Tree ................................................... 10-10
%N texts for function symbols ......... 57-38 @UNITMAPPING ............................... 11-6
*V*P S @WireColor ........................................ 31-13
- RI.ICF200* ....................................... 57-40 @WireCrossSection ............... 31-13, 31-14
- RI.ICF201* ....................................... 57-39 @Y Catalog attributes ................ 15-1, 16-8
*V*P texts .............................................. 53-8
@ Functions ........................................... 64-8
@3D branch ........................................... 53-4
@ALIAS ..................................... 13-2, 49-14
Numerics
@AREA .................................................. 48-9 1-to-1 reference ....................................... 8-6
@BridgeType ......................................... 31-8 1-to-n inheritance .................................... 7-1
@CONNECTION ............................... 48-10 3 level pipe structure .......................... 57-11
@ConnectionType 3D .......................................................... 16-19
- @ConnectionTypeE .......................... 31-1 3D Geometry tab ................................. 53-15
- @ConnectionTypeF .......................... 31-2 3D objects .............................................. 52-2
- @ConnectionTypeI ........................... 31-3
- @ConnectionTypeR ......................... 31-4
- @ConnectionTypeS .......................... 31-4
@DocumentTypeMapping ................ 40-15 A
@DRW_TYPE ...................................... 31-9
................................................................ 49-17
@DXF ..................................................... 35-9 Accept unit ............................... 16-15, 16-16
@ELO_KSP ......................................... 31-10
Access ................................... 3-1, 3-5, 24-23
@G (base object Document groups) .. 40-1 - Import ........................................ 33-1, 33-6
@G Document groups ........................ 64-12 Access to lists ...................................... 16-19
@IMP_ARROW ................................. 48-10 Accessory ............................................. 10-22
@IRF_Detail .......................................... 48-8 Account ................................................... 6-25
@IRF_RI .................................... 48-8, 57-50 Action .................................................... 10-14
@Layer ................................................... 6-12 - Decision tables .................................. 28-1
@LocalInstance ..................................... 20-3 Action block ............................. 10-18, 64-26
@MASK ..................................... 12-7, 48-10 Action columns (decision table) ......... 28-3
@NameSystem ...................................... 40-1 Action line ............................................ 57-52
@O (base object documents) ............ 49-21 Actions .................................................... 33-1
@PIPECONSYMBOL ....................... 48-11 Actuating function .............................. 57-20
@PIPEENDSYMBOL ....................... 57-50 - creation ............................................. 57-54
- mouse menu ..................................... 64-55
@Position ............................................... 64-5
Actuating signal .................................. 64-55
@PROPAR ............................................. 31-5
Actuator ................................................ 10-18
@R Revision .......................................... 41-1
Actuator (built-in part) (P&ID object
@REPORTS .................. 40-1, 40-14, 49-22 class) ..................................................... 57-20
@RGB_COLOUR .............................. 31-12 Actuator (P&ID object class) ............ 57-20
© 2006 innotec GmbH I-1

Administrator ............................................6-1 - preferred assembly groups (signals with
ADO .........................................................33-1 channels) 64-51
- signals with channels .........64-10, 64-18,
Alarm display .......................................57-40 64-51
Alias .......................................................49-15 Assign object ........................................57-19
- Alias pointer ........................................13-2
Assign product data .............................64-76
- AliasFullLableWithoutFolder ..........65-9
- Property .............................................49-15 Assignment manager ..........................64-59
Alias for labels atb files ......................................................2-6
- Icon .....................................................49-17 Attribute ....................................10-22, 45-33
Alias functionality - definition .............................................15-1
- activate ...............................................49-17 Attribute ((text parameter) ...................46-8
- Object structure ................................49-15 Attribute for
Align ......................................................43-15 - Document ..........................................46-35
All projects (usage) .............................12-32 - Object ................................................46-35
AllMyReferences ...................................45-8 - Project ................................................46-35
Allocate rights (right) ..............................6-7 Attributes ................................................19-1
- deletion (bulk processing) ................26-6
Allocate working areas .........................6-19 - querying ............................................25-19
Alternative labeling system ................49-14 Attributes catalog ..........50-7, 64-17, 64-27
Alternative user access ...........................3-2 Attributes via drag & drop .........15-7, 43-3
Always use linked value .....................16-16 AutoAlign .............................................47-20
Anchor .....................................................10-1 AutoCAD ................................................35-1
ANS standards ........................................5-19 - Exporting reports to ACAD .............35-1
ANSI ......................................................47-20 - import ................................................57-51
- Ansi1 ....................................................45-9 - Importing drawings ...........................35-4
- Ansi2 ....................................................45-9 - line thicknesses ................................46-22
- AnsiWiringRadius ...........................46-40 - Mapping ............................................46-22
Application ...............................46-40, 59-31 - PCP file .............................................46-22
- Place Windows metafile .................46-20
Approve revision (right) .........................6-7 AutoCAD drawing (Properties window) ..
AREANAME ... 64-9, 64-28, 64-45, 64-53, 14-6
64-63, ......................................................64-66 AutoConnect ............................64-42, 64-45
- standard table ....................................64-45
AutoConnectExternObjects ...46-40, 64-47
AreaNumber .........................................64-45
AutoConnectX .........................64-45, 64-46
Arrange tabs ............................................10-4
Autocorrection .....................................13-12
Article base data (def.) ..........................62-1
AutoDistributeTerminals .......46-41, 64-47
Article data (ExF) ................................62-12
AutoLoop ..................................64-42, 64-46
asc files ..................................................62-10
- AutoLoopCables ..............................46-41
ASPEN ....................................................50-7 - AutoLoopConnectorLayers ...........46-41
Aspen Pro ................................................51-1 - AutoLoopDebug ..............................46-41
Assembly ...............................................10-16 - AutoLoopFactor ...............................46-41
- AutoLoopFilter ................................46-41
Assembly group ...................................64-29 - Scriptoption AutoLoop ...................46-41
Assembly groups .....................64-64, 64-69 AutoLoopCable ...................................64-47
- DCS rack ...............................64-24, 64-64 AutoLoopCables ..................................64-45
- favorite assembly groups (signals with
channels) 64-10 AutoLoopConnectorLayers ...............64-46
- FD .........................................................64-6 AutoLoopFactor ...................................64-46
- field distributor .....................64-24, 64-73 AutoLoopFilter ........................64-41, 64-47
- functions with signals ......................64-19
- I&C .....................................................64-18 AutoLoopTerminalStrip .....................64-47
- motor control ....................................64-19 AutoMarkAsChanged .........................46-42
- motor controls .....................................64-6 Automatic Connecting ........................64-44
I-2 © 2006 innotec GmbH

Automatic connection ......................... 59-36 - creating ............................................... 49-3
Automatic generation... ...................... 57-47 - definition ............................................ 49-1
- in the broader sense ............................ 8-5
Automatic page number ....................... 40-3 - of report templates .......................... 49-22
Automatic Placing ............................... 64-42 - reference ............................................... 7-4
- search algorithm .............................. 64-43 - references ............................................. 8-5
- special cases ..................................... 64-44 - Setting up instances .......................... 20-2
Automatic reference creation .............. 40-5 - standard query ................................. 25-12
- Type Revision .................................... 41-1
Automatic referencing .......................... 40-5
Base Object (mouse menu) ................. 10-6
Automatic referencing of documents . 5-17
Base object for instances ..................... 20-1
Automatic separation .......................... 59-36
Base object for streams ...................... 57-46
Automatic value conversion .............. 19-14
Base objects (usage) ........................... 12-32
Automatically create hierarchy ........... 8-28
Base project ............................................ 49-1
Automatically created components
- creation sequence ............................ 53-63 Bay (control side) .................... 64-69, 64-70
Automatically generate name/device tag . Bay (field side) .................................... 64-70
13-3 Bay (Field) ........................................... 64-73
Autorouting BHD Drill data .................................... 63-10
- DESIGN diagrams .......................... 63-19 Bill of quantities .......... 64-61, 64-62, 64-72
AutoSaveDocument ............................ 46-42 Bird’s-eye view ..................................... 43-7
AutoStartLoop ......................... 46-42, 64-46 Blackbox ............................................... 10-15
AutoWatchRevisions .......................... 46-42 Blank source value .............................. 16-15
Auxiliary connectors ............................. 59-8 Block (create option) .......................... 12-11
AvTimeperCall ...................................... 3-25 Block for elements .............................. 12-19
Block object (right) ............................... 6-11
Block techniques (script) ................... 16-19
B Blocked ................................................... 6-24
Background ................................ 43-11, 46-1 BltPfd .................................................... 45-10
Background color BMK ..................................................... 49-14
- attributes ............................................ 19-14 BOOLEAN .......................................... 31-15
BackPointer branch table .......................................... 53-60
- BackPointerDevicesWithImplementatio BREADTH ........................................... 57-48
n (copy structure) 8-26 Break ..................................................... 10-17
- BackPointerDevicesWithLocation
(copy structure) 8-20 - Connection ......................................... 13-9
- Wires ..................................... 13-10, 13-12
- BackPointerDevicesWithUnit (copy
- Wires kept .......................................... 13-9
structure) 8-20
- Wires kept at the target .................... 13-9
- BackPointerDocsWithLocation ((copy
structure)) 8-20 Bridge .................................................... 64-44
- BackPointerDocsWithUnit (copy Bridgee
structure) 8-20 - changing type ................................... 59-67
bak file .................................................... 14-5 Bridges .................................................. 59-24
bak files ................................................... 30-2 Bulk processing ................................... 64-70
Base attribute ......................................... 16-9 - attributes ................................... 2-10, 26-6
Base data ................................................. 49-1 - base data ............................................. 2-10
- base objects ........................................ 26-6
Base data (right) ...................................... 6-8 - connectors .......................................... 26-7
Base list ................................................... 11-1 - Copy structure ................................... 8-17
Base lists ................................................. 11-1 - definition ............................................ 23-4
- deleting attributes .............................. 26-6
Base object - design mode ....................................... 26-6
- Change base object... ........................ 13-7 - documents ................................ 2-10, 26-7

- planning data .......................................2-10 CDI object classes .................................36-4
- planning objects .................................26-2 Cell index ..............................................16-14
- results list ............................................26-3
- setting attributes .................................26-6 Chain ..............................................5-20, 59-9
- start object ...........................................26-3 Chain -> Master .....................................59-9
Button ............................................16-2, 17-1 Change by rule .......................................58-3
By check (object test) ............................30-6 Change default object... ........................13-7
By own object link ..............................16-11 Change run case (mouse menu) ..........10-9
By owner (type of link) ......................16-11 Change static texts ...............................46-13
By save (object test) ..............................30-6 Channel .................................................64-22
By sync (object test) ..............................30-7 Channel request ...................................64-52
ByLevel .................................................10-10 Check (status) .........................................21-5
Check 3D / P&ID connections ............21-2
Check and Correct .................................30-9
C Check in ............................................7-2, 7-9
Check indexes ........................................3-18
C# .............................................................53-8
Check LogIn entries ..............................3-18
Cabinet ...................................................10-20
Check revision (right) .............................6-7
Cabinet diagram .....................................63-1
- autorouting ........................................63-19 Check validity (text masks) .................12-7
- Report templates auplan Checkbox ......................................16-2, 17-1
Reportvorlagen 63-12 Checkbox (spec script) .......................22-14
- standard tables ..................................63-11 CheckDelete ...........................................22-2
- symbols for views ..............................63-5 CheckDocObjects ................................46-43
- views ..........................................63-1, 63-3
- without view .......................................63-2 Checking
Cable ..........................................10-19, 59-59 - Indexes ................................................3-18
- Wires ..................................................13-12 CheckIOConsistency ..........................46-43
cable channel ........................................59-55 Checkobject (object test) ..........30-9, 30-10
Cable route ............................................10-21 CheckStatus ............................................21-4
CableObjectVersion ............................46-43 CheckStatus (script) ..............................22-2
Cables Child report ...........................................46-19
- Index ....................................................49-6 Childreport ............................................46-19
Cache Circle tool ...............................................43-9
- control ..................................................3-20 Class Element .........................................13-7
- entries ...................................................3-20
ClearCache .............................................3-24
cache ..............................................3-21, 3-23
CLink .................................................7-1, 7-4
CalcNextName .......................................22-2
CNameForNewObject ........................33-12
Calculate difference ...............................3-26
CObjectFullNameForPipe .....46-43, 57-46
CalculateLinkedSpecifications ..........16-15
Collections
Cards ......................................................64-62 - compare ...............................................8-39
Catalog attribute .....................................16-8 Collision ......................................21-2, 42-20
Catalog attribute (tab) ...........................15-7 COLOR .................................................57-48
Catalog attributes ...........................7-8, 15-1 Color
Catalog data PT ......................................50-4 - background color in attributes .......19-14
Categories .............................................57-10 Colors
Categories (flow diagrams) ................57-58 - color scheme text fields ..................19-14
Category ................................................10-15 - controlling the color in P&ID ........57-48
CDeviceFullName ...................46-11, 46-18 Colours
- Colored marking of the text frame 46-14
CDI ...........................................................36-1

- Coloring text ........................ 43-11, 47-15 - Paste .................................................. 13-10
- Colour (make column visible) ....... 13-10 - via nozzle .......................................... 57-33
- Colours and instances ....................... 20-2 Connection type .................................... 65-8
Column sequence (query) .................... 24-2 Connection with potential ................. 64-44
Column width (query) .......................... 24-4 ConnectionHook ..................... 46-44, 59-32
Columns ................................................ 13-10 Connection-independent .................... 59-56
COM Object viewer ............................ 12-30 ConnectionLineMode ......................... 46-44
Combobox .............................................. 17-2 ConnectionReference ......................... 59-32
Command line .......................................... 1-2 Connections
Comos Document Interface ................. 36-1 - Copy ...................................................... 8-4
Comos HOT-Line Support .................... 1-1 Connector ............................................. 10-16
Comos interfaces ......................... 39-1, 56-1 - Options .............................................. 64-57
- paste ................................................... 12-23
Comos pipe structure .......................... 57-11
Connector mapping .............................. 52-5
Comos system user ............................... 6-17
Connector points ................................... 53-8
comos.dll ................................... 12-30, 33-14
Connector table
Comos.mdb .............................................. 3-6 - sequence in Comos ......................... 53-63
COMOS_ISO ......................................... 53-1 Connector tool (reports) ....................... 47-1
ComosDevSpec ................................... 45-10 Connector.Label .................................. 12-20
ComosElmSpec ................................... 45-11 Connectors ............................................. 53-8
ComosObject ......................................... 36-5 - querying ............................................ 25-21
ComosReg ............................................ 30-12 - Tab ....................................................... 13-8
ComosSegSpec .................................... 45-12 - tab ...................................................... 12-20
- Working areas .................................... 6-16
ComosSpec ........................................... 45-13 Constituent parts of an object ............... 8-1
ComosWiresListIR ............................. 13-13
Contact mirror ..................................... 59-10
ComosXML object classes ................ 36-16
ContactMirror ...................................... 46-44
Compare collections ............................. 8-39 Contactor .............................................. 10-20
Comparing objects ................................ 8-35
Content .................................................. 36-17
Comparison only ................................. 16-15
content ..................................................... 36-4
Comparison only (attribute) ................ 19-8 ContentFix .................................. 36-7, 36-17
Component type .................................. 62-13
Context-sensitive mouse menu ........... 10-7
Compress Comos data .......................... 3-18
Control by means of attributes .......... 19-13
Compression .......................................... 3-18
Control cabinet diagram ...................... 63-1
- Access Mdb ........................................ 3-18
Control parameters ............................. 64-46
Computer (CVS) ................................... 3-26
Control system ..................................... 64-62
ConcessionRI ....................................... 46-43
Controlled data input .......................... 19-13
Condition columns (decision table) ... 28-2
ControlType ........................................... 12-4
Condition operator (decision table) .... 28-3
Conval (Properties window) ............... 14-6
Configurable I&C reports .................. 64-30
Conversion (of units) ............................ 11-5
Connect ....................................... 22-2, 57-17
Connect (I&C-Script) ......................... 57-43 Conversion of old data by script ...... 12-31
Conversion unit ................................... 46-15
Connect (script) ..................................... 22-2
Coordinates display ............................ 43-15
Connect with .......................................... 13-9
Connecting manually .......................... 64-55 Copy
- connections ........................................... 8-4
Connection ............................................. 13-9 Copy all scripts ...................................... 46-4
- Break ................................................... 13-9
- Break (wires kept) ............................. 13-9 Copy data
- Cut ...................................................... 13-10 - from template project ....................... 2-12

Copy data with Copy Structure ...........8-17 Cross references ...................................57-59
Copy script ..............................................46-4 Cross-hatching .....................................43-12
Copy structure (context-sensitive menu) .. Cross-reference (text variable for signals)
8-17 65-9
Copy structure (mouse menu) .............10-7 Cross-section ........................................13-10
Copy tab data ..........................................13-5 crp file .........................................14-5, 46-27
CopyConnectionDependentObjects .46-44 crp files
Copying .....................................................8-1 - bulk processing ..................................44-1
- across projects ....................................8-26 Ctrl+S (System Monitor) .....................3-20
- amount to be copied ............................8-1 Current database language ...................42-5
- Copy structure ....................................8-17
Current object .........................................10-2
- from template project ........................2-12
- keyboard command ...........................43-1 Current path (data matrix) ..................24-28
- Navigator .............................................8-11 Current project (usage) .......................12-32
- objects ..................................................43-1 Current unit ...........................................46-15
Copying across projects
CurrentTrans ........................................45-39
- Copy structure ....................................8-21
Customize .................................................2-8
copying across projects
- projection .............................................8-29 CustomizeFileOpenDialog (spec-script) ..
Copying tables ........................................8-34 22-16
Correct old texts .....................................46-4 CustomizeTree (spec-script) ..............22-17
CorrectRIRotation ...............................57-47 Cut ............................................................8-14
- Connection ........................................13-10
Costs .......................................................10-20 - object .....................................................2-3
Count ("Miscellaneous" for elements) ...... - Wires ..................................................13-10
12-18 CutLineWidth ......................................46-44
Count (monitoring) ................................3-25 CVS Monitor ............................................2-9
Count (option for elements) ...............12-10 CX ............................................................53-8
Country code ..........................................42-4 CY ............................................................53-8
CP .............................................................53-8
CProcess Number of process connectors ..
57-26
Create (elements) ...................................13-7
D
Create (right) ............................................6-7 DAO ...........................................................3-5
Create and edit list attributes ...............18-2 Data bus ..................................................65-8
Create base object product data” .........61-8 Data collisions (import) ........................3-11
Create columns .......................................18-2 Data copy for tabs .................................13-5
Create mode ..........................................49-11 Data flow control ...................................19-7
Create new symbol bar ...........................2-7 Data line ................................................57-52
Create option (base object) ................12-10 Data line (action line)
- Cross references ...............................57-59
Create revision (right) .............................6-7
Data matrix .............................................23-1
Create rows .............................................18-3
Data records selectors ...........................24-3
CreateDocumentGroup .........................22-2
Data set ..................................................10-16
Creating a control cabinet ..................64-62
Database
Creating new elements ........................12-17 - Create .....................................................3-6
Creation mode ......................................12-13 - creating ..................................................2-1
CreationStamp ......................................41-32 - Identifier ................................................3-7
criteria ....................................................59-58 - opening ..................................................2-1
- Reconcile .............................................3-10
Critical errors ..........................................30-6 - Release database ..................................1-1

- version synchronization ................... 3-15 Description (spec script) .................... 22-13
Database type ........................................... 3-1 DESIGN ................................................. 63-1
Databases .................................................. 3-5 Design ..................................................... 43-6
Date ............................................ 46-11, 46-18 DESIGN diagram
DB identifier .................................. 3-7, 3-19 - views ................................................... 63-3
DB synchronization ................................ 3-8 - without view ...................................... 63-2
DBExtras .............................................. 30-12 Design diagram ..................................... 63-1
- autorouting ....................................... 63-19
DBMon ................................................. 30-12 - Report templates ............................. 63-12
DBSync ......................................... 5-5, 30-12 - standard tables ................................. 63-11
DCS rack ............................................... 64-60 - symbols for views ............................. 63-5
- views ......................................... 63-1, 63-3
DD data records (ECAD) ..................... 58-2 - without view ...................................... 63-2
Debugging Monitor ............................ 30-12 DESIGN diagrams
Decimal delimiter .................................. 42-5 - autorouting ....................................... 63-19
Decimal places ..................................... 46-16 - Report templates ............................. 63-12
- standard tables ................................. 63-11
Decimal places (for units) .................... 11-5
- symbols for views ............................. 63-5
Decision table ............................ 10-14, 28-1 - views ................................................... 63-1
- Applications ....................................... 28-5 Design mode
- Design mode ...................................... 28-1 - toggling ............................................. 43-15
- Documentation of the action taken . 28-5
Design mode (attributes) ..................... 15-5
Declarations ......................................... 36-15
Design mode (bulk processing) .......... 26-6
Default table ........................................... 11-1
Designing symbols
Default unit ................................. 11-4, 46-15 - Isometric drawings ............................ 53-7
DefaultIdRectsForSymbols ............... 46-45 Detail ....................................................... 5-19
Definition of norm ................................ 53-3 DETAIL_IC ......................................... 64-15
Definition of pipe classes ..................... 53-3 DETAIL_JIC ....................................... 64-16
Delete (copy structure) ......................... 8-25 DetailReference ................................... 45-14
Delete (right) ............................................ 6-6 Details
Delete content (mouse menu) ............. 10-8 - Signal Manager ................................. 55-1
Delete pick lists ..................................... 5-13 Detail-type
Delete projection ................................... 8-23 - Delimiters ........................................... 5-15
Delete references without the original ...... Determine expenses ............................ 64-87
40-11 Determine quantities .......................... 64-87
Delete-Flag ............................................. 3-13 DevAllDescription .............................. 45-14
DeleteModePFD .................................. 46-45 DevContact .......................................... 45-14
Deleten DevDescription ................................... 45-14
- object ..................................................... 2-3 DevFunction ........................................ 45-15
DeleteWarning ....................................... 22-3 DevGUnit ............................................. 45-15
Deleting ..................................................... 9-1 Device ....................................... 10-19, 45-16
Delimiter path to zone .......................... 5-22 - Device label ..................................... 59-57
Delimiter sheet to path ......................... 5-22 Device channel request ...................... 64-53
Delimiter unit / location to sheet ........ 5-22 Device label ......................................... 57-41
Delimiters ............................................... 5-15 Device modification ............................. 58-3
Dereference (link) ................................. 12-8 Device request ..................................... 10-20
Dereferencing ...................................... 49-12 device selection ..................................... 2-12
Desc. (Text variable for signals) ........ 65-9 Device selection (product data) ........ 61-12
Description ................................... 13-3, 17-4 Device tag (text variable for signals) . 65-9
Description (attributes) ......................... 16-3 Device view ........................................... 50-7

Device.FullName .................................45-16 - Revisioning .........................................40-3
Device.Label .........................................12-20 - Usage ...................................................40-1
DeviceClassElement (copy structure) 8-26 Document scheme ...............................13-13
Devices Document version .................................3-16
- connecting ...........................................2-12 Documenta
Devices with location (query) 64-25, 64-72 - querying ............................................25-13
DevLocation .........................................45-17 Documents
- comparing ...........................................8-41
DevLocation1L ....................................45-17 - copying document types ...................8-44
DevName ..............................................45-18 - Document management ....................40-1
DevPosition ..........................................45-19 - Document types (dialog window) ...11-8
- evaluate .............................................25-16
DevType ................................................45-19
- printing ..................................................2-2
DevTypeL .............................................45-19 - Reference creation ...........................40-11
DevTypeW ............................................45-20 Documents directory ...................3-12, 3-19
DevUnit .................................................45-20 DocVariable .........................................36-10
DevUnit1L ............................................45-21 DOM ......................................................33-16
DevUnitPosition ...................................45-21 Dongle ...................................................30-13
Diagram type DoScale .................................................47-20
- DESIGN ..............................................63-1 Double-click ...........................................46-1
Diagram types ........................................45-1 Double-clicking .....................................10-5
Diagram types for views (DESIGN_) 63-6 Draft mode (import action) ..................33-2
Differences in the Object Matcher ......8-32 Drag & drop (reports) ...........................43-3
Dimensioning .......................................53-18 Draw options
DimensionSymbol ...............................46-45 - DrawTerminalSideMark .................59-24
DimensionTextHeight .........................46-45 Draw... (Option)
DimensionUnit .....................................46-45 - DrawPipeConnectorSymbol ..........46-46
DimLen object ........................................52-3 - DrawPipeEndSymbol ......................46-46
- DrawTerminalSideMark .................46-46
DIN 19227 ............................................57-22
Drawing reference .................................57-7
direct (access) .......................................12-31 DSpec ....................................................46-35
Direct start .................................................2-4
Ducting ....................................................50-4
DisConnect (E/I&C script) .................57-44
DWG/DXF
DisConnect (script) ................................22-3 - Break down drawing into report
Disconnecting from the bridge ..........59-67 elements 35-11
Display .....................................................10-3 - Break down DWG drawing into
- Type .....................................................16-1 planning objects 35-7
- DWG/DXF Mapping Editor ..35-1, 35-8
Display colors (AutoCAD) ................46-22 - DXF_inch.ini ....................................35-11
Display description (attributes) ...........15-5 - Export ..................................................35-2
Display names (attributes) ....................15-5 - Import ..................................................35-4
- save ....................................................25-17
Display with inherited objects .............8-32
DXF (Properties window report) ........14-5
DisplayConnectedWith .......................59-32
Dynamic link ..............................16-16, 19-8
DocObj
- copying via the Navigator ................8-12 Dynamic value .....................................16-16
DocPointer ..............................................36-5
Document ......................10-16, 36-10, 36-16
- Drag&Drop import ..........................40-15 E
Document group ..................................10-16
E&IC ........................................................64-1
- Document group (definition) ...........50-4
Document groups E&IC options .......................................57-19

E/I&C options ........................................ 64-7 Error output ............................................ 3-15
EBD Installation data ........................... 63-7 EvalOneRow ........................................ 46-31
ECAD ...................................................... 61-7 EvalOneRowObject Spec .................. 46-26
ECAD components import ................ 62-10 Evaluation .............................................. 46-9
eCl@ss .......................................... 50-7, 61-7 Evaluation Report (Properties window) ....
Edit 14-2
- (Min Max) ................................ 16-4, 17-6 Evaluation Reports
- (Min Value Max) ..................... 16-4, 17-5 - I&C .................................................... 64-30
Edit (Min Value Max) .......................... 19-8 Event-triggered systems ....................... 65-1
Edit field ....................................... 16-2, 17-2 Example
Edit mask ................................................ 58-4 - CDI .................................................... 36-15
Edit mode ................................................ 16-6 - Import script ..................................... 33-14
Excel ........................................... 24-23, 36-1
Edit new objects directly ...................... 10-3
- ExcelABC (function) ...................... 36-16
Editing attributes in a group .............. 19-14 - ExcelMergeAll (Scriptoption) ........ 37-2
Edit-OCX (option with texts) .............. 46-9 - ExcelRaster (Scriptoption) .............. 37-1
EE/I&C folder ............................ 57-10, 64-2 - ExcelSheetScaleH (Scriptoption) ... 37-2
- Import ........................................ 33-1, 33-7
Electrical Engineering, Instrumentation & - Interface (Control properties) ......... 17-3
Control .................................................... 64-1 - linking ................................................. 36-1
Element ................................................. 10-17 - Reimport ............................................. 37-3
Element (text variable for signals) ... 65-10 Excel (Properties window) .................. 14-6
Element of class Element ..................... 13-7 Excel interface ............................. 16-2, 17-3
Elements ............................................... 45-22 Execute ................................................. 16-20
- block .................................................. 12-19 Execute (Import) ................................... 33-4
Elements (creation mode) .................. 12-13 EXF ......................................................... 62-7
Elements, creation ................................. 13-7 ExF Import ............................................. 62-1
Elm..CO ................................................ 45-23 EXFConformable ...................... 46-48, 62-5
Elm..CP ................................................. 45-23 Expense objects ................................... 64-84
Elm..DS ................................................. 45-24 Exponential format ............................. 46-16
Elm..Label ............................................ 45-24 Export ................................................ 3-9, 5-3
Elm..VW ............................................... 45-25 - export in the Object Browser ........ 24-22
ELO_DOCSORT .................................. 31-6 - ExportFreeGraphic (RNE) .............. 37-2
ELO_OUTPUT ...................................... 31-6 Export Access ........................................ 3-11
EnableButtonANSICable ....... 46-46, 47-20 ExportDB.exe ........................................ 3-12
EnableButtonOblique ............. 46-46, 47-20 Expression (text parameter) ................ 46-7
EnableButtonSpline ............................ 46-47 Expression (Texttyp) .............. 46-11, 46-18
EnablePaging ....................................... 46-47 Ex-Protection ........................... 64-68, 64-69
EnableProcessConnection ................. 46-47 Ex-protection ................... 57-19, 64-7, 64-9
EnableProcessConnectionActor ....... 57-35 Ex-protection cabinet ......................... 64-69
EnableProcessConnectionSensor ..... 57-35 Ex-protection control cabinet ........... 64-68
EnableSynchronizeNavigator ............ 46-48 Extended amount to be copied ............ 8-10
end .............................................................. 2-2 Extension object (data matrix) .......... 24-17
End program ............................................. 2-2 External (object test) ............................ 30-7
Environmental conditions .......57-19, 64-7, Extra ........................................................ 2-10
64-9 exVisible ................................................. 37-3
EPLAN .................................................... 62-1
Equipment ............................................ 10-21
Error log .................................................. 3-15

F Full-text search ....................................40-16
Function ................10-18, 57-20, 64-2, 64-8
F1 key ....................................................16-20 - connectors .........................................57-36
Favorite assembly groups (signals with - data flow ............................................57-31
channels) ...............................................64-10 - definition ...........................................57-20
- display ...............................................57-41
Favorite measuring instruments ...... 64-11, - scripts .................................................57-43
64-51 Function Code ......................................53-15
FD Function code ..57-21, 57-22, 57-23, 57-29,
- Function diagrams .............................65-1 57-41
- Function modules general ..............65-12
- Isometric drawings ............................53-4
Field .......................................................36-10
Function component ...........................10-18
Field distributor ........................64-70, 64-72
Function data ........................................57-42
- creation ..............................................64-72
Function diagram ...................................65-1
Field location ........................................64-70
Function element .................................10-19
File
- save .........................................................2-1 Function modules ................................64-51
File link (Properties window) ..............14-6 Function plan (Logicad) .......................14-7
File selection .................................16-2, 17-4 Function rights .........................................6-8
File storage ..............................................14-5 Function rights (definition) ....................6-3
FillComboList (spec-script) ...............22-17 Function settings P&ID ......................57-24
Filter Function type ........................................57-22
- filter operator ......................................24-9 Functional chart .....................................65-1
- filter value ...........................................24-9 Functions ...............................................57-20
- filtering queries ..................................24-8 - creation ..............................................57-53
- setting (Object Matcher) ...................8-32 - Symbols .............................................57-38
Filter bar ..................................................10-1 - tabs .......................................................64-8
FilterRow (script function) .................22-17 - uasge ..................................................57-53
Filters Functions (measurements)
- Filters in the Properties window ......13-1 - %N text ..............................................45-26
First user ....................................................3-6 Functionscode ......................................53-27
Fix (Textyp) ..........................................46-14 Functionsn (Measurement)
Fixed (text parameter) ...........................46-8 - Base object ..........................................50-3
Folder FunctionType .......................................57-24
- base data view ..................................12-11 FuP ...........................................................50-1
- EE/I&C Engineering .......................57-10
- Planning page .....................................13-3
folder objects ..........................................10-3
Folders
G
- Documents folder ...............................64-3 GD 3D .....................................................63-9
- EE/I&C Engineering .........................64-3 GD Geometry .......................................16-19
Font ............................................43-11, 47-15 General (project properties) .................5-14
ForCDevice ...........................................10-11 GeneralScaleFactor .............................46-48
Format ......................................................16-5 Geotype .................................................53-15
Forms (def.) ............................................62-2 GetAllPropertiesAndMethodsByObject ...
Frames ...........................................16-2, 17-1 45-42
Frames (attributes) .................................15-6 GetConnectorLabel ...............................22-3
FromDoc ...............................................45-25 GetConnectorSpecification (script) ....22-3
FromDocObject ....................................45-25 GetDisplayValue .................................16-12
FullLabel ...............................................12-11 GetDisplayValue (spec-script) ..........22-18

GetDisplayXValue (spec-script) ...... 22-18 Horizontal (Tabs) .................................. 10-4
GetDocumentDirectory ........................ 16-2 HW Config ............................................. 56-1
GetLinkedSpecification ..................... 16-12 Hydraulics .............................................. 50-8
GetLinkedSpecification (spec-script) ....... Hyperlink .............................................. 16-20
22-19 HYSYS ................................................... 51-1
GetLinkObject ....................................... 17-5
GetLinkObject (spec-script) .............. 22-19
GetRoot (spec-script) .......................... 22-19 I
GetScriptUnit (spec-script) ................ 22-23
I connector ........................................... 57-37
GetScriptValue (spec-script) ............. 22-23
I&C ................................................ 50-2, 64-1
Global base objects ............................... 49-2
I&C Evaluation Reports .................... 64-35
Global script ........................................... 46-6
I&C settings ......................................... 64-27
Global test ............................................... 5-13
I/O card ................................................... 65-8
Global test (object test) ........................ 30-8
IC22 ....................................................... 57-28
GlobalPageNr .......................... 46-11, 46-18
ICA101 ................................................. 57-25
Go to ...................................................... 46-17
ICA103 ................................................. 57-25
Go to (data matrix) .............................. 24-29
ICA110 ................................................. 57-25
Grab points ............................................. 43-7
- user-defined ...................................... 45-41 ICF100 .................................................. 57-26
Grafische Objekte ............................... 46-31 ICF102 .................................................. 57-26
Graphic .................................................. 10-17 ICF200 .................................................. 57-25
Graphic options ................................... 57-59 ICF200 Optional
Graphical settings ................................ 57-42 - Graphic for relevant adjustments . 57-40
ICF201 .................................................. 57-25
Graphics .................................................. 32-1
- Scaling ............................................... 46-21 ICF201 Optional
Grid .................................... 43-7, 46-5, 64-43 - alarm display .................................... 57-39
IColumnDef ......................................... 24-16
Grid (reports) ......................................... 43-7
IColumnDefs ....................................... 24-16
Grid router .............................................. 53-3
Group (create option) ......................... 12-12 Icon
- delete ................................................... 12-4
Group delimiter ..................................... 42-5 Icon library ................................... 12-3, 12-4
Grouping (query) ................................... 24-7
Iconbar (Properties window) .............. 13-1
Grouping attributes ............................... 15-6
I-connector ........................................... 13-15
Groups ..................................................... 6-20
I-connector (terminals) ...................... 64-55
ID segment ........................................... 64-49
ID segments ......................................... 59-14
H Identifier ................................................... 3-7
Hairline ................................................... 37-2 Identifier tool ......................................... 43-7
Hardware IEC 1175 .................................. 64-25, 64-50
- Input ..................................................... 65-8 IEC1175 ................................................ 64-56
- Output .................................................. 65-8 IFilter ..................................................... 24-16
Hash table size ....................................... 3-20
Ignore bridges ...................................... 64-27
Help ......................................................... 2-14 Image selection ...................................... 16-3
Help tab ................................................. 16-20
Image selection (spec script) ............. 22-14
History ..................................................... 3-24
Imagineer documents (Properties window)
Hook-Up ............................................... 64-81 ................................................................... 14-6
Hook-Up graphic ................................. 64-82 Implement requests ............................. 64-66

Implement requests (option) ..............64-27 Inherited properties
Implementation ....................................64-65 - copying ..................................................8-2
- Implement (text variable for signals) .... Inheriting .................................................49-3
65-10 Inline device .............................57-33, 57-34
- Implementation pointer .....................13-2
Input channel ........................................64-52
- individual objects .............................64-66
- Name ....................................................5-20 input unit .................................................11-4
- several objects ..................................64-66 Input value ..............................................11-2
Implementing Insert columns (query) ........................24-23
- implement (Device) request .............60-3 Inserting into the bridge .....................59-67
Import ....................................................10-15
Installation
- Action ...................................................33-1 - AKZ .....................................................57-9
- ECAD .......................................58-1, 62-10
- ANSI ....................................................57-9
- ECAD data ..........................................56-1
- EN/DIN ...............................................57-9
- Excel ....................................................33-7
- ExF .............................................56-1, 62-1 Installation diagram ............................63-21
- EXF symbols ....................................62-12 - report template .................................63-24
- ImportRow (Import script) ...............33-8 - views ..................................................63-21
- manufacturer devices ........................61-6 Installation plans ..................................47-19
- Project ..........................................5-3, 39-1 InstanceCount ........................................3-25
- Report templates ................................39-2
- synchronized database ......................39-1 Instances ....................................................3-5
- System project ....................................39-2 Instances re attributes
- Translation ..........................................39-2 - Instances (project option) .................20-1
- Triga ...................................................56-11 - Instances as base object ....................20-4
Import (spec-script) .............................22-20 - Operation .............................................20-1
Import Comos datenbase ......................3-10 Instances with attributes
- Instanciating (option base object) .12-11
Import interface
- Simulator imports ..............................51-1 Instrumentation ....................................10-18
ImportDB.exe .........................................3-10 Instrumentation & Control ...................64-1
Importing article base data .................62-10 Interactive Report (Properties window) ...
14-4
Importing ECAD components .............58-1
Importing manufacturer devices .........61-6 interface language ...................................2-2
IPOS .......................................................53-17
Inconsistencies
- Status management ............................21-3 IQuery ....................................................24-16
Inconsistency (status) ............................21-8 IsAlias ....................................................49-17
Indeterminate wires .............................13-14 ISGlobalObj.dll ....................................33-14
Index ........................................................18-2 IsGroup ..................................................10-11
Index (Revision) ....................................41-6 IsImplementationValid .........................22-4
indirect (access) ...................................12-31 IsLocationValid .....................................22-4
Information .............................................30-5 IsLockAllowed ......................................22-4
Inheritance Isometric pipe structure ......................57-11
- tab Inheritance sources ....................12-32 ISort .......................................................24-16
Inheritance (rights) ..................................6-4 IsReleaseAllowed ..................................22-5
Inheritance mode .........................15-8, 16-9 IsUnitValid .............................................22-5
- active ..................12-18, 12-22, 15-8, 16-9 IsValueValid (spec script) .................22-13
- connector ...............................12-17, 12-22
- Elements collection .........................12-14 Item-Property ((text parameter) ..........46-7
- inactive ...............12-18, 12-22, 15-8, 16-9 Item-Property (text type) ....................46-13
- inactive for base objects .... 12-18, 12-22, Items ..........................................................7-9
15-8, 16-9
ITopQuery ............................................24-16
Inheritance source (mouse menu) .......10-6
ITopQuery browser .............................24-15
Inherited elements .................................13-6

J Level
- reduction ............................................. 8-24
Joint access ............................................. 5-12 Line thickness ...................................... 57-48
Joker for wires ..................................... 13-14 Line thicknesses (AutoCAD) ............ 46-22
Joker sign for wires ............................... 49-6 Line type ............................................... 57-48
Jumper distributor ............................... 64-73 Lines ........................................................ 43-8
Justification (option with texts) .......43-12, Link ................................... 16-14, 17-4, 19-8
47-15 Link (list) ................................................ 18-3
Link Min/Value/Max ......................... 16-15
Linking (attributes) ............................... 16-3
K Linking cells .......................................... 18-4
Linking the unit and location views 64-70
Keep visible .................................. 12-1, 13-2
Links
Key letter ................................................ 5-16
- linked attribute ................................... 19-8
Keyboard commands ............................ 43-1
Links (project properties) .................... 5-14
Keycode.exe ............................................. 1-1
List
Konverter .............................................. 30-13 - Control properties ............................. 18-2
konverter.exe ........................................ 30-13 - create and edit .................................... 18-2
- Minimum size .................................. 46-24
- place frame ....................................... 46-23
- Structure ............................................. 18-1
L List (attributes) ...................................... 16-4
Label ............................................ 13-3, 57-29 List of references .................................. 64-3
Label (text variable for signals) .......... 65-9 List query ............................................. 25-27
Label by owner .................................... 12-20 ListMaster ............................................ 46-48
LabelAlias ............................................ 49-14 LNTYPE ............................................... 57-49
Labeling systems ................................. 49-14 Load PlugIns ............................................ 2-5
Labelling for signals and connections ...... Load symbol scripts ............................ 12-24
64-50 Loading a pipe class ........................... 53-58
Labelling systems ................................ 49-11 LoadPicture .......................................... 46-22
LabelSize ................................................ 17-3 Local base objects ................................. 49-2
Language Local instances ...................................... 5-18
- copying ................................................ 8-44 Local working areas ............................. 6-15
- interface ................................................. 2-2 Localization ........................................... 42-1
- switching ............................................. 42-1
Location ................................................ 10-20
Languages
- Not translated ................................... 42-22 Location (convert) .............................. 30-13
Languages tab ........................................ 5-23 location planning ................................. 64-59
Last update (CVS) ................................. 3-26 Location pointer .................................. 64-25
Layers ................................ 32-1, 43-6, 43-16 - Kopy ...................................................... 8-4
Layers (working areas) ......................... 6-11 Location structure ............................... 64-59
Lock ........................................................ 13-1
Layout ................................................... 15-10
log files ................................................... 30-2
Layout (Column)
- delete ..................................................... 5-1 Log. potential ....................................... 59-59
- reset ........................................................ 5-1 Logging in ................................................ 3-1
- save ........................................................ 5-1 - First login ............................................. 3-6
lck files .................................................... 30-3 Logicad ................................................... 14-7
LCODBC32 ......................................... 30-13 Logical diagram .................................... 65-1
Length ........................................... 16-5, 17-3 Logical potential ....................... 10-19, 59-6

Logical potentials Memo field (attributes) .........................16-4
- preparing ............................................59-65 Memofeld ................................................17-5
Login ..................................................2-1, 3-1 Menu configuration .................................2-6
- CS (CreationStamp) ........................41-32
Meta-rights ...............................................6-1
LogPot pointer ......................................64-44
Metzner Triathlon ................................63-21
Loop .......................................................64-39
Microsoft Jet .....................................3-1, 3-6
Loop diagram ...........................64-19, 64-39
- auto-functions ...................................64-42 Min Max .................................................19-8
- configuration .....................................64-45 Mini-list .................................................25-27
- options script .....................................64-46 Mirror ....................................................43-14
Loop-Plan ..............................................59-20 MKY Mounting key ............................63-10
Mode ........................................................11-9
Mode for creation ................................12-13
M Modification of devices ........................58-3
Magnetic snap-to ...................................47-1 Modify ...................................................10-22
Main unit ...............................................57-10 Modify objects in Interactive Reports ......
47-14
MainDevice ..........................................45-26
Modules
Maintenance .........................................10-22 - EE/I&C modules ..............................59-26
Manufacturer ..............................59-59, 61-6 Mounting ...................................10-20, 59-59
Manufacturer data ................................64-80 Mounting accessories .........................64-79
Manufacturer Device .............................61-1 Mounting catalog .................................64-78
Mapping (AutoCAD) ..........................46-22 - constituent parts ...............................64-79
Mapping table .........................................52-4 Mounting comment .............................64-79
Marshalling ...........................................64-73 Mounting expense ...............................64-80
Marshalling cabinet .............................64-69 Mounting expense object ...................64-87
Marshalling management ...................64-75 Mounting expenses .............................64-87
Masks for texts .......................................12-5 Mounting instructions .........................64-82
Master / Slave ...............................5-20, 59-9 Mounting objects .................................64-79
Master report ..............................46-6, 46-30 Mounting planning ..............................64-78
Match document Versions ....................3-17 Mounting texts .....................................64-84
Material list ...........................................64-84 Move ............................................8-14, 43-13
Material lists area .................................64-82 Moving the working area .....................43-2
Materials ................................................59-60 MS SQL Server .......................................3-5
Maximum loaded objects .....................3-21 mssqlpwd.dat ..........................................6-26
MaxLoadedObjects ...............................3-22 MTS_JD ................................................64-64
MaxPageNr ...............................46-11, 46-18 MultiCRP ....................................30-13, 44-1
MC bay (control) .................................64-65 MultiCRP.exe .........................................44-1
MC bay (Field) .....................................64-73 Multiple connections ..........................57-59
MDB compression .................................3-18 Multiple selection ..................................10-5
Measurement function - copying ..................................................8-2
- creation ..............................................57-53
- mouse menu ......................................64-50
Measuring function ..............................57-20
Measuring instruments ........................64-11
N
MediumLine ...........................................37-2 Name ........................................................13-2
- Convention for devices .....................5-16
Memberships ..........................................6-18 - for implementation ............................5-20
Memo (Control properties) ..................17-5 - uniqueness ...........................................31-9

Name for implementation (flow diagram)
57-47
O
Navigate .................................... 13-10, 13-12 Object ...................................................... 8-31
Navigate (mouse menu) ............. 10-5, 10-8 - constituent parts .................................. 8-1
Navigation - copy ....................................................... 2-3
- cut .......................................................... 2-3
- Icon menu in Properties windows .. 13-1 - delete ..................................................... 2-3
- Navigation Assistant (decision table) ... - Drag object ......................................... 13-1
28-3 - in an Interactive Report .................. 49-24
- Navigation library (data matrix) ... 24-25 - in report ............................................. 49-24
- Navigation library extended .......... 24-27 - Insert object ........................................ 46-2
Navigation assistant ............................ 16-14 - paste ....................................................... 2-4
Navigation bar ....................................... 10-1 - translating object texts ................... 42-15
Navigator .................................................. 2-4 Object (copying across projects) ........ 8-30
- about copying ..................................... 8-11 Object (options group) ......................... 14-7
- Pick list ................................................ 10-2 Object = owner .................................... 49-24
- Status display ..................................... 21-5
Object allocations (References) ............ 8-4
NavigatorText ........................................ 22-5
Object behavior ................................... 12-10
neutral function .................................... 57-21
Object Browser ...................................... 24-1
New
- Attribute .............................................. 15-4 Object comparer .................................... 2-13
- Tab ....................................................... 15-4 Object debugger .................................. 30-11
New (Icon command) ........................... 13-1 Object debugger (right) ........................ 6-10
New (mouse menu) ............................... 10-7 Object differences ................................. 8-46
New base object ..................................... 49-3 Object from template .......................... 49-24
New document ..................................... 49-23 Object interpreter .................................. 2-13
New evaluation per page ...................... 46-9 object language translation .................. 2-11
new files .................................................. 30-2 Object management .............................. 6-23
New report template ........................... 49-22 Object of a report ........................ 14-3, 14-4
New under Master ................................. 13-8 Object path ........................................... 46-17
New user profiles .................................. 6-17 Object queries
NewCObject ......................................... 33-10 - Display in reports ............................ 46-25
NewObject ............................................ 33-10 Object query ......................................... 10-15
- Mini-list ............................................ 25-27
NewSpec ............................................... 33-11
Object release ........................................ 3-21
NO data records (ECAD) ..................... 58-2
Object rights ............................................. 6-5
No link .................................................. 16-11
Object rights (definition) ....................... 6-3
NoCon.dat ............................................... 3-15
Object Test ............................................. 30-7
Nominal pipe size
- Branch tab ......................................... 53-60 Object test .................................... 2-11, 30-5
Nominal width ....................................... 53-3 Object tool (reports) ........................... 47-14
Non-specific wires ................................ 49-6 objects release ........................................ 3-23
Normal (Properties window) ............... 14-6 Objects that have been brought over ... 8-7
not relevant for ordering .................... 59-59 Oblique connections ........................... 47-20
Nozzle ................................................... 57-33 O-connector ......................................... 13-15
N-to-1 relations ........................................ 7-4 O-connector (terminals) ..................... 64-55
Number of collections .......................... 3-20 OLE object ............................................. 46-2
Number of objects ................................. 3-20 OnChange (spec-script) ..................... 22-12
Numbering .............................................. 58-3 OnChangeOther (spec-script) ........... 22-21
OnCheck (script) ................................... 22-5
OnClick (spec-script) ......................... 22-21

OnClose ...................................................36-6 orapwd.dat ..............................................6-26
OnCreateReferenceDocument (script) ...... Order ......................................................59-60
22-6 Order list / parts list .............................59-59
OnDocObjCreate (script) .....................22-7 OrgDocument .......................................49-23
OnDocObjDelete (script) .....................22-7 Origin .....................................................46-19
OnEdit (spec-script) ............................22-22 Original .................................................49-15
OnEditOk (E/I&C script) ...................57-44 OSpec ....................................................46-35
OnEditOk (script) ..................................22-7 Output ....................................................59-59
OnEStampCreate ...................................22-7 Output and operation ..............57-41, 57-46
OnEStampShow .....................................22-8 OutputDebugString .............................33-16
OnLocationSet ........................................22-9 Owner (Navigation to...) ......................13-1
OnLockDone ..........................................22-9 Owner (signal) .....................................64-57
Only folders OwnerInstance .......................................20-3
- base data view ..................................12-11
OnMenuCreate .....................................64-26
OnMenuCreate (Script) ......................22-11
OnMenuCreate (script) .........................22-9
P
OnMenuExecute ..................................64-26 P&ID
OnMenuExecute (script) ......................22-9 - Pipes ...................................................57-11
P&ID options .........................................5-20
OnNotLongerReferencedBy (script) 22-10
P&ID pipe structure ............................57-11
OnOpen ...................................................36-6
P&ID tab ...............................................57-48
OnProjectOpen (script) .......................22-10
OnReferencedByDevice (E/I&C script) ... P&ID templates .....................................52-7
57-44 Page
- Nr ................................46-10, 46-11, 46-18
OnReferencedByDevice (script) .......22-10
Page area .....................................64-9, 64-48
OnReferencedByDocument (script) .22-10
Page number ...........................................5-16
OnRelease .............................................22-10
Page reference symbol ........................57-50
OnReleaseDone ....................................22-10
Page references ......................................5-20
OnRevision (script) .............................22-11
PaperSize ..............................................25-18
OnShow (spec-script) ..........................22-22
Parameters
OnUnitSet .............................................22-11 - copying ................................................8-44
OPC ........................................................64-26 Parameters (data matrix) ....................24-28
Open ...........................................................3-1 Parent .........................................................7-2
Open project .............................................2-1 Parent object .............................................7-2
Opening databases ...................................3-1 Part .........................................................59-59
Operator .......................................16-15, 19-8 Parts .......................................................59-60
Operator (product data) ........................61-4 Parts list evaluation .............................64-86
Optional Paste
- Graphic for relevant adjustments ..57-40 - Connection ........................................13-10
Optional objects ...................................49-10 - Wires ..................................................13-10
Options ....................................................46-5 Paste link (mouse menu) ......................10-8
- EE reports ..........................................59-31 Paste under Master ................................13-8
- Project properties ...............................5-15
Path ..........................................................5-23
Options group documents (Properties
window) ...................................................14-6 PCC Component for process coupling .....
57-24
Oracle .................................................3-1, 3-5
PCL ........................................................53-15
Orange background .............................61-14
pcl files ....................................................58-3

PCP file ................................................. 46-22 Pipe structure in the Navigator ......... 53-57
PCP-Datei ............................................... 39-2 PipeCAD pipe classes project ............. 5-20
PDAA.1 Product request .................... 64-30 Pipes ............................................ 50-2, 57-11
PDAA.2 Product request Function ... 64-31 - optical interruption .......................... 57-15
- separating ......................................... 57-15
PDAA.3 Data sheets Motor ............... 64-31
PipeSpec ................................................. 53-5
PDAD.1 Armature overview ............. 64-36
Place attributes .................................... 46-34
PDAE.1 Function and signal list ...... 64-37
Place auxiliary connectors ................. 13-10
PDF ........................................................ 41-24
Place graphic objects .......................... 46-31
PDS objects ............................................ 35-6
Place sub-report ................................... 46-29
PE base objects .................................... 52-11
Place Windows Metafile ...................... 39-2
Performance Monitor .............................. 2-9
Place Windows metafile .................... 46-20
Permit value input ............................... 46-16
Placeholders ........................................... 12-5
PFA Position diagram, single line .... 64-41
Placement overview ........................... 57-10
PFFA Functional diagram ................. 64-41
Placement point (reports) .................... 43-7
PFPA ....................................................... 64-3
Placing a report on a report ............... 47-16
PFPA.1 Signal list ............................... 64-38
Placing terminals ................................. 64-43
PFPA.2 Signal list (hardware) .......... 64-38
Planning object
PFPB List of references ........... 64-3, 64-38 - Connectors .......................................... 13-8
PFSM.1 Loop ANSI ........................... 64-40 - Specification ...................................... 13-4
PFSM.2 Position diagram .................. 64-40 - Wires ................................................. 13-12
PhysUnitLabel ....................................... 36-5 Planning object references .................... 8-5
PI01 ........................................................ 57-28 Planning object status ........................... 21-3
PIA602 ...................................... 57-14, 57-15 Planning object status value ................ 21-3
Pick list (Navigator) .............................. 10-2 Planning objects
Picklist values - bulk processing .................................. 26-2
- querying ............................................ 25-24 - standard query ................................... 25-7
Picture PlanObj (usage) ................................... 12-32
- Place picture frame ......................... 46-22 Plant Design System ............................. 35-6
- Scaling ............................................... 46-21 PLC overview ...................................... 62-16
Pipe ................................ 10-17, 10-21, 57-12 PLC programs ........................................ 65-1
- Graphical properties ........................ 57-16 Plot frame (def.) .................................... 62-2
Pipe branch ........................................... 57-13 PLT position - function overview .... 64-36
Pipe branch separative ........................ 57-15 PLT position overview ....................... 64-35
Pipe class ...................................... 53-3, 53-5 PLT position sheet .............................. 64-77
Pipe class management Plug ....................................................... 10-18
- "Branch" tab ..................................... 53-60
- "Devices" tab .................................... 53-60 Plug strip .............................................. 10-20
Pipe classes project ............................... 5-20 PlugIn
Pipe cut mode .......................... 57-14, 57-15 - Assignment Manager ........................ 2-14
- Base data import Triga 1.04 ............ 2-14
Pipe segment ........................................ 57-13 - Conversion of units ........................... 2-15
Pipe segments ...................................... 57-13 - Document interface ........................... 2-14
Pipe separative ..................................... 57-15 - DWG/DxF Mapping-Editor ............ 2-14
- EPlan data exchange ......................... 2-14
Pipe structure ....................................... 57-11 - Export LogiDoc (in Access) ........... 2-15
- Base objects ...................................... 57-14 - Marshaling Management ................. 2-15
- First level .......................................... 57-12 - Pipe classes ........................................ 2-15
- Level3 ................................................ 57-13 - Ruplan import .................................... 2-15
- Second level ..................................... 57-13 - VNS import ........................................ 2-15
- Third level ........................................ 57-13 Pneumatics ............................................. 50-8

Pointer ....................................................36-16 Prefix ...................................5-15, 5-16, 5-23
- Alias .....................................................13-2 Prepare valve ............................57-54, 57-56
- Implementation ..................................13-2 Preparing 3D templates ........................52-9
- unit ........................................................13-2
Pointers Preparing documents at the base object ....
- copying ..................................................8-3 49-23
Position ..............................10-21, 64-2, 64-5 Preparing logical potentials .......49-6, 59-8
- creating automatically .....................57-18 Preprepared documents ......................49-23
- data flow ............................................57-19 Primary language ...................................42-4
- tabs .......................................................64-6
Print (mouse menu) ...............................10-8
Position (convert) ................................30-13
Print jobs ...............................................25-18
Position diagram ..................................64-19
PrintManager ............................................2-2
Position in the substance stream strip .......
Pro II ........................................................50-9
57-48
Process connector .......57-21, 57-22, 57-27,
Position number ...................................53-17
57-30
Position sheet ........................................64-30 - number ...............................................57-36
Positioning Process coupling
- Report .................................................47-16 - auto-create .........................................57-35
Positions ................................................57-17 - creation ..............................................57-55
PotAllDescription ................................45-27 - options script ....................................57-35
- switch .................................................57-34
PotDescription ......................................45-27
- valve ...................................................57-34
Potential .................................................10-19 process coupling ..................................57-30
- Logical potential ....................59-8, 59-65 - inline device .....................................57-34
- logical potential ..................................49-6
- Struktur kopieren ...............................8-26 Process technology
- Options ................................................5-19
Potential references ...............................5-20
Process units .........................................57-51
Potential tracking ...................................5-17
Process visualization ...........................64-26
PotentialProlongation ..............46-49, 59-10
Processing with ........................57-41, 57-46
Potentials .................................................59-6
Product Data ...........................................61-1
PotLocation ...........................................45-27
Product data ......................2-12, 61-1, 64-77
PotName ................................................45-27
Product data (right) ...............................6-10
PotUnit ...................................................45-27
Product, requirement ...........................16-19
PPC .................................................53-1, 53-6
Product, requirement combination .....17-3
PPC Parts list, Hook Up .....................64-81
ProductRequestDisplayText ..............61-15
PPC reports ...........................................64-39
ProgID .........................................12-4, 24-17
PPCB Hook-Ups with position .........64-85
Prohibitions on projection (copy structure)
PPCC ......................................................64-86
...................................................................8-26
PPStatusCheck .......................................21-6
ProII .........................................................51-1
PPStatusSet .............................................21-6 Project ........................................33-13, 36-16
PQAC.1 Loop, check protocol ..........64-37 - closing ...................................................2-1
PQBA.1 LList of security-relevant E/I&C - create ......................................................5-2
installations ...........................................64-39 - creating ..................................................2-1
Predetermine wires ..............................13-14 - export .....................................................5-3
- import ....................................................5-3
P-references ..............................................8-5 - language ..............................................42-3
Preferred assembly groups (signals with - save ........................................................2-1
channels) ...............................................64-51 - saving .....................................................2-1
PreferredConnectionDirection ......... 64-48, - selectionl ...............................................2-1
64-49 Project directory (rename) ...................5-13
PreferredDirection ...............................46-49 Project directory matching ...................2-10

Project management ............................... 6-2
Project options (right) ........................... 6-10
R
Project options for flow diagrams / P&ID Rack .......................................... 10-21, 45-28
57-46 Racks ..................................................... 64-62
Project properties Range attribute .................................... 19-13
- E&IC ................................................. 64-27 Rating for grid routing ......................... 53-3
- General ................................................ 5-14
Read completely (right) ......................... 6-5
- Links .................................................... 5-14
- Options ................................................ 5-15 Read-only due to ................................... 6-24
Project suppositions EXF .................... 62-7 Real devices
Projection ........................................ 8-8, 8-29 - importing ............................................ 61-6
- Copy structure .......................... 8-22, 8-23 Reconciliation (databases) ................... 3-10
Prolongation ......................................... 59-10 Recreate deleted objects ........................ 6-2
Properties ...................... 13-11, 46-11, 46-18 Reduction of levels ............................... 8-24
- comparing ........................................... 8-37 RefChain ............................................... 45-28
- of Excel documents ........................... 36-2 Reference
Properties of Word documents ......... 36-10 - Alias .................................................. 49-15
Properties window - Original ............................................. 49-15
- Filtering ............................................... 13-1 - paste ....................................................... 2-4
- Keep visible ........................................ 13-2 - unit ....................................................... 11-4
Properties windowr Reference (Properties window) .......... 14-6
- Iconbar ................................................ 13-1 Reference documents ........................... 5-22
Property Reference not resolved ......................... 5-22
- Alias ................................................... 49-15 Reference with location ....................... 5-22
PropName ............................................... 36-5
Reference with sheet ............................ 5-23
PropParameter ....................................... 36-5
Reference with unit ............................... 5-22
PS ........................................................... 57-50 Referenced objects ................................ 3-20
PSpec ..................................................... 46-35
References
ptmcast .................................................. 30-14 - comparing ........................................... 8-37
- copying ................................................. 8-3
References pointing outwards ............... 8-3
Q RefMaster ............................................. 45-29
Refresh (mouse menu) ......................... 10-9
QDev010 objects with DocObj ......... 57-10
Refresh speed ......................................... 3-20
QuadrantOffsetLeft ............................. 46-49
RefSimple ............................................. 45-29
QuadrantOffsetTop ............................. 46-49
Registry ................................................. 30-14
QuadrantSizeX ..................................... 46-49
RegMaid ............................................... 30-14
QuadrantSizeY ..................................... 46-50
Reimport ................................................. 34-1
QuadrantStartChrX ............................. 46-50
Relation (data matrix) ........................ 24-29
QuadrantStartChrY ............................. 46-50
Relay ..................................................... 10-20
QuadrantStepX .................................... 46-50
Release unused objects ........................ 3-23
QuadrantStepY .................................... 46-50
ReleaseAllObjects ................................. 3-21
Quality assurance ................................ 10-21
ReleaseObjects ...................................... 3-21
Queries
- concept ................................................ 23-1 Releasing objects .................................. 3-21
- Object Browser (definition) ............. 23-2 Relevance display ............................... 57-40
Remove document group ..................... 5-22
Rename ..................................................... 2-8
Rename (copy structure) ...................... 8-25
Renumbering ......................................... 58-3

Report RIST .......................................................48-20
- Designer ...............................................46-1 RNE .........................................................37-1
- Layers .................................................43-16 - Reimport .............................................37-3
- Object .................................................49-24
- Report object .....................................49-24 Room .....................................................10-20
- ReportObject .....................................46-18 Root-Filter (Navigator) .........................10-1
- ReportObject (text type) .................46-11 RootObject ..............................................33-9
- ReportScript ......................................45-29 Rotate .....................................................43-13
- select template ..................................49-24
- Version .................................................3-16 Rotated alignment ...............................59-24
- Version number ..................................3-16 Rounding off of decimal places ........46-16
Report template ....................................49-20 Route ......................................................59-55
ReportObject .........................................36-17 Routing ....................................................50-4
ReportObject-Property (text parameter) ... Row height (query) ...............................24-3
46-7 Row report ............................................46-26
Report-to-Excel ......................................37-1 Rqmt ......................................................45-30
Request ....................................................61-1 Rqmts .....................................................45-30
- implementing requests ......................60-3
Run case ..................................................5-24
- Preparing a request ............................61-3
- Change run case .................................10-9
Request and security .............................64-9
Run cases
Request attributes ................................64-30 - controlling via objects .....................12-10
Request implementation (query) ..... 64-25, - copying ................................................8-44
64-67
Request implementation query) ........64-20
Requests ................................................64-66 S
Reset .......................................................13-12
- Columns .............................................13-10 S7 / HW config ....................................64-62
RestoreReferencesAfterCopy ............46-50 S7 project ................................................56-5
RestoreRequest .....................................22-11 Save
Return objects .........................................11-7 - DWG/DXF ........................................25-17
- TIFF/PDF ..........................................25-17
RevColumnNr ..........................41-32, 41-33
Save as DWG/DXF .............................25-17
Revision .............................10-21, 32-1, 41-1 Save automatically ................................10-3
- Revision archive .....................5-17, 41-20
- Revision environment .....................41-40 ScaleForObjects .......................46-51, 47-20
- Revision index ....................................41-6 Scaling ...................................................43-14
- Revision monitoring ..........................41-9 Scaling of placed files .........................46-21
- RevisionObject (Script) ..................41-32
- RevisionTableDate (Script) ............41-32 SCGlobal ...............................................36-16
- RevisionTableDescription (Script) ........ Scheme
41-32 - in bulk processing ..............................26-3
- RevisionTableIndex (Script) ..........41-32 - save under ...........................................26-4
- RevisionTableUser (Script) ............41-32 - Scheme per object ...............13-11, 13-13
- RevLine (Script) ...............................41-32 - Screen scheme ..................................13-11
- Standardabfrage Dokumente ..........25-16 Schrankplan
- Timestamp .........................................41-12 - Reportvorlagen .................................63-12
Ridged bridge .......................................59-67 Screen scheme ......................................13-11
RIDIVPOS ............................................48-20 Script ............................................10-15, 15-8
RIFLOWDIRSYMBOL .....................48-20 - at base object ....................................12-26
Rights list ................................................6-22 - bulk processing ..................................44-1
- For the attribute properties tab ......16-19
Rights management .................................6-1 - Query revision data .........................41-32
Rights tab ................................................6-21 - Script- modules ................................36-14
RILNTYPE ...........................................48-20 - symbol script ....................................45-36

- Text type Script ......... 46-7, 46-12, 46-19 - QuadrantStepX ................................ 46-39
Script (Tab) ............................................ 15-8 - QuadrantStepY ................................ 46-39
- RestoreReferencesAfterCopy ....... 46-39
Script error handling ............................. 22-1
- ScaleForObjects .............................. 46-39
Script options ....................................... 46-36 - SectorOffset ..................................... 46-39
Script tab ............................................... 16-19 - SectorSize ......................................... 46-39
ScriptOption - ShowConnectedWith ...................... 46-39
- ShowConnectionInfo ...................... 46-39
- AnsiWiringRadius ........................... 46-37
- ShowLineModeControl .................. 46-39
- Application ....................................... 46-37
- AutoConnectExternObjects ........... 46-37 - ShowSymbolBar ............................. 46-39
- SideView_X ..................................... 46-39
- AutoDistributeTerminals ............... 46-37 - SignalLeftX ...................................... 46-39
- AutoLoop .......................................... 46-37
- SignalRightX ................................... 46-39
- AutoLoopCables .............................. 46-37
- SignalSlotCount .............................. 46-39
- AutoLoopConnectorLayers ........... 46-37
- SignalSlotHeight ............................. 46-39
- AutoLoopDebug .............................. 46-37
- SignalTopY ...................................... 46-39
- AutoLoopFactor .............................. 46-37
- SignalWidth ..................................... 46-39
- AutoLoopFilter ................................ 46-37
- SignalWidth1 ................................... 46-39
- AutoSaveDocument ........................ 46-37
- SignalWidthGraphic ....................... 46-39
- AutoStartLoop ................................. 46-37
- SignByEmptyReference ................. 46-39
- CableObjectVersion ........................ 46-37
- SnapPrecision .................................. 46-39
- CheckDocObjects ............................ 46-37
- SortNewObjectsInCategories ........ 46-40
- CheckIOConsistency ...................... 46-37
- StdPipeFlagNoColor ...................... 46-40
- CObjectFullNameForPipe ............. 46-37
- StdPipeNoReflect ............................ 46-40
- ConcessionRI ................................... 46-37
- SuppressReference .......................... 46-40
- ConnectionHook .............................. 46-37
- SymbolType ..................................... 46-40
- ConnectionLineMode ..................... 46-37
- Unit .................................................... 46-40
- ContactMirror_X ............................. 46-37
- VGBConnectionLength ................. 46-40
- ContactMirror_Y ............................. 46-37
- WorkingBackupTime (Double) .... 46-40
- CopyConnectionDependentObjects ...... - XXDocProgID ................................. 46-40
46-37
- CutLineWidth .................................. 46-37 Script-oriented drawing ..................... 46-33
- DefaultIdRectsForSymbols ........... 46-37 Search ...................................................... 25-7
- DeleteModePFD .............................. 46-38 Search (mouse menu) ........................... 10-8
- DimensionSymbol ........................... 46-38
- DimensionTextHeight .................... 46-38 Search at once ........................................ 25-7
- DimensionUnit ................................. 46-38 Search object .............................. 64-6, 64-19
- DrawPipeConnectorSymbol .......... 46-38 Search objects ...................................... 64-63
- DrawPipeEndSymbol ..................... 46-38 Search strings ....................................... 57-59
- DrawPipeEndSymbolForSegment 46-38
- DrawTerminalSideMark ................ 46-38 Search text ............................................ 47-18
- EnableButtonANSICable ............... 46-38 Searching for documents ................... 25-14
- EnableButtonOblique ..................... 46-38 Second access .......................................... 3-6
- EnableButtonSpline ........................ 46-38
- EnablePaging ................................... 46-38 SectorOffset ......................................... 46-51
- EnableProcessConnection .............. 46-38 SectorSize ............................................. 46-51
- EnableProcessConnectionActor ... 46-38 Segment ........................ 10-17, 57-13, 64-48
- EnableProcessConnectionSensor .. 46-38 - direction ............................................ 64-49
- EnableSynchronizeNavigator ........ 46-38 - limits .................................................. 64-50
- EXFConformable ............................ 46-38 - properties .......................................... 64-49
- GeneralScaleFactor ......................... 46-38
- ListMaster ......................................... 46-38 Segment separative ............................. 57-15
- PotentialProlongation ..................... 46-38 Segmentation (Automatic Placing) .. 64-48
- PreferredDirection ........................... 46-38 Segmenting pipes ................................ 57-15
- QuadrantOffsetLeft ......................... 46-38
- QuadrantOffsetTop ......................... 46-38 Segments .............................................. 57-13
- QuadrantSizeX ................................. 46-39 Select ....................................................... 10-4
- QuadrantSizeY ................................. 46-39 Select page in the template file ........... 46-1
- QuadrantStartChrX ......................... 46-39 Select report template ..... 14-3, 14-4, 49-24
- QuadrantStartChrY ......................... 46-39

Selection ..................................................10-5 Signal list ........................57-10, 64-3, 64-38
Separate functions into blocks (script) ...... Signal list (hardware) ............................64-3
12-31 Signal Manager ....................................64-58
Separator character for import .............33-7 Signal name matching ........................64-58
Separators ................................................65-9 Signal of owner ....................................64-57
Server database export ..........................3-11 Signal tracking .......................................5-18
Set (status) ...............................................21-4 Signal tracking (option) ......................64-27
Set auxiliary connectors .....................13-16 Signals acc. to IEC 1175 ....................64-51
Set base object ........................................13-3 SignByEmptyReference .....................46-53
Set up worksheet ....................................46-5 Simatic S7 ...............................................56-1
SetItemObject .......................................46-30 Simulators ...............................................51-1
SetLang ..................................................30-14 Single selection ......................................10-5
SetLicPath .............................................30-14 SLINE ........................................64-16, 64-41
SetLineWrap .........................................46-26 Slot .........................................................10-21
SetScriptUnit (spec-script) .................22-23 Slots .........................................................65-6
SetScriptValue (spec-script) ..............22-23 Smartsketch (Properties window) .......14-6
Setting attributes through bulk processing SMS
26-6 - ptmcast.exe .......................................30-14
Setting objects manually ....................49-24 Snap to (connections) ...........................47-1
Setting origin ........................................46-19 SnapPrecision .......................................46-54
Settings ..........................................10-3, 46-5 Snap-to grid (reports) ............................43-7
SetWireNumberByCoord ...................59-32 Soft (option with texts) ...........43-12, 47-15
Shileded cables Software
- changing in the diagram .................59-54 - Input .....................................................65-8
ShowConnectedWith ..........................46-51 - Output ..................................................65-8
ShowConnectionInfo ..........................46-51 Sort (query) .............................................24-6
ShowLineModeControl ..........46-52, 59-46 Sort alphabetically .................................10-3
ShowSymbolBar ..................................46-52 Sort by... (elements) ..............................13-8
SI unit ..........................................11-4, 46-15 Sort Document .......................................5-21
SideView ...............................................46-52 Sorting ...................................................59-59
SI-Einheit ................................................11-5 Sorting text (tab) ....................................15-7
Signal ...........................................10-21, 65-7 SortNewObjectsInCategories ............46-54
- base object ...........................................50-6 Spaces ......................................................5-16
- form ......................................................65-8 Specification
- level ......................................................65-8 - definition .............................................15-1
- manager ...............................................2-12 - Tab Attributes ....................................13-4
- preparing ..............................................49-7
- Signal Manager ..................................55-1 Specifications .........................................19-1
- SignalLeftX .......................................46-52 - tab .......................................................12-16
- SignalRightX ....................................46-52 Specifications with graphical relevance ...
- SignalSlotCount ...............................46-53 12-25
- SignalSlotHeight ..............................46-53 SpecUnit ................................................33-11
- SignalTopY .......................................46-53
- SignalWidth ......................................46-53 SpecValue .............................................33-11
- SignalWidth1 ....................................46-53 SPS addresses .......................................22-24
- SignalWidthGraphic ........................46-53 SQL Server ...............................................3-1
- type .......................................................65-7
- types ...................................................65-11 S-references ..............................................8-5
Signal data ...............................................65-7 Stammobjekt für Rohrleitung ............57-14
Signal from owner ...............................57-38 Stammobjekt für Rohrleitungsabschnitt ...

57-14 Substance streams ............................... 57-52
Standard catalogs .................................. 53-3 Sub-symbols ........................................ 45-32
Standard layers .................................... 43-16 Subsymbols ............................................ 11-3
Standard loop ............... 64-29, 64-39, 64-53 - alarm/ relevance displays ............... 57-40
Standard queries (definition) ............... 23-3 Subtype (connector) ........................... 12-21
Standard query Suffix ....................................................... 5-23
- attributes ............................................ 25-19 Supplier ................................................. 59-59
- base objects ...................................... 25-12 Suppliers
- connectors ......................................... 25-21 - copying ............................................... 8-44
- documents ......................................... 25-13
- picklist values ................................... 25-24 Support ............................................ 2-9, 3-17
- plannijng objects ................................ 25-7 Support (DB identifier) .......................... 3-7
Standard table ........................................ 16-5 SuppressReference .............................. 46-54
- @DRW_TYPE .................................. 31-9 Swap (wires) ........................................ 13-12
- copying ...................................... 8-34, 8-44 Switching bridge ................................. 59-67
- Definition ............................................ 11-1
Sychange .............................................. 30-15
Standard tables ....................................... 11-1
Sychange.exe ......................................... 3-14
standard unit ........................................... 11-4
Symbol
Start object .............................................. 25-7
- hierarchy ............................................. 45-3
Start object (bulk processing) ............. 26-3 - Isometric drawings ............................ 53-7
Start object (data matrix) ................... 24-27 - layer and label .................................... 45-2
Static link .................................... 16-14, 19-8 - script .................................................. 45-36
- script header default commands ... 45-36
Static value ........................................... 16-14
Symbol Designer
Status ........................................... 3-19, 15-10 - Align .................................................. 43-15
- automatic status change .................... 21-7 - circle/segment .................................... 43-9
- edit group Status (base object) ...... 12-15 - cross-hatching .................................. 43-12
- Status calculation log ........................ 21-7 - expanded design mode ..................... 43-9
- Status display ..................................... 21-5 - Lines .................................................... 43-8
- Status Management ........................... 21-1 - mirror ................................................ 43-14
- StatusInfo ............................................ 21-4 - move .................................................. 43-13
Status (object) ........................................ 6-24 - rotate .................................................. 43-13
Status display ......................................... 10-3 - scaling ............................................... 43-14
Status line ............................................. 43-15 Symbol Editor
- Default settings .................................. 45-1
Status management (rights) ................. 6-25 - toolbar ................................................. 45-3
StdPipeFlagNoColor ........................... 46-54 Symbol file ............................................. 11-3
StdPipeNoReflect ................................ 46-54 Symbol files (def.) ................................ 62-1
Step ........................................................ 10-18 Symbol path ......................................... 12-24
Step (data matrix) ................................ 24-28 Symbol preview .................................... 10-4
Stop (Import) .......................................... 33-4 Symbol texts
Stretch ................................................... 43-14 - Parameter setting ............................... 45-3
Stretching of graphics ......................... 46-21 Symbol types ......................................... 45-1
StrField .................................................. 33-12 Symbol-Designer
Strip tab ................................................. 13-14 - stretch ................................................ 43-14
Structure (create option) .................... 12-12 - Text .................................................... 43-11
Structure differences ............................. 8-47 Symbole .................................................. 11-3
SymbolRotationByDimension .......... 53-30
Structure tree (definition) .................... 49-2
Symbols
Subelements ......................................... 52-14
- drawing vs. scripting ........................ 45-3
Subelements (creation mode) ............ 12-13 - in standard tables ............................... 45-3
Subreports ............................................. 64-32 - space .................................................... 45-2

Symbols for views (DESIGN) .............63-5 Template reference ..................................7-4
SymbolType .........................................46-54 Templates ................................................5-15
Synchronization ...............................3-7, 3-8 - Defination ...........................................52-1
- Preparation ..........................................52-1
Synchronize database ............................3-10
Terminal ................................................10-17
Synchronize database version ..............3-17
Terminal strip ...10-19, 64-64, 64-72, 64-74
Synchronize project folder ...................30-1
Terminal strips / plug strips ...............59-59
SYS System information ......................64-8
test ............................................................2-11
SYSISO .................................................53-17
Test list ....................................................30-5
System (tab) ............................................12-1
Text ............................................24-23, 43-11
System data
- for signals ............................................65-7 Text (Properties window) ....................14-6
System Monitor ......................................3-20 Text (symbols) .....................................12-26
System project ..........................................5-1 Text allocations ....................................46-12
Systems of units .......................................2-9 Text color ..............................................19-14
SystemUID ...........................................30-11 Text file
- Import ..................................................33-1
Text file (Import) ...................................33-7
Text functions ........................................45-6
T Text masks ..............................................12-5
Tab Text symbol ..............................45-32, 64-16
- attributes ............................................12-16 Text variables (of signals) ....................65-9
- Connectors ..........................................13-8
- connectors .........................................12-20 ThickLine ................................................37-2
- Elements ............................................12-17 ThinLine ..................................................37-2
- Function data ....................................57-26 three-level pipe structure ....................57-11
- Process connection data ..................57-29
- RI Presentation .................................57-25 Tiff .........................................................41-21
- Script (attribute) ...............................16-19 Tiff documents (Properties window) .14-6
- Script (attributes) ...............................15-8 Tiff/PDF file, saving ...........................25-17
- scripts .................................................12-26 Time .......................................................10-22
- Specification .......................................13-4
- Specifications ...................................12-16 Time (monitoring) .................................3-25
- Strip ....................................................13-14 Time interval ..........................................3-26
- Substance data ..................................57-27 Timestamp ............................................19-14
- SYS System information ................57-24
- System ..................................................12-1 Timestamps ..........................................41-12
- usage ..................................................12-31 tmp file ....................................................14-5
- Wires ..................................................13-12 tmp files ..................................................30-2
Table synchronization ...........................3-15 ToDoc ....................................................45-30
Tabs ToDocObj .............................................45-30
- "3D Geometry" .................................53-15
Tooltip ...................................................16-20
Tag symbols ................................53-8, 53-20
Total objects ...........................................3-23
Target attributes .....................................19-8
Transforming ........................................43-13
Target object (data matrix) .................24-27
Transition ..............................................10-19
TD data records (ECAD) ......................58-2
Translation
Tear off (mouse menu) .........................10-8 - Comos DB ..........................................2-11
Template ........................................49-8, 52-1 - Exclusion ...........................................42-22
Template branch ..........................49-8, 52-1 - Object description ..............................2-11
template file ..........................................49-22 - object description ...............................2-11
Transparent ...........................................43-11
Template project
- copying data ........................................2-12 Tree structure (definition) ....................49-2

Triga drawings (Properties window) . 14-6 UserScriptBlock1 (E/I&C script) ..... 57-45
Troubleshooting UserScriptBlock2 (E/I&C script) ..... 57-46
- Object test ........................................... 30-5 Using I&C ............................................ 64-50
TSVA .................................................... 64-64 Utility program
TSVE_JD .............................................. 64-64 - MultiCRP.exe .................................... 44-1
TV_RV .................................................. 64-64 Utility programs
Type ......................................................... 16-5 - global test ........................................... 30-8
Type of display ...................................... 16-1
TypInfo ................................................. 13-10
V
Value Control Type .............................. 17-2
U Variable
- Input .................................................... 65-8
Undo Comos objects ............................. 33-4
- Output ................................................. 65-8
Unique label ......................................... 12-11 vbscript.dll ........................................... 12-30
Unit ........................ 10-15, 16-5, 17-2, 46-55 Version .................................................... 3-17
Unit (convert) ....................................... 30-13 Version management .......... 3-7, 3-16, 39-1
Unit (KKS) ............................................. 57-9 Vertical (Tabs) ....................................... 10-4
Unit Control Type ................................. 17-2 VGBConnectionLength ..................... 46-55
Unit conversion ..................................... 30-4 Via linked object (link type) ............. 16-12
Unit pointer ............................................ 13-2 Via linked object (link) ...................... 16-12
- Kopy ...................................................... 8-4
View
Unit prefix .............................................. 5-16 - DESIGN diagram .................... 63-1, 63-3
Unit structures ........................................ 57-9 - placing ................................................. 63-2
Unit systems ........................................... 11-3 View/Slice .............................................. 63-3
- copying ................................................ 8-34 Viewing license ....................................... 6-2
Units Views ............................................ 10-9, 50-7
- copying unit groups .......................... 8-44 - installation diagram ........................ 63-21
- Unit conversion .................................. 11-5
- Unit groups ............................... 11-3, 11-4 Virtual ................................................... 12-14
Universal access ...................................... 3-1 Virtual elements .................................. 12-18
Unlock ..................................................... 13-1 Virtual table ........................................... 23-1
Update (context-sensitive menu) ...... 13-11 Visible for all users ............................. 12-10
Update connected devices ................. 57-32 Visualization element ......................... 10-19
Update connected devices later on ... 57-32 vrg files ................................................... 58-2
Update static link ................................. 57-32 VSUI bar
- dynamic control ............................... 53-17
Update values ......................................... 13-4
VSUI spec ............................................ 53-17
Update versions ..................................... 3-15
Use complete structure name .............. 5-22
UseAliasForLabelFunctions .. 49-14, 49-17
User (CS) .............................................. 41-32
W
User (CVS) ............................................. 3-27 W connector ......................................... 57-37
User address ......................................... 10-16 Warning notes ...................................... 64-82
User current ............................................ 42-4 Wildcards ............................................... 12-5
User list ................................................... 6-17 Windows
User name ................................................. 3-1 - options ................................................. 2-13
UserFunction ........................................ 45-30 Wire ....................................................... 10-17
- connector .......................................... 12-21
UserScript (script) ............................... 22-12

Wire bridge ...........................................59-67
Wire information ...................................2-12
Wires ..........................................13-10, 13-12
- Break ..................................................13-10
- Cut ......................................................13-10
- Paste ...................................................13-10
- Preparing .............................................49-5
- Swap ...................................................13-12
- Tab ......................................................13-12
With DB synchronization .....................3-13
Without deleted objects ................3-8, 3-13
Word ........................................................36-9
- linking ..................................................36-1
Word (Properties window) ...................14-6
Working area ......................6-11, 15-8, 16-6
- assign base object ............................12-10
- Determining ......................................46-19
- Move ....................................................43-2
Working area (tab) .................................15-8
Working areas ........................................32-1
Working areas (definition) .....................6-4
Working height ......................................63-4
Working mode (decision table) ...........28-4
WorkSet .....................................33-13, 36-17
Write (option for connections) ..........59-46
Write (right) ..............................................6-6
Write to standard table ..........................12-8
X
xlFoldermargin .......................................37-1
XML .......................................................24-23
XML display ...........................................36-2
XXDocProgID ......................................46-56
Z
Z Mounting ...........................................64-11
ZB data records (ECAD) ......................58-2
Zone .........................................................5-23
Zoom ........................................................43-2

C Programme Comos Help ENGLISH HelpMenu Manual

Uploaded by

Copyright:

Available Formats

C Programme Comos Help ENGLISH HelpMenu Manual

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

C Programme Comos Help ENGLISH HelpMenu Manual

Uploaded by

Copyright:

Available Formats

Imprint

2006 innotec GmbH

Comos Hotline Support:

Manual - HB82E07 Status: June 21, 2006

© 2006 innotec GmbH

© 2006 innotec GmbH 1

2 © 2006 innotec GmbH

4 WORKING LAYERS / PROJECT HISTORY

© 2006 innotec GmbH 3

4 © 2006 innotec GmbH

© 2006 innotec GmbH 5

6 © 2006 innotec GmbH

© 2006 innotec GmbH 7

10 DISPLAY IN THE NAVIGATOR

8 © 2006 innotec GmbH

12 PROPERTIES: SYSTEMTYPE CDEVICE

© 2006 innotec GmbH 9

13 PROPERTIES: SYSTEMTYPE DEVICE

10 © 2006 innotec GmbH

14 PROPERTIES: SYSTEMTYPE DOCUMENT

© 2006 innotec GmbH 11

12 © 2006 innotec GmbH

18 PROPERTIES: LIST ATTRIBUTES

19 USING AND LINKING SPECIFICATIONS

© 2006 innotec GmbH 13

20 INSTANCES (REDUCING THE NUMBER OF OBJECTS)

22 SCRIPT FUNCTIONS OF COMOS OBJECTS

14 © 2006 innotec GmbH

© 2006 innotec GmbH 15

16 © 2006 innotec GmbH

© 2006 innotec GmbH 17

18 © 2006 innotec GmbH

27 QUERIES - PROGRAMMER’S VIEW

29 OLD PROCESSING TECHNIQUES

30 TOOLS AND UTILITY PROGRAMS

© 2006 innotec GmbH 19

31 SYSTEM PROJECT: STANDARD TABLES

20 © 2006 innotec GmbH

32 BASE OBJECTS OF THE SYSTEM

© 2006 innotec GmbH 21

33 IMPORT VIA ACTION OBJECTS

35 AUTOCAD (IMPORT, EXPORT DXF)

22 © 2006 innotec GmbH

36 CDI (COMOS DOCUMENT INTERFACE)

37 RNE (REPORT TO EXCEL)

© 2006 innotec GmbH 23

24 © 2006 innotec GmbH

40 DOCUMENT MANAGEMENT (DQM)

© 2006 innotec GmbH 25

26 © 2006 innotec GmbH

© 2006 innotec GmbH 27

28 © 2006 innotec GmbH

© 2006 innotec GmbH 29

30 © 2006 innotec GmbH

© 2006 innotec GmbH 31

32 © 2006 innotec GmbH

© 2006 innotec GmbH 33

34 © 2006 innotec GmbH

47 DESIGNER AS INTERACTIVE REPORT

© 2006 innotec GmbH 35