Best Of

Ok, thanks! Can I have a configuration variable in the OpMerge Context or is there some other way around it? Normally I would configure the height and width when I instanstiate?

//instanstiate based on family code


if (product.FAMILY == "AA" || product.FAMILY == "BB" || product.FAMILY == "CC")


{


var size = decodeArray(context, { "input" : product.SIZE })[0];


const instSourcePart = newInstantiator(id + "SourcePart");


addInstance(instSourcePart, SOURCE_PART::build, {


"configuration" : { "Height" : stringToNumber(size[0]) * millimeter, "Width" : stringToNumber(size[1]) * millimeter

},


});


instantiate(context, instSourcePart);


}

Or, is there a scaleable and robust alternative workflow for this? Bearing in mind the person operating is not necessarily an experienced CAD user to minimum 'touch points' are a must.

You can set the configuration in the build function:

 var config = {
        "width": 5*millimeter   
    };


    var buildFunction = MyThing::build(config);


    opMergeContexts(context, id + "mergeContexts1", {
            "contextFrom" : buildFunction
    });

Thanks a lot, this gives some idea of workflow:

https://cad.onshape.com/documents/335c3bc233fcce3c30b2039c/w/bdd4614f35a7e60f537fe3ef/e/7aacf76406137249751d0c24?renderMode=0&uiState=66c51b790dbef66be5bf6556

Hello,

We use feature script extensivley for running configurations. There are a few reasons for this, but essentially we can bypass assemblies, drive the configuration using strings rather than enums, and the configurations are typically much easier to maintain. In previous iterations of products we have done the configuration in the assembly and they tend to be temperamental.

This particular product can have hundreds if not thousands of possible configurations.

The typical workflow runs something like this:

• Source parts are created in part studios
• A featurscript is made which can read a table of configurations, I have built a few custom features to help with this, such as one which converts a imported .csv into an array of maps with the keys based on the header row, and another that allows for arrays to be written as strings and converted to allow them to be entered in the table.
• The featurescript then based on the logic of the configuration, instantiates the relevant part studios, and assembles them in the context.
• A good part of the configuration is the machining of holes and slots in a particular pattern, and this is done once the assembly is made in the context.

This flow has been very effective in the past, essentially the end user just enters the product code as a string in the feature input, adds the product size, and the product is fully built and configured in the part studio just with a couple of clicks. It is so much easier to maintain than using part studio and assembly configurations.

The issue I have now is that I'm trying to import sheet metal models, and they don't bring the sheet metal context through when instantiated and then I can't get the sheet metal pattern. Any ideas? One work around is to make the sheet metal parts in the featurescript which is ok for simple parts, but as soon as there are some flanges etc it becomes very difficult to query a particular edge to treat, for example to add another flange or a radius.