Adaptive part won't adapt

[DRoam]

I've been working with adaptive parts for a while now so I think I have a pretty good handle on how they work, but I've tried every trick I know and can't get this adaptive part to adapt correctly. When I apply the final constraint, which should drive its length, Inventor tells me it's an inconsistent constraint. If the part would adapt, it should be perfectly consistent. I've attached my workset, the constraint I'm trying to apply is "Flush:17" under "Side Guard Plate" (the last component in the browser tree). Can someone tell me if I'm missing something that's causing issues with the adaptivity?

[JDMather]

Isn't this basically the same problem as this one http://forums.autodesk.com/t5/Autodesk-Inventor/Adaptive-cylinder-length-not-adapting/td-p/3940056

I would have used this to locate and define my sketch plane and projected geometry to use adaptive sketch constraints rather than assembly constraints.

[Anonymous]

The problem is in your rectangle sketch in Side Guard Plate.

The rectangle is constrained about it's center, and this fights with the other two geometries you want to refrence.

Just window the midpoint in the sketch and delete it, you will get an error once, and then it should be fine.

Scratch that,  I was gettin the error because I projected something as a test.

Deleting the rectangle center constraint will fix it all fine and nice.

T.S.

[DRoam]

Thanks for the reply, JD. I think I see what you're suggesting. Constrain one end of the part in the assembly, then edit the part within the assembly and constrain the other end via a sketch constraint to projected geometry, correct?

A couple quick questions. One, why won't it work the way I was originally trying to do it? If the geometry doesn't conflict with the constraints I'm trying to create, Inventor should be able to solve it, shouldn't it? Two, is there a reason I should favor constraints at the sketch level over assembly-level constraints and adaptivity? I've always preferred the latter because it seems more streamlined, but if the former is more reliable I'll try and adjust my workflow.

tsreagan, thanks for the input, I'll experiment with your suggestion too and see if it helps.

[Anonymous]

The way you were trying works,  its just the center constraint giving you grief.

Though I had issues using this method,  I tend to do it as stated above, (within a sketch while edit in place.)

That way if you change parts to the point where you lose faces and thus connections,  it is easier to track in the sketch, purple colors, yum.

T.S.

[JDMather]

---

@DRoam wrote:

 I've always preferred....

---

Either way you do it - I would do it with the part plane co-planar with the red face in the image I attached.

[Anonymous]

So not to confuse, if you want it the way you have:

save and return to ASM,  unsupress your constraint,  all woks fine.

I should start tryin this method more, in simpler situations,  it seems the bugs are not as prevelant now.

T.S.

[Anonymous]

JDMather has pointed out a key concept as  well.

When you first start a part,  think of how it will relate to the rest of the ASM, and choose the initial work planes based on ease of control from the main ASM and how your part relates to it.

T.S.

[Anonymous]

JDMather,

I use your method,  but in all honesty, I tried(and wanted) the direct method Droam is using when I first started with Inventor, and never could get it to work without blowing up on me. So I resorted to the more stable sketch projection method.

I was impressed to see it work fine in this example,  I will experiment with it and see,  maybe it's not so buggy now, or maybe I was too inexperienced to get it working smoothly then.

I don't know if you have tried the assembly method recently.

Maybe your in the same boat as me, and mainly doing it the long way because of such grief experienced early on.

T.S.

[DRoam]

Ok, I was able to get it to work both ways, via cross-part projection (after deleting the center-point constraint), and with assembly constraints (after deleting the center-point constraint).

This is great, and will probably serve my purposes. I'm concerned though because I have the center point constrained for a reason--so that I can use the orign planes for constraining to the middle of the plate if necessary. I'd like to still have that option available even when the plate's lengh is driven adaptively. A solution which allows both would be fantastic.

[Anonymous]

In the Side Guard Plate:

Create Plane between two planes,  and it will make an adaptive center plane for you.

T.S.

[DRoam]

I'd wanted to avoid that but I suppose it will work. I'm dealing with a standard plate template that I place from content center and contains iLogic that we use for BOM purposes, so I was hoping to not have to do a whole lot of modifications as I'm placing them and using adaptivity. I thought I'd worked like this several times before and not seen this issue, but I guess I haven't constrained one of these plates quite in this manner before. Anyway, I think I can make the suggestions you and JDMather suggested work, thanks to you both for your help.

However, I'm reluctant to accept any of your posts as a solution because I don't feel the issue has been resolved; I don't see any reason why the original way I wanted to do this would be an issue. As far as I can see, there's one and only one solution to the geometric constraints I applied, so in my opinion this is a bug. So I'd rather see Autodesk fix it than say I'm ok with a workaround. 

[Anonymous]

There may be a way to get your center plane to behave,  instead of center constraint,  dimensions and a formula may allow the other constraints to be in place,  you might play with that,  I know what you mean about adding things to the standard parts,  I don't like to do that either.

Ohh, and I am not concerned about solution tagging stuff...   Unless I get a hot chick after x number of solutions 🙂

I just comment in here for you guys benefit.

T.S.

[JDMather · Accepted solution]

---

@DRoam wrote:

 I don't see any reason why the original way I wanted to do this would be an issue. As far as I can see, there's one and only one solution to the geometric constraints I applied, so in my opinion this is a bug. So I'd rather see Autodesk fix it than say I'm ok with a workaround. 

---

I don't think it is a bug, I think it is normal parent/child behavior.

The parent existed before the child and the child can't force the parent to move.

In this case the parent feature of relevance is the Origin Center Point.

The centerpoint rectangle in sketch cannot force the parent origin point to move as the rectangle changes size.

Edit:  I take all that back after editing SideX dimension.  Let me look at this a bit more.

If you had placed such the the origin was at the lower left corner in image and used a 3-point rectangle I don't think you would have seen an issue because the origin would not have to move for the rectangle to change size.

[DRoam]

---

@Anonymous wrote:

I don't think it is a bug, I think it is normal parent/child behavior.

The parent existed before the child and the child can't force the parent to move.

---

This just got a little over my head... haha, I think that makes sense though. It seems somewhat limiting to me, but it makes sense.

[DRoam]

---

@Anonymous wrote:

Edit:  I take all that back after editing SideX dimension.  Let me look at this a bit more.

---

Oh ok, thanks a lot. I thought I hadn't seen that sort of limitation affecting my designs before. I'm curious to see what you find. Many thanks for your expertise.

[Anonymous]

When your designs become more complex, you start running into these types of errors more often.

Most users start out with simple configurations and get used to a certain work flow... one that tends to... well you just want to pull your hair out on larger more complex designs.

I still don't fully understand the dynamics of parent child,  as it gets fuzzy when you add two components at the same time and then create adaptive connections between them and the main assembly.

Maybe JDMather has some more tips on this,  perhaps an order of constraint placement rule of thumb, or something ?

T.S.

[DRoam · Accepted solution]

Even though he second-guessed his answer later, I think JD was correct that this particular issue was due to the Sketch rectangle being constrained by its centerpoint. Basically, the Adaptivity would have to re-size the part AND move it to get it to satisfy the constraints, which is generally a no-no with Adaptivity.

The general rule with Adaptivity is that the Adaptive part's position should be fully defined first, whether using the origin planes or fully-defined and non-adaptive part geometry (faces, edges, etc.). Once the position is fully defined by constraining fully defined features, constraints can then be applied to drive Adaptive features as appropriate.

The problem with what I was trying to do in this case, is I was trying to define the part's position by constraining a non-fully-defined (i.e. adaptive) feature, and then also drive its geometry by applying a second constraint to the same adaptive feature... so a double no-no. JD's suggestion was to re-constrain the part's base Sketch so that the corner was at the origin of the part. I could then, in the assembly, apply one constraint to the end of the plate (the "origin") to define the position, and then apply another constraint to the other end to drive the adaptive feature--thereby following the rule stated above.

That said, even following that general rule can result in broken assemblies if Inventor gets its wires crossed as to which constraint, along a given degree of freedom, is meant to define the part's position, and which is meant to drive the Adaptivity. I believe it's this inability to specify the driving/driven direction of a constraint on an Adaptive part which leads to the majority of Adaptive assembly failures, even when it's set up 100% properly.

Because of this gap in Adaptivity control, I've created the following request in the IdeaStation: Option to designate constraints as ‘Adaptivity-driving’ rather than ‘Assembling'.

If this additional control is added, combining proper use of that control with the rule stated above should result in 100% robust Adaptive assemblies.

[DRoam · Accepted solution]

Just wanted to add something to this thread, because it's directly related to the topic of Adaptive parts not adapting and may be enlightening to those struggling with this issue.

Ever notice how once you've applied a constraint to an Adaptive part, you can no longer drag whatever you constrained it to in order to make your Adaptive part... adapt? Take the following assembly for example:

Say I've set up the pipe to have an adaptive length, where the left end is the "origin end" and the right end is the "stretching end". Then I constrain it to an I-beam at each end as shown in the picture.

Then say I want to drag one of those I-beams to increase their distance. Well, guess what? I can't, because the so-called "adaptive" pipe is constrained to them, and the only way I can change the I-beams distance is by actually applying a constraint to control their distance, thereby over-riding the pipe's current length and causing the Adaptivity to kick in.

How silly is that? My pipe is supposed to be "adaptive" and yet it's actually preventing me from moving the I-beams it's supposed to adapt to. It's actually dictating where things are in my assembly rather than adapting to where they are like it was designed to.

Why? This is why: because Inventor has no idea that the constraint on the stretching-end of the pipe is ONLY supposed to adapt the pipe's length, it's NOT supposed to tell the I-beam where it should be.

But Inventor doesn't know this, so until another constraint is applied and says otherwise, Inventor's not going to try to adapt the length of that pipe, and it's definitely not going to let go of the constraint on the stretching-end long enough for me to re-position the I-beam where I want it.

But what if it would? What if Inventor knew that the constraint on the stretching-end of the pipe could be "relaxed" while I move the I-beam where I want it, and THEN re-applied to stretch the pipe to its new proper length?

What if, indeed. Hit the up-vote button on this Idea to find out. All I can tell you is, it's gonna be good, and you'll be amazed at how much better Adaptivity works.