"Brass, red 80% Cu","Red Brass "
"Brass, yellow 65% Cu","Yellow Brass "
"Brass, cast","Cast Brass"
PML programming error in user macro.
the User Guide for details of how the Neutral File understands default orientations of certain profiles.
If the user defines their 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:
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
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 customised 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
• 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:
The user is 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 recognise 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.
ENCODING:ASCII
# header texts
# non‐ASCII profiles
:Γρxνxθ:Corinthian Column, 1 cubit:
# non‐ASCII materials
|χάλυβα, ανθρα|Green‐veined m arble|