Part Program Translation/Emulation
The need to exchange part programs between different brands of NC controls has existed from the time there was more than one manufacturer building controls. This need, referred to as "part program compatibility" is driven by companies that have created large libraries of part programs for brand "A" controls and suddenly discover they needed to run them on brand "B" controls.
Golden E. Herrin
The need to exchange part programs between different brands of NC controls has existed from the time there was more than one manufacturer building controls. This need, referred to as "part program compatibility" is driven by companies that have created large libraries of part programs for brand "A" controls and suddenly discover they needed to run them on brand "B" controls. The cost to reprogram or repostprocess the programs is prohibitive in this situation driving control builders to provide a means of interchanging part programs between the different brands of controls. Additionally, part program incompatibility is not limited to controls manufactured by different control builders but often exists between different models of controls built by the same manufacturer. As a result, control builders have launched a number of solutions to address the problem of program incompatibility such as BCL input (now EIA ANSI-494), translation, and emulation.
To many users it comes as a shock to find out that there is part program incompatibility between controls since we have EIA and ISO standards that govern part program codes. But as it turns out, these standards are used only as guidelines for control designers, not as hard and fast rules. Flexibility is exercised by control designers to create new, innovative, and different programmable features for each brand of control to make them unique and more desirable than their competitor's control. These differences are further magnified by machine tool builders who many times create additional and unique programming capability in the control when they design the machine interface.
The end result of either emulation or translation is the same-read a part program created for a brand "A" control and convert its codes to one that can be understood by brand "B" control. The difference between the two is in how they handle the conversion. Emulation will convert the part program codes on the fly as the part program is being read and executed. Translation requires that the entire part program be converted first, stored in its converted form, and then run. This action is similar in the personal computer world to converting a WordPerfect file to a Microsoft Word file, or a Lotus spreadsheet file to a Microsoft Excel file. The extra step in translation is usually an advantage because it provides an opportunity to make edits and corrections to the stored translated program without altering the original part program.
The question often arises about how well translators and emulators work. Their effectiveness can be compared to that of optical character recognition (OCR) programs for optical scanners. OCR programs can look at a page of scanned text and, in some cases, interpret every character on the page. In other situations where different styles and sizes of fonts are used or where there are special characters imbedded in the text, the conversion is incomplete. The results of part program translation and emulation is very similar to OCR recognition-simple programs for simple machines tend to convert completely and accurately, complex programs using a lot of complex cycles and subroutines often do not convert completely, but like OCR, the voids in translation process can be finished out by manual intervention making the exercise worthwhile.
There are some pitfalls to avoid when utilizing emulation and translation features in CNCs. For example, they can not resolve basic incompatibilities between control architectures such as special cycles embedded in one control and not the other or different methods of branching within subroutines. Additionally, emulation and translation should never be viewed as a solution for basic machine incompatibility. They cannot solve mechanical in compatibilities between machines such as: insufficient number of axis, insufficient spindle speed or power, pallet shuttle versus no pallet shuttle, toolchanger versus no toolchanger, insufficient number of tools, or inadequate work zone size. Also, emulation and translation can not work magic to activate features provided in new machines that were not in older machines and therefore not programmed in the original programs. For example, if the new machine is equipped with probe and torque controlled machining, these features will never be activated from the old programs and therefore the new machines are generally under utilized when running old programs.
Are translators and emulators worthwhile? Yes, even with the above limitations they can still be a very desirable software tool for any shop that is making transitions from old to new controls or when changing brands of controls.