Items added to the model are recorded as such; they are indicated by changing their colour, a suitable message is output to the log file and they are then transferred to a special area. Merging will transfer all the added items from the reference model to the original model. If required, they are then sorted according to material type.
The new items are gathered together into a site whose name is constructed from the Transfer and Revision Numbers so that you can easily locate all items added at a specific version or date.
For example, a new STRU may be created with the name of /FAB-NEW-DEMO-SYSTEM/A.1 under the container element as specified in the Store in: field on the Import window. The components of this name are as follows:
the system prefix
identification of new element container
the current MDB, for example: /DEMO
the current user name, for example: SYSTEM
the current Transfer letter, for example: 'A'
the current revision number, for example: '1'
You would thus be able to find all the added items to this MDB at this version.
/FAB-

the system prefix
NEW-
identification of new element container
<mdb name>-
the current MDB, for example: /DEMO
<user name>-/
the current user name, for example: SYSTEM
<transfer nr>.
the current Transfer letter, for example: 'A'
<revision nr>
the current revision number, for example: '1'

Import
/
NEW-
<mdb name>-
<user name>-/
<transfer nr>.
<revision nr>


Deleted items in the model are recorded as deleted during the Compare phase and remain in the reference model to be deleted later if not required. This separation of operations is so that you can see what will be deleted during the Merge process. Before deletion the objects are changed in colour so that they may be identified.
'Deleted' items are disconnected from the old model and transferred from the current part of the database into a STRU created under the special 'Deleted' SITE.
As with the added items, the STRU is named out of components, thereby enabling you to determine at which version items may have been removed from the model.
For example, a new STRU may be created with the name of /FAB-OLD-DEMO-SYSTEM/A.1 under the special SITE /FAB-OLD-DEMO-SYSTEM. The components of this name are as follows:
the system prefix
identification of new element container
the current MDB, for example: /DEMO
the current user name, for example: SYSTEM
the current Transfer letter, for example: 'A'
the current revision number, for example: '1'
You would thus be able to find all the 'deleted' items to this MDB at this version.
/FAB-
the system prefix
OLD-
identification of new element container
<mdb name>-
the current MDB, for example: /DEMO
<user name>-/
the current user name, for example: SYSTEM
<transfer nr>.
the current Transfer letter, for example: 'A'
<revision nr>
the current revision number, for example: '1'
Note:
An item is not actually deleted from the original model. The apparent deletion may, in fact, be because the item was never transferred to AVEVA Bocad Steel in the first place due to some reason. Alternatively it may have been created in the base product since the initial Export process had taken place.

Note:
/
-
OLD-
<mdb name>-
<user name>-/
<transfer nr>.
<revision nr>


In merging plates the interface tries to keep the original vertices as they may have been used for locating dimensions on drawings: it may be that just the positions have been changed. However, the comparison only works in list order: the interface does not look around for another vertex in the same physical place, although it may be in a different list position. Extra unwanted vertices are deleted on merging and all new vertices are added to the end of the list. A totally new Plate is just imported directly.
Note:
Changed objects are indicated as such by a change in colour.

Note:


WARNING: Reference SITE
nnnn contains transient data
The reference SITE is likely to be deleted some time.
Model comparison
completed
Process was successful.
Failed to compare models
Do they both exist?
WARNING: Reference SITE
nnnn contains transient data
The reference SITE is likely to be deleted some time.
Model comparison
completed
Process was successful.
Failed to compare models
Do they both exist?

WARNING: Reference SITE
nnnn contains transient data
The reference SITE is likely to be deleted some time.
Model comparison
completed
Process was successful.
Failed to compare models
Do they both exist?

WARNING: Reference SITE
nnnn contains transient data
Model comparison
completed
Failed to compare models


As has been described in Comparison and Merging Processes there are two validation checks you can perform prior to the full import and merging of models.
The first option is for profile mapping. The Profile Mapping? Option on the Run Information window turns this on. The Import process initializes normally and calls the external program to process the incoming file. In so doing it checks for a complete mapping of the profiles in the mapping tables. A log file is produced. No further Import actions are undertaken with this option.
Second, you can check that there are not any duplicate UUIDs. This can quite easily come about if you copy members in AVEVA Bocad Steel without creating unique UUIDs for them. When they are imported into the base product, the Comparison process may fail as it could be uncertain as to which member it is supposed to be comparing.
The options for this check are NEW and GLOBAL. NONE turns the facility off. NEW checks among all this run's imported members contained in the reference model for duplicate UUIDs, while GLOBAL checks the whole structural database, both imported and existing elements. These can be quite slow options as the reference model must be created and compared anyway.
As this option also calls the external program which checks the mapping of profile names between systems, you will see that the log file may also list any problems with the mapping tables. So this option is actually a combination of this and the previously mentioned validity checking option. For a sample log file, refer to Sample Validity Check Log File for further information.

Comparison and Merging Processes
Sample Validity Check Log File
Comparison and Merging Processes
Run Information
Sample Validity Check Log File


You can display a Highlighter window from either the Import or Export windows by the General > Highlight menu bar option.
The window allows you to identify in a graphical window whatever they want, either according to Import date, or by Transfer/Revision number combinations. The Select by toggle switches the window into the appropriate mode. Both these options work from the start element selected and will indicate only those items that are in the drawlist.

Highlighter
Import
Export


The window below allows you to choose what to enhance on the screen according to the Import Date of an item.

In the Selected items box, you can select any combination of Added, Changed, or Deleted Items for identification, according to the date range described below.
By selecting the inclusive dates defining the limits of the range using the From and To date selector gadgets you can locate on the screen those items in the current drawlist which have been changed, added or deleted.
Note:
As the 'deleted' elements are relocated in the database after Merging, the area where they are finally located should also be in the drawlist if you want to see what has been 'deleted'.

Note:


The window below allows you to choose what to indicate on the screen according to the Version of an item.

The functionality available to select changed, deleted or added items is identical to that for highlight by import date, refer to Highlighting by Import Date for further information.
By selecting the versions defining the limits of the range using the From and To version selector gadgets you can identify on the screen those items in the current drawlist which have been changed, added or deleted.
Note:
As the 'deleted' elements are relocated in the database after Merging, the area where they are finally located should also be in the drawlist if you want to see what has been 'deleted'.

Highlighting by Import Date
Highlighting by Import Date
Note:


Bad date input
The configuration of day, month and year is illegal. Or is the start date after the end date?
Bad version input
Is the start version after the end version?
Nothing to highlight
Nothing satisfies the selection criteria.
Bad date input
The configuration of day, month and year is illegal. Or is the start date after the end date?
Bad version input
Is the start version after the end version?
Nothing to highlight
Nothing satisfies the selection criteria.

Bad date input
The configuration of day, month and year is illegal. Or is the start date after the end date?
Bad version input
Is the start version after the end version?
Nothing to highlight
Nothing satisfies the selection criteria.

Bad date input
Bad version input
Nothing to highlight


This section contains technical information which is not immediately specific to Products but of which you should be aware in order to get the best out of the interface.


Although it is not critical for this interface, the recommended suffix for the files is to be abs.


Below is a diagram illustrating the positions of the Cardinal Points.
The Cardinal Point imported should be retained for later export. This is because it is likely to be a source of confusion when a member originally laid out on Cardinal Point 14 (Top of Steel) is returned on the Cardinal Point 10 (Neutral Axis). It will cause minor problems in model versioning and comparisons.


There is a neutral definition of the default orientation of profile shapes. This is closely based on the AISC standard.
Below is a diagram showing the default orientations of the Catalogue profiles.


This section lists the UDAs defined for this interface, an attempt has been made to keep the unique abbreviation to 6 characters. The UDAs for this interface are:


:FABID/ATE
TEXT
30
SCTN PANE GENSEC
Date of Import
:FABIT/IME
TEXT
30
SCTN PANE GENSEC
Time of Import
:FABRE/VNO
INT
1
SITE ZONE STRU SCTN PANE GENSEC
Revision Nr (0)
:FABTRA/NO
INT
1
SITE ZONE STRU SCTN PANE GENSEC
Transfer index(1)
:FABTRR/VNO
TEXT
10
SITE ZONE STRU SCTN PANE GENSEC
Revision Text
:FABEX/CLUDE
LOG
1
SCTN PANE SJOI PJOI GENSEC
Exclude flag (f)
:FABSTA/TUS
TEXT
10
SCTN PANE GENSEC
Status text
:FABCD/ATE
TEXT
30
SCTN PANE GENSEC
Date of Creation
:FABMD/ATE
TEXT
30
SCTN PANE GENSEC
Date of Modification
:FABCT/IME
TEXT
30
SCTN PANE GENSEC
Time of Creation
:FABMT/IME
TEXT
30
SCTN PANE GENSEC
Time of Modification

Name
Type
Len
On
Description
:FABID/ATE
TEXT
30
SCTN PANE GENSEC
Date of Import
:FABIT/IME
TEXT
30
SCTN PANE GENSEC
Time of Import
:FABRE/VNO
INT
1
SITE ZONE STRU SCTN PANE GENSEC
Revision Nr (0)
:FABTRA/NO
INT
1
SITE ZONE STRU SCTN PANE GENSEC
Transfer index(1)
:FABTRR/VNO
TEXT
10
SITE ZONE STRU SCTN PANE GENSEC
Revision Text
:FABEX/CLUDE
LOG
1
SCTN PANE SJOI PJOI GENSEC
Exclude flag (f)
:FABSTA/TUS
TEXT
10
SCTN PANE GENSEC
Status text
:FABCD/ATE
TEXT
30
SCTN PANE GENSEC
Date of Creation
:FABMD/ATE
TEXT
30
SCTN PANE GENSEC
Date of Modification
:FABCT/IME
TEXT
30
SCTN PANE GENSEC
Time of Creation
:FABMT/IME
TEXT
30
SCTN PANE GENSEC
Time of Modification


:FABMG/RADE
TEXT
24
SCTN PANE GENSEC
Material Grade
:FABMA/RK
TEXT
24
SCTN PANE GENSEC
Internal ID
:FABEMA/RK
TEXT
24
SCTN PANE GENSEC
External UUID
:FABPMARK
TEXT
24
SCTN GENSEC PANE
Piece Mark
:FABSHPCOD
TEXT
30
SCTN GENSEC
Profile Shape Code
:FABTYPE
TEXT
24
SCTN GENSEC PANE
Member Type
:FABBOCPRF
TEXT
30
SCTN GENSEC
Bocad Profile Type

Name
Type
Len
On
Description
:FABMG/RADE
TEXT
24
SCTN PANE GENSEC
Material Grade
:FABMA/RK
TEXT
24
SCTN PANE GENSEC
Internal ID
:FABEMA/RK
TEXT
24
SCTN PANE GENSEC
External UUID
:FABPMARK
TEXT
24
SCTN GENSEC PANE
Piece Mark
:FABSHPCOD
TEXT
30
SCTN GENSEC
Profile Shape Code
:FABTYPE
TEXT
24
SCTN GENSEC PANE
Member Type
:FABBOCPRF
TEXT
30
SCTN GENSEC
Bocad Profile Type


:FABEF/ID
TEXT
80
SITE ZONE STRU
'Engineering Firm Id'
:FABCL/ID
TEXT
80
SITE ZONE STRU
'Client Id'
:FABSTI/D
TEXT
80
SITE ZONE STRU
'Structure Id'
:FABPR/ID
TEXT
80
SITE ZONE STRU
'Project Id'
:FABMO/DNR
INT
1
SITE ZONE STRU SCTN PANE GENSEC
Model Number
:FABDE/CODE
TEXT
80
SITE ZONE STRU
'Design Code'
:FABSO/URCE
TEXT
64
SITE ZONE STRU
Data Source
:FABTA/RGET
TEXT
64
SITE ZONE STRU
Target Contractor
:FABID/ATE
TEXT
30
SITE ZONE STRU
Date of Import
:FABIT/IME
TEXT
30
SITE ZONE STRU
Time of Import
:FABEXCLUDE is a flag you can set on the items indicated. It is using this flag that you can control what is exported to the output file. By default the flag is false, that is the item is not excluded from the Export process.
:FABEMARK is the external UUID (Universal Unique Identifier) item. If the item originated in the base product then this value will be the AVEVA database reference number with the leading equals sign, '=', removed.
:FABMARK is the AVEVA internal database reference number. It may not be the same as :FABEMARK if the entity originated in AVEVA Bocad Steel.
:FABSTATUS is used to give you a view of the current status of the element. It has four different settings: to signify the item originated in the base product; ADDED indicates that the item has been added to the model externally, by Merging; CHANGED means that the item has been modified externally; and DELETED means that the item was in the original design model but has not returned from the external model. This last case may occur for one of several reasons. The item may not have been exported in the first place; it may have been added after the model was exported or it was deleted by the external system for some reason.
Name
Type
Len
On
Description/default
:FABEF/ID
TEXT
80
SITE ZONE STRU
'Engineering Firm Id'
:FABCL/ID
TEXT
80
SITE ZONE STRU
'Client Id'
:FABSTI/D
TEXT
80
SITE ZONE STRU
'Structure Id'
:FABPR/ID
TEXT
80
SITE ZONE STRU
'Project Id'
:FABMO/DNR
INT
1
SITE ZONE STRU SCTN PANE GENSEC
Model Number
:FABDE/CODE
TEXT
80
SITE ZONE STRU
'Design Code'
:FABSO/URCE
TEXT
64
SITE ZONE STRU
Data Source
:FABTA/RGET
TEXT
64
SITE ZONE STRU
Target Contractor
:FABID/ATE
TEXT
30
SITE ZONE STRU
Date of Import
:FABIT/IME
TEXT
30
SITE ZONE STRU
Time of Import


This interface version has some additional UDAs that must be added in Lexicon. Running the interface. Run bocudaupgrade.pmlfnc in Lexicon to install them.


Cross referencing models is the mechanism by which you can identify members in different models other than by visual comparison. There are two scenarios: one where an element is created in the base product; the other is where it was created in AVEVA Bocad Steel, but is to be imported into the base product.


When an element is created in the base product it gains a unique internal reference number of the form "=<integer>/<integer>", for example: =13/2305. On export from the base product this value, excluding the initial '=' character, will be passed through the UUID fields. AVEVA Bocad Steel will take this value and store it, and use it to allow the user of AVEVA Bocad Steel to identify the original member. On Export back to the base product, for any member which has this UUID attribute set, the original imported UUID will be returned. Thus a user of the base product will be able to spot any changes to the model. The Import system, then allows you to modify the existing structure, rather than just replacing it with a copy. In this way, any drawings, for example, which may have been produced between Export from and Import back to the base product, will retain their logical relationships to the steel members.

modify
replacing


Element Created outside the Base Product

A member created outside the base product will not have the UUID field set to be an internal reference number. The AVEVA Bocad Steel Interface would therefore know that it was importing a new element and would create it accordingly, whilst recording the external UUID as well.
If AVEVA Bocad Steel Interface detects that there are duplicate external UUIDs as it is preparing to export a model, the internal reference number is used in preference. This should give some chance of identifying the element if it returns from the external package. See the section regarding issues concerning entity comparison.


The base product has the ability to split the design model across several databases, some of which may be read only.
Exporting the model tries to update certain variables associated with the version management. However, if the database is read only, a macro file is produced that should be executed immediately as soon as you have write access to the database.
The file name is built upon the string "updateVersionNos" but with time stamp information attached so that they can be executed in chronological sequence. An example file name might be "updateVersionNos201312593744.mac", which was created at 09:37:44 on 25th January 2013.
Importing an existing, though modified, model is more difficult. Obviously you must have write access to the database. The reference site is created in the same database as the target area specified on the Import window. This allows new items to be transferred between the reference site and the target site using the INCLUDE command.
You should make sure that the incoming data is not to be spread across databases.
If the target area is empty the Compare/Merge processes are bypassed which can be a lot faster when importing large amounts of data.
Users of multi-write databases need to be aware that elements that are to be exported must be claimed out prior to export. All elements that are likely to be affected by importing must also be claimed out.
Important:
This must be performed before any further import procedures are performed.

Important:
Import


Imported curved segments will be GENSECs and new straight segments will also be GENSECs. However, if merging with an existing model and the interface can identify the source member that was originally a SCTN, it will remain a SCTN.
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.


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".
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, GENSEC, SCTN and PANE has 3 UDAs attached
A TransferLetter for example: 'C',
A RevisionNumber for example: '2'
Each Transfer has a Letter - A...Z
Each Transfer has a Letter - A...Z
Each Revision has a Number - 1,2,3...
Each Revision has a Number - 1,2,3...
Each SITE, GENSEC, SCTN and PANE has 3 UDAs attached
Each SITE, GENSEC, SCTN and PANE has 3 UDAs attached
A TransferLetter for example: 'C',
A TransferLetter for example: 'C',
A RevisionNumber for example: '2'
A RevisionNumber for example: '2'
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'.

Note:
Note:


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.
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.
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.
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.
Increment the SITE's RevisionNumber, for example: '0' to '1' if any imported entities have changed.


This section lists the exclusions which have been identified.
Penetration Holes
The interface does not allow the description of holes within Linear Members.
Templates
Catalogu 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.


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.


This is a statement of how the interface handles units.
The AVEVA Bocad Steel Interface attempts to keep the behaviour 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.


Certain components of Stairs, Ladders and Handrailing (SLH) will be transferred in the application. These are the GENSEC, SCTN, PANE, RAIL and KICKPL. Any of these elements that are directly or indirectly referenced, such as in templates, will be transferred. However, catalogue components themselves will not be transferred. Further, certain advanced detailing features of the handrailing, such as gaps might not be transferred.
Because of the nature of SLH, round-tripping of the data is difficult as it is challenging to reconstruct the complex data structures.
In detail, the treatment of SLH is as follows:


ABSI Export of SLH - Stairs Ladders & Handrail

Only valid in AVEVA E3D 2.1™
Only Detailed Mode Stairs' Ladders & Handrail will be exported. (Not Model Mode)
Catalogue based components will not be exported (For example: A Catalogue based Post, or Rung or Tread and so on).
Only valid in AVEVA E3D 2.1™
Only valid in AVEVA E3D 2.1™
Only Detailed Mode Stairs' Ladders & Handrail will be exported. (Not Model Mode)
Only Detailed Mode Stairs' Ladders & Handrail will be exported. (Not Model Mode)
Catalogue based components will not be exported (For example: A Catalogue based Post, or Rung or Tread and so on).
Catalogue based components will not be exported (For example: A Catalogue based Post, or Rung or Tread and so on).


Stringers, Treads, and Extensions (STRSTR, TREAD, TOPEXT, BOTEXT) - Can contain GENSEC and PANEL elements / Templates (TMPL). All GENSEC and PANEL elements will be exported as any other Curved Linear Member or Planar Member.
Stringers, Treads, and Extensions (STRSTR, TREAD, TOPEXT, BOTEXT) - Can contain GENSEC and PANEL elements / Templates (TMPL). All GENSEC and PANEL elements will be exported as any other Curved Linear Member or Planar Member.
Stringers, Treads, and Extensions (STRSTR, TREAD, TOPEXT, BOTEXT) - Can contain GENSEC and PANEL elements / Templates (TMPL). All GENSEC and PANEL elements will be exported as any other Curved Linear Member or Planar Member.


Rungs, Stiles, Hoops, Cage Bars, Gates (LDRRNG, LDRSTR, HOOPSE, RLCAGE, RLGATE) - Can contain GENSEC and PANEL elements / Templates (TMPL). All GENSEC and PANEL elements will be exported as any other Curved Linear Member or Planar Member.
Rungs, Stiles, Hoops, Cage Bars, Gates (LDRRNG, LDRSTR, HOOPSE, RLCAGE, RLGATE) - Can contain GENSEC and PANEL elements / Templates (TMPL). All GENSEC and PANEL elements will be exported as any other Curved Linear Member or Planar Member.
Rungs, Stiles, Hoops, Cage Bars, Gates (LDRRNG, LDRSTR, HOOPSE, RLCAGE, RLGATE) - Can contain GENSEC and PANEL elements / Templates (TMPL). All GENSEC and PANEL elements will be exported as any other Curved Linear Member or Planar Member.


Rails (RAIL) - exported as Curved Linear Members
Kick Plates (KICKPL) - exported as Curved Linear Members
Posts, Panels, Gates and Terminations (HRPOST, HRPANE, HRGATE, HRTERM) - Can contain GENSEC and PANEL elements / Templates (TMPL). All GENSEC and PANEL elements will be exported as any other Curved Linear Member or Planar Member.
Rails (RAIL) - exported as Curved Linear Members
Rails (RAIL) - exported as Curved Linear Members
Kick Plates (KICKPL) - exported as Curved Linear Members
Kick Plates (KICKPL) - exported as Curved Linear Members
Posts, Panels, Gates and Terminations (HRPOST, HRPANE, HRGATE, HRTERM) - Can contain GENSEC and PANEL elements / Templates (TMPL). All GENSEC and PANEL elements will be exported as any other Curved Linear Member or Planar Member.
Posts, Panels, Gates and Terminations (HRPOST, HRPANE, HRGATE, HRTERM) - Can contain GENSEC and PANEL elements / Templates (TMPL). All GENSEC and PANEL elements will be exported as any other Curved Linear Member or Planar Member.


In order to minimize the size of log files, especially when large models are being compared you can ask the interface to output Verbose or Brief log files.


In Brief log files, details of the comparison will be condensed onto a single line per item. This will be in the form of the following:


Linear members are either straight or curved. Modifications to straight members are detailed as below
LINMEM <ID> <state> <point> <size> <material> <rotation> <start> <end>
for example:
LINMEM =1234/5678 C Y Y Y N Y Y
The ID field will contain the internal database reference number by which the model components are to be identified between model versions. The state field may contain one of three options, A for added, D for deleted or C for changed. The other fields contain either a Y or N indicating whether the attribute at that location has been changed or not.
For curved members the member type is CURMEM but the attributes inspected for comparison are the same. The individual internal points along the SPINE are not compared.

ID
A
D
C
Y
N


PLATE <ID> <state> <point> <height> <material> <pos> <ori> <vertexCount> <changedVertex>
The rules for values in each of the above fields are as for the Linear Members.
Note that holes themselves are not compared. This is principally because the transfer is incomplete anyway. The interface only transfers PLOO and NXTR based penetrations. No other negative primitives can be transferred at the moment.
Below is a sample portion of log file in brief format following an Import:

All profiles were mapped
The following profiles were not in the specified standards
HP200x54 has                    1 occurrences
All mapped profiles were in the default standard
======================================
LINMEM =15322/447 C   Y   N   Y   N   N   N
LINMEM =15322/448 C   Y   N   Y   N   N   N
LINMEM =15322/449 C   N   N   Y   N   N   N
LINMEM =15322/450 C   Y   N   Y   N   N   N
LINMEM =15322/451 C   Y   N   N   Y   N   N   N
PLATE  =15322/1015 C   N   N   N   N   Y   N   Y
PLATE  =15322/1104 C   N   N   N   Y   N   N   Y
PLATE  =15322/296 C   N   N   N   Y   Y   N   Y
PLATE  =15322/414 C   N   N   N   Y   Y   N   Y
PLATE  =15322/598 C   N   N   N   N   Y   N   Y
PLATE  =15322/722 C   N   N   N   N   Y   N   Y
LINMEM =15322/423 D   N   N   N   N   N   N   N
LINMEM =15322/878 D   N   N   N   N   N   N   N
PLATE  =15322/553 D   N   N   N   N   N   N   N


In Verbose log files, full details of the comparison will be listed.
Below is a portion of verbose log file of the same Import as above:

CHANGES to mapped entities in /TEST-INTERFACE
GENSEC =15322/447 in /TEST-INTERFACE
     Rotation 'S 57.2932 D WRT /*' changed from 'N 57.2932 U WRT /*'
     Just 'TOAY' changed from 'TOAX'
GENSEC =15322/448 in /TEST-INTERFACE
     Rotation 'N 57.3314 D WRT /*' changed from 'S 57.3314 U WRT /*'
     Just 'TOAY' changed from 'TOAX'
GENSEC =15322/449 in /TEST-INTERFACE
     Rotation 'E WRT /*' changed from 'W WRT /*'
GENSEC =15322/450 in /TEST-INTERFACE
     Rotation 'S 32.925 D WRT /*' changed from 'N 32.925 U WRT /*'
     Just 'TOAY' changed from 'TOAX'
 PANE =15322/1015 in /TEST-INTERFACE
     Ori 'Y is E 0.053013 D WRT /* and Z is W 19.7106 N 89.9437 D WRT /*' changed
         from 'Y is W 0.053 U WRT /* and Z is E 19.721 S 89.9437 U WRT /*'
     Vertex 1 'E 134350.001 N 179399.999 U 104251.185 WRT /*' changed from 'E 137050
         N 179400 U 104248.687 WRT /*'
     Vertex 2 'E 134350.001 N 181874.999 U 104252.005 WRT /*' changed from 'E 134350.001
         N 179399.999 U 104251.185 WRT /*'
     Vertex 3 'E 134575.001 N 181874.999 U 104251.797 WRT /*' changed from 'E 134350.001
         N 181874.999 U 104252.005 WRT /*'
     Vertex 4 'E 134575.001 N 182099.999 U 104251.872 WRT /*' changed from 'E 134575.001
         N 181874.999 U 104251.797 WRT /*'
     Vertex 5 'E 137050 N 182100 U 104249.582 WRT /*' changed from 'E 134575.001 N
         182099.999 U 104251.872 WRT /*'
     Vertex 6 'E 137050 N 179400 U 104248.687 WRT /*' changed from 'E 137050 N 182100
         U 104249.582 WRT /*'
 PANE =15322/1104 in /TEST-INTERFACE
   Position 'E 144350 N 169625 U 104250 WRT /*' changed from 'E 144450 N 172000 U
         104250 WRT /*'
     Vertex 1 'E 144350 N 172100 U 104250 WRT /*' changed from 'E 144350 N 169625
         U 104250 WRT /*'
     Vertex 2 'E 147050 N 172100 U 104250 WRT /*' changed from 'E 144350 N 172100
         U 104250 WRT /*'
     Vertex 3 'E 147050 N 169400 U 104250 WRT /*' changed from 'E 147050 N 172100
         U 104250 WRT /*'
     Vertex 4 'E 144575 N 169400 U 104250 WRT /*' changed from 'E 147050 N 169400
         U 104250 WRT /*'
     Vertex 5 'E 144575 N 169625 U 104250 WRT /*' changed from 'E 144575 N 169400
         U 104250 WRT /*'
     Vertex 6 'E 144350 N 169625 U 104250 WRT /*' changed from 'E 144575 N 169625
         U 104250 WRT /*'
===========================
CHANGES >>>> 70 detected
ADDITIONS to mapped entities in /TEST-INTERFACE
===========================
ADDITIONS >>>> 0 detected
DELETIONS to mapped entities in /TEST-INTERFACE
 LINMEM =15322/423 has been deleted.
 LINMEM =15322/878 has been deleted.
 PLATE  =15322/553 has been deleted.
===========================
DELETIONS >>>> 3 detected


The Sample Validity Check log file displays shows a sample portion of a log file from an Import validity checking process to check for duplicate mark numbers.


This section describes the system architecture, the relationship between internal and external mappings, mappings files and overloading mapping files.


The diagram below illustrates the whole AVEVA Bocad Steel Interface system architecture.


There are two types of mapping files: internal and external mapping files.
Internal mapping files are prepared by the system administrator. They tell the interface where on the computer network the external mapping files may be found. The format of the internal mapping files is described in Internal Mapping Files.
External mapping files are files which determine how the interface handles the data for going to or coming from AVEVA Bocad Steel; for example, the Profile, Unicode and Material mapping files. The format of the external mapping files is described in External Mapping Files.

Internal Mapping Files
External Mapping Files
Internal mapping files
Internal Mapping Files
External mapping files
External Mapping Files


Overloading of mapping files is permitted and may occur. This means that a file that is found in the first folder will be overwritten by a file with the same identifying characteristics, though not necessarily with the same filename (Internal Mapping Files), found later in any of the succeeding folders. For example, a project mapping file could overload a company mapping file.
The sequence of environment variables is set to the locations of the internal mapping files. The interface will search all the folders pointed to by these variables and locate all files with the suffix .map in each sub-folder called BocadMaps. The .map files will be imported during system initialization as internal mapping files. The internal mapping files then become the basis for locating the external mapping files.
However, this does not alter the search rules for the external mapping files as based on the content of the identification line in the internal mapping file.
The diagram below illustrates how these environment variables may be used to select and overload sets of internal mapping files.

You does not have to use all three defaults variables.

Internal Mapping Files
Internal Mapping Files
.map
BocadMaps
.map


Relationship between Internal and External Mapping Files

For the purposes of this section, the variable BOCDATA is assumed to have been set up in your system initialization process to point to the folder containing the external mapping files.
The environment variable BOCDATA should point to a single folder only. This variable may be made to be project specific, so that the internal mapping files may be kept unchanged, but you will be able to pick up mapping files from a project-specific location.

You should take care in using environment variables in internal mapping files, as a recursive scan is not performed at this level. In this case the variable must point to only one folder.
Note:
BOCMAPS is not a variable specifically required by this interface.

Note:


After you have set the appropriate environment variables, some upgrade macros must be run on the project which:
Update catalogues to include the Pline representation of the Cardinal Points.
Install the UDAs which requires.
Update catalogues to include the Pline representation of the Cardinal Points.
Update catalogues to include the Pline representation of the Cardinal Points.
Install the UDAs which requires.
Install the UDAs which requires.
Note:
This process can be repeated as the supplied software performs the correct checks to see whether the project needs updating.

Note:


The standard AVEVA Solutions Limited steelwork catalogue at AVEVA E3D 2.1™ 2.1 is already compatible with SDNF. Older catalogues, and user catalogues might need to be upgraded to include the Pline representations of the SDNF Cardinal Points. Refer to Cardinal Points for further information.
You may upgrade the catalogues by performing the following actions:
There are 15 Cardinal Points defined in the AVEVA Bocad Steel Interface. The interface uses only 14 of them. Of the remaining Cardinal Points the interface tries to use those between 1 and 10.
If you have not used Plines representing Cardinal Points to place Linear Members in the base product, during the Export or Import processes an attempt is made to map existing Plines onto Cardinal Points.
This mapping is performed using information stored in a configuration file, bocloadcpdata.pmlfnc in the PMLLIB\Bocad\functions folder in the installation folder. This basic Pline mapping for the old (that is pre AVEVA E3D 2.1™ 2.1) structural catalogue and the new AVEVA E3D 2.1™ 2.1 supplied catalogue are as follows:
Note:
This upgrade process works only for the supplied catalogues. Further, it only works on the old British, American and DIN catalogues, to upgrade them to the new Plines. The mechanism should be easily extended to include other supplied catalogues. Upgrading user catalogues is described elsewhere.

Note:
bocloadcpdata.pmlfnc
PMLLIB\Bocad\functions


For symmetrical profiles in the new catalogue, which are symmetrical about the Y axis, the Plines below are mapped to Cardinal Points. It might appear confusing, but the left/right relationship depends on how you look at the profile - in the same direction as the profile vector, or against it.
LBOT

3
CBOT

2
RBOT

1
LMID

6
CMID

5
RMID

4
LTOP

9
CTOP

8
RTOP

7
NA

10
BNA

11
LNA

13
RNA

12
TNA

14
For angle and channel profiles in the new catalogue the Pline mapping is as follows. This difference is principally because of the SDNF definition of the default profile orientation.
LBOT

1
CBOT

2
RBOT

3
LMID

4
CMID

5
RMID

6
LTOP

7
CTOP

8
RTOP

9
NA

10
BNA

11
LNA

12
RNA

13
TNA

14
For the old (E3D1.1) catalogue the Plines are mapped as follows. For symmetric sections that are symmetrical about the Y axis. Symmetric Sections about Y Axis
RBOS

SNFA

1
BOS

SNFB

2
SS

SNFB

2
LBOS

SNFC

3
RIGH

SNFD

4
NARO

SNFD

4
AA

SNFD

4
MM

SNFF

6
NALO

SNFF

6
LEFT

SNFF

6
RTOS

SNFG

7
GG

SNFH

8
TOS

SNFH

8
LTOS

SNFI

9
NA

SNFJ

10

Pline
is mapped to
Cardinal Point
LBOT
3
CBOT
2
RBOT
1
LMID
6
CMID
5
RMID
4
LTOP
9
CTOP
8
RTOP
7
NA
10
BNA
11
LNA
13
RNA
12
TNA
14
Pline
is mapped to
Cardinal Point
LBOT
1
CBOT
2
RBOT
3
LMID
4
CMID
5
RMID
6
LTOP
7
CTOP
8
RTOP
9
NA
10
BNA
11
LNA
12
RNA
13
TNA
14
Pline
mapped to
Pline
which is
Cardinal Point
RBOS
SNFA
1
BOS
SNFB
2
SS
SNFB
2
LBOS
SNFC
3
RIGH
SNFD
4
NARO
SNFD
4
AA
SNFD
4
MM
SNFF
6
NALO
SNFF
6
LEFT
SNFF
6
RTOS
SNFG
7
GG
SNFH
8
TOS
SNFH
8
LTOS
SNFI
9
NA
SNFJ
10

Pline
Pline
Cardinal Point


TOAX

SNFA

1
TOAY

SNFA

1
RTTA

SNFC

3
LBOA

SNFG

7
NA

SNFJ

10
NAT

SNFK

11
NAL

SNFL

12

Pline
mapped to
Pline
which is
Cardinal Point
TOAX
SNFA
1
TOAY
SNFA
1
RTTA
SNFC
3
LBOA
SNFG
7
NA
SNFJ
10
NAT
SNFK
11
NAL
SNFL
12

Pline
Pline
Cardinal Point


LTOC

SNFA

1
RTOC

SNFC

3
FOC

SNFD

4
ROC

SNFF

6
LBOC

SNFG

7
RBOC

SNFI

9
NA

SNFJ

10
TOC

SNFK

11
BOC

SNFN

14
For further explanation of the reasons why the mapping may seem inconsistent, see the section describing the assumed default profile orientations in the file and Cardinal Points locations and the Structural Design User Guide. In particular your attention is drawn to the different handedness of the coordinate systems as illustrated below.

The main differences arise from the mapping of the profile orientations in the Catalogue onto the agreed format. The difference is most apparent in channel and angle profiles. The diagram below illustrates the mappings of the Plines to Cardinal Points.

If you want to create profiles, you must provide a Pline set similar to the ones provided here to map onto the Cardinal Point Pline set. If they are named differently, there must be a mapping to Cardinal Points as shown above. Further, you may have to manage the orientation of the profile with regard to the intermediate arrangement by using the Profile Orientation mapping file (External Mapping Files).
Pline
mapped to
Pline
which is
Cardinal Point
LTOC
SNFA
1
RTOC
SNFC
3
FOC
SNFD
4
ROC
SNFF
6
LBOC
SNFG
7
RBOC
SNFI
9
NA
SNFJ
10
TOC
SNFK
11
BOC
SNFN
14
Note:
The different Y directions to match the default angle orientations in each system.

Cardinal Points
External Mapping Files
Pline
Pline
Cardinal Point
Cardinal Points
Note:
External Mapping Files


Update Catalogs not supplied by AVEVA Solutions Limited

The interface tries to find the correct Justification Pline by comparing the positions of their ends and the start and end of the imported member.
This section gives details on how you can update the steel catalogues to include the Plines necessary for the interface.
The macro file, bocusercataupgr.pmlfnc in the bocad\dflts\user\upgrade folder in your data folder provides the basis on which you may build their own mechanism for updating the catalogues automatically. When the changes are complete you should perform a PML REHASH ALL operation in a command window. We have indicated where you may have to modify this file with lines prefixed by:
The macro must be run for each catalogue (CATA element) you want to update. You may have to modify it in a different way for each catalogue. (Details about how the file should be modified are given in following sections.)
You can write a macro which will call all the modified files in turn and so upgrade all catalogues at once. The macro takes one argument which is the DBREF (the database reference number) of the catalogue to be updated.
To update individual catalogues, run the upgrade macro as follows:
Important:
The naming conventions and database structure for the Pline sets should be similar to those used in the supplied Catalogues.

Important:
bocusercataupgr.pmlfnc
bocad\dflts\user\upgrade
PML REHASH ALL
¼
call !!bocUserCataUpgr( !!CE )


The supplied catalog contains profiles of 7 standard generic shapes which are detailed in the Structural Design User Guide. That manual explains the parameterization method for these shapes. As a result, there are 7 generic macros in the PMLLIB\bocad\upgrade folder in the installation folder, one for updating the Pline set of each standard shape. These are:
Tee shape
bocupgradet.pmlfnc
I shape
bocupgradei.pmlfnc
O, Tube, CHS shape
bocupgradeo.pmlfnc
C, Channel shape
bocupgradec.pmlfnc
L, Angle shape
bocupgradel.pmlfnc
RHS shape
bocupgraderhs.pmlfnc
Bulb shape
bocupgradebulb.pmlfnc
If you has other additional shapes, or have parameterized them in a different way from the supplied catalogues, you will have to write their own macro for their own shape based on the most suitable one provided. Please take note of the catalogue profile orientation with regard to the format.

Profile Shape
Macro
Tee shape
bocupgradet.pmlfnc
I shape
bocupgradei.pmlfnc
O, Tube, CHS shape
bocupgradeo.pmlfnc
C, Channel shape
bocupgradec.pmlfnc
L, Angle shape
bocupgradel.pmlfnc
RHS shape
bocupgraderhs.pmlfnc
Bulb shape
bocupgradebulb.pmlfnc


In order to customize the generic Pline generating macros listed above, or to create their own, you will need to understand fully how the profile in question is parameterized in their catalogue database, and how the profile shape is positioned relative to the Neutral Axis and the X/Y origin in the catalogue.
The structure of all the supplied macros is similar.
The macro first builds a list of any Plines that already exist. Any Plines that are not available and are needed by the AVEVA Bocad Steel Interface as listed in the !!BOCCPPKeys array, are then created. Doing this makes sure the latest configuration is being used.
We then need to define the Cardinal Point Pline location parameters related to the method of catalogue parameterization. These are Xoff, YOff, nYOff and nXOff. We also need to work out the location of the geometric centre relative to the method of profile definition. These location parameters are XCOff and YCOff. You will see above that the definition is in terms of a text string which describes a formula. Later on in the macro, this text string is inserted into the command line. This use of PML allows you to insert formulae into the Pline definition, rather than the immediately evaluated formula.
Using these Pline location parameters, all the Cardinal Point Plines required for the application can be located. Refer to Cardinal Points for further information.
If you are extending or modifying the application, all you need to do is to modify the part of the macro which calculates the location parameters. You should, however, pay close attention to the default profile orientations within AVEVA Bocad Steel Interface.
The structure of the upgrade process allows you to run the macro during the project as well as at project initiation. Any database relationships that refer to the old Plines will be maintained, for example, dimensions.

Cardinal Points
Cardinal Points


Once you have defined their generic shapes you need to be able to map the Pline set names to that shape. This is done by filling in a mapping file of PML objects in the bocusercataupgr.pmlfnc macro file. The first set in the UserMap array may have to be modified, and you may have to extend the list for their own additional specific shapes.
For example, a complete mapping for a Pline set consists of the following:
This means that the Pline set (PTSS) named /USER-PTSS-I is to be modified using the PML macro represented by the variable !Ishape.
Further up, you can see that the !IShape variable is associated with the macro !!bocUpgradeI( ). The args value is true or false depending on whether the catalogue to be updated is based on the old or new catalogues. This is most important when considering C or L shaped profiles where the orientations change.
  -- Map Shapes to generic update macros
    !TShape             = |!!BOCUpgradeT|
    !IShape             = |!!BOCUpgradeI|
    !OShape             = |!!BOCUpgradeO|
    !CShape             = |!!BOCUpgradeC|
    !LShape             = |!!BOCUpgradeL|
    !RHSShape           = |!!BOCUpgradeRHS|
    !BULBShape         = |!!BOCUpgradeBULB|
-- >>>> User to add any specific shapes here
--    !USERAShape         = |!!BOCUpgradeUSERA|
  -- >>>> User Map definition between PTSS and Shape code
    !UserMap = ARRAY
    !UserMap[ 1 ]         = object BOCMAPOBJ
    !UserMap[ 1 ].Name   = |/USER-PTSS-I|
    !UserMap[ 1 ].Macro   = !IShape
    !UserMap[ 1 ].Args   = |(false)|

bocusercataupgr.pmlfnc


Below are instructions to create and upgrade the Catalogue based on the requirement to create a new profile shape in both the base product and AVEVA Bocad Steel. Any operations that require changes to system mapping files or PML macro files, should be preceded by backing up the files first.


Create the new 2D profile shape. Determine the generic shape and parameterization best suited to the required profile.
At this point do not include Cardinal Point Plines in the Pline set, just place other Plines you will find useful and name them accordingly. Do not include any Plines with the special PKEY values as these will be added in the upgrade process. Build the new catalogue, recording which parameters apply to which dimension.
In AVEVA Bocad Steel create the profile such that its default orientation will be the same as that in the base product when laid out from start to end.
With predefined profiles, such as unequal angles, the default orientation may be different. In this case, you may need to use mirroring and/or rotation transformations to get to the correct "starting position". Mirroring represents a transformation about the Y axis: rotation is about the Z axis, following the "Right Hand Screw Rule". Keep a record of these necessary transformations as they will go into the orientation mapping file.
On the 2D profile in each package locate where the Cardinal Points and their Pline equivalents will be. In the PARAGON module, place any other Plines that you may find useful. Record the correspondence between Cardinal Points and Pline names. Remember also that any mirroring and rotation will affect the Cardinal Point locations.
If the new profile is not one of the existing shapes, you may need to assign a new profile integer shape code to it for use in the profile mapping file.
Also, if the new profiles are for a new country standard, you may need to assign a new country code to this. This country code abbreviation is stored in the internal steel standards file. This abbreviation is also used in the profile mapping file.
Note:
The coordinate system in the base product is right handed, whereas in the neutral file it is left handed. The Cardinal Point : Pline equivalencing by superposition is illustrated above for an unequal angle profile. Using this kind of diagram you will be able to determine the mappings between Plines and Cardinal Points.

Note:


Upgrade the Catalog for the AVEVA Bocad Steel Interface

Upgrading the Catalog involves adding Plines to be equivalent to the Cardinal Points.
In Paragon determine the parameterized geometry and Pline positioning for the Cardinal Points.
If you are extending an existing generic shape use the existing upgrade file provided. Or if the profile can be based on an existing generic shape, use a customized copy of the bocupgrade<*>.pmlfnc macro. Modify the profile upgrade macro to account for the new parameterization to create and locate the Plines for the Cardinal Points. Use an existing example as a guide.
Run boccataupgrade.pmlfnc macro for upgrading standard catalogues.
Inspect the macro bocusercataupgr.pmlfnc to extend any lists to include the new profile shape, associating it with any new profile upgrade macro. Once modified, perform a PML REHASH ALL command in a Command window, if necessary, then run this macro.
!Ishape = |bocupgradei()|
!UserMap[ 1 ] = object BOCMAPOBJ( )
!UserMap[ 1 ].Name = |/USER-PTSS-I|
!UserMap[ 1 ].Macro = !Ishape
!UserMap[ 1 ].Args = |( false )|

bocupgrade<*>.pmlfnc
boccataupgrade.pmlfnc
bocusercataupgr.pmlfnc
PML REHASH ALL


For the chosen profile in the chosen standard, if any transformations are to be applied to convert from the base product to the default system, they are to be recorded in the orientation mapping file. If the profile requires no transformations, it need not be listed in this file. In the example below, the British type 9 profiles are orientated by mirroring (1) and then rotating by 180 degrees. British type 8 profiles are not mirrored (0) and just rotated by 180 degrees.
AVEVA BOCAD
BRI 2 0 180
BRI 4 1 180
DIN 2 0 180
DIN 4 1 180


Any new profiles requiring mapping between the base product and the external steel detailing system should be entered in the mapping file. Refer to Profile Mapping Files for further information on the profile mapping file structure.

Profile Mapping Files
Profile Mapping Files


Re-initialize the System and Save the UI Binaries

On the Export or Import main forms use Control > Re-initialize for resetting the configuration data only.
Or execute call !!bocimpexp() in a command window to re-initialize the system.
However this last option is very brutal as all settings will be lost because the windows and menus are regenerated. You will then have to regenerate UI binaries after this.

Control > Re-
e
call !!bocimpexp()


Before you start designing steelwork, the application requires a set of User Defined Attributes (UDAs) specifically for storing related information. These are installed by performing the following actions:
More UDAs might be required in a later version of the application, so you will need to upgrade their current projects if they are to use this later version. The macro has been configured to keep existing UDA definitions so that you will not lose data.
Enter the LEXICON module with write access to all the relevant Dictionary databases.
Execute the upgrade macro by the following command:
call !!bocUDAUpgrade( )
Exit from LEXICON, saving the changes.
Enter the LEXICON module with write access to all the relevant Dictionary databases.
Enter the LEXICON module with write access to all the relevant Dictionary databases.
Execute the upgrade macro by the following command:
call !!bocUDAUpgrade( )
Execute the upgrade macro by the following command:
Exit from LEXICON, saving the changes.
Exit from LEXICON, saving the changes.
Note:
This upgrade may be run even if the UDAs exist already. In this way you may upgrade the system whenever necessary; for example, to include more UDAs needed for a later version of the application.

call !!bocUDAUpgrade( )
Note:


When the AVEVA Bocad Steel Interface application imports a model, some SITE elements might be created. Typically these will be called something like /FAB-OLD-DEMO-SYSTEM. These SITEs store items which have been 'deleted' from the model during the Export/Import cycle. These SITEs will be created only when needed, you can always recover elements from this area if they need to later on.
The name of deleted element SITEs are built up of the following components:
/FAB-
the system prefix
OLD-
identification of a SITE for ‘deleted’ elements
<mdb name>
the current MDB, for example /DEMO
<user name>
the current user name, for example SYSTEM
/FAB-
the system prefix
OLD-
identification of a SITE for ‘deleted’ elements
<mdb name>
the current MDB, for example /DEMO
<user name>
the current user name, for example SYSTEM
The application checks that you have read/write access to their specific SITEs, since you and the application may need to edit certain attributes.
The SITE for deleted elements is described in more detail in the User Guide, will store the 'deleted' elements in STRUs according to the Import revision, so that you can quickly isolate which items were deleted at which time.
You will note that the SITE names contain the current MDB and the current user name. This is to facilitate multi-user working, and multiple accesses to the database. There may be several of these, depending on which MDB and/or user has access to the particular database.
/FAB-
the system prefix
OLD-
identification of a SITE for ‘deleted’ elements
<mdb name>
the current MDB, for example /DEMO
<user name>
the current user name, for example SYSTEM

/FAB-
OLD-
<mdb name>
<user name>


You can set PML variables to customize. They are set in the file called bocuserdata.pmlfnc found in the bocad\dflts\user\bocpml\functions folder in your data area of the application.
The user modifiable function bocuserdata.pmlfnc is found in bocad\dflts\user\bocpml\functions
If you customize the AVEVA Bocad Steel Interface forms, you must reload the base product's user interface from macros in order to rebuild it. If you change variables in your data area, you can use the Re-initialize option on the main Import or Export forms.
Alternatively, you may reload the AVEVA Bocad Steel Interface system variables and rebuild the forms using the following command, after you have saved the bocuserdata.pmlfnc file:
However, if you find that the user interface forms are damaged, reload the UI from macros. A typical message indicating this condition might be:
call !!bocImpExp( )
Object does not have a member .targetlist
Note:
You must also load the AVEVA Bocad Steel Interface UI from macros if you make any changes to the internal mapping files

bocuserdata.pmlfnc
bocad\dflts\user\bocpml\functions
bocuserdata.pmlfnc
Re-
e
bocuserdata.pmlfnc
call !!bocImpExp( )
Object does not have a member .targetlist
Note:


You can change the colors of the objects on the screen using the variables listed below. If you want to change them, the list of colour numbers is given in the Model Reference Manual. The default settings are:
The duplicate colour is used when the import system searches for items with duplicated mark numbers.
!!bocColChanged     = ( 12 )  $* Mauve
!!bocColAdded       = ( 5 )   $* Green
!!bocColDuplicate   = ( 6 )   $* Cyan
!!bocColDeleted     = ( 2 )   $* Red
!!bocColExported    = ( 3 )   $* Orange
!!bocColDefault     = ( 1 )   $* Grey

!!bocColChanged     = ( 12 )  $* Mauve
!!bocColAdded       = ( 5 )   $* Green
!!bocColDuplicate   = ( 6 )   $* Cyan
!!bocColDeleted     = ( 2 )   $* Red
!!bocColExported    = ( 3 )   $* Orange
!!bocColDefault     = ( 1 )   $* Grey


You can modify the distance tolerance (the separation, in millimetres, below which two points are considered coincident), the minimum Plate thickness, and the minimum length of Linear Members. The minimum tolerance is used as a fine tolerance value in vector comparisons, such as for angles.
-- Set distance tolerance
!!bocDistTol        = ( 1 )
!!bocMinTol         = ( 0.01 )

-- Set distance tolerance
!!bocDistTol        = ( 1 )
!!bocMinTol         = ( 0.01 )


The system wait time represents a unit of time which the application will wait while the external program is executing. If there is no response within this time, the application may assume that the external program has stopped for some reason. This may not be the case - it may just be working hard!
You will be asked whether they want to wait for another unit period. This variable is nominally measured in seconds, but it is also dependent on how busy the computer is on other tasks as well.
There is also a variable, !!bocNoOfTries, which is used to determine how many iterations of the waiting loop the application goes through before prompting you for further information.
-- Set wait time
!!bocWaitTime      = ( 5 )
!!bocNoOfTries     = ( 5 )

-- Set wait time
!!bocWaitTime      = ( 5 )
!!bocNoOfTries     = ( 5 )


You can choose to ignore any errors caused by different material mappings by using this flag. What this means is that on comparing the original model with the imported model, any difference in material is not raised as an error.
-- Ignore Material changes
!!BOCIgnoreMatl  = false

-- Ignore Material changes
!!BOCIgnoreMatl  = false


The separator character for the external mapping files may be either a space or a comma. Using the variables below, you can indicate their choice.
There is a third file format for Profile mapping files. The BLOCK format is described elsewhere and is indicated here with !!bocBlockSep. Block formatted files are pre-processed by a separate tool for more efficient reading and parsing.
-- Mapping File separators
!!bocProfSep         = !!bocBlockSep
!!bocMatSep          = !!bocCommaSep
!!bocOriSep          = !!bocSpaceSep
Note:
All the files of the same type (either Material, Orientation or Profile) must use the same separator consistently: you cannot have some Material files space separated, while others are comma separated.

Note:
All
-- Mapping File separators
!!bocProfSep         = !!bocBlockSep
!!bocMatSep          = !!bocCommaSep
!!bocOriSep          = !!bocSpaceSep


You can write their own macros to be run before and after the both the Export and Import processes have taken place. This lets you build a model in the base product which then needs some sort of pre- or post-processing. This is performed using the variables below:
The above syntax defines the names of macros which are to be found in the folder structure below the %PMLLIB% environment variable. They are named as above with the PML suffix, '.pmlfnc'.
These macros will be called before and after the process has been executed. These macros should have either no arguments and return no value or have a single FILE argument and return no argument. The optional FILE argument refers to the ABSI log file.
-- Pre/Post Export User Defined Macros
!!bocPreExpMac  = |bocpreexport|
!!bocPostExpMac = |bocpostexport|
!!bocPreImpMac = |bocpreimport|
!!bocPostImpMac = |bocpostimport|
Note:
It is for you to handle all internal errors within the macros. Errors that are not handled could cause the transfer process to crash.

-- Pre/Post Export User Defined Macros
!!bocPreExpMac  = |bocpreexport|
!!bocPostExpMac = |bocpostexport|
%PMLLIB%
Note:


You may modify the sample macro, bocgetusermatl.pmlfnc, as named by the !!bocMaterialMac global variable and given in the bocad\dflts\user\bocpml\functions folder in the user data folder, if you have specific requirements as to where the material information resides. The bocgetusermatl.pmlfnc function can then be modified. Once modified, you should execute a PML REHASH ALL command.
The example macro is as follows:
The above example assumes that the material information for GENSECs resides on the catalogue component in the UDA :MATERIAL. If, for any reason, a material cannot be identified, a default value of 'St 37-2' is assigned.
The application assumes, by default, that this file exists under the above name in a folder below the %PMLLIB% search path, and that the starting point for database navigation is the current element under consideration, that is a Section, a GENSEC or Panel. for further information of how you can configure the system to use a material macro with a name of your choice, refer to User-definable Material Macro for further information.
Regarding the naming of this macro, refer to User-definable Material Macro for further information.
define function !!bocGetUserMatl( ) is STRING
  -- initialization
  !material = STRING( )
  !material = |unset|
  !start = ( ref )
  -- Set default material
  !defaultMaterial = |St 37-2|
  -- Some User specific PML to get the required info
  !type = ( type )
  if( !type eq |GENSEC| )then
    -- Material stored on Catalogue component
    goto catr
    handle any
      -- Bad or null reference
      !material = !defaultMaterial
      golabel /Finished
    endhandle
    !material = ( :Material )
    handle any
      !material = !defaultMaterial
      golabel /Finished
    endhandle
    if( !material eq |unset| or $
        !material.unset( ) or $
        !material.length( ) eq 0 )then
      -- Use default material
      !material = !defaultMaterial
    endif
  elseif( !type eq |PANE| )then
    -- Try to return :FABMGRADE or default material
     !material = ( :FABMGRADE )
    if( !material eq |unset| or $
        !material.unset( ) or $
        !material.length( ) eq 0 )then
      -- Use default material
      !material = !defaultMaterial
    endif
  endif
  -- Return string and exit
  label /Finished
  $!start
  return !material
endfunction
Note:
In writing your own macro, you must handle all errors encountered so that the macro will always safely return a valid PML string, whatever it may be.
Also, that materials for Panels must also be determined using this macro.

User-definable Material Macro
User-definable Material Macro
bocgetusermatl.pmlfnc
!!bocMaterialMac
bocad\dflts\user\bocpml\functions
PML REHASH ALL
%PMLLIB%
User-definable Material Macro
Note:
User-definable Material Macro


For reading many files, such as the mapping files, log files or even some internal files, there is a current size limit of 500000 lines.
This may be modified by changing the lines below.
Note:
That this is not the size of the input model file. It is the estimated size of the internal macro file produced during the translation process.

Note:


This section describes the formats for the mapping files between catalogues and those of external 3D steel detailing packages. The mapping files will indicate a correlation between the profile in AVEVA E3D 2.1™ and its equivalent in the other system, to which, or from which, data are to be transferred. It is your responsibility to make sure that any geometrical modelling required in either system is suitably reproduced in the other. The mapping files supplied are modifiable and extensible by you.


Replacement of SCTNs with GENSECs on Import

The base product structural user interface creates GENSEC elements for all structural members, whether they are straight or curved. In the first phase of import, all structural members are imported as GENSEC elements. If you are importing to update and existing model, the database type of elements is not changed.


You can select whether the file will contain listings of all the mapping files or just the section count table. This is done by the !!bocBriefHdr variable in the bocuserdata.pmlfnc file. By default the files have brief headers, but if you want to include details of all the files used for the translation, the variable can be switched to 'false'.
    -- Brief/Verbose Bocad Interface file header
    !!bocBriefHdr = true

bocuserdata.pmlfnc
    -- Brief/Verbose Bocad Interface file header
    !!bocBriefHdr = true


As has been described above, the file bocuserdata.pmlfnc can be modified by hand to provide a degree of customization. This overwrites the system variables in bocsystemdata.pmlfnc.
Note:
This latter function must not be modified.

bocuserdata.pmlfnc
bocsystemdata.pmlfnc
Note:


There is a third level of customization available that is accessible by a graphical user interface. This window has access to versions of all the variables in the bocuserdata.pmlfnc function, but it does not modify that function at all. Therefore, at this point, you are working with a local set of configuration data. This file also stores the settings on the attribute comparison window that drives the Compare/Merge operation.
The System Configuration window is accessible from either the main Import or Export window using Control > Configure.

The System Configuration window has five tabs Run Parameters, Model Parameters, Display Colours, Environment Parameters and Macros. The detail of the attributes can be read above. The forms do have some data validation, where appropriate.

By default, the system looks for a file ABSI.xml in your work area. If present, this file is accessed when this window, and even when the whole system, is initialized. If this file is not available, then the default values that are used are set in bocsystemdata.pmlfnc and subsequently overwritten by bocuserdata.pmlfnc. You can save the window, settings to this default file using the Control > Save option. To save the settings to another file, use the Control > Save as... option.
To load any settings file other than the default one use Control > Load... option. A file browser is displayed allowing you to choose where to locate the new file.
To restore the main default settings at window initialization, just delete the ABSI.xml file.
Click Reset to reset the values using the normal form initialization process with the current variables and any saved ABSI.xml file.
The Re-initialize option goes right back to the source variables in the system and user data and the default ABSI.xml files.
Click OK to transfer the settings to the main Import/Export system for use in that session. Once the window is displayed again, any unsaved attributes will be lost.

bocuserdata.pmlfnc
System
Configuration
Control > Configure
System Configuration
Run Parameters, Model Parameters,
Display Colours, Environment Parameters
Macros
ABSI.xml
bocsystemdata.pmlfnc
bocuserdata.pmlfnc
Control > Save
Control > Save as...
Control > Load...
ABSI.xml
Reset
ABSI.xml
Re-
e
ABSI.xml
OK


The application relies on several internal mapping files. These define where external mapping files are located on your system network, or they define the mapping of strings or attributes between the base product and the intermediate file. It is your responsibility to modify them correctly so that they indicate the correct file location.
Internal mapping files are loaded on start-up of the application. If there are any problems on loading, you will be prompted to confirm that you want to carry on with using the application, although it is frequently inadvisable. If you do not continue, a fatal error is raised and the application exited.
Internal mapping files must have a suffix '.map' and be stored in one of 3 areas pointed to by the environment variables for the system default area, the project defaults, for example: SAMDFLTS, and your work area. In locating the map files, the folders are searched in the listed sequence. This enables you to have company, project and user mapping files that can overload the previously installed versions. The example internal files supplied by the system should be found in the folder, BocadMaps.
Internal mapping files are of the form of an asterisk (*) separated sequence of strings. The first line of the file is taken to be a file identifier, the precise rules for which are defined below.
As an aid to generalising your application, you may include environment variables in the path names as long as they are defined in the base product format; for example:
These environment variables cannot be search paths: they must translate to a reference to a single folder.
Note:
If you change any of the internal mapping files, you must reload the base product's user application from macros. Alternatively you can use the Re-initialize menu option on the main Import and Export forms, you should then resave the binary UI.

Note:
Re-
e
BocadMaps
%ENVVAR%\
¼


Bad Map File
On attempting to load the internal mapping file, there are several potential errors: it is not of the correct format; it may not exist; it may contain empty lines; the first line is not correct.
No Mapping Table
defined for selection
The internal files recognize AVEVA Bocad Steel, but there are no mapping table files associated with it.
Bad Map File
On attempting to load the internal mapping file, there are several potential errors: it is not of the correct format; it may not exist; it may contain empty lines; the first line is not correct.
No Mapping Table
defined for selection
The internal files recognize AVEVA Bocad Steel, but there are no mapping table files associated with it.

Bad Map File
On attempting to load the internal mapping file, there are several potential errors: it is not of the correct format; it may not exist; it may contain empty lines; the first line is not correct.
No Mapping Table
defined for selection
The internal files recognize AVEVA Bocad Steel, but there are no mapping table files associated with it.

Bad Map File
No Mapping Table
defined for selection


The file mapping tables indicate the location of external Profile, Orientation, Unicode and Material mapping tables in the folder structure. The internal mapping tables may be specific to either the project or the company.
The tables are searched first for a project-specific set before a company-specific set.
The files consist of a first line, then a series of pairs of * separated values (with no spaces), indicating the location of the mapping file.
The first line in each file is a pair of values, the second of which is used to identify the list.
The second part must be one of:
The project-specific Profile mapping files for the TST project may be similar to:
PRF
for a Profile mapping table
ORI
for a Profile Orientation mapping table
MAT
for a Material mapping table
UNI
for a Unicode text string conversion file
PRF
for a Profile mapping table
ORI
for a Profile Orientation mapping table
MAT
for a Material mapping table
UNI
for a Unicode text string conversion file
and a companywide Unicode test string mapping table may look like:
The Material mapping tables are defined in a similar way. For example a project-specific Material mapping file, using a previously defined environment variable, BOCDATA, might look like:
A companywide Profile Orientation mapping table would look similar to the following:
for further information of the format of the external mapping files, consult the relevant section in this guide.
PRF
for a Profile mapping table
ORI
for a Profile Orientation mapping table
MAT
for a Material mapping table
UNI
for a Unicode text string conversion file
TSTPRF*TSTPRF
BOCAD*C:\AVEVA\Plant\Bocad\maps\Bocad\Bocad.map
AVEVA*C:\AVEVA\Plant\AVEVA\maps\xxxx\E3D.map
ANYUNI*ANYUNI
BOCAD*C:\AVEVA\Plant\Bocad\maps\Bocad\BocadUni.map
AVEVA*C:\AVEVA\Plant\AVEVA\maps\xxxx\E3DUni.map
TSTMAT*TSTMAT
BOCAD*%BOCDATA%\Bocad\Bocad.map
AVEVA*%BOCDATA%\AVEVA\AVEVAMat.map
ANYORI*ANYORI
BOCAD*%BOCMAIN%\maps\Bocad\BocadOri.map
AVEVA*%BOCMAIN%\maps\AVEVA\AVEVAOri.map
The first part of this identifier text is either the three-letter name of the project, for example: TST for the TST000 project, or ANY, signifying a companywide table for any project.
The first part of this identifier text is either the three-letter name of the project, for example: TST for the TST000 project, or ANY, signifying a companywide table for any project.
The first part of this identifier text is either the three-letter name of the project, for example: TST for the TST000 project, or ANY, signifying a companywide table for any project.

TST
ANY
PRF
ORI
MAT
UNI
TSTPRF*TSTPRF
BOCAD*C:\AVEVA\Plant\Bocad\maps\Bocad\Bocad.map
AVEVA*C:\AVEVA\Plant\AVEVA\maps\xxxx\
.map
ANYUNI*ANYUNI
BOCAD*C:\AVEVA\Plant\Bocad\maps\Bocad\BocadUni.map
AVEVA*C:\AVEVA\Plant\AVEVA\maps\xxxx\
Uni.map


Environment variable ‘$nnnn' not understood. - The application cannot determine the meaning of %nnnn% in the mapping file.
The application search order is for mapping files for:
The data lines are arranged, as in the above examples, as pairs between data found in the base product and that to be output in the file generated by the Export process.
User macro nnnn
not found
Cannot find user macro.
Error in user macro
nnnn
PML programming error in user macro.
User macro nnnn
not found
Cannot find user macro.
Error in user macro
nnnn
PML programming error in user macro.

User macro nnnn
not found
Cannot find user macro.
Error in user macro
nnnn
PML programming error in user macro.

Environment variable ‘$nnnn' not understood
User macro nnnn
not found
Error in user macro
nnnn


There are two situations for choosing whether a particular steel profile is permitted or not. The situations are Default or MulTiple.
The default steel standard is that listed as the first entry in the Steel Standard mapping file. This is the preferred standard.
If the profiles come from the other listed standards, they are deemed to be acceptable. In this case, a warning message will be output to the log file. Profiles taken from standards which are not in the list are flagged as errors.
The Steel Standards mapping files may be project or company specific. The identification convention used in the first line of the file, by which we identify the file, is similar to that mentioned above for other internal mapping files. It is the second entry on the first line which is critical. In this case, it is composed of two parts. The first part is either the three-letter name of the project, for example: TST, or it is the word ANY signifying that the file is company specific; that is for ANY project. The second part, STD, is compulsory.
The lines are * separated pairs (with no spaces), only the first value of which is used internally. The second value can be for information, as these files will be listed as comments in the exported file. The first value of each entry must be the country code for the profile standards, as recorded in the external Profile mapping files and as suggested in the section discussing the format of the Profile mapping files.
The sequence of search is for a project-specific mapping file, and then a company-specific file.
A project-specific mapping file for the TST project might look like:
A company-specific file for ANY project might look like:
TSTSTD*TSTSTD
EUR*Euronorm
BRI*British
AME*American
ANYSTD*ANYSTD
EUR*Euronorm
BRI*British
AME*American
GER*German
CAN*Canadian
JAP*Japanese

Default
Mul
Tip
le
TST,
ANY
STD
*
TST
ANY


While setting up the Export or Import variables, the external mapping files are initially tested to see if they are valid. At the top of each file is a check line indicating that the file is related to AVEVA Bocad Steel. The check line must be of the form:
AVEVA BOCAD
Note:
Tab characters are not permitted in the mapping files.
Comments may be included in the mapping files. They are indicated by a hash (#) character as the first non-blank character on the line.
Blank lines are also permitted.

Note:


Suitable Mapping Table File not found
File specified in the mapping table is not found.
Not a suitable Mapping Table File - Is it empty?
The header may not be of the correct format. The header is incorrect.
Suitable Mapping Table File not found
File specified in the mapping table is not found.
Not a suitable Mapping Table File - Is it empty?
The header may not be of the correct format. The header is incorrect.

Suitable Mapping Table File not found
File specified in the mapping table is not found.
Not a suitable Mapping Table File - Is it empty?
The header may not be of the correct format. The header is incorrect.

Suitable Mapping Table File not found
Not a suitable Mapping Table File - Is it empty?


Because in the base product element names cannot contain spaces, space-separated mapping files receive special treatment to allow spaces in external Profile names. A description of the individual fields in the Profile Mapping Files is given after this section.
The file format has four or five fields per line. Four fields are used for old format mapping files where the AVEVA profile name is either the Catalogue or the Specification name. Five fields are for either the newer format (version 2) or the Block format mapping files. These include both the AVEVA Catalogue™ and the Specification name. Version 2 files are differentiated from the Block format files by having a different header line which includes a single version number, rather than a description of the column widths. The Block format file is recommended.
The fields are read in the following order.
Refer to External Mapping File Separator for further information on how you can specify which separator which the application use to discriminate between fields.

External Mapping File Separator
External Mapping File Separator


You can also use Comma Separated Variable (CSV) format for the Profile mapping. In CSV format, the fields are separated by commas rather than by spaces. This means, therefore, that the names of profiles must not contain commas, but the external profile name can still contain spaces.
CSV format allows you to manage the mapping files in a spreadsheet program. If you are constructing a CSV file by hand, you should be aware how a CSV file handles commas in fields. Again, CSV files, managed in a spreadsheet program, can be converted easily to Block format.


Record Structure for Profile Mapping File

The mapping file consists of records of catalogue or specification profile name matched with the external profile name and two other fields giving the origin and profile shape code as recognized by the external package.
The profile names for the external package must be ascertained by you and matched correctly with the equivalent name.


Sometimes the project requires that the designer cannot mix profiles from more than one steel standard at the same time. Therefore, we need to record the origin of the profile. This is done in the third field, the steel standard field, which is currently codified as follows:
America
AME
Britain
BRI
Canada
CAN
Euronorm
EUR
Germany
GER
Japan
JAP
If you want to include profiles or joints from another standard or country, you must add a new and unique identifier.

Country
Code
America
AME
Britain
BRI
Canada
CAN
Euronorm
EUR
Germany
GER
Japan
JAP


The Profile Type field defines exactly what shape the profile is. This is because there may be many occurrences of the same profile name in the 3D steel detailing package, but used in different manners. For example, only those T shapes which are derived from cutting up I shapes may be stored. This could be recorded in the file as follows:
W21X44
W21X44
AME
1
I shape
WT10.5X22
W21X44
AME
10
Tee ex W21X44
The profile shape codes for the new AVEVA supplied catalogue are as follows:
1
I-shape (BEAM)
2
L-shape (ANG)
3
Z-shape
4
C shape (BSC)
5
FlatBar
6
Tube (TUBE)
7
Bar (TUBE)
8
RH-shape (BOX)
9
TC-Shape (BSC)
10
T-shape (TEE)
12

13
Cone

External
Origin
Shape Code
Description
W21X44
W21X44
AME
1
I shape
WT10.5X22
W21X44
AME
10
Tee ex W21X44
Type Code
Shape
1
I-shape (BEAM)
2
L-shape (ANG)
3
Z-shape
4
C shape (BSC)
5
FlatBar
6
Tube (TUBE)
7
Bar (TUBE)
8
RH-shape (BOX)
9
TC-Shape (BSC)
10
T-shape (TEE)
12
13
Cone


To extend the facilities provided by the system, the ASCII file may be extended. Once you have found a match between the base product catalogue profile name and the equivalent profile in AVEVA Bocad Steel, the name match may be added to the file, along with the catalogue origin and profile shape code.


The actual shape code number is not critical: the combination of the shape code and the country code IS critical. The combination of the shape and country codes enable us to identify exactly which AVEVA Catalogue™ item is being used. The list of country codes has been extended for the new AVEVA structural profile catalogue. This allows us to differentiate between the old and new catalogues, and the equivalent shapes in each catalogue. This means that we can apply treatment, such as rotation or mirroring, to any particular shape.
Below is a short extract of a Profile mapping file between the base product and AVEVA Bocad Steel.
This file has 5 columns consisting of the following:
AVEVA BOCAD 5 22 22 19 3 3
C10x15.3  AISC/C10x15.3  USC10*15.3   AME 4
C10x20    AISC/C10x20    USC10*20     AME 4
C10x25    AISC/C10x25    USC10*25     AME 4
C10x30    AISC/C10x30    USC10*30     AME 4
C12x20.7  AISC/C12x20.7  USC12*20.7   AME 4
C12x25    AISC/C12x25    USC12*25     AME 4
C12x30    AISC/C12x30    USC12*30     AME 4
C15x33.9  AISC/C15x33.9  USC15*33.9   AME 4
C15x40    AISC/C15x40    USC15*40     AME 4
C15x50    AISC/C15x50    USC15*50     AME 4
C3x4.1    AISC/C3x4.1    USC3*4.1     AME 4
C3x5      AISC/C3x5      USC3*5       AME 4
C3x6      AISC/C3x6      USC3*6       AME 4
The AVEVA Catalogue™ element name
The AVEVA Specification element name
The name of the profile in the external application (for example: Bocad)
The letter code for the Specification
The Shape Code.
The AVEVA Catalogue™ element name
The AVEVA Catalogue™ element name
The AVEVA Specification element name
The AVEVA Specification element name
The name of the profile in the external application (for example: Bocad)
The name of the profile in the external application (for example: Bocad)
The letter code for the Specification
The letter code for the Specification
The Shape Code.
The Shape Code.
Note:
The identification line at the top of the file which indicates the Target Package, for example: BOCAD. It also indicates the version number of the mapping file structure for example: 2 (it is not complete in any way).

AVEVA BOCAD 5 22 22 19 3 3
C10x15.3  AISC/C10x15.3  USC10*15.3   AME 4
C10x20    AISC/C10x20    USC10*20     AME 4
C10x25    AISC/C10x25    USC10*25     AME 4
C10x30    AISC/C10x30    USC10*30     AME 4
C12x20.7  AISC/C12x20.7  USC12*20.7   AME 4
C12x25    AISC/C12x25    USC12*25     AME 4
C12x30    AISC/C12x30    USC12*30     AME 4
C15x33.9  AISC/C15x33.9  USC15*33.9   AME 4
C15x40    AISC/C15x40    USC15*40     AME 4
C15x50    AISC/C15x50    USC15*50     AME 4
C3x4.1    AISC/C3x4.1    USC3*4.1     AME 4
C3x5      AISC/C3x5      USC3*5       AME 4
C3x6      AISC/C3x6      USC3*6       AME 4
Note:


Section Profiles sized by Design Parameters

To export or import a profile defined by design parameters to AVEVA Bocad Steel, you need to add a line at the bottom of the mapping file as follows:
For example:

CATREF SPREF
PRS@2@4@1@3
EUR
1
Where
PDMS profile name gives the Catalogue and Specification names of the profile used in PDMS.
BOCAD profile name is the name of the AVEVA Bocad Steel profile followed by design parameter numbers prefixed by @ symbol
Standard Key word is the country code for the type of standard.
Shape Code is the profile number given by the table above.
If the profile name is not found earlier in the mapping file, the application will try to map the profile to the PDMS profile finding the name that matches the prefix before the first @ in the name.
If a match is found, the order of the parameters will be used to set the corresponding design parameters in PDMS.
Below is an extract of the mapping file for just parameterized profiles.

There are three formats for Profile mapping files, the first two formats may be space or comma separated. And are indicated as such by setting the !!bocProfSep variable as !!bocSpaceSep or !!bocCommaSep.
The first has been described here, each line in the mapping file contains 4 fields - the AVEVA Catalogue™ or specification profile name, the external profile name, the country code and the shape code. Interpretation of the first field depends upon the !!bocProfMapRef variable as 'SPRE' or 'CATR'.
In this format, each line in the mapping file contains 5 fields - the AVEVA Catalogue™ profile name, - the AVEVA specification profile name, the external profile name, the country code and the shape code. Which of the AVEVA columns is picked also depends upon the !!SDNFProfMapRef variable. In order to distinguish this file from the previous format, the header line has an additional "version" field.
For example
AVEVA
FRAMEWORKS
2
AVEVA
FRAMEWORKS
2
The third, and now preferred, format is the Block format, a space separated file that has been pre-processed to facilitate more rapid parsing. Again, each record has 5 fields selectable according to the !!bocProfMapRef variable. This file has a header with more fields describing the column sizes for the file.
For example
AVEVA
FRAMEWORKS
5 19 19 16 3 3
AVEVA
FRAMEWORKS
5 19 19 16 3 3
This file type is indicated by setting the !!bocProfSep variable to be !!bocBlockSep, refer to AVEVA ABSI/SDNF Mapping File Convertor for further information.
PDMS profile names
BOCAD profile name
Standard Key word
Shape Code
For example:
CATREF SPREF
PRS@2@4@1@3
EUR
1
AVEVA
FRAMEWORKS
2
AVEVA
FRAMEWORKS
5 19 19 16 3 3

AVEVA ABSI/SDNF Mapping File Convertor
Where
AVEVA ABSI/SDNF Mapping File Convertor


New profile catalogue elements sized by Design Parameters

Some additional design profiles are provided for PDMS as follows:
These profiles may be optionally added to a catalogue by entering into Paragon and running the following function in a command window:


Profile cannot be
mapped
The profile is not in the Profile Mapping File.
Profile is not in
the standard
The profile is in the Profile Mapping File but is not in any one of the set of standards.
Profile is not the default
The profile is in the Profile Mapping File and is in one of the set of standards, but not the default standard.
Multiply defined entries
in Profile Table
Either a profile to be mapped or a mapped profile appears more than once in the Profile Mapping File.
Profile cannot be
mapped
The profile is not in the Profile Mapping File.
Profile is not in
the standard
The profile is in the Profile Mapping File but is not in any one of the set of standards.
Profile is not the default
The profile is in the Profile Mapping File and is in one of the set of standards, but not the default standard.
Multiply defined entries
in Profile Table
Either a profile to be mapped or a mapped profile appears more than once in the Profile Mapping File.

Profile cannot be
mapped
The profile is not in the Profile Mapping File.
Profile is not in
the standard
The profile is in the Profile Mapping File but is not in any one of the set of standards.
Profile is not the default
The profile is in the Profile Mapping File and is in one of the set of standards, but not the default standard.
Multiply defined entries
in Profile Table
Either a profile to be mapped or a mapped profile appears more than once in the Profile Mapping File.

Profile cannot be
mapped
Profile is not in
the standard
Profile is not the default
Multiply defined entries
in Profile Table


This is a tool to format the profile mapping files shared by the SDNF and ABSI interfaces and the AVEVA Bocad Steel from CSV files to a format for more streamlined use. It transforms input files, including formulaic entries into a "block" format where we know how big each field is. This makes the reading of the files much faster.
In order to speed up the interface the top line of the mapping file gives details of the field widths in the rest of the file. For example:
The converter does run stand-alone from the AVEVA E3D 2.1™ install folder, but it is also accessible from the Control menus on the Export and Import main dialogs for both SDNF and ABSI interfaces.
The format of the file is as follows…
[PDMS Catref name, PDMS Specref name] [External profile name, country code, shape code]
For example:
The shape and country codes are internal to us to help us uniquely identify the profile. At translation time, using a combination of these fields we can build a dictionary for profile mapping between PDMS/AVEVA E3D 2.1™ and Bocad, for example.
COMMENT;CATREF;SPREF;EXTERNAL;STANDARD;SHAPE
#;EU_BF100x7;EU-BF100x7;;EU;21
;EU_CF_CHS101.6x2.0;EU-CF-CHS101.6x2.0;=CHS{1}*{2};EU;7
;EU_CF_CHS101.6x2.5;EU-CF-CHS101.6x2.5;=CHS{1}*{2};EU;7
;EU_CF_CHS101.6x3.0;EU-CF-CHS101.6x3.0;EU-CF-CHS101.6x3.0;EU;7
Goes to
AVEVA BOCAD 5 19 19 19 3 2
EU_CF_CHS101.6x2.0 EU-CF-CHS101.6x2.0 CHS101.6*2.0       EU 7
EU_CF_CHS101.6x2.5 EU-CF-CHS101.6x2.5 CHS101.6*2.5       EU 7
EU_CF_CHS101.6x3.0 EU-CF-CHS101.6x3.0 EU-CF-CHS101.6x3.0 EU 7
EU_CF_CHS101.6x2.0 EU-CF-CHS101.6x2.0 CHS101.6*2.0       EU 7

COMMENT;CATREF;SPREF;EXTERNAL;STANDARD;SHAPE
#;EU_BF100x7;EU-BF100x7;;EU;21
;EU_CF_CHS101.6x2.0;EU-CF-CHS101.6x2.0;=CHS{1}*{2};EU;7
;EU_CF_CHS101.6x2.5;EU-CF-CHS101.6x2.5;=CHS{1}*{2};EU;7
;EU_CF_CHS101.6x3.0;EU-CF-CHS101.6x3.0;EU-CF-CHS101.6x3.0;EU;7
AVEVA BOCAD 5 19 19 19 3 2
EU_CF_CHS101.6x2.0 EU-CF-CHS101.6x2.0 CHS101.6*2.0       EU 7
EU_CF_CHS101.6x2.5 EU-CF-CHS101.6x2.5 CHS101.6*2.5       EU 7
EU_CF_CHS101.6x3.0 EU-CF-CHS101.6x3.0 EU-CF-CHS101.6x3.0 EU 7
EU_CF_CHS101.6x2.0 EU-CF-CHS101.6x2.0 CHS101.6*2.0       EU 7


It is accessed from the Interfaces tab.

It can also be accessed if you set up a link to run the program from within the AVEVA E3D installation.

Interfaces


There are 4 main combinations of settings:
Source folder unchecked/ External folder unchecked
(user specified output file name - allows producing temporary or copy files)
Input source file and target file names. Transform source file -> external file
For example: Bocad-BS.csv -> externalFileName.map
Source folder unchecked/ External folder checked
(output file name derived from input file name)
Input source file and external folder names. Transform source file -> external file in target folder
For example: Bocad-BS.csv -> Bocad-BS.map in external folder
Source folder checked/ External folder unchecked
(merge all CSV files into a stated file)
Input source folder and external file names. Transform and merge all source files -> 1 big target file
For example: (Bocad-ASNZ.csv, Bocad-BS.csv, … Bocad-US.csv) -> externalFileName.map
Source folder checked/ External folder checked
(bulk processing of multiple CSV files)
Input source folder and external folder names. Transform all source files in source folder -> 1 external file per source file in external folder
For example: Bocad-ASNZ.csv, Bocad-BS.csv, … Bocad-US.csv -> Bocad-ASNZ.map, Bocad-BS.map, … Bocad-US.map
The latter 2 options enable you to build larger compound mapping files of various sets of standards. By default, we issue a single file per standard. However, you are able to concatenate various standards into the working set using the bulk options.

unchecked
unchecked
file
Bocad-BS.csv -> externalFileName.map
unchecked
checked
ocad-BS.csv -> Bocad-BS.map
checked
unchecked
(Bocad-ASNZ.csv, Bocad-BS.csv, … Bocad-US.csv) -> externalFileName.map
checked
checked
Bocad-ASNZ.csv, Bocad-BS.csv, … Bocad-US.csv -> Bocad-ASNZ.map, Bocad-BS.map, … Bocad-US.map
bulk


The CSV file separator can be ',' ';' or tab you have to tell the spreadsheet package what the field separator is as the source file is opened.
The formulae can use either '{}' or '()'. Formulae also begin with '='. This is often an indicator for internal formulae. In order to see the formulae without the system making any attempt to evaluate them, you will have to turn this feature off, by showing the fields only.
The translator saves the previous configuration settings in the first place it can find out of the folders pointed to by the environment variables "AVEVA_DESIGN_USER", "PDMSUSER", "TEMP".


The workflow is essentially converting a .csv file to a .map file, you will spend time in Excel editing the .csv file. When done, it should go through the mapping tool to produce a .map file.
If there are errors, the converter produces an annotated .map.csv file which enables you to see where the problems are. Ideally the problems should be rectified in the main source .csv file and the file converted again.
For both AVEVA E3D 2.1™/PDMS and AVEVA Bocad Steel, the source file for the mapping file production will be the .csv file. The resultant mapping file is shared by the SDNF and ABSI interfaces as well as the AVEVA Bocad Steel product.
The conversion process can rely on other tables and files that are relevant to the external package. The External data folder is the folder that contains the converter related files, for example: the alle_prof.inp, profitab.inp and the generic.lis files for Bocad. For the converting of mapping files for other applications there is a recommended file structure to aid the conversion. We will have another folder with the profile lists and anything else we need. This is described in detail below.
The other targets that the tool lists are more for round-tripping E3D->E3D or PDMS->PDMS. In this case the 2nd and 3rd columns will be the same now, if you have used the CATR, the 1st and 3rd columns would be the same.

.csv
.map
.csv
.map
.map.csv
.csv
.csv
External data folder


We supply mapping files for AVEVA E3D 2.1™ and PDMS to allow round tripping of data, for Bocad and a sample set for Intergraph Frameworks, the originators of the SDNF file format.
How you use the Frameworks files as a template to build mapping files for other targets will be described below.

The source CSV files are in a folder <target>_CSV, and the output mapping files are in a folder <target_Maps>.

The system is configured to pick these up automatically using the BLOCKMAPS environment variable. If you place them somewhere else on the file system, you will have to tell the interfaces where they are.

The source file text below

Is translated to:


Building Mapping Files for any other target application

There are basic lists that the interfaces and convertor rely on.


1
BEAM - I-shape
1
RSJ - I-shape
1
DBEA - I-shape
1
DINI - I-shape
1
JISI - I-shape
2
ANG - L-shape
2
LP - L-shape
3
ZEE - Z-shape
4
BSC - C-shape
4
DBSC - C-shape
4
CHAN - C-shape
4
DINU - C-shape
5
FBAR - Flat bar
5
FB - Flat bar
6
RBAR - Bar
7
TUBE - Tube
8
BOX - RH-shape
9
BSC - TC-shape
10
TEE - T-shape
11
SBAR - Square bar
12
HBAR - Hexagonal bar
13
CONE - Cone
14
TR - Stair tread
15
RECT - Rectangular concrete profile
21
BULB - Bulb
1
BEAM - I-shape
1
RSJ - I-shape
1
DBEA - I-shape
1
DINI - I-shape
1
JISI - I-shape
2
ANG - L-shape
2
LP - L-shape
3
ZEE - Z-shape
4
BSC - C-shape
4
DBSC - C-shape
4
CHAN - C-shape
4
DINU - C-shape
5
FBAR - Flat bar
5
FB - Flat bar
6
RBAR - Bar
7
TUBE - Tube
8
BOX - RH-shape
9
BSC - TC-shape
10
TEE - T-shape
11
SBAR - Square bar
12
HBAR - Hexagonal bar
13
CONE - Cone
14
TR - Stair tread
15
RECT - Rectangular concrete profile
21
BULB - Bulb

1
BEAM - I-shape
1
RSJ - I-shape
1
DBEA - I-shape
1
DINI - I-shape
1
JISI - I-shape
2
ANG - L-shape
2
LP - L-shape
3
ZEE - Z-shape
4
BSC - C-shape
4
DBSC - C-shape
4
CHAN - C-shape
4
DINU - C-shape
5
FBAR - Flat bar
5
FB - Flat bar
6
RBAR - Bar
7
TUBE - Tube
8
BOX - RH-shape
9
BSC - TC-shape
10
TEE - T-shape
11
SBAR - Square bar
12
HBAR - Hexagonal bar
13
CONE - Cone
14
TR - Stair tread
15
RECT - Rectangular concrete profile
21
BULB - Bulb