Synchronous Technology: part II

118 0

I’ve been plugging through everything I’ve learned so far about Synchronous Technology, so here it is. The essential difference between Synchronous Technology and other systems out there that many are comparing it with (let’s be frank, that’s SpaceClaim, CoCreate and to a much less extent, IronCAD), is not so much the ability to interact directly with geometry, but rather the manner in which you add intelligence to your 3D product model.

When we design a product, we have two things in mind. What it looks like, whether in terms of aesthetic quality, but also that it need to fit and provide a certain function, and that’s often governed by form – after all, parts need to interact with those around them. But alongside this, you also need to be able to specify how a product is formed. Rough dimensions don’t cut it, you need to be able to tie information down, lock it out and ensure that the geometry you create fulfills a need, for function and performance.

In traditional history based systems, the latter part is much easier, as you are defining geometry from a very root level, which captures your design intent – but only just. the fact that you often have to add excessive dimensions and constraints at a feature/sketch level, means that the process is counter intuitive. In other words, history-based modeling is too over burdened.

What it DOES give you is the ability to add a lot of intelligence, so design change can be automated, dimensions and constraints interlinks between sketches, features, parts and sub-assemblies. But the end result is a dataset that’s horrendously complex and effecting even a small change can result in a parametric nightmare that take herculean effort to resolve – and in many cases, user remodel from scratch just to avoid it.

Direct Editing applications (such as CoCreate and SpaceClaim), work from the other end, where you play with the geometry and the constraints you apply (be they dynamically input, or more commonly, just a case of drag and drop geometry) are not maintained and stored. So, you can add dimensions if you need to, but they can’t be maintained and commonly accessed at a later date.

What Siemens has done is develop an architecture in which you can mix and match both. you can play with geometry to get it into shape, to ensure that the rough state of your model is how you want it. you can make changes very quickly indeed, by using inferred relationships, dynamic detection of ‘informal’ topology relationships – such as concentricity, parallelism, perpendicularity. this just enables to you edit the geometry and topology very quickly. But the trick is that when time comes to lock down feature size, dimensions, constraints, you can do is, just as you do already BUT, you can maintain them. Dimensions remain consistent, are stored and accessible, features are maintained, in respect to the dimensions, rules, constraints you provide.



They are applied after the geometry has been built – and this is key. you design, then you engineer. For me, the most interesting illustration i could find is the one shown here. its a model with parametric dimensions, but one that’s fully constrained – but the difference is that the ONLY dimensions, parameters and constraint you create, are the important ones – that, is the crux of the point and key to understanding what Siemens have developed.

Its a complex thought process to figure this out, with over 20 years of parametric, history-based modeling that the majority of us are familiar with and it’ll take time to settle and learn more.

NOTE: it’s been pointed out that I left Kubotek and its products out of these articles. Apologies to the guys over here.