Plant 3D Fasteners

[Phil-22]

Good afternoon,

I have been able to create a new fastener in Plant 3D. But, I am trying to restructure some fasteners to have a common BaseTable so that common joints have common properties without needless repetition for each fastener. For example, a socket-welded joint may have common properties with a back-welded threaded joint, as would buttweld, as would stub-in, etc.. The objective is to use the new common table in the isometric configuration so that the Weld table gets properties/values from the common table, rather than specifically Buttweld, Socketweld, etc..

I have created a table "GeneralWeld" under "Fasteners". Under this, I have created my new Fastener "BackweldedThread", and have moved "Socketweld" under this base table while I test. The BackweldedThread is configured to be available for threaded connections, and when a substitution is done in the model for a threaded connector - it works. I have updated the properties of the new fastener, and can see that the values are saved successfully, and the values appear correctly on-screen.

Through this though, I have the following issues:

 - I have checked the configuration several times, and while socketweld looks the same, and it saves data to the correct tables in the database, the values on-screen do not reflect what is in the database. For example I update custom WPS number with a value, save the model, see the saved value in the database, but on-screen I see the default empty-string.

 - The two fasteners (BackweldedThread & Socketweld) while under "GeneralWeld" are not visible as a Fastener when configuring Piping Connection Settings. I do see the GeneralWeld, but not the children.

What I am trying to do simply may not work. Hoping somebody else has experience in this area and may advise. The database seems to support the structure(s) - but it may be limited by front-end capabilities.

If this approach does not work, and I have a property WPSNo specified under each welded fastener, is it enough to specify only the property name in the HeaderRefName of the ColumnMapping under a TableScheme in the IsoConfig?

Thanks in advance,

Phil

[h_eger]

Dear @Phil-22 ,

Just a quick question: Why is it NOT possible to create new classes via the project setup under Plant 3D DWG settings?

Just because you create it in the database does not work in Plant 3D!
This rule is for safety so that the way Plant 3D works is not corrupted.

[Phil-22]

Quick question: Where do you think data of this nature is going to be stored in an environment which supports multiple users ? If not in the database - it'll be in xml or similar source which multiple users may access simultaneously.

Don't reply for the sake of replying, or to be demeaning to somebody which today may not know the software as YOU do. I have found other curious limitations of the software, as well as opportunities, and when I see that Single Branch Fitting under Pipe Run Component supports children - it's not illogical to question whether a continuation of a hierarchy under Fasteners too may be possible. If what I'm wanting to achieve is not possible - so be it. You could have offered your "expertise" on my question on the IsoConfig as to whether the table name is actually required in specifying properties. But I'll not waste your time on that. I'll test a little myself, or wait for a potential reply from somebody else. If the fastener hierarchy cannot be expanded the solution seems pretty evident.

As for "safety" or stability of the software - my testing is done in a sandbox. While I may be newer to THIS software - it's not my first rodeo.

Cheers.

[h_eger]

I do not want to discredit you in any way, I'm sorry if you felt offended by my answer, this is in no way my intention on this forum.

Good luck for the future.

[Phil-22 · Accepted solution]

Fair. Accepted. If I over-reacted I too apologize. It was the red-font, exclamation mark, and comment on safety and corruption of the software which gave me a “who’re you” reaction while not offering constructive feedback.

Full-disclosure – it was an Autodesk post which put me onto creating the class definition in the database.

Creating a New Threaded Seal Weld Fastener in Plant 3D | Search | Autodesk Knowledge Network

After another test, the matter seems to have resolved itself. I added a property to the Socketweld class, saved, deleted the property, saved, and it now saves and returns data correctly for the class and joint. Only thing I can chalk this up to is how the underlying query was compiled.

The Fasteners class hierarchy MAY be expanded beyond one-level. Classes deeper than the first level unfortunately are not able to be seen in the Modify Joint dialog under Fasteners. The Modify Joint dialog saves its information in the DefaultConnectorsConfig.xml file. Fastener classes may be manually specified in this file under the appropriate joint definition. Plant 3D reads this configuration file sequentially. Changing the sequence of joints in this file impacts both the order of joints in the Joint Setup dialog (which is not available through the UI), as well as the sequence if multiple joint options exist for a particular connection (which is not available through the UI). So if a threaded connection may allow either a threaded joint, or a back-welded joint, the sequence in the configuration file can establish a default joint (first being default).

Cheers

[George.Endrulat]

I know it's a big ask, but can you do a quick tutorial here about it with inserted images?  I think it would help a lot of people, myself included, you seem to have quite a good handle on all of this.

[Phil-22 · Accepted solution]

The objective of this configuration was to simply the data management and reporting capability from the Plant 3D system. There are a number of joints we wish to be able to specify on our drawings which are not part of the out-of-box configuration. These include tack-weld, back-welded thread, integrally reinforced joint, etc.

The initial basis for the inclusion of new fasteners was based on Autodesk documentation. Following the instruction, it would require creating the new fasteners and adding properties to each specific fastener individually where appropriate. If, for example, you wish to add the WPS to each welded joint, a property would have to be added to each fastener used in welded joints. Each repetition creates opportunity for a typographical error, but also creates the matter that similar information in the underlying database is distributed through numerous tables. Updating a parent class simplifies the administrator’s work.

Similar to the Elbow class, or Single Branch Fitting class – it was suspected an opportunity may exist in Fasteners to better organize information.

On evaluation of the underlying database structures, and opportunity to simplify data was recognized, and through testing, found to largely function within the Plant 3D environment. Recognized limitations will be highlighted below.

Understanding of what follows will require that an admin understand SQL at least to a most basic level. The basis of evaluation was the Buttweld fastener.

The work to be done is in the Piping database. Depending on your project configuration, this will be either the Piping.dcf SQLite database, or [Project Name]_Piping database if using SQL Server. I have our setup using SQL Server to allow extended capabilities. The principles are the same, but some SQL syntax may differ slightly (SQLite requires more text in statements than SQL Server).

Inside the Piping database is a Buttweld table. Plant 3D understands that this table exists and understands how to interact with this table through a configuration within the Piping database. The primary database tables involved are PnPTables, PnPProperties, PnPTableAttributes, and PnPColumnAttributes.

NOTE: I had already added properties to the Buttweld class, so my content may differ from yours, but the instructions below will still apply.

If a SELECT is done from the PnPTables table based on TableName=’Buttweld’ we will see the following:

This exposes that the Buttweld table has a base table of “Fasteners”. A Fasteners table also exists in the Piping database, and If a SELECT is done from PnPTables based on TableName=’Fasteners’ we will see the following:

This exposes that Fasteners is child to EngineeringItems, which coincides with another table in the database, and if you consider the progression through the Classes exposed in Project Manager, a trend is exposed that these tables form the same hierarchal relationship seen in Project Manager.

Now, if we dig deeper into Buttweld, if we SELECT from the above noted tables based on TableName=’Buttweld’ the following content may be seen:

If the table columns are expanded under Buttweld, you should see that the columns of the table match the entries of PnPProperties.

Autodesk is likely using these to configure/manage the underlying datatable used in the Project Manager interface. What is important to take from this is that these entries correlate with the fields in the database table, and also with the specific properties added to the Buttweld class. If a similar query is performed where TableName=’Fasteners’, you should see a similar result; a database table having columns matching the entries in the PnPProperties content and matching the properties added to the Fasteners class in P3D.

I have not dug into the PnPTableAttributes. I found only that the entry exists, and also correlates with the value shown in Buttweld class (see above image at the bottom). Notably, the ‘Nonspec’ value coincides with fasteners which are not spec-driven. If you look at the Gasket class, for example, the value for FastenerType is “Spec”. This recognition creates opportunity for further expansion of Fastener option, but is beyond the scope of this instruction.

Now looking at the content of the PnPColumnAttributes database table, we can see that the entries display the values assigned from Project Manager; where a value is specified for each column in the interface, for each property added to the class.

To summarize all that has been covered, a hierarchal relationship exists in the Piping database allowing inheritance of properties from parent class to child class, and the database contains additional tables which define the properties and their respective formats and values.

Going back to the objective, I am wanting to ensure that all welded joints have the same welding considerations. To achieve this, each welded fastener class would need the same properties. As I am lazy, I do not wish to add the properties to each existing and new class I will have in the project.

To achieve the result, I first created the necessary entries in the above noted tables based on Buttweld. Notice where I overwrote Buttweld with GeneralWeld.

NOTE: the INSERT lines are commented out so that I may display what was inserted without compromising my own environment.

After the content had been added to the necessary tables, I created the actual database table GeneralWeld, and corresponding view GeneralWeld_PnP

Notice in the below image how the hierarchal cascading of properties is facilitated.

At this stage, if Plant 3D is restarted, the newly defined GeneralWeld class should be visible. Noted I am able to expand mine as I have already created sub-classes under this parent.

Following the same steps already noted above, I created a sub-class BackweldThread under the newly created parent class of GeneralWeld. Note in the following images that I have only carried the PnPID in the child class definition. The queries are of a similar nature; but not exactly the same as in the above instruction.

On restarting Plant, and opening Project Manager, the newly created class should be visible.

Now that the new class is available, we have to have Plant 3D understand where it may be used. To achieve this, I created a new Joint definition. It is likely a result of how the interface is programmed, but the newly created BackweldThread class cannot be see in the Fasteners list at the bottom of the form. But, the GeneralWeld is. When creating your joint select the GeneralWeld option, and we will update this in the following steps.

Plant 3D stores the joint definitions in an XML file saved in the project directory named DefaultConnectorsConfig.xml. Open this file and quickly examine the contents if you’re unfamiliar with it. Below is an image from my configuration with the joint definitions collapsed. Note my sequence may not match yours as I have already done some configuration. An important note at this point is that the sequence of the joints in this file will match the sequence in which the joints are listed in Project Manager. This sequence is also impacting the order (and default) of joints applied by Plant 3D when establishing a connection between components.

Below is my updated BackweldThread joint definition. Under the JointElement tag your file will likely have a value of GeneralWeld at this time. Update this value to the name of your new class. In my case it was BackweldThread. After this update, Plant 3D will have to be restarted.

In my configuration this new joint was to serve as a default for our threaded connections. Now when I select a threaded joint and expand the Substitute Part flag, I can see the new joint option.

Hopefully this instruction is helpful. If something is not clear – please let me know.

Cheers,

Phil

[George.Endrulat]

@Phil-22Wow. That's the kind of post on here that keeps me coming back and participating.  Thank you.