hi,
I purchased CAMWorks 2009 (
www.camworks.com) 3 months back after evaluating HSM , FeatureCAM and MasterCAM. I found it to be one of the fastest and easiest cam system on SW for 2.5 axis milling. Specially the knowledge based machining facility.
I am pretty happy with the machined parts produced after running the simulations.
I will be cautious for the scenerio you mentioned.
Joe
Forgive me for saying this...and I could be completely off-base here...but your post sure sounds and looks like a plant from CAMworks. Why in the world would you go out of your way to give out the URL, etc.
If you are a legitimate end-user/machinist, please forgive me for saying the above.
Here's a list of the bugs/issues I just submitted to my VAR:
WARNING: This is the Internet and crazy people can post all sorts of crazy and contrived stuff. In reading throught the list below you are instructed to assume that I am an absolute idiot and that I do not know what I am talking about. Do not form any opinion whatsoever based on what you are about to read without first confirming through your own testing procedures the veracity of the claims. For all you know I can't put a round peg in an oversized round hole.
1- It is possible to generate toolpaths that contain a rapid plunge into the stock. This can cause tool and machine breakage as well as harm to the operator. This is a high-priority bug that needs fixing immediately. What I've been able to ascertain is that it can happen if one sets up a machined pocket feature with some islands and chooses spiral entry. If there isn't enough room for the spiral entry it seems that CAMworks decides that it is OK to, instead, plunge into the stock at full rapid travel speeds. The way I ran across this was to define such a pocket with normal plunge entry and then decide that I wanted to play with using a spiral entry instead. The toolpath was fine before, so I just selected spiral entry and moved on. How could I imagine that CAMworks would think that it was OK to rapid into the stock.
2- Rebuilding a modified part when using any AFR features makes a mess out of the part. Features don't move to follow the changes.
3- Producing a separate g-code program out of each of multiple setups results in programs that are named exactly the same. There is no option to name each program separately. Manual editing is required to fix it. This is not acceptable as this is a place where one could make catastrophic errors.
4- There doesn't seem to be a way to require and use different work offsets for different setups. A part with three setups, for example, will output a single CAM file with all the setups mashed together and all referenced to the G54 work offset. If it so happens that the second and third setups require re-clamping or re-fixturing the part and using a different (G55, G56, etc.) work offset CAMworks does not seem to offer a way to deal with this at all. The single monolithic CAM file will destroy the workpiece as it starts machining past the first setup without so much as a warning.
5- No option to automatically output each setup as a separate CAM file with sequential CAM program names and stipulated work offsets (G54, G55, etc).
One has to output each setup by hand and then go edit each file to change the program name and do a search and replace to change G54 to whatever might be needed. As program iterations are output this is an easy place to make a mistake by forgetting to make a change and crash the machine or ruin a part.
6- The provided Haas post creates a very unsafe program start condition. No tool or work offset is loaded and the machine is sent Z0 without missing a beat. This can result in a serious machine crash, a broken tool, broken or mangled workholding equipment or all of the above.
7- The provided Haas post does not end programs correctly. The tool is left at the workpiece and M30 is not issued.
8- Cutter compensation toolpaths cause errors at the milling machine when it is not taken into account that the tool might probe to be slightly larger than the nominal tool diameter used in CAMworks. The simulator does not have any provisions for this at all.
9- Contour operation. When enabling chamfer mode it is necessary to enable cutter compensation at the CAM level. This should be automatic. Because it isn't it is possible to bury a countersinking tool into the stock.
10- Exit from cutter compensation mode in a small pocket causes gouge when the machine moves from cutter comp to normal. The CAM code is wrong.
11- Haas post has coolant turn ON too late. In some cases the tool is already cutting before coolant comes on.
12- Coolant is being turned OFF too late, which causes coolant to be sprayed all over the toolholder's taper area during a toolchange.
13- Spindle RPM too high during retract. There is no reason to keep the spindle RPM at full tilt while doing a slow Z retraction from the workpiece.
I've watched the spindle run at 12,000RPM while the toolpath is told to move from 0.1in above the material to 1.0in above the material at 3 inches-per-second just prior to a toolchange. Either the spindle needs to be turned off earlier or the speed reduced to 1/10th (or whatever) of the cutting RPM's.
14- Program naming and setup comments are needed on a per-setup basis and these need to be able to make it into the CAM file.
15- No way to insert a programmed pause or stop to re-clamp or clean the workpiece.
16- Changing the origin for a setup does not produce a dialog or anything remotely similar to allow the user to set a different work offset (G54, G55,
etc.) for that set of operations.
17- I've seen it where the specified lead-in and lead-out feedrate is not respected and a different feed rate is used.
18- I've seen a markedly different cutting rate used than what was programmed for the particular tool. For example, a G01 at 150ipm rather than the programmed 100ipm.
19- General user interface issues with such things as windows that don't store and recall their position, the inability to resize dialogs to display full information on table columns that need to be wider, the lack of ability to edit tables in place (which requires cumbersome multi-keystroke navigation (for example: editing tool crib tool feed and speed and tool numbers), the lack of tool crib sorting capabilities, and more. In general, a very sloppy and time-wasting set of lazy interface decisions that cost in productivity and create more opportunities for making mistakes.
20- Using MS Access to edit and manage the database creates lots of opportunities for making serious errors. MS Access is not designed for this sort of ad-hoc database manipulation without a fairly massive amount of code wrapped around the database to, effectively, hide MS Access. I know, I have written many database applications, some using MS Access (which is a dog) others using MS Visual Basic to manage MS Access and SQL databases (better) and yet others using C++ to manage MS Access and SQL databases (by far the best in terms of control and elegance). Using MS Access as the interface through which my users would have to inteface with a database is just about the last choice I'd ever make unless I was able to put in so much code that, effectively, MS Access is safely hidden away.
Some of the above might have fixes through making changes in the way the program is used. Others could be bugs and yet other issues could just be the "personality" of the program.
Your mileage may vary.
-Martin