Why can't OnShape generate "oversize" chamfers? (Question/Feature Request)

aidan_fraser · May 2022

Hi all, sorry if this is a repost/resurrection of an old topic but I couldn't find much discussion about this.

Often I find myself wanting to use a sweep shape or chamfer distance that onshape doesn't accept. It's "too big", it has self-intersections around tight radii and I get an error message about self-intersection.

Another post by an onshape employee on another thread suggested this was to avoid generating bad geometry. I understand that we want to avoid bad geometry, but this isn't a satisfying explanation for me.

I'm trying to understand the rationale for the restriction. There are reasonable cases when a sweep or chamfer intersects itself. Often, increasing the sweep radius, or reducing the size of the sweeping shape can be a good workaround, but often it's an unacceptable compromise.

One common case I find quite a bit is trying to model a routed cut along a curved edge that has some radii/details that are smaller than the routed shape. I think it's a reasonable thing to want to do, because it's easy to imagine and describe the part. And manufacturing it can be really simple with a standard router.

I accept I may being totally naive here, but it feels like OnShape could accept "oversize" chamfers, at least in some simple cases (e.g. circular radii), since manually modelling these cases usually doesn't require a lot of thought, just lots of clicks and extra planes and sketches.

Thoughts?

EvanReese · May 2022

I think I get what you're asking. If I do, then I think it's not because it's not possible to do, but it's a lot more math and coding to get it to work and the use case is niche or at least not main stream. Of course I could be wrong because I don't do a lot of router work. Perhaps there will eventually be a sweep with a body as an input so you can simulate the exact path of a cutting tool like a bit. I know Solidworks has something like that.

nicholas_radzykewycz · May 2022

The best way I have found so far to do this is to make use of the slot sketch tool. Create your cut path, then go into the sketch and use the slot command and go down the path. You will then be able to set the diameter of your end mill to whatever you want, when it intersects your slot it will temporarily show an error, but once you click submit on the sketch it will resolve itself and clean up all the unusable sketch regions. Select your entire newly created sketch of intersecting slots, and extrude downwards to your depth of cut.

See Example contrasting the sweep approach with the slot approach:

https://cad.onshape.com/documents/b69d02e2fb6a21f644c95b14/w/9c791d33ceaf0c34a71ebe9d/e/ff94bfe49a468bd29bd3d460

@NeilCooke Any chance we could get skSlot into featurescript? I really want to make a featurescript for this milling function but I don't see the already existing slot command in the sk commands and I'd rather not re-derive the Slot sketch function from first principles if you are willing to give up it's secrets.

NeilCooke · May 2022

@nicholas_radzykewycz unfortunately, the slot tool is not a FeatureScript function, but a server-side routine that adds all the offsets, arcs, and constraints.

aidan_fraser · May 2022

A picture tells a thousand words?

Hopefully this explains what I mean. (Check out the source doc if you like)

Image: https://us.v-cdn.net/5022071/uploads/editor/kx/5stmirc9v2dt.png

aidan_fraser · June 2023

Hate to resurrect a zombie thread like this, but I continue to run up against this issue. Wondering if anyone, especially staff at Onshape, can weigh in on this definitively.

This "over-sized chamfer" feature would make OS more expressive, and parameterized models would be more robust (bigger parameter space). Maybe I'm a weirdo? Wouldn't be the first time! But it's hard to imagine this not helping a lot of OS users.

I am pretty naive to the way OS is implemented, but I imagine it's possible to detect intersections in the swept chamfer and internally split the chamfer into two separate chamfer operations.

Maybe I should try to make a prototype FS feature?

aidan_fraser · November 3

Is it rude to continue to bump this post? 🫢

I would love any kind of response from Onshape staff here, even if it's brief. Surely I'm not alone in running up against "maximum chamfer" limits?

S1mon · November 3

Someone should create an improvement request.

NeilCooke · November 9

@aidan_fraser the reason we don't do it is because Parasolid does not allow it. Thanks for the improvement request. This is the first time anyone has asked for this capability, so until it has been reviewed and implemented it might be quicker to create a custom feature if you need this every day.

martin_kopplow · November 9

There have been requests in the past to make chamfers more robust in general. This case here appears to be only one example. Just yesterday have I had an issue with chamfers not resolving after a change in geometry, even though the very area where it would create said Parasolids issue was not actually part of the model, because another piece of the solid took that place, and the edges involved would never actually meet. But since it is not uncommon (also with other software), I worked around it by modifying the model history. That would, however, mean that if - for any reason - someone wanted to change the geometry again, it could be necessary to modify model history again. That is not the spirit of a feature driven modeling approach. So, even if Aidan's case is one of a kind, the underlaying issue of chamfers failing whenever their edges meet (even if it was in a distance that is no longer part of the model at the time of editing), is still generally important. It appears direct editing modellers have less or no issues with this case.

aidan_fraser · November 10

Thanks for the response both of you.

@neilcooke I’m surprised I’m the first to raise this. I’m willing to accept maybe I use chamfers strangely. It’s possible there’s an easy workaround i’m not thinking of, or “macro chamfers” are typically modeled without using the chamfer feature.

When you next get the opportunity, please ask customers who use chamfer whether they run into the restriction and if so, how they deal with it. Would love to know. Maybe it’s not been reported because simply it’s always possible to “manually” build a self-intersecting chamfer, and there are “bigger fish to fry”.

Regarding “parasolid does not allow it”, I take that to mean it would be non-trivial to implement, which I have respect for.

It seems, then, that for this capability to be prioritized, it would have to be shown to be valuable enough to customers to be worth the effort. If so, I’ll try to gather evidence of this, although I am not well connected with OnShape users. I’m currently just going on instinct, and I’m willing to discover I’m wrong to think this would be a valuable improvement.

Also, just spitballing, perhaps an implementation could try to use parasolid’s “native” chamfer and, if it fails, retry with a more sophisticated approach that support self intersections. I’m happy to try to implement a featurescript prototype of that “sophisticated” approach, to show its potential value (and that it’s possible). Not sure how far I’ll get to be honest. I am a software developer by trade, but I’ve found the foundations of FS difficult to grasp so far.

@martin_kopplow ”direct modelling editors have less or no issues”

Yes, this is absolutely correct. Blender, for example, is sometimes inperfect but almost always allows chamfers to be pushed into self intersection.