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

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

   

2. Select Define Rules to 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

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

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