Assembly rebuild required, but why. Confusing at best. Or Bug?

[Anonymous]

An assembly has shelves that are positioned equally spaced (show with 3d annotations of 12 below). The position is a mate distance computed from an assembly sketch based on projected assembly geometry. The driven dimension of 39 depends on the height of the middle section, which is a parameter in the skeletal model that drives the parts:

The height of this part is changed my editing the parameter. The assembly correctly shows it is need of an update, and a "Global Update" is selected. The result makes it look like there is an error in how the shelf spacing is being determined, but the clue that this in not the case is the 12 inch distances are unchanged. The assembly can be closed and reopened, and the display looks the same:

 After doing a "Manage / Rebuild All" (after wasting time tying to figure out my mistake), the correct result is obtained:

The question is how is one supposed to know when a "Rebuild All" is required? A more subtle change, and without the 3D annotations could easily mean this error was even later, with even more cost...

(Inventor 2018.2, build 227, 10/24/2017)

[blair]

There should be a small "lightening bolt" on the very top of the menu bar that becomes active (changes from grey to yellow). I know, not the best place to look for it but being there makes it consistent for all the different environments (IPT, IAM, IDW and IPN).

[Anonymous]

I should have made it clear that the yellow lightening bolts come on, I choose the update, there is a delay while it does the update, the model changes, and lightening bolts are extinguished.

The problem is the dimensions are incorrect and the shelves are incorrectly positioned until the rebuild all command is selected.

[blair]

Sounds like an error or all the files haven't been properly closed and are still cache'd in memory. A save, and close all, should trigger a global update.

[Anonymous]

1. The skeleton parameter is changed.
2. The lightning bolts in the assembly turn on.
3. A global update is done. Assembly is incorrect.
4. The file is saved and closed.
5. The file is opened. It still complains about still out of date. Yes to update is selected. Still incorrect.
6. Saved again.
7. Inventor is closed.
8. Inventor started.
9. File opened. Still not correctly updated.
10. Only "Manage / Rebuild All" brings it truly up to date.

The project is attached. To reproduce open CabinetFrameAssembly.iam and observe the equal lower shelf equal spacing. Open Skeleton_room#cabinet.ipt and modify user parameter HF_height_M (change it to 8) in the skeleton. Do the update in the assembly and observe the shelves are no longer equally spaced. Do any combination of saving a reopening of the assembly and see that nothing changes. Finally to the rebuild all and see the assembly correct itself.

[johnsonshiue]

Hi! In theory, Rebuild All should never be needed. It should not be considered a workflow. The need to use it indicates something is not working correctly. It could be corruption or bad data or flat-out bugs. I will take a look at the files to understand the behavior better.

Many thanks!

[johnsonshiue]

Hi! I have pulled down the files and I would like to take a look. But, the steps you described are a bit vague. I don't know which parameter to change in order to see the bad behavior. Could you be more specific?

Many thanks!

[Anonymous]

The part to reproduce is at the end of the post:

The project is attached. To reproduce open CabinetFrameAssembly.iam and observe the equal lower shelf spacing. Open Skeleton_room#cabinet.ipt and modify user parameter HF_height_M (change it to 8) . Do the global update in the assembly and observe the shelves are no longer equally spaced (the 3d annotations show the incorrect spacing with correct numbers). Do any combination of saving a reopening of the assembly and see that nothing changes. Finally do the rebuild all and see the assembly correct itself.

So just 2 files need to be opened. The parameter to change is in the skeleton file, and is a user parameter called HF_height_M .

Thanks for taking a look. I have gone through this many times now, and the issue is 100% reproducible. Glad to know that one should not need intuition to know when "Rebuild All" is required!

[johnsonshiue]

Hi! I took a look at the files and I can reproduce the problem. I suspect it has something to do with the compute order. There is an interesting inter-dependency here. This is an example of mixing out-of-context and in-context workflow. The skeletal parameter, HF_height_M is out of context, meaning it is not aware of CabinetFrameAssembly.iam. Nor is it within the control of CabinetFrameAssembly.iam. It drives the change in the parts within the assembly. The assembly sketch has projected geometry from the part and the projected geometry drives a reference parameter which drives the spacing.

The bug here is that the reference parameter at the assembly is indeed up-to-date. But, the equation involving the reference parameter does not get solved. I guess there is a compute sequence issue here. I am able to reproduce the behavior using a much simpler example. I will work with the project team to understand the behavior better.

Many thanks!

[Anonymous]

Thanks for your explanation. I am trying to develop good technique, and know I made some mistakes that made this design more complicated to understand than was my goal. However, I was quite happy with the last step where I got the adaptive equal shelf opening result, and it sounds like you are not saying this is outright invalid. I assume Inventor would detect circular dependencies that have no proper solution. Glad you can reproduce in a simple case, so hopefully it can be fixed.

Is there another way to achieve the final equal spacing? I tried to find more direct ways to do it, and finally was forced in the assembly sketch with projected geometry to be able to calculate an offset distance. 

I did submit an idea to make 3d annotation dimensions exportable as parameters in the BOM, and it also seems if a 3d annotation dimension could be made visible as a parameter then this would give a very direct way to compute offsets based on other geometry. This would make these annotations more than documentation, and deleting them would have to come with a warning of the consequence. Is this worth another idea submission?

[johnsonshiue]

Hi! Actually, there is a more straight forward workflow using iLogic. The iLogic rule at the top-level assembly can access parameters in all components within the assembly. You can drive equations within the rule without having to create sketches to get driven dimensions.

Many thanks!