Internal Mapping Files

The application relies on several internal mapping files. These define where external mapping files are located on the user’s system network, or they define the mapping of strings or attributes between the base product and the intermediate file. It is the user’s responsibility to modify them correctly so that they indicate the correct file location.

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.

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 doe 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 the user's 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 the user’s application, the user may include environment variables in the path names as long as they are defined in the base product format; for example:

%ENVVAR%\¼

These environment variables cannot be search paths: they must translate to a reference to a single folder.

Error and Log File Messages

File Mapping Files

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 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 second part must be one of:
The project-specific Profile mapping files for the TST project may be similar to:

TSTPRF*TSTPRF

BOCAD*C:\AVEVA\Plant\Bocad\maps\Bocad\Bocad.map

AVEVA*C:\AVEVA\Plant\AVEVA\maps\xxxx\E3D.map

and a companywide Unicode test string mapping table may look like:

ANYUNI*ANYUNI

BOCAD*C:\AVEVA\Plant\Bocad\maps\Bocad\BocadUni.map

AVEVA*C:\AVEVA\Plant\AVEVA\maps\xxxx\E3DUni.map

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:

TSTMAT*TSTMAT

BOCAD*%BOCDATA%\Bocad\Bocad.map

AVEVA*%BOCDATA%\AVEVA\AVEVAMat.map

A companywide Profile Orientation mapping table would look similar to the following:

ANYORI*ANYORI

BOCAD*%BOCMAIN%\maps\Bocad\BocadOri.map

AVEVA*%BOCMAIN%\maps\AVEVA\AVEVAOri.map

for further information of the format of the external mapping files, consult the relevant section in this guide.

Error and Log File Messages

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:

1. A specific project;

2. Any project.

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.

Error and Log File Messages

Steel Standards Mapping Files

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 three-letter coding 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:

TSTSTD*TSTSTD

EUR*Euronorm

BRI*British

AME*American

A company-specific file for ANY project might look like:

ANYSTD*ANYSTD

EUR*Euronorm

BRI*British

AME*American

GER*German

CAN*Canadian

JAP*Japanese