Featured Applications


I have created the "Featured Applications" section of my site to hopefully provide some incites, training modules for beginners and other materials that I hope you might find useful.
If you have an article you would like to contribute, training materials or other resources you would like to contribute to my site please feel free to contact me at info@deltades.com

Articles:

Origin Axis Methodology An Argument for consistency in modeling practices

posted Apr 3, 2014, 6:48 PM by Rick Smith   [ updated Apr 8, 2014, 11:07 AM ]

In a recent discussion thread on Linked In:
Jay Williams of Genesys Systems Integration asks:

"Does anyone use standardized practices for how and when to use certain features of their Inventor modeling package?
i.e. constraining, shrink-wrapping, adaptivity etc.
Our goal is to create stable, easy-to-edit models used for fabrication and layout drawings. The parts lists on these drawings are expected to have descriptions and quantities that are dynamically linked and not manually overwritten. 
We have discovered tools available in the software might do a fast job for it’s designed use but does not always lend itself to editable fabrication drawings without “work-arounds”. Here’s a scenario involving (Inventor) Frame Generator that yielded an unstable, difficult to edit model.
An advanced user created a very complex 3D sketch driven frame. Years later, this frame needed to be edited by a moderate level user. (assume the originator of the model is no longer around) A lot of time was wasted trying to decipher how this frame was constructed. If there had been some guidelines in place on how to use this particular feature or the extent of complexity to which this tool could be used, it would have saved a lot of time. 
We have continuous training and standardization sessions and have definitely improved as a group. Real world is you’re always going to have varying skill levels amongst users through attrition. We are taking the approach of keeping our models as simple as possible through regulating the use of some features in the software. Surely this is not unique to just us. Wanting to hear how others have addressed issues like this.
A little history on how we do business: We have a 30+ user base. We are design-build company without product lines. During the design process models get handed off to other engineers for drawing creation and changes."

While the discussion largely centered around his example of the frame generator and prompted his follow up question:

"Thanks everyone for the input! The frame generator scenario from above was just a case in point where some guidelines for the use of that Inventor feature would have been helpful. I'll ask the question from another angle. Does every one have full reign to create models any way they see fit or are they subject to departmental guidelines or restrictions of any sort? If so, would like to hear what some of the guidelines/policies are."

I believe that what follows is at least in part more focused on an answer to his question and the techniques that may be employed to achieve a solution. See the original discussion thread here.

In 2006 while working for Northrup Grumman and explaining to the team my modeling approach I coined the term for an Origin Axis Methodology and wrote this paper to help explain it in detail. The paper is largely finished but I need to create some better examples and revise it based on the results so It continues to be a work in progress but the opening argument is posted below.  

A Problem:

Those in the field of mechanical design and engineering who are specialized in the use of CAD or Computer Aided Design and Engineering tools such as Autodesk Inventor, SolidWorks, Creo Parametric and others are all familiar with what is probably the first most common phrase through out the industry. "There are a million ways to model a part." 
The problem is that some of them can make the second most common phrase through out the industry "Think of the next guy because there will always be a next guy." And the job of editing the part in question so difficult that it becomes far easier and even necessary for the "the next guy" who has the job of making the inevitable changes to the design as a result of the revision process that occurs in course of product life cycle to start over, wasting valuable time and requiring the associated drawings to be revisited as a result of numerous factors involving part stability or even file association.
This begs the question: Can a company, community, or even the industry as a whole establish a common methodology in which consistency in modeling practices be achieved? 
If so how, what could be used as a common point of reference that all of an organizations designers and engineers could agree on? 
How would consistency in modeling practices be encouraged, enforced or even applied? And this would be just the start of it.

As defined, this is a problem of methodology where in the interpretation of how to go about modeling a part to meet design specifications outlined as a result of factors such as research of commercial parts to be used in the designs, custom form, fit and function requirements, weight, cost of production and more will all play in to the approach an individual might see as best in the process of modeling the part(s), subsequent sub-assemblies and assemblies even the materials and bill of materials may have an impact on how an individual goes about creating the models to be used and later documented in the detailing and drafting processes.
Indeed, modeling methodologies and decisions on how to model something as simple as a box with a hinged lid by six different people will result in six different solutions. 
In fact, even having the same person model something two or three separate times whether given sufficient time to forget how he/she might have done it the first time or not will inevitably result in several different solutions. Sometime as a result of having studied the problem and deciding it would be better this way than that or just as a result of finding other options.
Does this mean that we want to impose on everyone a means where by everyone models a given part the same way time and again? 
No, of course not it is not only impractical but impossible to expect an individual or group of individuals to model or approach a given problem identically. Nor can we expect or want a cad product to impose on the designer stringent rules reducing flexibility and effectiveness of the product. 
However, might it not be possible to employ a set of common ideas, rules, and methods such that an individual or design team might design a part the same way twice or even utilize common ideas to work together to create a consistency in there modeling practices such that if they understand the rules and what to look for, one person in the group can pick up the work of another in the same group or even that of someone outside that group who is familiar with the rules and have a reasonable expectation of knowing how this person likes to model things based on that common set of rules? 
For starters, there are common "features" with in an empty part and assembly file template. Further, there are common associations with in the file and more. 
This article hopes to demonstrate how these commonly overlooked features found in the initial template files of a CAD system can be leveraged to create consistency in modeling practices, employ common techniques and more so that the "next guy" who picks up a model that you worked on several years ago can, if he is paying attention and is good at his job, begin to notice that your designs have commonality in the file(s) where in the next one and the next after that have a consistent modeling methodology and have as a result made it easier and quicker to make the required edits to your work and fix the drawing package efficiently without making a mess of it and/or causing more pain than is already the case after revision G, H, J... etc. thus taking more of an engineering approach to the modeling process, after all isn't that the objective to "engineer" a solution? Create designs that are easily controlled, edited and detailed such that the model is stable, has few if any failures in the course of the product life cycle and the design changes made to it are fast, efficient, stable and update the drawings and documentation quickly and efficiently?  

As discussed previously, methodologies are inherently subjective to the common practices of the individual and as a result are quite likely never the same twice let alone between the work of two or more designers. 
A possible solution exists in the common practices employed by most if not all designers, even those who may employ part if not all of the methods described herein are still "feature based" that is a "feature" of a part is defined by the sketch and then extruded, revolved or used in surfacing in some fashion or other followed by another feature and another each built upon and dependent upon the previous feature.
However, common practices are often employed by the designer just because he/she found that this technique worked for them and is often used such as slots and hole patterns that use a line defined by the previous feature for direction. 
The immediate problem for this particular feature as defined is what if the previous feature containing the line on which the direction of the pattern changes or fails due to other unrelated geometry or any number of design changes especially in that of sheet metal applications and more.
Feature based methodology has been well established by the industry and is in fact the only way to date of creating cad models as we understand them today even with the advent of "direct modeling" in Autodesk Inventor or "synchronous modeling" in Solid Edge however, this kind of methodology has numerous weaknesses starting with the fact that it is completely open to how this person goes about modeling practices as opposed to that person. 
A completely subjective process which holds no consist processes even when the designer might rebuild a part or assembly which they have done before. 
So what do we do?
Let's start by establishing some ground rules and definitions.

Continued...
Contact Rick Smith @ rick.smith@deltades.com for the full White Paper on OAM.

Copyright October 2006


The Challanges of Scale-able Configurator Systems

posted Mar 5, 2014, 5:41 PM by Rick Smith   [ updated May 5, 2014, 8:02 PM ]

I have often been asked "What is a Scale-able Configurator?" and "Why would you want to do that?"

A "Scale-able Configurator" system employs everything from programming both in visual basic and in the case of Inventor, I-Logic utilizing things like case and if statements, to digital prototyping, extensive mathematics, and require associative parameters between every part and assembly scaling the designs up and down depending on a key parameter or set of parameter to achieve the objective. The configurator part of the solution swaps out parts and assemblies via programming usually from reusable libraries of both COTS (Commercial Off The Shelf) and custom materials based on factors such as operational requirements or environmental conditions.
First, it should be noted that a configurator is not appropriate for just any application. 
While notoriously difficult, involved and complex because this kind of project is all encompassing, associating every piece part, every sub-assembly, every assembly, every drawing and more, it will culminate in the drafting and detailing of each part, assembly, parts list, bill of material etc... the project delivers a unique solution and complete drawing or technical data package from the same set of files time and time again like a factory saving time, money and man power over the long term thus making it a worth while investment.

Yes, library parts and assemblies can be created for a unique solution and used to copy and reuse enabling some time savings where in the meta data provided for a project is entered and re-entered to every part and assembly detailing project specific information, revising unique part numbers specific to that project, and finally editing dimensions to adjust sizes and parts are then swapped out in the assemblies to achieve the completed designs, however each part and assembly may still need to be detailed again creating a new TDP (Technical Data Package) each time or you might even have associated drawing files to the library parts and assemblies but only through many days, even weeks of rework can the TDP be delivered and then it still has to be reviewed and revised for error correction. 

The scale-able configurator however, provides a consistent TDP that may need some massage just to clean up dimensions alignment or move a leader note to a position where it is not over lapping some other notes or something to that effect but the captured design intent and approved drawing package already exists and does not need to be revised and re-checked for each project. Once the package has been approved the system becomes a "factory" turning out consistent, correct and unique TDP's where in as with any mistakes, edits or omissions and unlike the "copied library" approach, the data entered cascades through out the project with complete parts lists, bill of materials and unique part numbering delivered for each and every project time and again.
Employing top down methodology, two dimensional cross sections of the envisioned machine such as an elevator are developed. Known as the "skeleton sketch" a single assembly or part file contains multiple sketches which are created in layers and associated by parameters. 
One sketch defines key boundaries of a key element like an elevator shaft for instance, the next defining the platform on which the elevator will ride etc... 
Depending on the application, a part file can be used, however, an assembly file may provide maximum flexibility in the development of this "Root" file if it becomes necessary to reference or position parts relative to key aspects of the skeleton, however, you have to be careful not to create circular references.

The difficult and time consuming part of the process comes when mistakes, omissions and edits are made to the skeleton sketches as the results cascade through out the entire project which can be... well traumatic, maybe even catastrophic which is the reason why such projects are not to be undertaken lightly.
Project planning is key to the development of any application for which a configurator is to be developed with a clear understanding of the projects scope, schedule and resources outlined in a requirements document to provide a clear picture of the project objectives prior to beginning any work the results of which must be thoroughly reviewed at key mile stones where in the resultant drawing package must be signed off on at each stage of implementation to reduce error and ensure successful implementation.
A Scale-able Configurator is an up front investment in time, money, and resources which should be considered in the long view of a company's overall engineering and manufacturing strategy. 

Simply put the "Scale-able Configurator is the apex of what a cad system such as Inventor, Solid Works, Pro-E etc... is capable of achieving. 
In the hands of a competent professional the results speak for them selves and I relish the challenges of this kind of work. 
Such systems once completed are capable of delivering the completed technical data package for a complex machine system such as an electric motor or an elevator lift within a matter of hours rather than days, weeks or even months saving time, money and reducing man hours over the long term. 
Depending on the implementation process, such systems can typically start to deliver a return on investment with in 3 to 5 months and begin delivering the full return on the investment within one year as apposed to time, money and man hours spent on the design and re-design of the same machine under a different project name and basically re-inventing the wheel.

In operation, a form is used to enter relevant project data such as title, project name, maybe a project number etc.. as well as appropriate dimensional information pertaining to the overall sizes for dimension variables A, B, C... which in turn are used in mathematical and associative equations along with components selections for operational characteristics unique to that project. Once processed the associated drawing package changes according to unique project specifications for "Project A"... B... C etc... providing the a for mentioned and required BOM and parts lists. The system is then reset and ready to do it again.
This enables a single individual to produce the complete TDP for a project within several hours again, reducing design cycle time and saving time, money and reducing resource requirements.
Documentation is critical, these systems become highly integrated and in addition to the requirements document it is extremely important to document  a "users manual" as well as such factors as key relationships, programming, the numbering system and how it is applied, where and how meta data such as project, title, and description are captured and applied.
 
The first question from management is "How long is this going to take?"
The real answer is as long as it takes... the tap dancing answer is... "Well, it will depend on the scope of the project, ensuring the identification and construction of the all encompassing sketches ensuring from the beginning that no omissions are made, defining how the nested sketches should be related and in what order, the associations between them and the difficulties encountered as they are defined, as well as the needs of any libraries that will be built to support the project for COTS parts and "standard" custom parts, programming, and numerous other factors and unknowns including but not limited too implementing lessons learned along the way that WILL result in re-work of the skeleton sketches which, because of the associative nature of this kind of project will damage and may even require reconstruction of associated parts or may even result in the realization that the complexities of what has been done so far can, should or even must be simplified and result in re-construction of the entire project. 
While this is somewhat time consuming and sounds drastic it is actually much easier to do the second time around because you have identified all the variables, outlined the requirements and more such that while the initial work may have taken several months to research and develop, reconstruction may be achieved in a matter of weeks resulting in significant improvements that are well worth the effort.
So as a result, rather than setting an arbitrary completion date, it is better to break the project up into phases with mile stones, and phased implementation so as to provide a return on investment as the project progresses, making weekly progress reports, extensive testing and most importantly, holding formal review meetings of the drawing packages and sign off on the completion of the phases prior to implementation so that parts don't come back wrong again and again."
Management starts to get a picture of the effort after that but nothing you say can really give them something they can point to and say we will be done by... Which is understandably uncomfortable and why the requirements document is important.

I have now built five configurators for various applications through out my career including an electric motor, a battery pack, a window and door system, one that defined the combinations and permutations of the various chemicals used in a product and an elevator system.  
The electric motor changed size and parts based on amperage, the battery pack based on the amperage, length and diameter of the battery selected, the windows and doors based on ballistic characteristics required and rough in dimensions.
The chemistry configurator was much more difficult, while the results of this did deliver a drawing package, the objective of the project was to deliver a bill of materials for purchasing.
Including containers and packaging the system defined 98 permutations and 457,163,239,672,252 possible combinations resulting in a discrete 983 line Bill of Material for the project. The system was achieved via the use of table driven I-parts and I-assemblies, programming and component swaps. A sphere represented the chemical compounds in the model but the part number, title and description provided the BOM for purchasing. The system was so complex I had to write a report on it.
The most recent application was for an elevator where in it is the same machine being built over and over with a change in sizes and parts used based on operational conditions such as seismic activity in the region.   

Autodesk, Desult Systems, PTC and others all know that these kinds of results can be achieved using there software and rightfully use that as a selling point talking about how there system can be used to create a "scale-able Configurator" for that project (what ever that maybe) quickly and easily making it sound like doing so is not only simple but the results are like magic! 
However, once the sales pitch is over, I have found that customers of these products while excited by the prospects of what these kind of systems can achieve are largely left with "Our product can do that" but no real understanding of what it takes to do it thus setting very unrealistic expectations by management of those like myself who are capable of constructing such a system but know the realities of what such a project entails. 
Which is why I chose this subject as my first Featured Applications article.  
I hope you have found it helpful and informative. If you have any questions please feel free to write me at info@deltades.com
Copyright March 2014

1-2 of 2