We are using Windchill 9.1 and WF5.0.
A user has an assembly consisting of a guard door, a hinge, and a frame. The hinge is mounted to the frame and the door is mounted to the hinge. All parts are checked into PDM in the RELEASED state (read only in our world).
The user revises the guard door to move the mounting holes. This is done by editing a dimension, so all the references are the same. The part updates and is checked back into PDM and goes through our standard process to get promoted back to the RELEASED state.
Upon opening the assembly, the assembly indicates that it is modified and wants to be regened. We want to get the assembly happy, but we don' t want to have to create a revision of the assembly just because the door changed. The assembly still consists of the same parts assembled in the same manner.
I believe I have all mass property calcs turned off for the assembly.
Any thoughts on how to prevent having to create a revision of the assembly just because a part was modified (causing parts to move around in the assembly)?
Michael in KC.
I'd first look for external references - maybe a door feature refers to another ccomponent in the context of the assy. It should show up by requiring the door, the assy, and the rest of the assy components being copied out of Commonspace when all that was selected was the door.
This is an age-old issue in CAD. In recent years, non-engineering changes at higher level assemblies were incorporated in the release cycles for simple updates to make the changes needed to do what you are running into. This is very similar to releasing a component and when you do the drawing, you need to move references to create good associative drawings. These are not engineering revisions but they are revised in the strictest sense to the PDM.
It is truly a matter of how you have your policies set up. If you have a check function in your organization, -any- change probably needs to be reviewed. But once the process is complete, whatever that may be, -someone- should be able to make the conclusion that the file has not changed in an engineering sense.
I have lived this nightmare through countless mis-management opportunities. In the end, most are very manual managed by some IT person since they couldn't put this allowance in a PDM policy without it being abused at some level.
In the worst case, some companies use "bin compatible" interchangeability rules. Simply moving mounting holes constitutes a part number change, and this would force higher level assemblies to be updated through the engineering change order rules. If new holes were added to the part, this would be bin compatible. as going forward, these parts would have both groups of holes. This process still boggles my mind, but it is a system that has taken hold in industry. But you know just how difficult it is to constantly be making part number changes if your file names are part number driven. In Creo, this requires very careful implementation if you don't want to redo -everything- you touch at next level assemblies. I have seen the results of poor model management after a year or two of ECO activity where drawings would come up completely in shambles from ECOs that did not follow through on updates to the highest level. This was with PDM and an group managing ECOs no less.
It's an interesting problem.
If one moves a part from Released to In Work, should the PDM system automatically move all referencing material from Released to In Work? Should the PDM system require ECOs to be raised against the part and all the referencing material (and all that references it, and so on) before moving the part from Released to In Work?
I agree on the drawings, though a bunch of that is due to PTC's not dealing with drawings very well. The reliance on the model extents as a basis for both view location and view extents, which in turn drive drawing notations that are related to views, is a constant challenge. Add a part or change a dimension and one can find all the BOM balloons are mislocated, along with leadered notes and symbols. There are effort-expensive workarounds to some of it, so it's a wash for effort.
Unfortunately for drawings, it doesn't matter how clean the ECO/Review/Release scheme is, the rework is still there to do. The best that can be said is that it lessens the surprise.
Hi Michael,
I would call this consequent behavior.
If you have a released assembly and all released parts if you modify one part off corse the assembly is changed.
It is in a different state as it was when it was released. How else would you 'freeze' a development state?
..to Constantin
I agree that Creo will view the assembly as having changed. However, in my production world, the assembly still consists of the same parts assembled in the same manner resulting in the same assembly. My users and I cannont afford to update all the assembly prints (and the manuals they appear in, and the ERP system which references the revision level of the assembly, etc) just because a part moved .5 inches.
Now if the part changes and alters the way the assembly is put together or changes the BOM, then yes, we have to revise the assembly and make all the changes to manuals and ERP system, etc.
So maybe the question I should have asked is How are others handling this type of situation?
We have an intralink admin with the power to set the model back into design state without actaully reving the model. We then regenerate assembly (and model check), check it in, and have him move it back to release.
Not sure this solves your issue, but its how we get around it.
Constantin is 100% correct.
Anything you do to circumvent the correct PDM process will be a workaround, not a solution.
However, I think a lot of companies keep design assembly models which never reach a released state. But if they change something in the design then all affected 2D drawings must be revised upwards.
Its up to each company to decide what a "revision" is, when it comes to mdels. For us, we TRY to revise the referenced model to match the assembly of the same name. But, what then if the assembly is used in multiple dwgs? For that, we TRY and rev the model to the highest rev dwg it's used in. Sometimes we make family tables of the models where just the title and P/N parameter changes, und it's a new filename (best to use a separate P/N parameter than use the filename, say, in a BOM), as in when a part does not change geometry, but then goes from one vendor to another to get plated/coated/painted etc.
Ok, so, then what do you do when you send out a STEP file to get machined? How d you rev that? We make the filename contain the rev and iteration info of the dwg, and the model itself. Why? Because for some CNC measuring devices I have to split some surfaces up for different profile tolerance zones.
It's difficult to keep all this straight, and I don't think that there's a single and/or easy answer, but I will say be as consistant as possible, and try and set up SOME strict guidlines as close to the beginning as possible.
Best of luck!
We had events where initial events (Before going into manufacturing), Engineering can modify in a different manner where top part revision number (p/n doesn't changes in this case) changes according to child part changes. As our BOM was top to bottom approaches this made easy to handle. (Like Engine-1*****, and Engine head become 11***, and Engine head sensor becomes 114*** etc). In drawing side, this will be updated in the document, when PLM link will be modified to new drawing file (Because p/n remains same only revision changes). And in the ECO (Custom application), we provided check box in the ECO window for engineers to select like what are the things will be affected because of this. (Like manufacturing assy, vendor tool, assembly location, cost changes, service manual etc etc). This option made the life easier. though some time engineers used to miss some time to select critical option, weekly update document (Simple excel) which contains, what area all the changes happened in that week to all stake holders severed the purpose to identify missed parts.
qnen,
The guard door was revised after the assembly was released.
Now the door has been changed (it is a new door), therefore the assembly has been changed, it is a new assembly containing different parts and must have a new revision.