how can you avoid circular references when designing parametrically?

Yes. You can't be your mother. If you manipulate time, you could disappear accidentally. Modelling history has similar phenomens.

Yes.

Use top-down method. Create the first masterpart with mixed technicue. Use surfaces and curves and solids and datum features. Define all depencies in masterpart. Then use geometry of masterpart for creating other parts. Make references only from masterpart, not between other parts. Reference net shoud be like tree, not spider net.

Petteri

I like Petteri's answer. (Being MY mother is something I'd avoid at all cost. )

I think there's some room to argue that CRC's aren't evil incarnate, but not much way to justify not avoiding them wherever possible (they can always be avoided, it just takes extra effort sometimes). Like GOTO loops in programming they add complexity and if not managed carefully result in unintelligible "spaghetti code" and unexpected, undesirable results.

In addition to Petteri's top down solution you could also create the holes as assembly features, but that adds a level of complexity that MAY be undesirable, too.

=============================

"dakeb" wrote...

A bit OT, but as long as we are on the topic:

I am getting circular reference errors on IMPORTED assembly models! Any thought of what could cause this? The imported models are from iges files, so there should be no relationships what-so-ever...

I've had the same thing happen with STEP imports. I haven't been able to pinpoint the cause(s), but usually it involves messing around in the imported assembly (delete parts?, create feature?, etc.). I've tried to get some resolution, illumination, etc. out of PTC; to no avail. As far as I'm concerned it's a bug, but have dropped it until it I upgrade and it happens again (and I have a fresh data set to send as an example).

Some (most?) of the time I've been able to eliminate the CRCs by fixing (constraint) all the components in the assembly. Mostly I now just avoid playing in the assembly; create simp reps instead of deleting components, etc.

I'll be watching to see if anyone has any enlightening explanations (and be most appreciative) as it is an irritating problem. 8~)

======================

To get out of the crc, redefine the coaxial hole to linear and pick a couple datum references. The holes will stay in the same place and the offset values you get should be correct. Redefining and picking other, internal references will usually take care of the problem of cicularity.

How serious are these crcs? They are a class of dependency and like all dependencies or parent/child relations, they facilitate and limit. Having holes in a lid that change position when their mating holes move demonstrates some of the power of parametrics and dependency. At the same time, it means you can't move the dependent holes independently. If you wished to, you'd have to break the dependency. Circular references can modify dependency from being linearly historical (earlier features influencing later ones) to later influencing earlier, making it difficult or impossible to change the earlier ones. If you spend some time tracking down circular references, you'll get some valuable lessons in orderly/disorderly ways of creating and managing dependencies.

One other small piece of advice, if you are going to be doing a lot of assembly modelling (creating parts and features in assembly). As much as possible, reference assembly datums and features, as opposed to those of other parts/components. While legitimate dependencies will still be involved, this can help avoid those Oedipal relations, the scorn of your coworkers, social ostracism, etc.

David Janes

Hmm. Interesting; haven't tried that and will surely keep it in mind.

Uh, huh. If for no other reason than that a dependancy isn't reported when querying the parent / child relationships, assuming there's not a logical explanation, or misconception on my part, for that.

On a parallel....and I think it might be related; what is the placement status of a component in an imported assembly? They aren't "Packaged" and they aren't "Fixed" (or otherwise constrained), but appear to be in some sort of placement limbo. I've thought that if each component had an explicit "Fix" or "Default" constraint added upon creation it might circumvent some problems of this sort. There are obviously things going on that I don't comprehend.

================================

: circumvent some problems of this sort. There are obviously things going on : that I don't comprehend. : Things that I don't comprehend, as well. Could you briefly relate how you created the assembly from iges components, or an iges exported assembly, or however you did it? First, I'm curious if everyone followed the same procedure; I've also found that telling how I got in, looking at the procedure, often helps me figure out how I got into the box and sometimes, how to get out.

David Janes

In my case the assemblies were simply customer furnished *.stp translated assemblies, opened or imported. As I said, I have no distinct idea what I did to goof the assemblies up, which is what really bothers me. You know the old saw; "those that do not rember history are doomed to repeat it"? Same goes for those that don't know how they screwed up their models. I am pretty sure that I've caused the problem deleting components from the imported assemblies (getting rid of extraneous stuff), but I've never been able to catch it, repeat it, verify, etc. (I think the CRCs may not be generated until the next time the assy or an upper level containing it is opened. (?))

I do have a small data set (about 250 KB; 2 parts, 2 assys; both ref the same parts) that I can email you if you want to take a gander. As near as I can figure it is simply a corrupted assy. It was several assy layers deep in the main assy and if I remember correctly I was trying to create some shrinkwraps in an upper level assy (actually I was experimenting with new stuff; trying to figure out a way to simplify the assembly which had way more detail in it than I needed and it was killing performance). When I noticed the CRC error message (probably when I subsequently re-opened the top level) I did a backup to save the bad assy after investigating it, shut down and copied the .asm from an archive data set. The assy file sizes are different, so I must have been in the file and saved, but feature for feature it appears to be identical to the good version.

This isn't a big problem for me, but I would like to have a better understand> Things that I don't comprehend, as well. Could you briefly relate how you created

You're right to want to know, for purposes of avoidance, how they're created. They do have a lot to do with history, first and foremost, because Pro/e is history-based where 'time's forward arrow' rules: older to younger, far to near, parent to child set the direction of dependency. When something violates that by making dependency circular, Pro/e has a hissy-fit. Still, it's a relatively unobtrusive one and not much is effected. So, one way to track them down is to use Pro/e 'Info' tools to study dependency, getting the references from, as Arlin suggested, looking in the crc file.

The way I have seen the circularity come about, in situations other than the imported assemblies, is while doing a lot of assembly modelling ~ creating parts, assemblies and features. It can easily happen, when working in a subassembly or its components, that the component or part feature will reference something in the higher level assembly, a datum plane or points or curves. The problem arises that this reference does not exist in the world of this part or subassembly. That might not be a problem as long as everything stays together, as long as all the refernced parts and assemblies are available. So, as dakeb's post pointed out, you can wind up in a situation where features of a part depend on features of another part that did not exist when it was created and which have no relationship to the part, except through the assembly. Move both of those parts to a directory where the assembly is not available and his tapped holes will fail with a message like 'Feature references unavailable'. Even though the referenced feature is available in the second part, it can't be "seen", or used, because there is no relationship between the two parts and no information gets passed, except through the assembly.

: I do have a small data set (about 250 KB; 2 parts, 2 assys; both ref the : same parts) that I can email you if you want to take a gander. As near as I : can figure it is simply a corrupted assy. It was several assy layers deep : in the main assy and if I remember correctly I was trying to create some : shrinkwraps in an upper level assy (actually I was experimenting with new : stuff; trying to figure out a way to simplify the assembly which had way : more detail in it than I needed and it was killing performance). When I : noticed the CRC error message (probably when I subsequently re-opened the : top level) I did a backup to save the bad assy after investigating it, shut : down and copied the .asm from an archive data set. The assy file sizes are : different, so I must have been in the file and saved, but feature for : feature it appears to be identical to the good version. : : This isn't a big problem for me, but I would like to have a better : understanding what's going haywire. I've since learned to make simp reps to : weed out the assemblies, which works well and causes no problems. I'd also : like to have some understanding of the "placement status" of the components : within an imported assy. : ================================== : : "David Janes" wrote... : > Things that I don't comprehend, as well. Could you briefly relate how you : created : > the assembly ..................... : > ................... : > ......... : :