Transfer of Curved Members

New straight linear members may be replaced by GENSECs according to the !!bocSCTNtoGENSEC flag. Members that are already SCTN elements in the model will not be changed.

Comparing GENSECs is only down to the point count level on the spine. The actual point attributes are not investigated, except for the start and end points. If there are the same numbers of POINSP and CURVE members respectively these are checked. Any alteration to these numbers will indicate changes. They must be inspected visually for comparisons. The re-imported CURVE element are likely to have changed because we only import 1 type - a THRU point, although there are 6 or 7 different types of CURVE points in the base product, each with different attribute combinations.

Version Numbering

The management of the attributes relevant to version numbering and revision control, that is :FABREVNO, :FABTRANO and :FABTRRVNO, is all performed in the base product user interface. The values of these attributes are not taken from the file. The header is used to transfer the main TransferLetter from the Configuration object, but the individual items are managed as described below.

The Configuration object should not be confused with the Header object. The former is used to store transfer indices - counts of Transfer Numbers and Revision numbers. These are for the whole database. The latter is used to store specific information pertaining to the transfer in question - for example: client information.

Because of the fact that the base product may be multi-user and that several user’s may be concurrently accessing the design databases at any one time, there may be several Configuration objects, one for each possible MDB:User combination. At the start of the Export or Import process, a poll is taken of ALL these Configuration objects to determine which is the highwater mark. That is, which is the highest Transfer Number, or Revision Number. We then take that and modify the Configuration object for the current MDB:User. In this way, by polling all objects, we can determine the latest values.

The rules of precedence for the Transfer and Revision numbers are that a Transfer is higher. So that "A.2" is later than "A.1" and "B.1" is later than "A.9".

Note:
The UDA, :FABTRANO, is actually an index into a character string returning the equivalent character as the TransferLetter.

Note:
This TransferLetter is cycled. As it passes 'Z' it will be succeeded by 'A'.

If there are more than 26 Transfers, the letter is recycled so that there may be slight problems at the wrap around.

Below are the rules by which the revision numbering is handled by the interface.

• Each Transfer has a Letter - A...Z

• Each Revision has a Number - 1,2,3...

• Each SITE, SCTN and PANE has 3 UDAs attached

• A TransferLetter for example: 'C',

• A RevisionNumber for example: '2'

• A TraRevNumber - A character-wise concatenation of the previous two, for example: 'C.2'

On Transfer into the Base Product

• If an entity (SCTN, GENSEC or PANE) has been changed or is new, set its TransferLetter to be that of the owning SITE and note that there is at least 1 changed item.

• Update the entity's (SCTN, GENSEC or PANE) RevisionNumber to be the incremented value of that of the owning SITE, because we haven't yet changed the latter.

• Increment the SITE's RevisionNumber, for example: '0' to '1' if any imported entities have changed.

Exclusions

This section lists the exclusions which have been identified.

Penetration Holes: The interface does not allow the description of holes within Linear Members.

Templates: Catalogues are not covered by Linear members and Plates contained in Templates or Groups will be transferred on export. There is no facility for constructing a new Template or Group on import. Elements that are in pre-existing Templates or Groups will be compared and merged, but new elements will not be placed in the same container.

Non-prismatic end details: Linear members in the current interface exchange format cannot describe any details at member/cleat ends apart from full orthogonal cuts. Hence, all sloped cuts, notches, will be approximated from minimum to maximum local longitudinal co-ordinate, which should be conservative regarding clash detection. The interface only transfers fully prismatic Plates. Hence, the Plate cuts/intersections which are not fully orthogonal to the Plate's local plane cannot be transferred. Such Plates will be exported 'uncut', which again should be conservative for clash detection.

Issues

The interface allows only for the transfer of a character descriptor for a Profile. For a successful data transfer, there will need to be co-ordination between users of each package to make sure that the geometric description associated with the catalogue name is identical and that there is a means of correlation between the packages.

In the base product, the structural model may contain two views of the data: one view defined by logical connectivity by references to the connecting items; and the physical view defined by the relative location of items. So, while we may logically relate two items, they may not necessarily be physically close to each other. Thus, transferring the model will necessarily involve the loss of real connectivity information which will be difficult to reconstitute correctly on Import.

The interface will output a warning message when sections are met which cannot be handled or are unexpected.

The double quote character " in text fields, particularly in profile names is not allowed. This can cause problems with imperial sized items in the catalogue that use the character to indicate inches. It is not allowed in ANY text fields.

Units

This is a statement of how the interface handles units.

1. Has a minimal set of unit definitions. ("feet", "meters", "inches","millimeters")

2. Exports in mm, that is the units exported in the file are mm.

3. Imports all units from internally. It reads any file unit (according to the "standard"), but...

4. The interface then converts the input units to mm prior to writing an input "macro", so the model in the ABS file is therefore in mm.

5. To support this, the interface environment, switches units to MM DIST, and UNITS DEGREES units prior to export and import.

6. Because of the way the interface handles UNITS, the original units cannot be restored to be precisely what they were before.

7. Therefore, after an export or import transaction, the units will be set to MM DIST/MM BORE/UNITS DEGREES.

The AVEVA Bocad Steel Interface attempts to keep the behavior of the system as consistent as possible across versions of the base product. Holes are always imported as NXTR elements because the interface does not do any shape recognition. This highlights a possible issue in exporting a model and re-importing. While a secondary PLOO would represent a hole, this would have to be represented on import as a negative extrusion, NXTR. So round tripping data will cause secondary PLOO elements as well as other negative primitives, to be converted to NXTR elements.

When importing into an empty area and using the "Import linear members as GENSECs" option, straight members may not be converted to GENSECS. This often occurs with a file that was previously exported from another base product model. The UUID attribute on the imported element may refer to an element with the same database reference number in the current model. Do not use the option to convert all straight members into GENSECs when importing a file containing elements that originated in the base product.