Scaled Feature

I totally forgot about wrap scale. You scaled imported geometry, need to see how wrap scale compares to regular model scale when using complex model with ton of features. Regular scale sometimes couldnt scale model.

Nice solution!

Here's the warp scale on some non-imported complex (variable rounds, drafts, sweeps, etc.) geometry.  Worked great in this case, no errors.

I finally figured out what those checkboxes by the values in the Warp feature are for.  You can make those specific values available as dimensions.  This allows you to enter the scale value you want for the family tables, and I suspect, you will have access to them for flexible models in assemblies as well.

When you use the Edit with the RMB in the model, you have to zoom way out to see those dimensions.  If you turn them on as annotation, they live far outside the model as well.  Zoom all doesn't pick them up (Creo 2.0 M040).

The only limitation I have seen in the Warp feature is that the surfaces may no longer be recognized as you would expect.  A rolled feature for instance is not "cylindrical" and the surface cannot be used to place an axis.

I also learned that you cannot make copies of a solid feature in the dialog.  But you can if it is a surface quilt.  Since you can have a second Warp translation, you can actually place parts side by side... original and scaled.

That's some good insight Tom, thanks.  I liked your 5 minute warp model you did.

Eric,

I can comment why I think this is a bad idea. Scale is an operation that affects the whole model, not some portion of the model. It affects all part level attributes - like relations, family tables etc i.e. is a global action.

Wheareas FEATURE would always respect it location in the model tree i.e. only affect (not modify but affect) geometry that was created before it. And never - after it.

Besides this, as a Feature it will have to respect all feature operation (like Copy, Mirror etc). Can you imagine the meaning of MIrroring the part that already have Scale feature in the tree ? We will get one more Scale feature later in the tree, and in a majoc way part will be scaled once again just upon left side creation.  Or placing UDF with Scale feature inside ?

And this is just for start, much more ambiguities will be down the road.

Shrinkage addresses certain aspects of the above conflict, but it is complex feature in its interaction with relations / parameters / family tables, that is not recommended for a general user who might not anticipate implications

Best,

- Vlad

Zak,

Thanks for your input.  Some background might help understand the application of this document.  This solution was for creating a thermally expanded representation of a part.  This is the final feature in the tree and may need to be modified depending on how it is manufactured.  There isn't a way to create a modifiable family table instance of an expanded part and name it something like thermally_expanded because the scale operation isn't a feature.  Furthermore, the user wouldn't be able to tell how large the thermal expansion was modeled at with the scale operation since it's not modifiable....can't be edited or driven by a parameter.  The shrinkage feature requires a special license, training, and for the part to be a manufacturing part.

Using the warp feature, these limitations can be overcome.  In fact, Solidworks has this feature and is why I was approached.  They wanted to do the same thing...to have a thermally expanded part as a family table instance.

The way I see it, the same argument could be applied to the flatten feature in sheetmetal (or others like remove surface, an inheritance merge, or even assembling components to each other).  Creating features on top of a flatten feature could be disastrous and create problems down the road...if the user doesn't know what they are doing or the implications thereof.  This is also the Achilles heel of parametric modeling altogether...understanding design intent history and the corresponding implications from somebody else's design.   But it would be bad if we took away the flatten feature because of that.  We shouldn't limit the functionality of the software because a user might not be well trained well.  That's just my opinion though.

That being said, this is why I created the document, to get valuable feedback from experts like you in the community to make sure I don't create a bigger problem in overcoming the limitations we are currently faced with and to find an even better way to do something if it exists.  So thank you for your input, it's greatly appreciated.

excellent