Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape, CAD, maker project and design.

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.

FeatureScript Instantiator: Configurations + FeatureScript = more power, easier coding

ilya_baranilya_baran Onshape Employees, Developers, Configurations EVP Posts: 702
As I've mentioned elsewhere, one of the cool aspects of configurations is that a custom feature can "call" a configured part studio.  This makes it easier to write custom features that create complicated geometry because you can model the complicated geometry interactively in a part studio.  However, the syntax to do this currently is somewhat arcane.  To make it easier, I've written an "instantiator" module that simplifies this and creates multiple instances of the same configuration efficiently.  My intent is to incorporate it into the FS standard library, but for now it's available as an Onshape document: https://cad.onshape.com/documents/333ec067d919f3b6987002ce/w/ffc55a1fc90a9ba29b73505e/e/18b028058ab32602ad4be712

Here's how the instantiator can be used:

firstPartStudio::import(...); // These imports are created using the import button in the Feature Studio
secondPartStudio::import(...);

// later, in a feature
const instantiator = newInstantiator(id + "myId");

var firstQuery = addInstance(instantiator, firstPartStudio::build, { "configurationInput" : configurationValue }, transform(vector(1, 2, 3) * inch)));
var secondQuery = addInstance(instantiator, secondPartStudio::build, secondConfiguration, someOtherTransform));
// repeat the above as necessary

instantiate(context, instantiator); // This actually brings in the bodies
// Now firstQuery and secondQuery will resolve to the instantiated geometry

The document contains an example feature for adding keys to a keyboard that becomes much easier to create with the instantiator:

Please post feedback on the instantiator here!

Ilya

P.S. The instantiator internally takes care of some efficiency concerns, deriving the first instance in a given configuration and body-patterning the rest.  User-overridable tolerances are used to determine which configurations are considered "the same."
Ilya Baran \ Director of FeatureScript \ Onshape Inc

Comments

  • konstantin_shiriazdanovkonstantin_shiriazdanov Member Posts: 430 ✭✭✭
    can this be used for substituting query parameters for a feature sequence from some source part studio, or this works only for numeric values?
  • mahirmahir Member, Developers Posts: 470 ✭✭✭
    @ilya_baran, just making sure I understand. Is the intention just to reduce the number of function calls when instantiating more than one configuration?

    In your previous example you were able instantiate a configuration with three commands - import(), importDerived(), and opTransform(). The resulting body can be patterned like any other body. For X configurations from Y part studios, you end up with Y+2X function calls.

    With the instantiator you combine the config input and transform, so 2X becomes X. You still need three function calls - partStudio::import(), addInstance(), and instantiate(), but instantiate() only has to be called once. You end up with Y+X+1 function calls (which is less than Y+2X when X>1).

    Is that the gist?
  • kevin_o_toole_1kevin_o_toole_1 Onshape Employees, Developers, Configurations EVP Posts: 328
    @konstantin_shiriazdanov
    If I'm understanding you correctly, the answer is no. Derived brings in an entire part studio after all its features have regenerated. There's no way to bring in just some of its features. One useful invariant is that Derived Part Studio will always produce the same output for the same configuration, no matter where you use it.

    Am I understanding your question correctly? If not, could you clarify?

  • ilya_baranilya_baran Onshape Employees, Developers, Configurations EVP Posts: 702
    @mahir
    Reducing the number of function calls (and their ugliness -- the importDerived call is somewhat awkward) is part of the goal.  The bigger part is that opPattern is cheaper than importDerived and configurations are often repeated.  The instantiator only does importDerived for unique configurations and patterns the rest.
    Ilya Baran \ Director of FeatureScript \ Onshape Inc
  • konstantin_shiriazdanovkonstantin_shiriazdanov Member Posts: 430 ✭✭✭
    @kevin_o_toole_1 ok, thanks
    i hoped that since we can configure query fields in config table there may be a way to regenerate a sequence of features from that configured part studio into the target PS only changing those query parameters, like a function call with new argument.
  • mahirmahir Member, Developers Posts: 470 ✭✭✭
    edited January 10
    @konstantin_shiriazdanov, I think only configured variables can be called externally. Regular configured feature inputs (numeric or otherwise) are not.
  • ilya_baranilya_baran Onshape Employees, Developers, Configurations EVP Posts: 702
    Ok, there is a bit of terminology confusion going on here.

    From a FeatureScript point of view, a Part Studio is a function that takes arguments (each argument is a "Configuration Input") that together make up the configuration.  These configuration inputs may be enums, booleans, strings, lengths, angles, or numbers.  They may not be queries.  "Configuration variables" is just a term for configuration inputs that are not enums or booleans.

    The part studio function creates a context, calls features (which are functions that take "Feature Parameters" as arguments), and returns the context.  Feature parameters can be lots of different types: every type allowed as a configuration input and also queries, lookup tables, feature lists, etc.

    The fact that you can configure queries means that that you can make a query feature parameter depend on the value of an enum or a boolean configuration input.  It does not mean that you can pass a query to a part studio (we did think about allowing this but it runs into serious difficulties I won't go into here) as a configuration input.

    Does this help?
    Ilya Baran \ Director of FeatureScript \ Onshape Inc
  • konstantin_shiriazdanovkonstantin_shiriazdanov Member Posts: 430 ✭✭✭
    thanks, I think I understood the boundaries of the possible

  • Dylan_StewartDylan_Stewart Member, Developers, Configurations EVP Posts: 106 PRO
    edited January 11
    @ilya_baran So is it now possible to configure part properties? 

    If so, how would you call that in FS? 
    Digital Engineering
  • ilya_baranilya_baran Onshape Employees, Developers, Configurations EVP Posts: 702
    edited January 11
    @Dylan_Stewart not yet -- coming very soon.

    EDIT: to clarify, you can configure part properties interactively in the table.  What is coming soon is the ability to set part properties from FeatureScript.  When you bring in a part via derived (in FS or otherwise), its part properties come with it.  This does not yet work on the instantiator; that requires some internal changes.
    Ilya Baran \ Director of FeatureScript \ Onshape Inc
  • Dylan_StewartDylan_Stewart Member, Developers, Configurations EVP Posts: 106 PRO
    @ilya_baran But if the part's properties are configured before exporting, the properties will follow when the part is imported?

    Digital Engineering
Sign In or Register to comment.