Structural Design User Guide

SDNF Export/Import : Customise SDNF
This chapter describes the PML variables which the user can set to customise SDNF. They are set in the file called sdnfuserdata.pmlfnc found in the SDNF\dflts\user\SDNFPML\functions folder in the user data area of the interface.
The template user modifiable function sdnfuserdata.pmlfnc is found in SDNF\dflts\user\SDNFPML. This whole user folder should be copied to the folder as defined by the environment variable AVEVA_DESIGN_USER. This copy can then be modified to the user's personal requirements.
-- Program equivalent list
-- !equivalent.append( |Existing program for which we have the mapping files| )
-- !equivalent.append( |New program to use the mapping files for the program above| )
Note:
Note that all the files of the same type (either Material, Orientation or Profile) must use the same separator consistently: the user cannot have some Material files space separated, while others are comma separated.
The above syntax defines the names of two macros which are to be found in the folder structure below the %PMLLIB% environment variable. They are named preexport.pmlfnc and postexport.pmlfnc, respectively.
The above defines a reference to a macro which is to be found in the folder structure below the %PMLLIB% environment variable. This macro takes no arguments and returns a string.
In the sdnfuserdata.pmlfnc function there is a variable, !!SDNFProfMapRef, which the user can set to determine whether SDNF uses the Specification or Catalogue Component. By default the lines are as follows, with the second line commented out:
The user can select whether the SDNF file will contain listings of all the mapping files or just the Packet count table. This is done by the !!sdnfBriefHdr variable in the sdnfuserdata.pmlfnc file. By default the SDNF files have brief headers, but if the user wants to include details of all the files used for the translation, the variable can be switched to 'false'.
As has been described above, the file sdnfuserdata.pmlfnc can be modified by hand to provide a degree of customisation of XXX. This overwrites the system variables in sdnfsystemdata.pmlfnc.
There is a third level of customisation available that is accessible by a graphical user interface. This form has access to versions of all the variables in the sdnfuserdata.pmlfnc function, but it does not modify that function at all. Therefore, at this point, the user is working with a local set of configuration data.
The System Configuration window has five tab’s Run Parameters, Model Parameters, Display Colours, Environment Parameters and Macros. The detail of the attributes can be read above. The forms do have some data validation, where appropriate.
By default, the system looks for a file SDNF Interface.xml in the AVEVA_DESIGN_USER area. If present, this file is accessed when this window, and even when the whole XXX system, is initialised. If this file is not available, then the default values that are used are set in sdnfsystemdata.pmlfnc and subsequently overwritten by sdnfuserdata.pmlfnc. The user can save the window, settings to this default file using the Control > Save option. To save the settings to another file, use the Control > Save as... option.
To load any settings file other than the default one use Control > Load... option. A file browser is displayed allowing the user to choose where to locate the new file.
Reset resets the values using the normal form initialisation process with the current variables and any saved SDNF Interface.xml file.
The Re-initialise option goes right back to the source variables in the system and user data and the default SDNF Interface.xml files.
OK transfers the form settings to the main Import/Export system for use in that session. On re-showing the form any unsaved attributes will be lost.
As is described in Transfer of Curved Members, XXX can rebuild a complex member from its component straight and curved segments. This is dependent upon the member name or its components. Using the member names and their start and end positions, a GENSEC can be rebuilt. Unfortunately this may be a wrong assumption when members being imported share duplicate names or parts thereof. This problem can be compounded when the model is a nodal one.

1974 to current year. AVEVA Solutions Limited and its subsidiaries. All rights reserved.
AVEVA Logo