Positional Representation Bug

[skotzur]

Hey everyone, we've used this workflow in the past without issue, but it started to give us grief in the past 6 to 9 months (maybe 20202 issue?)

We'll have an assembly (Assembly1) with several positional reps (1) & (2). The master may be the same as one of the positional reps, or it may be unique. In the master certain constraints are suppressed so that there are no conflicts. Each positional rep will have certain overrides either suppressing, or enabling constraints as needed to form that positional rep.

We have a second assembly (assembly2) into which we place Assembly1 and use one of Assembly1's Positional Reps.

-or-

We have a second assembly (assembly2) into which we place Assembly1. Assembly2 has positional reps (1) and (2) and in each of those positional reps we go into assembly1 and select its corresponding positional reps. (1) in (1), (2) in (2), (master) in (master).

These positional reps are used to represent the same collection of parts in different orientations. We don't want a separate drawing or BOM for these different representations, we just want to be able to display it in different configurations where needed.

Well, the issue that has developed is that you can open and look @ Assembly1 and everything is fine. Then you either return Assembly1 to the Master Positional Rep, or close it. Then open Assembly2 and try to update it, or drag some part of it that's flexible. A red Cross develops and upon inspecting, there are now newly developed constraint issues in Assembly1. ALL constraints are now active and unsuppressed in the Master Positional Rep of Assembly1. This causes conflict in the master and also many of the other positional representations.

I've linked the following 2 videos. These were developed for internal circulation, so my apologies in advance if they don't meet certain community standards or drag on for a bit too long.

https://drive.google.com/file/d/1MJfKNlJfvHu537skC5uZr9xausmdNIEZ/view?usp=sharing

https://drive.google.com/file/d/1JKfGhmSxKZK7SBreCHom-1U7txKYpVeO/view?usp=sharing

[karthur1]

Watched the first video where the 05077.iam gives an error when you select the master PR. Not exactly sure why it is happening, and difficult to even guess what is going on without looking at the assembly structure.

After you get the error, have you tried to do a "rebuild All" on the iam? That should clear the errors.

For the second video, again, it is very difficult to actually tell what is going on without the model.  I dont even see the "Cab-Pendant_E01.iam" in the "12054-05.iam".

[johnsonshiue]

Hi! Are you on Inventor 2020 or 2021? Please share the Inventor files with me directly (johnson.shiue@autodesk.com). I would like to understand the behavior better. Either it is a bug or there is a logical reason.

Many thanks!

[skotzur]

Johnson,

Thanks for your reply. We're on 2020 and we're up to date with updates. I'm swamped right now but I'll get something off to you within the next 24 hours via email.

Scott

[J_Dumont]

Going by what I see in the videos the problem seems to be happening if you change the Positional Rep of the sub-assembly without editing it first. I tested with several of my own examples and I was able to reproduce the issue.

However, if I edit the sub-assembly first, I am to change to any Pos Rep and then activate Master without any issue. It appears that if the sub-assembly isn't being edited in the context of the parent assembly, Inventor cannot modify the suppression of the constraints.

It seems to be working as designed.

I hope this helps.

[skotzur · Accepted solution]

Jim,

I don't know if what you're saying is a direct solution to my problem, but it did spark a distant memory that was covered with cobwebs and had a few inches of dust on it. It led me to a reasonable workflow that avoids errors, but I still believe that the behavior is undesirable.

In the following video I start with the inital behavior with a few more details than last time because it may not have been entirely clear to everyone what was going on.

At 3:30 I demonstrate a method for working with the assembly and successfully prevent the red cross. It works, but is less than ideal. It's alleviating the symptom without really addressing the cause. 

At 4:12 I demonstrate an even better workflow that's less of a temporary band-aid and more of permanent solution.

When it's all said and done though, the inability to use nested master flexible assemblies seems like a bug to me.

https://drive.google.com/open?id=1tM6PTajbkx4Yobajvnbgn3D2QkJjQqdy

[johnsonshiue]

Hi Scott,

Many thanks for sharing the files with me personally. I am in the process of downloading them. After that, I will take a look and get back to you with my findings.

Thanks again!

[skotzur]

@karthur1, Thanks for weighing in. Rebuild all has not resolved this issue. I haven't attempted it on these assemblies in particular, but I have used it in the recent past on similar assemblies to no avail. 

I understand your confusion with not having seen the CAB-PENDANT_E01 in the browser. At some point in its history it was renamed and the browser nodes were never renamed to reflect the change. In the more recent video I take a bit more time to explain the assembly structure and our workflow. If you care to watch it, it may be a bit more clear for you to follow, although it's a bit longer than the other ones(7:45 I think).

[johnsonshiue · Accepted solution]

Hi Scott and Kirk,

Without disclosing the detail of Scott's files, I can acknowledge there is a bug here. PosRep and Flexible do not play well together as discussed by several threads on the forum. PosRep intervenes constraint solves in a bad way leading to inconsistent behaviors. There are usually "workarounds" to bypass the flaky behaviors again. But, sooner or later, the flakiness will be back.

On 2021, we made significant improvements on PosRep and Flexible. Scott's files will work as intended on 2021. If possible, please try it on 2021.

Many thanks!

[SER4]

It appears that this is related (probably even directly related):
https://knowledge.autodesk.com/support/inventor/troubleshooting/caas/sfdcarticles/sfdcarticles/Const...
I'm on 2022.3.1, and still having problems with Flexible and Pos Reps.  Something that did work on the Master Pos Rep, will not work on a custom Pos Rep.

It seems like all the custom Pos Reps are "built off" the Master (hence the 'Override'), which I'm starting to think doesn't make good sense.  Seems to me that each Pos Rep should be just its own thing by itself?

[johnsonshiue]

Hi! Yes, it could be related. We used to have issues in Flexible + PosRep workflows. As of 2021, things get a lot better. If you are still seeing a problem, please share the files here or send them (zipped) to me johnson.shiue@autodesk.com directly. I would like to understand it better.

Many thanks!