Professional Documents
Culture Documents
Configuration Guide
AVEVA Solutions Limited
Disclaimer
1.1 AVEVA does not warrant that the use of the AVEVA software will be uninterrupted, error-free or free from
viruses.
1.2 AVEVA shall not be liable for: loss of profits; loss of business; depletion of goodwill and/or similar losses; loss of
anticipated savings; loss of goods; loss of contract; loss of use; loss or corruption of data or information; any
special, indirect, consequential or pure economic loss, costs, damages, charges or expenses which may be
suffered by the user, including any loss suffered by the user resulting from the inaccuracy or invalidity of any data
created by the AVEVA software, irrespective of whether such losses are suffered directly or indirectly, or arise in
contract, tort (including negligence) or otherwise.
1.3 AVEVA's total liability in contract, tort (including negligence), or otherwise, arising in connection with the
performance of the AVEVA software shall be limited to 100% of the licence fees paid in the year in which the user's
claim is brought.
1.4 Clauses 1.1 to 1.3 shall apply to the fullest extent permissible at law.
1.5 In the event of any conflict between the above clauses and the analogous clauses in the software licence under
which the AVEVA software was purchased, the clauses in the software licence shall take precedence.
Copyright
Copyright and all other intellectual property rights in this manual and the associated software, and every part of it
(including source code, object code, any data contained in it, the manual and any other documentation supplied
with it) belongs to, or is validly licensed by, AVEVA Solutions Limited or its subsidiaries.
All rights are reserved to AVEVA Solutions Limited and its subsidiaries. The information contained in this document
is commercially sensitive, and shall not be copied, reproduced, stored in a retrieval system, or transmitted without
the prior written permission of AVEVA Solutions Limited. Where such permission is granted, it expressly requires
that this copyright notice, and the above disclaimer, is prominently displayed at the beginning of every copy that is
made.
The manual and associated documentation may not be adapted, reproduced, or copied, in any material or
electronic form, without the prior written permission of AVEVA Solutions Limited. The user may not reverse
engineer, decompile, copy, or adapt the software. Neither the whole, nor part of the software described in this
publication may be incorporated into any third-party software, product, machine, or system without the prior written
permission of AVEVA Solutions Limited, save as permitted by law. Any such unauthorised action is strictly
prohibited, and may give rise to civil liabilities and criminal prosecution.
The AVEVA software described in this guide is to be installed and operated strictly in accordance with the terms
and conditions of the respective software licences, and in accordance with the relevant User Documentation.
Unauthorised or unlicensed use of the software is strictly prohibited.
Copyright 1997 to current year. AVEVA Solutions Limited, and its subsidiaries. All rights reserved. AVEVA shall not
be liable for any breach or infringement of a third party's intellectual property rights where such breach results from
a user's modification of the AVEVA software or associated documentation.
AVEVA Solutions Limited, High Cross, Madingley Road, Cambridge, CB3 0HB, United Kingdom
Trademark
AVEVA and Tribon are registered trademarks of AVEVA Solutions Limited or its subsidiaries. Unauthorised use of
the AVEVA or Tribon trademarks is strictly forbidden.
AVEVA product/software names are trademarks or registered trademarks of AVEVA Solutions Limited or its
subsidiaries, registered in the UK, Europe and other countries (worldwide).
The copyright, trademark rights, or other intellectual property rights in any other product or software, its name or
logo belongs to its respective owner.
OpenSteel Configuration Guide
Revision Sheet
Contents Page
Configuration Guide
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:1
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:1
Installation on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:1
Hardware and Operating System Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 3:1
Disk Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:1
Read from the DVD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:1
AVEVA Licensing System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:2
How to Run OpenSteel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:3
1 Introduction
AVEVA OpenSteel is the interface for PDMS which allows the user to import and export files
to and from the DESIGN module using the SDNF (the Structural steel Detailing Neutral File)
format. The SDNF format was originally defined by the Intergraph FrameWorks user
community for the transfer of steel data. The format is in the public domain and is therefore
available to be considered as a suitable means of transferring data between 3D steel
detailing packages and PDMS.
The OpenSteel interface uses a large proportion of the information transferable in SDNF
format. Refer to the OpenSteel User Guide describing SDNF, its format and contents.
This version of OpenSteel is compatible with PDMS (Series 12) on the Windows operating
system.
Glossary is a Glossary
Installation on Windows tells the user how to install the product on the workstation.
Internal Mapping Files describes how to set up the internal mapping files which
control the location of data to be transferred between
different systems.
External Mapping Files describes how to set up the external mapping files which
control how and what data is transferred between different
systems.
Start OpenSteel describes the checks that are made when the user starts up
the OpenSteel interface, and how to correct some problems
which may be encountered.
Examples of Typical lists the scripts supplied with the products which the user
Environment Scripts will need to edit to customise the OpenSteel interface and
use them with their own projects.
2 Glossary
SDNF (Structural steel Defined by the Intergraph FrameWorks user community for
Detailing Neutral File the transfer of steel data. It is in the public domain and is
Format) therefore available to be considered as a suitable means of
transferring data between 3D steel detailing packages and
DESIGN.
Source Package The external package from which an imported SDNF file is
coming.
Target Package The external package for which an exported SDNF file is
destined.
UDA (User Defined An attribute in DESIGN which the user can define and
Attribute) attach to specific elements. This interface requires a certain
set of UDAs for storing SDNF-specific data.
3 Installation on Windows
This section tells the user how to install OpenSteel on a Windows workstation and what the
user then needs to do in order to be able to run the program.
The software is supplied on DVD. Read the label on the supplied medium, and its
documentation, for any updated installation instructions.
It is assumed that the user is familiar with the concepts of directory and file hierarchies for
storing data on disks and with the most commonly used Windows operating system
terminology and commands.
Note: The definition of the hardware and operating system requirements for the third party
software with which this interface is to work is outside the scope of this document.
Note: During the installation sequence, follow the on-screen instructions as they appear.
It is recommended that the user uses the default settings for folder paths etc.
Note: The default installation disk is, in some circumstances, the largest disk, and this is
not always appropriate. This can be checked and if necessary changed by clicking
the Advanced button on the installer.
The manuals for OpenSteel and AVEVA Licensing System (ALS) may be read with the
Adobe Acrobat file reader.
The C:\AVEVA\Plant\Design directory will now contain a new sub-directory called
OpenSteel[ver] where [ver] is the installed version of OpenSteel.
The OpenSteel[ver] directory will contain the following sub-directories::
test A sub-directory which contains test files and project and results from the
test Export and Import. This may be deleted when you are satisfied that
the product has been installed correctly. However, it is helpful to
maintain a test area.
All the necessary OpenSteel directories have been created and the software installed.
Note: If the installer detects an existing OpenSteel installation, it will display a set of options
for modifying/repairing/removing these existing files in place of the standard
installation options. Other versions of OpenSteel need not be removed before
installing this version.
4 OpenSteel Environment
Like PDMS, OpenSteel uses environment variables to refer to all directory paths. This
allows the user to locate these directories anywhere on the file system. The product is
supplied with a file OpenSteel_env.bat in the executables directory, which sets default
values for the environment variables so that they point to the directory structure as installed.
It also sets the PATH variable to include the PDMSEXE directory.
The user may need to modify this file to reflect the directory structure of their own
installation. The following is a list of the variables the user may need to reset, with a brief
description of each one.
PMLLIB The search path for PML macros. If this is already set, add
the pathname to the directory containing the OpenSteel
application-ware macros. For example: %OPENSTEELUI%
%PMLLIB%.
xxxDFLTS The location of the project default mapping files, where xxx
is the project code.
SDNFMAPS This is used in the internal mapping files for the location of
the mapping files. It is set to a single directory. It is not
essential for OpenSteel.
The user does not have to use all three defaults variables, and they can use any others
which have defined as well.
The user should take care in using environment variables in internal mapping files, as a
recursive scan is not performed at this level. In this case the variable must point to only one
directory.
After the user has installed OpenSteel and set the appropriate environment variables, some
upgrade macros must be run on the project which:
• Update catalogues to include the Pline representation of the SDNF Cardinal Points.
• Install the UDAs which OpenSteel requires.
Note: the user will have to perform these actions on the supplied project. This is in order to
familiarise themselves with the process of upgrading a project for OpenSteel.
Note: This upgrade process works only for the AVEVA Solutions Ltd supplied catalogues.
The user may upgrade the catalogues by performing the following actions:
1. Enter PDMS and enter PARAGON with write access to all relevant catalogue
databases.
2. In a command window in PARAGON, run the upgrade macro by the following
command:
3. call !!SDNFCataUpgrade( )
4. The macro suite will check to see if this upgrade has already been executed and create
or modify the original set of Cardinal Points with an updated set.
5. Exit from PARAGON, saving the changes by returning to MONITOR.
There are 15 Cardinal Points defined in the SDNF standard. The OpenSteel interface uses
only 14 of them: the Shear Centre (Cardinal Point 15) is not a practical reference point to
use in these circumstances. Of the remaining Cardinal Points, OpenSteel tries to use those
between 1 and 10, because other systems prefer to use these, rather than the higher points.
If the user has not used Plines representing Cardinal Points to place Linear Members in
PDMS, during the Export or Import processes an attempt is made to map existing Plines
onto Cardinal Points. This mapping is performed using information stored in a configuration
file, sdnfloadcpdata.pmlfnc in the pml/functions directory. This basic Pline mapping is as
follows:
RBOS SNFA 1
BOS SNFB 2
SS SNFB 2
LBOS SNFC 3
RIGH SNFD 4
NARO SNFD 4
AA SNFD 4
MM SNFF 6
NALO SNFF 6
LEFT SNFF 6
RTOS SNFG 7
GG SNFH 8
TOS SNFH 8
LTOS SNFI 9
NA SNFJ 10
Angles
TOAX SNFA 1
TOAY SNFA 1
RTTA SNFC 3
LBOA SNFG 7
NA SNFJ 10
NAT SNFK 11
NAL SNFL 12
Channels
LTOC SNFA 1
RTOC SNFC 3
FOC SNFD 4
ROC SNFF 6
LBOC SNFG 7
RBOC SNFI 9
NA SNFJ 10
TOC SNFK 11
BOC SNFN 14
For further explanation of the reasons why the mapping may seem inconsistent, see the
section describing the assumed default profile orientations in the SDNF file and Cardinal
Point locations in the OpenSteel User Guide, and the Structural Design User Guide. In
particular we draw the user’s attention to the different handedness of the coordinate
systems as illustrated below.
The main differences arise from the mapping of the profile orientations in the PDMS
Catalogue onto the agreed SDNF format. The difference is most apparent in channel and
angle profiles. The diagram below illustrates the mappings of the Plines to Cardinal Points.
Note: The different Y directions to match the default angle orientations in each system.
Y
(PDMS)
CP 1 CP 11 CP 2 CP 3
Plines Plines Pline Plines
SNFA SNFK SNFB SNFC
TOAX NAT RTTA
TOAY
CP 12 CP 13
Plines Pline
SNFL CP 10 SNFM
NAL Plines
SNFJ
NA
CP 4 X
Pline (PDMS)
SNFD
X
CP 5 CP 6 (SDNF)
Pline Pline
Z SNFE SNFF
(PDMS)
Z CP 9
(SDNF) Pline
+
SNFI
CP 7 CP 14 CP 8
Plines Pline Pline
SNFG SNFN SNFH
LBOA
Y
(SDNF)
Diagram illustrating mapping of Cardinal Points to Plines
for Angle profile
If the user wishes to create profiles, the user must provide a Pline set similar to the ones
provided here to map onto the Cardinal Point Pline set. If they are named differently, there
must be a mapping to SDNF Cardinal Points as shown above. This is performed in the file
sdnfloadcpdata.pmlfnc in the pml/functions directory. Further, the user may have to manage
the orientation of the profile with regard to the SDNF intermediate form by using the Profile
Orientation mapping file (External Mapping Files).
A sample extract of the Pline mapping in the file sdnfloadcpdata.pmlfnc is given here.
-- Cardinal point Pkeys
!!SDNFCPPkeys.delete( )
handle( 2,751 )
-- Variable does not exist
endhandle
!!SDNFCPPkeys = ARRAY( )
!!SDNFCPPkeys[ 1 ] = |SNFA|
!!SDNFCPPkeys[ 2 ] = |SNFB|
!!SDNFCPPkeys[ 3 ] = |SNFC|
-- Angles
!!SDNFCPBMTOAX = |SNFA|
!!SDNFCPBMTOAY = |SNFA|
!!SDNFCPBMRTTA = |SNFC|
!!SDNFCPBMLBOA = |SNFG|
In the above example, the Pline, whose Pkey is TOAX, is mapped to the Pline whose Pkey
is SNFA and which is equivalent to the Cardinal Point number 1; RTTA is equivalent to
SNFC (Cardinal Point 3). The user must not alter in any way the array which maps
Pline names to Cardinal Point Pkey values, i.e. the array !!SDNFCPPkeys.
Thus, if the user has a new Pline, whose Pkey is RTOP, which is to be equivalent to
Cardinal Point 3, the user must insert a line similar to the following in the mapping list:
!!SDNFCPBMRTOP = |SNFC|
i.e. the format is…
!!SDNFCPBM<Pline PKEY> = |SNF[A-N]|
the user will then be able to use the RTOP Pline for their own positioning functions, but the
interface will know that it is equivalent to the SNFC Pline (i.e. Cardinal Point 3). Thus,
importing new items positioned using Cardinal Point 3 will appear in the PDMS model to
have been positioned using the RTOP Pline.
Pline mapping on Import is subject to the constraint that the map will take the first equivalent
it finds. In some circumstances the Pline TOAY (Cardinal Point 1) may be Imported as Pline
TOAX (also Cardinal Point 1) because the TOAX mapping is the first suitable one the
system finds. There is no way that the interface can determine which Pline the system
originally used.
Important: The naming conventions and database structure for the Pline sets should be
similar to those used in the AVEVA supplied Catalogues.
This section gives details on how the user can update the steel catalogues to include the
Plines necessary for the OpenSteel interface.
The macro file, sdnfusercataupgr.pmlfnc in the pml/upgrade directory provides the basis
on which the user may build their own mechanism for updating the catalogues automatically.
We have indicated where the user may have to modify this file with lines prefixed by:
>>>> User…
The macro must be run for each catalogue (CATA element) the user wishes to update. The
user may have to modify it in a different way for each catalogue. (Details about how the file
should be modified are given in following sections.)
The user can write a macro which will call all the modified files in turn and so upgrade all
their catalogues at once. The macro takes one argument which is the DBREF (the database
reference number) of the catalogue to be updated.
To update individual catalogues, run the upgrade macro as follows:
1. Start up PDMS and enter PARAGON with write access to all the relevant catalogue
databases.
2. Make the catalogue (CATA) the user wants to update the current element and give the
command:
call !!SDNFUserCataUpgr( !!CE )
3. Repeat for as many catalogues as required.
4. Save your work and exit from PARAGON by returning to MONITOR.
If the user has other additional shapes, or have parameterised them in a different way from
the supplied PDMS catalogues, the user will have to write their own macro for their own
shape based on the most suitable one provided. Please take note of the catalogue profile
orientation with regard to the SDNF format. Refer to the OpenSteel User Guide for more
details.
------------------------------------------------------------------------
-- Define function
define function !!SDNFUpgradeL( ) is REAL
-- Initialisation
!error = !!SDNFCPErrOK
!origin = ( ref )
-- Build map of existing PLINes
!plineMap = ARRAY()
var !coll collect all PLIN with (substring((PKEY ),1,3) eq |SNF|)for CE
if( not !coll.empty( ) )then
-- Build a map indexed on PKEY - don't delete them
do !i values !coll
$!i
!pkey = PKEY
var !pkeyString hash( |$!pkey| )
!index = !pkeyString.real( )
!plineMap[ !index ] = !i.dbref( )
enddo
endif
-- Create all new SDNF PLINes necessary
!pkeysHashed = ARRAY( )
do !i to !!SDNFCPPkeys.size( )
!pkey = !!SDNFCPPkeys[ $!i ]
var !pkeyString hash( |$!pkey| )
!index = !pkeyString.real( )
!pkeysHashed[ $!i ] = !index
-- Try going to PLINe called SNF[A-N]
$!plineMap[ $!index ]
handle( 2,109 )( 2,752 )
-- Failed - create it
NEW PLIN $!!SDNFCPData
PKEY $!pkey
!ref = ( ref )
!plineMap[ !index ] = !ref
endhandle
enddo
-- Set Pline dimensions
!YOff = |( ATTRIB CPARA[ 4 ] )|
!nYOff = |( ATTRIB CPARA[ 4 ] - ATTRIB CPARA[ 1 ] )|
!YCOff = |( ATTRIB CPARA[ 4 ] - ( ATTRIB CPARA[ 1 ] / 2.0 ) )|
!XOff = |( ATTRIB CPARA[ 2 ] - ATTRIB CPARA[ 5 ] )|
!XCOff = |( ( ATTRIB CPARA[ 2 ] / 2.0 ) - ATTRIB CPARA[ 5 ] )|
!nXOff = |( -1.0 * ATTRIB CPARA[ 5 ] )|
-- All requisite PLINes exist now
The macro first builds a list of any SDNF Plines that already exist. Any SDNF Plines that are
not available and are needed by the OpenSteel interface as listed in the !!SDNFCPData
array, are then created. This ensures we use the latest configuration.
We then need to define the SDNF Cardinal Point Pline location parameters related to the
method of catalogue parameterisation. These are Xoff, YOff, nYOff and nXOff. We also
need to work out the location of the geometric centre relative to the method of profile
definition. These location parameters are XCOff and YCOff. The user will see above that the
definition is in terms of a text string which describes a formula. Later on in the macro, this
text string is inserted into the command line. This use of PML allows the user to insert
formulae into the Pline definition, rather than the immediately evaluated formula.
Using these SDNF Pline location parameters, all the Cardinal Point Plines required for the
OpenSteel interface can be located. Refer to the OpenSteel User Guide regarding these
Cardinal Points.
If the user is extending or modifying OpenSteel, all the user should need to do is to modify
the part of the macro which calculates the location parameters. the user should, however,
pay close attention to the default profile orientations within SDNF.
The structure of the upgrade process allows the user to run the macro during the project as
well as at project initiation. Any database relationships that refer to the old Plines will be
maintained, e.g. dimensions.
This means that the Pline set (PTSS) named /USER-PTSS-I is to be modified using the
PML macro represented by the variable !Ishape. Further up, the user can see that the
!IShape variable is associated with the macro !!SDNFUpgradeI( ).
Above are the three diagrams that show the Plines and Cardinal points that are to be
considered in DESIGN and Frameworks for the case of an unequal angle. The left hand
diagram shows the normal Plines associated with the angle profile in its default orientation;
the middle diagram shows the Cardinal point positions in Frameworks for the angle, also in
its default orientation; the right hand diagram shows the Pline equivalents to the Cardinal
Points.
Note: The coordinate system in PDMS is right handed, whereas in Frameworks it is left
handed. The Cardinal Point : Pline equivalencing by superposition is illustrated
below. Using this kind of diagram the user will be able to determine the mappings
between Plines and Cardinal Points.
If the new profile is not one of the existing types, the user may need to assign a new profile
integer type code to it for use in the profile mapping file.
Also, if the new profiles are for a new country standard, the user may need to assign a new
country code to this. This three letter abbreviation is stored in the internal steel standards
file. This TLA is also used in the profile mapping file.
More UDAs are required in this version, so you will need to upgrade your current projects if
you are to use this later version of OpenSteel. The macro has been configured to keep
existing UDA definitions so that you will not lose data.
OpenSteel will check that the user has read/write access to their specific SITEs, since the
user and the interface may need to edit certain attributes. Refer to the OpenSteel User
Guide for more information.
The SITE for deleted elements, named in a similar manner to the Configuration object and
described in more detail in the User Guide, will store the 'deleted' elements in STRUs
according to the Import revision, so that the user can quickly isolate which items were
deleted at which time.
The user will note that the SITE names contain the current MDB and the current user name.
This is to facilitate multi-user working, and multiple accesses to the database. There may be
several of these, depending on which MDB and/or user has access to the particular
database. During the Import and Export processes, all these elements are inspected to
determine the latest transfer information.
Therefore, the supplied product will be available automatically in the DESIGN General and
Steelwork application-ware systems.
If the user wants to integrate OpenSteel into other application-ware toolbars, all the user
needs to do is to find the suffix applicable to the toolbar with which the user wants to
integrate OpenSteel and copy either of the DES-UTILS-xxx files to have the new suffix.
OpenSteel will then become available in that application-ware package.
For example, to integrate OpenSteel into the Piping Application, the user needs to copy
DES-UTILS-GEN to a file called DES-UTILS-PIPE. OpenSteel then becomes available
under the Utilities > Piping menu option.
There are two PML functions in the pml/functions directory which the user can run from
LEXICON and PARAGON to perform the first two actions. They are run in a command
window by using the following syntax:
The user can then, if they want, remove all the /SDNF-CONFIG-xxx elements from every
Design database, as these will no longer be necessary.
It is then up to the user whether the user delete the SITEs containing the ‘deleted’ elements.
Finally, the user need to ‘disconnect’ OpenSteel from the DESIGN application ware. This
involves deleting or renaming the ‘DES’ files in the pml directory.
6 Customise OpenSteel
This chapter describes the PML variables which the user can set to customise OpenSteel.
They are set in the file called sdnfuserdata.pmlfnc found in the pml/functions directory of
the interface.
If the user customises the OpenSteel forms, the user must reload the DESIGN user
interface from macros in order to rebuild it. If the user changes variables in the user data
area, the user can use the Re-initialise option on the main Import or Export forms. Refer to
the OpenSteel User Guide for more details.
Alternatively, the user may reload the OpenSteel system variables and rebuild the forms
using the following command, after the user have saved the sdnfuserdata.pmlfnc file:
call !!SDNFImpExp( )
However, if the user finds that the user interface forms are damaged, reload the DESIGN UI
from macros. A typical message indicating this condition might be:
Object does not have a member .targetlist
The user must also load the DESIGN UI from macros if the user make any changes to the
internal mapping files
!!SDNFExtProgAbbr.append( |STE| )
!!SDNFExtProgAbbr.append( |STR| )
!!SDNFExtProgAbbr.append( |XST| )
!!SDNFExtProgAbbr.append( |PDM| )
-- ANY to be the last in the list
!!SDNFExtProgAbbr.append( |ANY| )
This list is picked up automatically by the Import and Export forms. Thus, if the user wants to
extend or modify the list of Target Packages the user needs only to change it here, and not
in the form definition files. The user will also have to generate the other internal and external
mapping files required by the new system.
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.
Note: It is for the user to handle all internal errors within the macros.
Note: It is for the user to handle all internal errors within the macro.
Note: The supplied files are based on the Catalogue Component names.
!!sdnfSCTNtoGENSEC = false
If the user is importing to update and existing model, the database type of elements is not
changed, but all new elements will be replaced or not as required.
There is a third level of customisation available that is accessible by a form. This form has
access to versions of all the variables in the sdnfuserdata.pmlfnc function, but it does not
modify that function at all. So, at this point, the user is working with a local set of
configuration data.
The configuration form is accessible from either the main Import or Export form using the
Control > Configure... menu item below.
The System Configuration Form has 5 tab pages for 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 OpenSteel.xml in the PDMSUSER area. If present,
this file is accessed when the form, and indeed the whole OpenSteel 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 form 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 form is shown for you to choose where to locate the new file.
To restore the main default settings at form initialisation, just delete the OpenSteel.xml file.
The Reset button resets the values using the normal form initialisation process with the
current variables and any saved OpenSteel.xml file.
The Re-initialise option goes right back to the source variables in the system and user data
and the default OpenSteel.xml files.
The OK button 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.
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 OpenSteel Import and Export forms. The user should then
resave the binary UI.
Internal mapping files are loaded on start-up of the OpenSteel 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 files must have a suffix ‘.map’ and be stored in a directory under the
%SDNFINTMAPS% environment variable. The supplied interface stores example files in a
directory pml/OSDE.
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 PDMS format; for example:
%ENVVAR%\…
These environment variables cannot be search paths: they must translate to a reference to
a single directory.
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 The internal files recognise an external package, but there
defined for selection are no mapping table files associated with it.
The project-specific Profile mapping files for the TST project may be similar to:
TSTPRF*TSTPRF
STRUCAD*C:\AVEVA\Plant\OpenSteel[ver]\maps\StruCad\StruCad.map
XSTEEL*C:\AVEVA\Plant\OpenSteel[ver]\maps\XSteel\XSteel.map
STEELCAD*C:\AVEVA\Plant\OpenSteel[ver]\maps\SteelCad\SteelCad.m
ap
PDMS*C:\AVEVA\Plant\OpenSteel[ver]\maps\PDMS\PDMS.map
and a companywide Unicode test string mapping table may look like:
ANYUNI*ANYUNI
STRUCAD*C:\AVEVA\Plant\OpenSteel[ver]\maps\StruCad\StruCadUni.m
ap
XSTEEL*C:\AVEVA\Plant\OpenSteel[ver]\maps\XSteel\XSteelUni.map
STEELCAD*C:\AVEVA\Plant\OpenSteel[ver]\maps\SteelCad\SteelCadUn
i.map
PDMS*C:\AVEVA\Plant\OpenSteel[ver]\maps\PDMS\PDMSUni.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*%SDNFMAPS%\StruCad\StruCadMat.map
XSTEEL*%SDNFMAPS%\XSteel\XSteelMat.map
STEELCAD*%SDNFMAPS%\SteelCad\SteelCadMat.map
PDMS*%SDNFMAPS%\PDMS\PDMSMat.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
PDMS*%SDNFMAIN%\maps\PDMS\PDMSOri.map
For details of the format of the external mapping files, consult the relevant section in this
guide.
Environment variable ‘$nnnn' not understood. - The interface cannot determine the meaning
of %nnnn% in the mapping 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.
ANYANYCON*ANYANYCON
*Default Connection
BP*macro BasePlate
TP*TP
etcº
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
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.
No Connection mapping System cannot find a suitable table for the nnnn target and
table for nnnn for mmmm project.
project mmmm
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:
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
While setting up the Export or Import variables, the external mapping files are tested to see
if they are valid. At the top of each file is a check line indicating the external package to
which the file is related. The check line must be of the form:
PDMS TargetPackage
For example:
PDMS XSteel
The target package name must be as it appears in the data list, !!SDNFExtProgList (see
External Packages). This list is picked up automatically by the Export and Import forms.
Note: Tab characters are not permitted in the mapping files, as they interfere with the field
separation.
Comments may be included in the mapping files. They are indicated by a hash (#)
character as the first non-blank character on the line.
Suitable Mapping Table File specified in the mapping table is not found.
File not found
Not a suitable Mapping The header may not be of the correct format. The header
Table File - Is it empty? does not match the target package.
See External Mapping File Separator for information on how the user can specify which
separator which the interface will use to discriminate between fields.
Important: It is assumed that the package importing the data will perform the mapping to
local names. Any system exporting data will export its own local names without
performing any translation process whatsoever. This interface, however, checks
that there is a valid mapping for a Profile before it is exported, even though the
local PDMS profile name is still exported. This can also be a cause for
misunderstanding if the SDNF output file is inspected, and the user still sees
PDMS profile names, and not the names translated for the target package.
Field Description
1 PDMS catalogue profile name (without leading / )
2 External catalogue profile name
Field Description
3 Steel standard. See below.
4 Profile type. See below.
The catalogue names for the external package must be ascertained by the user and
matched correctly with the equivalent PDMS name.
Country Code
America AME
Britain BRI
Canada CAN
Euronorm EUR
Germany GER
Japan JAP
If the user wants to include profiles or joints from another standard or country, the user must
add a new and unique three-character identifier.
Similarly, angles (L shapes) are further classified if they are to be placed back to back by
either the long or short leg to form a double-angle profile. For example:
We have assumed that double angles may have a gap (i.e. 0 or more) corresponding to type
10 below, but to differentiate between short-leg and long-leg double angles we have used
type 10 to identify the long and type 11 the short leg back-to-back double angles. There are
no genuine type 11 profiles in the supplied data set.
The profile type codes are as follows:
Note:
1. Types 10 and 11 are often not available in external 3D steel detailing packages as a
single Catalogue entry. In those cases, they must therefore be modelled as two single
sections.
2. If Bent Plates are to be treated as angles with regard to mirroring etc., they must be
classified as angles (type 9).
Note: The identification line at the top of the file which indicates the Target Package.
PDMS XSTEEL
HE280A HEA280 EUR 20
HE280B HEB280 EUR 21
HE300A HEA300 EUR 20
HE300B HEB300 EUR 21
HE320A HEA320 EUR 20
HE360B HEB360 EUR 21
L35x5 L35*5 EUR 9
L40x20x3 L40*20*3 EUR 9
L40x5 L40*5 EUR 9
L45x30x3 L45*30*3 EUR 9
L45x30x4 L45*30*4 EUR 9
L45x30x5 L45*30*5 EUR 9
L45x4 L45*4 EUR 9
OD355.6x12.2 PD355.6*12.2 EUR 13
OD355.6x8 PD355.6*8 EUR 13
OD406.4x12.5 PD406.4*12.5 EUR 13
OD42.4x3.2 PD42.4*3.2 EUR 13
OD42.4x4 PD42.4*4 EUR 13
OD457x10 PD457*10 EUR 13
Profile is not in The profile is in the Profile Mapping File but is not in any one
the standard of the set of standards.
Profile is not the default The profile is in the Profile Mapping File and is in one of the
set of standards, but not the default standard.
Important: It is assumed that the package importing the data will perform the mapping to
local names. Any system exporting data will export its own local names without
performing any translation process whatsoever. This interface, however, checks
that there is a valid mapping for a Material before it is exported, even though the
local PDMS material text is still exported. This can also be a cause for
misunderstanding if the SDNF output file is inspected, and the user still sees
PDMS material texts, and not the text translated for the target package.
When the OpenSteel interface is started, the Properties database is searched for SOLI
elements which may define materials used to fabricate elements in the Design. An internal
list is then built for rapid reference.
Materials are usually associated with PDMS elements using the Material Reference
attribute, MATR, which points to a SOLI element in the Properties database. However, the
user may want to use the local :SDNFMGRADE attribute to specify the material. Either of
these should be set for the interface to be able to export elements successfully.
If the above system is still not specific enough, there is a mechanism by which the user can
define from where the material information is to be derived. See the next section for details.
When an element is exported, its material is determined by inspecting the :SDNFMGRADE
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 :SDNFMGRADE attribute on the SCTN or PANE element. The text is then looked up in
the Material mapping file to check that there is a translation into the SDNF file replacement
text. The local material text is still exported.
When an element is to be imported, the SDNF file material description is looked up in the
material mapping file and translated into the PDMS equivalent text string. This is then
initially copied into the :SDNFMGRADE attribute of the element before any attempt is made
to rationalise the MATR. If a SOLI element with this material text is found, the interface will
set the MATR to point to the correct SOLI element.
As with the profile mapping file, the first line is an identifier which indicates the external
package or system with which the file is associated.
No match for material The material is not in the Material Mapping File.
Unrecognised Parse This should not occur. If it does then it indicates a system
State error. Although the error is non-fatal it should be reported. A
number representing the parse state will also be output.
!start = ( ref )
-- Set default material
!defaultMaterial = |St 37-2|
-- Some User specific PML to get the required info
!type = ( type )
if( !type eq |SCTN| )then
-- Material stored on Catalogue component
goto catr
handle any
-- Bad or null reference
!material = !defaultMaterial
golabel /Finished
endhandle
!material = ( :Material )
handle any
!material = !defaultMaterial
golabel /Finished
endhandle
if( !material eq |unset| or $
!material.unset( ) or $
!material.length( ) eq 0 )then
-- Use default material
!material = !defaultMaterial
endif
elseif( !type eq |PANE| )then
-- Try to return :SDNFMGRADE or default material
!material = ( :SDNFMGRADE )
if( !material eq |unset| or $
!material.unset( ) or $
!material.length( ) eq 0 )then
-- Use default material
!material = !defaultMaterial
endif
endif
-- Return string and exit
label /Finished
$!start
return !material
endfunction
The above example assumes that the material information for Sections resides on the
catalogue component in the UDA :MATERIAL. If, for any reason, a material cannot be
identified, a default value of 'St 37-2' is assigned.
The interface assumes, by default, that this file exists under the above name in a directory
below the %PMLLIB% search path, and that the starting point for database navigation is the
current DESIGN element under consideration, i.e. a Section or Panel. See the previous
sections for details of how the user can configure the system to use a material macro with a
name of the user’s choice.
Note: In writing the user’s own macro, the user must handle all errors encountered so that
the macro will always safely return a valid PML string, whatever it may be.
Also, that materials for Panels must also be determined using this macro.
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 the external
package.
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.
PDMS
CATALOGUE CATALOGUE
DEFINITION DEFINITION
Y Y
start start
X X
end end
Z Z
IS
EQUIVALENT
TO
Z
end
IS
EQUIVALENT
TO
start
MIRROR Y
Z Z end
end
start
start
ROTATE 180
ROTATE 180
Y Z
end
start X
DEFAULT
ORIENTATION
SDNF
Diagram illustrating the effect of the
Mirror and Rotation flags
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 SDNF 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
• A set of string substitutions to be used whenever a quoted-string is written to the SDNF
file.
• As potentially any character can be used in the string, first non-space character of
the line is used as a delimiter for that line
• 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 SDNF 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, you decide to output in UTF-8
characters, and thereby diverge from the literal interpretation of the SDNF 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 PDMS names. This is in addition to the usual profile and material
mapping files.
Below is an extract of a log file trying to use the Unicode description file to translate text
fields.
9 Start OpenSteel
This chapter describes the checks that OpenSteel makes when the user starts up the
interface, and how some of the problems which might be encountered are handled.
When the user starts the interface, certain checks are made to ensure that the SDNF
interface will be able to proceed. The system checks that:
• The catalogues include the Pline representation of the SDNF Cardinal Points.
• The UDAs which OpenSteel requires are available.
• There is a default object to store the Configuration information and it is available for
modification according to the Import and Export status.
• There are SOLI elements in the Properties database which may be used for material
text. The Description attribute is assumed to contain the material text for use in the
external Material mapping file and relating MATR and :SDNFMGRADE attributes.
• The version of PDMS is supported.
When the user tries to invoke the Import or Export forms without the necessary data loaded
the user will be presented with appropriate message forms. For example:
In the above case, if the user answers YES, the interface will automatically install the SITE
to store the configuration details without switching modules. The interface will not be able to
proceed if the user does not install the configuration details, and a Fatal Error is raised.
In the case of the OpenSteel Plines or UDAs, the user will be instructed to change modules
and to follow the further instructions given. If a command window is open instructions on
what to do are listed. Read the sections on upgrading a project for OpenSteel.
or
Important: If, at the end of the initialisation process, the interface still has no mapping files
to work with, the user will be informed with a fatal error message.
OpenSteel Plines not The OpenSteel interface won’t work without them. This is a
present in Catalogue. fatal error.
Must be installed first
UDAs for OpenSteel he OpenSteel interface must have the UDAs installed. This
Interface not present. is a fatal error.
Must be installed first
No Map Files of any The recursive search of the directory(ies) pointed to by the
kind found %PMLLIB% environment variable has failed to discover any
internal mapping files named *.map. This is a fatal error
and the interface cannot really proceed.
Unsupported version of The system cannot determine which version of PDMS the
AVEVA PDMS user is running.
This appendix lists typical scripts which the user can use as a basis for editing their own
versions, so that the user can invoke the OpenSteel interface. The file OpenSteel_env.bat
must be called in the user’s evars.bat file.
Three versions of this file are installed with the product:
• OpenSteel_env_116.bat is compatible with PDMS 11.6 series, and sets the TST project
variables to the 11.6 version of the project.
• OpenSteel_env.bat is compatible with PDMS 12 series, when installed to a path not
containing spaces (as is recommended), and sets the TST project variables to the 12
version of the project.
• OpenSteel_env_path_space.bat should be used only with PDMS 12 series, and only
when the install path contains spaces. This is not recommended.
echo off
echo *** INITIALISING AVEVA OpenSteel ENVIRONMENT ***
If the user wants to change the location of the interface material, the only variable to change
is %SDNFMAIN%. However, see the section describing the system architecture to
understand the significance of the environment variables related to the internal mapping
files.
Index
A customise . . . . . . . . . . . . . . . . . . . . . 6:1
how to run . . . . . . . . . . . . . . . . . . . . 3:3
AVEVA Licensing System . . . . . . . . . . . . 3:2 special sites . . . . . . . . . . . . . . . . . . 5:12
C P
Cardinal Point Plines . . . . . . . . . . . . . . . . 5:1 PML Applications
Colour Code . . . . . . . . . . . . . . . . . . . . . . 6:3 integration into . . . . . . . . . . . . . . . . 5:13
Connected Members . . . . . . . . . . . . . . . . 6:4
S
E
System Architecture . . . . . . . . . . . . . . . . 4:1
Environment
OpenSteel . . . . . . . . . . . . . . . . . . . . 4:1
Variable . . . . . . . . . . . . . . . . . . . . . . 7:3
T
Export Header . . . . . . . . . . . . . . . . . . . . . 6:4 Tolerance Settings . . . . . . . . . . . . . . . . . 6:3
G U
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 2:1 Uninstall
OpenSteel . . . . . . . . . . . . . . . . . . . 5:13
I Upgrade a Project . . . . . . . . . . . . . . . . . 5:1
User Defined Attributes
Installation installation of . . . . . . . . . . . . . . . . . 5:12
on Windows . . . . . . . . . . . . . . . . . . . 3:1
W
M
Waiting Time . . . . . . . . . . . . . . . . . . . . . 6:3
Mapping Files . . . . . . . . . . . . . . . . . . . . . 4:2
Material Flag
Ignore . . . . . . . . . . . . . . . . . . . . . . . . 6:4
O
OpenSteel