Using variables to scale a sketch

kenn_sebesta167

I'd like to scale an entire sketch based on a variable, so that I can then set that variable up as a configuration. This is proving to be somewhat difficult, as the sketch transformation feature seems to be a one-off, and does not allow any kind of programmatic input.

Is there a natural way to do this, or is this going to have to be done through some kind of Extrude--> Scale --> Use workaround?

_anton

I think I'd either multiply all sketch dimensions by a #scale variable, or (depending on complexity) try to rework the sketch to maintain the same shape but be driven by one or two key variables, which would be multiplied by the same #scale.

eric_pesty

Using variables in dimensions is easy enough but only workable for a simple sketch. I guess the question would be why you need to do this at the sketch level as there might be better workflows depending on what you are trying to achieve.

Depending what you are trying to do, you could either scale parts or you might be able to create a zero offset surface(s) of your sketch and use that directly further downstream as planar surfaces behave mostly the same as sketches for a lot of things.
The main exception would be if you have a lot of construction geometry, but even then you might be able to have a base surface that gets scaled and add a sketch later referencing this with your construction geometry (so that it would scale with it).

S1mon

I have a logo that I need to reuse at various scales. I find it easier to insert as a part, scale (using transform/scale) and then use the edges in whatever sketch I need next. This also has the side benefit of version control on the logo itself.

I would also recommend voting for this IR so that you could use the transform feature outside of Sketcher, instead of the transform tool in sketcher.
https://forum.onshape.com/discussion/12062/transform-sketch

wout_theelen541

kenn_sebesta167 said:

I'd like to scale an entire sketch based on a variable, so that I can then set that variable up as a configuration. This is proving to be somewhat difficult, as the sketch transformation feature seems to be a one-off, and does not allow any kind of programmatic input.

Is there a natural way to do this, or is this going to have to be done through some kind of Extrude--> Scale --> Use workaround?

You can simplify that workaround by instead creating a blank sketch on your sketch plane with imprinting enabled just make sure nothing else is on the same plane. That might be easier than entering all those equations. If you do just want to relate to your scale factor I would use intermediate feature variables to avoid relating everything to a configuration variable just to avoid the clutter in the configuration table.

romeograham

@S1mon
Along with using a body for a logo: if you use the face of your logo part (select the face to extrude for an emboss / deboss for instance) you have the added benefit of the selection being robust to changes to the edges of the logo...and not failing when an edge disappears or appears later when you Version the logo.

Generally, selecting faces reduces work and makes Feature Lists more robust to changes.

Extrude 3 uses the face as a selection:


...then when a fillet is added to the logo - it's not necessary to edit Extrude 3 - it just works, because the selection isn't dependent on the definition of its edges:


One of those cases where selections can be such a big part of robust Feature Lists.

kenn_sebesta167

_anton said:

I think I'd either multiply all sketch dimensions by a #scale variable, or (depending on complexity) try to rework the sketch to maintain the same shape but be driven by one or two key variables, which would be multiplied by the same #scale.

That would work if the original sketch were dimension driven. However, in my case the original sketch is a trace using splines to approximate complex curves, so the shapes are not dimensioned. I suppose I could go through and try to dimension everything, but that sounds complex, tedious, brittle, and prone to breakage.

I think @S1mon's approach (with @romeograham's excellent observation) is how I will have to move forward for the moment.