cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - If community subscription notifications are filling up your inbox you can set up a daily digest and get all your notifications in a single email. X

Regen: Generic with an Instance open

Dale_Rosema
23-Emerald III

Regen: Generic with an Instance open

I am not sure if this is something that it occuring or not, so could someone else test it. If I have a generic part open and have one or more instance of that generic open. When I make a change to the generic and regen the generic, the instance that is open in not regen'ed. I have to regen the instance separately from it's window.

I find that I keep trying to regen the generic and then release that the error is occuring on an instance that I have open and when I regen that, the corrections made in the generic with then update.

Thanks, Dale


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.
7 REPLIES 7

You need to verify the instances in the family table.

If the instance is not open, you get a regeneration error when trying to save unless you have that warning turned off or somehow bypassed. Very annoying! I would rather have a warning that gave me the option to verify all instances before saving. It sounds like having the open instance, the regen in that instance is equivalent to verifying in the generic.

Dale_Rosema
23-Emerald III
(To:TomD.inPDX)

How do you speed up verifying that takes 30-40 minutes? Cannot always justify that for a small change.

Not verifying the family table can save some time, but it also can leave some problems, mostly having to do with information that is needed by Windchill.

Verify steps through the process of regenerating the instances and also updates instance-specific information. If a change is made that is certain to only affect a dimension value, then that's probably safe to skip verification. If instances are added to the family table, then it's best to verify. In between, it's harder to tell. Add a column for a dimension value, probably OK; add a column for a parameter, it's best to verify; change an entry to replace a component in an assembly - verify that for certain.

I think there's a separate area in the part or assembly files that maintains instance information that is not in the simple table itself and it's this area that is updated by verify or by regeneration.

The only way to speed this up is to start the verify before lunch, or before going home. Either way, you aren't there so you don't spend time on it. You can also hit the verify button and see what instances need it and then open those and regen individually, though it is liable to want all of them done.

Dale_Rosema
23-Emerald III
(To:dschenken)

Any instance that is open and has been regenerated doesn't need to be verified (it already shows as "Success").

Also, you get the "Do you really want to verify a part that has not been regenerated" message. Close out of the family table and then regen. And then you have to regen again before you get the green dot, hopefully. Then get back into the table and then verify.

It still asked to verify the models even if I change a name in a decription of the part.

I am thankful that I have two work stations at my desk so I can bounce back and forth between the two seats.

Besides, I don't have WindChill....

Maybe the read only trick will help?

I have never liked family tables and certainly not for massive library parts. One little file corruption and poof, tons of file recreation work... for PTC tech support of course.

I have been using them a little more just to get use to them. Nothing that takes more than a few seconds for verification. But it seems that times when regeneration is expected, the model is considered "not changed" and when it doesn't need regeneration, it does it 2 or 3 times. A little attention or a review about this by PTC wouldn't hurt.

I suspect there are all kinds of config settings or tricks that may help situations such as yours, Dale, but they are not well publicized. If you really want to understand your particular issue, you might submit a support case.

Ha! I tried read-only. It prevents the instances from getting changes beyond that point in the generic.

I never have had file corruption in family tables and that includes some really large ones.

The biggest problems are that they work as one would expect, but that is different from what a lot of users imagine.

The most common source of problem is 'rename' where the user just types a new name in the table over an existing name. Gaaah! This is where Windchill certainly comes in. The old name had a record linked to the generic, but the old name is gone, so Windchill doesn't know where it went. Likewise all the assemblies that had that name inside them also don't know where it went. They go by name, not by which row a name was on, so they all fail to find the 'renamed' instance. As far as the generic is concerned the user deleted the old instance and added a new one.

Another is users don't verify, which means that one or more instances can be booby-traps that fail on retrieval for one reason or another. For example, a careless change to a sheet-metal part prevents the flat pattern from being created. Open the related drawing and the flat pattern view is destroyed; panic ensues and more damage is done. Or parameters don't get updated in the instances. The alternative is to have the model regen for every keystroke or change of selection.

The one that I appreciate the least is the silent fail. In an assembly with a family table, if an item cannot be retrieved in an instance then all the components that depend on that item will be ignored, rather than drawing attention to the missing part and all the unplaced children.

Why bother with them? Because when an item is really part of a family, it is often trivial to make reliable, significant changes to hundreds or thousands of items with a great deal of confidence that it all works right, rather than opening each one of those hundreds or thousands of items to add some new geometry or parameter. Even when the count is just a few, if the changes are complicated, a family can still be much easier, and they are a good way to handle product variations with Program.

Top Tags