Civil 3D – Part Builder Context Solution Part 1

I stated previously that David Neill gave me an idea.  A simple switch that had not been useful previously.  The problem was that I had just not returned to it after so many new ideas.  Thanks David!!  I guess collaboration works huh.

It took a while.  I had beaten this up over and over.  I did not want to rerun it all.  Through the frustration, I just kept thinking there is no way David is crazy.  Eventually, I got the combination right. 

This article proceeds with the premise that everyone is familiar with part builder to some degree, and has an existing part that needs to be made variable.  If not, I have a load of info already to use to catch up.

I did say multi part.  Don’t worry, there are only 2 parts.  The first is what David ad I worked to beat, and the second is when that wasn’t good enough for me.

Part 1 – Getting our existing Parameters into  structure that allows later adjustments.

Part 2 – Getting the Catalog require parameters BACK INTO the model.

I have rewritten this 3 times.  Please forgive me if it is a bit shabby.  It is all starting to run together now.

The old problem

We have been fighting an old issue of customizable parameters.  We can make he basic parameters such a height, width, etc. adjustable in the Civil 3D environment, but not specific feature parameters that we need.  Say like the angle of a structure slope.  After working so hard on a structure, who wants to be stuck with a limitation.  David and I did get some ranges and lists to come through, but we couldn’t do it on a consistent basis…until now.

I will go through and identify the major portions of this adjustment.  As I do I will discuss the issues, and explain the edits.  We will be changing things as we go.  This is not a tutorial, but more of an explanation, and a few warnings that have not been made clear elsewhere.

We will focus on the following:

• Some basic information about the Catalog
• Getting into the Part Builder Catalog in 2010
• The Custom Switch
• The Model Variables
• The Context
• The Named Parameter
• The thing that hides Successes and Failures the most
• Validation

Some Basic information about the Catalog

Here is a little flow chart to use to kind of understand the mechanics we will be toying with.  This list is not complete, and the actual application check order may be out a bit, but the general idea is all you need to understand.

To the left is the Vista file explorer tree for the Part Catalogs, in the middle is the Files and feature we need will be toying with, and to the right is a basic description.  These paths are provided below so that you can copy paste into explorer if you need.  I did a few times myself.

The Catalog path – C:\ProgramData\Autodesk\C3D 2010\enu\Pipes Catalog\US Imperial Structures\

Our previous ‘Custom Library’ path – C:\ProgramData\Autodesk\C3D 2010\enu\Pipes Catalog\US Imperial Structures\Inlet-Outlets-Custom

The Catalog Shared content – C:\ProgramData\Autodesk\C3D 2010\enu\Pipes Catalog\Aecc Shared Content

The Validation results – C:\ProgramData\Autodesk\C3D 2010\enu\Pipes Catalog\US Imperial Structures\Validate

Now lets talk about the structure catalog. The catalog stores all the data about the Structure, including the model parameters, Parameter Contexts, Structure types, etc.  It keeps them together in XML files linked together.  A list of structures is in there, and links to its specific XML file.  That file contains all the parameter configurations, including what variables may be adjusted.  We can call all that the structure part of the catalog.

The Catalog is also responsible for creating new parts.  Through a hierarchy of ‘Inheritance’, the new part is prepared based on the structure type you wish to create.  Various parameters are included in the part.  We call these the REQUIRED parameters, because the catalog will not budge without these being in the XML file.  You don’t have to use them, but they must be there.  The configured Parameters file in the Shared Content folder keeps track of what must go with what.  It uses Contexts to keep track of it all.  We can call this the Context part of the Catalog.

In order to get the Part changes to be recognized by the catalog, it needs to be validated.  The Catalog reads each part XML file in the structure part, and QA’s those against the rules in the Context part.  Just in case someone has been monkeying around.  Now who would do that?  The results of this are published to the validation folder, and we can call this the Validation part of the Catalog.

Once the Part model is saved and closed, the catalog does not refer back to the DWG for anything. Why should it?  It has the Part XML which contains all the configurations anyway.

There has been no way to simply make a parameter you made, become available at he Pipe Network, of the Parts List.  The reason is it’s not part of the rules.  We are going to show you how to make it a ‘part of the family’.  Keep in mind, by the end you will see it is only a step-child, and not really  part of the family.  In Part 2 I will show you how to overcome the ‘step-child’ issues.

There is some other monkey business in there, but we don’t really need to know about that. 

Getting into the Part Builder Catalog in 2010

If you are unaware of how to navigate to Part Builder in 2010, just go through Modify the Pipe Network…Pick the Modify tab on he Ribbon, and pick Pipe Network from the Design Panel. 

The Custom Switch

The custom switch lies in the Part Builder environment.  Having this switched on allows the parameters in the model be connected with parameters that are added to the Catalog process.  Open your customized part file, and switch this on.  Save the File.

The Model Variables

The part model we are designing has parameters (variables) right?  Dimensions and the like.  These are basically in the DWG file.  We get at those in the Model Parameters list.  There we equate things like bAng = SWAng.  A few of these need to be configured as lists and ranges. 

Soooo, we go to the Size Parameters, and Edit configurations.  This area shows us how the model parameters will be configured for use.  Variables can be turned into lists and ranges.  Then all the parameters, no matter how configured, are then saved to the Part XML file and become part of the Catalog.  Later this XML information is passed on to the Parts List.  We all know this never works the way we want.

In the example above you can see the model parameters in a part I was playing with recently.  The wingwall has a variable wall angle, bAng.  bAng was then controlled by a parameter ‘SWAng’ that has been configured as a Range, and will be passed on the the Parts List. 

We had done this numerous times with ‘SHBW” and the like as you may recall.  This was easy because ‘SHBW’ was a Catalog Required parameter, nd as such received all the privileges of the family.  We want to know about the non-Catalog parameters.  That is where the switch and contexts come in….

The Contexts

The Contexts are the nuts and bolts of this operation, and essentially where we left off last time.  Contexts are parameter categories in the Contexts part of the Catalog that are used to keep everything in order.  No recognized variable context – No work!

The Contexts are created in the AeccPartParamCfg.xml file (the Configured Parameters file). Open this file using the paths I provided above, and a text editor.  Don’t be intimidated by the amount of data here.  As we scroll down the list, you should notice the file broken down into sections:

AeccParamDeclaration  (parameters are prepared here)

• AeccDfSortGroup name="Part Properties"
• AeccDfSortGroup name="Geometry"
• AeccDfSortGroup name="Catalog Entry"
• AeccDfSortGroup name="Catalog Entry"
• AeccDfSortGroup name="Misc"

AeccParamUsage  (contexts are prepared here)

• AeccPartDomainCfg domain="Pipe_Domain"
• AeccPartDomainCfg domain="Structure_Domain
  • AeccPartTypeCfg type="Struct_Junction"
  • AeccPartTypeCfg type="Struct_InletOutlet"
  • AeccPartTypeCfg type="Struct_General"

It is not important to understand all the ins and outs here.  What is important to know is that we need a defined context, and a variable to assign THROUGH that context.  The contexts are defined in the Parameter Usage section, under AeccPartTypeCfg.  Scroll to the bottom of the file, and find the area shown in the image below.  The only difference in your file and the image is the 2 parameters near the Highlight.  The remaining strings should be identical.

 

The contexts are defined with 2 types of Keywords.  Required and Optional.  This can be seen in the following 2 examples:

<AeccReqParam context="StructHwBaseThickness"/>

<!–AeccOptParam context="StructApnLength"/—>

In the image above, the "StructHwBaseThickness" parameter is REQUIRED to be included in any Part file that is an InletOutlet type.  We used it in the Part Builder Series.  Any variables we add here with the Required definition MUST be included in any new and validated Part XML files.  It will also allow proper evaluation of current files with this context.

The Optional ones are parameters like Material.  You see these in every part file, and we can edit this any way we like.  The trick is if we use the Optional definition, EVERY Inlet Outlet structure in the Part List will get this variable (even if there is no use for it).  This can get pretty annoying.

I have added 2 contexts while testing this.  The Required “StructWngAngle” and the Optional “StructHwTopSlope”.  The TopSlope parameter was used to work out the bugs in our part builder series.  The Highlighted one is for the new test with angled wing walls.

Create a new line just below the line that reads: “<AeccReqParam context="StructHwBaseThickness"/>”

Now add this string:

<AeccReqParam context="StructWngAngle"/>

Now that we have defined a new Context, we need to indicate which parameter will fall in this Context. Scroll up to the top, and find the parameter we used in the Part Builder series.  ‘SHBTh’.  Use the image below for a reference.

You may remember this one from our tutorial.  ‘SHBTh’. Above we used its Context definition as an example, and here we can see the parameter being defined in under that context.  This is it’s birthright.

What say we do a little forgery, and get our parameter some papers.  Scroll down the list to the end of these parameters, but not out of the sort group.  Add the following line:

<AeccDfParameter name="SWAng" desc="Wing Angle" context="StructWngAngle" index="0" datatype="Float" usage="Double_General" unit="" visible="True" internal="True"/>

Now we have defined our parameter to be used in our custom context.  Copy the exact context name. We will be using it in the next step.  Save the file and exit.

The Named Parameter

We’re not done with the text editing yet.  More XML fun to come.  Navigate to the Custom Structure folder containing the part file, and open its XML file.  Mine for example was in the …Pipes Catalog\US Imperial Structures\Inlet-Outlets-Custom\ folder.

Inside you will see the parameter that we needed ranged (or listed) up at the top.

Find the part of the string that composes context.  I suspect it is a generic context.  Change this to be EXACTLY what we added our optional context list.  Ensure the index is set to ‘0’, and visible is set to ‘1’.

Save the file and exit.

The thing that hides Successes and Failures the most

Before we can go further, we need to do something very important.  If you have gone ahead without this step, start over.  Exit out of Civil 3D completely.  We can use every tool to force the catalog to acknowledge us, but the Catalog will not hand the CONTEXTS to the parts list until we restart Civil.  Civil reads the contexts and parameters when it starts.  Don’t believe me, try shoving in something out of whack and see if it doesn’t flag as soon as you start Civil.

Validation

Open the Part Builder Catalog, and select the US Imperial Structure Catalog header.  Pick ‘Catalog Regen’.  The catalog will evaluate all the parts coming into it.  Then pick ‘Validate’, and the Catalog will evaluate all the data attached to itself and spit out the results to the validate folder.

Navigate to the structure validation path.  First open the Catalog_Regen_Summary.txt file.

Your structure should be OK!

Next, open the validation report for your structure. 

The part should have validated ok.  If so, you’re doing fine.

Create the network

Now go to the parts list; A Fresh Parts List, not one that had the old stuff in it.  Add the family and then add a size.  Create a network with you new Part.  Edit the properties.  Make sure the style shows the 3D solid.

Now we have no problem changing the wall angle in the part.

Notes and Reminders

When creating a new structure, the CUSTOM required context definitions will be added to the Part XML.  They will not be added to the Part DWG and the model dimensions.  The result is that Civil says ‘”the CUSTOM dimension exists in the configured XML, so it must exist in the model”.  But it doesn’t.  So when you go to add the CUSTOM parameter from the Required context, and place it into the model, Civil balks and says ’Hey, that already exists!”

So you cannot use it.  All the discussions David and I have had rests on the premise that your are getting an EXISTING model parameter out TO the Catalog, not the other way around. 

Part 2 is all about beating this final problem.  Now, no problem.

Using the Optional Parameter Definition will have your parameter in EVERY one of the Parts in the Part List for that structure type.  You can play with this a bit, but it may become frustrating.

Backup your catalog.  I usually back up the entire structure.  It has saved me in he past, and if you pursue this, it will eventually save you.

That’s it folks.  Those cool parts you wanted variable, well you got it.  Please take the time to thank David Neill who got me back into this, and then helped me get through it.