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

Community Tip - You can Bookmark boards, posts or articles that you'd like to access again easily! X

Breaking assembly family table into individual instances

ClaudiuCraciun
6-Contributor

Breaking assembly family table into individual instances

Hi,

I wonder if there is a way to save the istances of an generic assembly in individual assemblies

Ex:

I have an assembly with 5 instances. Every instance contain components that belongs to other generic.

I would like to know if there is a way for these 5 instances to be saved into individula assemblies with no connection to the previous generic and also the subcomponents that are used in instances that belongs to other generic to be saved individual without any coection to the generic.

In few words i'm not allowed to use anymore the instaces. All assemblies, parts are not allowed to have any instance or to be an instance of a generic.

I'm asking this because I have around 300 generics with ~40 instances. In total if I'm going to break the family table will be a huge number >20.000 models.

I found a toolkit program that is able to break the family table in separatly models but it's able to do just for level1 and not for subcomponents(level2)

Any ideea how I ca break these femily tables before 2012?

Thx,

CC

1 ACCEPTED SOLUTION

Accepted Solutions

Egad Claudiu...

Given there's little you can do, you have to suffer through poor decisions made by your management. Haven't these guys ever heard of a replication server? Ugh.

Metadata is relatively quick to download. The performance problem you'll see is going to be caused more because you have overseas workers accessing data thousands of miles away. Working with Windchill the way you're company is trying to use it is like buying a nice G5 jet, parking it in the ocean, and then demanding that everyone wear inflatable life vests while on board because the jet doesn't float very well.

In short... makes no sense and is a waste of a perfectly good jet.

Good luck.. sorry to see you in this situation!

-Brian

View solution in original post

14 REPLIES 14

Hi Claudiu...

By deleting the family tables, the instances should become standalone. However, this can be complicated by Windchill or PDMlink. Are you using Windchill (PDMLInk or Pro/INTRALINK) to manage your models? Let me know so I can tailor a solution to your specific needs.

The bigger question is... WHY can't you use family tables anymore? This smacks of some management decision that "family tables are bad" thus requiring you break all these instances apart. Family tables are tremendously powerful and infinitely useful. Breaking them apart after you have 20,000 models relying on them is, in my humble opinion, a criminal misuse and misunderstanding of Pro/ENGINEER.

But... most designed I know have worked under a boss who didn't "get it". I've had to break apart my own tables before and it's painful. Write back and I'll try to help you.

Thanks!

-Brian

Even me I don't understand why a proe functionality like Family table or interchange assembly need to be destroied before to upload everithing in PDM (windchill)

The answer was when a projects is checked out from the commons space is not good to see all the instances in case that you are using just one.

I taking this as a true. Who decided this seems that has years of experience with Winchill with multiple facilities and this is what he recommened.

Now I have to find a way to broke all these family tables

Hi Claudiu...

The person who decided this is... wrong. I'm almost vibrating in my seat trying to stem the torrent of insults I want to hurl at this person. But in trying to be constructive, let's discuss his assertions instead:

- You do NOT need to pull out all instances of a family table if you're just using ONE. There's a configuration setting in PDMLink to control this.

- You can use display filters in your workspace to remove instances from the workspace listing. Thus, you don't have to see ANY instances!

- The loss of interchange groups and family table functionality hurt you many times over... slowing your design processes and complicating your engineering work.

The person with multiple years of experience using Windchill at multiple facilities sounds like a WINDCHILL person, not a Pro/ENGINEER person. He doesn't sound like ANY kind of designer or engineer. If he has any type of experience with these tools, he'd understand what he's asking is really, really silly. I'm sure PTC consultants would back you up in this. He's effectively saying you can't use the tools you've been given because "its not good" to have instances in your workspace (or project). Who says this?? Poorly trained people say this. People who do not understand the tool say this. Experienced, reasonable, educated people do not advocate this kind of thing.

I wish I worked with you. I'd be the first to fight against this policy. Then I'd move up the chain of command until someone listened. I've gone head-to-head with Windchill guys, managers, and "experienced" IT people at a previous employers for the good of the company. They lose. If you can get a reasonable person to hear your concerns and understand what is being sacrificed, you have a chance to prevent this needless destruction of your models.

ANYWAY... you asked how to break them apart. From your email I'm assuming you're using Windchill PDMLink and Projectlink. Here's what I'd do. I did some testing and it works.

First, call up all 5 instances of your top level assembly into memory. Next, open the generic assembly. Go to Tools>Family Table>Edit (inside table tool)>Delete Entire Table. Exit the family table. You'll see messages scroll up the screen saying your 5 instances are no longer table-driven. Save the generic and save all 5 assemblies. This will create 6 standalone assemblies (one for the generic and one for each instance).

Next, start opening up your lower level tables and removing THOSE tables, too. Save again at each layer. If you start at the top level assdembly and work down to the lower levels you'll be able to successively break apart the tables. This only works for instances you have IN SESSION.

This technique will work although it can be painstaking.

Still, a better technique is to put together some type of spreadsheet or chart or email detailing how much money the company will LOSE due to this wrongheaded idea. In this economy if you can prove the company is wasting money performing all this extra work... and wasting the value of the expensive Pro/ENGINEER software tools, you'll catch someone's attention. If not, something much deeper is wrong at your company.

Good luck... truly!

-Brian

Thx for unswer.

I'm not familiar with winchill. I'm learning now but I have to follow the recomandation that they gave me before to add all these items to Winchill.

They motivated that if in one project that has let say 5 generics (every generic with 50 instances) if o facility in China (where the conection is not the best) will take time to load all these instances or to read the metadata.

They mention that having parts with more that 5-maximum 10 instances will have a big impact for the facilities (china, india) that try to access project information.

Again, I never used Windchill, now i'm learning and I cannot argue with people that knows and have Windchill experience.

For me as ProE guy, I add these functionalities (family table, interchange functionality) to help designers to replace, to avoid failures and update projects when one compoent is change (in design and cam)

Seems that PDM guys have more power now and until i'll learn I have to follow their recomandation

Anyway, thx for the information you gave me

CC

Egad Claudiu...

Given there's little you can do, you have to suffer through poor decisions made by your management. Haven't these guys ever heard of a replication server? Ugh.

Metadata is relatively quick to download. The performance problem you'll see is going to be caused more because you have overseas workers accessing data thousands of miles away. Working with Windchill the way you're company is trying to use it is like buying a nice G5 jet, parking it in the ocean, and then demanding that everyone wear inflatable life vests while on board because the jet doesn't float very well.

In short... makes no sense and is a waste of a perfectly good jet.

Good luck.. sorry to see you in this situation!

-Brian

linda
5-Regular Member
(To:BrianMartin)

Brian Martin,

we are facing the same problem, to merge into windchill the 3ds in family of 3 or 4 leves and with assembly relation.

Can you give me a scenario when i want to modify one part instance from the assembly instance?

the structures are like this:

top assembly has 5 parts. the third part refers the first part's geometry and add an offset to construct a feature , so the third part can update automatically when referenced feature in the first part changes. relation in an assembly context.

the assembly has 5 instances assemblies and each has 5 parts instances. part 3 has 4 levels families.

if i want to modify the third part of assembly instance 2, what are the least to be check out and so to be locked?

the generics of the 5 parts and the top assembly, the assembly 2 and the parts instance in assembly 2, right?

in other words, the whole assembly can not be check out by other person for any modification to whatever, the whole assembly is locked. If it is true when using windchill, what else we can do than to break the family table?

when you check in those files, what happens, new revisons for all checked out parts/assemblies? even only parts 3 is modified?and How to know other parts not afffected, lets say i changes the common dimension in the modified instance by mistake, all the instance in the family be modified, the other related parts will be checked out automatically for the update with new revison? or when i check in all files, the related parts will have a state not updated? it will be updated when someone check it out? what happens to the drawings based on those new revison?

thank very much.

linda

Hi Linda...

Ah, the fun of family tables. I can't think of any feature of Pro/E more maligned than family tables. Sometimes the criticisms are deserved but admittedly, sometimes they are fair and reasonable. I read your scenario a few times to insure I understand what you're asking. I think I'm on the same page with you... and you're asking fair questions. Family tables are very powerful... and they have some great benefits for designers. They also come at a price... and companies occasionally come to the conclusion that this price is too high.

It's true that when you modify an instance of a table (either assembly or part instance), you have to check out the generic thus locking it and preventing others from modifying it. In many cases, the tables are simple. Tables are great for libraries of hardware and other items that are not frequently being modified. When the hardware tables are completed, they're rarely modified... therefore the problems you're raising do not come up.

Beyond hardware libraries there are also other great reasons to use family tables. Sometimes in an active design you can make a great case for using family tables... even nested tables. This is what you've presented in your scenario. You've got an active design under development... multiple engineers working in collaboration. On top of this, you have nested tables complicating things. This is where things get interesting.

To paraphrase, you asked (at minimum) which objects need to be checked out" for the scenario you mentioned. You're modifying assembly instance #2 which requires the assembly generic... thereby locking out all assembly instances. You're modifying the 3rd part... so you'll need the generic for that part, too ... thereby locking out all the instances within that generic (and all sublevels, too). You correctly determined that your entire assembly and most of the parts will be locked... and no one else can modify them until changes have been completed.

In many cases, this is STILL not a big problem. If you're assemblies and parts are small enough... and your team is small enough, you can usually manage this situation. Collaborative engineering requires... communication. Most of the time, a small team is agile enough to understand the limitations posed by family tables. Yet they opt to work through the issues because the tables offer a fantastic set of options that speed modifications, drawing creation, and interchangeability. Basically, the pain of dealing with the tables is worth the benefit in these cases.

Sometimes though, you have a large team... and a big project. In these cases, having an entire assembly checked out to ONE individual is a real problem. Other designers are waiting to make changes- and are prevented from doing so. Some of these problems can be mitigated by careful planning of the assembly structure. By breaking the assembly into sub-structures, you can minimize the impact of family table changes on the entire team.

I'm sure it seems like I'm dancing around the topic... but the point is that there are several ways to navigate the family table issues and mitigate their negative effects. If you've already got a large assembly built with nested tables and you're already passed the point of being able to manage it, your options are increasingly poor.

Yes, iterations will change as objects are modified in Windchill. Yes, nested tables cause many objects to be locked while modifications are underway. And yes, if you make a mistake editing the instance, you can inadvertently mess up other related instances. These are all fair criticisms. And yes, one way to eliminate the problem is to break apart all of the instances and keep the parts as standalone objects. But I think this method completely throws out the beneficial aspects of tables for the convenience of having individual parts.

You can mandate that designers use NO family tables. You'll certainly make life easier on the Configuration Management people. However, you're tying the hands of your designers to use the full power of Pro/ENGINEER to create models. The whole reason companies spend so much money on the software is that is has the ability to save time... and get products to market more faster with less expense, higher quality (less mistakes), and fewer resources. Family tables keep a design consistent. Individual models can have individual errors that slip through the review cycle. Individual models require individual management... and individual changes... and individual drawings. You pay a price in productivity when you remove tables from your palette of options.

Is there any way to gain some of the benefits of family tables... YET keep the models separate? YES! There are a few options you might want to investigate. First... take a look at Inheritance Models. You can mimic some of the benefits of family tables... without the table... using inheritance models. Second, consider keeping the parts tables as-is. Individual part tables are much easier to handle in Windchill... and they don't have the far reaching negative effects of tabled assemblies. Third, in some cases you can remove assembly tables and get some of the same benefits using Flexible Components. For cases where the table is helping to show various mechanical states of an assembly (like a boom being raised, lowered, extended, etc), Flexible Components and flexible features can take over these duties. Thus you can remove the table and still get the variety of mechanical states you need.

If you can tell me more about your situation, I can try to be more specific. I'd like to give you as much help as I can but it's tough when I'm not sure exactly what your specific goals and requirements are. If you'd like to talk more in email or call to discuss things further, let me know and I'll get you my contact information.

Thank you and good luck!!!

-Brian

linda
5-Regular Member
(To:BrianMartin)

Hello Linda,

Hello,

I agree with you that for the standard parts in libray, the family table can be as complicate as possible, because it is read only files. No chance it is modified.

It is also good if it is small table.

But for the roution used parts in a manufactury company, the modification is very often, to the 3ds or 2ds, though small issues. And the family is for the whole production line-the whole ball valves products. Imaging what will happen if i want to modify 3" ball body, which will take often one week goes through 3d, 2d modifications, checking, approving! All ball valves products can not be touched. only work can be done is on butterfly valves products or check valves products.If some one works on a check valve part, the check valve products are locked also. All engineering staff has to wait for the products unfrozeon?

the generic assembly has 12 sizes assemblies instances which are comprised of 10 machined components. The body is controlled by the ball.the component,take the ball for example, has a generic of 12 machined parts, the machined part is the generic with gating and casting instances in the second level family table.

it is small or big?

we can use merge or inheritance to replace the family table, where inheritance has the options to vary the dimensions, features. it will be applicable to choose almost every dimensions for the variation between the difference sizes?

For the Flexible Components, you mean that i assemble the assembly with components which have all flexible features, flexible dims inside? whenever I open the assemblies, I have to set all the flexible issues? How long it can takes to retrive an aseembly with 20 parts?

I think all those skills may only be used for small variations. If there are many variation, it is better to make it standalone.

Happy Christmas Day!

linda

Hi Linda...

I re-read your email a few times and I think I understand your structure. This is definitely what I'd call a SMALL assembly.

It sounds like you have a basic assembly model with multiple sub-components. All of these components are table-driven... sometimes with multiple levels. Occasionally you have relations controlling some of the relationships between components which ties these components to the assembly. Your problem is that you always need to make small changes to your components but you don't want to lock up the entire assembly to do it. But because of the relationships and the tables, you're stuck.

Inheritance models can handle some of the problems with components, but not the assembly. You could keep the 12 different sizes of balls and then make the gating and casting modifications to each as inheritance models rather than a nested family table. This might help.

You could use flexible components to handle some of the assembly problems. You only need to pick the items you want to vary. I hear you when you say you need almost EVERYTHING to vary. But if that's the case then you're really back to using family tables. I was suggesting flexible components if you needed to show a valve in an open and closed position. You can do that with a flexible component rather than having two instances (one for each position).

It seems though that neither of these solutions are going to give you quite what you need. I think you need to re-examine the entire structure of your top assembly. Are you using skeletons at all? If so, can't we use the skeleton to eliminate some of the relations which are tying the components together? Basically, you've got too many external references. When everything is tied together this deeply... you can't modify one piece without locking out all of the others. You need to manage the references in a way that provides you with the dimensions you need from the assembly while keeping you free to modify components individually. This can be done. I suspect the way you have the built the assembly is hampering you, though.

Without trying to build a small-scale, skeleton driven model to investigate, I can't give you concrete solutions. I need to make a small assembly that replicates your situation. This might take some time. I can work on this over the next week after work hours and write back when I have something. If you come across more data or have anything else you can provide, that will certainly help.

Thanks and best regards,

-Brian

linda
5-Regular Member
(To:BrianMartin)

hi

i tried to use the skeleton to avoid cycle reference, and do design analysis, but our r&d director prefers to use assembly family table with components references in between.

do not bother about it too much, i will see how the data are merged to the windchill by the expert, then i will let you know.

thanks

linda

My person opinion is that your R&D director probably doesn't understand skeletons. Whenever you're hampered by management's misunderstanding of the software, you're going to suffer. Unless you can break the relations which force you to check out the assembly to update individual parts, you're going to continue having this problem.

If you could implement a simple skeleton to handle the references and relationship between ball and housing AND make use of inheritance models for the 2nd-level family tables (like the gating and casting), you could resolve most of your problems.

It probably took a good long time to build such a nice set of tabled assemblies. It would be a real shame to lose them.

Best of luck!

-Brian

I think at the end I found a way to break the family table.

I have no choice. The managers and PDM experts that we have ask this and at the end I have to break everithing in individual models.

With a little API aplication this stuff can be done.

I'll let you know in future what is going to happend with library and me .

Hi,

 

Referring to -> "I found a toolkit program that is able to break the family table in separatly models but it's able to do just for level1"

Can you please share this toolkit program with me? I have FTs which are just 1 level and this program will be very useful for me.

 

Thanks and Regards,

Jyothi

While the responses to the original post where a bit humorous ... this is a common problems.

 

We did something like this with Nitro-CELL years ago to do this.  The same principle can be done with CREOSON (for free).

 

Nitro-CELL UseCase Breakout Family Table Instances

 

Dave

 

This is a use case demo of how to use Nitro-CELL to breakout family table instances from a generic using a batch worksheet to iterate through instances within part model that contains a family table. Get your FREE Download and License now at: https://www.simplifiedlogic.com/nitro-cell
Top Tags