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.
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
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.
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
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 system’s 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.
Let’s take an example: for a certain system (let’s 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 that’s 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.
Now let’s take the first part of the last phrase: "The result is speeding up the modelling process...". That’s 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 M3’s 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 pre-requests 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:
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 there’s 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”
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
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… Let’s 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)!
For all options:
even you select just one part, do not be surprised to see into confirmation window more parts changed, or part id’s 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 didn’t 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!); there’s
no problem, since weldgaps are a special kind of parts, no specification (yet!) behind them. Please note that: if you’ll 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 wasn’t made via specification - don’t 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 wasn’t specified from start. That’s 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
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. Let’s 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 we’d 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
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); that’s 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 don’t 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: PJ-MOD1-BL23 and PJ-MOD2-CO5 collided 2 times. In the same time in Message Window is written total no’s of interferences found.
2. “Highlight all”: allows user to see in view or shaded mode/viewport all clashes. Here also the total no’s 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: PJ-MOD1-BL23 (7, HARD) interfere with PJ-MOD2-CO5 (25, SERVICE AREA )! , where 7 and 25 are part id’s.
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).
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.
Let’s 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, isn’t 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
above-mentioned 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).
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/User’s 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 no’s 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
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:
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
Let’s 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 (there’s no
coincidence, in our example I used same no’s 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 we’d 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)
visual checking of the model is made, it’s 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, isn’t it?
