Inter-component associativity

[DRoam]

I am wanting to know what methods you all use for driving a part's geometry based on the location/orientation of related components in a master assembly. Piping is one example of this, as pipe has to run between two components whose position may change. The Tube and Pipe environment is a possible solution, but only if the scenario involves piping and if you like the Tube and Pipe environment (and many don't). This type of inter-dependency happens often with non-piping parts. For example, a bracket that connects two parts whose distance may change.

Below are the only possible ways I know of to accomplish this associativity currently, and the reasons they fall short:

1. Adaptivity. Adaptivity is the most obvious solution, but I think we all know that Adaptivity can be tricky at best, and dysfunctional at worst--especially when your situation is similar to mine, where my assembly is very large with dozens of components constrainted very intricately, and that's how it has to be. As long as there's no adaptivity, it's very robust and works just fine. Once you add adaptivity, constraints start getting angry and my computer starts getting sluggish. The truth is, we often don't need Inventor to do the very resource-intensive geometric solving required by Adaptive parts. All we really need is for Inventor to check one or two very specific measurements in an Assembly, and to drive a part's geometry based on those.
2. Multi-body parts. This only works if you're actually modeling all of the inter-related geometry within the multi-body part. In my case, I have hydraulic cylinders and other purchased parts, as well as other assemblies which are already complete. This nullifies the multi-body part option. Of course, I could Derive the cylinders and other parts into the assembly, and use a Move operation, and... well that just gets way too complicated, plus... now I'm trying to make an "assembly" within a part, which is just silly.

I said that often all we need is for Inventor to check one or two very specific measurements in an Assembly, and to drive a part's geometry based on that. That would make so many modeling situations so much easier for me, and I assume it would for others, too.

With all of that said, I'd love to have your input in the form of: a) Suggestions of how you would accomplish this associativity with current Inventor functionality, and b) Kudos to the IdeaStation suggestion (link below) if you would use the proposed functionality and think it's better than anything currently available.

Thanks to all for any input 🙂

-----------------------

There are actually to similar ideas.

This is one that I posted some time ago. It has more Kudos at the moment but it's older: http://forums.autodesk.com/t5/inventor-ideastation/driven-quot-constraints-quot-similar-to-driven-di...

Here is a newer post with a very similar suggestion: http://forums.autodesk.com/t5/inventor-ideastation/allow-measument-to-be-saved-as-a-feature/idi-p/56...

Autodesk will eventually mark one as a duplicate if they get enough attention, so please cast Kudos for both so your vote counts no matter which they make the master idea 🙂

[Anonymous]

A year and some months later 🙂

For those who may read this and are trying to perform associative cross-part geometry projection and are struggling with projected geometry being fixed and not associative:

As I mentioned before, the work around for this is to accept the limitation on what you can and cannot project while maintaining an associative state. The idea, then, is to project other geometry that can provide you with the same associative information and/or outcome as the geometry you want to project. For example, if I were to be sketching the tube as I did in the above video and, for whatever reason, I wanted to project the edge of the cylindrical face on one of my "fittings", Inventor would allow me to do so, but it would not allow it to be associative. I should mention that I'm speaking purely from memory and am not actively testing this as I go. So in order for me to get that same edge, I can instead project the top and bottom faces of the cylinder itself and draw the line(s) between them. This would give me the same result and it would be associative.

I believe the pattern in the behaviour has to do with the type of edge/face projected. Once edges are no longer flat, I believe Inventor just has a much more difficult time working with them. And the more "not-flat" they become, the more limited the end user is to work with them. This can be seen when working with a flat face, followed by similar work on a cylindrical face, then followed by similar work on a spherical face. Users, when trying such a thing, will undoubtedly find more difficulty in creating successful features and results when working with the non-flat faces.

Ultimately, and to address DRoam's request directly, the method I use to associatively project geometry that Inventor doesn't want to allow to be associative is to not project that geometry at all. If you're using Inventor and facing this challenge, search for other geometry that can be projected associative that you can use to attain the same result. This may take some time to learn the ins and outs of but with a little patience and practice, you'll find yourself aware, before trying, of what Inventor will and will not make associative and you will be able to get the results you want effortlessly.

Last but not least, I would encourage all end-users to familiarize themselves with the Derive tool(s) in Inventor. Make parts adaptive by cross-part geometry projection can be great in a pinch. It's a very quick way to achieve a result. However, due to the seemingly extensive limitations, I've found time and again that the Derive feature is a far superior method for cross part association. Since this thread was active, I've continued to use Derive more and more to achieve this goal and though it takes a little longer and sometimes you have to use the tool more than once within the same part file to get information from several different parts, I've found great preference for it over other methods. I've said many times before that I believe Adaptivity creates more problems than it solves. I feel as though DRoam has done some extensive research and has come to a similar conclusion and I'm glad to hear that I may not be completely off base.

I'll set aside some time soon, DRoam, and read that dissertation. If you'd like for me to create a quick demonstration of the work-around I described above, let me know and I will do that as soon as I'm able. Should only take a few minutes at my desk and I can easily spare that for a quick video.

Thank you.

[DRoam]

Kudos! Thanks for that detailed answer, Will.

One more question for you: Could you work up a sample assembly from which you can demonstrate both types of behavior--geometry coming in wrong (fixed) and geometry coming in correctly (associative)? A reproducible example is the best way to help Autodesk address this. I've tried to come up with one myself but haven't been able to come up with a good one. Pretty much all the geometry has come in associative (fortunately), except for a few odd lines which I'd never try to project anyway. And I can't find one of my old assemblies that had this issue. There aren't very many since I've learned, like you, to avoid Adaptivity as much as possible.

And that leads me to my second point of discussion. I agree that using Derive functionality, Linked Parameters, and other skeletal-type modeling strategies is the ideal method for cross-part associativity. Whenever two or more parts have associated features or closely related geometry, Multi-body modeling, Sketch sharing, Parameter sharing, etc. are the most robust and streamlined methods to accomplish this. However...

Sometimes the geometry of a part, or the relationship between two or more parts, is driven by factors which can't be represented in a skeletal model. As I've mentioned many times when talking about inter-part design, there are a few common causes of this situation:

• When a part's geometry is determined by a characteristic of its parent Assembly which is not explicitly defined by the design. Example: A part's length is determined by the distance between two other parts, but there is no parameter defining the distance between those parts, because their distance is a factor which is driven by the design/assembly (i.e. a measurement); it is NOT a specified factor of the design (i.e. a constraint). (Hence the need for Measurement Parameters).
• The existence of standard-geometry parts, such as: Structural members, fasteners, piping fittings and adapters, gears and sprockets
• The existence of unique purchased parts, such as: Switches, manifolds, clips, linear actuators, handles, rod ends, etc.

There is simply no way to account for these occurrences in skeletal modeling, because the whole premise of skeletal modeling is that your skeleton contains all of the geometric information necessary to create the parts within its scope. This is not possible when the outside environment (assembly) determines part of the design. And it is prohibitively difficult when standard-geometry or unique purchased parts exist. These can be accounted for, but, as I said, it's prohibitively difficult.

And that is why Adaptivity is so important. Because it's the best, and in many cases the only, method of associatively linking features of a design when one or more of those three elements are present. And those elements are extremely common. Structural members, pipe fittings, and purchased parts are ubiquitous. And whey they are present, because of their integral but fixed nature, they almost always dictate many important features of the design.

Anyway, I wrote all that just to respond to your recommendation of Derive tools. In short, I agree. Adaptivity should be a last resort and should only be used when skeletal modeling techniques (Multi-body parts, derived sketches, derived geometry, linked parameters, etc.) can't do the job. But when they can't, we need Adaptivity to be capable of pulling through for us. Hence the "dissertation" and IdeaStation posts I linked to in my above post.

Sorry for another long post, just trying to thoroughly cover all of the possible discussion points related to Adaptivity and cross-part associativity. I've been wishing for Autodesk to improve this functionality for a long time, but I've only recently been able to sufficiently wrap my head around how Adaptivity currently works, which functionalities should work but are bugged, and which functionalities simply aren't built in but need to be for Adaptivity to deliver on its potential. I think I cover all of that well enough in the long post I mentioned (here). And in this post I've just covered why it's so necessary for Adaptivity to do its job better, even though we do have great tools like multi-body modeling and Derive.

So, hopefully, my job here is done . All that's left is for Autodesk to address the issues keeping Adaptivity from fulfilling its potential. To anyone reading--first of all, have yourself a cookie for making it this far--and second, you can help that process by voting on the Ideas I linked to in my above post, and by adding to the discussion on this thread. Many thanks! 

[DRoam · Accepted solution]

The TL;DR version for anyone who wants it:

1. We need Adaptivity. (Here's why)
2. Adaptivity doesn't work. (Here's why)

What you can do about it:

1. Vote to fix Constraint-driven Adaptivity, Projected-geometry Adaptivity, and Copy Object adaptivity
2. Also vote for measurement parameters and the ability to make a shared sketch Adaptive.
3. Join the discussion here.