{"id":20019,"date":"2018-04-26T10:00:21","date_gmt":"2018-04-26T14:00:21","guid":{"rendered":"https:\/\/blogs.solidworks.com\/tech\/?p=20019"},"modified":"2018-04-26T09:52:00","modified_gmt":"2018-04-26T13:52:00","slug":"how-to-simplify-maintenance-of-design-automation-projects-by-using-constraints","status":"publish","type":"post","link":"https:\/\/blogs.solidworks.com\/tech\/2018\/04\/how-to-simplify-maintenance-of-design-automation-projects-by-using-constraints.html","title":{"rendered":"How to simplify Maintenance of Design Automation projects by using constraints"},"content":{"rendered":"

By Oliver Dover, Business Consultant, Tacton Systems \u00a0<\/em><\/p>\n

A Design Automation project lifecycle is longer than you would think. You might consider the work done when it is set into production, but I would argue otherwise. Rather, a Design Automation project is a living thing which will be updated with new product data and variants during its lifetime. And as it gets older and more experienced, the project needs to be maintained to stay efficient.<\/p>\n

But here\u2019s the tricky part: the more data you have, the harder its maintenance will be. A common problem is that when a new variant of a part or subassembly is added, logic needs to be changed in order to define how this new variant will fit into the Design Automation system. Old rules need to be edited and new rules might need to be created.<\/p>\n

So, is there a way to simplify this? Yes, there is. In this blog post, I\u2019ll show you how you can separate your data from logic, as well as update your product data without having to change your logic, by using a constraint based design automation approach.<\/p>\n

Let\u2019s have a look at a simplified example of a conveyor model (picture 1). More specifically, we will concentrate on the Beams and the Rollers (picture 2).<\/p>\n

\"\"Picture 1<\/em><\/p>\n

 <\/p>\n

\"\"<\/p>\n

Picture 2<\/em><\/p>\n

\u00a0<\/em><\/p>\n

In our example, there are three variants of beams, and three variants of rollers. The ways in which these can be combined are shown in the matrix below:<\/p>\n\n\n\n\n\n\n
<\/td>\nBeamA<\/strong><\/td>\nBeamB<\/strong><\/td>\nBeamC<\/strong><\/td>\n<\/tr>\n
RollerA<\/strong><\/td>\nAllowed<\/td>\nNot Allowed<\/td>\nNot Allowed<\/td>\n<\/tr>\n
RollerB<\/strong><\/td>\nAllowed<\/td>\nAllowed<\/td>\nNot Allowed<\/td>\n<\/tr>\n
RollerC<\/strong><\/td>\nAllowed<\/td>\nAllowed<\/td>\nAllowed<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

 <\/p>\n

I will first describe how you would go about a configuration using a sequential approach. Then, I\u2019ll show how to handle the same configuration using constraints and the benefits of using this approach.<\/p>\n

Sequential approach<\/strong><\/p>\n

The sequential way to set this up is to have three rules stating that if<\/strong> a certain Beam is chosen, some Roller is allowed. See an example of a rule set which would achieve this bellow:<\/p>\n

If Beam A then RollerA or RollerB or RollerC<\/em><\/p>\n

If Beam B then RollerB or RollerC<\/em><\/p>\n

If beam C Then RollerC<\/em><\/p>\n

Let\u2019s imagine that we now need to add a new roller, \u201cRollerD\u201d. This roller should work for BeamA and BeamB. To ensure a correct set-up, we would need to change two of the rules we created earlier to take this new roller variant into account.<\/p>\n

If Beam A then RollerA or RollerB or RollerC or RollerD<\/em><\/p>\n

If Beam B then RollerB or RollerC or RollerD<\/em><\/p>\n

If beam C Then RollerC<\/em><\/p>\n

Constraints based approach<\/strong><\/p>\n

With a constraint based tool, rules refer to properties<\/em> of the variants rather than the variant values or the variants themselves.\u00a0 This enables us to create a rule saying why<\/em> the Rollers and Beams fit together, rather than in what combination.<\/p>\n

In our example, the reason for the allowed combinations of rollers and beams is that the Roller Diameter cannot be larger than the Beam height.<\/p>\n

We begin by creating a table for rollers and beams A-C, with the necessary properties.<\/p>\n\n\n\n\n\n\n
<\/td>\nRollerDiameter (mm)<\/td>\n<\/tr>\n
RollerA<\/td>\n10<\/td>\n<\/tr>\n
RollerB<\/td>\n20<\/td>\n<\/tr>\n
RollerC<\/td>\n30<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\n\n\n\n\n\n
<\/td>\nRollerHeight (mm)<\/td>\n<\/tr>\n
BeamA<\/td>\n35<\/td>\n<\/tr>\n
BeamB<\/td>\n25<\/td>\n<\/tr>\n
BeamC<\/td>\n15<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

 <\/p>\n

Now, we need only one<\/strong> rule to describe how these can be combined. In this rule, we will only include logic which refers to the properties, rather than specific values or variants, since our aim is to separate the data from logic.<\/p>\n

RollerDiameter<RollerHeight<\/em><\/p>\n

The result will be the same as with the previous rules. The difference is that this rule is compact yet easily understood. We have been able to replace the 3 rules, shown in the sequential approach example, with just one. If we now want to add a new Roller, we simply add a new row in our Roller Table and no change in rules is necessary.<\/p>\n\n\n\n\n\n\n\n
<\/td>\nRollerDiameter (mm)<\/td>\n<\/tr>\n
RollerA<\/td>\n10<\/td>\n<\/tr>\n
RollerB<\/td>\n20<\/td>\n<\/tr>\n
RollerC<\/td>\n30<\/td>\n<\/tr>\n
RollerD<\/td>\n22<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

 <\/p>\n

To summarize <\/strong><\/p>\n

In real Design Automation projects, the dependencies between components are generally complex with a lot of dependencies between different components. This increases the importance to separate the data from logic, as we have done with this one very simple example. By using the constraints based approach, you can easily separate your logic from data, inevitably simplifying maintenance. Working with constraints means you get a lot fewer rules, as well as an easier way to update your product data without having to go through your logic and find all the rules which need to be edited.<\/p>\n

 <\/p>\n

If you want to learn more about Tacton Design Automation, do so here<\/strong><\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"

By Oliver Dover, Business Consultant, Tacton Systems \u00a0 A Design Automation project lifecycle is longer than you would think. You might consider the work done when it is set into production, but I would argue otherwise. Rather, a Design Automation<\/p>\n... Continued<\/a>","protected":false},"author":423,"featured_media":20021,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[11,21],"tags":[487,2390],"class_list":["post-20019","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-design","category-solidworks","tag-automation","tag-constraints"],"acf":[],"_links":{"self":[{"href":"https:\/\/blogs.solidworks.com\/tech\/wp-json\/wp\/v2\/posts\/20019","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.solidworks.com\/tech\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.solidworks.com\/tech\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.solidworks.com\/tech\/wp-json\/wp\/v2\/users\/423"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.solidworks.com\/tech\/wp-json\/wp\/v2\/comments?post=20019"}],"version-history":[{"count":3,"href":"https:\/\/blogs.solidworks.com\/tech\/wp-json\/wp\/v2\/posts\/20019\/revisions"}],"predecessor-version":[{"id":20024,"href":"https:\/\/blogs.solidworks.com\/tech\/wp-json\/wp\/v2\/posts\/20019\/revisions\/20024"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blogs.solidworks.com\/tech\/wp-json\/wp\/v2\/media\/20021"}],"wp:attachment":[{"href":"https:\/\/blogs.solidworks.com\/tech\/wp-json\/wp\/v2\/media?parent=20019"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.solidworks.com\/tech\/wp-json\/wp\/v2\/categories?post=20019"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.solidworks.com\/tech\/wp-json\/wp\/v2\/tags?post=20019"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}