SupportModeler™ for PDS™ Admin
Guide
Copyright
Copyright
Copyright © 1998-2003 Intergraph Corporation. All Rights Reserved. Including software, file formats, and audiovisual displays; may be used pursuant to applicable software license agreement; contains confidential and proprietary information of Intergraph and/or third parties which is protected by copyright law, trade secret law, and international treaty, and may not be provided or otherwise made available without proper authorization.
Trademarks
SupportModeler and SupportManager are trademarks of Pelican Forge Software Corporation.
Intergraph, the Intergraph logo, SmartSketch, FrameWorks, SmartPlant, and INtools are registered trademarks and PDS is a trademark of Intergraph Corporation. Microsoft and Windows are registered
trademarks of Microsoft Corporation. ISOGEN is a registered trademark of Alias Limited. Other brands and product names are trademarks of their respective owners.
Warranties and Liabilities
All warranties given by Intergraph Corporation about equipment or software are set forth in your purchase contract, and nothing stated in, or implied by, this document or its contents shall be considered or deemed a modification or amendment of such warranties. Intergraph believes the information in this publication is accurate as of its publication date.
Restricted Rights Legend
Restricted Rights Legend
Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c) of the Contractor Rights in Technical Data clause at DFARS 252.227-7013, subparagraph (b) of the Rights in Computer Software or Computer Software Documentation clause at DFARS 252.227-7014, subparagraphs (b)(1) and (2) of the License clause at DFARS 252.227-7015, or subparagraphs (c) (1) and (2) of Commercial Computer Software---Restricted Rights at 48 CFR 52.227-19, as applicable.
Unpublished---rights reserved under the copyright laws of the United States.
Intergraph Corporation Huntsville, Alabama 35894-0001
Admin Guide Purpose
Admin Guide Purpose
This guide explains how to create and manage pipe support projects using SupportModeler, Version 7.2.3. This guide is intended for use with Intergraph PDS plant design projects.
Installing the Software
System Requirements
Make sure that your system has the following hardware and software before installing SupportModeler:
• Pentium III 500Mhz
• 128 MB memory minimum, 256 recommended • 50 MB hard disk space
• MS Windows NT 4.0 or higher, or Windows 2000 • MicroStation SE or J compatible with your version of PDS • Microsoft Access drivers installed
SupportModeler does not require PDS installed on the workstation. However, SupportModeler interfaces with Intergraph Plant Design System (PDS™) projects created with version 6.4.1 or higher.
Installing SupportModeler
Software Delivery Directory Structure
4. Contact Intergraph Corporation to obtain and install proper licensing for the software.
5. Test SupportModeler to make sure that the software is installed and that it can access the required licenses.
Software Delivery Directory Structure
During installation, the software is delivered to your machine’s
C:\Program Files\SupMod\directory with the sub-directories shown in the diagram below. The software delivery directory contains the software executables, documentation, a sample tutorial project, and delivered versions of all the project setup files and libraries.
C:\Program Files\SupMod\Docs - contains user, tutorial and administration guides
C:\Program Files\SupMod\Mdlapps - contains the executable software programs
C:\Program Files\SupMod\Mdlapps\config -configuration files that are used when starting SupportModeler
C:\Program Files\SupMod\Lib - the delivered libraries
C:\Program Files\SupMod\Seeds - delivered seed files and settings files C:\Program Files\SupMod\Tutorial_PDS - tutorial project - copy to your machine's \Temp directory before using.
Installing the Software
Upgrading a Production Project to Version 7.2.3
Version 7.2.3 of SupportModeler uses a significantly different data storage method than version 7.1. Version 7.1 used JSpace object models for attribute storage while more recent versions use a relational database. Because of this, we highly recommended completing any existing projects using your current version of SupportModeler.
For conversion of version 7.1 projects, please contact Pelican Forge for assistance.
Restoring Customizations to the SUPPORT definition
Version 7.2.3 of SupportModeler uses significantly different library definitions than version 7.1. Version 7.2.3 uses straightforward script files to define both vendor libraries as well as the SUPPORT definition as opposed to the older JSpace Libraries. The SUPPORT class has been replaced by a support item file --SUPPORT.ITM - found in the
...\lib\sm_core_user\ directory. This is the file that you should save away in an enterprise location and customize to suit your requirements. Presently, there is no automated function to upgrade an old
SM_core_user.lib. Changes made to the SUPPORT class of previous versions must be manually made to the SUPPORT.ITM file. Please see the SupportModeler Library Customization Guide for information on how to do this.
Restoring Customizations to the Vendor Databases
As recommended, any customized vendor databases (for example customized versions of SM_Anvil.mdb or SM_Utility.mdb) should have been stored in a secure location. Follow this procedure for each customized library to restore any customizations.
Retaining Customizations to the Vendor JSpace Libraries
6. Save the file and exit.
Retaining Customizations to the Vendor JSpace Libraries
Version 7.2.3 of SupportModeler uses significantly different library definitions than version 7.1. Version 7.2.3 uses straightforward script files to define vendor libraries. Presently, there is no automated function to upgrade old vendor libraries. Changes made by the user to the pre-Version 7.2.3 vendor libraries must be manually made to the new libraries. Please see section for information on how to do this.
Any custom library that Pelican Forge has created for customers can be upgraded to the new format by contacting Pelican Forge.
Preparing for Project Creation
Preparing for Project Creation
This section describes how to prepare for creating your first production SupportModeler project.
✍
This preparation and the associated company-wide changes are usually made while setting up the first production project. The process is usually iterative - make changes, copy them to the project, test them in the project, make required changes and copy them back to the master lib and seeds directories.✍
If you wish to have detailed on-site assistance with this process, Pelican Forge offers a QuickStart customization service to setup and configure your first project. Please contact Pelican Forge for prices and available scheduling.Create Server Directories for Master Libraries and Seeds
Most companies want to centralize their seed and border files, settings files, and libraries on a central server that is accessible to all client machines.
Following is the suggested setup of a master reference directory for SupportModeler seeds and libraries. Use whatever directory names make sense to you.
All SupportModeler projects would use the files from this location. This directory structure should be backed up regularly.
Make Company-Wide Changes to Project Setup Files ➤ To create a Master Seeds and Libs directory on your
server
1. On your server, create a top level directory to store the master seeds and libraries. For example, create a folder called \SupModMaster or \SuptRef.
2. Create the Seeds, CoreLibs, VendorLibs and MyLibs sub-directories. The names are your choice.
3. From the delivered software directory, C:\Program
Files\SupMod\Seeds\ copy all files into your new master \Seeds\ directory.
4. From the delivered software directory C:\Program Files\SupMod\Lib\, copy folders SM_CORE and SM_CORE_USER into your new CoreLibs directory.
5. From the delivered software directory C:\Program
Files\SupMod\Lib\, copy all remaining folders, including the \Bmp sub-directory and all of the files it contains, into your new
VendorLibs directory. This will take a few minutes as there are many large files in these directories.
6. If you have had custom libraries of your company support standards developed by Pelican Forge, or developed new libraries yourself, move or copy them into your new MyLibs directory.
Make Company-Wide Changes to Project Setup Files
Make company-wide changes to project setup files. Some settings will be used by all SupportModeler projects and would be done in the master libraries and seeds. Files such as model seeds, drawing seeds and borders, SM_DRW.DAT, SM_PDS.DAT, and Core Libraries often get company-wide changes.
After you create individual projects, you can then make project-specific changes to the project-specific files.
Preparing for Project Creation Model Seed Files
Model seed files define the working units of the SM project. Sample seed files are delivered with SM in the C:\Program Files\SupMod\Seeds\ directory, with the following working units:
W
The working units must match between SM and PDS.If your PDS project uses one of these standards, just specify the appropriate design file master units name during SM project setup If your PDS project uses different working units, you must edit the SM seed file using MicroStation and set it up to match your PDS project. For feet projects in PDS, make sure to edit the Seed_feet_PDS file. When a PDS project is created, this file is copied to the project's \Seeds directory and renamed to seed_feet.
W
Seed File Name Name(in SM Setup) Master Units Sub Units Sub/ Master UOR/ Sub Seed_inches Inches In tn 10 1000 Seed_feet (only used
with PlantSpace projects) Feet ' " 12 25400 Seed_meters Meters M mm 1000 80 Seed_millimeters Millimeters Mm mm 1 1000 Seed_feet_PDS
(Only used with PDS projects. Automati-cally copied and renamed to Seed_feet during project cre-ation)
Make Company-Wide Changes to Project Setup Files .For detailed information, refer to the section “Customizing the Fabrication Drawings” on page 53 of this guide.
Drawing Settings File SM_DRW.DAT
This simple ASCII file controls what annotation is written onto the drawings, and controls the symbology of graphics and annotation, sets project-specific configuration variables, and defines the list of available drawing seed files for the project. The file itself contains detailed comments explaining how to use it. A sample SM_DRW.DAT file is delivered with SM in the C:\Program Files\SupMod\Seeds\ directory. The various sections of the file are summarized as follows:
• SYMBOLOGY - defines the line weight, style, color and level to use for the support and reference graphics in the fabrication drawings. • TEXT_NODES - assigns specific project and drawing properties
from the supports to specific, user-defined text nodes in the drawing seed file. Allows the use of expressions as well as property names. • CONFIGURATION_VARIABLES - allows you to specify
project-specific configuration variables to control drawing behavior and format. The newly delivered SM_DRW.DAT file lists all of the available configuration variables along with extensive comments on how to use them.
For more information, refer to the section “Customizing the Fabrication Drawings” on page 53 of this guide and to the delivered example SM_DRW.DAT file.
PDS Correspondence File SM_PDS.DAT
This simple ASCII file controls what data is transferred between PDS and SupportModeler. The file itself contains detailed comments explaining how to use it. A sample SM_PDS.DAT file is delivered with SM in the C:\Program Files\SupMod\Seeds\ directory.
The various sections of the file are summarized as follows:
• PIPING_DATA - defines which attributes of the PDS pipe segment from pdtable_12 get transferred into the support when you connect to pipe.
• PIPING_DATA_WITH_UNITS - exactly the same but is only used for PDS pressures and temperatures.
• SUPPORT_DATA - defines which support properties get transferred into pdtable_80 during Update PDS.
• PROJECT_TABLES - primarily for case-sensitivity issues with SQL Server. Most people don't need to change this. You may need to add or remove the FORWARD_SLASH from the pdtable_113 entry to
Preparing for Project Creation
make to the paths for SupportModeler models match the format of other PDS models.
• COLUMN_NAMES - primarily for case-sensitivity issues with SQL Server.
• SYMBOLOGY - defines the symbology to use when SM creates PDS logical supports during Update PDS. This should match the symbology that PDS expects for logical supports.
• AREA_DEFAULTS and MODEL_DEFAULTS - define which default values should be set in pdtable_112 and pdtable_113 when SupportModeler creates areas and models in the PDS database. Most people don't need to change these.
• SUPPORT_OBJECTS and COMPONENTS_&_ASSEMBLIES -define which properties should be available during a Design Review session.
• PATH_CONVERSION - defines optional text substitutions to help SupportModeler find PDS models using the model paths from pdtable_113.
For details on the uses of SM_PDS.DAT file, refer to the section “Using SM_PDS.DAT to Configure the PDS Interface” on page 35 of this guide and to the delivered example SM_PDS.DAT file.
Core Libraries
Each project uses a specific set of core libraries named SM_CORE and SM_CORE_USER. The delivered libraries (represented as directories) are located in C:\Program Files\SupMod\Lib\. These libraries contain simple script files (***.itm) that can be edited with any text editor. The most important file for administrators is the SUPPORT.ITM file located in the SM_CORE_USER folder. It is a very important, very customizable definition that affects several aspects of SupportModeler. It
Make Company-Wide Changes to Vendor Libraries. what properties of the support get written into pdtable_80 during Update PDS.)
• As a Receiver for Connect to Pipe Properties (Remember the PIPING_DATA section of the SM_PDS.DAT file that controls what properties of pdtable_12 get written into the support during connect to pipe)
• To define the automatic format for the Support ID using the SUP_ID_FORMAT property.
Make Company-Wide Changes to Vendor Libraries.
If you plan to make changes to the delivered libraries, or get a custom library created for your company by Pelican Forge, you would generally do this before starting modeling in a project. It is a difficult manual process to implement library changes retroactively to already-modeled components.
For detailed information on library creation and customization, refer to the SupportModeler Library Customization Guide. For minor changes and customizations, we recommend that you take the Administration and Customization Training course. For creating new libraries or making extensive changes, we would very strongly recommend that you take the Component & Assembly Creation Training course.
Valid Library Installations
Libraries can exist anywhere on the disk or a network server. The requirements for installation are as follows:
• Every library must be contained within a folder named the same as the library.
• The database file must exist within this folder with the same root name.
• For vendor libraries, which contain specific components and assemblies to be used for modeling, there is a folder below the Library and database files called BMP. This contains all the image files associated with the library
• Each item file -- ***.ITM is a definition for a particular component or assembly.
Preparing for Project Creation
Delete Local Libraries from Client Machines more information on loading and unloading vendor libraries, refer to the SupportModeler User Guide for PDS.
Creating a SupportModeler Project
Creating a SupportModeler Project
Once the preparation for project creation is complete, perform the following operations for each project.
If you wish to have detailed, on-site assistance with this process, Pelican Forge offers a QuickStart customization service to setup and configure your first project. Please contact Pelican Forge for prices and available scheduling.
Create a Supports discipline in PDS
All of the pipe support areas and models that you will create in SupportModeler will be automatically written into the PDS project control database.
You must manually create a Supports discipline in PDS, but then SupportModeler will use this discipline when creating areas and models in pdtable_112 and pdtable_113.
➤ To create a support discipline
1. Using PDS, choose Project Administrator > Project Environment Manager > Create Discipline Data.
2. Create a new discipline for pipe supports.
All areas and models created in SM for this project will be automatically added to the PDS project control database using this discipline. You do not need to add areas or models to this discipline using PDS. For example, create a discipline named Supports.
Decide on project location are working on - one to the PDS design database (dd_*) and one to the PDS project control database (pd_*).
If you are using an Oracle database, we recommend using the Microsoft ODBC for Oracle drivers rather than the Oracle ODBC drivers, although either will work.
Each client machine will need these same two ODBC sources in order to open the SupportModeler project.
Decide on project location
Normally, your SupportModeler project would be located on a server where all client machines can have access to it.
Most companies create the SupportModeler project within the PDS project directory.
SupportModeler project within PDS project directory In this case, you would manually create the Supports directory and specify this Supports directory as the location when you use SupportModeler to create the PDS_PROJ1 pipe support project. SupportModeler would create the \Supports\PDS_PROJ1 directory and its contents.
Alternate Directory Structure for shorter path names If length limitations for pdtable_113 path names would be exceeded with the previous structure, the following shorter paths may be used. Name all SupportModeler projects Sup and create them directly within the PDS project directory. The drawback of this method is that all SupportModeler
Creating a SupportModeler Project
projects would be called Sup, rather than the project name, which can introduce some confusion.
Create the SupportModeler project
Create the SupportModeler project
➤ To create a SupportModeler project
1. If you will be creating an Oracle-based SupportModeler project, see “Creating an ORACLE SupportModeler™ Project Database” on page 27 for steps you should perform prior to creating the project.
2. Choose File>New Project from the SupportModeler menu bar to create a new SupportModeler project. If you already had a project open, close the project first.
The Create New Project dialog box is displayed.
3. Use the following table to help you fill in all of the appropriate project options, noting which values can be changed later and which cannot.
Creating a SupportModeler Project
Field or Button Project Option Description Change
Later?
Name The name of the SupportModeler project, up to 50 characters. No Location Also referred to as project_dir, this is the root directory for the project, where all
the SupportModeler files for this project will be stored. These files include mod-els, drawings, seed files and border files. The Browse button to the right of the field displays a file selection dialog box to help select the directory, whether on the local machine or a network drive.
This is the actual location of the project files. A project can be moved simply by using Windows commands to move the root directory of the project. The value of this field will be updated automatically the next time the project is opened. Example: Create a project with Name EXAMPLE_PROJ in Location \\machine_name\share_name
This step creates a directory called EXAMPLE_PROJ on the machine named "machine_name" in the shared directory called "share_name".
Note: Because the SupportModeler project files are different, you should not store them in the c:\Bentley\Workspace\Projects directory that MicroStation/J automatically sets up at installation.
Auto
Workstation/Server Name
The name of the node where this SupportModeler project will exist. PDS uses this name to locate the project. This should be the same server name that you browsed to when setting the Location for this project.
Yes
Project Directory on Server
The full path to this SupportModeler project as it would be displayed on the server machine. PDS uses this path to locate the pipe support dgn files. If you browse for the project location, this path will get partially set automatically. How-ever, if the location you select is on a remote server, as in most production projects, you would need to edit the Project Directory on Server field to use the actual path on the server (i.e. C:\path\share\ ), rather than the shared path name or UNC path name
This path should represent the same path that you browsed to when setting the
Location for the project, except this field contains the directory as it would be specified on the server, not from a remote client machine.
Create the SupportModeler project
Directory for Core Libraries
The path to the directory where the core libraries (folders sm_core and sm_core_user) are found. For production projects, you would select the \CoreLib\ directory from the Master Libs and Seeds directory you created on your company server. You can also use the delivered core libraries which are delivered with SupportModeler in C:\Program Files\SupMod\Lib\
If the selected directory does not contain folders SM_Core, the system will dis-play a warning that the path is not valid.
Yes
Source Directory for Seeds
When a new project is created, a set of seed files is copied from this directory to the Seeds directory of the new project. For production projects, you would select the \Seeds\ directory from Master Libs and Seeds directory you created on your company server.
No
Interface Mode The interface mode used to run this project. The available options will be deter-mined by which software licenses you have installed. Select PDS for use with PDS, or PlantSpace for use with PlantSpace. The Stand Alone option is also available and could be used if you are not using any PDS or PlantSpace 3D plant models.
No
Data Source Name, Design
The ODBC data source name corresponding to the PDS design database that you want to associate with this SupportModeler project. The data source name must already have been created.
No
Data Source Name, Project
The ODBC data source name corresponding to the PDS project database that you want to associate with this SupportModeler project. The data source name must already have been created.
Note: When a PDS project is created, a file named the same as the project with a *.pwd extension is created in the project directory. This file can hold the user-name and password associated with each of the two PDS data sources. You must edit this file manually to add the username and password, or see “Using
SMpass-word.exe” on page -24, to generate an encrypted password file.
No
SupMod ORACLE db If you wish for the SupportModeler Project database to reside in an ORACLE databse, check this box. Refer to the Section “Creating an ORACLE
SupportMod-eler™ Project Database” on page -27 for information on setting up your Oracle
database.
Project Units Area The values in this grouped area (for length, mass, force, moment, temperature and pressure) indicate the units that should be used to display data in the BOM description of the fabrication drawing. In addition, the Length units (Length (& Dgn MU’s)) indicate the MicroStation Master Units used in the model. The value chosen here will determine which seed file is used whenever a new model is cre-ated. The seed file will be project_dir\Seeds\seed_units.dgn where units is the value you chose for this field.
Note: The setting of the Length field should match your PDSproject setup. No
User Keyin Units Area The values in this grouped area (for length, mass, force, moment, temperature and pressure) indicate the units that should be used to enter data into any key-in prompt (not pull-down menus). The entered value is automatically converted and stored in the object model in the Object units.
Yes
Nominal Diameter The value of this parameter controls how the user enters nominal diameters (for Rods and Pipe sizes) and how they appear on the fabrication drawing. If it is imperial, inch sizes will be displayed to the user and will be shown on the fabrica-tion drawing. If it is metric, mm nominal units will be used.
No
Field or Button Project Option Description Change
Creating a SupportModeler Project
4. Click OK to accept the project options and create the new project.
✍
Clicking CANCEL exits without creating a project.A new SupportModeler project directory structure is created for the project, with the required subdirectories, seed files, project file and project database.
Project Directory Structure
SupportModeler supports the existence of multiple projects, each of which may be in different units and on different computers. A project can be broken down into any number of areas, each of which can contain any number of models, which in turn can contain any number of supports. When you create a new SupportModeler project, you specify a location for the project and SupportModeler creates a directory structure that will contain all of the project files.
A typical directory structure for a project named SupportModeler Project #1 containing Area1 and Area2 is shown as follows.
Upon creation, the project directory contains three files:
Windows NT and the Project Database SupMod Oracle DB during project creation, this database will not be included.
• sm_oracle.con. If you selected SupMod Oracle DB during project creation, this file defines the connection parameters for the Oracle-based SupportModeler project database.
• projname.pwd - can be edited to add a user name and password for the ODBC connection to the PDS project and design database. Examine this file for detailed directions, or see “Using
SMpassword.exe” on page -24 for information on how to generate an encrypted password file.
Upon creation, the project directory also includes a Seeds directory that contains the seed files and settings files for this project.
A subdirectory is also created for each modeling area that you create within the project. Each of these directories will, in turn, have two subdirectories named:
• \mod\ for support models (*.dgn and *.smj) • \drw\ for fabrication drawings
The naming convention for support fabrication drawings is as follows: model_supportID_revision.sht
Windows NT and the Project Database
By default, SupportModeler uses a project database (the database located in the project root directory and used to store all design information) in Access 2000 format. If you are using SupportModeler with Windows NT 4.0, you should convert the database from access 2000 format to Access 97 format. Performance will be significantly improved. To do this, you will need to open the project database in Access 2000 and save it as an Access 97 format. This will need to be done for each project created to work with Windows NT.
This is unnecessary if you are using Oracle for the SupportModeler project database by choosing SupMod Oracle DB during project creation.
Password Files
SupportModeler now has the capability of reading binary files that contain the username and password information for connection to the
Where Means
model The name of the model where the support is located supportID The identification of the support
Creating a SupportModeler Project
two types of databases that it connects to during a PDS session. The two password files are located in the root of the SupportModeler project folder and are named i) proj_name.pwd and ii) sm_oracle.con Proj_name.pwd
Proj_name.pwd contains the ODBC Data Source Name, username and password information for connecting to the PDS project and design database.
This file is created automatically when the project is created. You can either edit this file manually, or use SMpassword.exe.
✍
Ensure that the ODBC data source names exist for the project before continuing with the next step.➤ Manually editing the Proj_name.pwd file
If your PDS database is password protected, you will be prompted for both the dd and pd passwords. You can edit the *.pwd file in the new SupportModeler project directory to automatically fill in the passwords for you. Examine the file itself for instructions. This is an ascii file and must be readable by any designer using SupportModeler for this project. For security reasons, you may with to encrypt this file, using
SMPassword.exe. For details, see the next section. ➤ Using SMpassword.exe
1. SMpassword.exe is delivered with SupportModeler. It is located in the SupportModeler\mdlapps folder.
Oracle Connection File
✍
The file created must be named the same as the project and have a .pwd extension..3. Once the encrypted password file has been created, you can overwrite the .pwd file in your new or existing SupportModeler project folder.
Oracle Connection File
If you selected the SupMod Oracle DB check box during project creation, an sm_oracle.con file will be created in the project’s root directory. This file contains the information necessary to connect to the SupportModeler project database in Oracle.
Automatic Creation of Sm_oracle.con file The sm_oracle.con file is created automatically when a new SupportModeler project is created. The file contains connection
Creating a SupportModeler Project
information which you entered into the SupportModeler Project DB Info dialog box: during project creation.
➤ To recreate an sm_oracle.con file
If the oracle login information changes, you may need to regenerate the sm_oracle.con file.
1. Create a dummy SupportModeler project in a temp location.
2. Press OK in the Create New Project dialog and fill in the SupportModeler Project DB Info dialog.
✍
If a project already exists in the oracle database that you point to in the dialog, SupportModeler will tell you that project creation failed, but a new sm_oracle.con file will be created where you asked.3. Copy this new sm_oracle.con and overwrite the existing sm_oracle.con file of your real SupportModeler Project.
Creating an ORACLE SupportModeler™ Project Database
Creating an ORACLE SupportModeler™ Project Database
It is now possible to have the SupportModeler project database reside in an Oracle database. To accomplish this there are a couple of things the Oracle DataBase Administrator must do BEFORE creating the SupportModeler project. These items are described below.
✍
Note: There may be more than one way to create the following items. We describe only one of these.➤ To Create a New Tablespace in ORACLE for the SupportModeler Project
1. Use Oracle DBA Studio to create a new Tablespace in the oracle database of your choice.
2. Highlight the database of interest (PDS in this case) and click on the Create icon as shown in the figure below
Creating an ORACLE SupportModeler™ Project Database
3. Select Tablespace from the dialog that comes up and press the Create button.
4. Key in a new name for this Tablespace (you should use the same name as the SupportModeler project you intend to create later)
Creating an ORACLE SupportModeler™ Project Database
5. Increase the Size of the file from 5mb to at least 100 mb. This will ensure that there is sufficient storage space. Then click the Create button..
6. Once the Tablespace has been created, you can create a new user. Expand the Security item in the database and select the Users item then click on the Create icon.
Creating an ORACLE SupportModeler™ Project Database
7. From the dialog that appears, click on User then click the Create button
Creating an ORACLE SupportModeler™ Project Database
8. Complete the form by keying in a Name and Password. Usually, the name is the same as entered in step 3. The Password is usually the same as the Name.
9. Under the Tablespaces heading, change the Default from INDX to the project name (in this case, SM_MYPROJ) and Temporary to TEMP_SEGS.
10.Select the Role tab on the Create User Dialog Select RESOURCE form the list of Available Roles, then press the down arrow button to
Creating an ORACLE SupportModeler™ Project Database
grant that role to this new user. If the CONNECT role has not already been added, do so as well. Click on OK to create this user.
Creating an ORACLE SupportModeler™ Project Database
11.Start SupportModeler and from the File menu, select New Project.
Check this box to have SupportModeler create the project database in the Oracle database you just created. When you finish completing this form and press OK, you will be asked for additional information about the Oracle database
Creating an ORACLE SupportModeler™ Project Database :
1. Service name as shown in the Oracle DBA Studio.
2. TableSpace name from step 3. Uppercase.
Using SM_PDS.DAT to Configure the PDS Interface
Using SM_PDS.DAT to Configure the PDS Interface
To configure a SupportModeler project to work with a PDS project, you need to:
• Set up the PDS database to receive ODBC connections and create ODBC data source names on each client machine to read and write from the PDS database.
This has already been completed in the section “Creating a
SupportModeler Project” on page -16 because the ODBC must be setup and working before you can create the project.
• Edit the SM_PDS.DAT file for the project. This is the primary resource used to configure the data transfer and integration between the SupportModeler project and the PDS data, and is the primary focus of this section.
✍
ODBC provides the mechanism for transferring data between SupportModeler and PDS, while the SM_PDS.DAT file determines what data is transferred.✍
The delivered SM_PDS.DAT file is in C:\Program Files\SupMod\Seeds.✍
While working on your first production project, the process of setting up SM_PDS.DAT is usually iterative - make changes and test them in the project’s SM_PDS.DAT file, then copy them back to the master lib and seeds directories to use as a master for future projects. Each project’s SM_PDS.DAT file is often edited after the project has been created in order to meet project-specific requirements.Overview of the PDS Interface
Four Parts of the Interface
There are four main parts to the SupportModeler-PDS interface: • Model management - SupportModeler areas and models are
automatically entered in the PDS project control database for use by PDS designers and post-processing tools. SupportModeler can attach
Using SM_PDS.DAT to Configure the PDS Interface
PDS reference files based on discipline, area and model. Uses pdtable_111, pdtable_112, and pdtable_113.
• Connect to Pipe - transfer PDS segment data based on a graphical selection of a PDS pipe segment center line. Reads data from pdtable_12_xx.
• Update PDS - writes logical supports into the referenced PDS piping models. Uses pdtable_114 to determine system_unique_no and writes to pdtable_80_xx.
• Check with PDS - reports discrepancies between PDS and SupportModeler. Compares support locations and data from pdtable_12_xx and pdtable_80_xx.
Integrating with PDS Deliverables
The logical supports created in PDS piping files by SupportModeler and the detailed graphics in the SupportModeler design file are used in PDS to:
• Generate and annotate isometric and orthographic drawings • Create basic pipe support listings
• Perform clash detection
• Provide support locations for stress neutral file generation All of these post-processing tools are used in the normal manner.
Pipe Segment Attributes to Read from PDS
The PIPING_DATA and PIPING_DATA_WITH_UNITS sections control which PDS database attributes are transferred to which SM properties during the Connect to Pipe operation. You can use any attributes from pdtable_12 (segment data).
Using PDS Code Listed Attributes in SupportModeler
✍
SupportModeler is intended to be the main repository of detailed design information and only a minimal amount of data should be transferred to PDS table 80. SupportModeler Reports are better suited to the detailed reporting of pipe support material takeoff than data that is transferred to PDS table 80.In addition, hard-coded values can be written into a specific attribute in pdtable_80 by specifying a value in double quotation marks (“) in place of the Property Name. As delivered, this is used to write PSL into both the model_code_log and commodity_code attributes for each support. Refer to the SUPPORT definition in the SUPPORT.ITM for detailed
information.
One-line script expressions, to be evaluated on the support item, can also be used as the property name. If an expression requires more than one line, you can externalize the expression into a script item file and refer to it here with the syntax
EXECUTE <LIBRARY> <SCRIPT>
where <LIBRARY> is the name of a loaded library, often
SM_CORE_USER, and <SCRIPT> is the name of a script in that library. Refer to the EVAL_SAMPLE.ITM file in ..\SupMod\ Lib\
SM_Core_User\ for an example of a script file for use as an expression.
Using PDS Code Listed Attributes in SupportModeler
For SM to understand and use PDS code-listed attributes, the code lists must first be extracted to ASCII neutral files and the SM_PDS.DAT Correspondence File (SM_PDS.DAT) must be edited to point to these code-list files.
Use the PDS Standard Note Library Manager to extract the code-lists for those database attributes that SM will use. Make sure that they are stored in a location that is accessible from all client machines using the same path, and specify this path and file name in SM_PDS.DAT. For each row in SM_PDS.dat that uses a code-listed PDS attribute, the code-list path should be specified in the Full Path to Codelist column.
PDS Project Database Table Names
The PROJECT_TABLES section tells SupportModeler the exact names of several required PDS project control database tables. Used primarily for case-sensitivity issues with SQL Server, most people don't need to change this section.
You may need to add or remove the FORWARD_SLASH option from the pdtable_113 entry to get the paths for SupportModeler models to match the format of other PDS models. When you create the first
Using SM_PDS.DAT to Configure the PDS Interface
SupportModeler model in a new project, examine the PATH_NAME column pdtable_113 to see whether the SupportModeler model path has the same format as other PDS models.
PDS Database Column Names
The COLUMN_NAMES section tells SupportModeler the exact column names of several required attributes in both the project and design databases. Used primarily for case-sensitivity issues with SQL Server, most people don't need to change this section.
PDS logical support symbology
The SYMBOLOGY section defines the symbology to use when SM creates PDS logical supports during Update PDS. This must match the symbology that PDS expects for logical supports or PDS will not recognize them as supports.
➤ To determine and set the logical support symbology for PDS
1. In PDS, place a logical support into a piping model.
2. Use the PDS Analyze tool or the MicroStation Element Information tool to examine its level, color, and weight.
3. Enter the level, color and weight into the SYMBOLOGY section of the SM_PDS.DAT file that will be used on the project.
✍
If all of your PDS projects use the same logical support symbology, you could make this change to the SM_PDS.DAT file in the master seeds directory. Otherwise, wait until after you have created the project and then make this change to the SM_PDS.DAT file in the project’s \Seeds\Path to PDS Models
Path to PDS Models
In order for SupportModeler to find the PDS reference files, one of the following changes may be required:
• Additional shares may be required on the PDS file server. • A PATH_CONVERSION section may be needed in the
SM_PDS.dat correspondence file.
➤ To test if SupportModeler can find PDS models:
1. Open a model in your new SupportModeler project
2. Select File | Attach PDS Reference File to attach a valid piping model as a reference model.
3. If you get a warning saying that the file was not found, record the path that it tried to use to access the file.
4. Make changes to the shared directories on the server or add a PATH_CONVERSION section to SM_PDS.DAT based on the explanations outlined below.
5. To retest, close and open the SupportModeler project so that it re-reads the SM_PDS.DAT file and repeat this procedure.
Understanding How SupportModeler Locates PDS Reference Files
SupportModeler uses the model data in pdtable_113 of the PDS project control database to locate PDS reference files. To convert the
pdtable_113 data into a standard Windows UNC file path, SupportModeler normally strips any leading drive letter from the PATH_NAME, and then appends the resulting PATH_NAME to the NETWORK_ADDRESS.
For example, using the following pdtable_113 model data, SupportModeler looks for the reference model using the path:
\\PSERV112\proj\cal25\pds\models\piping\pipea1m3.dgn
Share Names
If your PDS file server does not have appropriate share names, the simplest solution is to share the appropriate directories.
Where Means
MODEL_FILE_SPEC pipea1m3.dgn
PATH_NAME e:\proj\cal25\pds\models\piping NETWORK_ADDRESS PSERV112
Using SM_PDS.DAT to Configure the PDS Interface
In the previous example, the PDS file server PSERV112 would need to have the \proj directory shared using the name proj.
If it not acceptable for your network operations to add this new share, you can also enter a path conversion in the SM_PDS.dat correspondence file.
Path Conversion in the SM_PDS.DAT File
To add a path conversion to the SM_PDS.dat file, create a new entry at the end of SM_PDS.dat using the PATH_CONVERSION keyword followed by pairs of substitution strings, as follows:
PATH_CONVERSION
…
For the previous example, suppose your PSERV112 already had the \piping directory shared out cal25p and you do not want to share the proj directory. With the following entry in SM_PDS.dat, SupportModeler will now look for the reference model using the path
\\PSERV112\cal25p\pipea1m3.dgn PATH_CONVERSION
txt1 , sub1 txt2 , sub2
Where Means
sub1 sub1 should be substituted for txt1 in PATH_NAME sub2 sub2 should be substituted for txt2 in PATH_NAME
Control of Interference Envelope File Generation requires more than one line, you can externalize the expression into a script item file and refer to it here with the syntax
EXECUTE <LIBRARY> <SCRIPT>
where <LIBRARY> is the name of a loaded library, often
SM_CORE_USER, and <SCRIPT> is the name of a script in that library. Refer to the EVAL_SAMPLE.ITM file in ..\SupMod\ Lib\
SM_Core_User\ for an example of a script file for use as an expression. Refer to the SupportModeler Library Customization Guide for more information.
Control of Interference Envelope File Generation
The CLASH_ENVELOPE_SETTINGS section determines what items and what properties of those items get written to the interference envelope file. The envelope file is used by PD_Clash to perform intelligent interference detection.
The COMPONENT_FILTER_EXPRESSION is a boolean test that is applied to each SupportModeler component. If the expression evaluates to TRUE on a component, that component will be included in the clash envelope for its support. If FALSE, it will not be included. This is generally used to eliminate items with no physical graphics (welds, notes, etc.) but can be extended to selectively include components.
SUPPORT_NAME_EXPRESSION and
SUPPORT_DESCRIPTION_EXPRESSION are evaluated on each support item to generate a name and description for the support in the clash envelope file.
Testing a new SupportModeler Project
Testing a new SupportModeler Project
Before doing any production work in a new SupportModeler project, we strongly recommend testing the project using the following procedures:
In SupportModeler:
1. Check the project directory structure to make sure that it has been created correctly. See “Project Directory Structure” on page -22
2. Open the project in SupportModeler
3. Create one test area and one test model. For detailed instructions, see “Setting Up Areas and Models” on page -44.
Make sure a directory is properly created in the project directory for the new area you created. Make sure that the new DGN model is properly created in the \mod\ directory of your new area and that a new set of database tables tSupports_xx, tItems_xx,
tConnectPoints_xx, and tProperties_xx are created in the project database.
4. Attach PDS Reference Files
Make sure that the lists of disciplines, areas and models are correct for the PDS project you are working on. If not, check the ODBC data source for the project database.
Make sure that SupportModeler can find the PDS reference files. If not, see the section “Path to PDS Models” on page 39.
5. Start New Support and connect to pipe segment.
Make sure that the pipe attributes are correctly brought into the support properties in the Active Support Parameters dialog. If not, see the section “Pipe Segment Attributes to Read from PDS” on page 36.
In the PDS database
In the PDS database
1. Check pdtable_112 for your new area entry. Are any AREA_DEFAULTS changes needed in SM_PDS.DAT?
2. Check pdtable_113 for your new model entry. Are any
MODEL_DEFAULTS changes needed in SM_PDS.DAT? Check the model path. Do you need to take out the FORWARD_SLASH from the PROJECT_TABLES section of SM_PDS.DAT?
3. Check pdtable_80_xx for the associated PDS piping model.
In PDS
1. Open the piping model that was associated with your support model.
2. Review the logical support that was created from SupportModeler. If the symbology is incorrect in SM_PDS.DAT, you will not be able to review it.
3. Attach the support model as a reference file using the standard PDS reference file tools. If the path in pdtable_113 has the wrong slashes (back vs. forward) it may not be able to attach the file. Also, if the Workstation/Server Name or Project Directory on Server are incorrect, PDS will not be able to find the files.
4. Create an ISO drawing for the supported line. The logical support created by SupportModeler should appear. Note that ISO annotation is controlled by pdtable_80 entries, ISOGEN options file settings, and PDS Isometric Drawing Labels and can be easily customized. The SM_PDS.DAT file controls what gets written to pdtable_80.
5. Generate and annotate a GA/Ortho drawing.
6. Create a Framework ASCII grid file for testing drawing generation in SupportModeler.
Setting Up Areas and Models
Setting Up Areas and Models
To help organize the pipe supports in large engineering projects, a SupportModeler project can be broken down into any number of areas. Each area can contain any number of models, which in turn can contain any number of supports. SupportModeler modeling areas are simply a high-level way of grouping models together and are analogous to folders on your PC’s hard drive.
Adding a New Area
✍
Each SupportModeler area is automatically added to the Design Area table in the PDS project control database (pdtable_112).➤ To add a new area
1. Start SupportModeler and open the Add/Open Model dialog box.
2. In the Add/Open Model dialog box, choose File>New Area, or click the Add New Area button.
Adding a New Model
6. Click OK.
Adding a New Model
Models in SupportModeler consist of matched sets of MicroStation design (DGN) files and model tables in the project database, which together act as an enhanced design file. The DGN files store the support graphics and the database tables store the rich data associated with each support item.
To add a new model
1. In the Add/Open Model dialog box, click an existing area so that it is highlighted in the project hierarchy.
2. Choose File>New Model, or click the Add New Model button. The Model Information dialog box is displayed.
3. At the Name field, type a name for the new model.
Model files are limited to the column width allowed in pdtable_113 of the PDS project control database.
✍
The model name cannot be changed after creation.4. Click OK.
✍
Please note that if you name your Support models the same as your Piping models, you must be sure to delete the models usingSupportModeler only. If you deleted Support models through PDS, any other files with the same names are also deleted.
PDS Site Identifier
Implementation of a new Site Identifier (Site_ID) attribute in PDS 7.2 to facilitate Data Exchange in Workshare projects
A new configuration variable called SUPMOD_PDS_SITE_ID has been added to SupportModeler. When set, SupportModeler will assign newly created models to the site identified by the configuration variable. The text that the configuration variable is set to must match exactly an existing PDS site identifier. An example of this configuration variable is in
Setting Up Areas and Models
mslocal.cfg delivered with this version of SupportModeler. You may wish to set the configuration variable in a project specific pcf file.
✍
This configuration variable is valid only with PDS Version 7.2 or later projects.Changing an Area or Model Description
➤ To change an area or model description
1. In the Add/Open Model dialog box, click the area or model containing the description that you want to change.
✍
The description of a support is automatically set equal to the support ID and cannot be changed.2. Click the description field and edit the description.
When you leave the field, you are prompted to confirm the description change to prevent inadvertent description changes.
3. Click Yes to accept the change, or No to leave it unchanged.
Deleting an Area
W
Deletion is permanent and cannot be undone. The area is removed from your hard drive.➤ To delete an area
1. In the Add/Open Model dialog box, click the area that you want to delete.
Deleting a Model
Deleting a Model
W
Model deletion is permanent and cannot be undone. The model and the associated supports and drawings are removed from your hard drive. ➤ To delete a model1. In the Add/Open Model dialog box, click the model you want to delete.
2. Choose File>Delete Item, or click the Delete Item button to delete the model and all of the supports within that model. A prompt is displayed asking you to confirm your actions because deletions are permanent.
✍
Individual supports cannot be deleted in this manner. See the sections Deleting Pipe Support Items from Supports and Deleting Entire Pipe Supports, later in this chapter.When you delete a model, the entry in the Design Area table, pdtable_113, of the PDS project control database is also deleted.
W
The project hierarchy of areas and models is stored both as a directorystructure on your hard drive and in the SupportModeler project database. Because of this, do not use any Windows file management tools to delete or manipulate models as these changes would not be reflected in the project database.
With PDS projects, the hierarchy is also stored in the PDS project control database.
Moving, Copying or Renaming Models
To move, copy or rename a model, please see the SupportModeler for PDS User’s Guide.
Project Maintenance
Project Maintenance
Archiving Projects
The model files and project database contain the primary design information.
➤ To archive a project:
1. Backup the project folder recursively.
2. Archive any libraries and their associated database files that were used to model any supports and their bitmap files. For example, your master lib and seeds directories.
✍
You can add these SupportModeler directories as User Data to your PDS Archive.Retrieving a Model from Backup
Normally, the SupportModeler project directory is backed up (probably on a daily basis) as part of the ordinary server backup. Sometimes, you may wish to retrieve a particular model from the nightly backup. ➤ To retrieve a model from backup:
1. Retrieve the project database as well as the design file from your archive device and place these into a temporary location
2. Open the SupportModeler project that you want to import the backup model into.
3. Select File>Copy/Import Model... The Copy/Import Model dialog opens.
Checking for Model Inconsistencies ➤ To edit project options
1. Start SupportModeler.
2. Select File>Open Project from the SupportModeler menu bar to open the project or, if the project was opened recently, select it from the Most Recently Opened list near the bottom of the File menu. The project will open, vendor libraries will be loaded into memory, and the Add/Open Model dialog box will open.
3. Click Done to close the Add/Open Model dialog box.
4. Choose File>Project Options from the SupportModeler menu bar to display a dialog box very similar to the Create Project dialog box.
5. Edit any project options that are not grayed out.
6. Click OK to accept the changes or click Cancel to exit without changing the project options.
✍
Depending on which project options you change, a warning may be displayed indicating that the changes will not take effect until you exit and restart SupportModeler.Checking for Model Inconsistencies
SupportModeler provides a MicroStation keyin command
SMCHECKMODEL which checks the active SupportModeler model for inconsistencies and reports any problems it finds. In particular, it checks for:
• pipe support graphics in the MicroStation DGN file that do not have corresponding project database entry.
• project database entries that do not have corresponding pipe support graphics in the associated MicroStation DGN file.
• make sure that every component is part of a support.
These inconsistencies usually result from editing a SupportModeler model using plain MicroStation rather than SupportModeler, but can also occur as a result of network communication problems or crashes of the client or server machines.
The SMCHECKMODEL operation creates a log file in the model’s directory named the same as the pipe support model, with the extension *.chk. Upon completion, it displays this file using notepad. Generally, to fix these problems, you would use the SMFIXMODEL tool explained below in the section “Fixing Model Inconsistencies” on page 50. Whenever a user opens a model, SupportModeler automatically runs SMCHECKMODEL in the background, without displaying the log file.
Project Maintenance
If it finds any problems, it warns the user and recommends that the administrator run SMFIXMODEL.
SMCHECKMODEL does not change the model in any way and can safely be used at any time.
➤ To check a model for inconsistencies
1. Start SupportModeler and open the project containing the model.
2. Open the model to be checked.
SupportModeler automatically runs SMCHECKMODEL in the background and warns if it finds any problems. It will not display the log file.
3. Optionally, in the MicroStation keyin field, type SMCHECKMODEL.
SupportModeler will repeat the model check and will display the log file showing the results.
Fixing Model Inconsistencies
SupportModeler provides a MicroStation keyin command
SMFIXMODEL which fixes any inconsistencies that it detects in the active SupportModeler model. The SMFIXMODEL operation fixes problems that are reported during an SMCHECKMODEL including: • deletes pipe support graphics in the MicroStation DGN file that do
not have corresponding project database entries.
• Deletes project database entries that do not have corresponding pipe support graphics in the associated MicroStation DGN file.
• deletes components, both the graphic and the object, that are not part of a support
Reinstancing Supports
5. Open the model to be checked.
SupportModeler automatically runs SMCHECKMODEL in the background and warns if it finds any problems. It will not display the log file.
6. In the MicroStation keyin field, type SMFIXMODEL. SupportModeler will delete inconsistent elements and fix any mismatched locations. It will display the log file showing the details of what was changed.
Reinstancing Supports
SupportModeler provides a function reinstance the supports in the active model based on the current definition of the SUPPORT item in SM_CORE_USER library. This is very useful if you add or remove properties and want to propagate these changes to supports that have already been modeled.
The Reinstance Supports command does not reinstance or change components or assemblies, it only changes the SUPPORT object itself.
✍
The SupportManager product, available separately, adds the ability to reinstance all of the supports in a project, or in specific areas and models, automatically. This is very useful if you want to make retro-active changes to a project that already has numerous supports modeled.➤ To reinstance supports in a model
1. Make sure that the changes you make to the SUPPORT object are made in the particular SM_CORE_USER library (SUPPORT.ITM) that is used by the project. For example, your master lib and seeds directories as discussed in “Create Server Directories for Master Libraries and Seeds” on page 8.
2. Start SupportModeler and open the project containing the model.
3. Open the model.
SupportModeler automatically runs SMCHECKMODEL in the background and warns if it finds any problems. It will not display the log file. If any problems are reported, these should be fixed before updating the supports. Refer to the section “Fixing Model Inconsistencies” on page 50.
4. From the Support Menu, select Reinstance Supports.
SupportModeler will update each support in the model and change it to match the current definition of the SUPPORT item script, including adding any new properties that were added to the definition. The values of existing properties from the existing support are passed into the new support.
Project Maintenance
Configuration Variables for SupportModeler
SupportModeler Version 7.2.3 provides numerous configuration variables which give you control over many aspects of the software. All of the configuration variables are included in two delivered files, with extensive comments on how to use them:
• C:\Program Files\SupMod\mdlapps\config\mslocal.cfg • C:\Program Files\SupMod\Seeds\sm_drw.dat
Generally, drawing-related configuration variables are included in sm_drw.dat and all other settings are in mslocal.cfg
Please refer to the delivered versions of these files for instructions on how to use the various configuration variables. Specific configuration variables are mentioned in the sections of this guide dealing with the
Customizing the Fabrication Drawings
Customizing the Fabrication Drawings
SupportModeler fabrication drawings are generated automatically based on simple formatting features that you specify in the drawing seed files and an ASCII configuration file called SM_DRW.DAT.
Drawing Seed Files
Drawing seed files define the location and size of support graphics in the drawing and contain text nodes that are used for annotating the border and defining annotation symbology. Each drawing seed file can have an optional border file attached as a reference. The drawing seed files work together with the SM_DRW.DAT drawing settings file.
SupportModeler creates each fabrication drawing by copying a 3D drawing seed file (*.sht) with an optional attached border reference file (*.brd) into a new 3D drawing file. The user can select the seed file to use for each support in order to most effectively display the graphics of the support and its position in the plant. You determine what seed files are available to the user for the each project.
Each project can use standard company-wide drawing formats, or each can have unique project-specific drawing formats.
✍
See the delivered example seeds and borders SM_ASIZE and SM_BSIZE in the C:\Program Files\SupMod\Seeds\ directory.✍
Seed files must be 3D MicroStation files, not 2D, or the drawing routines will not work properly.✍
Seed files for a project should be located in the project’s \Seeds\ directory.View Definition Panels
A view definition panel is a numerically-tagged rectangular shape in the drawing seed file in which a view of the 3D support model can be displayed.
✍
Maximum number of view panels in a drawing is now 20 (increased from previous limit of 5 in versions prior to Version 7.2.3).During drawing production, the 3D support model and it’s displayed reference models are attached as reference files for each view panel. Each view is sized and clipped in the orientation specified by the user (in the
Relevant Settings for “Drawing Seed Files” Location
Customizing the Fabrication Drawings
Active Support Parameters properties View in Panel 1, View in Panel 2, etc.) so that the active support and a portion of the surrounding structure fit within the panel. In addition, view panels can automatically display detail cells on the drawing (see “Automatic Detail Cells” on page 68). The view panels themselves are automatically deleted from the drawing file after the reference files are attached.
➤ To create a view definition panel in a drawing seed file Refer to the MicroStation User’s Guide for detailed instructions on placing a block and working with tags.
1. Using the MicroStation Place Block tool, place an orthogonal block into the seed file (.sht, not the border file), within the boundaries of the border.
2. Using the MicroStation Attach Tags tool, attach a numerical tag to the block with a unique value from 1 to 5.
Once a view panel is created, it can be copied to create additional view panels. For copied panels, use the MicroStation Edit Tags tool to change each tag to a unique numerical value from 1 to 5.
Relevant Settings for “View Definition Panels” Location
SUPMOD_DRAWING_VIEW_PANEL_TAG_SET_NAME SM_DRW.DAT
SM_DRAWCLIPZ SM_DRW.DAT
SUPMOD_DRAWING_SUPPRESS_COMMON_ORTHO_SCALE SM_DRW.DAT SUPMOD_DRAWING_FAST_FIT SM_DRW.DAT SUPMOD_DRAWING_SUPPRESS_REFS_IN_VIEW_PANELS SM_DRW.DAT
Drawing Seed Files Automatic View Panel Labels
When the user generates a drawing, each view panel that displays a drawing view, or the keyplan, gets an automatic text label to clarify the contents of the view. For example, Elevation Looking West, Isometric Looking Northeast, Plan View, or Keyplan. You can control the text of these labels and the symbology but, for now, the label is always placed at the bottom center of the view panel..
Annotation Text Nodes
Text nodes are placed into the seed file to define the location, font, and justification for displaying specific annotation data on a fabrication drawing. Each text node corresponds to a specific SupportModeler property as defined in the SupportModeler drawing settings file, SM_DRW.DAT. For each project, this ASCII data file maps specific properties, or expressions, to specific text node numbers. Each seed file used in a project should use the same text node numbers for the same properties. Data is displayed on a text node by using the text attributes associated with that text node.
Refer to the MicroStation User’s Guide for detailed instructions on changing view settings, working with text nodes, and compressing design files. Relevant Settings for “Automatic View Panel Labels” Location
SYMBOLOGY_VIEWLABELS SM_DRW.DAT Associated SYMBOLOGY_VIEWLABELS text node Drawing Seed Files SUPMOD_DRAWING_NORTH_TEXT SUPMOD_DRAWING_EAST_TEXT SUPMOD_DRAWING_SOUTH_TEXT SUPMOD_DRAWING_WEST_TEXT SUPMOD_DRAWING_NORTHEAST_TEXT SUPMOD_DRAWING_NORTHWEST_TEXT SUPMOD_DRAWING_SOUTHEAST_TEXT SUPMOD_DRAWING_SOUTHWEST_TEXT SUPMOD_DRAWING_TOP_TEXT SUPMOD_DRAWING_BOTTOM_TEXT SUPMOD_DRAWING_ELEVATION_TEXT SUPMOD_DRAWING_ISOMETRIC_TEXT SM_DRW.DAT SUPMOD_DRAWING_SUPPRESS_VIEW_LABEL_JUSTIFICATION_CHANGE SM_DRW.DAT Description of MicroStation Saved View, if User specifies a saved view in a view panel Support models
Customizing the Fabrication Drawings
➤ To add a text node to a drawing seed file
1. Open the drawing seed file in MicroStation.
2. Turn on the display of text nodes by using the MicroStation View Settings dialog box.
3. Set the MicroStation Active Text Attributes as you want.
4. Set the text node number by using the MicroStation key-in: nn=###
where ### is the node number that you want.
5. Using the MicroStation Place Text Node tool, place the text node in the location in the seed file (.sht, not the border file) where you want it.
6. In the same manner, place additional text nodes.
✍
The node number is incremented automatically after each placement. If the next number is the one you want, you do not have to set the node number again.7. Turn off the display of text nodes and compress the design file.
8. Add or edit entries in the SM_DRW.DAT file for the new text nodes. Refer to the section “Controlling Drawing Features using
SM_DRW.DAT” on page -59 for more information. Unless the text nodes are listed correctly in the drawing settings file, SupportModeler will ignore them during drawing creation.