Constraint Bug / Mystery

[cwhetten]

I have two parts (a pipe and a valve) in an assembly that have 3 IDENTICAL angle constraints, and these are driven by some fancy parameters.  When the parameters change to certain values, one or more of the angle constraints on the pipe fail, even though the IDENTICAL constraints on the valve solve properly.  I'm at wit's end trying to understand why.

Open the assembly and find the parameter called TeeOrientationAngle (to more easily find the pertinent parameters, turn on the key parameter filter in the lower left corner of the parameters dialog--see image below).

Change the value of TeeOrientationAngle to 45 degrees.  Both parts change alignment properly.

Then change the parameter called ElbowOrientationAngle to 45 degrees.  Again, both parts align properly.

Now change ElbowOrientationAngle to 90 degrees.  There will be an error.

The constraint named Angle:12 under _GaugePipe4 will become sick.  But, its identical twin named Angle:21 under _GaugeDrainValve will be just fine.  These two angles, being created in the same way, should not have different solutions!!! 

Try suppressing the sick Angle:12 just to be sure that its twin is solving properly.  The design doctor will go away, indicating that all is well.

I am stumped.  Did I miss something?  Is Inventor flaking out (i.e. bug)?  Angle constraints are hard enough to control without apparent inconsistencies like this, so I'm hoping I just missed something.  Anybody want to take a stab at it?  The assembly is attached (files are version 2014).

Cameron Whetten
Inventor 2014

[admaiora]

Can be something iLogic related with the rule0 ?

[salariua]

I looked ove the constraints and all the project. It seems to be done correctly, but I bet the problem is when you multiply by "-" to change direction.

I have elbow on 0 deg and the tee seems fine between 0-90 and 270-360 deg.

You gonna have to narrow it down but here's how I've done it to check it reall quick.

Created a form and added the elbow and tee orientation angles with a controller of type slider , min 0, max 359, step 5. and drag the sliders to check realtime update.

[cwhetten]

There's an iLogic rule in the assembly called "Angle Testing" that cycles through values of each angle parameter in 45-degree increments.  But I like the slider idea much better.  I'll use that to help me look deeper at the problem.

It could be in the negative multiplier, but it seems to me that a problem like that would manifest identically in both parts, not just one or the other.

Any other thoughts?

[salariua]

It's kind of hard to guess your problem. In your original post you tell us what to change in order to replicate your error. We did and found the error. Maybe you want to explain with some images or descriptions what are you trying to do. Others might come with different solutions as you've seen above with controlling the angle via forms.

[wimann]

I can't say for sure that what I'm thinking of could be causing the problem but I will say that I often avoid angular constraints in assemblies simply because each regular angular constraint has two solutions and sometimes the negative and positive "seem" to switch on me.

If you're already using iLogic, what I would likely do is make a part file which these parameters are passed down to then use those parameters at the part file level to move either planes or sketch lines or (take your pick) then constrain your parts to this "driver" part file. If you're using sketches, depending on the range of possible angles, it may be worth dimensioning your angle from a line that does not match your zero deg measure. This would allow your angle to be less than zero and not confuse the lines about which way the angle should travel. The idea is to not let the value that drives the location of the line drop to zero becuase once it is zero, there are two possible outcomes for 1 deg.

Anyway, that may not be the issue here but without testing it out, that would be something I would keep on my list of possibilities.

Hope this helps.

[salariua]

Like I said we are only guessing here and if he presented the files, or the idea of what we are trying to solve it might be easier.

But nonetheless Kudos to Will for mentioning the plain / sketches constrains. I have used them to drive my ifeatures, (position and angle) very successfully but din't think it would apply here.

[cwhetten]

Hi all, I appreciate the responses.

Here is a picture of the assembly that I am working on.  It is a pressure gauge line that goes into a larger piping system. 

The end user will need to be able to adjust the orientation of the piping by changing the two angle parameters I mentioned (ElbowOrientationAngle and TeeOrientationAngle).  The elbow orientation angle changes the angle of the entire assembly at the elbow, rotating around the green axis highlighted in the image.  The tee orientation angle changes the angle of the drain valve (the blue valve) at the tee, around the yellow highlighted axis.  The two blue parts in the image (the valve and a piece of pipe) need to be aligned with each other, but they must be constraned to the assembly origin only, not to each other or the tee or any other parts in the assembly (because we will be doing a lot of component replacement as pipes change size and valves get swapped out).

In order to align the two blue parts, I created the identical angle constraints that I mentioned initially, and that is where I am seeing the error.

I suspect that the end user will only need to adjust the angles in 90-degree increments, and it currently works for all of these, but I wanted to figure out how to make it work no matter what angles are specified.

I guess I was posting here to see if the error I am seeing is a bug.  I wanted to get some more eyes on the issue, in case the error is mine, and not the software.

Cameron Whetten
Inventor 2014

[wimann]

---

@cwhetten wrote:

...The two blue parts in the image (the valve and a piece of pipe) need to be aligned with each other, but they must be constraned to the assembly origin only, not to each other or the tee or any other parts in the assembly (because we will be doing a lot of component replacement as pipes change size and valves get swapped out)...

---

You can always constrain their relative origin planes/axis/point to one another. Then replacing components shoudn't be an issue as the origin features always exist. Though, so long as the ball valve and pipe are created the same way every time (no matter what the size change), you should be able to replace component even with geometric constraints without failures. But at the very least, their origins could be constrained together and/or to the origin features of the Tee.

Nevertheless, I don't really see a good reason for the constraint failures you've been experiencing. I'd just say that even though what you're trying should work, there may be another way that will work all the same that won't throw the same strange error. Just my 2 cents.

Have a good one Cameron.

[salariua · Accepted solution]

I had a go with this, didn't had all files, had to add my own, and hope to get the attachment trough (1.5M)

Here's the end result, changing angle every 15 degree, can't see you using lower step size for this.:

Removed all parameters, and ilogic, only added a form to drive my 2 parameters.

[wimann]

Good call on the assembly planes (undoubtedly) driven by the angles.

I would think that with the set up you have there, you ought to be able to do whatever increment you wanted to. But you're right, 15 ought to do.

[cwhetten]

Yes!  Assembly workplanes are brilliant!  I was overthinking it all.  The planes are so much easier to control, and any constraints to them are properly retained after component replacement.

Will, you mentioned constraining between part origins.  Yes, that works well, and these constraints are retained after component replacement.  But this assumes that the origin planes are in useful and consistent positions to begin with.  In this scenario, I am using content center tees and elbows, and a lot of these were poorly designed with regards to origin placement.  This poor placement can be mitigated with constraint offsets, but only to a point.  I was trying to avoid doing this, but maybe I was trying too hard.  You and Adrian have helped me to realize I was going about this all wrong, and I stupidly forgot to keep it simple! 

Thanks, Adrian.  Assembly workplanes are a fantastic workaround.

Cameron Whetten
Inventor 2014

[salariua]

The only limitation with this is:

Even if you set the assembly as flexible it can only have one set of angles, as soon as you change it for one project it will change in all projects.

What you need to do is control the movement from one level up (parent assembly). You need to set a bit of ilogic like this.

ADS_Elbow_Angle = Parameter("ADS_Angle Test 1:1", "ADS_Elbow_Angle")
ADS_Tee_Angle = Parameter("ADS_Angle Test 1:1", "ADS_Tee_Angle")

translate as

Assembly_Elbow_Angle_Parameter = Parameter ("Subassembly name ", Subassembly_Elbow_Angle")

I have given same name for parameters inside asm as in part so that you can copy/paste the form and export/import parameters.

Let me know how are you using this, what problems you have with it.

[cwhetten]

I am developing a master model / job template model.  When my clients win a new bid, they will create an independent copy of the master model, and then adjust the copy according to that specific job's requirements.

This is all controlled through parameters and iLogic code, and it's all done with a "top-down" approach, from the parent assembly file, as you said.  It's all coming together rather nicely, and now that I've got a much simpler approach to the orientation angle of the gauge piping, I can move on to the next area.

Thanks again.

Cameron Whetten
Inventor 2014