Variables in timeline - use case

henry_feldman

So, this may be a logic thing I missed, but I don't understand why variables are included in the stack of the timeline. In many cad packages (let's use Fusion360 just as an example) the variables are a thing that is outside the timeline. The variables just "are", rather than existing from a time forward. I am not sure what it means to have a variable not exist at the beginning and then later exist. What would be the use case for that? It also makes finding a variable painful when you have a big stack of stuff on the left. In Fusion360 for instance you have a variables dialog with a 2 column table in it.

It is just weird to realize you need to add a variable to a sketch, then essentially roll back, add a variable (which are all static globals anyway) and then roll forwards so you can use a variable (or drag the variable up before the sketch). 

As a second follow on it would be awesome that in any field that accepts variables, that once I hit #, that it autocompletes variable names

ilya_baran

There are a few reasons we made variables part of the feature list, most of them with an eye towards future functionality.  For instance, once we ship feature pattern, we will have the ability to "pattern" variables, where each pattern instance sees a different value of the variable.  Another piece of future functionality is assign-variable-to-measurement, where you can set a variable to a length or angle (or area or what not) based on the geometry.  Both of these use cases require variables to be part of the feature list.

To find variables more easily, you can start typing in "variable" into the filter box at the top of the feature list.

I agree that autocompleting on # is a good idea.  We have plans for this and other usability improvements.

3dcad

I'm missing a separate list to create/edit a bunch of variables in one go + other usability improvements.

henry_feldman

@ilya_baran
So this seems to be 2 separate things in hindsight. There are global static variables (i.e. are given a numeric or static formulaic value by the user - e.g. 5.3 or #fooBar * 2 where fooBar is also a static) and derived variables (from a measurement). Obviously a derived measurement needs to be defined prior to its use, but the others are static, so should be defined like a static class-variable in code (even if you guys just auto-advanced them all to the top of the feature list would be fine).

The problem with derived variables that I see (and anyone who developed big apps is painfully aware of) that when your source base (in this case a giant pile of features) get huge, the order of operations is rapidly going to scale beyond human capacity to manage (just like linker order gets rapidly out of hand in a big build script).

I ran into this the other day with only 60 or so features when my sketch was above the variable but I couldn't see it. And it isn't obvious that that is what has occurred (filtering of course makes it worse, because it is the relationship between the variable and sketch that matters)

ilya_baran

We could have had two concepts as you suggest (and we may still introduce something like a document-wide variable set), but that would require more concepts and more UI for you to learn (and for us to maintain), including, for instance, UI to switch variable types.

The problems you mention with what you call "derived" variables (understanding relationships with other features) are a general problem with parametric modeling.  By making variables part of the feature list, tools we develop for navigating feature relationships will help with variables also.

You are right that keeping track of variable dependencies can get complicated.  In software development, I personally find that a combination of good tools and good coding practices help me keep things straight.

A couple of workflow hints (involving filtering) until we develop improvements are:
1. If you hover over the filtered out "..." you can see in a tooltip exactly which features are filtered out.
2. If you filter out everything but the variables, you can see which variables come after non-variable features.  In that filtered out mode, you can easily drag them above the "..." all into one group at the beginning.

thomas_kozak

Extremely excited to hear that "assign-variable-to-measurement" or as Henry Feldman terms it "derived variable" is coming to OnShape.  Right now I run into problems where a sketch needs a dimension equal to some feature which will be changed parametrically and doesn't have an easily-calculatable value

henry_feldman

ilya_baran said:

you can easily drag them above the "..." all into one group at the beginning.

Ah, that is incredibly useful to know. At least I can quickly fix it. Thanks.

ilya_baran

Feature pattern, the first use case I mentioned, has landed: https://forum.onshape.com/discussion/2675/improvements-to-onshape-february-11th-2016
Assign-measurement-to-variable is in progress.