|
<< Click to Display Table of Contents >> Configuration of revision comparisons |
  
|
|
<< Click to Display Table of Contents >> Configuration of revision comparisons |
|
When doing a comparison, it is necessary to define identities for the objects that are going to be compared. This is a requirement to make it possible to determine whether two different objects means that an old object has been removed and a new one added, or if an existing object has been changed.
This identity is defined in the way that is described in the table below.
Object |
Identity |
Devices |
The item designation is used as identity. |
Wires |
The item designation combined with the connection number of both ends, where the two ends are sorted, is used as identity.
Example:
From =A1+E1-K1:A1 to =A1+E1-X1:1
If a wire would be connected in the other direction in the next revision, like shown below, it would still be regarded as the same wire, since the ends are first sorted.
From =A1+E1-X1:1 to =A1+E1-K1:A1
|
Cable cores |
Exactly the same identity definition as for wires is used. |
The revision comparison is a process where the objects of the old and the new revision are divided into three categories:
1.Objects present in only the old revision (removed objects)
2.Objects present in only the new revision (added objects)
3.Objects present in both the old and the new revision. These objects may be unchanged or changed.
The new and the old version of the objects in the latter category, are finally compared with each other to find out if they have been changed or not. Which properties that should be part of this comparison are defined in a configuration that the user can alter.
The setting at delivery is described in the table below.
List |
Compared properties |
Device list |
Index Quantity |
Wire list |
Wire number Dimension Colour Signal name Node name |
Cable core list |
Cable item designation Cable core number Index of the cable Electrical data of the cable (cable type) |
This setting is made in an INI-file called REVISION.INI, which is located in the \ELSA\SYSTEM directory.
REVISION.INI is divided in three sections:
•[ITEM] for the device list
•[WIRING] for the wire list
•[CABLE] for the cable core list
The picture below shows the content of REVISION.INI at delivery, which is consistent with the table above.
Figure 1660: The content of REVISIONS.INI at delivery
The properties are represented by field names from the TARGET databases that are involved. These field names are the same as are part of the report variable definitions that are found in the Report Generator and which are well-documented. There is one exception from this however, and that is the item designation of cables that is represented with a slightly more complicated expression:
#QUELLDWG_1#BKZ_ARB
This means that this property is fetched from *5.DBF (the “*G.DBF” of revision reports) using a key from *9.DBF (the directly referred TARGET database).
This technique can be used for other properties stored in *5.DBF as well.
The user can edit REVISION.INI to remove or to add properties. If a property of an object is different in the old and new revision but that property is not part of REVISION.INI, the change in question will be disregarded.
cadett is happily providing services regarding customization of REVISION.INI, report definitions for lists of changes or other matters regarding revision handling.