External Mapping Files

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.

Error and Log File Messages

Space-Separated Format for Profile Mapping Files

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 four fields are read in the following order.

1. The first field is the AVEVA Bocad Steel Interface name (with no leading, trailing or embedded spaces).

2. The fourth field is the Profile shape code (with no leading, trailing or embedded spaces).

3. The third field is the Steel Standard (with no leading, trailing or embedded spaces).

4. The second field is the external profile name, once the leading and trailing spaces have been removed.

See for information on how the user can specify which separator which the application will use to discriminate between fields.

CSV Format for Profile Mapping Files

The user 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 the user to manage the mapping files in a spreadsheet program. If the user is constructing a CSV file by hand, the user should be aware how a CSV file handles commas in fields.

Profile Mapping Files

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 catalogue item in AVEVA Bocad Steel Interface and its equivalent in the other system, to which, or from which, data are to be transferred. It is the user’s 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 the user.

Record Structure for Profile Mapping File

The database file consists of records of catalogue 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. A typical record is as follows:

300X300X214.00SHS TUB30030025.0 BRI 8

The fields are described below:

The catalogue names for the external package must be ascertained by the user and matched correctly with the equivalent name.

Steel Standard Field

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:

If the user wants to include profiles or joints from another standard or country, the user must add a new and unique three-character identifier.

Profile Shape Code Field

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:

The profile shape codes are as follows:

Extending the Profile Mapping File

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

Sample Profile Mapping File

Below is a short extract of a Profile mapping file between the base product and AVEVA Bocad Steel.

This file has five columns consisting of the following:

• 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.

  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).

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:

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 three letter 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.

New profile catalogue elements sized by Design Parameters

Some additional design profiles are provided for PDMS as follows:

5. Design parameter controlled Z profile

6. Design parameter controlled solid circular bar profile

7. Design parameter controlled flat bar profile

8. Cone profile where thickness is perpendicular to surface.

9. Design parameter controlled flanged C profile.

These profiles may be optionally added to a catalogue by entering into Paragon and running the following function in a command window:

!!boccatadespar()

Error and Log File Messages

Material Mapping Files

Elements cannot be transferred through the AVEVA Bocad Steel Interface if they do not have a valid material associated with them.

The existing base product material description may not be recognized; consequently, there must be a means by which we can translate the material description between systems. This is performed by means of a Material mapping file which relates the base product text description of a material to that output to, or found in, a file.

The user can modify and extend the mapping file.

When the application is started, the Properties database is searched for SOLI elements which may define materials used to fabricate elements in the base product. An internal list is then built for rapid reference.

Materials are usually associated with the base product elements using the Material Reference attribute, MATR, which points to a SOLI element in the Properties database. However, the user may want to use the local :FABMGRADE attribute to specify the material. Either of these should be set for the application to be able to export elements successfully.

If the above system is still not specific enough, there is a mechanism by which the user can define from where the material information is to be derived. See the next section for further information.

When an element is exported, its material is determined by inspecting the :FABMGRADE attribute first, then the Description attribute of the SOLI element to which the MATR refers. If that fails, the user configurable mechanism is invoked. The text is then transferred locally to the :FABMGRADE attribute on the SCTN or PANE element. The text is then looked up in the Material mapping file to check that there is a translation into the file replacement text. The local material text is still exported.

When an element is to be imported, the file material description is looked up in the material mapping file and translated into the base product equivalent text string. This is then initially copied into the :FABMGRADE attribute of the element before any attempt is made to rationalise the MATR. If a SOLI element with this material text is found, the application will set the MATR to point to the correct SOLI element.

As with the profile mapping file, the first line is an identifier which indicates the external package or system with which the file is associated.

Error and Log File Messages

User-Definable Material Macro

The user 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 the user has specific requirements as to where the material information resides. The bocgetusermatl.pmlfnc function can then be modified. Once modified, the user should execute a PML REHASH ALL command.

The example macro is as follows:

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 |SCTN| )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

The above example assumes that the material information for Sections 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 or Panel. See the previous sections for further information of how the user can configure the system to use a material macro with a name of the user’s choice.

Note:
In writing the user’s own macro, the user 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.

See regarding the naming of this macro.

Error and Log File Messages

Sample Material Mapping File

Below is a sample comma separated mapping (CSV) file to map between the base product materials found in the Properties database and the file targeted at XSteel.

AVEVA,BOCAD

"unset","unset"

"TREAD-ALU","TREAD-Aluminum"

"ALUMINIUM","Aluminum"

"GR 420 I","GR 420 I"

"Pyrocrete","Fire concrete"

"Tread Grade","Tread Grade"

"LDPHP-GRADE","LDPHP-GRADE"

"Aluminium, cast","Aluminium, cast"

"Aluminium, wrought","Wrought Aluminium"

"Aluminium, Duralumin","Duralumin"

"Brass, red 80% Cu","Red Brass "

"Brass, yellow 65% Cu","Yellow Brass "

"Brass, cast","Cast Brass"

"Steel, carbon","Carbon Steel"

"Steel, chrome","Chrome Steel"

"Steel, Ni-chrome","Ni Steel"

Profile Orientation Mapping Files

Using the Profile Orientation Mapping File you can define how translates a profile from the base product format into the Neutral File format on Export, or from it on Import. Refer to the User Guide for further information of how the Neutral File understands default orientations of certain profiles.

If you define your own catalogue profiles, or modify the supplied ones, and need to transform them into or from the format, this mapping file should be used. In all cases an Orientation mapping file should be available, even if it is empty apart from the first line.

Below is an example file:

AVEVA BOCAD

BRI 2 0 180

BRI 4 1 180

DIN 2 0 180

DIN 4 1 180

EUR 2 0 180

EUR 4 1 180

The first line is the file identification line, described as for the Material or Profile mapping files. The structure of the rest of the mapping file is of a comma or space separated file with four fields per line.

The first two fields provide the identification of the profile for treatment. The first of the identification fields states the steel standard from which the profile is to be taken. The second is the actual profile type code according to the codes given. Thus, in the example above, the user can see that the channels (type 2) and angles (type 4) from the Euronorm, DIN and British Standard catalogues have been identified for special treatment.

The third and fourth fields describe what the user wants to do with the profile shape. The third is the mirroring flag, which should be set to 1 if the profile is to be reflected about the Y-axis. This will commonly be the case for angle profiles. no mirroring is indicated by a value of 0 in this field.

The last field defines how much additional angular rotation the user wants to apply to the shape. For example, some catalogues may define the long leg of an unequal angle to be on the horizontal, whereas AVEVA Bocad Steel Interface expects it to be vertical. The rotation angle must be between -180 and +180 degrees.

Note:
Mirroring will change the start and end positions of the linear member. It is therefore advisable that if the user can achieve the same result purely by rotation, then the latter is the preferred option. In this way the user will avoid confusion in AVEVA Bocad Steel.

If, during the Import or Export process, an entry for a specific profile is not found, no action is taken, and no error message is output as it is assumed that the user does not want it to receive special treatment.

The following figure illustrates the effect of each operation on different catalogue representations of an angle profile. We re-emphasise the difference in the handedness of the coordinate systems.

Mirrored Profiles

In the base product it is possible to set a mirror flag which implies that the profile is to be mirrored about the local Y axis, while keeping all other geometric attributes unchanged. Also the user might wish to define a new arrangement of profile in the catalogue that would need mirroring before being written in the ABS file using the Orientation Mapping File. Under normal circumstances the ABS file would simply transfer a mirror flag, indicating what is required and how to interpret the geometric data.

Unfortunately, AVEVA Bocad Steel cannot handle mirroring, in any form. Therefore the ABSI interface has to handle all this internally before export, and after import. However, it is impossible to completely undo the transformations that have been performed on an element for export when the interface is re-importing the same element. For example: the ends might have been swapped round, or the end connectivity might be changed. In these situations the Compare/Merge might highlight a changed element even though it appears to occupy exactly the same location.

Unicode Text String Description Files

Users who take advantage of the Unicode features of the base product may have issues when exporting and importing a model. The primary danger is where there are catalogue profile or material names in the base product that contain Unicode characters. Therefore, a dictionary file may be written to convert any base product strings that contain Unicode characters into equivalent strings that do not. It is these latter strings that will appear in the file. This might actually be a description of the profile, rather than the known profile name. This could be to inform or alert the users of the external application of what the profile is meant to be.

Because there are strings other than the profile names that appear in the file, this Unicode description file should be regarded as a kind of dictionary, a look-up for any string, rather than just a profile name description table. Therefore, its format and use is different from that of the other mapping files. It is used immediately prior to writing out the text strings and it is only to contain the strings that require stripping of Unicode characters. It is also used on file import.

This Unicode description file may be customized for each target system, in the same way as the other mapping tables. This will contain:

• An indication of the encoding to be used for the file

  • Unicode UTF-8 with a Byte Order Mark (BOM):

    ENCODING:UTF8BOM

  • Unicode UTF-8 without BOM:

    ENCODING:UTF8noBOM

  • Force to Default encoding:

    ENCODING:DEFAULT

  • Force to ASCII:

    ENCODING:ASCII

• A set of string substitutions to be used whenever a quoted-string is written to the file.

  • As potentially any character can be used in the string, first non-space character of the line is used as a delimiter for that line

  • Only complete strings would be substituted

  • Comment lines are indicated by '#'

  • not every string needs to be in the dictionary - others would be passed through without error (but would trigger a warning if characters were lost in the encoding)

So a dictionary for export might look like:

You are not forced to prepare one of these files: the system will cope if one does not exist. It would just mean that the strings would not be translated and the user would have to take his chance with the target package. Further, the file can be empty, but if there are any strings requiring description, there must be the ENCODING: statement as the first non comment line in the file.

It should be noted that text fields are of a fixed maximum width. If the resultant text is too long, it will be truncated, and the user warned. Ideally, the translation should succeed with no truncation warnings, and all profiles mapped either by the main mapping file or through using the Unicode description file. If, however, the user decides to output in UTF-8 characters, and thereby diverge from the literal interpretation of the format, truncation will not take place.

On import the system will attempt to recognize names in the dictionary, and to translate them back into the original names. This is in addition to the usual profile and material mapping files.