how can you avoid circular references when designing parametrically?

Discussion in 'Pro/Engineer & Creo Elements/Pro' started by dakeb, May 10, 2004.

  1. dakeb

    dakeb Guest

    How can you avoid circular references when designing parametrically?

    Lets say you create box.prt which becomes your first component in box.asm.
    Then you create lid.prt and place it on box.prt in box.asm, aligning planes
    to box.prt. You create some holes in the lid (a single cut feature) to fix
    the lid to the box. You create tapped holes (hole features) in the box using
    the axis of the lid holes as references. You now have a number of circular
    references, but you know if you modify the cut feature in the lid your hole
    placements will automatically update.

    Questions.

    1) Is this type of circular reference a bad thing?
    2) Does this increase regens?
    3) If so what's the best workaround?
     
    dakeb, May 10, 2004
    #1
  2. dakeb

    Petteri Guest

    Yes. You can't be your mother. If you manipulate time, you could disappear
    accidentally. Modelling history has similar phenomens.
    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
     
    Petteri, May 10, 2004
    #2
  3. dakeb

    Arlin Guest

    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...
     
    Arlin, May 10, 2004
    #3
  4. dakeb

    David Janes Guest

    : How can you avoid circular references when designing parametrically?
    :
    From your example, there are two fairly simple ways to avoid or get rid of the
    crc. To avoid, create the holes in the base part, assemble the top and make the
    dependent, coaxial holes in this part. No circular reference, no loop is closed as
    happens when you make the top dependent to the bottom then make a feature in the
    bottom dependent to the top.

    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
     
    David Janes, May 10, 2004
    #4
  5. dakeb

    Arlin Guest

    I have been able to eliminate MOST of the circular reference errors by
    looking at the CRC file and rearranging the assembly componets that seem
    to be causing the error... still, I agree, seems like a bug.
     
    Arlin, May 10, 2004
    #5
  6. dakeb

    David Janes Guest

    <snip>
    : 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
     
    David Janes, May 10, 2004
    #6
  7. dakeb

    David Janes Guest

    : 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. (?))
    :
    First, if you're not looking for them, it can be hard to even notice the crc.
    Maybe you stumble on the message saved to your working directory or happen to see
    a message buzz by as the assembly regenerates, maybe when you've deleted
    components or turned some subs into simp reps, which will also cause regeneration,
    though not the crcs themselves.

    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 .....................
    : > ...................
    : > .........
    :
    :
     
    David Janes, May 29, 2004
    #7
Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.