Version: Windchill 13.0
Use Case:
1. My client makes use of "Part" objects.
2. They have a need to represent instances of these "Parts" as instances in parent objects.
3. For example, my customer makes use of "Parent Part 1" and "Parent Part 2". "Child Part 1" is used in both parent parts.
4. My customer has a requirement to make use of objects in Windchill to represent the different instances of the child part referenced by the two parent parts.
5. These instances should be uniquely identified by serial numbers.
6. It is important that the objects being used to represent the child part instances represent the form of the child part at a certain revision.
7. It is not acceptable for the objects being used to represent the child part instances to simply represent the part master and not a specific revision of the part.
It was previously suggested to me that making use of "Part Configurations" and "Part Instance" objects in Windchill is often not the best way to approach management of serialised parts in Windchill. My understanding as to why this is the case is summarised below: If the form of a child part instance changes, then a new child part configuration will have to be created and associated to a new version of the child part instance. Since the child part instance would often have a parent instance/s, a new version of the parent instance/s will have to be created to include the newer version of the child instance which contains the latest part configuration. Following this approach will involve creating a new child part instance, a new child part configuration, a new parent part configuration and a new parent part instance. In situations whereby there are many layers of assemblies contained within an assembly structure, the process of performing an update to the configuration of a part instance could be extremely extensive. This is because of the knock-on effect that would occur to all the parents of the part instance, at different levels in the assembly structure, that would also now need to be updated to make use of a new part configuration.
To avoid this issue, the approach below was recommended to me:
Instances of a part can be represented in a BOM as a sub-type of a part object. These types of part instances can be made a parent of the part object which they are being used to represent. I can assign a value to an attribute of the part instances to represent its serial number ID. Should the configuration of the part (that the part instance is representing) change, I would have to create a new version of the child part. The newer version of the child part would automatically be reflected in the structure of the part instance without a new version of the part instance being created. Consequently, this would also mean that no new versions of any parents of the part instance would be created either.
Description:
The problem I am experiencing with this approach is that the object I am using to represent instances of a part doesn't seem to be exclusive to the revision of the part it is representing. When the part (that the part instance object is representing) is updated to a newer revision, this is being reflected in the structure of the part instance. Using an example, I can create a part in Windchill called "1234". I can then create another part in Windchill called "5678" to act as a part instance of "1234". "5678" arrives in Windchill at revision "A". To show the relationship between the part and the part instance, I can include "1234" as a child in the structure of "5678". Currently, there is only one revision of "1234" in Windchill and this is "1234,A". Consequently, the revision of the child part displayed in the structure of "5678,A" is "1234,A" If I create "1234,B" and then return to the structure of "5678,A", I can see that the structure has automatically updated to include "1234,B". "1234,A" no longer exists in the structure, even though "5678,A" was created to represent an instance of "1234,A" and not "1234,B". The functionality observed here means that, using this approach, we cannot keep control over the revision of a part that features as a child of another part. Therefore, the approach does not allow us to accurately reflect the form of part instances used in parent assemblies.
In summary, it seems that we could use "Part Configuration" objects in conjunction with "Part Instance" objects to accurately control the configuration of instances of parts in Windchill. However, this could result in lots of work if the configuration of a low-level part instance in an assembly structure needs to be updated. This is because of all the resulting updates that would have to be made to all of the higher-level part instances in the structure required to represent the newer configurations of the child part instances. To resolve this, I could use the other approach that I have detailed towards managing part instances. But this will not allow me to keep good control over the configuration of part instances used in parent assemblies.
