fam table + PLM question
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
fam table + PLM question
Hi,
we moved to Creo/pro 2 m030(m050) on WC10 m040.
On Wildfire 4.0, in order to add an instance to the family table of say nas620 washers, I woluld check out the generic only, add the needed instance and check generic and that instance back in. It was possible because of the following config options:
save_objects changed
regenerate_read_only_objects no
In Creo/Pro2 M030(or m050) it requires all instances to be checked out and itterated. Why? What is changed?
Did you figure out how to get it back?
Thank you,
D
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.
- Labels:
-
General
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
>
> Hi,
>
> we moved to Creo/pro 2 m030(m050) on WC10 m040.
>
> On Wildfire 4.0, in order to add an instance to the family table of say nas620 washers, I woluld check out the generic only, add the needed instance and check generic and that instance back in. It was possible because of the following config options:
>
> save_objects changed
>
> regenerate_read_only_objects no
>
> In Creo/Pro2 M030(or m050) it requires all instances to be checked out and itterated. Why? What is changed?
>
Opening WF4 or earlier family table in WF5 M050+ and WC 0.1 M020+ requires all instances to be checked out and iterated the first time. After that only the generic is iterated when adding new instances.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
A couple things we learned when we adopted PDMLink back in 2006. No nested family tables and the check in of the generic has to include every instance.
It was possible to edit the generic or inidividual instances and only check those in but that created a situation where another user could not update their workspace because the other intances were dependant on that workspace generic iteration.
In my opinion treat the entire table as one object. If the generic is checked in and iterated then checkin and iterate all instances too.
KR, Jim
