Best Of

Hi there,

I have a cylindrical solid bar. In each end, there is to be a counterbore/cylindrical cutout for the shoulder of a shouldered socket head cap screw, plus a tapped hole. The direction of the threads in the taps will oppose each other.

I modeled the bar as an extrude. I modeled the shoulder cutout features as extruded cuts. I then created a tapped hole with the hole feature on one end as shown in image 1. It is an M4x0.7mm tap 10mm deep, with the pilot hole being 14mm deep, to allow room for a plug tap. Call this tap1.

I then move on to create the second tapped hole feature. It is to have the same drill and tap depth as the previous tapped hole. Call this tap2. To do this, the drilled regions of tap1 and tap2 will intersect, but the threads won't. However, when I try to create tap2, what I get is an error saying "the hole does not intersect the part". I do not get this error when I reduce the drill depth of tap2 to be such that the drilled regions from tap1 and tap2 don't intersect (as seen in the image below).

Therefore, the issue is independent of the thread depth. The error message is incorrect. The drilled hole for tap2 does intersect the part, and would remove material, up until it reaches the drilled region from tap1. It seems that the hole feature doesn't allow intersection with another hole feature.

From a manufacturing perspective, it may be bad practice to drill and tap tap1, then drill and tap tap2 (as the order is described above). In actuality, you'd likely drill the pilot hole thru the part (in onshape, use an extruded cut), then tap from either end (in onshape, two separate tapped holes). However, I cannot replicate this last workflow in onshape, as the "tapped hole feature" will have a warning saying that it doesn't interest the part (no geometric change), and the hole won't generate.

Therefore, I'd like two things:

1. Perhaps an explanation from someone who works for onshape explaining why this is the behavior of the feature. I see this as a valid limitation to current modelling capabilities. This part can definitely be manufactured, but can't yet be modeled in onshape. If I am incorrect, please do let me know!
2. A possible workaround, so that I can portray the threads from the two threaded holes in a drawing with the correct depth of tap2, and be able to send a drawing for this part to our manufacturer on time.

Thank you for any information you're able to provide!

Zane

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.