To "Coincident Constrain", or "Concentric Constrain", that is the question. (Misquoting Shakespeare)

StephenG

I have always been curious why some CAD products have both a "coincident" and a "concentric" constraint.

I understand for certain types of 2D curves (those that have a center attribute, not a mid point along its length) it might be more natural to think in terms of making curves concentric versus making their respective center's coincident. Internally, I wonder if the 2D constraint solver treats them differently; Onshape's doesn't seem to differentiate between the two.

For example, even though Onshape strongly implies "Concentric" can only be used with arcs and circles...
 
it is possible to create a concentric constraint between the end points of 2 line segments, or a curve end point and an arc/circle; effectively it functions a coincident constraint. The only difference I have found is the Concentric constraint gives one the ability reference an arc/circle/ellipse's center point by selecting its associated curve. Maybe this is justification enough to keep it, but I am of the opinion that when an easy to use general purpose function (coincident) is available, the specialized variant should be depreciated. The benefit being less functions to learn and a less cluttered UI. Space is opened up on the toolbar to add (make visible) something else.

For those that argue a concentric constraint is important from the standpoint of capturing/expressing design intent, I wish that 2D constraints were always applied in a way that accurately reflects design intent to support the GD&T process. But the reality is that 2D sketching constraints are used as hammers to beat a collection of curves into an idealized shape that hopefully will survive reasonable dimensional change. I do not expect to see that approach change in my lifetime.

The esoteric of how to tolerance geometry to manufacture a product that still functions is not a top (a non) priority during the geometric modeling design phase.

To the best of my knowledge no CAD vendor has attempted to use a 2D sketch constraint schema to drive the GD&T process.

Onshape (at this time) does not even make available (display) the driving dimensions in a drawing. (Hopefully, we will see this functionality soon.)      

paul_chastell

A little background on our reasoning may help. We considered it sufficiently useful to make a concentric constraint that captures design intent, expressly so that a user could say "these circles are concentric" rather than "these circle centers are coincident". That is even more important when referencing edges of the part because the center of circles/ellipses is not available for constraining to. I should also mention that concentric constraints are added by users a lot, more than either parallel or perpendicular, and the number of concentric constraints created recently was roughly 1/3 of the number of coincident constraints. One user's "I have too many buttons, this is redundant" is always going to go up against another user's "where is tool X?". I'm confident we made the right choice in this case but, as with many aspects of Onshape, we constantly review our workflows and functionalities in the light of both feedback and data.

StephenG

I was not aware the bounding edges of the face selected to create a sketch plane were that accessible for constraining.  I have not had an issue using the coincident constraint to constrain to a circle/arc center to the center of a circular edge on the sketch plane because I always use "Use".

It is my practice to "Use" the edges that are going to be leveraged in the sketch. This is done for 2 reasons:

 1) I have found that things just work better; the result is a more consistent and predictable.

 2) A "Use" curve is displayed with a thicker line width which makes it standout; this provides better communication about the purpose of the sketch curves and its dependency to other features in the part.

As I get more accustomed with how Onshape works I see that I can take shorts cuts.

If the purpose of providing the Concentric constraint was to support a "these circles are concentric" thinking, then where is the "Co-linear" constraint, which supports the "these line segments are to line up" thinking?

I guess my biggest complaint with the Concentric constraint is, that contrary to what the tool tip says, it can be used against non-circular sketch entities. 

Since you seem to have access to metrics on Coincident/Concentric constraint usage it would be interesting to see if there is a consistent correlation between a concentric constraint and a true GD&T concentricity callout in the drawing.

By "depreciating" it I do not necessarily mean getting rid of it. A good compromise might be to stack it under the "Coincident" tool bar icon (along with the "Colinear" ).