Civil 3D – Part Builder Context Solution Part 2

Part Builder Context Solution Part 1

Ok, at last, the end of the journey.  We covered getting the model values out of an existing part.  The remaining issue lies with what to do now that we have a mandatory context added to the structure type.  Each time we create a new form of that structure type, that variable will be added to the Part XML file with all the other OEM required variables, such as "SHBTh".  This would not be a problem except that we still cannot get our non-OEM variables forced into the part model parameters.

As you may recall from earlier discussions, adding an existing catalog parameter to the model parameters is verboten.  Consequently without some assistance, each new part would require yet another context parameter to be created in the list.  Eventually the list of copies of the same variables would be ridiculous.

What we did figure out is that we can link a required context parameter that is created in the part XML, to a parameter we used in the model parameters. 

The basic outline is as follows:

• Create the new part, using the proper structure type. 
• Validate the part and save it.
• Create the model to its completion, adding any model parameters as needed.
• Configure the Required Context Parameter to be a range or a list as desired.
• Save the part and exit.
• Edit the Part XML, and change the MODEL parameter’s equation to equal the Required Context Parameter.
• Save the file and perform a catalog regen, and a catalog validation.
• Check the part validation file to confirm all is well.  If it says there is a duplicate parameter, return to the Part XML, find the parameter definition that is a duplicate, and delete it so that only one parameter definition remains

Civil 3D – XML Pipe Import Parts Catalog problem

Pipe Networks and the beloved XML has once again bit someone in the fanny.  This time it is the ‘Can’t Swap Part’ on imported pipe networks.

Here’s the deal.  Among all the interesting stuff an XML file will bring in for you, it won’t bring in the Parts List name.  It contains the Material and size of the part as well as the name, just not the Parts List.  I suspect this is good, considering you may not have that named List, but this still leaves us with pipes that have to be swapped.

It seems as though the Network adopts the creation aspects of the commands settings.  The network is created, and then handed the parts to complete the pipe network.  When it does, it sets them by the information in the XML.  The size is correct, but the XML has no idea what to tell your application about what these should look like, other than diameter. 

The application responds with it’s defaults.  If you have no default Parts List set, then the parts list comes in NULL. Notice the example below.