Technical Information

Bocad Steel Interface

Bocad Steel Interface : Export/Import : Technical Information

This section contains technical information which is not immediately specific to Products but of which you 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). It will cause minor problems in model versioning and comparisons.

Default Orientations

There is a neutral 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.

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


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

Project Data


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

:FABEXCLUDE is a flag you can set on the items indicated. It is using this flag that you 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 you 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 the item has been added to the model externally, by Merging; CHANGED means that the item has been modified externally; and DELETED means that the item was in the original 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 you 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 you 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 you have write access to the database.

Important:

This must be performed before any further import procedures are performed.

The file name is built upon the string "updateVersionNos" but with time stamp information attached so that they can be executed in chronological sequence. An example file name 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 you 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.

You 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.