bogus refs & check in - m050

[davehaigh]

I was just working on an assembly drawing. In the assembly yesterday, I had replaced some screws, using the notebook option. All this was done in the context of the workspace, have not been working outside the context of PDMLink.

When I tried to check in the drawing, it grabbed the screws I'd replaced and had them in the list to check in. It was a small assembly so fortunately I noticed the problem.

I went into the reference viewer and sure enough it showed the screws I'd replaced in Red.

I broke the dependencies in the reference viewer and regenerated the model, draft, & sheets. I went to check in again. It still showed the replaced screws in the check in list.

I had to erase the drawing and assembly from memory, and bring it back up in order for the check in list to be correct.

Anyone else see this bad behavior in m050?

David Haigh
Phone: 925-424-3931
Fax: 925-423-7496
Lawrence Livermore National Lab
7000 East Ave, L-362
Livermore, CA 94550


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.

[davehaigh]

I had the same problem with an upper level assembly drawing, but nothing was working to remove the files from the check in list.

I had to break the drawing dependencies, before it would give me the correct list of files to check in.

I understand having this problem if you do a replace when outside of the context of PDMLink. But not when you're working in an active workspace.

David Haigh

[bfrandsen]

David,
Have you tried with the config.pro option remember_replaced_components NO?
I wonder what the reason behind this functionality is.

/Bjarne

[ocorten-2]

I just recently set the config option remember_replaced_components to NO, but immediately users started complaining about replaced sub-assemblies and parts loosing all color.
So be carefull using it.


Did you try to cleanup the dependencies in the drawing?
Meaning:Backup the drawing to working dirErase the drawing from memorySet these config options:
cleanup_drawing_dependencies YES_CS_NOT_REQUIRED
cleanup_layout_dependencies YES_CS_NOT_REQUIREDOpen the drawing from working dir
Now, if non-required dependencies are found you get a dialogue box which enables you to remove them,
A reason why we often need to use the cleanup dependencies trick is the use of repeat region tables and fix index.
This creates an upwards relationship between the drawing to the fixed model, which does not go away when you remove the model from the assembly.

Layouts also have a bad habit of creating unwanted dependencies. So if you use any layouts, first clean them up as well with the same procedure.


Kind regards,

Olaf Corten




Olaf Corten
CAD/PLM Manager
Besi Netherlands B.V.
Ratio 6, Duiven
Phone: +31 26 3196215
Mobile: +31 644548554
www.besi.com






From: Bjarne Frandsen <->
To: "Haigh, David A." <->, "-" <->
Date: 03-06-2013 07:48
Subject: [proecad] - RE: bogus refs & check in - m050



David,
Have you tried with the config.pro option remember_replaced_components NO?
I wonder what the reason behind this functionality is.

/Bjarne

[bfrandsen]

Hi
I have had this set since September 2012 in Creo 2.0 and have not received a single complain about colors disappearing.
But I also know, than no company have the same Creo setup, so other settings can have influence of course.
Try it out and see what happens.

Best regards

Bjarne Frandsen | Technology Specialist, MCAD
Phone: +45 9684 4825 | Email: -

[cid:image001.png@01CDCC9C.5B8352F0]

Bang & Olufsen A/S | Peter Bangs Vej 15 | DK-7600 Struer | Denmark
www.bang-olufsen.com

[egifford]

Olaf,

Thanks for providing some insight into why this happens with drawings. We've had to occasionally use the method you describe to clean up dependencies between a drawing and models that have been removed from the drawing's driving assembly model.Sometimes in our case the tie is revealed when a user will try to do a "remove from workspace" on the part(s) removed from the assembly that shouldn't be referenced by anything in the workspace anymore.The action fails because the assembly drawing still has a tie to the component.

Erik

[LawrenceS]

We also use the method described to clear up dependencies from dwgs but have never found what on the dwg stored the dependencies. It very well could be the repeat region for us too, though we only rarely use the finicky “fix index” feature.

However, to avoid this problem I tell users to always have the dwg and the model open simultaneously (especially when replacing components) and make sure to save the dwg before erasing from session. Since I have started doing this, I no longer get ghost objects tied to dwgs.

Although this does not prove this is the solution, it seems to be true and is good enough for me. I would be interested in knowing if anyone else has experience with this and if it helps avoid having ghost objects and other check-in problems?

Lawrence