Autocreation list of custom features by script.

max_borsh

Hi Everybody.
Supposing I have some custom features that I need to invoke in specific scenario to create my entire Part.

Is there any way to write a script that could call features in a particular order(i.e. by scenario)?

I know that I can just create another feature and call all functions (custom features) that I need to create Part.
But in this case I'll get only one feature in my feature tree (in Part Studio) instead of the list of called features.

For clarity, get some images:

I want to take list of features (then I'd get some changes at any feature):
   
Instead of this:

So, I just want to have the way where features will be constructed automaticaly,
not manualy (call each feature by clicking the one in list of custom features).

kevin_o_toole_1

I would say no, this isn't possible in the way you described.

One unique aspect of FeatureScript that differentiates it from other CAD automation systems is that FeatureScript inputs are driven by the inputs to the model tree — FeatureScript doesn't create, or modify, or drive the feature tree.

The plus side of this is that everything in an Onshape feature tree is there from direct design intent – If "extrude1" is in the feature tree, it's because a human decided to put that extrude there. If "Box build 1" is in the feature tree, it's because a human added a feature that builds a whole box. Afterwards, if that user wants to e.g. change the box dimensions, they can do so by changing the inputs to the box feature. They DON'T now have to infer which of the generated features need to be modified such that the dimension will correctly change in the resulting output. The feature designer, on the flip side, doesn't have to construct their features in such a way that provides an interface for editing after the fact. They just need to expose the correct inputs to a single feature once.

This is all well and good while we're sitting in our ivory towers musing about good CAD philosophy and designs that need to be maintained for years. In the real world, there are definitely going to be times that you want exactly what you've described – A quick way of automating a workflow with a one-shot script that populates a feature tree. FeatureScript, plain and simple, can't do this, and Onshape will one day need a macro language to fill this need. Don't worry, we are listening, and this is on our wish list.

With pure FeatureScript, the right strategy is going to depend on your specific use case. Most times, I'd recommend consolidating your features into one feature with a nice interface. If you really want 5 features in the feature tree, the only way this is going to happen is if the user creates 5 features.

Dylan_Stewart

Yes, it is very possible. 

This sounds very similar to what I am doing.

If you want, you could share the document with me and I can help out. 

kevin_o_toole_1

I would say no, this isn't possible in the way you described.

One unique aspect of FeatureScript that differentiates it from other CAD automation systems is that FeatureScript inputs are driven by the inputs to the model tree — FeatureScript doesn't create, or modify, or drive the feature tree.

The plus side of this is that everything in an Onshape feature tree is there from direct design intent – If "extrude1" is in the feature tree, it's because a human decided to put that extrude there. If "Box build 1" is in the feature tree, it's because a human added a feature that builds a whole box. Afterwards, if that user wants to e.g. change the box dimensions, they can do so by changing the inputs to the box feature. They DON'T now have to infer which of the generated features need to be modified such that the dimension will correctly change in the resulting output. The feature designer, on the flip side, doesn't have to construct their features in such a way that provides an interface for editing after the fact. They just need to expose the correct inputs to a single feature once.

This is all well and good while we're sitting in our ivory towers musing about good CAD philosophy and designs that need to be maintained for years. In the real world, there are definitely going to be times that you want exactly what you've described – A quick way of automating a workflow with a one-shot script that populates a feature tree. FeatureScript, plain and simple, can't do this, and Onshape will one day need a macro language to fill this need. Don't worry, we are listening, and this is on our wish list.

With pure FeatureScript, the right strategy is going to depend on your specific use case. Most times, I'd recommend consolidating your features into one feature with a nice interface. If you really want 5 features in the feature tree, the only way this is going to happen is if the user creates 5 features.

Dylan_Stewart

@kevin_o_toole_1

Hmmmm... Maybe I misunderstood what is trying to be accomplished. 

@max_borsh  I would listen to Kevin over myself (for obvious reasons)

My apologies for spreading false information. But, if it's a matter of all the parts talking to each other and swapping out parts and changing each part, then why is it not possible? The reason I ask is that I am working on a feature that constructs multiple different parts and each one of them can be changed and modified. 

kevin_o_toole_1

@Dylan_Stewart
If I understood @max_borsh correctly, he's trying to make a single FeatureScript which, when run, leaves multiple features in the feature tree as outputs. This is something a macro language can do, but FeatureScript can't.

The things you just described do sound possible.

Dylan_Stewart

 Oh okay, now I see. Sorry for the misunderstanding. 

robert_morris

@max_borsh
One alternative that might work for you is to create a "template" document that has a Parts Studio for each scenario with just the base features in it (the ones you would want to have in your script). That way you only have to create the features once and you can copy the Parts Studio around to other documents when you need to.

When you want to create a new document that uses one of those scenarios, just right-click on the template Parts Studio tab and select "Copy to clipboard". and in the new document, click the '+' button and select "Past tab".

owen_sparks

Forgive me for being lazy and just asking rather than trying it but could you use variables declared in the part studio (by humans, not variables declared in featurescript code) as inputs to list of sequential featurescript features?

eg variables user declares:-
#BoxWidth
#BoxHeight
#BoxDepth

then run featurescripts:-
Build_Me_A_Box 
Build_Me_A_Lid
Build_Me_A_Handle

Not linking the fs to the variable in code but by having the user type "#BoxWidth" into the user interfaces of each.

We'd then having the option to change multiple parts generated by separate featurescripts from one dimension.

Cheers,
Owen S.

kevin_o_toole_1

@owen_sparks You can read any variables set by users or via getVariable, because internally, the Onshape variable feature is just calling setVariable).

One tricky thing is documenting the fact that your features require such a variable to be set (so a user of the feature doesn't get confused if they forgot that step or spelled the variable name wrong).

A possibly better interface could be a "setup" feature which takes in a length, width, and height (possibly building the basic thing), and also sets the three variables with setVariable. Then downstream features can access those values, and the user has a mistake-free dialog in which to enter them.

owen_sparks

Thanks @kevin_o_toole_1 makes perfect sense.

kevin_o_toole_1 said:

@owen_sparks You can read any variables set by users or via getVariable, because internally, the Onshape variable feature is just calling setVariable).

This highlights the sense of your features, and fs all using same native language rather than bolt on afterthought macros.

One tricky thing is documenting the fact that your features require such a variable to be set (so a user of the feature doesn't get confused if they forgot that step or spelled the variable name wrong).

I think we're talking at cross purposes here.
The workflow I was hoping to illustrate was a method to have a user run sequential featurescripts (possibly from different developers even) driven from some variables set at the beginning.  Thus creating feature tree entries for each step as per the original poster's intent.  No programming would be required for a user to achieve this.  (An option to enable the user to pick a pre-declared variable from drop down list would help here.)

A possibly better interface could be a "setup" feature which takes in a length, width, and height (possibly building the basic thing), and also sets the three variables with setVariable. Then downstream features can access those values, and the user has a mistake-free dialog in which to enter them.

That's elegant :-)

Cheers,
Owen S.