Constrain solving - as complicated as that

[Cris-Ideas]

Hello All,

I have started this thread to bring up and hopefully explain problems related to constrain solver and gain knowledge on how exactly constrain solver handles the assembly.

This is because I am experiencing many problems related to assembly solving that should not be expected.

Originally I was discussing this issues in the thread related to problems with flexible assemblies but I decided to split this topics and this thread is intended to focus on constrain solver it self.

I would like to encourage especially people from Autodesk who have the knowledge about constrain solver it self to participate and help us understand better how this works to make our lives easier.

I will be posting videos and data sets, so anyone could try the same what I do and see if is getting the same outcome.

I also would like to ask you to do the same, and if possible use videos with comment rather than long posts, as this is more easy to follow and understand the intent.

I will be also giving each example a name, so it was easy to track replays. So when posting please make it obvious what you are referring to. 

If you are interested in problems related to flexible assemblies please visit this thread Flexibility not working properly in inventor - BUG that has been there for ever

Cris.

[Cris-Ideas]

After this side political discussion let's get back to constrain solving in inventor, that's lacking a lot as we could observe so far.

Now short series about DOFs. First is:

#153.1 - two parts, two constrains and total mess in DOFs !

Any comments?

Personally I would like to be explained if DOFs analysis is directly linked to assembly solver. I would expect so because DOFs should directly come from the solution.

If they come like that = there is no chance this works in complexed scenarios.

data set: # 153.1

Cris.

[johnsonshiue]

Hi Cris,

I appreciate every single issue you have reported. It is a reminder to us that we have room for improvement. Inventor is not perfect we all know. You successfully draw attention from us and we are doing everything we can to help. Certainly, you can say it is not good enough.

But, what is good enough? Do we get your recognition when things are right? Do we get your reward when we found technical problems in your design? If Inventor was not usable, you would not be here discussing issues. You would have moved to a different forum. But, I notice you have helped answer quite a few questions. I again greatly appreciate it. It is more than I had hoped for.

Like I said before, there is level of trust and respect on the forum, which is why we have an engaging user base. I hope we can keep it this way. I have answered all your inquiry based on my best knowledge. If it is not good enough, please feel free to contact any person you know at Autodesk for better answers. As long as you use Inventor, we are here to help.

Many thanks!

[Cris-Ideas]

@johnsonshiue

What would be good enough:

something like that for example:

Thank you for reporting this issue. Fixing bugs is very important to us. 

We have documented this bug with a number .....

Development team is to review possibility of fixing it by ....(date)

Than we will inform you when we expect it to be fixed.

Should you receive no information by .... (date)  please contact  (persons name) (e-mail).

Cris.

[Cris-Ideas]

@johnsonshiue

I appreciate what you do. And what I write is nothing personal. It concerns Autodesk Corporation as organisation.

I do not even have a problem with customer support answering "suppress constrain", when this has no sense.

But I do have a problem with corporation that I feel does not treat me (customer) seriously.

Cris.

[johnsonshiue]

Hi Cris,

You are asking something that I cannot fulfill. I just cannot commit on when a given issue can be fixed. You and I are not in a contractual relationship.

We do have escalating process. Please feel free to contact Autodesk Product Support to escalate the issues. As you know clearly, not every issue is important to fix and not every issue can be fixed in time. I think I have said enough. I would like to focus on understanding the issues and involving the project teams to resolve the issues.

Regarding your sentiment to the company, you are entitled to your opinions. I think you would find it rare to have the same level of engagement, transparency, and responsiveness in other companies, just to put into perspective. Most of the forum users would agree with me on that.

Many thanks!

[Cris-Ideas]

@johnsonshiue

You asked if I give you credit for the bugs you fixed and for the effort you put in making the software better.

Well in general I do by paying for the software.

As for a specific bug I would like very much to be able to announce something was fixed. But really I do not follow everything what is going on. When I encounter something that does not work I bring it up.

In the same time I am not updated when bug I have reported is fixed. When Support case is closed there is usually a link to some article on autodesk website and information "You will be notified when this article will be updated"

But I recall non of the cases where I would receive any update.

Honestly even not to long ago I started to writing a post that was to be titled "This was finally fixed" when I run on to something that surprisingly as so seem to work and as I recalled it was not working before. But it turned out very quickly that it is not working still. So I must have had cancel my post.

If you point me to the bug that I reported and that really makes a difference when fixed I will announce on the forum it was fixed. But in general I do not consider fixing bugs some very big commitment from the software supplier. I rather consider it a normal situation they are fixed, not something that requires special "thank you note"

So now can you explain what is the mechanism of getting so bad DOFs analysis results and if this is also as solver sees this DOFs?

Cris.

[johnsonshiue]

Hi Cris,

#153 is indeed a bug, likely in constraint solver. Another way to prove it, is to simply change the angular constraint to directed or undirected angle. In these two types, the DOF analysis is correct. This is definitely wrong. I will work with the project team and understand the issue better. If you have a case ID, please let me know too.

Regarding credits, I am not asking for any. Your patronage is greatly appreciated. Like I mentioned earlier, I wish all the issues did not exist in the first place. Then, we would not have to deal with bugs. Unfortunately, we are humans and the product is built by people and we do make mistakes.

The problem is that you reported hundreds of issues within a span of weeks, which created an illusion as if the product was not usable. The teams scrambled to resolve the issues. Unfortunately, we just cannot address all of them.

If one takes a microscope to look at everything, all things look weird and ugly. I cannot thank you and other forum users enough for reporting various issues. Every issue represents unsatisfied customers and everyone of them can be an opportunity to improve.

Many thanks!

[Cris-Ideas]

---

@johnsonshiue wrote:
...

The problem is that you reported hundreds of issues within a span of weeks, which created an illusion as if the product was not usable. The teams scrambled to resolve the issues. Unfortunately, we just cannot address all of them.

...

---

just to clarify this.

Indeed I have reported hundreds of cases. But not in a week span, but through years.

In a single week I had never reported more than 10.

Edited

I did check support cases I have access from account I am currently using (approximately 50% of all cases I had in total).

number is 116

61 - closed as change request

14 - open - change request

10 - pending

31 - rest, (solved, unconfirmed, closed)

This covers period form February 2016 till now.

To earlier cases I do not have access, as the other account is no longer on subscription.

Cris.

[Cris-Ideas]

Hi,

This is next ridiculous DOFs analysis from my storage.

# 119.5

As we already know DOFs come from constrain solver this example shows that other things do not work also. And only this simple video shows that:

1) POS REPS do not work

2) DOFs do not work in Master

3) DOFs do not work in POS REPS

4) Constrains are not recognised correctly in POS RPES

5) Constrains are solved badly

so entire assembly modelling core of inventor fails.

Watch and try for your selves.

data set: https://autode.sk/2MQvXrJ

My bug documentation storage folder is full of such things. This is so frustrating.

Cris.

ps. As you can hear in the video comment what I find sometimes surprises even me.

[Cris-Ideas]

Hi,

Let's continue with DOFs before changing to different aspects of constrain solving.

# 153.3 bug

theoretically this two constrain sets produce exactly the same relationships between parts.

But for Inventor it is not the case.

data set available for download: https://autode.sk/2vVYDJm

Cris.

[johnsonshiue]

Hi Cris,

Many thanks for reporting the issue! This is a very good catch! The excessive DOF is indeed a bug in the constraint solver in 2017. It has been fixed on 2018 and later.

Regarding why there is only one DOF when Mate:7 is suppressed, it is because the Nut itself cannot move. The movement is due to the Washer.

Thanks again!

[johnsonshiue]

Hi Cris,

Regarding 153.3, I cannot say I fully understand the point. Indeed, there is difference in DOF Analysis results between the two sets. But, the two sets of constraints are different to begin with. Axial Mate means the offset distance between the two vectors have to be fixed, while Angular constraint does not require offset distance. Although the component movement behaviors look the same, the underlying constraint systems are different.

Did you report it as a case? What is the case ID?

Many thanks!

[Cris-Ideas]

@johnsonshiue

Hi Johnson

regarding #119.5

You have many times stated that:

- constrains do not have master and slave components,

- constrains in the assembly do not have any hierarchy,

- constrains are bidirectional.

And now you say that nut is following the washer. Why should it follow the washer and why it should not be the washer that follows nut, or even why should it not be the bolt that should follow all other components?

There is no logical explanation I can find to justify why it is the nut that is following. Especially that  nut has constrains directly with the top level assembly.

Also DOFs are by definition degrees of freedom in top level assembly coordinate system. DOFs are properties of each of the assembly components and they are individual properties of those components.

There are other examples (few posts earlier) which show what you just stated regarding #119.5 is not true.

Take for example data set from the first post. There is also a nut and a washer that move together but each have indicated translation DOF.

Inventor should indicate DOFs according to what DOFs are free in the context of top level assembly coordinate system for each component independently. Components that can have DOFs indicated as "cubes" moving with other components can be indicated only in graphical window in case they are fully constrained with other components or components groups that have free DOFs.

I encourage you to examine how DOFs are indicated for various simple  examples from this thread and also from other threads regarding flexibility you know.

You will easily find inconsistent behaviour and see that what you stated regarding #119.5 will not be valid for other cases.

From my experience I can tell that DOFs analysis fails in different way for various constrain types, and for various constrain sets between various sets of components.

This is just working inconsistently.

Cris.

[Cris-Ideas]

@johnsonshiue

Hi Johnson,

Regarding #153.3

Design intent in this case is as follows:

For two identical sets of components,

define various constrain sets,

that produce exactly identical positional relationship between component pairs,

and show that components having in fact exactly identical DOFs are indicated as having different DOFs by inventor.

And that's exactly what is shown in the video.

As for support cases.

I am reporting all. But currently forum and Support cases got slightly out of sync. So this one is most probably still waiting.

Will update you.

Cris.

[Cris-Ideas]

@johnsonshiue

Hi Johnson,

I am playing now with simple DOFs examples for several hours straight. And I have come to the point where I feel we need clarification what exactly DOF is, according to Inventor.

Could you give us theoretical, mathematical definition of DOF in inventor, according to how it is designed in the software.

Maybe it is the case so DOFs in inventor are not DOFs of real life, in such case we need to understand what they are in order to use them.

Cris.

[Cris-Ideas]

Hi,

I was playing a bit after Johnson wrote that nut is following the washer.

And I have following example that is not following this concept.

DOF is indicated for part that actually "should follow" the other component.

As you can see although part is "following" local coordinate system along X translation this DOF is indicated explicitly for the part after Y translation of the part in local coordinate system is free. But this translation is totally dependent form translation along global X in this example. So it should not influence DOFs analysis, the same way as allowing for Z translation of part in local coordinate system is not influencing DOFs along X analysis.

But allowing Y translation DOES influence DOFs analysis for X translation.

"Should not all axes be equal?

Or Y axis is somehow special, and most equal of all axes?"

#153.3A

data set for download: https://autode.sk/2Lpgi10

Cris

[johnsonshiue]

Hi Cris,

You got me on this one. I don't think I have an answer to that. The constraint solver is proprietary. I am not sure if we could make such information public. I will work with the project team but I don't think I would get an answer soon.

Many thanks!

[Cris-Ideas]

@johnsonshiue

---

@johnsonshiue wrote:
...I will work with the project team but I don't think I would get an answer soon.

...

---

do you mean answer to the question:

What exactly is DOF in inventor?

If so I am sure this must be made public as inventor does DOFs analysis, but clearly results do not follow real life understanding. And in such case users, mostly engineers, must know exactly what is that analysis considers DOF.

I see two potential options here.

1) DOFs as inventor understands them should follow real life understanding of DOFs, and in such case DOFs analysis should give results accordingly (currently it does not do that, so this would be a bug than)

       or

2) DOFs in inventor shear only the same name with real life DOFs, and in such case we need to know what exactly are they.

I have played with them whole day today and I must say I do not understand the logic behind this. It seems so complicated comparing to real life understanding that I really do not have clue what is DOF according to inventor.

Also from the results of my "studies" it seems that both constrains and parts in assembly follow some order.

This would however be contradictory to everything you stated in this regard in the past.

So quite obvious question is:

How this really works?

Is there in fact hierarchy of constrains and components in the assembly or not?

If there is, than how it works?

I personally think there should not be, as this would be the most robust and stable solution. This is also perfectly in accordance with theory behind constrain solving. But who knows what is inside inventor.

I think I will leave you with those questions for some time, hoping you will get back with some final and clear answers. I am not asking you to revile constrain solver coding secrets, but to answer simple bur fundamental questions on how this software works for user.

I will leave DOFs for some time, and bring up other constrain solving related problems that are waiting.

until tomorrow.

Cris.

[Cris-Ideas]

Just a quick video.

Good Job Autodesk,

Bravo!

What an improvement this is!

or wait. IT IS NOT!!!!

I wonder did anyone in Autodesk tried this before making users to try?

Is this SERIOUS?

Cris.

[johnsonshiue]

Hi Cris,

When you recorded the video, "Enable redundant relationship analysis" option is on, right? I think this is related to the defect (not being able to flip) that you reported earlier (INVGEN-19140).

Many thanks!