Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.

First time visiting? Here are some places to start:
  1. Looking for a certain topic? Check out the categories filter or use Search (upper right).
  2. Need support? Ask a question to our Community Support category.
  3. Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
  4. Be respectful, on topic and if you see a problem, Flag it.

If you would like to contact our Community Manager personally, feel free to send a private message or an email.

Autocreation list of custom features by script.

max_borshmax_borsh Member, Developers Posts: 14
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).

Best Answer

Answers

  • Dylan_StewartDylan_Stewart Member, Developers Posts: 107 PRO
    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. 

    Digital Engineering
  • Dylan_StewartDylan_Stewart Member, Developers Posts: 107 PRO
    @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. 
    Digital Engineering
  • kevin_o_toole_1kevin_o_toole_1 Onshape Employees, Developers, HDM Posts: 565
    @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_StewartDylan_Stewart Member, Developers Posts: 107 PRO
     Oh okay, now I see. Sorry for the misunderstanding. 
    Digital Engineering
  • robert_morrisrobert_morris OS Professional, Developers Posts: 166 PRO
    @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_sparksowen_sparks Member, Developers Posts: 2,660 PRO
    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.
    Business Systems and Configuration Controller
    HWM-Water Ltd
  • kevin_o_toole_1kevin_o_toole_1 Onshape Employees, Developers, HDM Posts: 565
    @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_sparksowen_sparks Member, Developers Posts: 2,660 PRO
    Thanks @kevin_o_toole_1 makes perfect sense.

    @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.


    Business Systems and Configuration Controller
    HWM-Water Ltd
Sign In or Register to comment.