Saving assembly conflict message ask to check out parts

[amorales]

Hi All,

When saving a assembly I sometimes gets the conflict message come up to check out parts that are read only and is not checked. I just set all to continue but is there a reason why this conflict comes up when I did not edit these parts?

Thank you.

This thread is inactive and closed by the PTC Community Management Team. If you would like to provide a reply and re-open this thread, please notify the moderator and reference the thread. You may also use "Start a topic" button to ask a new question. Please be sure to include what version of the PTC product you are using so another community member knowledgeable about your version may be able to assist.

[dschenken]

Mostly this is because they are marked as modified when they are opened and regenerated. This can be a result of dependencies of the parts on the assembly; sometimes they have circular references; if they are family table items and weren't validated or if there is a parameter that is calculated that isn't in the family table (mass properties, for example). Sometimes it is due to a conversion from one version of internal data structure to a newer one. There have been only a few version changes in PTC history that are significant enough to result in that upgrade.

When you look you will probably see these items are marked as modified. You can either replace these in memory from the Workspace ahead of saving the assembly or just go with continue or skip them.

[ChristopherLewi]

Just a couple of thoughts to expand on Davids. This is a daily situation for us. The logical answer is indeed Creo sees the data as having been regenerated (and then somehow changed). Why could that be? Our primary case is that we make a load of external relationships (often because we're dirty modellers) and we also modify sub-components continually AND then we pull into our workspace the LATEST configuration (which has unlikely ever existed before). In truth it's amazing that any of our assemblies ever regenerate green. Another massive situation is 'live shrinkwraps' (OMG) and 3D cable harnesses that directly reference the undelying systems (can you imagine how messed up that is). BTW, The adhesive part you show in your image sounds like one of those things users like to make related to the surrounding geometry, i can almost imagine someone liking the fact that they can easily make the dab of glue in that corner by sweeping along the edge of a component or something. Associativity is such a great tool in the hands of those that know what it means. Sadly most mortals fall short and so I propose that we have to have a combat strategy instead....we semi-successfully combat this by encouraging the use of turning off the dependencies on these external data sharing features (by the time you get to release anyway). We also have encouraged the use of workspace lock to stop ourselves from using the continue feature and making more work at check-in time. Sadly i think the ultimate solution (users that make clean data) is a bit of a dream for us. We're waiting for PTC to give us a feature whereby objects in Windchill that are released SHOULD NOT REGENERATE without special permission from the driver. We'd also like a way to actually stop the user checking in 'yellow' or 'red' status assemblies. Anyone with the answer to that would be a great person for me to talk to.

These unwanted relationships we accidentally make in Creo also prove to be fun when doing save as's by the way, another area that is deeply affected by user modelling practice.

[StephenW]

I lock all files in my workspace except the ones I am expecting to change so nothing else will be allowed to be modified. It works well except every once in a while a locked sub-model will not allow the assembly I am working on to be saved. I usually watch when I save to make sure pro/e actually says it saves.

The other guys have done a good job of explaining why this happens, i'm just presenting my solution.