Internal Mapping Files

The interface relies on several internal mapping files. These define where external mapping files are located on the system network, or they define the mapping of strings or attributes between Model and the intermediate SDNF file. It is your 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 Model user interface from macros. Alternatively you can use the Re-initialize menu option on the main SDNF Import and Export windows. You should then resave the binary UI.

Internal mapping files are loaded on start-up of the SDNF interface. If there are any problems on loading, you are prompted to confirm that you want to carry on with using the interface, although it is frequently inadvisable. If you do not continue, a fatal error is raised and the interface exited.

Internal mapping files must have a suffix '.map' and be stored in one of 3 areas pointed to by the environment variables AVEVA_DESIGN_DFLTS, the project defaults, for example,. SAMDFLTS, and AVEVA_DESIGN_USER. In locating the map files, the folders are searched in the listed sequence. You can have company, project and user mapping files that overload the previously installed versions. The example internal files supplied by the system are to be found in the folder, SDNFMaps.

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.

When an SDNF export file is created, all these internal files are listed at the top of the file as comments. Comment lines in SDNF start with the # symbol.

As an aid to generalising the user interface, you may include environment variables in the path names as long as they are defined in the correct 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 Tables

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 for the associated external package. The external package may be a 3D steel detailing package (for example, StruCAD), an intermediate file (for example, SDNF), or even a steel fabricator's catalogue. The package name must correspond exactly to that in the list set up during the user customization process.

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 AVEVA project.

The second part must be one of:
The project-specific Profile mapping files for the TST project may be similar to:

TSTPRF*TSTPRF

FRAMEWORKS*C:\AVEVA\Plant\SDNF\maps\FrameWorks\FrameWorks.map

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

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

ANYUNI*ANYUNI

FRAMEWORKS*C:\AVEVA\Plant\SDNF\maps\FrameWorks\FrameWorksUni.map

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

The Material mapping tables are defined in a similar way. For example a TST project-specific Material mapping file, using a previously defined environment variable, SDNFMAPS, might look like:

TSTMAT*TSTMAT

FRAMEWORKS*C:\AVEVA\Plant\SDNF\maps\FrameWorks\FrameWorksMat.map

AVEVA*%SDNFDATA%\AVEVA\AVEVAMat.map

A companywide Profile Orientation mapping table would look similar to:

ANYORI*ANYORI

FRAMEWORKS*C:\AVEVA\Plant\SDNF\maps\FrameWorks\FrameWorksOri.map

AVEVA*%SDNFMAIN%\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 interface cannot determine the meaning of %nnnn% in the mapping file.

Text Conversion Mapping Files

The text conversion mapping tables perform conversion operations between text strings derived from the Design database and the SDNF file. These cover the Holds, Paint Spec Coding and Connection Type text.

Environment variable ‘$nnnn' not understood. - The interface cannot determine the meaning of %nnnn% in the mapping file.

Holds and Paint Spec Files

The simplest tables are the Holds and Paint Spec tables which are used for reference. The tables described here, provide an aid, so that the value of the field in the SDNF file may be interpreted. No action is taken by the interface to manage these values inside Model: the value in the :SDNFHOLD and :SDNFPSPEC attributes are used to store and export the values. The SDNF file takes an integer value in the Status and Class field for a Linear Member or Plate which this interface is using as the Holds and Paint Spec values. These tables are output in the top of the SDNF file. Examples are:

STATUS*HOLD

0*Undefined

1*Fixed

2*Provision

3*Other

or

CLASS*PSPEC

0*Undefined

1*Lead Paint

Connection Mapping File

The Connection mapping table allows you to define a conversion table between a Model value and a string value which appears in the Packet 40 entries (Connection Details) in the SDNF file. As this interface currently only exports connections to SDNF, this conversion is made only during the Export process. There is no means yet by which Packet 40 can be imported and interpreted by the interface to create a Joint of the correct type.

The table identification method is similar to the methods described for the external mapping files, but here the code is in three parts depending on a) the Source or Target Package and b) the project. The first part is the three-letter abbreviation for the Source or Target Package as set up in the user customization process; the second is the project name, for example, TST, or ANY; and the third component of the name must be CON. A file for the external package identified by XST and for the TST project might look like:

XSTTSTCON*XSTTSTCON

BP*macro BasePlate

TP*TP

FPWB*FPWB

FPWC*FPWC

A file for any Source or Target Package, but for only the TST project may be:

ANYTSTCON*ANYTSTCON

BP*macro BasePlate

TP*TP

FPWB*FPWB

FPWC*FPWC

and for any Source or Target Package and any project the file might look like:

ANYANYCON*ANYANYCON

BP*macro BasePlate

TP*TP

EP*End Plate

FPWB*FPWB

FPWC*FPWC

The interface search order is for mapping files for:

1. A specific Source or Target Package and a specific project;

2. Any Source or Target Package and a specific project;

3. Any Source or Target Package and any project.

The data lines are arranged, as pairs between data found in Model and that to be output in the SDNF file generated by the Export process.

On Export, the interface searches for a string identifier in the Design database. The identifier is mapped to the output string based on the mapping table. For example, an occurrence of ‘EP’ in the Design database is output in the SDNF file as ‘End Plate’ in the relevant field in the Packet 40 section of the SDNF file.

To find the end coding in Model, the interface looks at the CTYA attribute on the catalogue description of the Joint associated with an end of a Linear Member (SCTN or GENSEC). The coding is taken from there, but, while the interface exports the data, it is also transferred to the CTYS or CTYE attribute of the SCTN or GENSEC as appropriate. A warning is raised if an end coding mapping cannot be found.

To cater for the fact that the CTYA may not be set and you want there to be a default end connection type, all you need to do is to include a line in the file similar to:.

Note:
There is no Model value before the asterisk. For unset CTYA values Default Connection is mapped into the output file.

ANYANYCON*ANYANYCON

*Default Connection

BP*macro BasePlate

TP*TP

etcº

User-Definable Mapping Macros

The mapping file extract displays the entry:

BP*macro BasePlate

You can customize the text string in the SDNF output file, rather than just having a single text for all cases; for example, if you want to transfer a set of parameters along with the text.

Note:
The SDNF limit for the length of the replacement text is 50 characters.

Thus, when the interface meets a replacement text which has ‘macro’ as its first word, a macro of the defined name is searched for under the %PMLLIB% search path. The macro file name must be completely in lowercase and end in .pmlfnc, according to PML conventions. The macro takes no arguments, as there are no means of transferring them in this situation, and it returns the character string to be inserted into the SDNF file. For example, the interface searches for a macro file baseplate.pmlfnc.

The example base plate macro supplied with the interface is:

define function !!BasePlate( ) is STRING

  -- initialization

  !string = STRING( )

  !start = ( ref )

  -- Some PML to extract the required information

  goto catr

  !thick     = para numb 1

  !nrOfBolts = para numb 2

  same

  !width     = desp numb 1

  !length    = desp numb 2

  -- Concatenate information into the string

  !string = |Base Plate $!width[ 1 ] $!length[ 1 ] | + $

            |$!thick[ 1 ] $!nrOfBolts[ 1 ]|

  -- Return string and exit

  $!start

  return !string

endfunction

The example may return a single text string such as:

‘Base Plate 250 300 25 4’

which should be sufficient information for the external system to generate an end detail of the correct type and dimensions.

It is assumed that the system is at the Design Joint in the database at the point of calling this user macro.

Note:
In writing the user macro, you must handle all errors encountered, so that the macro safely returns a valid PML string, whatever it may be.

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 is 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 used 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; for example, 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 are listed as comments in the exported SDNF file. The first value of each entry must be the country 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