• No results found

Technical Information

In document BOCAD Steel Interface (Page 50-59)

A.1 under the container element as specified in the Store in: field on the Import window

3.3 Technical Information

This section contains technical information which is not immediately specific to Products but of which the user should be aware in order to get the best out of the interface.

Recommended File Suffix

Although it is not critical for this interface, the recommended suffix for the files is to be abs.

Cardinal Points

Below is a diagram illustrating the positions of the Cardinal Points.

The Cardinal Point imported should be retained for later export. This is because it is likely to be a source of confusion when a member originally laid out on Cardinal Point 14 (Top of Steel) is returned on the Cardinal Point 10 (Neutral Axis). Additionally, it will cause minor problems in model versioning and comparisons.

Default Orientations

There is a definition of the default orientation of profile shapes. This is closely based on the AISC standard.

Below is a diagram showing the default orientations of the Catalogue profiles.

Pline Selection Rules

The user can define which Plines are identifiable or selectable using the supplied structural design appware. Saving the rules generates a file in the default folder. This is later automatically picked up on re-entry into the base product. Then, these rules become applicable to various operations in the standard Steelwork Appware.

AVEVA Plant and Outfitting 12 Series

Select Settings > Pick Filters > Plines to display the Pline Filter window.

AVEVA Everything3D™

On the Sections tab within Structures, in the Settings group, click Plines Filter to display the Pline Filter window.

Clicking Define Rules displays a window on which the user can create their own. Above is the window filled in for the supplied Pline filter rule. The operation of the window is fairly self explanatory.

Use of Pline Filters

The default drawing flags for the Plines have been changed to LEVEL 99 99, CLFLAG TRUE and TUFLAG TRUE. In the base product the user can choose which Pline filters to use using the following method.

AVEVA Plant and Outfitting 12 Series

Select Settings > Pick Filters > Plines to display the Pline Filter window.

AVEVA Everything3D™

On the SECTIONS tab in the Settings group, click Plines Filter to display the Pline Filter window.

Select which rule set the user wants to use by indicating it.

Click OK. This rule set then becomes available for use when using AppWare functionality only.

Note: Direct querying, such as "q idpl @" does not access this rule set.

UDAs

This section lists the UDAs defined for this interface, an attempt has been made to keep the unique abbreviation to 6 characters. The UDAs for this interface are:

General Data

Name Type Len On Description

:FABID/ATE TEXT 30 SCTN PANE GENSEC Date of Import :FABIT/IME TEXT 30 SCTN PANE GENSEC Time of Import

:FABRE/VNO INT 1 SITE ZONE STRU SCTN

PANE GENSEC

Revision Nr (0)

:FABTRA/NO INT 1 SITE ZONE STRU SCTN

PANE GENSEC

Transfer index(1)

:FABTRR/VNO TEXT 10 SITE ZONE STRU SCTN PANE GENSEC

Revision Text

:FABEX/CLUDE LOG 1 SCTN PANE SJOI PJOI

GENSEC

Exclude flag (f)

:FABSTA/TUS TEXT 10 SCTN PANE GENSEC Status text :FABCD/ATE TEXT 30 SCTN PANE GENSEC Date of Creation :FABMD/ATE TEXT 30 SCTN PANE GENSEC Date of Modification :FABCT/IME TEXT 30 SCTN PANE GENSEC Time of Creation :FABMT/IME TEXT 30 SCTN PANE GENSEC Time of Modification

Structural Data

Project Data

:FABEXCLUDE is a flag the user can set on the items indicated. It is using this flag that the user can control what is exported to the output file. By default the flag is false, that is the item is not excluded from the Export process.

:FABEMARK is the external UUID (Universal Unique Identifier) item. If the item originated in the base product then this value will be the AVEVA database reference number with the leading equals sign, '=', removed.

:FABMARK is the AVEVA internal database reference number. It may not be the same as :FABEMARK if the entity originated in AVEVA Bocad Steel.

:FABSTATUS is used to give the user a view of the current status of the element. It has four different settings: to signify the item originated in the base product; ADDED indicates that

Name Type Len On Description

:FABMG/RADE TEXT 24 SCTN PANE GENSEC Material Grade

:FABMA/RK TEXT 24 SCTN PANE GENSEC Internal ID

:FABEMA/RK TEXT 24 SCTN PANE GENSEC External UUID

:FABPMARK TEXT 24 SCTN GENSEC PANE Piece Mark

:FABSHPCOD TEXT 30 SCTN GENSEC Profile Shape Code

:FABTYPE TEXT 24 SCTN GENSEC PANE Member Type

:FABBOCPRF TEXT 30 SCTN GENSEC Bocad Profile Type

Name Type Len On Description/default

:FABEF/ID TEXT 80 SITE ZONE STRU 'Engineering Firm Id'

:FABCL/ID TEXT 80 SITE ZONE STRU 'Client Id'

:FABSTI/D TEXT 80 SITE ZONE STRU 'Structure Id'

:FABPR/ID TEXT 80 SITE ZONE STRU 'Project Id'

:FABMO/DNR INT 1 SITE ZONE STRU SCTN

PANE GENSEC

Model Number

:FABDE/CODE TEXT 80 SITE ZONE STRU 'Design Code'

:FABSO/URCE TEXT 64 SITE ZONE STRU Data Source

:FABTA/RGET TEXT 64 SITE ZONE STRU Target Contractor

:FABID/ATE TEXT 30 SITE ZONE STRU Date of Import

:FABIT/IME TEXT 30 SITE ZONE STRU Time of Import

design model but has not returned from the external model. This last case may occur for one of several reasons. The item may not have been exported in the first place; it may have been added after the model was exported or it was deleted by the external system for some reason.

Updating the UDAs

This interface version has some additional UDAs that must be added in Lexicon. Running the interface. Run bocudaupgrade.pmlfnc in Lexicon to install them.

Cross Referencing Models

Cross referencing models is the mechanism by which the user can identify members in different models other than by visual comparison. There are two scenarios: one where an element is created in the base product; the other is where it was created in AVEVA Bocad Steel, but is to be imported into the base product.

Element Created in the Base Product

When an element is created in the base product it gains a unique internal reference number of the form "=<integer>/<integer>", for example: =13/2305. On export from the base product this value, excluding the initial '=' character, will be passed through the UUID fields. AVEVA Bocad Steel will take this value and store it, and use it to allow the user of AVEVA Bocad Steel to identify the original member. On Export back to the base product, for any member which has this UUID attribute set, the original imported UUID will be returned. Thus a user of the base product will be able to spot any changes to the model. The Import system, then allows the user to modify the existing structure, rather than just replacing it with a copy. In this way, any drawings, for example, which may have been produced between Export from and Import back to the base product, will retain their logical relationships to the steel members.

Element Created outside the Base Product

A member created outside the base product will not have the UUID field set to be an internal reference number. The AVEVA Bocad Steel Interface would therefore know that it was importing a new element and would create it accordingly, whilst recording the external UUID as well.

If AVEVA Bocad Steel Interface detects that there are duplicate external UUIDs as it is preparing to export a model, the internal reference number is used in preference. This should give some chance of identifying the element if it returns from the external package. See the section regarding issues concerning entity comparison.

Cross Database Working

The base product has the ability to split the design model across several databases, some of which may be read only.

Exporting the model tries to update certain variables associated with the version management. However, if the database is read only, a macro file is produced that should be executed immediately as soon as the user does have write access to the database.

Important: This must be performed before any import procedure is performed.

might be "updateVersionNos201312593744.mac", which was created at 09:37:44 on 25th January 2013.

Importing an existing, though modified, model is more difficult. Obviously the user must have write access to the database. The reference site is created in the same database as the target area specified on the Import window. This allows new items to be transferred between the reference site and the target site using the INCLUDE command.

The user should make sure that the incoming data is not to be spread across databases.

If the target area is empty the Compare/Merge processes are bypassed which can be a lot faster when importing large amounts of data.

Users of multi-write databases need to be aware that elements that are to be exported must be claimed out prior to export. All elements that are likely to be affected by importing must also be claimed out.

3.3.1 Transfer of Curved Members

New straight linear members may be replaced by GENSECs according to the

!!bocSCTNtoGENSEC flag. Members that are already SCTN elements in the model will not be changed.

Comparing GENSECs is only down to the point count level on the spine. The actual point attributes are not investigated, except for the start and end points. If there are the same numbers of POINSP and CURVE members respectively these are checked. Any alteration to these numbers will indicate changes. They must be inspected visually for comparisons.

The re-imported CURVE element are likely to have changed because we only import 1 type - a THRU point, although there are 6 or 7 different types of CURVE points in the base product, each with different attribute combinations.

Version Numbering

The management of the attributes relevant to version numbering and revision control, that is :FABREVNO, :FABTRANO and :FABTRRVNO, is all performed in the base product user interface. The values of these attributes are not taken from the file. The header is used to transfer the main TransferLetter from the Configuration object, but the individual items are managed as described below.

The Configuration object should not be confused with the Header object. The former is used to store transfer indices - counts of Transfer Numbers and Revision numbers. These are for the whole database. The latter is used to store specific information pertaining to the transfer in question - for example: client information.

Because of the fact that the base product may be multi-user and that several user’s may be concurrently accessing the design databases at any one time, there may be several Configuration objects, one for each possible MDB:User combination. At the start of the Export or Import process, a poll is taken of ALL these Configuration objects to determine which is the highwater mark. That is, which is the highest Transfer Number, or Revision Number. We then take that and modify the Configuration object for the current MDB:User. In this way, by polling all objects, we can determine the latest values.

The rules of precedence for the Transfer and Revision numbers are that a Transfer is higher. So that "A.2" is later than "A.1" and "B.1" is later than "A.9".

Note: The UDA, :FABTRANO, is actually an index into a character string returning the

If there are more than 26 Transfers, the letter is recycled so that there may be slight problems at the wrap around.

Below are the rules by which the revision numbering is handled by the interface.

• Each Transfer has a Letter - A...Z

• Each Revision has a Number - 1,2,3...

• Each SITE, SCTN and PANE has 3 UDAs attached

• A TransferLetter for example: 'C',

• A RevisionNumber for example: '2'

1. A TraRevNumber - A character-wise concatenation of the previous two, for example:

'C.2'

On Transfer into the Base Product

• If an entity (SCTN, GENSEC or PANE) has been changed or is new, set its TransferLetter to be that of the owning SITE and note that there is at least 1 changed item.

• Update the entity's (SCTN, GENSEC or PANE) RevisionNumber to be the incremented value of that of the owning SITE, because we haven't yet changed the latter.

• Increment the SITE's RevisionNumber, for example: '0' to '1' if any imported entities have changed.

Exclusions

This section lists the exclusions which have been identified.

Penetration Holes: The interface does not allow the description of holes within Linear Members.

Templates: Catalogues are not covered by Linear members and Plates contained in Templates or Groups will be transferred on export. There is no facility for constructing a new Template or Group on import. Elements that are in pre-existing Templates or Groups will be compared and merged, but new elements will not be placed in the same container.

Non-prismatic end details: Linear members in the current interface exchange format cannot describe any details at member/cleat ends apart from full orthogonal cuts. Hence, all sloped cuts, notches, etc. will be approximated from minimum to maximum local longitudinal co-ordinate, which should be conservative regarding clash detection. The interface only transfers fully prismatic Plates. Hence, the Plate cuts/intersections which are not fully orthogonal to the Plate's local plane cannot be transferred. Such Plates will be exported 'uncut', which again should be conservative for clash detection.

Issues

The interface allows only for the transfer of a character descriptor for a Profile. For a successful data transfer, there will need to be co-ordination between users of each package to make sure that the geometric description associated with the catalogue name is identical and that there is a means of correlation between the packages.

In the base product, the structural model may contain two views of the data: one view defined by logical connectivity by references to the connecting items; and the physical view defined by the relative location of items. So, while we may logically relate two items, they may not necessarily be physically close to each other. Thus, transferring the model will

The interface will output a warning message when sections are met which cannot be handled or are unexpected.

The double quote character “ in text fields, particularly in profile names is not allowed. This can cause problems with imperial sized items in the catalogue that use the character to indicate inches. It is not allowed in ANY text fields.

Units

This is a statement of how the interface handles units.

1. has a minimal set of unit definitions. ("feet", "meters", "inches","millimeters") 2. exports in mm, that is the units exported in the file are mm.

3. imports all units from internally. It reads any file unit (according to the "standard"), but...

4. the interface then converts the input units to mm prior to writing an input "macro", so the model in the ABS file is therefore in mm.

5. To support this, the interface environment, switches units to MM DIST, and UNITS DEGREES units prior to export and import.

6. Because of the way the interface handles UNITS, the original units cannot be restored to be precisely what they were before.

7. Therefore, after an export or import transaction, the units will be set to MM DIST/MM BORE/UNITS DEGREES.

The AVEVA Bocad Steel Interface attempts to keep the behaviour of the system as consistent as possible across versions of the base product. Holes are always imported as NXTR elements because the interface does not do any shape recognition. This highlights a possible issue in exporting a model and re-importing. While a secondary PLOO would represent a hole, this would have to be represented on import as a negative extrusion, NXTR. So round tripping data will cause secondary PLOO elements as well as other negative primitives, to be converted to NXTR elements.

When importing into an empty area and using the "Import linear members as GENSECs"

option, straight members may not be converted to GENSECS. This often occurs with a file that was previously exported from another base product model. The UUID attribute on the imported element may refer to an element with the same database reference number in the current model. Do not use the option to convert all straight members into GENSECs when importing a file containing elements that originated in the base product.

3.3.2 Stairs, Ladders and Handrailing

Certain components of Stairs, Ladders and Handrailing (SLH) will be transferred in the application. These are the GENSEC, SCTN, PANE, RAIL and KICKPL. Any of these elements that are directly or indirectly referenced, such as in templates, will be transferred.

However, catalogue components themselves will not be transferred. Further, certain advanced detailing features of the handrailing, such as gaps might not be transferred.

Because of the nature of SLH, round-tripping of the data is difficult as it is challenging to reconstruct the complex data structures.

In detail, the treatment of SLH is as follows:

ABSI Export of SLH - Stairs Ladders & Handrail

• Only valid in AVEVA E3D™ (Not AVEVA 12 Series)

• Catalogue based components will not be exported (For example: A Catalogue based Post, or Rung or Tread and so on).

Stairs:

• Stringers, Treads, and Extensions (STRSTR, TREAD, TOPEXT, BOTEXT) - Can contain GENSEC and PANEL elements / Templates (TMPL). All GENSEC and PANEL elements will be exported as any other Curved Linear Member or Planar Member.

Ladders:

• Rungs, Stiles, Hoops, Cage Bars, Gates (LDRRNG, LDRSTR, HOOPSE, RLCAGE, RLGATE) - Can contain GENSEC and PANEL elements / Templates (TMPL). All GENSEC and PANEL elements will be exported as any other Curved Linear Member or Planar Member.

Handrails:

• Rails (RAIL) - exported as Curved Linear Members

• Kick Plates (KICKPL) - exported as Curved Linear Members

• Posts, Panels, Gates and Terminations (HRPOST, HRPANE, HRGATE, HRTERM) -Can contain GENSEC and PANEL elements / Templates (TMPL). All GENSEC and PANEL elements will be exported as any other Curved Linear Member or Planar Member.

In document BOCAD Steel Interface (Page 50-59)

Related documents