Derived sketch geometry doesn't update for certain changes

[h_versteeg73PBR]

When creating sketch geometry in a base part and deriving this to a different part, all updates in the base part get forwarded to the derived part, except in the following circumstances, which require require the sketch to be un-derived and re-derived for changes to show up:

•  Firstly: deriving a 3D sketch, using that sketch in the derived part in a feature (e.g. guide/center line for loft, sweep), then replacing the geometry in the base part sketch with new geometry (e.g. remove spline, create new spline). Based on what happens when performing similar actions with 2D sketches, I would expect the old geometry to disappear from the derived part, and the dependent features to break, requiring manual re-selection of the new, updated geometry. What happens instead is that the old 3D geometry remains intact in the derived sketch of the derived part, the feature does not change, nor does it break, and the new geometry also shows up in the derived part (see attached example files, from after such an update). If the 3D sketch is not used by a feature, the update proceeds as expected. Usually the line color for the now-removed geometry in the derived part is still the same as for projected/included geometry, but I have had instances where the color changed to 'unconstrained' and the elements could be manually removed from the sketch in the derived part (have yet to reproduce this on its own)
• Changing sketch geometry (2D or 3D) from normal to construction or vice versa does not show up in derived parts with a normal update (also in attached example files, 2nd sketch, rectangle cross line)
• We've also had sporadic issues with additions to regular 2D sketches not showing up, but so far have not been able to reliably reproduce this. When going to 'edit derived part' such changes do show up, but disappear again when closing the dialog window.

[johnsonshiue]

Hi! I believe this Derive behavior has something to do with the fact that the derived sketch has already been consumed by a feature. To certain extent, it is not unique to the Derive workflow. You may reproduce a similar behavior within a part.

1) Create a rectangle in a sketch.

2) Create another sketch on a parallel plane -> project the rectangle to the new sketch.

3) Extrude the second rectangle as a box. 

4) Edit the first sketch -> delete the rectangle -> create a circle -> Finish Sketch.

You will see the box is still there. And, the projected sketch becomes sick.

The behavior isn't exactly the same as Derive but it is quite similar. The key here is that once the sketch is consumed but the source is deleted, the derived sketch will remain there to keep the feature computing.

I think you are looking for a way to use the source sketch to drive the features in the derived part. It will work as long as the source sketch undergoes geometric change, not topological change (deleting or creating new geometry).

Many thanks!

[h_versteeg73PBR]

Thanks for the reply. From what I can tell, the behavior you described regarding projected geometry in (2D) sketches is not the same as shown by derived 2D sketches, which then in turn behave differently from derived 3D sketches. I've attached a minor variation of the parts from the original post. In the base part, the first sketch has been changed from a circle to a hexagon (i.e. completely new geometry). The derived sketch in the derived part fully updates to the new geometry and does not become sick, only the dependent feature breaks, which can be easily fixed by editing the feature and selecting the new geometry for use (this is what I expect to happen and feels intuitive).
In contrast, both the old and new 3D sketch geometry still show up in the derived part, where the old geometry also doesn't become sick (different from projected), nor does the dependent feature break (different from 2D derived and projected). You also cannot delete or unlink either of the two sketch geometries within the derived sketch (which is possible when a projected sketch entity becomes sick). For a proper update you have to: remove the relevant feature, remove the derived 3D sketch from the part, add the sketch back in, then add the feature back in. This all becomes quite frustrating to deal with if there's more than one feature that depends on the derived 3D sketch, as these can't just be redefined/relinked to the new geometry but have to be fully removed, else the sketch cannot be unselected for inclusion in the derived part, and made to update.

The part about propagating changes in lines being marked as construction or not, does seem to be consistent with projected geometry, in the sense that that aspect gets copied over when something gets 'imported' for the first time, but afterwards the downstream entity has the final say over whether something is construction or not. For derive, this seems less intuitive than for projected entities. The latter usually involves explicit manual selection of specific sketch or solid entities while inside a sketch environment, which are then manipulated based on their use in the sketch being edited. Derive on the other hand almost always functions as carbon copy of full features from a base part (aside from explicitly set high level modifications like scaling and merging solids). Breaking with that logic/expectation in a (very) small subset of cases can be quite counterintuitive, and creates unexpected behavior in a feature of inventor that is otherwise very well defined and extremely useful.

[johnsonshiue]

Hi! Indeed the project behavioral model I mentioned isn't completely the same as Derive here. There are inconsistencies in terms of how Derive sketch deals with missing source. I need to look into it further. But, I cannot promise a quick fix. Based on my experience, any subtle change in Derive workflow can lead to unintended consequences.

Many thanks!

[h_versteeg73PBR]

Thanks for looking into it, considering the complexity of the systems at play I wasn't expecting a quick fix. Looking forward to any updates, whenever they may follow.

[robertoQVBND]

I'm having the same problem. If I project geometry of a part in a new sketch, when this part is modified (even if I just change dimensions, not deleting anything or changing it to construction) the new sketch and opperations stay with the old references.  It's driving me crazy 😩

[johnsonshiue]

Hi Roberto,

I am not 100% sure if the issue you are seeing is the same as the OP. Please share an example that illustrates the derive update issue. I would like to understand it better.

Many thanks!

[bradeneuropeArthur]

---

@johnsonshiue wrote:

Hi! Indeed the project behavioral model I mentioned isn't completely the same as Derive here. There are inconsistencies in terms of how Derive sketch deals with missing source. I need to look into it further. But, I cannot promise a quick fix. Based on my experience, any subtle change in Derive workflow can lead to unintended consequences.

Many thanks!

---

Same issue we still have on Inventor 2024.

@johnsonshiue isn't it then the case better to prevent using derive methods in skeletal designs and put as much as possible all features as much as possible in one and the same part because you see directly where things go wrong, correct?

Remarks to a workflow we struggling with is that we split up all skeletons into separate parts as much as possible.

• Each Multibody is a separate part
• Each parameter is a separate part
• Each sketch is a separate part
• Each surface is a separate Part
• Each Block is a separate Part. 

These part use derive methods from each other.

For example parameters are used as derive in sketches.

These sketches are used as derive in Surfaces.

These surfaces are uses in Multi-bodies and so on

For example:

Folder Multibody
1234-MB001.ipt
1234-MB002.ipt
1234-MB###.ipt
Origins
1234-NO001.ipt
Folder Parameters
1234-PAR001.ipt
1234-PAR002.ipt
1234-PAR###.ipt
Sketches & Blocks
1234-SK001.ipt
Folder Interfaces
1234-IF001.ipt
1234-IF002.ipt
1234-IF###.ipt
Surfaces
1234-SURF001.ipt
1234-SURF002.ipt
1234-SURF###.ipt

The skeletal assembly contains than..

1234-ASSEMBLY.iam
Multibody
1234-MB001.ipt
1234-MB002.ipt
1234-MB###.ipt
Origins
1234-NO001.ipt
Parameters
1234-PAR001.ipt
1234-PAR002.ipt
1234-PAR###.ipt
Sketches & Blocks
1234-SK001.ipt
Interfaces
1234-IF001.ipt
1234-IF002.ipt
1234-IF###.ipt
Surfaces
1234-SURF001.ipt
1234-SURF002.ipt
1234-SURF###.ipt

The result is that the skeletal assembly uses over 300+ (or sometimes even more) different parts that derive from each other and multiple derives in parts when for example the sketch uses 10 parameters, there are 10 derives.

What is your opinion regarding this and does this overshoot the target maybe?

[johnsonshiue]

Hi Arthur,

Either way should work as it was designed. The number of derive source files should not be an issue. If you put all the source objects in one ipt file, that should work fine too.

It is hard to tell which one is more preferable. I guess you may consider modularize the skeletal source. I don't think a model should be strictly top-down or bottom-up. It is always somewhere in between. The art is where is the best "in between."

A complex machine should be divided into a few function groups. I believe each function group will need at least one skeletal part. You may consider using UCS so that each function group can be designed independently from others. Then you could constrain the common UCS from each functional subassemblies in the top-level assembly.

Many thanks!

[johnsonshiue]

Hi Arthur,

Either way should work as it was designed. The number of derive source files should not be an issue. If you put all the source objects in one ipt file, that should work fine too.

It is hard to tell which one is more preferable. I guess you may consider modularize the skeletal source. I don't think a model should be strictly top-down or bottom-up. It is always somewhere in between. The art is where is the best "in between."

A complex machine should be divided into a few function groups. I believe each function group will need at least one skeletal part. You may consider using UCS so that each function group can be designed independently from others. Then you could constrain the common UCS from each functional subassemblies in the top-level assembly.

Many thanks!

[bradeneuropeArthur]

Same thought I have, thanks.