Serious problem.. discovered mirrored part in assembly didn't update with base

[bl1droid]

Inventor 2019.3 win 7 pro

I finished a large assembly last week that just had one of our CNC guys come to me saying that a LH version of one of my parts was not symmetrical to the RH on its hole spread.  I told him that wasn't possible..... I opened the base part and the derived mirror and checked it and sure enough the LH parts hole spread is off by a 1/16"..  the LH part is a straight mirrored piece off the rh, the update button is greyed out on the part.. no lightning bolts.. So it shows no signs of needing an update...  I remember updating the rh/base part and changing the hole spread a week or so ago.. but the LH part didn't update.  Why this is really bad is that my main baseplate has its holes projected off of those pieces.. so now its holes will be wrong for the LH part if i fix it.  Upon examining the LH part.. if i click edit derived part inside of it.. i can watch the holes move to the correct location.. cancel the edit and they go back wrong again..click ok and then they update correctly.  Now though since the main baseplate these bolt two is finished i had to suppress it so it won't change.  This is a major issue.. i use mirrors and hole projections throughout designs and trust that they actually update with changes.  Talking to one of our other engineers here about it, he said he had a part the other day as well that didn't update but noticed it and clicked around on the mirrored part until it updated.  I'll be glad to share the data.  This is bad.  I attached a pic of the lh and rh part.. from the assembly and you can see the lh part in the browser open.

Brian 

[Cadmanto]

When you mirror parts in Inventor, it creates completely new independent parts.  So, if you modify the RH one, the LH one will not reflect those changes.  You have to modify both of them.

Windows 10 x64 -16GB Ram
Intel i7-6700 @ 3.41ghz
nVidia GTS 250 - 1 GB
Inventor Pro 2018

[bl1droid]

It is a derived part.... mirror.. it is not an independent part.. it is dependent on the base it is referenced from.  It  better update.  It has since R1.  See attached pic.

---

@Cadmanto wrote:

When you mirror parts in Inventor, it creates completely new independent parts.  So, if you modify the RH one, the LH one will not reflect those changes.  You have to modify both of them.

Windows 10 x64 -16GB Ram
Intel i7-6700 @ 3.41ghz
nVidia GTS 250 - 1 GB
Inventor Pro 2018

---

[Cadmanto · Accepted solution]

Did you try doing a rebuild all in the part?

And in the assembly?  

Windows 10 x64 -16GB Ram
Intel i7-6700 @ 3.41ghz
nVidia GTS 250 - 1 GB
Inventor Pro 2018

[bl1droid]

Just tried rebuild all in both.. no change in either.  The only way i can get it to update is to click edit derived part.. and click ok, then it updates...

[rhasell]

Hi

I agree with you, this is a problem, and errors can go to manufacture. (Mine is not a mirrored component, but still derived components)

I had I had a similar experience yesterday. The derived components were not updating, and not matter what I did, nothing could force the updates to propagate through to the various parts.

The fix for me was to switch off the the "Export Object" and then switch it on again.

[johnsonshiue]

Hi! The behavior does not sound right to me. Please share the files here or send them to me directly (johnson.shiue@autodesk.com). I would like to understand the behavior better.

Many thanks!

[bl1droid]

Everybody.. please pay attention to your derived parts.. it is confirmed that there are instances where Inventor does not recognize that the part has changed and therefore does not attempt to update it.  Rebuild all does not work on these instances and the only thing that will correct it is to do an edit on the derived part and let it rebuild it.  From my conversations with Autodesk, they do not currently have a solution to this problem.. it is a "perfect storm" type event when this happens.  We have seen it twice on 2019 here from two different users.  Please be aware of this and keep an eye on your parts when and where you can.  Hopefully this issue will be corrected in future releases.  I've been using since R1 and have seen a lot of issues come and go.. fixed.. return again.. fixed again but don't recall coming across this one before.

thanks,

Brian

[DRoam]

@johnsonshiue, is this a regression in 2019? Or is the cause unknown?

Regarding "Rebuild All" not updating the part... this seems to be a fairly common problem in Inventor -- where "Rebuild All" does not, in fact, mimic rebuilding the feature history of all parts, as it should. Reading this thread brought to mind another conversation where editing a coil feature and clicking "Ok" gave different results than doing a Rebuild All.

Johnson, why does Rebuild All not always rebuild all? Is this an intentional limitation, or something that could be improved?

[johnsonshiue · Accepted solution]

Hi Derek,

This is definitely a bug, a geometry specific bug. If I understood it correctly, I don't believe this is a regression. Brian sent me the files exhibiting the behavior. I can describe the situation without disclosing his design. Basically, there is a rail with a bunch of holes. The derived mirrored part does not update when the hole spacing is changed in the source part.

The trouble happens within the algorithm determining if a given part has been changed. For performance purpose, Inventor uses a concept of checksum to laundry-list geometry. When the checksum is not changed, it means the part geometry has not been changed and there is no need to trigger an update in the derive part.

Rebuild All does not trigger an update because the checksum still returns the same value in this particular case. Editing Derive node force the geometry to be reloaded. As a result, it becomes updated. The bug here is that why the change in hole spacing does not change the checksum value. We have similar problems before but it is somewhat random or somewhat geometry specific. Something is wrong for sure. But, we cannot guarantee it always works. I am aware of a fix we made in the coming 2019.4 to address a similar case but I need to confirm with the project team.

Many thanks!

[DRoam]

Thanks for the explanation, Johnson. I'm vaguely familiar with how checksums work so that makes sense.

Except for one thing -- I could understand why such a checksum would cause an Update not to recalculate a feature; but I would have thought that a "Rebuild All" would recalculate all features period. I thought the whole purpose of Rebuild All was to "rebuild all" features, regardless of whether they actually need it. Is that not the case?

[johnsonshiue]

Hi Derek,

The rebuild all does not help also indicates it is checksum related issue. The geometry is indeed changed. Rebuild all does not change the fact. The checksum algorithm still think the "rebuilt" geometry is the same as before. That is the bug. This is geometry specific. In other cases, the checksum clearly reflects the geometric change.

Many thanks!

[rhasell]

Thanks

That explains my problem as well.

Mine was also a hole pattern (I enlarged a PCD, which did not propagate through to the slave parts), I guess changing the export flag caused the checksum to update.

[DRoam · Accepted solution]

---

@johnsonshiue wrote:

The checksum algorithm still think the "rebuilt" geometry is the same as before. That is the bug.

---

I see now, this makes sense. Thanks for clarifying.

I wonder if it would make sense to create a secondary "Force Rebuild All" command to rebuild all features regardless of whether the checksum indicates the need it (or, without even checking the checksum at all)? Maybe this is already possible via the API?

This wouldn't help the (probably more critical) issue that Update isn't catching the need for a rebuild. But it would at least give us a way to make absolutely sure that all features have been freshly calculated as defined*.

EDIT: *That's what I always thought Rebuild All was doing anyway...

[Anonymous]

worked for me, thank you 👍