Internal Mapping Files

Structural Design User Guide

SDNF Export/Import : Internal Mapping Files

The interface 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 Design and the intermediate SDNF file. It is the user’s responsibility to modify them correctly so that they indicate the correct file location

Note:

If the user changes any of the internal mapping files, the user must reload the Design user interface from macros. Alternatively the user can use the Re-initialise menu option on the main SDNF Import and Export forms. The user 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, the user will be prompted to confirm that the user wants to carry on with using the interface, although it is frequently inadvisable. If the user does 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, e.g. SAMDFLTS, and AVEVA_DESIGN_USER. In locating the map files, the folders are searched in the listed sequence. This enables the user to have company, project and user mapping files that can 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 below.

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

As an aid to generalising the user’s interface, the user may include environment variables in the path names as long as they are defined in AVEVA E3D™ 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


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 recognise an external package, but there are no mapping table files associated with it.

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

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, e.g. 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:


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

STRUCAD*C:\AVEVA\Plant\SDNF\maps\StruCad\StruCad.map

XSTEEL*C:\AVEVA\Plant\SDNF\maps\XSteel\XSteel.map

STEELCAD*C:\AVEVA\Plant\SDNF\maps\SteelCad\SteelCad.map

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

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

ANYUNI*ANYUNI

STRUCAD*C:\AVEVA\Plant\SDNF\maps\StruCad\StruCadUni.map

XSTEEL*C:\AVEVA\Plant\SDNF\maps\XSteel\XSteelUni.map

STEELCAD*C:\AVEVA\Plant\SDNF\maps\SteelCad\SteelCadUni.map

AVEVA*C:\AVEVA\Plant\SDNF\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, SDNFMAPS, might look like:

TSTMAT*TSTMAT

STRUCAD*%SDNFDATA%\StruCad\StruCadMat.map

XSTEEL*%SDNFDATA%\XSteel\XSteelMat.map

STEELCAD*%SDNFDATA%\SteelCad\SteelCadMat.map

AVEVA*%SDNFDATA%\AVEVA\AVEVAMat.map

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

ANYORI*ANYORI

STRUCAD*%SDNFMAIN%\maps\StruCad\StruCadOri.map

XSTEEL*%SDNFMAIN%\maps\XSteel\XSteelOri.map

STEELCAD*%SDNFMAIN%\maps\SteelCad\SteelCadOri.map

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

For details 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.

Holds and Paint Spec Files

The simplest tables are the Holds and Paint Spec tables which are just for reference for the user. The tables described here just provide an aid to the user, 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 Design: 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:

Connection Mapping File

The Connection mapping table allows the user to define a conversion table between a Design 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 above 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 customisation process described above; the second is the project name, e.g. 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:

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

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

The interface search order is for mapping files for:

A specific Source or Target Package and a specific project;

Any Source or Target Package and a specific project;

Any Source or Target Package and any project.

The data lines are arranged, as in the above examples, as pairs between data found in Design 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. This is then mapped to the output string based on the mapping table. For example, an occurrence of ‘EP’ in the Design database will be 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 Design, 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 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 the user wants there to be a default end connection type, all the user needs to do is to include in the file a line similar to the following.

Note:

There is no Design value before the asterisk. This means that for unset CTYA values Default Connection is mapped into the output file.

User-Definable Mapping Macros

The user will notice that the mapping file extract shown above has the entry:

BP*macro BasePlate

This is the means by which the user can customise the text string in the SDNF output file, rather than just having a single text for all cases; for example, if the user wants 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 following name is searched for under the %PMLLIB% search path. The macro 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. In the above case, the interface will search for a macro file baseplate.pmlfnc.

The example base plate macro supplied with the interface is:

define function !!BasePlate( ) is STRING

-- Initialisation

!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

This 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’s own macro, the user must handle all errors encountered, so that the macro will safely return a valid PML string, whatever it may be.

Error and Log File Messages


No Connection mapping table for nnnn for project mmmm	System cannot find a suitable table for the nnnn target and mmmm project.
User macro nnnn not found	Cannot find user macro.
Error in user macro nnnn	PML programming error in user macro.
No mapping for Connection type nnnn	Cannot translate Connection text.

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, e.g. TST, or it is the word ANY signifying that the file is company specific; i.e. 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 SDNF 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:

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