In Reply to Gregory PERASSO:
Hi
really depending on your CAD design/assembly methodology. And proE have a lot of"strange" behaviours about asm refesh. Even if the component modification does not impact position, or other relationship in the context of the asm
Something to be aware, and whatever is you CAD tool, is that you have to adapt your methodology (notably assembly strategies, or cross references between CADstructure branch)if you want to work with a CAD structure and a BOM integrated (ie owner link)in PDMLink. You're not "alone"in the design departement as it was for intralink ...
Revising parts in BOM and level where you propagate it, is a pure BOM management action. (interchangeability, tracking serial numbered part ...). It should not be drived by a CAD constraint. (example because a dimensionis drived by a relation ...)
but as says at the begining, ProE is not robust about it (lot of cases , notably if you create cut views in a asm), even if components are totaly design without cross references.
regards
Gregory,
Thank you for the response. Rest assured we are no strangers to Enterprise Change, and our Engineering groups are used to their changes being a global event. The issue we are struggling with is the “used by” driven need to regenerate all assemblies when a Pro E component is updated in a way that does not impact its geometry or any assembly relations. Perhaps the best/worst example of this would be an update to a library part that only changes its colour. Having to “change” the assemblies for that would be a lot of unnecessary overhead.
I am surprised there doesn’t appear to be any kind of administrative mechanism for updating all the assemblies that use a component en-masse in the event of a trivial change. Given that any representations of the assemblies are flagged out of date when a component changes, and if they are updated the new representations show the updates. It seems like something could be done fairly “cheaply” server side during that process to iterate and update the assemblies.
Another less automatic process might be something like a “zero track” iterative change, launched automatically against the assemblies to temporarily change their state allowing a user to edit them. But having a user checkout, download, regenerate and check in the assemblies is not a lot of value-add for the time spent. You also run the risk that the user would make other edits during that process outside of the scope of the original change.
I am guessing that most PTC customers either live with out of date assemblies until they need updated themselves, or include the assemblies on the change with the component.
Does anyone have another approach?
-----
Lewis
