Lenin

Page 1

Tribon Data Base superserver & subserver

The client-server access to a data bank located on a remote machine is based on ONC RPC (Open Network
Computing Remote Procedure Calls). In order to provide access to data bank located on the server we must
have the following Windows services running on the server machine:

PowerRPC Portmapper
TRIBON M1 DB Service

TRIBON M1 DB Service is what we call "superserver". Its executable file is - ea312.exe.

This superserver listens to calls from client applications and when the first request to access a data bank
arrive, the superserver run another program - ea310.exe which we call "subserver".
On the server machine we may have only one superserver process, but more than one subserver
processes. For every application accessing the data banks, we must have one subserver process dedicated to
transfer the data between the application and the data banks. When the application is terminated the
corresponding subserver process should be automatically stopped. In other words, if you have 10 Tribon
applications accessing data bases located somewhere on the server, then you should have one ea312
process and ten ea310 processes running on the server. If you do not have any Tribon application running you should have only one ea312 process running on the server.
However, it might happens that the data base subserver process is not terminated when the client's
application exit. For a period of few hours a small design group (let say 5 - 10 persons) usually generate a
number of such obsolete subservers. These obsolete processes could lock some extra licenses, lock or even
corrupt the corresponding data bank, decrease the system performance, etc. Hence, we have a pretty good
reason to terminate any obsolete Tribon subserver as soon as it appear. There are several ways to do that.
One of them is to use "Tribon DB Server Maint" application. Unfortunately, it is hard to determine there
which process is obsolete and which one - not. Using this application any user can kill any Tribon
subserver. It is very easy (and it happens quite often) to terminate a working subserver and this way
to destroy the corresponding application. Then somebody in the workgroup will get the message
"Tribon DB SubServer on host host_name not responding" and his application will not be able neither to
save the changes to the data base, neither to read from the data base.
One optional way to deal with the obsolete Tribon subservers is to use the new DBTools Pro version and
its Data Base SubServer process control facility. It provide an easy and safety way to clean any obsolete
subserver. While DBTools Pro is running on the user's machine, it constantly monitor all subservers and
Tribon applications running on the user's PC. If one application exit and its corresponding subserver does
not terminate, a message box will inform the user about the obsolete subserver and an option to kill this
process will be provided. The users are allowed to kill only those Tribon subservers that belongs to
themselves. An Administrator's version is available as well. It has extended functionality and allows also
obsolete subsevers clean up at scheduled time interval.

Lenin

Page 2

Tribon License server on Windows XP

From TRIBON Installation guide we can learn that:
"All major Tribon Solutions AB applications are protected using a license server called FlexLM combined
with a hardware key, commonly known as a dongle."
In order to operate the dongle needs to have a proper software drivers installed in the operating
system. Sometimes the drivers included in the installation CDs are not the latest. Thus if your operating
system is not supported - the license server could not start. For example, if you are running Windows XP
the sentinel drivers provided with M1v4 and M2 might not work.
You could use the following link to get the most recent drivers from RAINBOW Technologies
http://www.rainbow.com/support/eu_support.htm
Tribon Data Base superserver & subserver
The client-server access to a data bank located on a remote machine is based on ONC RPC (Open Network
Computing Remote Procedure Calls). In order to provide access to data bank located on the server we must
have the following Windows services running on the server machine:

PowerRPC Portmapper
TRIBON M1 DB Service

TRIBON M1 DB Service is what we call "superserver". Its executable file is - ea312.exe.

This superserver listens to calls from client applications and when the first request to access a data bank
arrive, the superserver run another program - ea310.exe which we call "subserver".
On the server machine we may have only one superserver process, but more than one subserver
processes. For every application accessing the data banks, we must have one subserver process dedicated to
transfer the data between the application and the data banks. When the application is terminated the
corresponding subserver process should be automatically stopped. In other words, if you have 10 Tribon
applications accessing data bases located somewhere on the server, then you should have one ea312
process and ten ea310 processes running on the server. If you do not have any Tribon application running you should have only one ea312 process running on the server.
However, it might happens that the data base subserver process is not terminated when the client's
application exit. For a period of few hours a small design group (let say 5 - 10 persons) usually generate a
number of such obsolete subservers. These obsolete processes could lock some extra licenses, lock or even
corrupt the corresponding data bank, decrease the system performance, etc. Hence, we have a pretty good
reason to terminate any obsolete Tribon subserver as soon as it appear. There are several ways to do that.
One of them is to use "Tribon DB Server Maint" application. Unfortunately, it is hard to determine there

Lenin

Page 3

which process is obsolete and which one - not. Using this application any user can kill any Tribon
subserver. It is very easy (and it happens quite often) to terminate a working subserver and this way to
destroy the corresponding application. Then somebody in the workgroup will get the message "Tribon
DB SubServer on host host_name not responding" and his application will not be able neither to save the
changes to the data base, neither to read from the data base.
One optional way to deal with the obsolete Tribon subservers is to use the new DBTools Pro version and its
Data Base SubServer process control facility. It provide an easy and safety way to clean any obsolete
subserver. While DBTools Pro is running on the user's machine, it constantly monitor all subservers and
Tribon applications running on the user's PC. If one application exit and its corresponding subserver does
not terminate, a message box will inform the user about the obsolete subserver and an option to kill this
process will be provided. The users are allowed to kill only those Tribon subservers that belongs to
themselves. An Administrator's version is available as well. It has extended functionality and allows also
obsolete subsevers clean up at scheduled time interval.

Tribon M1 / M2 Project Security Setup

/Sys admin guide/
1 Preface
One TRIBON project is a complex environment which consists of different kind of information. There are
data banks, default files, project configuration file, symbols, applications' input and output files, etc. Each
of these items has to be accessed and supported in the right way. For example, the data banks have to be
accessed only trough the applications that are especially designed for this purpose. Opening any of the data
banks' files as a text file for example may corrupt the data bank and destroy the information inside, hence
to destroy the model information.
Considering the TRIBON working environment in the real live, we have to admit that one TRIBON
project will be accessed by a number of people, specialists in their area - pipe, hull, outfitting, etc., but with
different computer skills. In order to build one trouble less working environment, we must protect the
sensitive project information from the human's mistakes and at the same time to provide flexible and
unrestricted way of working for every project participant.
The purpose of this document is to give to the reader a basic understanding for TRIBON project
environment, the usage of the different project's items and some examples of how these items could be
organized and protected using the standard Windows security facilities.

2 Basic concept

Lenin

Page 4

In the real practice one TRIBON project is accessed in client-server working environment. In other words ,
the project and all its components are located on the server while the designers' workstations (client PCs)
are running the applications locally and access the model information located on the server. This way all
project participants use the latest model information and the latest project settings. All sensitive
information is located in one place (on the server) and it is easy to back up or restore it when required.
2.1 The server
Generally when we say "server", we have in mind a powerful computer running Windows Server operating
system. On this machine we could set up a number of software servers to handle the client-server
networking environment. Such servers could be DNS, DHCP, Telnet, FTP etc. On the same machine we
could create and configure different computers, groups and users accounts with the corresponding level of
privileges and file access permissions. Usually we setup this machine as a domain controller. These settings
are network wide and even if the user login from different client's workstation he will have always one and
the same privileges.
TRIBON Server
Normally we call "TRIBON server" the machine where the TRIBON projects are located. This could be the
same domain controller, a second domain controller or even just a normal computer running Windows
Workstation software but with higher performance. However for a workgroup of 3 to 7 designers one
workstation dedicated for TRIBON server could be more than enough, but for bigger design offices
Windows Server operating system is recommendable.
What we call "TRIBON Server" is actually a set of software servers (windows services) and project
relevant data banks and ASCII files. Depending on the purpose of this software we can define the following
items:

TRIBON License Server

TRIBON Data Base Server
TRIBON Surface Server
TRIBON Project Server

The common practice is to have all of them configured and working on one and the same machine and
usually this is a Windows Server platform. In some rare cases the surface server could be located on a
different PC or even there could be more than one surface servers running in the network. At this moment I
would like to point out only the difference between Data Base Server and Project Server. For many users
both servers sounds as one and the same functionality, but it is quite different actually. The Data Base
server is supposed to provide access to the data banks where the model objects are stored, while the Project
server's usage is to keep the project's definitions and to provide this information to the client's PCs, serving
d065...sdb files in fact.
TRIBON Client
Usually this is the designer's PC which is running Windows Workstation software. TRIBON software must

Lenin

Page 5

be installed on this machine as well. It is user's choice whether a full installation to be done or only the
required packages for this particular working place to be installed.
Generally the client's PC access the information located on the server in two ways:

TRIBON data banks are accessed using TRIBON data base server and its sub servers based on
PowerRPC Portmapper service

For all other files the standard Windows file sharing is used

Tribon Pipe Specification

From Tribon documentation we know that "Specifications are used to control the selection of components.
A specification defines a subset of components allowed in a certain type of pipe system or for a certain type
of usage or quality level."
Also one of the best way to describe Tribon Pipe Specification is as a bunch of rules that "tell" what
component from Components' database [SBE_GENCMPDB] is to be used into specific system, for a given
pipeline/surrounding part(s) size.
Specification uses 3 kinds of categories of data:
1. Intervals (the complete name is "Pipe intervals");
2. Functions (the complete name is "General functions component data");
3. Sequences (new from M2, fully available from M3).
A pipe interval is practically a pipe size (referring to one pipe component, type code 70xx). This category
establishes which are the systems pipes (as material, sizes and other technical/dimensional aspects).
General function component data contains component groups having the same technical and functional
meaning, but with different sizes.
Lets take an example: for a certain system (lets call it BL - ballast system) we have to use all flat flanges
PN16, acc. to DIN, from DN25 to DN200. For this we have to create a function, having a long name (e.g.
"DIN flanges PN16") and a short name (e.g. "FPN16"). After that for any interval that have as nominal
diameter DN25 up to DN200 we have to add reference to the proper flange component (using Select
Component), and so we are creating following rule:
For the system BL, for pipe size 114.3x7.1 (DN100) the flat PN16 flange is DIN.F.PN16-100 (the
component name for our flange is given here arbitrary).
Actually thats the way Specification works.
Regarding sequences: imagine that the above-described function is like a command. Then the sequence is
like a macro-command. Into sequences user declares the chain of functions (no component is
declared here, only functions via sort name) in order to be added/inserted into model. The result is
speeding up the modelling process when multiple parts are added/inserted.

Lenin

Page 6

Now lets take the first part of the last phrase: "The result is speeding up the modelling process...". Thats
actually the aim of specification - to make Tribon pipe modelling faster. As a bonus the specification helps
avoiding errors too.
Looking into Tribon Pipe Specification, some people ask "Why to spend time creating specification,
instead to open directly Diagram or Pipe Modelling applications?"
This is actually the only disadvantage of Specification. On the other hand, as advantages can be counted:

the modeling process is governed by rules imposed the system (its place on ship, the fluid carried
by its pipelines, etc.), and so lesser errors can be made when choosing a component to add/insert
into current pipeline;
the choice of components, when using specification, is much faster than using directly Components
DB (no need for extra checks and the number of components to browse are dramatically reduced
from hundred of even thousands in db to a number having only one digit);
users may check latter the "origin" of the part, i.e. how the part was chosen (specification, function
name, size etc.), having as help for this Search criteria;
one of the most powerful function of the modelling, Resize/Respecify can be used later on at a full
blast only if all parts into pipeline were added/inserted using specification.

If it seems that the effort to make Tribon pipe specification is a little bit too big, lets remember that it is
possible to have a standard specification, for all projects or used as starting points for project-dependant
specifications, we can copy specifications and edit them, and it is possible to export/import specifications
also.
Article written by Dragos Patilea
Powerful functions of Pipe Modelling: Resize/Respec.

Important notice:
Even many aspects are similar with Tribon M3s Resize/Respec.,
what is written here is valid only for Tribon M2 SP4 and SP5.
Introduction:
Resize/Respec. function is a powerful one, but sadly not very often used by 3D modellers, due to prerequests and its apparent behavior - random result. Actually this is wrong, you will see that below.
The function was available (for NT platforms) starting M2 version.
The main aim of function is to provide to user an instrument to change:

the dimension of parts for entire pipe or branch (re-size them)

Lenin

Page 7

to change specification that parts are pointed to

just using one function only.

Highlights:
Function options:
Resize/Respec. has 4 options, allowing the change of:

the size of a part/parts/all parts within a branch/all parts within a pipe via specification (Resize
option)
the specification for a part (might look strange, but is possible)/parts/all parts within a branch/all
parts within a pipe (Respecify option)
to change a part/parts, if the name of comp.(s) is/are known (Key in option)
to change a part/parts directly from component data bank (Component db option)

Restrictions:
For Resize option, if addressed to a part/some parts within branch/pipe, then the part(s) should be
modelled via specification. If the same option is addressed to the entire pipe (by changing the main comp.
and/or all parts within), then pipe should be created using specification.
Please note that the system allows users to use this option just for main comp. This is not OK, in my
opinion, due to many reasons, but I will not insist on that here.
For Respecify option, if addressed to a part/some parts within branch/pipe, then the part(s) should
be modelled via specification (like the above). Also theres no way to change specification of main
component if the pipe was not created via specification; trying to do this the user will be prompt not with
no spec. attributes line displayed next to component name, but Search component (Respec mode)
window will pop-up, having OK button not active, and so making it useless.
The Key in option has no restrictions at all, and so it has more power and became the most dangerous
option of all (e.g. if the keyed-in component is missing in db, than the component is replaced, without any
warnings, by frame). User has to avoid using it when the modelling is spec. driven, with one exception,
shown later on.
Similar with the above, Component db is less restrictive and has full control on component names. Same
advice here: avoid it when modelling is spec. driven.
Therefore, first two options have to be used only when modelling was made via specification, and last two
only when the modelling is not implying any specification (with the above mentioned exception).
You figure out already that the Resize/Respec. function is more than its name, and is not addressed only to
pipes created and modelled via specification. As written in Documentation: By using the Resize/Respec.
function, one or more parts in a pipe may be re-sized, re-specified or re-placed

Lenin

Page 8

Aspects of Specification and Pipe Modelling:

As you know from my previous article (Tribon Pipe Specification), the best description of specification is
as a bunch of rules, which, during modelling, tells directly to the system (Automation Level as High)
which parts have to be taken from components db, or allows user to pick only pre-established items from
the same db (Automation Level as Low). In order to use Specification option when creating pipes and
adding/inserting parts into existing pipes we need to have the Tb environment variable
SB_PIPE_SPECDRIVEN set to ALWAYS, or at least YES.
I would like to insist a little bit on this variable, found on d065<proj_name>.sbd file:
SB_PIPE_SPECDRIVEN = NO

user is allowed to create pipes directly from comp. db only;

functions of add/insert parts have no Search Component(from specification) window, but directly
Pipe Material one;
advantages:
o modelling process is 10%-25% faster, if the component db is small to medium and has
group organized structure and Same as option is used extensively
o no need to spend time creating and updating specifications
disadvantages:
o no specification means less control on components used within certain pipe system
o refining/revision process is slow, and big alteration of comp. db or pipe system will become
an issue

SB_PIPE_SPECDRIVEN = ALWAYS

every part within pipe system is found into specification

new pipes will be created having as basis pipes from specification only
any other modelling options when adding/inserting parts, like Key in, Component db etc. are
missing (except for Resize/Respec.!)
advantages:
o absolute control on components used within certain pipe system
o the refining/revision process can be few times faster (incl. due to the use of Resize/Respec.)
disadvantages
o the use of Same as is not possible
o user has to create and update (if needed) system specification

SB_PIPE_SPECDRIVEN = YES
In fact this is of mixture of spec. driven modelling and not spec. driven modelling; therefore user may use
information from specification or directly from component db or from already modelled items
New pipes can be created via specification (Resize and Respecify options can be used) or directly from

Lenin

Page 9

component db (only Key in and Component db options are working)

advantages:
o prime-modelling is faster than having SB_PIPE_SPECDRIVEN = ALWAYS, since options
like Same as and Key in of part add/insert functions can be used
disadvantages:
o use of specification became optionally, even it exists
o refining/revising process gets tricky (e.g. for the best result user has to investigate which
parts are added via spec. and which are not), and so time consuming
o less control of modelling

However, if SB_PIPE_SPECDRIVEN will be YES , some master-rules has to be created at user level
that have to manage all options found when creating pipes, add/inserting parts, Resize/Respec. etc.
Otherwise the result might be surprisingly out of control.
Since the complying with these master-rules is hard to be supervised, in my opinion YES value has to
be avoided.
Working with Resize/Respec.:
Before using it
Maybe this sounds strange (especially for fast users), but for a safe result is better to make some
checks/preparations/adjustments before using Resize/Respec. function:

how the pipe was created (via specification or not);

which parts were done via specification., and which were not;
if joints, weldgaps, insulation, on surface parts were used and if some adjustments are needed;
if new elbows, bends, etc. will have or not sufficient space, after the changes;
identify external connections (for best result they have to be disconnected);
identify on surface connections (for best result they have to be disconnected);
identify complex parts (e.g. 3/4-way couplings/valves) were used (for best result branch connection
have to be disconnected);
check if bending machine has proper set-up. Insert line BMOBJECT_ID=0 in SBP_MODE_DEF
file, if missing.

Inside the function - what is happening?

Well, well Lets say we have pipe/branch prepared. If no pipe is current we can start to use
Resize/Respec. function, for a branch or for entire pipe. Remember: that means all changes will be made
right away, without the possibility to undo them later on (no Cancel function here)!
Below will be presented all working options for most of situations.

Lenin

Page 10

For all options:

even you select just one part, do not be surprised to see into confirmation window more parts
changed, or part ids changed - this is OK (the entire branch/pipe is re-organized to support the
changes). What you have to do is to investigate closer these changes, e.g. if a part was replaced by
frame. If so maybe you didnt make all checks/preparations/adjustments as written above
when user accept the changes, a new (buffer) pipe is created, e.g. <proj>-<mod>-<sys>1000,
<sys>1000 = pipe name. In modelling the use, even for testing, of pipe manes like <sys>1***
should be avoided, if not forbidden; reserve them for Resize/Respec.
if working with weldgaps - you may find some having 0.0000 value (e.g. weldgaps at the first conn.
of straight pipe parts). Please adjust them to proper values before confirmation of changes, if they
seem to be affected by initial changes. For this you are allowed to use Key in option even
the pipe was spec. driven modelled (yes, is that exception that I pointed to before!); theres
no problem, since weldgaps are a special kind of parts, no specification (yet!) behind them. Please
note that: if youll fail to do this then the null weldgaps will be deleted from model!
please pay attention to Func and Spec columns. Sometimes information presented there is not
accurate!

For Resize option:

if the pipe wasnt made via specification - dont use it; instead Key in or Component db options
will do the job
when using Resize/Respec.>Branch do not change the main component size - this will affect the
entire pipe, not only the branch!

For Respecify option:

is not only futile, but a little bit dangerous to use this function for pipes not created via
specification. Avoid troubles and never try to specify a pipe that wasnt specified from start. Thats
it, nothing to do here!
even the system is permissive, never respecify only some parts or a branch, only pipes are
allowed, with all parts within
before using this option, maybe is better to open Specification program (TbSpec.exe) and to check:
o if the short name of functions, for both specifications, are identical
o if you do have, for a certain interval and function, component name assigned, and if is
correct

For Key in option:

never use it when SB_PIPE_SPECDRIVEN = ALWAYS, with the above described exception
if pipe was spec. driven modelled, try to avoid it you might need to use the Resize/Respec.
function again
just pay attention on keyed in text ;)

Lenin

Page 11

For Component db option:

again: has to be left aside when SB_PIPE_SPECDRIVEN = ALWAYS

has to be forgotten if pipe was spec. driven modelled

After function is done

For M2 (and not only) there are declared some limitations. Lets see what we have to do after the
Resize/Respec. is done, in order to surpass them:

when operation is completed, pipe branches are disconnected. If wed take care of this before,
having everything under control, we have to go back and re-connect. Please note that sometimes the
environment is changed too - then, some adjustments has to be made

some parts might be replaced (not all the time) by frame, due to environment or components prop.
(e.g. reducers, tees, bends), sometimes together with surrounding parts (straight pipes). This could
happen even we followed all the steps of the above, but this will be a very rare situation
weldgaps (in fact just some of them!) will be removed. If we paid attention to weldgaps during the
resizing/respecifying/replacing process, this problem is fixed.

Few more lines:

Maybe you noticed - this article is somehow long. However, the problem is not as detailed as it should (e.g.
I skipped how to update a part having its component changed issue). If you feel that you need more info,
please send an e-mail.
To conclude: the function is fine; you just have to pay a little more attention when using it, before and after.
I just hope that my hints will help you to use successfully this function.
Thank you for reading it.
Article written by Dragos Patilea
Classical collision control (in Tribon Mx)

Collision control is important when user goes for detailed design and Tribon has this feature well
developed.
In order to check for collision user should go for Tools>Model>Collision Control function.
Collision control function

Lenin

Page 12

When going for this function user is prompt with a window called Collision control, having title
Collisions between and three options:
1. Indicated models
2. Indicated models and view
3. Restrict on model types
A little bit strange, user should go first for 3. to choose the type of model items that have to be
checked. I repeat: type of model items, not the items - these are collected using options 1. or 2.
Regarding these two options, I think is useful to add here some aspects that are missing in both Training
Guides and Documentation:
1. lets the user to collect all items from a model view(s); thats happening when he/she is choosing the level
1 for the subpicture. Moreover Options (++) will return the collecting loop to the choosing level step; and
this can be very useful when user like to see collision of all items in one view with only one item from
another view (example: user had added a new structure in the model and wants to check collision between
this one and all the other existing items in the surroundings).
2. permits the user to collect one by one model items (in my opinion the option name is wrong and
confusing, since selection is no view dependent - till now I dont have an explanation for it).
After selecting the model items that have to be checked (all of them should be in one view of the drawing,
in order to get collected), we have some Result options (from a window named also Collision control),
as follow:
1. List: user will be prompt with a window having all interferences presented simplified. Example: PJMOD1-BL23 and PJ-MOD2-CO5 collided 2 times. In the same time in Message Window is written total
nos of interferences found.
2. Highlight all: allows user to see in view or shaded mode/viewport all clashes. Here also the total nos
of interferences are written in Message Window.
3. Highlight one by one: allows user see one by one all clashes and to take a closer look (only in shaded
mode) to them. This time into Message Window can be read more details on each collision, like: PJMOD1-BL23 (7, HARD) interfere with PJ-MOD2-CO5 (25, SERVICE AREA )! , where 7 and 25 are part
ids.
4. List on file: the detailed list of interferences will be saved into lst directory of the project as a file
having lst extension and free name (up to user).
5. Set (none) shaded mode

Lenin

Page 13

Note: the above list of options is slightly different in M1.

Collision control of what?
Many people just ignore the collision control build-in feature, and they are going only for visual inspection,
since this kind of check looks reliable enough and much faster than the Tribon collision control. In fact
using shading mode/shaded viewport (or Design Manager, as alternative) user can see all possible
interferences. Apparently it is all about his/her eyes and experience, but in Tribon virtual world doing so
might be wrong.
The reason is complex, and has the origin not in the model itself, but in the entire industry that is hidden
behind of the presentation of the model.
Lets make an experiment:
- open a new drawing in your current project (no format needed) , add all panels from a section (select one
section with problems) in a new model view. Make a check and have the result as a list. Please note the
number of interferences.
- go to Tools>Preferences and choose Model Draw Code/Panel, change the default values for the codes
to No for Brackets, Cutouts, Profiles and Thin for Panels. Go back to your view and exchange it from
Defaults.
- use again collision control function and compare the new number of interferences with the old one. The
new number is smaller, isnt it?
This boring experiment was needed to prove my point: the collision control is not only about the model but
also about graphical presentation of it. And the presentation is not unique; it depends of the abovementioned drawing codes that control the 3D appearance of the model.
What is happening behind the scene?
The system is picking the position of model part (not for the entire item!) and recreates the 3D-shape of it
according to drawing codes used for the model items selected. That means the system collects the on-view
instance of the model, having actual position.
Note: If the model is missing in db (the view is not valid) the user is prompt with a warning
message or window. Also if the model is obsolete (and need exchange), the all model items, not only
selected for checking against collision, from the view are automatically exchanged if as Result options are
used 2. Highlight all and 3. Highlight one by one (Repaint could be needed here, depending how user left
the function).
However, the best result is with valid views on drawing (all items are updated and no phantom item in
workspace).

Lenin

Page 14

Drawing codes and presentation

I think is clear now: clash management is controlled by the model presentation via drawing codes. But not
only!
Drawing codes are handled by Drafting default keywords for more information please refer to
Documentation: Tribon M1(M2/M3) Drafting/Drafting/Users Guide/Appendices/Drafting Default File
Keywords/Drawing Codes.
For outfitting items things are more complex here. Just go to Tools>Preferences and choose Model Draw
Code/Cableway or Model Draw Code/Pipe.
Since I would like to have as example from this point a globe valve, please allow me to discuss only on
valve drawing codes (controlled by the keyword PIPE_VALVE_CODE_DRAW from SBD_DEF1 Drafting
default file also). In this case we have 6 codes available (the nos in front are actual values of the
keyword!):
1 - Centre line
2 - Material: draw 3D-symbol (font 0), known as default volume, if exists, else draw centre line; also this is
the default value of this keyword
3 - Material & centre line: draw both symbol and centre line
4 - Symbol & centre line: as 3 (is relevant only for pipes!)
5 - Volume: draw volume if exists, if not same as 2
6 - Insulation: insulation, if added, is drawn also (there are some limitation here, not subject for this article)
In 5 - Volume we have first contact with Detail level. As you know in Volume group of component
properties are found, beside name of the volume(s), the type of it/them (in our case is 2, since valves are
allowed to have only actual volumes as 3D appearance), scale factor, usage code (we are talking about
modelling, so it is always 2) and detail level. This detail level let us to have attached as reference more
than one volume, depending on our purposes. Important: one detail level per volume, please.
Usage of softness, material alias file and detail levels
In order to have a clear understanding of detail levels, I will go to the origin: volume primitives softness.
The default value of softness is 0 (the common hard area, solid, impenetrable), and is controlled by
VOLUME_SOFTNESS keyword in the same SBD_DEF1 file.
When creating/editing a volume, user can change the softness of an existing primitive, using
Volume>Softness>Modify function, or can set the softness for further inserted primitives by

Lenin

Page 15

Volume>Softness>Default
Softness value can be from 0 (this should be reserved to hard area) up to 9, according to rules established in
SB_MTRL_ALIAS file. This is a text file, usually having the name mtrl_alias or similar, with extension
def, commonly found into def project directory. Bellow we have an example of a possible content of it:
HARD = 0
SERVICE AREA = 3
DISMANTLING SPACE = 4
MAINTENANCE SPACE = 5
INSULATION = 7
As result some primitives can be declared soft and having a dedicated type of softness, according to the
designation of the modelled space.
Important: if in volume some primitives are declared having softness e.g. 8, which is missing in
SB_MTRL_ALIAS, then the system will automatically declare it Hard area (this is exact spelling of it!);
therefore primitive will be recognize as solid, and not soft area.
In our case (a simple valve) we need to provide service area (for movement of the hand wheel) and, if
necessary, insulation. That means we have to model one volume (all primitives are hard) that will have
added some other primitives, for service, which have to be soft with softness 3. The new volume should
have same name as the all-hard one, but with suffix S, in order to be easily recognized - but this is not a
rule.
Now our valve as component has 2 volumes, one all-hard (real appearance) and one with service area. We
have to manage to use them both, according to our needs, incl. from collision management point of view.
For this we have detail levels.
In our example we have to use only two detail levels, i.e. 9 for full detail volume (all-hard) and other one,
for servicing.
Note: always use all-hard volume as first volume, since any level (detail level -1) used mostly for
graphical presentation leads to first volume.
There is no file with rules for using detail levels; however the best is to have established for all projects the
same rules, and posted to all designers/users, as follow:
0 - not used

Lenin

Page 16

1 - just the box

2 - simplified volume (can be used for complex equipments)
3 - volume with service area included
4 - volume with dismantling space included
5 - volume with maintenance space included
6 - volume with another kind of space
7 - items with insulation
8 - volume with soft spaces all together
9 - full detail
Like for material alias file, this is just an example, with the remark that you have to preserve 9 for full
detail (all-hard) volume.
Back to Collision control
Lets summarize first: we have a valve and two volumes, first one is full detailed (all primitives
have softness 0), and is related to detail level 9. The other one is full detail plus service area (some extra
primitives are added and have softness 3); for this I recommend to use detail level 3 (theres no
coincidence, in our example I used same nos for type of material).
Going to modelling: the default value for piping items is 2 (Material), as already presented. Due to that is
possible to have in drawing, as appearance, just the 3D symbol (font 0), given automatically by the system
when saving the component. Checking for clashes now can be plain futile, as long as parts of valve (e.g.
rod, hand wheel) are not shown. The best is to have an accurate 3D presentation of it, by volume modeling.
But we have already 2 volumes by two different detail levels. If we change the drawing code from Material
(2) to Volume (5), we can see the detail level -1, actually first volume. I suppose that we followed me and
first volume is detail level 9 - this one will be exchanged into drawing. Now we can proceed to interference
checks if wed like to see if my valve is clashing to something else as hard/solid item. In order to check if
valve can work in its specific environment, we have to go for detail level 3, to exchange the model item
again (its owner pipe) and to use again Collision control function.
There are known following types of clashes:
1. hard area/hard area (the items cannot be mounted on ship)
2. soft area/hard area (e.g. coolers may need space for dismantling/maintenance; ignoring this, even a

Lenin

Page 17

visual checking of the model is made, its hard to be 100% that there is enough space for maintenance)
3. soft area/soft area (e.g. two valves, like ours, hand wheel up - soft area/service space).
As you noticed, only 1. is important, but other two also, which are defined by Documentation as soft
collision.
Final remarks:
Oh yes, Tribon collision control is complex and cannot be ignored by a good designer, due to its versatility
and accuracy.
In fact concepts as material alias/softness, detail level and drawing codes are build around the collision
control (also known as clash management), to serve it. Secondly is about the appearance of the model after all, we need 3D capability to see items on ship, in order to place them correctly, without clash, isnt it?
Article written by Dragos Patilea