The Cost Of CAM Automation

Some years ago I had a demo of Featurecam. At the time I was using VX now ZW3D and while I could cut parts there were things involved to do so I did not like. Things like having to create a surface where the cut path would extend past the part perimeter so I could generate a more efficient tool path. So the idea of feature recognition was of interest to me and I wanted to see Featurecams version of this. Keep in mind this was probably five or six years ago so I have no idea what the current capabilities are.

The auto part cutting toolpath the guy pulled up dropped my jaw on the table. One click and there was this magical stuff on the screen. But then it went downhill quickly because when I asked for specific finishing strategies he could not do it. I presume shame on him for not spending the time to learn 3D. If I was selling software I sure would not decide learning all about it was to hard but he did. But the other thing I decided was there were to many complexities to make it work. VAR’s take note. Featurecam lost any chance with me because they sent an incompetent out to demo and sadly he was the only demo jock Featurecam had around here.

Now the question of is it worth it to slog through the process of finding the magic for daily real world use needs to be asked. Is it even possible for CAM software to automatically do what I want often enough or ideally all the time? The answer for me was no then and still is today.

I am going to talk about Geometric’s CAMWorks for SW and SE VS Autodesk’s HSM today and compare the underlying philosophy of the two programs. The question is will it be worth the time to make a complex set of rules work as in CW or is it better to have rapid tool path creation where the user has to interact with the program at every step of the way. I will say this for Geometric. Even though I have no interest in them anymore the program has come a LONG way from the SE ST7 CW4SE debacle. I can’t say much about the SW side as I have never used it. But there is a huge difference between quick and easy well laid out CAM strategies and the labyrinth of complexities to make things work most of the time with feature Recognition and Tech Data bases or their equivalents. What makes sense for most shops?

This is a reply to an ongoing post at the closed CAMWorks SW user forum. The forums may be closed but they never say you can’t copy paste what is there so I do so today.

“November 30, 2015 at 5:23 PM
#41481
Reply
dr_cw
Participant
Topics Created: 0
Replies Created: 2

Know this is an old post but we are ‘new’ Camworks users as of 2014 and we experienced some of the same issues and frustrations noted above. However things are better.

Brief history, we are a production shop, use customer models, and have used another CAM package for over 30 years, so we’re not newbies in that regard. FYI, our main CAM software has it’s fair share of a learning curve and issues too. Solidworks is our CAD software.

Our primary interest is the AFR side of Camworks, knowing there will be limitations, it still looked good. After the past year, and minimal Camworks use (inconsistent program results) we just committed two people, for the last twelve weeks, doing nothing but Camworks ‘development’. It has come along ways toward being what we were wanting it to be.

The four key points for us were:
Understand, and set the default options for Camworks (do this before the next step).
Complete rebuild of the Techdb, started from scratch for strategies, particularly the operation default settings.
Set all tooling feeds and speeds.

A multitude of testing and documentation on AFR application, this is on going.
A bit unusual but depending on how AFR is ran it can provide different results, sometimes it will only run one way and not another. We use, MfgView setting and our optimum process is do a manual “Mill Part Setup”, choosing machining direction. Then run “Recognize Features”. Holes, pockets and bosses run well, most slots come out pretty good. Fillets and ‘broken’ geometry can be an issue.

For what it’s worth, good luck.”

There is I suppose in a large shop a place for CW. But what astounded me was the time this shop thought was worth it to make CW work a fair portion of the time. I was left thinking to myself that if this is a real metric for time to do it right how in the WORLD was a small shop ever going to find 2 men times 12 weeks times 40 hours a week (I presume) to get some common features to work well while leaving much that still does not? 960 hours of time gone and how could I possibly justify or benefit from this? Just how many YEARS of cam plans could HSM write in that same time period? And never have to worry about Tech Data Base corruption requiring a rewrite through program failure (fairly common based on forum complaints) to Geometric changing the way it all works requiring you to redo your data to meet the new paradigm. And don’t forget to add the periodic Microsoft Access problems into the mix for further joy and productivity.

What is the value of time in our shops? What is the potential value of the time gained in years to come if the TDB and Feature recognition could be made to work right and in a bullet proof fashion? It might be worthwhile for specific environments and particular conditions but for the vast majority of us, no way Jose. Certainly it must be mathematically possible to implement the TDB FR paradigm but no one has come up yet with the underlying structure to make it work without tremendous up front and reoccurring effort.

This idea of time has value and simplicity while producing profit-making tool paths is the underlying premise of a program like HSM. To bring in a part cold and quickly generate a tool path with either a unique tool library for that part or picking from a common use one you already have. How many programs could be done with 960 hours of time and unlike the above shop where their fruit off the tree only works often the HSM tool paths always work just like you program them to. 960 hours just blows my mind.

Sitting here this morning trying to figure out how this TDB FR scenario would really be beneficial after all the time spent to get most of the way there to the CAM Valhalla and I just can’t see it. But then I have never worked for a company large enough that could possibly benefit from this.

Where I am heading with all this is can software be to clever and to cute with its underlying operational premises? In other words is it even possible to do at this time with current state of the art capabilities? What are the real needs for most shops?

If I and my nearby peers are typical what we want is quick, easy and reliable CAM plans and we do not want tremendous overhead and complexities that take lots of time both to learn and implement and then periodically have to repair.

Sometimes I wonder why aspects of programs were written or tried and I often think that like CAMWorks (and ProCAM before them) has tried to do the results reflect more of what some marketing whiz-bang says will sell over what the technical guys say they can actually do. We all know what happens when wonderful sales people dictate what will be done over what can be done don’t we.

Leave a comment