Machining Cost Model Enhancements
• aPriori 2019 R2 provides a new External AxiGroove Broaching operation. This operation represents the linear broaching of a rotationally-symmetric pattern of slots, such as the fir-tree or dovetail root joint features commonly found on turbine and compressor disks. In this operation, a linear broach with a series of roughing and finishing teeth is applied in turn to each slot comprising the AxiGroove GCD. Note that this is different than the Internal Gear Broaching operation, which assumes that all slots are cut simultaneously by a broach which has teeth distributed around the circumference of the broach.
The External AxiGroove Broaching operation now will be assigned automatically to external AxiGroove GCDs which are determined to be feasible for broaching but not for hobbing. To determine feasibility for broaching, a new AxiGroove property isStraightExtrude was introduced; when set to true it indicates the AxiGroove geometry can be generated by extruding the tooth/valley profile in a straight direction and therefore can be created by a linear broaching motion. Feasibility for hobbing is determined by checking the value of the existing AxiGroove property Radial Undercut Volume Ratio. A value greater than zero indicates that some geometry of the axiGroove “teeth” obstructs the adjacent slots or “valleys” when approached from the radial direction and therefore hobbing is not feasible. In the baseline cost models, External AxiGroove Broaching will fail if the slots are unobstructed, so that Hobbing is assigned instead. If broaching is desired in this situation, override the feasibility rule checks for the operation.
• In aPriori 2019 R2, the Machining cost model was re-architected to make the code easier to maintain and configure. A significant portion of machining operation logic was consolidated into centralized library files. Specifically, operation costTaxonomy and toolLookup files were consolidated for a targeted set of processes and operations. Previously the logic was defined separately for each unique combination of process, operation, and GCD, even though much of the logic was identical or near-identical.
This code-consolidation resulted in greatly streamlining the cost model. the targeted processes and operations, the number of distinct files and the number of lines of code each were reduced by roughly 90%; overall the number of distinct files and lines of code in the entire Machining cost model was reduced by almost half. As a result, it will be much easier for both aPriori developers and customers to extend or configure cost models, as new operation logic needs to be implemented in only one centralized location instead of tens of locations.
The logic and functioning of the cost model were not altered (with the exception of some bug fixes identified during the code consolidation process). Therefore, general cost model behavior and results have not changed as a result of this consolidation effort. Customers who plan to configure the Machining cost model should familiarize themselves with this file consolidation approach and adopt the use of centralized library files as practical, in order to make future upgrades faster and easier.