Synchronous Sketching, Spaceball bugs, BlueDots

I’m jumping in right now to play around with synchronous sketching, and I’m finding something I’m not too impressed with. Is this Matt-the-Noob ready to learn something new? or is this a weakness in the tool? Watch the movie and tell me which it is.

Update: Ok, this is from Dan Staples. Dan says that yes, there is a dependency there with a certain direction, but that is created by the relationship added.

So instead of trying to do this with synchronous sketches, let’s try to do it with ordered sketches and the BlueDot. This actually works. You wouldn’t think that ordered would succeed where synchronous fails, but its true in this case. …that is unless some of this is operator error, which is entirely likely.

If the presentation of this information looks scattered and fragmented, that’s because I’m trying to learn something at this point, rather than trying to teach something. I’m just letting you follow my disjointed learning process. Let me tell you, trying to write a blog while you’re learning a topic is harder than it looks. ;o)

===================================================

Ok, so after all this failure, I’m starting to feel pretty comfortable. I try to trick the software now. We’re getting into familiar territory: workarounds. I’m not confident yet in the sketcher, but I’m sure this will change. I’m pretty disappointed that even within Synchronous mode, you still have directional parent/child relations. I thought this was the whole point of synchronous, to get rid of these.

Anyway. Here’s my workaround attempt. I make the two splines again, and I’m more careful about how I draw them. I’m learning. Action-object. I can’t seem to make object-action work in synch sketches. I constructed this sketch, thinking I could game the system a little. I create an offset plane, draw the circle on the plane right above the origin, then draw 3 pt splines on the other two perpendicular planes, with the mid points of the splines at the center of the circle. I thought then I’d be able to just move the circle to get the two splines to expand. Still not getting that one to go.

Here’s what I’m expecting: I’m expecting to be able to pull up the middles of the two splines at the same time, regardless of which one I’m editing at the time. I’m expecting that synchronous sketches in SE will work just like a single 3D sketch in SolidWorks, except that everything will work the way its supposed to. 3D sketches in SW are notoriously buggy, but the concept is perfect. If this were solid geometry, Solid Edge would be able to make the edits perfectly, but it can’t manipulate sketches? If I understand this correctly, then there seems to be a disconnect. I guess the idea here is that sketches are throw away items, but it doesn’t account for what I’m trying to do with driving ordered features with synchronous sketches. You just can’t get there from here.

Maybe I just can’t let go of the idea of driving 3D with 2D. Maybe this situation would never really come up in the world of things you actually do in SE. I’m definitely expecting the 2D parametrics to be as good as the 3D parametrics. Where would I use this?

7 Comments

Add a Comment
  1. Really interesting to watch you find your way around SE Matt. I haven’t adventured too much with sync sketches, but the blue dot can be a handy thing at times. There are a few areas of the interface with SE that seem to have been forgotten about. Try changing the input curves to a sweep or blue surf. I swear it is written in code or a deliberate puzzle. I am not a new user..

    Peter.

     

  2. So in the first example rather than invoke a pierced relation on the fly can you draw the 2 splines near on another and then pick your points and make them coincident and have it work? I presume the act of piercing immediately implies a relative order. Sorry if SW terms dont fit SE….

  3. Matt I’m sure Dan Staples will have the official answer to this, but my guess is that there are still aspects of Sync code that still have a bit of history in them. I think we all can appreciate just how complicated Sync has to be, in order for all this to work it’s magic. The fact that you still can move/edit the intersection of the two splines maybe tells you that SE Development left this “as is” temporarily while the new code is being written…. again I’m just guessing from past experience. Or it could be a rare bug. Anyway I have seen a few other workflows similar to this, that have a bit of “History” or Ordered mindset to them when working in Sync. It can be annoying to folks new to Sync until you realize it’s NOT YOU. Dan usually will step up and explain the behavior or workaround until these small issues can be dealt with.

    Again I’m sure you’ll agree this is not a show stopper but more of a little curiosity or remnant of the past still lurking.

    Bob

  4. Matt i may have a work around

    Here i brief.

    Draw your too spline, lets say on two perpendicular plane. ( front and side)

    Create a parallel plane (top) and set the height. On the parallel plane create a point.

    Then connect  any point of each spline to the point, Remember the the first select element, is the one that will receive the constraint ( it will be the child of the relation).

    If you have difficulty to connect two points, you may have to lock sketch plane to facilitate the connection.

    Once this is set, the point will drive the curve.

    Remember to set the curve to shape edit

    Not the best elegant solution but it will be close to what you are looking for.

  5. To clarify the order-independence in Synchronous sketch…

    1. Clearly the sketches are order independent insomuch as there is no “roll back” when editing them. You can always see all of them when you are editing. “Later” sketches do not get rolled back and disappear when you are editing “earlier” sketches. (you can turn any sketch off if you like, but it’s up to you)

    2. You can create a dependency between the sketches by establishing a constraint/relationship. This has nothing to do with the order they were created, but everything to do with the order you do the relationship in. That is, Matt’s Sketch 2 became dependent on Sketch 1 not because it was placed second, but because he established a constraint in Sketch 2 to the pierce point of Sketch 1. Instead, had he forgone the pierce point at that time, and then come back and made a constraint of Sketch 1 to the pierce point of Sketch 2 (yes, completely possible in Synchronous), then Sketch 1 (though placed first) would have a dependency on Sketch 2.

    3. Whereas this has many of the benefits of the 3D Sketch in SolidWorks it is quite different particularly in it’s solving. What Solid Edge Synchronous is doing in this case is a network of 2D solves that may have relationships between them. This will be significantly more stable than a 3D solve, which uses a completely different technology. This is no knock on SolidWorks (in fact they use our Siemens PLM solver technology) — it is just the state of the art, physics and mathematics — a 2D solve will always be more quick and reliable than a 3D solve.

    4. We are certainly not “done” in our work for creating the network of curves for surfacing applications. What you are seeing here is largely the (positive) side effects of Synchronous sketching for machinery design. As we put more attention on surfacing, you will see improvements in this and many other areas.

     

  6. I think it’s interesting that you truly can’t have completely independent features. Features are dependent on each other really from a functional standpoint as much as from a CAD “limitation”. Really a history is born out of reality more than because the CAD is a certain way, though the CAD definitely determines how those dependencies are created and how they interact.

    I think the need in terms of feature dependency is to be able to change that order easily. In SolidWorks, I’d like to be able to delete a feature without a mandatory deletion of sub-features and be able to re-order a dependent feature above it’s parent. I can then fix the errors and failures. At this point we’re not able to do that in most cases.

    It will be interesting to see where ST takes CAD. Might be improvements in both History based modeling and Synchronous Technology.

    Craig Sink

    Solid Improv

    1. You’re right that there are dependencies in design. But the artificial dependency in history-based CAD of a feature being dependent on ALL features that precede it is not necessary. Imagine you have a long part — on one end you have the first feature placed. On the other end, you have the 301st feature placed. These two have no design dependency. Yet, if you edit the first feature, the 2-301st features will regenerate — whether there are any design relationships or not. This is one of the big inefficiencies in history-based modeling. We tried for several years to solve it in the context of history, but it is not really solvable in that way. You need a new paradigm where the features are all peers, not linearly dependent — aka Synchronous Technology.

      This video is about 4 years old, but does a pretty good job explaining this.

      http://www.youtube.com/watch?v=jkCYbqU3NbI

       

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Heads up! You are attempting to upload an invalid image. If saved, this image will not display with your comment.

On The EDGE © 2013 Frontier Theme