INTELLIGENT WORK FORUMS
FOR ENGINEERING PROFESSIONALS

Log In

Come Join Us!

Are you an
Engineering professional?
Join Eng-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Eng-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Jobs

Inventor assembly heirarchy

Inventor assembly heirarchy

(OP)
can you seasoned Inventor users walk me through a little discourse on the Inventor assembly heirarchy? it behaves in the same way that Solid Edge does, which i have seen firsthand create a lot of problems: you can drag items in the assembly tree anywhere you want, even above items that they are constrained to. also, you can suppress items, but their dependant items do not suppress, as well.

try this mental gymnastic exercise:

let's build a tower, made out of three blocks. drop the first block into the assembly at the origin. then stack block 2 onto it, and constrain it to block 1. then drop block 3 onto block 2, and constrain it to block 2. now, in the assembly model tree, you can drag block 3 up above block 2 and block 1 if you wish. it completely disregards the sequential order? plus, if you suppress block 2, then block 3 should be suppressed as well, since it is constrained to block 2 - but it doesn't get suppressed. so, assembly constraint heirarchies are ignored?

this is just like SE, but actually you don't have the ability to suppress objects in an assembly in SE. In Pro/E (Creo), these releationships are enforced and thus you cannot get your assembly constraints all tied up in knots like you can in SE (and apparently Inventor). having worked with SE for two years, i can tell you i came across a lot of assemblies with constraints so out of whack the only way to fix them was to delete all the constraints and start over; the problem was that SE let the user do this behavior. it appears as though Inventor does, as well...

am i missing something really important here? am i correctly describing the behavior of Inventor?

RE: Inventor assembly heirarchy

I like freedom. Guess you don't :)

RE: Inventor assembly heirarchy

(OP)
mcgyvr;

come on. you're confusing "freedom" with "sloppy" or "inaccurate". i expect a 3D CAD program to function in an accurate, professional manner; this isn't graphic arts. if you want artsy-fartsy pretty images, then go draw a picture of a kitty using 3DSMax. if you want accurate, reliable, engineering data, that's what Inventor is for, and that's what i expect. to be able to rearrange items such that their constraints don't matter is unacceptable in this environment. if Inventor isn't at that level, they need to truthfully advertise it as an entry- to low-level graphic arts program that happens to be able to slap some dimensions on a drawing so detailers can use it.

Solid Edge is so "flexible" (marketing buzz word) that low-skilled users started generating assemblies that you couldn't trust, and didn't behave in any predictable manner. so what good were they to engineers? beyond a visual representation of parts (which is just a picture), not much. Inventor appears to function the same as SE from what i've seen during my very limited exposure to it. if that's the case...what a shame.

if i'm not using Inventor properly, then i need to know what i'm doing wrong. if it's designed to be able to do these things, then i would like to know how that behavior is justified in a 3D engineering package.

RE: Inventor assembly heirarchy

I've been using it for 10+ years I guess and NEVER has the assembly tree order EVER been a problem (well except for the cable harness/piping nodes and component patterns which require some tricks to move them around and I complain about this with every new release). (I've never used a program where it is important either..thank god I think)
Being able to arrange the parts in an assembly tree into a logical order or into folders is something that I love (and folders were a much awaited new feature from a few releases ago). I put all my fasteners in a folder all my enclosure parts into one folder,etc.. It makes finding/organizing parts so easy.

Just for reference (using your tower example) what is the process (in your "other" program) when later I decide that block 2 is better suited on top of block 3 and not under it.. Must you, first delete the constraints, then move the parts in the assembly browser, then redo the constraints? And what happens when you don't have the part in the right order in the assembly browser.




RE: Inventor assembly heirarchy

ungarata,

I think this is one you're going to have to take on the chin. Inventor doesn't rely on the tree order to define constraints. You could place all the parts of an assembly into the assembly pane in whichever order you want, and constrain anything to anything else in whatever order you want. This provides freedom to insert a nut before a bolt, or vice-verse. If you suppress something that has constraints applied to it, then yes, the CONSTRAINTS get suppressed... but the separate part doesn't get suppressed, as it shouldn't. If I want to suppress a ball that is constrained to a stem's rotational axis, for example, and I suppress the stem (in turn suppressing it's axis), then you're saying that my ball should also be suppressed? No, instead it frees the ball from the constraints applied to the stem. Am I interpreting your issue correctly?

Inventor and Pro/E differ in a few major ways, and some things you just have to get used to! lol

RE: Inventor assembly heirarchy

(OP)
mcgyvr;

i agree about organizing the tree; instead of folders, i'm used to using groups. i also group all the fasteners together at the end of the tree, then i can control their visibility all together by either showing or hiding the group.

tower example, "other" programs:

move block 2 on top of block 3 in Solid Edge: in the assembly tree, grab block 2 and drag it below block 3 (or grab block 3 and drag it above block 2). it will now appear (looking at the order of the tree) that you have assembled block 1, then block 3, then block 2. however, the constraints are all knotted up; they are still there, but now some of them appear as lower-level constraints instead of primary constraints. you have to backtrack and diagram out how the assembly is constrained to make any changes that might affect other parts or assemblies. suppress functionality? nonexistant.

move block 2 on top of block 3 in Pro/E (Creo): *part* of the constraints will need to be changed, depending on how you constrained the blocks. you can either suppress them, or you can delete them. then, you can drag block 2 below block 3 (or drag block 3 above block 2). then, re-apply the deleted constraint (probably "mate") or un-suppress it and redefine it. extra steps? yes. tangled constraints? nope. correct "suppress" functionality? check: if you suppress block 3, it will also suppress block 2.

i'm not sure what you mean by your last question. you can drag parts around in the assembly tree all day long as long as you're not tangling constraints up with each other. if you have a part deep in the tree that you want to move up above other parts (and there are no constraints in the heirarchy), then that's fine; drag away and reorder all you want.

RE: Inventor assembly heirarchy

(OP)
EMorel;

okay, you've summed it up: Inventor doesn't rely on assembly tree order. so, it's just a list, not a sequential or heirarchical list. i don't agree with your observations about correction behavior regarding suppressing assembly objects. you can suppress constraints all you want, but if you suppress a part that has other parts constrained to it, they should be suppressed. suppressing is in effect rolling the model back; something that should always be done.

look at the tower example: block1 on the ground, block2 stacked on it in the middle, block3 stacked on block2 on the top. now, suppressed block2; block3 should be suppressed, as well. to suppress something is to consider it gone; it is NOT the same thing as making something invisible, but still there. physically, you would have a tower with a section missing out of the middle, and the top block would be magically floating in mid-air. since block2 is not there, you cannot build on it, so block3 would need to be suppressed, as well. now, if you suppress the constraints from block2 to block3, then you wouldn't have to suppress block3 itself. suppressing objects removes their influence from the assembly (including their mass properties).

i'm beginning to view Pro/E and programs that function like it into a "hardcore engineering" group and Inventor/SE into a "design" group. that will of course irk some people, but i'm trying to get to the bottom of how the programs function, not start a religious war (as another poster commented).

RE: Inventor assembly heirarchy

Ungarata,

I look at it differently. With assemblies in Inventor, the parts are their own model entities. They are created separately. In a PART model, if you suppress a feature that was created before another, it will in turn suppress the later feature as well. That is where the hierarchy that you are talking about comes in. In an assembly model, the parts are individual pieces that are added. So by adding one part and then another, suppressing the first one should NOT and DOES not suppress the second added part. If they are constrained together, those constraints are automatically suppressed with the suppressed piece, but the un-suppressed part remains, as it should.

Look at this way. In a real assembly, in real life: If I have a shaft held into a sleeve by a pin... and I remove (or "suppress") the pin that is constraining the shaft to the sleeve, is the shaft going to disappear? No, it will remain there, but will be able to move freely in and out of the sleeve since the pin is no longer there to constrain it. The piece being suppressed and the constraints it implies are suppressed, not the pieces that rely on the constraints.

In your block example, if you were to stack the 3 blocks and suppress block 2, block 3 would not be "magically" floating in thin air... it would be free to move down to block one under the influence of the operator. If what you are looking for Block 3 to fall down to Block 1 after you suppress Block 2, start working with simulators... Inventor doesn't take gravity into effect. lol. But by suppressing Block 2, you are also suppressing the constraints between Block 2 and Block 3. At least mine does when I do it...

RE: Inventor assembly heirarchy

ungarata,

I've had an epiphany this morning at work. I was helping someone else with a model on their computer and ran into what you are talking about. I suppressed something and the constrains remained until I suppressed them separately. For some reason, mine does not do this, mine suppresses constraints associated with the suppressed part. I don't know where my settings differ, but I understand your frustration now! lol

RE: Inventor assembly heirarchy

(OP)
EMorel;

well, that's interesting, and i've never heard of that type of behavior from ANY CAD program, but actually i am just frustrated by the items i mentioned in the previous post(s). i hadn't experienced a situation where i suppress a part and it's constraints were still hanging around to wreak havoc... but, i'll be sure to watch out for that happening now that i know that it's a possibility. weird.

to answer your previous posts, no, i'm not expecting to simulate gravity or anything. i guess my hangup is how suppress should function. let me play around with a couple of scenarios and think about this for a bit.

thanks,

-ungarata

RE: Inventor assembly heirarchy

(OP)
EMorel;

I did verify the behavior you last described; if I suppress an object, it's constraints are NOT suppressed and are indeed still active. I suppressed the middle block in my block tower example, and the constraints for itself, and to it from block3 above it, are still there. if i now try to add a constraint to block3 that conflicts with the constraints already applied between it and block2, i get a constraint conflict.

in this example, it's easy to see what's going on and fix it. i'm trying to imagine this occurring in an assembly of 200 components, with some of them suppressed, and somebody has also reordered the assembly tree (see my previous post on this subject). now i try to reconstrain something and start getting constraint conflicts, and i'm trying to track down what the issue is. with the constraints of suppressed parts still active, plus the order of assembly not known to help troubleshooting, this turns into exactly what i faced when i used Solid Edge for two years. if the assembly tree order constraint heirarchy was honored, you could use it to find the problem; go down the list until you come to the first part that is unhappy - there's your problem. if you're able to drag parts in the assembly tree anywhere you want, you lose this troubleshooting ability.

i guess the reason i like the way Pro/E handles suppression of components and honoring constraint heirarchy is that it is 100% IMPOSSIBLE to screw up the assembly in the manner that i've outlined here (and seen firsthand in SE). call it sloppy, call it careless, call it ignorance on the part of the person running the software, but if the program allows this to occur, then it is also to blame, IMHO. i've seen SE assemblies, of hundreds of parts, so screwed up with parts floating out in space unconstrained, and constraint conflicts, that i couldn't do ANYTHING with the assembly until i stripped every constraint off of every part, then started over and rebuilt the assembly.

RE: Inventor assembly heirarchy

Make logical use of sub-assemblies too.
It is unlikely that every part in an assembly of any size would be at the main assembly level.

RE: Inventor assembly heirarchy

(OP)
rollupswx;

agreed; subassemblies will help cut down the length of the assembly tree. however, if you look back at my posts and replace the words that refer to components with your "subassembly" word, then the same issues still hold true; you'll have the same problems with subassemblies as you do with components.

in Solid Edge, we were working with very large files; thousands of items, both parts and subassemblies. there could be hundreds of subassemblies in the family tree; some of these subassemblies were unconstrained, or had constraint conflicts, etc. it resulted in assemblies that you couldn't trust, that had erratic behavior when you modified them, etc. i place a lot of the blame for that on SE itself because it allowed this situation to be possible. i'm starting to get the picture that Inventor works the same way. :(

RE: Inventor assembly heirarchy

I work with assemblies with thousands of components, never once have I had an issue. The only time I ever got constraint errors was when I first learn 3D modelling and I didn't know what I was doing. Sounds more like a case of good 3D modelling practices, not a program specific issue. Logical use of sub-assemblies is a must, and there is rarely an exception.

RE: Inventor assembly heirarchy

ungarata,

I don't remember if Pro/E does it and I don't know if SolidEdge does it or not, but Inventor has an "easy button" when it comes to finding what constraints are messed up. If you have an issue, there is a red plus sign that will light up on the top toolbar, right side. Clicking the plus sign will open the error message box that tells you what constraint is messed up and give you the option to edit the constraint.

RE: Inventor assembly heirarchy

Just for a bit of information, Solid Edge splits the part's constraints into 2 areas with a dotted line dividing the areas.
This dotted line represents the part, so constraints shown above the line are constraints to parts above it in the assembly tree, and constraints below the line are constraints to parts below it in the assembly tree.
In effect this (usually, but not always) means that constraints above the line are the constraints that position the part, whilst those below the line are for parts constrained to the part.
I find this a little easier than the Inventor way of just having one long list of constraints, but then in Inventor you can re-order constraints within the list.
Re-ordering the assembly structure will move constraints above or below the line.
Quite simple really.
Conflicting constraints are indicated in the assembly structure by a red 'lightning' symbol.

As for blaming a cad system for poor assembly modelling techniques.......
I think the answer is you don't leave assembly models unconstrained or with constraint conflicts.
Do it right in the first place and you will have fewer problems later (whether that's solid edge, inventor or whatever).

bc.
Core i5-3570 @3.4GHz , 8GB RAM
Quadro FX4600. W7 Pro 64-bit.

RE: Inventor assembly heirarchy

Quote (beachcomber)

I find this a little easier than the Inventor way of just having one long list of constraints,
Switch your model browser to "assembly view" instead of "modeling view" then constraints are listed below the component they are attached to and not just one long list in a constraint folder.. and you can re-arrange them too if you want. You can also right click on one and select "other half" and it will show you the other part that the constraint is applied to.

RE: Inventor assembly heirarchy

(OP)
beachcomber;

Having used SE for two years, I'm familiar with how it handles constraints; both the good and the very bad. The red conflict symbol is a double-edged sword; it shows you that there is a problem, but it also lets the problem exist. that combined with poor modeling techniques (that it also lets you do) will get some people into trouble, and cause headaches for people down the line who have to work with that data. am i blaming SE for poor modeling techniques? no. am i blaming SE for letting them occur? absolutely. other CAD programs will not let you do some of the things you can in SE (all in the name of "flexibility"), so the data is much more solid. i have seen and worked with some of the most-terrible CAD data you can imagine that was created in SE by someone who didn't know any better, and SE let them do it.

i've opened up SE assemblies that had over 50 red conflict markings in them; how do you troubleshoot it? the order of the parts in the model tree doesn't mean a thing. how do you find the conflict? what usually happened is the person trying to modify the assembly model simply gave up and deleted any constraint that had a conflict, and either left the parts unconstrained or simply grounded them right where they sat. either solution is totally unacceptable.

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Eng-Tips Forums free from inappropriate posts.
The Eng-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Eng-Tips forums is a member-only feature.

Click Here to join Eng-Tips and talk with other members!


Resources


Close Box

Join Eng-Tips® Today!

Join your peers on the Internet's largest technical engineering professional community.
It's easy to join and it's free.

Here's Why Members Love Eng-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close