Hi All,
This is in part a philosophical question and in part looking for advice from people who have implemented the Mechanical CAD Connectors with Innovator.
Before anything else I will say that I appreciate the physical part should not, in ideal circumstances, have a part revision stamped or otherwise identified on it. That is not how certain parts of the organisation see things.
As an organisation we have for many years directly linked our physical part revisions to the Mechanical CAD Model revisions. Physical parts will often have a revision identified on them and this revision directly relates to the CAD model data revision.
Now we are live with Innovator and about to start implementing the CAD connectors. This brings to a head a change that the organisation did not really appreciate until very recently. The Innovator Part Data (which I will refer to as the Part Metadata), Document Data and CAD Document data are all independent entities that can change their revisions independently and in some cases dependently.
This leads to the very real situation where, if you identify the part revision on a physical part, you have to ask which revision should be on the physical part.
Should it be the CAD model revision which fundamentally is the primary data telling you how to build a "thing" and only changes when it has to or should it be the Part Metadata revision that changes when any related Document or CAD Document changes?
I'm looking for input where possible from people who have encountered this themselves to find out how other organisations deal with this.
Thanks,
Brian.
Hi Brian,
It seems that you know this, but I'll underscore that doing things this way isn't a good idea, and is totally counter to typical BOM management practices and ASME Y14.100 / ASME Y14.35. But with that disclaimer...
In the past, I worked in an organization that had a similar practice to yours. I was told that the constraints of the MRP system required that all Drawings, CAD Models, and the Part record itself have matching revision levels. We were using Enovia but I believe that the philosophical nature of your question makes the particular PLM solution irrelevant.
The way we handled it was completely manual. It was understood by the designers and engineers that all items must be revised together. Despite it being manual, things worked out fine. Maybe 1 out of 100 times there would be a mismatch and we would have to fix it.
In Innovator, if you use ECO's this usually takes care of itself since the impact matrix will go find the CAD. In the planning phase, make sure that the action is set to revise for all these Items. If you use the MCO mechanism to adjust the AML of the Part when required, then things will probably be fine since the AML doesn't bump major_rev.
You should disable to Manual Release Action for both the Part and the CAD Document, and be sure that only the Aras PLM identity is able to execute the transition from Preliminary to Released. This will prevent users from accidentally circumventing the ECO Process, and help make sure things don't slip through the cracks.
If you wanted to move to the next level of automation, you could create a method and attach it to the Lifecycle transition to Released for each of the ItemTypes you need to manage. It could query the other related items and be sure that they are all on the same change Item.
In Innovator, If something were to become mis-matched, the "lagging" record(s) would have to be revised, first individually, to bring it to the same revision level. But because released Items have fixed behavior, the other items will still be pointing to the previous revision, so once you've revised the lagging record on it's own, everything will have to be revised together to fix the relationships.
Best,
Mike
Hi Brian,
It seems that you know this, but I'll underscore that doing things this way isn't a good idea, and is totally counter to typical BOM management practices and ASME Y14.100 / ASME Y14.35. But with that disclaimer...
In the past, I worked in an organization that had a similar practice to yours. I was told that the constraints of the MRP system required that all Drawings, CAD Models, and the Part record itself have matching revision levels. We were using Enovia but I believe that the philosophical nature of your question makes the particular PLM solution irrelevant.
The way we handled it was completely manual. It was understood by the designers and engineers that all items must be revised together. Despite it being manual, things worked out fine. Maybe 1 out of 100 times there would be a mismatch and we would have to fix it.
In Innovator, if you use ECO's this usually takes care of itself since the impact matrix will go find the CAD. In the planning phase, make sure that the action is set to revise for all these Items. If you use the MCO mechanism to adjust the AML of the Part when required, then things will probably be fine since the AML doesn't bump major_rev.
You should disable to Manual Release Action for both the Part and the CAD Document, and be sure that only the Aras PLM identity is able to execute the transition from Preliminary to Released. This will prevent users from accidentally circumventing the ECO Process, and help make sure things don't slip through the cracks.
If you wanted to move to the next level of automation, you could create a method and attach it to the Lifecycle transition to Released for each of the ItemTypes you need to manage. It could query the other related items and be sure that they are all on the same change Item.
In Innovator, If something were to become mis-matched, the "lagging" record(s) would have to be revised, first individually, to bring it to the same revision level. But because released Items have fixed behavior, the other items will still be pointing to the previous revision, so once you've revised the lagging record on it's own, everything will have to be revised together to fix the relationships.
Best,
Mike
