parametric modelling

[sanjeeva]

Hi


I have a problem to execute my idea. There are10 assemblies. there is slight variations in assembling values. So i need to create a model in such a way that if we change the value in assembly drawing, it has to update the model and drawing.


Family table will not serve the purpose because the variations are unknown.


If we go through the parametric modelling because of complexity of model regeneration errors takeplace.


can i get the solution for the above problem...

 

[andysuth]

Try using relations.





You can have the locally controlled Parameters in the individual models and then control them in exactly the same way as a parameter in the model, just suffix with a :2 or :4 etc.





e.g.


chairlegs = 500


no_legs = 5


Chairlegheight:2 = Chairlegs


Chairlegpat:2 = no_legs


then click on the tick (verify) will create two new assembly parameters called "Chairlegs" and "No_legs" with the above values, and then go to component 2 in the assembly and put those values there.


If you make a rename trail file then it can open the individual components, rename "In session" and then rename assembly (in session) then save the assembly gives you a (somewhat messy directory) and a new variation in design.





This is especially useful for companies making bespoke products for individual clients that are variations of standard designs e.g. window frames, staircases, gantry cranes etc.





I'm working on a way to use family tree instead of creating a whole new file each variation, but no joy yet.


Good luck with that.


-AS

 

[pjw]

That's not a good way to do it at all. In any case, you should be using component IDs for the relations and not the session IDs. Session IDs change between different sessions of Pro/E and the order they were opened. I guarantee you'll have problems if you use the session IDs to drive relations. The other problwem is that you could end up with conflicts. It's not always possible to track down where relations are stored. So you may end up regenerating an assembly, updating some component's dimensions somewhere, and then opening up another assembly and changing its dimension again.


Use top-down design. Use skelton features such as datums to drive you lower level part dimensions. This is an extrmely common approach for your problem.


Phil

 

[andysuth]

Fair comment that session ids do change, but I write the trail files so that the first thing they do is open the drawing file or assembly file, so it's not an issue, they always have the same ID.





Skeletal design features, I've had problems with patterning (occurances etc.)on such and find it easier to pass variables to parameters instead.





Tracking changes etc. is quite easy if you are methodical about it.





I've used this method on several systems and it's not bitten me yet, however I'm always looking to improve so might give skeletal another try if patterning occurances can be performed within it!


-AS

 

[dgs]

Session IDs change but I've found that Pro|E does a pretty good job at tracking them. The next time I open an assy with relations containing session IDs, they are updated to the new values. I don't know how they are being tracked, but they are.


Using them in drawings can be more problematic, but in relations they seem to be pretty robust.

 

[dr_gallup]

I use session ID's in drawing notes all the time & have never had one cause a problem. Sure they change from session to session but Pro/E tracks them internally somehow.

 

[pjw]

Most of the time it does. There are times when you can catch it out.


Phil

 

[andysuth]

The main problem I've faced is when loading a saved set of relations as a text file, that won't be updated, but if you are careful to load the assembly or drawing as first file after ProE opens, the archive is normally the same (so long as no components are suppressed between saving the archive text file and saving the assembly).





-AS

 

[andysuth]

I don't think part id 's are conducive to how I use it (renaming the parts) but how is that done Phil? is it like:





heightart001= 520


patternart003= 450


etc?





-AS

 

[pjw]

d1:CID_44=d0


where d1 is your component ID and is found from the Feat ID list in your model tree. Multiple instances of the same compoent will always have different CIDs.


d0 is your assembly dimension. If you wanted to feed a component level dimension you would simply use the same format as the left hand side of the equation. Make sure you add the relations at component level if you're adding them in your assembly.

 

[pjw]

I'm sorry, d1 is not the component ID - d1 is the dimension and :CID_44 is the component ID. My mistake. 44 IS NOT the session ID - it is the Feat ID found from the model tree (or by selecting 'Info' about the component).

 

[andysuth]

I'll have a play with that later, though things like the gantry cranes have several sets of identical components, so may be best sticking with the session ID's.





Cheers,





-AS

 

[sanjeeva]

Hi,


There is no difference if we use the session ids are paramter ids. Its better if use any other procedure to solve this problem in stead of using pro/programe. Because model is robust. One assembly contains 70 components with 3 sub assemblies. and there are assemble features like holes.


The method to follow: topdown and skeleton is required i think so... Now even outof this i am trying with layout modelling. Apart from this layout modelling any other suggestions to do.

 

[metin_mehel]

Hello,


You must create a part which includes all types of it. you will hide or show the features on one part and so you will get many parts from one part.


secondly when you create assembly use this kind of part and never use their specific features (surfaces). for assembling use planes of part.


I made a program like that it works and I can create many types of assemblies.