Recently, I had a customer point out to me that when they replaced a component (let's say it was pipe) in their piping spec with an identical catalog item (same descriptions, schedule, etc.) and then ran an isometric, the bill of materials would separate out the new spec items rather than consolidate them together into one row.
This is what they expected to see on their isometric:
This is what they got instead:
You can see that instead of all of the 4" SCH 40 pipe consolidating into a single row, they were getting two rows. One row represented the pipe that was in the model before the spec update and the other line represents the pipe that was added to the model after the spec was updated from the catalog.
The first place to look for how an isometric style is configured is in the Project Setup, however some configuration items like this are buried deeper. The key to finding out what was happening required editing the IsoConfig.xml file located in the isometric style folder (e.g. C:\Project ABC\Isometric\Final_ANSI-B). I used firstobject's XML editor (www.firstobject.com) to open this file, and looked at the contents under Data>AggregatedLists>AggregatedList=Materials to see the list of columns used to group rows by:
For the record, the aggregated list named "Materials" holds the definition for bills of materials (hereafter called BOM, because I'm a lazy typist) where the shop and field items are not segregated, such as out of the box configurations like Final_ANSI-B. The various component groups are listed under it, such as "PIPE". Since the customer's issue was related to pipe components, I thought I would start there.
I saw that three "columns" are used to determine whether items consolidate together in the BOM: Category, Code and Description. These are virtual columns of data, that is, they don't necessarily have to appear in the BOM but can still be used to determine how things appears. This is what frustrated the customer, since it was not obvious from the isometric output what was causing the seemingly identical items to not consolidate together. I knew that the Category (shop vs. field) of the pipe was the same and so was the Description of both pipes. Therefore, I assumed that it must be the Code column which was causing the behavior and by commenting out this line in the xml file I proved my theory.
So what is "Code" and where is it defined? It turns out that the answer is found by looking at the PCF file in the \PCFs folder under the isometric style. I opened the file in Notepad and saw that my two pipe components had different ITEM-CODE values:
I recognized the first part of ITEM-CODE as being the name of the piping spec but didn't know where the numeric suffix came from. It turns out that the answer is simple: since my spec didn't have values for Item Code (shown in the Spec Editor Edit Parts dialog below) the software attempted to generate a unique code using the spec name and the unique ID (referred to as a PnPID) of the part in the spec:
When the customer had erased and replaced the pipe in his spec, he inadvertently generated a new PnPID for the parts that were added back into the spec, and hence subsequently placed in the model. This is one reason why I recommend customers don't erase items from Plant 3D specs while in the middle of a project. I know this sounds like an unreasonable statement but, believe me, there is a completely reasonable workflow that supports this that I will include in my Autodesk University class this year. (If you don't plan on attending AU 2015 you might see me post a link to the class here in the blog after December…maybe ;p). For now you will have to take my word on this or comment below if you'd like more details.
So, how did we fix this? I recommended to this customer – since they did not use unique item codes - to replace "Code" in the IsoConfig.xml file with another property besides Description to help consolidate parts correctly. In this case "Size" worked well and he did this in the PIPE group as well as other groups which where under the AggregatedList=Materials section of the file.
I hope this helps understand a little more about how Plant 3D isometric bills of materials are generated. I also hope to see you at Autodesk University in Las Vegas this December!
(0)