Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.
First time visiting? Here are some places to start:- Looking for a certain topic? Check out the categories filter or use Search (upper right).
- Need support? Ask a question to our Community Support category.
- Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
- Be respectful, on topic and if you see a problem, Flag it.
If you would like to contact our Community Manager personally, feel free to send a private message or an email.
This type of error makes my experience of onshape incredibly frustrating

Here Onshape is able to chamfer one edge but fails to chamfer another edge that is identical to the first. Not only is the failure to chamfer illogical, the error message gives the user nothing. As a user, you are left to figure out whether it's your sketch, whether it's a bug, or maybe you clicked the wrong entity? In short, your troubleshooting options are all options. You get zero clues that might narrow down your search for the solution.
Except, there is no error. That 4th edge is able to be chamfered, without alteration. Just do it in a separate operation. When you figure this out, especially after you went searching for why the error occurred in the first place, then you have just wasted your time.
I draw a sketch that is symmetrical. The circles are symmetrical by definition. The edges in the upper half of the sketch are mirrored from the lower half. Therefore the shape I extrude should is symmetrical.
When I go to chamfer the extruded shape, I can chamfer the 3 edges. But not the 4th. Except, I can chamfer the 4th, just as long as I do it in a separate operation, proving that the chamfer tool here in this example does not work consistently. [edit: add "Or, instead of 2 separate operations, just pick 5 edges and that 4th edge, that could not be chamfered before, is now chamfered."]This type of illogical inconsistency is frustrating, makes me second guess myself and wastes users time.
Please Onshape, get rid of these types of errors. They occur regularly for me and turn simple tasks into frustrating wild goose chases often resulting in solutions like this one (which don't always work), or the redoing of work.
The Sketch:
The Shape:
Chamfer tool can do 3 edges:
But it can't do 4 edges and can't tell me why it can't do 4 edges:
Expect it can do that 4th edge:
Comments
Out of interest, if you make the V shaped faces parallel, does it still fail?
Use the "Offset" measurement type
In addition to Greg's note, Selecting faces in this set up will also reduce the selection set. Less mouse clicks without zooming around to get back side.
tangent definitely doesn’t seem to be the right application in this case. Curious why tangent was selected?
While it can be frustrating for a new user (no idea what your experience is…no judgement there) especially those unfamiliar with some of the terminology that is used in software….the challenging experience now will lessen the impact things like this going forward. Non manifold geometry and self intersecting geometry are foreign concepts in the beginning and trip up many for long than it probably should. Maybe a link when it occurs to an explanation would help. Same with sketch is not fully defined. A link to a thorough explanation for newbies to follow when it occurs would definitely help. Every software has its quirks and preferred way to work with it.
Tangent wasn't selected as such, it was the option that the chamfer window opened with.
How do you get to that conclusion that tangent is not the right method for this scenario? Tangent seems to work because the chamfer applies in 2 separate operations. And, very interestingly, it also works in one operation if I select more edges. With that type of feedback that I get from onshape, where in that feedback is my clue that this is the issue?
Unconstrained sketch is not important in this case but I understand the importance of constraining sketches when you are going to adjust measurements later, or use variables etc.
Yes, seems to fail using the tangent option but works as stated above by others using the offset option:
Greg, what's your process to get to that answer? I ask, because from the situation that I was in, I couldn't identify anything that helped me narrow down my options. I'd love to have some idea of where to look when I encounter these situations.
Also, any idea why it works on 2 separate operations?
@martin_danger - I can't swear to this, but I suspect there are issues with (id's/naming) of faces or edges - and this is causing the feature to fail (and why it works in two separate operations). Fillets and chamfers are notorious for being touchy concerning order of appearance issues. That's why they recommend doing those operations last, if possible. This is not a terribly good explanation, but I hope it helps a little
Thanks Rick,
yours is the only answer that attempts to address the main issue for me - the inconsistent and illogical results that onshape returns for some operations. It is this behaviour that makes it so difficult to learn from your mistakes.
@martin_danger
A little more explanation - When using fillets or chamfers, if you select to many edges (the ones that use the same id's twice) it will throw that error. The fix is to split up the operation, into 2 separate fillets, this way there is no conflict between id naming. Because of the complexity inherent in fillets, trial and error is the only way that I know of, to deal with this issue. Once you realize what's happening it's only a minor inconvenience. I look at this as the price you have to pay, for the free use of the program - and they are constantly making improvements, so who knows. Good luck
Thanks for that explanation Rick. Splitting it up into separate operations is something that I have used before. I used that workaround before assuming I was making a mistake of some sort so that's why I thought I would try to work it out this time around and post it here.
But, and this proves my main point here about illogical and inconsistent results, selecting MORE edges to chamfer [edit: removed 'fillet'] results in no error. So your explanation of an edge ID being used twice doesn't seem to explain the error in this instance, unless selecting more edges somehow resolves the duplicate edge ID issue.
It really does 'feel' like some kind of programming issue. I mean, those are often the ones that give you odd results like this that just don't make sense and aren't explained by theories that have worked in the past.
While I agree it can appear to be odd and inconsistent on the outside. Computer programming is always consistent in its results. Going forward I think you'll find that features that "terminate" into themselves are not handled. I haven't explored that thoroughly just a hunch. Curious if fusion and solidworks handle that well.
I think it's just a bug, probably in the kernel. My guess is that the tangent option is not frequently used. We filed it and the part studios team will take a look.
In my experience with other CAD systems, (NX mostly) there are often inconsistencies in behaviour for the same or similar operations.
it is my understanding that this is sometimes caused by the tiny differences in the tolerances of the geometry underlying. where talking about the difference between 4.999999999999 and 5.000000000000001 (I'm not sure how many 0's Onshape uses).
I was trying to replicate your issue and it was very easy, so it may also be the 'weakness' of this chamfer algorithm. a face-blend set to chamfer is a more robust tool, (but also more comprehensive and therefore worse UI).
It was also solved by switching from 1x45 degrees to an equal distance chamfer.
The best solution is to never draw symmetrical parts as a whole. Only draw half and mirror (or pattern for rotational symmetry).
This will also save you time (clicks) and performance, and can prevent accidental assymmetries (if you forget to click both sides).
after the mirror for my parts, there are only intentional assymetric geometry changes. (often logo's and poke-yoke features).
I get that a computer program always gives the same results, except for those rare bit-flip cases. But just because a program is consistent in its results doesn't mean it behaves consistently when we think about its actual purpose. Its purpose is to assist people in the design process, so we need to evaluate its consistency based on human expectations. If a program only measures itself by whether it behaves consistently from a programming standard, it will be almost impossible for people to use it effectively.
The example above highlights this issue. From a human perspective, the result seems inconsistent, and I don’t see a valid argument against that. Yet, this same mistake can be reproduced consistently, which does suggest that, in a technical sense, the program is behaving consistently.
Hi Jelte,
thank you for your suggestion there. Yes, I will try to use that approach more often. I didn't in this case because drawing the full sketch was easier and quicker to do than the half. But of course, I paid for that initial time saving by dealing with the chamfer issue later!
@martin_danger
I had absolutely no problem getting 4 chamfers on my first try
https://cad.onshape.com/documents/5a4d51735f2ebc5b0a7ea05a/w/88c2bc54bfff9abae04c9482/e/94068328586a06d795e2f5b8
At this point, I do have a guess where the problem MIGHT BE in your document, But it is hard to be sure, because I didn't see a link to your document as I just skimmed over this whole thread.
Without access to your document, I am GUESSING this MIGHT be where the problem is.
But it is a big guess at this point. Looks like things might possibly be fighting with each other at each of these points.
I believe there are points coincident to the 35mm diameter construction circle where the red arrows are pointing to that should be removed and this would possibly free up the problem you are having.
Notice that in my sketch at the link above, I did not have any such coincident points, and as such, this is why I was able to make the 4 chamfers at the same time.
Any constraints where the RED ARROWS are pointing to in the post/picture above should be removed.
If you want to make that 35mm construction circle coincident to the vertical line, the constraint should be placed where the GREEN ARROW is pointing to below.
Andrew, your post has disappeared. I wanted to thank you for writing it as it expressed so well the experience I was trying to convey. Did you intentionally remove it?
Hi @steve_shubin
thank you for sharing that document and your solution.
In my sketch, there were no constraints between those two points marked by your red arrow and the 35mm construction circle. However, assuming you meant that I should remove the 2 points that the red arrows were pointing to, I did that and still got the same error. I'll post the screenshots in my next message.
I do appreciate you looking into this issue I am having, however, that is not the point of my post. @andrew_kleinert described it well in his now missing post above. These errors keep happening and it's difficult to figure out if it's me or if it's OnShape. The lack of feedback about errors makes troubleshooting them time consuming because you aren't given any clues to narrow down your search for a solution. You then face the decision of either starting again (often quicker than troubleshooting) or starting again and spending even more time to write a bug report.
You know the saying that one should learn from their mistakes? That isn't possible with these types of errors. Not in a practical sense anyway.
Screenshot showing no constraints between those two points and the circle.
Screenshots showing two points removed and tangent constraint between horizontal line and 35mm circle as suggested and how resulting chamfer error persists.
@martin_danger
I understand you're wanting more extensive feedback from the program. I am not a programmer so I couldn't say how involved that is to do in this case. I could only imagine that having a program that gives a lot more guidance could possibly be a pretty heavy undertaking for the programmers.
Regarding all the 3D programs I've used, I'm trying to think back regarding how all these programs were with trying to head off problems. I'm having a bit of a time remembering all but I am concluding at this point that none were perfect, that is for sure, as I figure I probably would have been a lot further along in my ability to use them.
So along the lines of how well a program steers you —- I'm not much help at this point.
Now as stated above, this may be a bug in the kernel. So if that is what it is, then hopefully this could be brought to the attention of the kernel maker — Siemens.
Aside from the above, I do find it at least a bit interesting on how it seemed to work so effortlessly in my case
So with all programs, they way I figure it, it's a matter of trying to figure out all the do's and don'ts.
Along these lines, one important thing that has helped me to use Onshape has been the ability to see how others have gone about constructing their parts — by being able to review the feature list and sketches and such in their documents. In fact in my case, I would say this has been maybe the most important aspect of my learning the program.
So if it were possible for you to post a link to your document, I sure would like to look under the hood a bit. Maybe I could learn another thing to look out for.
@steve_shubin Here's a document for you to explore. Adding an edge or face seems to let the chamfer work fine. https://cad.onshape.com/documents/8092b726982e19bbd6e8a8dd/w/fd3b7d732b9db64632cb189f/e/1a8630e1a1fdba5c3a4adf16
So it sounds like it's working fine for you also. Yeah, I had no problem myself.
Thanks for the post, but what I want to see in particular is the @martin_danger document.
I'd like to see what is causing the problem with Martin's document, if it is possible to detect.
no it’s not working hence the red chamfer feature. It’s very repeatable
Hi @martin_danger, thanks. Yes, I did intentionally remove it.
I think you've made a fair point about your user experience with Onshape, one I strongly empathize with. You provided a worked example to illustrate your point.
(A) Others in this thread have been very practical and shared their time and expertise to provide solutions to your worked example. That's to their credit and our benefit. And that's all the user community can do.
(B) As helpful as the user community are, it still doesn't address the root cause of the point you're trying to make. If your user experience is anything like mine, you could have just as easily have posted many other examples. Some of them will be user errors, some of them will be sub-optimal modelling practices, some of them may be limitations of the software for which there are work-arounds, and some of them may be bugs. Irrespective of what they are, it all detracts from the user experience because they're blockers and there is very little feedback provided by the software to help the user get over those blocks. And posting it on a forum to get support from the user community, or reporting it to support, doesn't feel like it should be the panacea.
I deleted my post because, as valid as I think (B) is, I didn't want it to detract from (A).
In summary, if instead of those annoying NPS surveys Onshape send out from time-to-time, if instead they asked "From your user point of view, would you prefer if Onshape invested resources into (1) adding more features, and if so which ones?, (2) Improving the UX? or (3) improving testing, bug-fixing and making the system more stable, reliable and deterministic?" My answer would be along the lines of "I'm currently having a lot of trouble getting Onshape to understand my design intent and it feels a bit unstable. I really don't know if (2) or (3) would help me more. But as interesting as features like generative design and more simulation functionality are to me, I definitely would NOT vote for (1) at this stage"