FeatureScript and Configurations

I've talked about how great Onshape configurations are in the past. They work great and are super powerful. FeatureScript also works fantastically with Onshape's configurations, as your custom feature can be configured in the same ways that the Onshape standard features can be configured. But did you know that a FeatureScript can also utilize information from the current configuration, or Part Studio Data input types?

First, lets talk a quick refresher about FeatureScript IDs for configurations in Onshape. The names of the configuration tables and values are not the same in the background as what they are displayed as in the user interface.

In a Part Studio configuration panel, for any table or variable you can click on the ellipses followed by the "Edit FeatureScript IDs".

Bringing up the window showing FeatureScript IDs. This can either be modified to something more expected and consistent, or just noted for use in a custom feature. When working with configurations and FeatureScript, these are the values that matter. The Display values are what the user is expecting, but these are the values that need to be used when specifying configuration data.

Current Part Studio Configuration Variables

First way of looking at the configuration is through variables. In a part studio, the current configuration is set as variables. For a known configuration variable, we can do:

getVariable(context, name);

But, if we don't know the name of the configuration variables:

getAllVariables(context);

And we can look through for what we think are configuration variables. For example, we could look for tables that default to starting with "List_"

var allVariables = getAllVariables(context);
for (var k in keys(allVariables))
{
    if(startsWith(k, "List_"))
    {
        // Do something with this variable
    }
}

Its not completely fool proof, but if we can use some assumptions in our FeatureScript, it will make things easier. If our feature was the first one in the tree, we could assume that all the variables are configuration variables. There is no one right answer here so you will need to make the appropriate choice for your scenario.

This can also be applied to computed properties. For a configured part, the property will be computed for the specific configuration. All that is required is the context, so if we are only looking at variables that start with "List_" we can have the configuration name as a custom part property.

annotation { "Property Function Name" : "Configuration Name" }
export const configName = defineComputedPartProperty(function(context is Context, part is Query, definition is map) returns string 
{
     var allVariables = getAllVariables(context);
	for (var k in keys(allVariables)){
		
       if(startsWith(k, "List_"))
       {
           return allVariables[k];   // only selects the first one
       }
	}
}

Now, this only works for a single configuration table, so you might need to modify for your situation.

PartStudioData Configuration Data

When using a partstudiodata input type in a custom Feature (its the input type that lets you select parts from other part studios), the configuration data is also available. This is a requirement for something like instantiating. But there is more than just the current configuration available.

Starting with a part studio data parameter:

annotation { "Name" : "Part studio" }
definition.myPartStudio is PartStudioData;

We have two properties to look at:

definition.myPartSudio.configuration
or
definition.myPartStduio.configurationData

configuration gives us the current configuration selected by the user. This gets used in something like an instantiator function, or can just read what the current configuration is. This is a map where the keys are the variable name, and the value is the selected option.

configurationData contains information about the configuration variables and tables that are setup in that part studio. Again, this type is a map containing a key with the table/variable name, and the value is dependent on the type of configuration input.

Tables contain - options, defaultValue. The list of options could be used to generate a matrix of all configurations.

Variables - Such as lengths or boolean contain a defaultValue.

This information could be used to either generate new configuration with the instantiator, or have context information about both the current configuration and other configurations.

If you still find all of this a bit overwhelming? SmartBench Software is the industry leader in Custom FeatureScript and Onshape integrated application development. Checkout our services page for more information, or contact Caden to schedule a discovery call.