More to configurations.

brian_pinder662

Progressing with configurations but would like a little help please. I have a pipe tee which has a variable (PipeRad17.5) or (PipeRad 21mm) Which works fine on the the 17.5 PipeRad, but on the 21mm Pipe Rad there is an extrusion that needs to increase from 1.5mm to 4.5mm. My question is how to write an equation to the extrusion that will allow this, or is this not possible.
Can anyone help please.
Regards Brian.

NeilCooke

== is comparing the variable to a value. 

Read it as: if #PipeRad = 21mm then 4.5mm else 1.5mm

MBartlett21

You should probably take tolerance into account using tolerantEquals

tolerantEquals(#PipeRad, 21 mm) ? 4.5 mm : 1.5 mm

PS: you can just use 21 mm, rather than 21 * millimeter

owen_sparks

It represents the word "else". So we have the question first, that is to say a logical test to see if a condition of met. Then we have the value to use if that condition is true, then after the colon the value to use if that condition is false.

Condition? Value if true : value if false


So in your example we're doing "if pipe diameter = 21mm then use 4.5mm, else use 1.5mm instead."

Does that make sense? Cheers Owen.

NeilCooke

In the extrusion depth field, type something like:

#PipeRad == 21 * millimeter ? 4.5 * millimeter : 1.5 * millimeter

tim_hess427

@NeilCooke - Is there a reference somewhere with more information about expressions like this? I can remember coming across a couple things like this on the forums, here. But, I have trouble finding the info later. 

kevin_o_toole_1

https://cad.onshape.com/help/Content/numeric-fields.htm has some info on parameter expressions.

Note that these expressions are evaluated as FeatureScript, so anything that's valid FeatureScript also will work in that field... But of course that's like saying you could solve your problem by learning Chinese. That help page instead just goes over most of the useful cases.

brian_pinder662

Yes Neil this worked Fine thank you. Thanks also to Tim & kevin for their comments. I have been trying to work out how this works, for example what does the two equal signs mean, and the ?. Knowing how the expression works would be a great help. Is there tutorial that may explain.
Once again thank you all. I shall be spending some time trying to work it out.
Brian. 

NeilCooke

== is comparing the variable to a value. 

Read it as: if #PipeRad = 21mm then 4.5mm else 1.5mm

brian_pinder662

Thanks Neil, Will get there eventually .
Brian

MBartlett21

You should probably take tolerance into account using tolerantEquals

tolerantEquals(#PipeRad, 21 mm) ? 4.5 mm : 1.5 mm

PS: you can just use 21 mm, rather than 21 * millimeter

brian_pinder662

It is slowly coming together, but can someone explain what function the colon (:) represents.
Brian.

owen_sparks

It represents the word "else". So we have the question first, that is to say a logical test to see if a condition of met. Then we have the value to use if that condition is true, then after the colon the value to use if that condition is false.

Condition? Value if true : value if false


So in your example we're doing "if pipe diameter = 21mm then use 4.5mm, else use 1.5mm instead."

Does that make sense? Cheers Owen.

brian_pinder662

Thanks Owen, yes got it.
All the best Brian.

Jake_Rosenfeld

For the curious, this ?: syntax is called the ternary operator, and is present in most modern programming languages.  Here is its wikipedia page. 

As @kevin_o_toole_1points out, the availability of this type of syntax inside of a feature dialog is a direct result of the expression in the box being evaluated as FeatureScript, and the ternary operator being a piece of syntax that is available in FeatureScript.  If anyone has suggestions of ways we can improve the documentation around this, or ways to make doing this kind of operation easier/more understandable, please feel free to say so!

owen_sparks

Jake_Rosenfeld said:

If anyone has suggestions of ways we can improve the documentation around this, or ways to make doing this kind of operation easier/more understandable, please feel free to say so!

Hi.

For the less cody users perhaps OS could accept a range of formats:-

The existing:-

#PipeRad == 21 * millimeter ? 4.5 * millimeter : 1.5 * millimeter

Something Excel-esque:-

=IF(Condition,Value if True,Value if false)

Something a little more human readable as per Visual Basic:-

If Condition Then Value if True Else Value If False

A different scenario...  I heard a computer game dev put it this way:- "there are no wrong answers" for what the user does, the software should just accommodate it.

I quite like the excel format as the parameters are separated by commas.  No trying to remember if this parameter uses one "=" or two, or is it a colon here or a question mark?

Cheers,

Owen S

Jake_Rosenfeld

owen_sparks said:

A different scenario...  I heard a computer game dev put it this way:- "there are no wrong answers" for what the user does, the software should just accommodate it. 

A very good book on product design once told me that is no such thing as human error, only bad design.  Someone might be tempted to blame themself for putting the ? or : or == in the wrong place, but really it's the software's fault for not being clear and usable.  Thanks, as always, for the great feedback.

owen_sparks

@Jake_Rosenfeld @Jason_S
Thanks for the replies and for not being all defensive over a bit of Onshape that arguably already works just fine   I think I'm stuck between generations.  Half of me expects to "do thing properly" when looking at new software.  Read the manual, do the training etc.  The other half thinks of software as apps that should be so intuitive to use, or should guide the user through a process, such that a manual isn't ever necessary.

Mulling this further, and with a view to the long term I have an additional thought.  I'd love to see a function icon next to the input field on feature dialogues. Clicking this would open a Featurestudio and build a template of a blank function complete with link to the input field.  The user would then have:-
(a) Space. 
We've winged about tiny input fields for a while and with a Featurestudio we'd have more than we could ever need.  We'd be free to use multi-line expressions to make reading them easier.
(b) Auto complete becomes available. 
The is already a perfectly good auto complete for building an if statement for example.
(c) Comments. 
We can add comments to expressions so the intent is even clearer even after time has passed or if editing another designer's feature.
(d) Menus.
There are already drop down menus for query functions and the like, this could be build upon with expressions to guide someone who can't benefit from the autocomplete because they don't know what to start typing. 
(e) If nudges folks gently into FS.  
If I have one regret over my Onshape learning curve it's not getting into FS much earlier, but that's for another post.

Thanks also for the link to that book.  I'll be having a read!  This excerpt just makes perfect sense:-

Even the smartest among us can feel inept as we fail to figure out which light switch or oven burner to turn on, or whether to push, pull, or slide a door. The fault, argues this ingenious-even liberating-book, lies not in ourselves, but in product design that ignores the needs of users and the principles of cognitive psychology. The problems range from ambiguous and hidden controls to arbitrary relationships between controls and functions, coupled with a lack of feedback or other assistance and unreasonable demands on memorization.

The Design of Everyday Things shows that good, usable design is possible. The rules are simple: make things visible, exploit natural relationships that couple function and control, and make intelligent use of constraints. The goal: guide the user effortlessly to the right action on the right control at the right time.

The Design of Everyday Things is a powerful primer on how--and why--some products satisfy customers while others only frustrate them, especially if you make all the blasted icons grey rectangles.

Cheers,
Owen S.

konstantin_shiriazdanov

owen_sparks said:

Mulling this further, and with a view to the long term I have an additional thought.  I'd love to see a function icon next to the input field on feature dialogues. Clicking this would open a Featurestudio and build a template of a blank function complete with link to the input field.  The user would then have:-
(a) Space. 
We've winged about tiny input fields for a while and with a Featurestudio we'd have more than we could ever need.  We'd be free to use multi-line expressions to make reading them easier.
(b) Auto complete becomes available. 
The is already a perfectly good auto complete for building an if statement for example.
(c) Comments. 
We can add comments to expressions so the intent is even clearer even after time has passed or if editing another designer's feature.
(d) Menus.
There are already drop down menus for query functions and the like, this could be build upon with expressions to guide someone who can't benefit from the autocomplete because they don't know what to start typing. 
(e) If nudges folks gently into FS.  
If I have one regret over my Onshape learning curve it's not getting into FS much earlier, but that's for another post.

We are talking about ability to preprocess inputs for built in features here and there in a number of threads for more then a year already. By many reasons, it would allow to break the borders in parametrization which are now unreachable in all the MCADs with built in fuctionality. There are also no CADs wich can collect references automaticaly - you can make a number of cross sections with feature pattern but you would need to pick them one by one manually for the loft, you can make a pocket with edges to fillet but you have to select them one by one for the fillet each time the number of edges changes. You can make a complex sequence of subfeatures based on some reference entity but you generally can't poppulate it on a number of slightly different entites near of it. And I feel that Onshape is as close as noone else to the seamless solution of this parametrization problem - refferense preprocessing with subfeatures. Last time @ilya_baran said it can make feature behavior too complex if it was made as subfeature call defined for the input field, but it wouldn't be more complex then it is now if Query fields would consume global variables of Query type. We could simply made some custom feature for Queries as Measure value for numeric vaules now, and call it explicitly.

owen_sparks

@konstantin_shiriazdanov
YES! 
For anyone following along, one such discussion we had is here and highlights a simple use case for what we describe:-
https://forum.onshape.com/discussion/7185/use-featurescript-queries-in-standard-partstudio-features
Owen S.

tim_hess427

This stuff sounds awesome. I've been planning to dig into feature script, but as you mentioned, it looks a little daunting and being able to dabble with some fancy functions in existing features would be great.

brian_pinder662

Further to my attempts at configurations, Could anyone help with the correct syntax. I require a sketch dimension to to change. For example I have a dimension of 99.81mm which I require to change to 105 mm when I  change variable (PipeRad 17.5mm to PipeRad 21mm) Can this be done or can it only be done by list input. Thanks for all your help and comments.
Brian

Eleanor_Coffin

Is it possible to use this syntax to suppress/unsuppress certain parts in assemblies? (Or is there a better way I should go about this?)

I'd like to do something like this: #Length < 1300mm ? suppress[part] : unsuppress[part]