8 Replies Latest reply on Sep 17, 2017 3:26 AM by Alex K.

    Leaning towards DriveWorks, but TactonWorks looks interesting

    Steve Martens

      I have pushed Design tables as far as I can, DriveworksXpress has given me a good start and a demo set for the decision makers.


      I have a quote for DirveWorks, I also have a history with the people there, good folks who are competant and quick with a smile.


      Is there any advantages with TactonWorks?  Both software packages demo well,but I only know companies with DriveWorks.

        • Re: Leaning towards DriveWorks, but TactonWorks looks interesting
          Tim Glavin



          I'm not sure what problem you're looking to solve, but if you've pushed design tables as far as you can, using any master modeling-based configurator may not take you much further.


          I agree that the folks at DriveWorks are good people. I like Glen Smith and Maria Sakar.


          The problem is with the approach. Like sculpture, in master modeling, every has to be in the model. You just get to remove or replace. Configurations can not be composed in SolidWorks, so any part with features or assembly with parts has to enumerate the powerset of every combination of problem dimension. Complexity grows exponentially.


          Every KBE addin to SolidWorks is a master modeling-based configurator except one; Genus Designer. You might want to at least look at it as alternate approach. Designer's configurator is generative (i.e. it has rules for adding and orienting features to parts and parts to assemblies) so complexity grows linearly rather than exponentially.


          In addition, it is an actual design system (configurators automate detailing, not design). If you have a "real" design problem, it may be the only way to go. It approach is fundamentally different from configurators, so it might be worth a look.




          - Tim

            • Re: Leaning towards DriveWorks, but TactonWorks looks interesting
              Steve Martens

              Hello Tim,


              Thanks for the mention of Genus Designer, I have looked at it in the past but categorized it in one not to pursue as it didn't seem to have a large following and it always concerns me if a software doesn't have sufficient revenue to continue.


              Your right "complexity grows exponentially", for our situation I can make either driveworks or tacton do well.  In Driveworks, one doesn't need to have a configuration for every option, the software creates a new part based on inputs.  The boundarys around the industry, and common practice in our industry have a natural limit we don't need to go past, with that in place all kinds of changes can happen.


              I don't plan on the software to be 100%, hopefully grow to 90% and model the rest.


              Unless I am not understanding your comments.



                • Re: Leaning towards DriveWorks, but TactonWorks looks interesting
                  Tim Glavin



                  I understand your concern about the apparent following.


                  The real question is what kind of tool does it take to solve your problem?


                  If the tool is wrong, it doesn't help if the tool has a large following.


                  We haven't talked about your problem, so the best I can do is speak in impossibly vague generalities.


                  If your problem is a configuration problem (as opposed to a design problem) and if the combinatorics aren't too bad, than any configurator will do. Go for what is comfortable.


                  If the problem is a configuration problem but the combinatorics are just nasty, then you'll want a generative configurator. A generative configurators has rules for adding and orienting features to parts and parts to assemblies, so complexity growth is linear. Genus Designer was recently used to automate piston (cars, motorcycles, ATVs, snowmobiles, jet skis, etc.) configuration. The problem involved exactly one part with numerous features. The piston manufacturer tried solving it using master modeling but hit the wall on complexity. They solved it easily using Genus Designer with minimal consulting (most of it involving how NOT to approach it as master modeling).


                  If you have a real design problem, then the only good answer is a design tool. Since most configurators claim to be doing design, this requires some explanation.


                  Configurators automate detailing, not design. They require a full and unambiguous specification (one set of inputs) and yield one design description. The effort saved automating detailing can be huge, but it is not design.


                  Design problems have more than one correct answer. The activity of design involves generating and sifting through alternatives to find the best design for a customer's problem. So design is optimization.


                  The result of design, whether manual or automated, is a set full design specifications. The best full specification can be input to a configurator to automate detailing.


                  Some configurator companies offer "what if" capability. "What-if" is "iteration by engineer". One configurator company call this "interactive automation", a contradiction so compact as to be elegant. Design automations is "automated automation". "What-if" produces exactly one design per iteration, gives an engineer no way to compare alternatives and gives you no way to tell how close any solution is to the boundary of what is possible. While "what-if" typically allows and engineer to try a dozen alternatives to to find "good enough", design automation might compare millions to find an optimal solution.


                  There are signs that you're beginning to use a configurator for a design problem. Here are just a few:


                  1. are you forced to partition the design space to insure unique answers when previously
                     you supported overlapping designs?
                  2. are you saying (or being told) that design is an 80-20 problem. and that you should
                     be trying for an 80% solution.
                  3. your interface requires input of many parameters of no interest to (and often, not understood)
                     by a non-technical user just insure a full specification.
                  4. you find that, although you targeted your design application for end-users, because of item 3
                     above, the application has to be run by an engineer.


                  The whole point is, choose you design tool to meet the needs of current and future projects, not by how many well-meaning people recommend it (many of whom have never used any of them and the rest who have only used a configurator).


                  If you have any doubts, do a small proof of concept on what you deem to be the "hard parts" of your design problem. Please contact me if I can be of any assistance.




                  - Tim

                    • Re: Leaning towards DriveWorks, but TactonWorks looks interesting
                      Steve Martens

                      Hello Tim,

                      I appreciate the time and effort you have invested into this post, and I think I am begining to see where you are coming from.  I am glad you made the distinction between configurations and design.  My goals are related to projects that are not design, they could be considered configurations but there is no way to determine the detailed requirements prior to a customer apoproaching us.  We know the parameters of what needs to be done, just not the length, thickness's, diameters and general layout and position of pieces.  Designing any thing new does not enter the picture, I have been designing products and machines for over twenty years and this isn't design.


                      I have been using configurations and family tables for almost all of those twenty years as I started with ProE in the mid nineties and switched to SW in 2001.  this goes beyond what those tools can do as well.  I had the good fortune of demo-ing and selling Driveworks for a time (over 5 years ago) and have been following the company and it's competitors since just in case I needed them.  Well that time has come and I am comparing Tacton (or any other) to ensure I am choosing the best tool.


                      I need a tool that can follow a flow chart of inputs that will then produce a set of models with corresponding drawings detailed as much as possible.


                      All the Best


                      • Re: Leaning towards DriveWorks, but TactonWorks looks interesting
                        Alex K.

                        Hi Tim,


                        I read you posts here and in the other related Thread. (Automated Parametric Design, Product Configurators )

                        And i kind of get your point but can´t completely follow you.


                        I agree on the majority of your points. But from my expieriences with Tacton and DriveWorks - it´s exactly what i´m doing there is: Kind of using the orientanional approach you described for generative configurators. Too avoid the issues you described.


                        One question for me is when you talk about automating the design process - you look for a powerfull solver technique which analyses various design variants and makes live easier for the designer? From a logical standpoint Tacton/DriveWorks i think is not the tool to do this but can at least reduce to all "possible" permutations in your defined solution space. (What is maybe exactly the thing you are not looking for?) 


                        So don´t get me wrong but in my opinion in a configurator you really don´t look for what you described as the weaknesses of a master model based configurator - i think if you want to automate/configure a product it´s really necessary to know your details and have a clear solution space, otherwise you run exactly into the problems you mentioned.


                        I haven´t really thought about solutions for automating design processes - and because of that maybe i´m completely wrong. But from a product configuration standpoint i think Driveworks or Tactonworks will fit the needs of most of us just fine. So i think what you described you are more about looking for automated ways for design validation - which i agree with you a generative approach seems promising - and starting from design phase you may even increase the benefits.

                          • Re: Leaning towards DriveWorks, but TactonWorks looks interesting
                            Tim Glavin



                            I apologize for being slow to answer. For some reason I was not notified of your post or I just got busy and missed it.


                            I'm not entirely sure what you're asking. Let me start by saying that configuration and design are two different problems. Design, starting with customer requirements (a partial specification) is exploratory (one-to-many). Configuration (detailing), starting with a complete and unambiguous specification, is one-to-one.


                            With respect to the design problem, it doesn't necessarily help to have a clear picture of your design space. The relationship between design variables (those are typically your inputs; the ones under your control) and performance variables (the ones you use to measure its quality) is usually complex. When it is, you can't know which inputs will give you an optimal, good enough, or any design; you have to explore the space and test the alternatives. "What if'ing" a few designs in a space of millions doesn't help much. (I'm not sure if this is what you're getting at).


                            If you don't have a design problem, then a configurator may be answer.


                            The discussion about configurators stands alone. It also doesn't as much depend on your understanding of your design alternatives as with characteristics of your problem that you don't have any control over.


                            If the number of variations In your product is very large, then your master model will likely be very large and fragile. If you are a master modeling rock star (some people are), then you can deal with this.


                            If your problem is open-ended and has n of some component(s) where n is often large and a pattern won't solve the problem, then your master model will at least start out large. ...maybe very large. You may be able to handle this, but it's part of your problem and it won't go away.


                            If you have product variations that contain differences in how components are oriented with respect to one another, this can be VERY difficult to deal with in a master model.


                            As an example; you are designing a heat exchanger that n circuits with m connections to input headers and m connections to output headers. The headers can be on the front or back. This problem has high variability, is open-ended and has a difficult mating scenario. We have solved this problem. We came in after a master model based product could not. I don't think we're any smarter than those guys (although if you've heard a rumor to the contrary, I probably started it). The master model approach just has some limitations.


                            No matter how well someone knows his problem, its characteristics are outside his control. The configurator can handle them or it can't no matter how smart the application builder. It's about the problem and about the approach to solving it, not the people.


                            Your problem may be solvable by a master model-based configurator. They are very popular so I can only assume that many people have had good results. The kind of problem you have and the approach that will lead to a successful application is something you want to know before you start an application.


                            Please let me know if this answers your question.




                            - Tim