Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.

First time visiting? Here are some places to start:
  1. Looking for a certain topic? Check out the categories filter or use Search (upper right).
  2. Need support? Ask a question to our Community Support category.
  3. Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
  4. 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.

Equal constraint - Use with Care between sketches

andrew_troupandrew_troup Member, Mentor Posts: 1,584 ✭✭✭✭✭
edited September 2015 in Using Onshape
In the excellent webinar on basic sketching which has just gone up on the site, the question came up "How do I relate entities in one sketch to entities in another". Cody replied that at present the only two methods are "Derive Sketch" and "Equal" constraint.

I though it might be worth adding a "Yes, but" to that second option, which if he'd gone into it more deeply, I'm sure Cody would have mentioned.

Essentially, an equal relation in sketch A will make an entity equal to the PROJECTION, into sketch A, of an entity in sketch B.




The bottom right line is sketched on plane A, defined by the underside of the hollow cylindrical solid.

It makes no difference to its length which of the highlighted lines at top left (on plane B) I constrain it equal to, even though their lengths are clearly different.

The line at bottom right is actually the same length as the upper one at top left.

It doesn't appear to be, being foreshortened in this view, because it is actually normal to the top left line.
It comes out of the page, from left to right.

Comments

  • _Ðave__Ðave_ Member, Developers Posts: 712 ✭✭✭✭
    Definitely a noteworthy observation @andrew_troup and thanks for the warning. I had to work an experiment to confirm my concept of your post. Therefore if I may and correct me if wrong but to be clear, the equal constraint works as desired whenever the sketches are on planes which are parallel to each other. The projected equal issue only occurs when the sketches are on planes which are not parallel to each other.   
  • andrew_troupandrew_troup Member, Mentor Posts: 1,584 ✭✭✭✭✭
    edited September 2015
    @da_vicki
    What you say is entirely true.

    However it does not invariably invalidate using it with planes which are not parallel to each other:
    In the case of planes not parallel to each other, it still works in special cases, because  an equal relation in sketch A will make an entity equal to the PROJECTION, into sketch A, of an entity in sketch B.

    My graphic showed such an instance: Plane A is normal to Plane B, and yet there is still the possibility of deriving benefit from an equal relationship.
    In the case of the upper left line in my graphic (on Plane B ), it is constrained parallel to Plane A (the base face of the cylinder).
    So it will project its full length onto that plane, meaning an equal relation to that line will "do what is says on the tin", with entities in sketch A.

    If you look closely at the graphic you may see the faint grey lines indicating the projection of the 
    Plane B lines: there's a rectangle there which is actually the revolve sketch for the cylinder. 

    (Note that the last statement in my previous post, about the line on Plane A being normal to the page, was included purely to help others interpret the ambiguity of a 2D graphic depicting 3D geometry.
    That line could be skewed to any angle on Plane A, yet the equal relation would keep it constant in length)
  • billy2billy2 Member, OS Professional, Mentor, Developers, User Group Leader Posts: 2,014 PRO
    edited September 2015
    2 lines 2 different planes. This should work. The equal constraint should not translate through matrix transformations (projects). 

    My vote, this is a bug.


  • _Ðave__Ðave_ Member, Developers Posts: 712 ✭✭✭✭
    @billy I'll go with a bug unless someone can explain any real usefulness otherwise.
  • lougallolougallo Member, Moderator, Onshape Employees, Developers Posts: 2,001
    It appears that the equal measures in plane.  If the sketches were parallel it works.  I have written an improvement.
    Lou Gallo / PD/UX - Support - Community / Onshape, Inc.
  • andrew_troupandrew_troup Member, Mentor Posts: 1,584 ✭✭✭✭✭
    edited September 2015
    @billy and @nav
    I think it's a question of consistency with how other constraints operate.

    All sketch constraints, without exception, are 2D not 3D, and are essentially internal to the sketch.
    It seems to me this is so desirable (for robust behaviour to model changes) as to be almost essential.
    I'll explain what I mean by "Internal":

    Take the example of a parallel constraint from a sketch line to a model edge. That model edge may start out lying on a parallel plane to the sketch plane, in which case a "parallel" constraint is uncontroversial and easy to grasp.

    However, say the model changes, so that plane is angled differently. 
    That edge needs to still dictate the orientation of the sketch line, or the model will fail, even if the plane is reangled by an imperceptible amount. Yet it is geometrically impossible for the entities to remain parallel.

    The only way there can be a viable parallel relation after the edit is to resolve the model edge to 2D, by projecting it to the sketch plane (internalising it) before permitting it to participate in a sketch relation.

    And this is not a special case. In every instance (although most users do not often notice)
    , sketch constraints operate with the PROJECTED, or internalised, location of external geometry (#).

    Hence my comment above, regarding consistency. 

    More examples: When the user creates a coincident constraint to a remote vertex, it is to the projection of that vertex; same for a model edge wandering about the model at funky angles: It is first projected to the sketch, in the "mind's eye" of Onshape (or SW, or whatever), in order to provide something to constrain an entity from within the sketch. If anyone doesn't get this, I'll knock up a study model to illustrate, but I think it would be even more instructive for interested or curious users to do that themselves.

    (#)
     (except for "Pierce", where it is patently inapplicable. This presents no great problem since the "Pierce" concept is self-defining, moreover it essentially still operates internally to the sketch)
    ___________

    I wonder if the sort of "equality" you (understandably) want to see might be better provided by linking dimensions, or by equations, or some other parametric intervention. 

    I'm not sure the complication would be helpful if "equal" were made the single member of a third class of sketch constraint, which is external in focus rather than internal.
    While it would ease the confusion about that particular relation, it would increase confusion about the significance of all other relations. It could almost be argued that "Equal" currently does the user a favour, by exposing a truth which is otherwise cryptic.
  • paul_chastellpaul_chastell Onshape Employees Posts: 124
    edited September 2015
    @andrew_trouphit the nail on the head. With all constraints (almost) the geometry involved in the constraint is projected into the plane of the sketch, exactly as if you did "use" first. The two current exceptions are pierce, where the 'thing' isn't projected but instead intersects the sketch plane (yielding a point), and constraints to a plane, where the intersection of that plane with the sketch plane (a line) is used.

    So expect all constraints to act on projections or intersections. We understand that there is a need to set up a parametric relation between, e.g. two circles on non-parallel planes, and we have plans to address that though it is unlikely that we will overload the constraints with more behaviors.
    Paul Chastell
    TVP, Onshape R&D
  • andrew_troupandrew_troup Member, Mentor Posts: 1,584 ✭✭✭✭✭
    edited September 2015
    @paul_chastell wrote:

    <<
    expect all constraints to act on projections or intersections>>

    Now THAT'S an epic distillation - worth chiselling across the top of a young CAD jockey's monitor.
  • billy2billy2 Member, OS Professional, Mentor, Developers, User Group Leader Posts: 2,014 PRO
    edited September 2015
    I don't think length should be projected. I get your argument though. 

    Not that this means anything, but I just made this assignment in SW and it doesn't project:



    'Z' is now up, and external constraints are now projected, I can live with that. Thanks for pointing this out. I submitted it as a bug yesterday so we'll have to see how cad Gods rule on this. I can go either way.



  • matthew_menardmatthew_menard Member Posts: 96 ✭✭✭
    I operate under these same constraints in Solidworks too, so this isn't necessarily an OnShape problem.  It would be nice to be able to make lines equal that would otherwise project as less than intended (or as a point if it is completely perpendicular to the plane).  However, equations/parameters/named dimensions would also probably work as a better fix to this issue.
  • andrew_troupandrew_troup Member, Mentor Posts: 1,584 ✭✭✭✭✭
    edited September 2015
    @billy
    I'm confused by your graphic.
    The fact that both lines are hi-lited makes it seem superficially as if both entities appear within a single sketch, but that's not the situation you describe (the only way I can make sense of it: maybe SW is hi-liting the second line as a way of illustrating the participants to the relation, which is indeed external, as is the second line?)

    Can you spell out all the construction steps?

    (If SW currently works as described, they must have made the change since I disembarked the upgrade treadmill!)
  • billy2billy2 Member, OS Professional, Mentor, Developers, User Group Leader Posts: 2,014 PRO
    edited September 2015
    red line on top plane & green line on front:



    So I'm editing sketch4 which is the green line and I set to the length of the red line. In onshape, this line length would be zero following your example. In SW they are equal.


    I think the cad Gods have spoken and the projected method is preferred in OS due to consistencies in downstream operations. This is different than SW. I'm using SW2014, not sure what SW latest thoughts are though (not staying current).

    Glad you pointed this out as I would have done it using SW methods and could be off. Thanks. 


  • andrew_troupandrew_troup Member, Mentor Posts: 1,584 ✭✭✭✭✭
    edited September 2015
    @billy
     I think you will find that if you do the same in Onshape, you will get the same result.
    The projection of the red line onto the front plane is full-length.
    The relation you are creating is in the front plane, as I understand it.

    ON EDIT: if you delete the relation, and try to recreate from the top plane sketch where the red line is drawn, I suspect your sketch will collapse and go a funny colour. I recommend the Heineken manoeuvre, should that happen  :#
  • billy2billy2 Member, OS Professional, Mentor, Developers, User Group Leader Posts: 2,014 PRO
    edited September 2015
    matthew-

    The cad Gods said that linking dimensions will give us what I (we) want with a more consistent interface. Linking and equation are coming and will handle this relationship.



  • andrew_troupandrew_troup Member, Mentor Posts: 1,584 ✭✭✭✭✭
    @billy
    actually I'm fairly sure of my ground for once, because I just remembered proving this to myself in Onshape recently

     because I exploited  that exact "loophole" in the rule "do not rely on equal constraints between entities which are not on parallel planes", to carry a dimension derived from a construction sketch over to an orthogonal plane, while responding to the challenge to model a dodecahedron with the fewest features.

    It was a workaround for the current inability to use equations or link dimensions between sketches.
  • andrew_troupandrew_troup Member, Mentor Posts: 1,584 ✭✭✭✭✭
    @billy
    We cross-posted, and you might have missed one of my posts.

    I think you were mistaken in interpreting the implications of your test:
    the example you posted does not demonstrate that SW and OnS are any different in how equal relations are implemented.
  • Narayan_KNarayan_K Member Posts: 379 ✭✭✭
    I checked the same with Solid Edge it is also gives the same result of Onshape.It is also taking projected length of line(drawn in other plane) for equal contain.
  • shashank_aaryashashank_aarya Member Posts: 265 ✭✭✭
    Just now I checked this condition in Creo and found that same results appear as @da_vicki explained about parallel and normal planes. But in Creo we can apply parametric relations between sketch dimensions even if they are not on parallel planes. Definitely this can be one of the improvement when Onshape will introduce the parametric relationship between sketches.
  • andrew_troupandrew_troup Member, Mentor Posts: 1,584 ✭✭✭✭✭
    ... in Creo we can apply parametric relations between sketch dimensions even if they are not on parallel planes.....
    Same is true for Solid Edge and Solidworks

    So, summing up for constraints/relations: we have verified that Onshape, Creo, Solidworks and Solid Edge all implement them, to elements which do not lie in the sketch plane, the same way: to the projection (#) of those elements onto the sketch plane.

    (#) or intersection with the sketch plane, in the exceptional cases @paul_chastell instanced
    It's important to remember that projections are always projected normal to the sketch the element is being projected onto.
    Obvious as it seems, this occasionally trips up even the most experienced users. 
  • rune_thorsen229rune_thorsen229 Member Posts: 179 ✭✭
    @billy and @nav
    I think it's a question of consistency with how other constraints operate.

    ...
    While it would ease the confusion about that particular relation, it would increase confusion about the significance of all other relations. It could almost be argued that "Equal" currently does the user a favour, by exposing a truth which is otherwise cryptic.
    Totally agree on doing the user a favour: CONSTRAINTS BETWEEN ORTHOGONAL PLANES see also coincident vs. pierce,  Fastened mate orientation error/bug/unexpected behaviourAllow transform to work on sketches
  • rune_thorsen229rune_thorsen229 Member Posts: 179 ✭✭
    ... in Creo we can apply parametric relations between sketch dimensions even if they are not on parallel planes.....
    Same is true for Solid Edge and Solidworks

     
    Except that onshape sells itself as "next generation cad" ;.P
     


Sign In or Register to comment.