Making Software Get Along: Integrating Optical and Mechanical Design Programs

As modern optomechanical engineers, we have the good fortune of having very sophisticated software programs available to us. The current optical design, mechanical design, industrial design, and CAM programs are very powerful tools with some very desirable features. However, no one program can do everything necessary to complete an entire optomechanical system design. Each program has a unique set of features and benefits, and typically two or more will be used during the product development process. At a minimum, an optical design program and a mechanical CAD package will be employed. As we strive for efficient, cost-effective, and rapid progress in our development projects, we must use these programs to their full advantage, while keeping redundant tasks to a minimum. Together, these programs offer the promise of a "seamless" flow of data from concept all the way to the download of part designs directly to the machine shop for fabrication. In reality, transferring data from one software package to the next is often frustrating. Overcoming these problems takes some know-how, a bit of creativity, and a lot of persistence. This paper describes a complex optomechanical development effort in which a variety of software tools were used from the concept stage to prototyping. It will describe what software was used for each major design task, how we learned to use them together to best advantage, and how we overcame the frustrations of software that didn't get along.

Keywords: optomechanical design, optical design software, software integration, data exchange, data file translation, computer aided design, computer aided machining, solid modeling, surface modeling, optical modeling

Optical and mechanical design software programs have come of age with the microprocessor. Engineers now have a staggering array of design tools available to them, from simple raytracing programs to powerful 3D solid modeling packages. Computer-aided design (CAD) and computer-aided engineering (CAE) software has become very powerful and is available to perform a variety of highly specialized tasks such as non-sequential raytracing of optical systems or mold flow analysis for molded components. For even the simplest of optomechanical design projects, at least two of these programs would be used - one for the optical component design and one for the design of mechanical mounting hardware. Complex optomechanical design efforts would benefit from several additional types of software for design and analysis of the complete system. Ideally, the design data would flow smoothly from one software package to the next. The reality is that there is a confusing muddle of software to choose from with a witch's brew of file formats to deal with. In addition to exchanging data between mechanical CAD programs, optical engineers must also deal with data exchange between optical and mechanical programs. This paper describes the function of the major CAE software categories available to the optomechanical design team, the role of each type of program, and what happens when the designers try to exchange data between them. We describe our experience with data exchange on a large optomechanical design project, and how we managed to make our software get along.

A few examples of programs in each software category will be presented along with their role in a typical optomechanical design effort. Individual software packages are listed for informational purposes only, and inclusion in this paper does imply that we endorse any particular program.

For the purposes of this paper, programs that are used primarily for lens design and offer robust optimization of optical parameters will be classified as "optical design" software. These include popular lens design programs such as Code V® and ZEMAX™. Programs that primarily perform optical analysis of an optical system with limited or no optimization capability are classified as "optical analysis" programs. These programs analyze the illumination properties of an optical element by tracing a large number of rays through the system. These include programs such as ASAP and LightToolsTM.

Optical design software is used primarily to model and optimize a lens design. The starting design can be input manually by the user, or a sample lens included with the program can be loaded, or lens file from a database program (usually a separate software package) can be imported as a starting point for the design. Powerful optimization tools are used to modify the initial design until the specifications for the lens are met and no further improvement is possible within the constraints of the system. For many development efforts, the lens design is performed first, with mechanical design following. Optical design data can be exported from most leading programs directly into the mechanical design software using DXF or IGES file formats (file formats are defined in Table 6). Prescription data is available for export in text format. Graphical data can also be transferred to other programs as a "windows metafile", a JPEG image, a bitmap image, or copied and pasted via the Windows "clipboard". These formats are best suited for importing graphics into reports or presentations, and are not very useful as mechanical design inputs. Table 1 lists some commonly used programs.

For complex or specialized optical analyses, a lens design program can fall short. Although optical design programs have recently begun to incorporate complex optical analysis functions such as non-sequential ray tracing, a more rigorous illumination analysis of an optical system is best accomplished using specialized software capable of tracing very large numbers of rays. Typical applications for such software include radiometric analysis and illumination design. These programs are designed to receive CAD input so that complex non-imaging optical elements can be analyzed after being designed in a mechanical CAD package. Automotive light pipes and tail light reflectors are typical applications for such a design flow. The analysis programs also accept lens designs from one or more optical design software programs. These can be modeled along with CAD-generated mounting hardware and simulated light sources to predict their "real world" performance with respect to illumination uniformity and stray light, for example. Some of the available optical analysis programs are listed in Table 2, along with their import file formats.

Mechanical design CAD programs are tools that are used to create and modify the design of mechanical parts and systems. Also available are specialized programs that import CAD data for mechanical analysis, including motion, thermal effects, stress, or molding. The design packages fall into a few basic categories. Two-dimensional programs are used primarily for drafting purposes. Three-dimensional CAD programs produce wireframe models, surface models, or 3D solids. Some software packages focus on one of these methods of modeling 3D objects, while others offer multiple 3D modeling capabilities. For data exchange, most of the mechanical design and analysis programs support one or more of the widely used file exchange formats, such as IGES or STEP. Each program usually supports several other import/export file formats.

Wireframe models represent 3D objects by defining them as a series of points and edges. Many optical design programs feature 3D wireframe modeling capability. Table 3 lists a few examples of mechanical CAD programs that perform wireframe modeling.

Surface modelers employ the points and edges of a wireframe, but also incorporate connecting surfaces between the edges. The surfaces represent the "skins" of the modeled objects. These skins can be shaped by pulling and stretching to create unusual forms. These types of programs are frequently used to quickly develop concept models to demonstrate design and styling options for a product. They can be great demonstration tools for presenting new product concepts, and are often the basis for making a mock-up model using rapid prototyping techniques such as stereolithography. Some examples of 3D surface modeling software are summarized in Table 4.

There are two different methods of representing 3D solids. One is called constructive solid geometry (CSG), where the 3D solid models are typically formed by performing actions on simple shapes, much as the real part would be fabricated by machining. These actions include extruding, revolving and cutting a basic shape. The second method is called boundary representation (B-rep), where the data is described by bounding surfaces that incorporate topological information. Three-dimensional programs maintain parametric relationships between objects. This can be very useful for examining part fit during the design phase, before any parts are fabricated. Pro/ENGINEER became an early standard for 3D solid modeling software, but it now shares that market with several other programs. Table 5 lists a few of the software packages that offer 3D solid modeling.

Mechanical analysis programs are used in conjunction with mechanical design software to check the performance of a proposed design. Finite element analysis (FEA) programs predict the effects of stress on a part. Programs for FEA such as Algor perform accurate stress analysis on complicated shapes. A library of software modules can analyze linear and nonlinear stress, vibration and natural frequencies, heat transfer, electrostatics, fluid flow, piping design, and composite materials. Algor also offers CAD interfacing, design, and meshing tools. A second example is DesignWorks (CADSI) -- a program that will perform stress, displacement, thermal, convection and natural frequency studies directly inside CAD environments such as SolidWorks. Performing analysis within the design program environment offers several advantages. One obvious plus is that the CAD data does not require translation into the file format of the FEA program! Another advantage is that changes can be made and tested on the fly. The availability of a built-in analysis function encourages earlier analysis and can save the designer from traveling too far down a poor design path. Many of the top solid modeling design packages include analysis capability, or offer it as an option.

Another form of mechanical analysis is motion analysis. These programs simulate the assembled design and animate it, predicting its performance as used. Stress, vibration, durability, thermal performance and more can be analyzed, and the design may be adjusted if it fails to meet requirements. Design Works/Motion (CADSI) and Pro/MECHANICA (Parametric Technology Corp.) are two examples of motion analysis software. They work within SolidWorks and Pro/ENGINEER respectively.

For molded parts, CAE tools are used to predict performance of plastic injection molded parts by analyzing fill, cooling, packing, shrinkage, warpage, and residual stress. The part design and tooling can be optimized early in the design stage to insure manufacturability. Examples of this software category include Part Advisor and Dynamic Series (both by Moldflow Corp.) and C-Mold (C-Mold).

Electronic design can be performed in software such as OrCAD. OrCAD is an electronics design software system with modules covering the entire electronics development process, from component selection to printed circuit board design.

Computer aided machining (CAM) is in wide use for rapid prototyping and CNC machining. Designs can be transferred to the fabrication machine directly, skipping the manual programming step, reducing the possibility of error, and speeding up production. IGES files are usually used for this. For rapid prototyping, most CAD programs will export STL or STC file formats for direct input into the stereolithography apparatus (SLA) to produce the prototype part.

In an optomechanical development project, data flows in convoluted paths. In order to streamline the design process, it is critical to insure that data is exchanged efficiently and accurately between software packages. Figure 1 illustrates the complex data pathways that are involved in optomechanical design.

Optical information can be transferred to a specialized, non-sequential raytracing (NSR) program for detailed illumination analysis. These results (or new data, if the NSR program allows changes or optimization) may flow back into the lens design program, or could be directed to the mechanical design program. Optical design data may be sent to the mechanical design program, or may be routed to the FEA program for analysis. Mechanical design information may flow to either the lens design program or the NSR program. In some cases, both optical and mechanical design data are sent to the NSR program for analysis. Mechanical design information may be sent to an FEA or moldflow package for detailed analysis. Results may be used to modify the mechanical design. Electronic design data flows to the mechanical design program. When the design is complete (or if an interim prototype is required), the mechanical design data is directed to the CAM software, which may involve CNC machining or rapid prototyping.

Failure to take advantage of smooth, electronic data transfer can result in a lot of redundant work and wasted hours. Repeated manual input increases the chances that an error will occur. Since design data is exchanged multiple times, manual entry would result in a needlessly expensive project. Unfortunately, it is not always easy or straightforward to exchange design data between the various software packages that are in use.

Potential pathways for design data flow between software packages.

Figure 1: Potential pathways for design data flow between software packages. The dotted line arrows represent paths where analysis data is used as a basis for design change, but the analysis program does not modify the design data directly.

The key problem with software data exchange is incompatible file formats. Even with built-in translators and "standard" file formats, errors can and do occur. It is very difficult to write a foolproof translation program to convert one file format to another. Consider the problems that occur with language translation. Sentence structure and syntax vary widely between languages. Some concepts and phrases easily expressed in one language may not exist in others. Fine detail can be lost. To illustrate this, a sentence was composed in English. It was translated by an Internet translation service from English to French, from French to German, and finally from German back to English. The results are listed below.

The errors in the grammatical structure of the translated sentence make it difficult to understand, but it is clear that the original meaning has been lost. Although CAD data is more mathematically structured than language and should be easier to translate, a computer program that translates CAD data can have similar difficulties.

Figure 2: Error message generated during a translation of an IGES file into SolidWorks.

In some cases, the translated file incompatibility with the receiving software is so pronounced that no data is exchanged. In other cases, the exchange is partial with missing information or errors (see Figure 2). Some solids arrive as single, featureless entities. These are "dead-end" files that cannot be modified, and many CAD operations cannot be performed on such compromised data. Another potential problem that may occur during data exchange is the loss of parametric information that was present in the original file. Other problems with translated data include connected entities that no longer touch or that cross over each other, curves that end up as a series of lines, repeated data, formerly closed surfaces becoming open at one or more points, incomplete data, loss of layer information, and features that are no longer to scale.

Other impediments to CAD data exchange include underlying differences in the way each program represents and structures the CAD data, lack of agreement on standards, differing interpretation of standards, proprietary solutions, and differences in system architectures. In order for a translation to be successful, the sending CAD system and the receiving CAD system must be able to handle the same types of entities. If one program uses custom or proprietary entity types, the data generated may be difficult to translate. The foreign entities must be dissected into a collection of common entities. If, for example, a program that understands only line entities is receiving a curve from a source program, that curve must be sectioned into small line segments that closely approximate the original curve. Inevitably, some information will be lost during this process. The translated entity is fundamentally different than the original, even though it may look the same on-screen. In a real-world translation, these small differences may be acceptable, or they may stack up to produce significant errors.

Standard file formats attempt to address this problem by providing a common exchange language. Sounds nice, but proprietary data must still be translated into the standard format by a translation algorithm. The translation is only as good as the algorithm, and some entities will end up as approximations if the standard format does not include the original entity type. As mechanical design programs become more sophisticated, it is more difficult for standard formats to keep up with new entity types. Another problem is that each software maker tends to support only the parts of the standard file formats that support their data types. In some standards such as IGES, a given entity can be created in more then one way. Some software developers do not support all of the methods for creating the given entity, but still claim to be IGES complaint. This is a common complaint about the IGES standard. An ambiguous or poorly written standard can result in misinterpretation. Use of a standard also requires two translations rather then one. The design data from the source program is translated in the neutral format of the standard, and then translated into the format for the receiving program. As evidenced by the language example, multiple translations are sure to cause some loss of meaningful data.

There are two types of standard formats for data exchange. Some examples of each type are listed in the table below. The first consists of national or international standards (such as IGES, VDA-FS, or STEP), and the second includes proprietary file formats that become commonly used as standards due to the market dominance of a particular CAD package. An example of the second type is AutoCAD's popular DXF format. AutoCAD was the market leader for 2D design and drafting for many years. The DXF format became a de-facto standard because of its wide usage. DXF files have limited translatability, however. When exchanging data in DXF format, dimensions can fly off into outer space, fonts can be lost, and colors may be changed. Another drawback is that DXF files tend to be significantly larger than the original CAD files, making digital transmission more time consuming.

The latest international attempt at a CAD design standard is the ISO 10303 Industrial automation systems - Product data representation and exchange. Commonly known as STEP (the STandard for the Exchange of Product Model Data), this standard was created to replace the various national, international and de-facto standards with a single format that provided for the most efficient and accurate exchange of CAD/CAM data. Another goal was to address the need for data exchange throughout the life of a product. In many cases, the useful lifetime of a product greatly exceeds the average lifetime of the CAD program or version that was used to produce it. In order for the data to retain its usefulness, it is desirable to avoid proprietary file formats that may become obsolete. In addition, it was recognized that more than one type of software is used during a product design, and that these programs will operate on the same dataset. STEP goes beyond previous data exchange standards by providing for a Neutral Data Model that permits data to be stored on any database platform and accessed from any application via a standard interface. STEP also has the ability to store more than just geometric information, unlike previous exchange standards. Information such as part attributes may also be stored and translated. Originally released by ISO in 1994, STEP is still evolving, and has not yet displaced IGES and other standard formats.

There is still no panacea for CAD/CAM data exchange. There are, however, some good "workarounds" and tricks that can be employed when software doesn't get along. The best bet is to try the simplest solutions first. Consider how the receiving program will use the data. For example, in order to perform a stray-light analysis, a non-sequential raytracing program needs to receive the lens design data from the optical raytracing program, and the lens housing CAD data. If the mechanical design includes hardware that the lens mount interfaces with (i.e., an entire instrument), much of the CAD information will not be needed for the optical analysis. It may be more effective to translate only the lens mount itself, along with any nearby hardware that could potentially interact with the lens system.

If your software is equipped with a translator, try a direct translation into the receiving software format. If this doesn't work you may try to exchange the files via a standard file format such as IGES or STEP. Once this is done, the designer will need to be vigilant about finding translation errors. Pay particular attention to potential trouble spots, such as trimmed entities, curves, and line intersections. Simplifying the original file before transfer can be helpful. Try removing hatching, dimensions, and other non-essential items. A well-structured CAD file will have a smoother translation than a poorly constructed one. Use layers to best advantage and make sure good drafting practices are in use.

If built-in data translators do not perform adequately, a third-party data translation program may be more cost-effective than extensive troubleshooting and repair. A few examples are listed below:

Choose software from a reliable source that provides good technical support. Whether you use a separate data translation program or the original CAD program's own import/export capabilities, don't be afraid to ask the software manufacturer to translate a sample file for you. Websites for either the source or destination software manufacturer may offer tips on sharing data. If the manufacturer is less than helpful, assistance may be found with the software program user groups, chat rooms or online bulletin boards. Post a query stating the problems that you are having - someone else who solved a similar problem may be willing to help. Be sure to include enough detail to elicit specific solutions. If the design file is not proprietary, you can even post the file as a challenge for others to solve!

Before translating a large, complex file, it is best to test the program's data exchange capabilities on a test file. Begin with a simple file and move on to more complex files. Check the accuracy of spline curve translations and trimmed entities. A telltale sign of a poor translation is when lines or curves extend beyond their original length. Pay attention to error messages generated during the translation and exchange (see Figure 2). Perform data exchange testing on both component and assembly-level files. Verify that parametric relationships are unaltered. Inspect fonts and text - these may need to be moved and cleaned up. Perform these tests early in the design process so there will be time to work out the issues without affecting the project schedule.

Solids can be notoriously tricky to translate. 3D solids may be CSG or B-spline entities, and the receiving and source software may have incompatible construction methods. When a solid is translated, the guide curves and wireframes are reconstructed in the new environment and then the solid is knitted together. If too many errors in the knitting process occur, the translation will fail. Some CAD packages include knitting repair, but their capabilities are limited. One workaround is to exchange only the guidecurves, then create the solid in the new program using its own "fill" command to knit the solid together.

We learned to make software get along by experience. The more complete and complex the development project, the more times you will need to exchange data between the various software programs needed for each phase of the project. On a recent development project, we employed several types of CAD software to develop new eyewear (spectacles and goggles - Figure 3). The eyewear consists of an ophthalmic frame, an elastomer "skirt" to provide a seal against the face, lens inserts, shields, and insertable notepads in several sizes. At the beginning of the project, industrial designers developed concept models for all of the components and assemblies using Form Z, a surface rendering package. The surface models can be manipulated to show the product from different perspectives and are easily modified. A design concept was selected and optical design of the lenses commenced in Zemax based on the chosen form. Lenses and optical shields were designed to the product specification, which included parameters such as optical power and astigmatism, ophthalmic prism, and minimum thickness. The Zemax design and analysis defined the extent of the lenses to satisfy field of view requirements, material, thickness, radii and tolerances on optical data. This information served as input to the mechanical design, along with the initial Form Z concept models. Most of the mechanical design of the frames was performed in SolidWorks.

Figure: 3 Exploded view of goggle system, showing the software used to design each component. (click to enlarge)

The lenses were designed in Zemax using an approximate position for the eye. We had no difficulties importing IGES data output from Zemax into SolidWorks. The translation was fast and smooth, and no error messages were generated. Zemax has both IGES and DXF export capability, with some limitations. 2D layouts can be exported as a DXF file consisting of arcs and lines. For a non-spherical surface, the arc representing the surface is an approximation that is accurate only at the vertex, top and bottom of the surface. 3D solid models of a Zemax lens, or subset of a lens, can be exported as a DXF file. The surface is represented by a collection of small facets in full 3D orientation. The "Export IGES" command that we used will create an IGES file of the lens data (with traced rays, if desired). Lines (IGES entity 110), arcs (IGES entity 100) and splines (IGES entity 112) are used to represent the surface data. Lens edges are not exported, but can easily be created in the destination CAD program. Zemax software documentation gives an excellent description about how the lens surfaces will be represented in the IGES file and can be used as the basis for correcting the data in the receiving CAD system, if more accuracy is required. The spherical lens design that we translated did not require any corrections. This is a great example of how simpler CAD data files will translate with few or no errors.

Figure 4: Modeling the fit of prescription lenses installed in the frame using SolidWorks.

Figure 5: Edging and field of view determination using lens designs from Zemax and SolidWorks mechanical modeling.

Figure 6: Modeling prescription lenses in the "as-worn" position using SolidWorks.

Once the lenses were imported into SolidWorks, they had to be "cookie-cut" to fit into the frame opening. The fitting of lenses into the frames was performed in SolidWorks, as shown in Figure 4. This data was used to generate edging instructions. The fields of view for various viewing angles were determined without considering refraction effects. The lens, after edging to fit the frame, were sectioned in SolidWorks and a marginal ray was drawn to determine the angular field of view. A schematic of this process is shown in Figure 5. This was done to save time. A more rigorous way to determine field of view would be to export the cut lens from SolidWorks back to Zemax for the marginal raytracing. Most optical design programs, including Zemax, can handle a user-defined lens aperture. Another optomechanical design integration task was to insure that there was no interference with either the wearer's face or with parts of the goggle/spectacle when prescription lenses were installed (-10D to +8D). In the "as-worn" position, the optical fitting parameters (eye relief, centration) were double-checked using SolidWorks to model the system, as shown in Figure 6.

The engineering plan called for importation of the Form Z files into SolidWorks, which was a more suitable program for producing mated assemblies, fabrication files, and drawings. Unfortunately, we discovered that Form Z could only output facetted IGES surfaces that SolidWorks was not able to interpret properly. Numerous attempts at translation were unsuccessful, and we realized that there was fundamental limitation in Form Z's IGES translator. As a workaround, we imported only the guidecurves in IGES files from the Form Z design. Because no surfaces were created, these curves were not facetted, and were successfully used to recreate solids in SolidWorks, mainly by using loft and sweep commands. Though we were successful in the end, we exceeded our budgeted engineering hours.

The rubber skirt component of the goggle was very difficult to model and design in SolidWorks due to its thin-walled, complex, "swoopy" geometry. This component was therefore designed in the Alias surface modeling program. Surface models can be pulled and stretched much like an actual rubber part, making Alias a more appropriate environment for the skirt modeling. We had been assured that models created in Alias could be imported into SolidWorks so that we could mate them into complete assemblies. Pre-tests of simple parts translated into IGES files and imported were successful. However, when the finished skirt designs were imported, knitting errors resulted. The repair features in SolidWorks were not able to fix them. We tried resaving the SolidWorks files as IGES files and doing the repairs in Alias, but new errors were always generated in the retranslation process. There was probably a solution to this problem, but we ran out of time. In the end, we used the imperfect files, and they were good enough to show what the skirt and the complete assembly looked like. However, because the skirts were incompletely knitted, SolidWorks represented them as surfaces, not as solids, and was unable to produce a section view of the part. This limited our ability to insure correct fit of the skirt to the frame.

After each mechanical design iteration, the data was output for rapid prototyping. Our rapid prototype (RP) house uses the 3-D program Solid View for viewing and quoting files, and Pro-E for file manipulation. Some of our files were output in IGES format from Form Z. The RP house was able to use these files; except that they were so large they had to be sent by CD-ROM rather than over the Internet. Other files were output as STLs from SolidWorks. These were small enough to transmit electronically, and were accepted without problem. In general, the rapid prototyper told us, the biggest problem they have with files they receive from their customers is knitting errors. AutoCAD solid models are the worst offenders, as the smallest error causes their system to crash. Another common problem results when the designer sets the resolution of the file too low, and the prototype parts come out unacceptably coarse.

The authors wish to thank the following individuals and companies for their contributions to this paper: William Collins and AOtec, LLC. Language translations were performed using "AltaVista Babel Fish" - http://babel.altavista.com/translate.dyn.