Problems with family tables

[ptc-914868]

I am working with Creo Parametric 2.0 release M010

We have a large catalogue of drawings ceated in previous versions of Pro/E and my problem concerns them.

I have just updated some dimensions in the generic part and come accross 2 problems.

#1 If a dimension (dia of a hole, for example) is updated, when the drawing containing the generic is opened, the dimension shows correctly.

If a drawing containing an instance is opened, the drawing shows the original value. Once regenerated the value is correct.

Whether or not I save the drawing, the next time it is opened the dimension is back to the original (incorrect) value, until the drawing is once more regenerated.

*note, this is refering to a general dimension, not one that is contained in the family table.

#2 Similar to the above, If the dimensions contained in a patern table are updated (patern of points), then the values of all pattern articles are correct, but in the instance only the first article dimensions are correct, the remaining dimensions remain at their old dimensions.

No amount of regenerating will fix this, the only way I have found is to bring each instance into session & update the dimensions & re-save the instance.

I don't understand how there can be a difference between the generic & its instances when the feature is not in the family table.

I have found that removing the .xpr file this problem is fixed.

Is there a problem with .xpr files? can I configure Creo to run without creating them?

Thanks.......Stuart

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.

[TomD.inPDX]

Stuart, you might look at the updates for the different builds of Creo 2.0. I seem to recall something along these lines as being an issue that later resolved. I would recommend submitting a case. You certainly have posted enough detail to get a fairly quick response from customer service.

Short of that, you could try loading M060 on a test platform and see if the issue still exists.

If you have an account you can compare releases using the update advisor: https://www.ptc.com/appserver/cs/update_advisor/update_advisor.jsp

[MartinHanak]

Stuart,

to prevent the creation of .xpr files, set the following config.pro option:

SAVE_INSTANCE_ACCELERATOR NONE

Martin Hanak

[vzak]

Hi Stuart,

Let me explain a bit on .xpr (.xas for assembly) files behaviour. Main purpoce of accelerator files is to eliminate instance generation file upon its retrieval. .xpr file is a kind of snapshot of instnace model when it was last saved in session.

Now next time when this instance is retrieved, Creo performs certain checks for its up-to-dateness i.e. can this .xpr file be used as is, or it needs slight update (if generic model or table content changed slightly), or it is completely invalid since generic changed too much.

The change in behaviour that happened in Wildfire 5 (I think, but probably in Creo1) is that .xpr files are less "sensitive" and are used by Creo retrieval in more cases than before.

- Previousely if even slight modification (say Hole Dia change) happened in generic then .xpr file was invalidated and instance was generated "from scratch" - much more time consuming, but fully precise result.

- Now if the change is small like this, .xpr file will be used by Creo retrieval and instance will come up not fully up-to-date - but very fast. User however gets indication by Yellow regeneration light that model needs to be regenerated to get completely up-to-date. This regen is still much "cheaper" in time then full, from scratch instance generation.

So here is a trade off : if you use accelerator files (SAVE_INSTANCE_ACCELERATOR option) now they will be used more often than before hence saving good chunk of retrieval time, BUT - you need to be careful since sometimes your model will come up with Yellow light , means asking for small regen.

We do admit that for some (actually many) users even a small risk of not fully up-to-date model is unacceptable, despite time gains. And Yellow light can be missed out. So we work to restore (optional) the behaviour to not use accelerator files if they are even little out of date. This will come with one of next Creo2 builds, and shall address your case #1 : if you check drawing, I guess you will see it requires regeneration ...

However your case#2 looks like a bug that worth submitting to PTC. At least you will get TS looking at the model and correcting any error if it is there in design ... though it does not sound like this.

Best,

- Vlad

[TomD.inPDX]

up-to-dateness ...is that a new word?

Thanks for clearing this up, Vladimir. I too would have missed the regen requirement.

A "regen_drw_on_open" yes* no might be useful and a lot more intuitive.

[Patriot_1776]

I like the "small regen" bit too. How do I get a "large regen" vs a "small regen"? Can I get a "Super-Sized" regen with fries?

On of my long-time issues with Pro/E, is that the software is not smart enough to completely regen. sometimes, depending on the relations, etc., you have to regen twice to get the file to work right. To me, this is unacceptable. If it's "smart" enough to give you a yellow light, why not just force a second (or third) regen?

[ptc-914868 · Accepted solution]

Hi everyone, and thanks for your responses.

with .xpr files I could not get this problem fixed, even if I deleted all associated .xpr's & re-created them with

File - Manage File - Instance Accelerator - Update

I could not replicate the problem on a machine loaded with M060 version of the software.

Soultion

Delete all .xpr files.

set SAVE_INSTANCE_ACCELERATOR = NONE

get IT to update to M060 version of the software.

We did have another case yesterday where the family table value in the instance kept reverting to the generic value upon retreval, even on the M060 machine.

solution (as always) is to bring generic into session, bring instance into session from the family table. change the value in the instance, save the instance, save the generic.

many thanks,

Stuart

[TomD.inPDX]

Stuart Tyler wrote:

...
We did have another case yesterday where the family table value in the instance kept reverting to the generic value upon retreval, even on the M060 machine.

solution (as always) is to bring generic into session, bring instance into session from the family table. change the value in the instance, save the instance, save the generic.

many thanks,

Stuart

That is simply -UNACCEPTABLE- and I really hope PTC is paying attention to this.

Do these real world scenarios actually cause the following condition:

• You save and close the drawing in a correct configuration and all data correct.
• When you re-open the file after a few days (not in memory) you get a -different- drawing with data errors?

I don't like family tables and the more I read Creo's implementation of them, the more they worry me.

[Patriot_1776]

I like 'em, and have seen a few funny things with them, but nothing this serious. Wow! THAT needs fixing. Thanks to Vladimir, knowing how creo (of course) isn't as good with family tables, I made that change in my config.pro. Man, is there some way creo is NOT just a big step backwards???

[Dale_Rosema]

Something that I remembered about family tables.

Are the dimensions that are not updating driven by a paramter? Does that parameter have a given value in the definition of the paramter or is it blank.

See this link to issues I was having when the field was left blank and the parts were not regenerating correctly.

http://communities.ptc.com/message/185521#185521

Thanks, Dale