What's new
What's new

Mastercam popularity

I currently own my own company and CAMWorks is my CAM of choice. If I was to hire someone and pick up a different CAM of their choice, and they left, I would just reprogram the part. I honestly don't like running other peoples programs, we all program differently and all though most the it really doesn't matter, a part is a part no matter how you got the finished part, watching someone else's program run in a machine can be painful!

But in the instances of when I was an employee at a shop that bought a seat of CAMWorks for me to use, in all reality, any decent programmer more than likely can open a different CAM software and figure out the basics pretty quick to post out a program or make some basic edits if need be. My previous company still uses some of my proven programs, I believe they have the NC files saved, but I did go back in some time after I was gone and walked a previous co worker through the basics so he could post out the program, but if it were me in that situation, like I said above I would just re program the part.
That makes sense. I suppose the type of parts, and type of shop matter a lot in this case. We make a lot of parts with lots of complexity, where it wouldn't be worth reprogramming so we do our best to always keep the MC files current because we get a lot of rev changes. I'm currently working on a part with over 800 toolpaths. Not saying that to say "my parts are harder" or anything like that. Hell, I might even be able to do it with much less if I were a better programmer. I just find it interesting to see how different types of shops operate.
 
That makes sense. I suppose the type of parts, and type of shop matter a lot in this case. We make a lot of parts with lots of complexity, where it wouldn't be worth reprogramming so we do our best to always keep the MC files current because we get a lot of rev changes. I'm currently working on a part with over 800 toolpaths. Not saying that to say "my parts are harder" or anything like that. Hell, I might even be able to do it with much less if I were a better programmer. I just find it interesting to see how different types of shops operate.
I have quite a few complex parts, but a majority of what I do at my shop isn't repeat work, it is one to three parts. I do have some repeat work that is complex that I have the same 500-1000 tool paths and easily 8-16 hours into programming that have 30+ hour run times. Something like that, no I probably wouldn't reprogram, but I'd say chances are a company is probably up to date on their software maintenance and a quick phone call to a VAR explaining an employee left, we need a quick tutorial so we can simulate, verify and post out this large program, you'll get plenty of help.

My most recent company I worked for before I went on my own, had a repeat part that I had programmed in CAMWorks, it was a few months after I had left, they called, asked if I could help them out. I went in the next day and walked an old co worker through simulating, and posting out programs. You wont get that with every employee or co worker, but I don't burn bridges. Since I've went on my own, I've done work for multiple previous employers and I've had a few do work for me as well.
 
And for simple user level post changes you don't have to learn MC's retardet MP post language to change a coolant code. It's all in a logical spreadsheet.
Yeah, I've exhausted my options at that level of post editing that's allowed via the txt files which is essentially what codes/comments to place at certain points in the call stack. i.e. safe positions, tool changes, work offset calls, etc..

What I can't change is things like how a G81 is posted and it's corresponding arguments; or how a linking move to the safe/home position is called on 5x drilling.

5x optimized movements to keep the tool close while the part is indexing is a challenging task, most posts default to full Z retract, index, then approach. There is some cleaning up to do on how this is executed on the Fanuc control. It works, just not ideal or representative of what the software is capable of. It's a complex problem to solve for sure. Just would like to sit down with them and show them what we see so they can have that 'ah-ha' moment.
 
With regards to AI, I think rather than have the AI write the gcode directly, it makes more sense to have the AI interface with the CAM software.
The tools that some CAM systems have regarding "Technology Databases" is really what would need to be developed, IMO. Tools with proven cut data for specific features and then combined with Feature recognition gets us part of the way. Holes should be a no-brainer at this point, but I haven't seen a dataset that's reliable from a fresh install. The customer is left to build that out to their liking which in most cases would be best anyways as who the heck knows what people are doing with their tools and what kind of work-holding they're using. However, I feel 'standard' use cases should be bulletproof. i.e. drilling/tapping holes, generic pockets, and even 3D surfacing to a specific finish requirement considering cusp height and Ra.

Using manufacturer specs on a tool is hit or miss. So, just importing their data isn't always ideal either. Not to mention only a few tool manufacturers have partnered with CAM companies to make their tool data available, none of which is cross compatible amongst CAM systems. Maybe the geometry is easy, but the solid cut data is rare to find.

If Sandvik handed out well proven and well laid out strategies to use with MC, good luck catching up with that.
 
. I do have some repeat work that is complex that I have the same 500-1000 tool paths and easily 8-16 hours into programming that have 30+ hour run times.

I cannot, for the life of me figure out how you guys are capable of producing CAM files with 500-1000 toolpaths, in 8-16 hours. It has taken me much, much longer than that.
 
I cannot, for the life of me figure out how you guys are capable of producing CAM files with 500-1000 toolpaths, in 8-16 hours. It has taken me much, much longer than that.
For me, it's the TechDB defaults that are saving me a whole lot of time. I can in some instances make it through parts without ever adjusting, feeds, speeds, DOC, etc. As long as when I configure my stock I select the correct material, I have it all separated based on material as well.

All my standard tools and operations have everything saved, if I select a 1/4" ball end mill for a multiaxis toolpath, and my material is selected, it pulls in all my saved data based on what I've saved over time. I select the tool from my crib, create the operation, and generate the tool path. Then of course I have a drop down for further defaults within them operations as well for odd stuff that may need adjustments.
 
Yeah, I've exhausted my options at that level of post editing that's allowed via the txt files which is essentially what codes/comments to place at certain points in the call stack. i.e. safe positions, tool changes, work offset calls, etc..

What I can't change is things like how a G81 is posted and it's corresponding arguments; or how a linking move to the safe/home position is called on 5x drilling.

5x optimized movements to keep the tool close while the part is indexing is a challenging task, most posts default to full Z retract, index, then approach. There is some cleaning up to do on how this is executed on the Fanuc control. It works, just not ideal or representative of what the software is capable of. It's a complex problem to solve for sure. Just would like to sit down with them and show them what we see so they can have that 'ah-ha' moment.
why not use linking moves to keep the tool close while indexing?
 
why not use linking moves to keep the tool close while indexing?
I do. And that portion works ok for most, but the logic in the VM sometimes introduces a full retract. I wouldn't doubt if there was a setting I overlooked for those instances as I'm still navigating my way through things, don't always use those machines, and have only used HM for 2 years now.

But enabling optimized 5x movements also forces us to use feed moves in place of rapids to make those types of moves fluid as doing it in rapid doesn't allow for a constant rate when there are 100 positions that make up the whole repositioning sequence. Then, small moves seem fast where larger moves are slow due to the feed rate setting being at 200ipm vs rapid getting up to 472ipm. Sure, I could set the feed to what rapid is, but we like to keep the pucker factor lower as we gain more confidence in the VM(which is solid btw).

For this example specifically, I'd like a bit more insight into getting these settings dialed in which probably involves some job parameter tweaks as well as post tweaks to get things to be money. Where this wraps into my initial point is that I made the tweaks to get it this far.

When I first received the post for either of our Fanuc 5x controls(same control/different machine style, head/head vs table/table) neither worked. And at the time I was entirely new to HM so I was doing what I could to just get things functional with help from support. Then tweaked more as I went. If we had a Grob or Hermle, it would've been pretty close to plug n' play as they have decades perfecting posts for the Siemens and Hiedenhains. For Fanuc... not so much.

Fanuc actually recommends using TCPC while in TWP, but HM support balked at that(which is a story on its own). It makes a big difference on a Head/Head machine, not so much Table/Table. But handling the logic of when to use it or not and getting that all dialed in takes some effort. And I would be more than happy to sacrifice my time getting that figured out on my own, I just don't have access to the tools that allows me to deep dive into the post to do that. I get a check box here and there, but have to ask for a change of that type to be implemented by them. Then starts the war of Post Guy vs Programmer vs MTB.

Anyways...
 
I do. And that portion works ok for most, but the logic in the VM sometimes introduces a full retract. I wouldn't doubt if there was a setting I overlooked for those instances as I'm still navigating my way through things, don't always use those machines, and have only used HM for 2 years now.

But enabling optimized 5x movements also forces us to use feed moves in place of rapids to make those types of moves fluid as doing it in rapid doesn't allow for a constant rate when there are 100 positions that make up the whole repositioning sequence. Then, small moves seem fast where larger moves are slow due to the feed rate setting being at 200ipm vs rapid getting up to 472ipm. Sure, I could set the feed to what rapid is, but we like to keep the pucker factor lower as we gain more confidence in the VM(which is solid btw).

For this example specifically, I'd like a bit more insight into getting these settings dialed in which probably involves some job parameter tweaks as well as post tweaks to get things to be money. Where this wraps into my initial point is that I made the tweaks to get it this far.

When I first received the post for either of our Fanuc 5x controls(same control/different machine style, head/head vs table/table) neither worked. And at the time I was entirely new to HM so I was doing what I could to just get things functional with help from support. Then tweaked more as I went. If we had a Grob or Hermle, it would've been pretty close to plug n' play as they have decades perfecting posts for the Siemens and Hiedenhains. For Fanuc... not so much.

Fanuc actually recommends using TCPC while in TWP, but HM support balked at that(which is a story on its own). It makes a big difference on a Head/Head machine, not so much Table/Table. But handling the logic of when to use it or not and getting that all dialed in takes some effort. And I would be more than happy to sacrifice my time getting that figured out on my own, I just don't have access to the tools that allows me to deep dive into the post to do that. I get a check box here and there, but have to ask for a change of that type to be implemented by them. Then starts the war of Post Guy vs Programmer vs MTB.

Anyways...
i dont think you can rapid smooth linking moves anyway, it would jitter like crazy, at least it has any time i've tried. trust your sim(after proven on several jobs) and full send with smooth linking moves at max feed rate!
 
I've been doing it for years with no problems, and know many others that do it as well.

Programming is the easy part of my day, most the time my machines can't keep up, I'm always ahead on programming. I've built my TechDB in CAMWorks to work for me, and make programming incredibly efficient. I've built in many default settings based on material and operations created that I rarely have to select a tool, change feeds or speeds, DOC, step overs. Over the years I have defined the TechDB to how I program. It doesn't work on every part, but one of my biggest customer a majority of their parts, I don't even have to select any features. Create the stock, Extract Machinable Features, and Generate Toolpaths, less than 5 clicks I can have I'd say I can have 50% of my parts programmed. I do greatly benefit from this particular customer designing in SolidWorks and sending me SW native files, CAMWorks recognizes and sorts the threaded, reamed, counterbore holes, etc. and again will pull out the correct spot drill, drill, tap or reamer, etc. and depending on the size I have it pull in a chamfer tool and chamfer the hole prior to threading or reaming if the spot drill isn't big enough to do it.

As a one man shop, you have to find ways to make things work for yourself, this goes for my machine set ups as well. I created my own tool pre setter that the length offsets are universal from machine to machine, and based on my vise bed being Z0 in the machine. I don't have to ever jog down a tool to touch it off, I don't ever have to pick up a Z height in my machine based on above and how I program. I know where my vises are, and if I set a part on parallels my Z machine height is the parallel size.

Like I said, you have to find ways to make things work for you and be efficient. If your business failed, I highly doubt it was solely due to being the programmer.


Wow. I feel lazy yet doing so much more work then I need to be.

I mainly use Camworks. I really need to spend more time in the techdb and getting better at adding my own stuff. I have my basic tools and and feeds and speeds for certain tools, and was adding more stuff to the library when I first got it, but last few years I have just been head down doing the work trying to get things done, but I probably should of spent more time on the long term time savings available in the techdb.
 
Wow. I feel lazy yet doing so much more work then I need to be.

I mainly use Camworks. I really need to spend more time in the techdb and getting better at adding my own stuff. I have my basic tools and and feeds and speeds for certain tools, and was adding more stuff to the library when I first got it, but last few years I have just been head down doing the work trying to get things done, but I probably should of spent more time on the long term time savings available in the techdb.
I didn't start utilizing the TechDB until about 5-6 years ago, and I had been using CAMWorks for about 10 years at the time!

The old TechDB was terrible to try an get anything right, it was about a year after they overhauled it, I had a slow day and decided to spend some time dialing in operations. It's a never ending process though. I find myself adding and editing frequently but now that I am very familiar with it, its a very easy process and it really helps day to day.
 
The tools that some CAM systems have regarding "Technology Databases" is really what would need to be developed, IMO. Tools with proven cut data for specific features and then combined with Feature recognition gets us part of the way. Holes should be a no-brainer at this point, but I haven't seen a dataset that's reliable from a fresh install. The customer is left to build that out to their liking which in most cases would be best anyways as who the heck knows what people are doing with their tools and what kind of work-holding they're using. However, I feel 'standard' use cases should be bulletproof. i.e. drilling/tapping holes, generic pockets, and even 3D surfacing to a specific finish requirement considering cusp height and Ra.

Using manufacturer specs on a tool is hit or miss. So, just importing their data isn't always ideal either. Not to mention only a few tool manufacturers have partnered with CAM companies to make their tool data available, none of which is cross compatible amongst CAM systems. Maybe the geometry is easy, but the solid cut data is rare to find.

If Sandvik handed out well proven and well laid out strategies to use with MC, good luck catching up with that.
The default TechDB settings and operations you get in CAMWorks are absolutely terrible, I'm pretty sure whoever developed them has never been in front of a machine!

I remember the first few years using CAMWorks and trying the Feature Recognition and allowing it to do its Automated process, thinking, what in the hell kind of tool paths is this and who would ever program a part like this! And this seems to be the source of every complaint of users that have tried and dislike CAMWorks. They have this idea that day one it should be perfect and it's far from it and they either don't care to take the time to make some needed changes or just don't do it and give up cause it's not what they expected day one.

"The customer is left to build that out to their liking which in most cases would be best anyways as who the heck knows what people are doing with their tools and what kind of work-holding they're using."

You said it right there, I agree 100% with that statement, and assume that's part of why, but like you said, there are some basics that could be easily perfect, I remember a I had to reinstall and forgot to import my TechDB and all the blind tapped holes were being tapped .25" deeper than the drill, pocket roughing strategies straight plunged at 100 IPM to floor depth.
 
Wow. I feel lazy yet doing so much more work then I need to be.

I mainly use Camworks. I really need to spend more time in the techdb and getting better at adding my own stuff.
I deep dived the TechDB for a while. The easiest, and IMO, the best way to add you're own stuff is this: Program up a specific feature, like a pocket, with the roughing and finishing you typically use. Then, in the feature tree, right click on that feature and 'Save Operation Plan' and give it a unique and simple name. Then when you make a new pocket feature, you can set what operation plan you want it to use. So, in theory, if you do this for a large portion of your repetitive tasks, you can take a generic part that uses these tasks, make all the features with their desired strategies, and then "Generate Operation Plan", boom done.

To take it one step further, you can set the default strategies that it picks in the TechDB. That way when you make a feature or recognize a feature, it's set to YOUR default. It takes a few tries to figure out the flow, but it's the fastest workflow I've found personally.

Additionally, I think it's important to have the tools YOU use in the database. That way you know exactly what you're working with when you're deciding what to grab.
 
i dont think you can rapid smooth linking moves anyway, it would jitter like crazy, at least it has any time i've tried. trust your sim(after proven on several jobs) and full send with smooth linking moves at max feed rate!
Its a acceleration/deceleration thing. Rapid moves are considered point to point, exact stop type of mode. Ramp up to speed and down to stop for each point. Where as feed moves are blended due to an allowance of corner rounding(or starting the next move before finishing the last). Finish quality settings being set to max accuracy produces similar 'jittering' results. Fanuc has AI controur control and high speed settings that help smooth line-arc feed moves but can also control accuracy as well. Our head/head machine can travel at 2000ipm in XY. Turning on AICC keeps the machine from cutting corners, but gives it the freedom to haul the mail if it can, again adjusting the accel/decel profiles throughout the path. It's always a balance between speed/accuracy.

I'm curious as to how Siemens and Heidenhain handle it as I've never used one of their controls.
 
I deep dived the TechDB for a while. The easiest, and IMO, the best way to add you're own stuff is this: Program up a specific feature, like a pocket, with the roughing and finishing you typically use. Then, in the feature tree, right click on that feature and 'Save Operation Plan' and give it a unique and simple name. Then when you make a new pocket feature, you can set what operation plan you want it to use. So, in theory, if you do this for a large portion of your repetitive tasks, you can take a generic part that uses these tasks, make all the features with their desired strategies, and then "Generate Operation Plan", boom done.

To take it one step further, you can set the default strategies that it picks in the TechDB. That way when you make a feature or recognize a feature, it's set to YOUR default. It takes a few tries to figure out the flow, but it's the fastest workflow I've found personally.

Additionally, I think it's important to have the tools YOU use in the database. That way you know exactly what you're working with when you're deciding what to grab.
That’s where it really started for me, I started saving operations and started seeing the benefits and one day I took the deep dive and just configured as much as I could directly in the TechDB.
 
I deep dived the TechDB for a while. The easiest, and IMO, the best way to add you're own stuff is this: Program up a specific feature, like a pocket, with the roughing and finishing you typically use. Then, in the feature tree, right click on that feature and 'Save Operation Plan' and give it a unique and simple name. Then when you make a new pocket feature, you can set what operation plan you want it to use. So, in theory, if you do this for a large portion of your repetitive tasks, you can take a generic part that uses these tasks, make all the features with their desired strategies, and then "Generate Operation Plan", boom done.

To take it one step further, you can set the default strategies that it picks in the TechDB. That way when you make a feature or recognize a feature, it's set to YOUR default. It takes a few tries to figure out the flow, but it's the fastest workflow I've found personally.

Additionally, I think it's important to have the tools YOU use in the database. That way you know exactly what you're working with when you're deciding what to grab.

Thanks, I am going to start doing this.
 
Its a acceleration/deceleration thing. Rapid moves are considered point to point, exact stop type of mode. Ramp up to speed and down to stop for each point. Where as feed moves are blended due to an allowance of corner rounding(or starting the next move before finishing the last). Finish quality settings being set to max accuracy produces similar 'jittering' results. Fanuc has AI controur control and high speed settings that help smooth line-arc feed moves but can also control accuracy as well. Our head/head machine can travel at 2000ipm in XY. Turning on AICC keeps the machine from cutting corners, but gives it the freedom to haul the mail if it can, again adjusting the accel/decel profiles throughout the path. It's always a balance between speed/accuracy.

I'm curious as to how Siemens and Heidenhain handle it as I've never used one of their controls.
i wouldnt be able to tell you how they do it from a foundational point of view, but its Fmax vs f(whatever your feed rate is)
 








 
Back
Top