IV 2023 screws up constraints

[Walter-Eikelenboom]

Hi there.....

Could someone (at Autodesk) please help me with this problem (see video)

Never had this with previous versions and I'm really about to give up (on IV)

Thanks

[kacper.suchomski]

Hi

A question arises in my mind - do angular constraints consider component origin planes or assembly environment global origin planes?

Remember that when one component is rotated relative to the global origin, the angular inclination values of other components relative to the same origin plane automatically change.

When I open the files, I see that many of them are made relative to the global origin planes. Consider whether this is really the right way to define constraints.

[JDMather]

@Walter-Eikelenboom 

If this were my design I would use only planes that go through the axis of rotation for the Angle constraint.

I might also immediately take over to Environments>Dynamic Simulation.

[Walter-Eikelenboom]

Good morning guys,

Thank you both for replying to this post.

The problem I'm having is that it worked just fine in previous versions.

For a few years now, I'm working on a new product, where I fold multiple (solar panel) frames, into small, easy to transport "packages"

I made a few different models of this system using Inventor 2019 (with the same constrains and all) without any problems whatsoever. Even Inventor Studio was able to handle these assemblies.

I placed a few of them on YouTube (https://www.youtube.com/@walasco-3D)

The folding is done using noting more than a smart configuration of rods, (gear) hinges and plates (we patented this so it's (sort of) save to  talk about it here 😉).

An simplified example of this configuration made in Inventor 2023 is shown in this post.

The problem is that when the base (A) is rotated (driven), Inventor calculates a (the) different solution for the plates (F). These plates are kept in place by the rods (D)

Theoretically there are 2 solutions possible for this position. At the start things are okay, but when I rotate it becomes a mess because Inventor uses the other solution.

@kacper.suchomski"Remember that when one component is rotated relative to the global origin, the angular inclination values of other components relative to the same origin plane automatically change"

That would be a new one than 😟

Only part (A) is constraint to the assembly origin planes. All the other parts are constraint to each other.

Arm (E)'s vertical position is constraint to (C) with an angle constraint (DRIVE). If the inputs of this constraint are turned because of a 180 degree rotation, than that would be a (big) problem. But i don't believe that cause (E) isn't constraint to the assembly planes.

But that's not really the problem (i think). Things also go wrong (without driving the arms first (DRIVE constraint) ) when only driving the ROTATE constraint. Even if you delete part (G) !

@JDMatherI think i know what you mean, but even with (G) deleted, after rotating things are going south.

Inventor calculates the wrong solution (position) for plates (F).

Again.... Inventor 2019 handled this without any problem.

What am i missing here.

Thanks again.

[johnsonshiue]

Hi! Many thanks for sharing the files! There seems to be a change in behavior indeed. It should just work. The only way I can mitigate the behavior is to change the ROTATE angle to 179.999 or 180.001 to avoid 180 exact. I cannot explain the behavior. It looks like a bug to me. I need to work with the project team to understand it better.

Thanks again!

[Walter-Eikelenboom]

Hi Johnson,

Thank you for looking in to this (again 😁)

I spent a lot of hours trying to solve this problem and the "funny" thing is that i came to the same conclusion (independent from yours a few hours before your reply)

<179.99 works fine and >180.11 also, but 180 it becomes a problem for IV

As i said earlier, in theory there a multiple mechanical solutions possible for this design (see video)

When the base rotates 180 degrees, IV calculates a different solution then the one intended.

I hope u guys can figure out why cause (and i know I'm repeating myself) in previous versions this problem wasn't there.

🤞

[johnsonshiue]

Hi Walter,

Many thanks for sharing the detail! So far it does look like a change in behavior in the way the constraints are solved. You mentioned that it used to work fine. Do you still have the files that worked before? I would like to do some comparison.

Thanks again!

[Walter-Eikelenboom]

Good morning Johnson,

I can do better.

I saved all parts as SAT (i also did this for the 2023 assembly files to simplify things)

Then i opened those SAT's in IV 2019 (still got that version installed) and saved them as IPT's

I then rebuild the assembly (in IV 2019) without having to watch were i put the constraints (part faces or part planes etc.) and without having to watch what type of (mate) constraint solution i have to use (all undirected)

Then i drive the DRIVE and ROTATE constraints.

No matter what i do.... there is no problem (see video)

Hope this helps.

[Walter-Eikelenboom]

UPDATE:

I copied the 2019 assembly (project) to 2023 (without migrating) and this is what happens (video)

😠

[johnsonshiue]

Hi Walter,

Thank you so much! I no longer have access to 2019. I tried using this 2019 dataset in 2020 and I am seeing the same defective behavior. This means the change in behavior started in 2020. I need to work with the project team to understand the behavior better.

Thanks again!

[Walter-Eikelenboom]

Any news......?

[johnsonshiue]

Hi Walter,

I did not get much feedback from the project team. I will work with the team to understand it better. I am sorry for the delay.

Many thanks!

[johnsonshiue]

Hi Walter,

It seems to be a known issue in the constraint solver (INVGEN-64399). At the moment, there is no fix yet unfortunately.

Many thanks!

[3D4Play]

Johnson, will you please elaborate on this INVEN-64399 issue, tell us where we can see what it's about, or tell us where we can go to track it?

[Walter-Eikelenboom]

Hi Johnson,

Nothing personal of course, but this really s**** for me.

Again, this wasn't an issue in previous releases and now i have a bunch of 2019 models i can't work with.

What a mess

And if i should open them in 2019 I've got a compliance "officer" up my a**

[johnsonshiue]

Hi Folks,

INVGEN-64399 is about the inconsistent solve result. For whatever reason, the angular solve resolve cannot be kept consistently depending on the angular increment. At the moment, we don't know what exactly caused the behavior. Nor do we have a solution yet.

Many thanks!