Elting Mechanical Enterprises

A number of mechanical software developers have been working on new/old method of creating solid models that us not history based. Meaning that new features (holes, cuts, etc) are not part of a parent/child relationship. Now this is nothing new. For many years, we could create solid models in Autocad which had no dependant feature history. The real difference now is that we can create them using parametric sketches. This is an enormous improvement over past methods.

Why Explicit Modeling is Important

For years the only way to work with CAD files from different developers was to export the native file (i.e. Pro/E, SolidWorks, etc) to a neutral format like IGES or STEP. Once one has imported the file into your software, editing the solid can be a chore since most modeling software don't have the tools to deal with these "dumb" solids. This is where the explicit modelers really shine. The next few years will show these types of modellers to start gaining market share. Some of the larger software developers have seen the writing on the wall, namely PTC (Pro/e - CoCreate), Autodesk Inventor Fusion, and Seimens Synchronous Technology. So far, SolidWorks and Alibre Design have not expresses interest in developing explicit tools. I truely believe this is a mistake. For those of use that need to modify customer files for stress analysis, having tools to easily de-feature a model is a must.

The "Holy Grail" of CAD

Many have thought that CAD software developers would come together to accept a unifying file format that could be read by different CAD software. For years it was IGES and more recently STEP (STandard for the Exchange of Product model data) formats. Where different CAD software can import the geometry, their really isn't much in way of "intelligence" left in the part. Meaning that all the parametric data that developed the features of the solid are lost in translation. The "Holy Grail" was thought of if a version of say STEP could have the parametric feature data inside the code of the file, to be read by whatever CAD software and the geometry would then be read in as if it were a native file. The closest any of the CAD developers have come this has been with Alibre (www.alibre.com) submitting its STEP schema to the International Organization for Standardization (ISO) for review. That's great, for everyone else. Until all 3D CAD software exports using this schema, all the receiver will get is a dumb solid. Its been eight (8) years since Alibre submitted this to ISO so I don't expect much came from it.

In conclusion, as I see it the best alternative to the "Holy Grail" is having really good tools for "carving up" dumb solids. That means, Explicit modeling.

Finding the right solution can be difficult but, even worse if one is looking for it in the wrong place.

Often clients will tell me that they have a production problem and it is all because of our "widget" machine and they want me to have a look at and see what can be done to fix it. Once I've gotten to see the widget machine in action I ask, "so, tell me what's the problem? It appears to working fine. I see that its pumping out gadgets at a pretty good rate so, what gives?" The usual reply is something like, "its working fine now, but it breaks down all the time" or, "its doesn't produce the gadget to spec but, today its doing okay" or something to that effect. Sound familiar?

At this point, I start my "investigation". I round up the usual suspects (line operators, maintenance techs, engineers) and start in with the questions. It never fails to amaze me how no matter what kind of gadget a company produces, they all suffer from the same problem when it comes to solving production issues, perception is their reality. Facts don't lie but, people do. Or at least they lie to themselves and they believe their own lies and then the lies become the "truth".

So, how do we fix their production problem. First, we start with the end in mind. Meaning, what is the target throughput of there operation. How many gadgets need to be shipped. Working "backwards" through the operation, allows me to get down to what is truly important, finding the real bottlenecks in the processes. One of the best ways to find bottlenecks is looking at the data that has already been collected. Once its been correctly analyzed, patterns can be found that usually lead to causes in lost production. The trick to this is the "correctly analyzed" part of this investigation. People have a "funny" tendency to see what they want to see or they just don't think to look at the data in a way that can help them see the real issues.

Once a client sees that the widget machine is not the real problem and its actually the gizmo machine that is truly slowing the process down, its like an "ah ha" moment. Sometimes, it just takes a bit of courage to press the client and find the real truth.