How to use variable as dimension

lars_andersson

My first attempt to use variables. I am probably making a beginners mistake.
The error text when hovering over the red box says "Enter a valid expression"

The document is at:https://cad.onshape.com/documents/83409d532f4b46bd83ba32cd/w/2e1ea2949d804e7d8f616d0f/e/0fc783875c5145b3b61caabe

andrew_troup

It's a problem of timing.
You need to leap into that Delorean and drag the line specifying the variable so it is further up the tree than any sketch or feature you want to use it in.
Otherwise it's like trying to be born before your mum.

andrew_troup

@lars_andersson
You'll soon get used to the "one rule to rule them all", in a history based modeller, which is this :

ANYTHING in the feature list which can be dragged (and currently in Onshape, that's everything except the Origin and three Construction Planes) is 
"Time Dependent".

The feature list is a history, in strict "chronological" sequence, of successive additions or removals or alterations to the model.
As such, nothing Time Dependent (ie, in the body of the tree) can ever be truly global.

Otherwise paradoxes, analogous to those arising from thought experiments in time travel, would immediately cause smoke to pour out the vents of Onshape's server saloons.

ON EDIT: I'm not trying to minimise your point: I can see how it would be confusing to someone from a prog background, especially if you didn't notice that the variable was not added at the top of the tree.
 I can see why it's not (because of future desirability of variables driven by aspects of the model) and I can also see why a tutorial would not be aimed at programmers, just at newbies to MCAD ... but if "Help" does not already point out the TD of variables, perhaps it should (especially given that in some other MCAD, they are not TD)

ilya_baran

@lars_andersson Right now I think you're right -- there's never any harm in pushing the variables to the beginning (though from a performance point of view, we internally regen all features after the variable whenever the variable changes -- so if you have a frequently changing variable used at the end of the list, you'll get better performance if the variable feature appears later).

But the current variable functionality is only part of what we're planning to do in this area.  As an example, in the future you'll have the ability to assign variables based on measurements of the geometry in the part studio.  To do that, the variable definitions (and if you want to define more variables based on these measurements) will have to come after the relevant geometry in the feature list.

andrew_troup

It's a problem of timing.
You need to leap into that Delorean and drag the line specifying the variable so it is further up the tree than any sketch or feature you want to use it in.
Otherwise it's like trying to be born before your mum.

joris_kofman

That being said it is an obvious idea to allow creation of variables by entering the name of the value into a dimension.
The value of that variable could then be the value that was already entered into the dimension box.

This of course means that a feature will try to influence the features that come before it, which is probably the biggest no-no in all of feature based modelling.

lars_andersson

andrew_troup said:

It's a problem of timing.
You need to leap into that Delorean and drag the line specifying the variable so it is further up the tree than any sketch or feature you want to use it in.
Otherwise it's like trying to be born before your mum.

Great thanks!

I just clicked the (x) icon and had a variable made for me wihout much thought. Maybe a progamming background fooled me here, I was thinking of a variable as something globally defined.

The error text when trying to use the variable was not very helpful. The tutorial on variables did not make me realise this either.

andrew_troup

@lars_andersson
You'll soon get used to the "one rule to rule them all", in a history based modeller, which is this :

ANYTHING in the feature list which can be dragged (and currently in Onshape, that's everything except the Origin and three Construction Planes) is 
"Time Dependent".

The feature list is a history, in strict "chronological" sequence, of successive additions or removals or alterations to the model.
As such, nothing Time Dependent (ie, in the body of the tree) can ever be truly global.

Otherwise paradoxes, analogous to those arising from thought experiments in time travel, would immediately cause smoke to pour out the vents of Onshape's server saloons.

ON EDIT: I'm not trying to minimise your point: I can see how it would be confusing to someone from a prog background, especially if you didn't notice that the variable was not added at the top of the tree.
 I can see why it's not (because of future desirability of variables driven by aspects of the model) and I can also see why a tutorial would not be aimed at programmers, just at newbies to MCAD ... but if "Help" does not already point out the TD of variables, perhaps it should (especially given that in some other MCAD, they are not TD)

joris_kofman

The way the variables are defined as a feature is actually a really clever way of not having to make a lot of code to look for loops in the definitions, pretty clever of the onshape people.

lars_andersson

Tried to think of a situation where it is meaningful not to have all variables defined before all "real" elements. At my learning level I could not think of any.

NOTE: I don't have any problems moving the variables up the tree now that I have been educated to do so.

ilya_baran

@lars_andersson Right now I think you're right -- there's never any harm in pushing the variables to the beginning (though from a performance point of view, we internally regen all features after the variable whenever the variable changes -- so if you have a frequently changing variable used at the end of the list, you'll get better performance if the variable feature appears later).

But the current variable functionality is only part of what we're planning to do in this area.  As an example, in the future you'll have the ability to assign variables based on measurements of the geometry in the part studio.  To do that, the variable definitions (and if you want to define more variables based on these measurements) will have to come after the relevant geometry in the feature list.

andrew_troup

@ilya_baran
Thanks for that; it confirms my hunch, which I mentioned further up the thread, regarding a newly added variable :
 << I can see why it's not [added at the top of the tree] (because of future desirability of variables driven by aspects of the model)>>