Middleware Bridges the Optical/Mechanical Design Gap
- Created on Monday, 01 May 2006
Mechanical CAD (computer-aided design) programs have become very sophisticated during the past few years. Unfortunately, there is still a portion of the engineering spectrum that cannot be handled well in a traditional CAD program: optical modeling. If you are creating a complicated optical system (think of a camera zoom lens), then it is best to perform almost all of the design in a specialized optical design software program and then transfer the optical design to a CAD program for the later stages of the design process where items like housings, threads, cams, and motors are designed and integrated into the model.
On the other hand, if you are designing a simple indicator light for the outside of a computer housing, then the optical analysis would be a small portion of the overall design, which would be performed almost entirely within a CAD program. The projects that lie in between these two extremes are the ones that typically require using some type of optical software in addition to CAD software. Ideally, the optical and CAD software also have to exchange model data back and forth between them in order to facilitate the iterative cycles that the engineering process typically entails.
Interoperability and Data Integrity
A typical application that requires iterative exchange between optical and CAD software would be the design of specialized or technical lighting. A good example would be an LED ‘ring light’ that mounts on the outside of a camera lens, providing broad, even, and consistent illumination for macro photography, robotic vision, or even medical procedures. In these cases, both the optical and mechanical aspects of the ring light design need to be considered together.
Depending on the capabilities of the CAD and optical software, the design of a ring light model could follow four different workflows.
First, the model could be exchanged back and forth between the optical and CAD software using external data files or translators. Passing the model directly between programs would require either a common data file format or import/ export translators to translate from one file format to another. Using a common data file format would be ideal as long as the optical software program respected the integrity of the CAD data in the file, and vice-versa. Unfortunately, most software programs use proprietary formats. On the other hand, using translators to import/export solid models has a large drawback in an iterative workflow environment. Optical properties (i.e. reflective coatings) would need to be re-applied every time the model is imported back into the optical software, and mechanical design properties (i.e. tolerances and parameter dependencies) would need to be re-applied every time the model is imported back into the CAD software.
Second, the CAD and optical software could transfer model changes directly using data exchange protocols. DDE or COM protocols often are used to exchange data among Windows programs. This approach typically requires specialized macro programming to make sure that the desired data is transferred and applied on the receiving end.
Third, the optical software could work as a sub-program entirely within the CAD software (or vice versa). This approach typically limits the capabilities of the subprogram due to user interface, data manipulation, and memory management limitations of the “parent” program.
The final option is to have an approach where you primarily perform design work in program “A” and utilize a sub-program, or bridge program, to apply specialized properties for program “B”. Model transfer only goes one way (from “A” to “B”), but program “A” (in combination with its bridge or sub-program) maintains all properties for both programs “A” and “B”. Lambda Research has adopted this final approach through the development of TracePro Bridge for SolidWorks.