Continue to Site

Welcome to MCAD Central

Join our MCAD Central community forums, the largest resource for MCAD (Mechanical Computer-Aided Design) professionals, including files, forums, jobs, articles, calendar, and more.

Register Log in

Inheritance Feature

B

brchapman

New member
I create a lot of casting and machining models. In the past I used family tables to do this but was told family tables can be unstable in Intralink and it was a poor practice. I have to admit that some of the more complex castings, with multiple machined models made from this casting did make for somereally hairy family tables.


I was told that the "inheritance feature" was similar to the "Solid Body" functionality in Solid works, which I found to work very well. My problem with the inheritance feature is that the target part does not automatically pull the reference part into session. I have to do this manually by selecting the "external inheritance feature" and "update". Is there any way around this? I am concerned that a user will not be aware of this and that it will cause a problem. Any suggestions would be appreciated.


Thanks.
 
Assumingthe raw casting is your 'source' part and the machined version(s) are the 'target' parts:


If you need the solid and datum geometry from the source model inserted into the target model so that additional features can be created, I would recommend using an External Merge feature (Merge from other model). Ext-Merge is very stable and there are very few bells and whistles (i.e. things that users can screw up). You always get the exact geometry from the source model and, optionally, datum features.


If, however, you need any of the following additional functionality, then you might need theinheritance feature:

  1. <LI>Ability to see entire source model tree within target model
    <LI>Ability to supress certain source features in the target model
    <LI>Ability to have target dims different from target dims
    (note: #2 and #3 do not affect the source model)</LI>


I think that in many cases, the added functionality can be overshadowed by the risk that the target model can become different than the source model. For example, if I have a machined model containing an inheritance feature of an as-cast model, I'd always be checking the inheritance table to make sure there are no differences between the models. This risk becomes even greater if other people are working on the models. With the Ext-Merge, this is a non-issue.


Just some stuff to think about,


-Brian
Edited by: Brian_Adkins
 
Brian


Thanks for your input. I remember looking at merge years ago when the co. I was with at the time was trying to figure out the best way to model castings and machinings. We settled on family tables instead of the merged models.I cannot really remember the reason why. Probably because of the lack of info. with the merged model. Looking back at the problems we had with instances, it is probably better not to have all of that info. on the machined (target) model. I can still remember making machine drawings, showing some dim. on the drawing and tagging them as Ref. dims. only to have the foundry call me up a month later asking me if I really wanted a dim. on the casting drawing to be a ref. There was also a big issue with Geotol datums. Any datum set on the casting had to be used on the instance. For ex., if I used datum A and B on the casting, and I wanted a different A and B on the machining (almost always the case) I was stuck. The work around was to draw datum A and B as 2d text. Not a very good approach.


I think I will take a look at the merged models again. It may be the way to go. It still does not resolve the issue I am having when I pull the target model into session and it does not regen with the latest ref. model changes though.


I did find the config option "retrieve_data_sharing_ref_parts"that when set to yes will pull the ref. model into session when the target model isopened up. For some reason though, I still have to regen the target modelin order for it to update. The target model must be coming into session first, and then the ref. model comes into session (afterthe targethas already regenerated). I do not care for this, and all of the users will have to be aware of this limitation. I guess as long as we regen the target, all will be OK.


Brian
 
I think you guys are all right and you should use what ever is right for that model.<?:namespace prefix = o ns = "urn:schemas-microsoft-com:eek:ffice:eek:ffice" />


One other way that I usemost of the time is copy geom feature from other model.


Then I can copy as little or as much as I want from the casting. One of the nice things about this feature is that when you change the cast model it forces the surfaces that you copied back to the cast parts color.


The down side of not using Inheritance Feature is that you can't ref a pattern from the original model.So if you have a row of cast holes that you want to machine out you can't just add the hole and ref the existing hole pattern.


If you have not tried the copy geom feature from other model you might be miss the best way yet or at least the simplest. Hopefully PTC will add the missing ability
 
I know this is an old stale post but I was just playing around with using an external inheritance feature for the first time. I tend to stay with tried & true techniques that I fully understand. In the past I have always used merges to get raw (cast or forged) geometry into my finished parts. I thought I would try the newer & supposedly better external inheritance feature.

So I have a family table of forgings. Each forging gets machined into multiple finished parts. I made the first finished part by creating the first solid geometry as an external inheritance and then making all the machining cuts. I made a drawing of the machined part & all is happy.

Now my problem is that if I startup Pro/E and open the drawing it says it ignored the external reference. If I open the machined part and RMB on the external inheritance and select Open Base, Pro/E can not find the forging instance (it is in the same directory)! If I manually locate the generic forging & then pick the correct instance it works.

I tried setting retrieve_data_sharing_ref_parts to YES. That made the drawing fail to open until I manually opened the forging instance.

Is Pro/E incapable of finding it's own instances in the case? I have used the same construct of family table of raw parts to make family table finished parts before. It is possible to add the merge to the finished part family table and Pro/E will happily substitute the correct raw instance. Am I doing something wrong or should I beat on PTC?
 
Your problem is simple. You are mistaken on how to use this feature (which is understandable (first time and all)).

If you are going to use an inheritance feature then you would have no need for a family table.

You may not even need to use inheritance.

Here is what I think would suit your needs.

Simple make a part that is your forging. Now that you have this. Open a new part and add a "copy geometry" feature in to the new part. use the forging part to copy the geometry from. use a surface that will be the least likely to change as your ref feature and then copy solid.
Once you have this copied into the new part (and it is dependent (which you can turn on and off)). Then solidify your surf envelop. once solidified you can start machining with cuts.

Make you're forging a different color then the new machined part and you be able to see where all of the cuts are.

Now save this as machined part 2 thru 12,24 whatever and modify the cuts to match.

All of the parts will update with the original forging but will not be affected by the other versions of machined parts.

I hope this helps

Good luck
Heath
 
Heathbn,


Both techniques are fine....


I would prefer to use inheritance, but Cad Standard here requires copy geom for raw> finished parts.


But in my opinion Family tables do not 'last' very well for raw> finished parts unless they are simple parts or never need changing much.


Also the file name is sometimesanE.R.P.problem when using family tables.
 
I've used Ext. Merge for alot of years and not too long ago we switched to using a publish geom (I was out voted). I posted a question about Merge v. Publish Geom pros and cons, but haven't had too many replies yet.
 
Heathbn - There are multiple forgings, they are already family table instances. Each forging gets machined into multiple finished parts. I definitely want to stay with family tables because of the automatic replacement capability in assemblies. These end up going into finished products with like 400 unique instances. No way I'm giving up family tables. Parts have to stay dependent, I can't imagine why you would want inheritance to vary independently in a manufacturing environment, great way to introduce errors.

Now maybe I should be using copy geom instead of inheritance but in either case Pro/E should be able to find the reference to the raw part. It can with a merge, it's like PTC screwed up the code in inheritance.

Publish geom & copy geom seem like an awful lot of work compared to a simple merge. Maybe I'll just go back to what has always worked.
 
How can i edit the external inheritance model?. I am not able to hide the surfaces, curves that are used to create a complex shapes, in the drawings.
 
can the external feature not be treated in the same way as an import feature can be where curves can be deleted by edit definition etc?
 
You must log in or register to reply here.

Sponsor

Articles From 3DCAD World

Back
Top