Refer to External Mapping File Separator for further information on how you can specify which separator which the application use to discriminate between fields.
Input source file and target file names. Transform source file -> external file
The workflow is essentially converting a .csv file to a
.map file, you will spend time in Excel editing the
.csv file. When done, it should go through the mapping tool to produce a
.map file.
If there are errors, the converter produces an annotated .map.csv file which enables you to see where the problems are. Ideally the problems should be rectified in the main source
.csv file and the file converted again.
For both AVEVA E3D 2.1™/PDMS and AVEVA Bocad Steel, the source file for the mapping file production will be the .csv file. The resultant mapping file is shared by the SDNF and ABSI interfaces as well as the AVEVA Bocad Steel product.
The conversion process can rely on other tables and files that are relevant to the external package. The External data folder is the folder that contains the converter related files, for example: the alle_prof.inp, profitab.inp and the generic.lis files for Bocad. For the converting of mapping files for other applications there is a recommended file structure to aid the conversion. We will have another folder with the profile lists and anything else we need. This is described in detail below.
There are three separate folders: the source csv files, the resultant mapping files and the supporting data files.
The important file to note is the shapes.txt file, this is a file that links the shape to the file tables in the standard folders below. Below is a sample of the
shapes.txt file.
This indicates, for example, that files C.txt (line 7) are related to the shape code 4, which you will see above refers to C shapes. The profile tables related to the external package may then be sorted into folders named according to the standard to which they apply.
This will assist in housekeeping, as this is just a sample data set, the C.txt contains just 1 entry, UNP220. The interface now has enough information to perform the conversion.
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 GENSEC, 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.
You 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 you have specific requirements as to where the material information resides. The bocgetusermatl.pmlfnc function can then be modified. Once modified, you should execute a
PML REHASH ALL command.
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, a GENSEC or Panel. For details of how you can configure the system to use a material macro with a name of your choice, refer to
User-definable Material Macro for further information.