Creating an accurate BOM in part studios even when all of the parts aren't replicated

monroe_weber_shirk

I'd like to create an accurate BOM for a drinking water treatment plant in a part studio (not an assembly). I'm in the process of implementing that by attaching part info as an attribute to each unique part when the part is created. That way if the part is replicated the attributes go with it and the part count remains accurate. I want to take this one step further. I want the ability to not actually replicate the geometry of all of the parts so that regeneration time remains fast. AND I want the part count to still be accurate for the BOM. 

My proposed solution is to add a counter to the part attribute that would be multiplied by the replications when the geometry isn't actually replicated. Thus this one part would essentially represent all of the identical parts and it would know how many of those parts exist in our water treatment plant. 

We would have the option of either replicating the geometry or multiplying the counter for a representative part depending on whether we wanted to show the geometry or not. In either case, the BOM would be correct. In the ideal world this would be an option in the linear pattern feature.

My question...
Given that this isn't likely going to be an option in the linear pattern feature, what is the best way to create this? 

1. Create a copy of the linear pattern feature and edit it to have this additional feature (seems like a bad coding practice)
2. Create a new part attribute linear pattern feature that only multiplies the counter on the part and then uses a configuration Boolean to select either the linear pattern feature or the part attribute linear pattern feature.
3. A completely different approach that I didn't think of!

Alex_Kempen

You should be able to write a wrapper feature for the linear pattern feature which calls the linear pattern feature directly. In FeatureScript, all features are functions, so using one feature in another is generally as easy as calling it and passing in an appropriate parameter definition.

// at the start of your feature, export the linear pattern std studio (might not be neccessary):
export import(path : "onshape/std/linearPattern.fs", version : "1560.0");

// copy and paste the linear pattern feature UI and add your own UI options as needed

// In your feature body:
// configure the linear pattern definition as desired (i.e. if (definition.tenInstances) { definition.numInstances = 10; })
// call the linear pattern feature directly:
linearPattern(context, id, definition);
// use qCreatedBy(id, EntityType.BODY) + the definition to figure out what got made and set attributes from there

monroe_weber_shirk

Thanks @Alex_Kempen. That was the pointer I needed. My understanding is that I do need to copy about 100 lines of code because the precondition and the function calls aren't neatly wrapped inside a function for the linear pattern. 

Alex_Kempen

Yeah, you'll have to copy over the UI, but you should be able to use the editing logic functions, feature body, and manipulator change functions directly. One of the features I demo'd last night was a wrapper for the onshape hole feature, which can be found here:
https://cad.onshape.com/documents/d33530b06909083111cf1770/w/5be0429e68b3332e158a3559/e/2ac1b130ef1d31461f8fca54

You'll notice that I copied and pasted the hole UI into my own predicates in the holeCommonUI.fs studio in order to make packaging a bit easier. Since not all of the hole.fs enums/and or bound specs are exported, I also had to copy some of those as well. Lastly, you can see that the editing logic function is also used directly with some manipulations that vary depending on my own settings.

You can also find a basic wrapper for hole.fs here:
https://cad.onshape.com/documents/4c21d0c3c89c0a81aadfdac6/w/a7ccf556a74ce09cd04151e0/e/de971c1cdceeb2372ae0a45f