Shop's Coding Solution Results in New Time-Saving Software Feature

No matter how good the software package, those using it can always come up with ways it could be better. Vericut from CGTech (Irvine, California) is no different, regularly adding features and functionality based on feedback from its user base. Most of the changes are small—updating a CAM interface to the latest version or adding a filter to make searching for data easier—but occasionally, the company receives a customer request for a more robust change. Responding to requests both large and small, the company aims to maintain a user-focused product experience over the long haul.The software is currently in its eighth version.

One such request came from Ultra Machining Co. (UMC), a second-generation, family-owned manufacturing company in Monticello, Minnesota. UMC has served the area’s aerospace and medical industries for nearly 50 years. It specializes in precision machining of complex parts from difficult materials such as Hastelloy, Inconel, Stellite and other superalloys. UMC employs more than 200 people and operates a variety of advanced multitasking machine tools, including eight- and 12-axis triple-turret lathes, five-axis machining centers, Swiss-type screw machines, wire EDMs and more. The company offers engineering, prototyping, just-in-time inventory management and various finishing and assembly services.

The specific part that triggered the Vericut customization request was a medical component referred to as a cutting guide. It is made of 17-4PH H900-grade stainless steel, and like most of parts at UMC, is challenging to machine.

To minimize cycle time on this part, programmers Don Lahr and Mike Triplett—longtime Vericut users—employ the software’s OptiPath module to optimize tool paths. It does this by breaking them into smaller segments, then dynamically adjusting feed rates based on factors such as cut depth, chip load, approach angle, setup rigidity and other machining conditions.

Instead of using a single feed rate, the OptiPath module outputs NC code that speeds up where possible and slows down when necessary. This greatly reduces problems with deflection in thin-walled, delicate parts, or where clamping forces are less than adequate; interruptions caused by intersecting holes, slots and similar part features; chatter in corners or where large amounts of leftover material are encountered; extreme tool overhang common during five-axis machining; tired machine tools and worn spindles; and tool rubbing caused by inadequate feed rates. Besides problem-solving, the system makes things more efficient, eliminating air cutting and wasted machine motion, and kicking up feed rates on light cuts. All these features come together to improve productivity by shortening cycle times and preventing damage to workpieces. UMC uses the OptiPath module on many of its more difficult jobs.

But there’s one complication. Because the software functions by essentially “taking the reins” when determining the correct feed rate for a given machining condition, it outputs hundreds or perhaps thousands of feed-rate commands throughout a typical program. When a machinist recognizes an opportunity to further optimize the code in a given cutting situation, he or she has two options: either bring the program back to the programmers for another pass or edit it manually.

One reason this becomes a snag is because of the experimentation necessary for many new parts. “When you start the OptiPath process, you input the different variables, including the desired feed rate, and the software takes it from there. You don’t, however, always know exactly what that starting feed rate should be,” Mr. Lahr says. “We’re always programming new parts and trying out different cutting tools. Sometimes, the fixture isn’t as rigid as expected, or the tool is sticking out a bit farther than you’d like, and your best estimate isn’t always good enough.”

According to Mr. Lahr, the operator would sometimes just have to live with a less-than-ideal feed rate. Unless the job quantity was large enough to warrant the additional programming time, or the cutting tool simply didn’t work at the optimized feed rate, it didn’t make sense to let the machine sit idle for up to half an hour while the machinist raised concerns with the programmers. Over time, however, these compromised feed rates cost the shop time and money in extended job times.

After giving the problem some thought, Mr. Lahr and Mr. Triplett developed a simple, but useful, solution. By adding a macro variable “multiplier” to each programmed feed rate and setting the value of that variable to 1.0 at the start of the program, the operator could then globally adjust all feed rates up or down as needed by changing that single value. Because the variable would adjust multiple lines of code (whichever were assigned the variable), using it to increase a single feed rate by 10 percent effectively increased all feed rates by 10 percent. “We let OptiPath do its thing, and if the machinist thinks the machine can run faster or maybe needs to back off for whatever reason, all they have to do is tweak one number,” Mr. Lahr says. “It’s pretty cool.”

However, to implement this change in Vericut, UMC needed some help from CGTech. Mr. Lahr reached out to area sales engineer Scott Reiner, who passed the request on to the development team. To Mr. Lahr’s delight, the custom code was rolled into the next release just two weeks later. “CGTech has made other changes for us over the years, but none of them came through quite this quickly,” Mr. Lahr says. “It was exactly what we were looking for.”

CGTech’s product manager Gene Granata says success stories like this are not unusual. “We receive a lot of requests and inquiries on the website, in our Vericut user groups, training sessions, and even from our field sales team,” he says. “We review all of them. Sometimes the functionality already exists, and it’s a matter of helping the customer find it. But quite often we get suggestions that will be of general use to our customer base and add genuine value to the software. That was the case here.”