Machine configuration should control Speeds and Feeds

[Greg_Haisley]

OK here is the scenario. You have a HOT job that you want to post across various machines with different max spindle limits. (My current CAM programming problem.) My work around is to copy the job and manually adjust each tool to not exceed the machines max spindle speed. Not a big deal if you only have a few tools. But do it for 20 tools and 3 different machines and tell me how you like managing that mess.

With the current product you have to edit each tool with regards to spindle speed limits to get optimum output from the machines. If the system would allow for the machine configuration to over ride the speed / feed based on a max SFM setting relative to each tool. Then the task of posting to various machines with different spindle max  limits becomes a non issue. 

Thoughts anyone? I tend to overreach allot with CAM packages. It's my nature to exploit the system to the max.

[Rob.Lockwood]

Yep. I've hammered on this before, among other related stuff. It's really kind of a quagmire when you get into the details; do the machines have the same horsepower available relative? I think it's hard to get this perfect, but having nothing is crummy.

Fwiw, you could definitely tackle this with a ton of post-processor customization.. 🙂

[Greg_Haisley]

@Rob.Lockwood it is a good thing you and I aren't coders. I figured you probably thought about this one before. I searched the HSM ideas for something similar but did not find anything.

If development doesn't want to tackle this one.

Then please fix the tool layout so these edits would be a lot easier. What I'm talking about is this - you want to increase the RPM for a tool, fine change the RPM. Guess what just happened? The chip load just decreased because you increased the RPM. That is not the way it should work. The chip load should remain constant relative to the RPM. Not relative to time. In my case IPM. Please at least fix this issue if the original issue is too much of a challenge. 

[Rob.Lockwood]

@Greg_Haisley this one is probably just in how you're initially defining the speed/feed, but you're right, it probably needs adjustment.

If you define your feedrate as IPT, and allow the feedrate to be calculated based on RPM*IPT*Flute#, then feedrate will adjust properly. If you input the RPM and feedrate directly, then the feedrate is now the master, and the IPT will adjust accordingly to maintain the feedrate.

As far as being coders.. one of these days i'll get sick of sitting on this side of the fence 🙂

[Greg_Haisley]

@Rob.Lockwood excellent point. I keep forgetting about using formulas within the UI. My bad. I'll fix that right away.

It does suck on this side of the fence. I was told that each job is like a school test. The catch is you have to get a 100% every time to get paid no exceptions.  'B''s or worse are reworks/rejects.

Wouldn't it be nice to produce a product that your customer base will provide ideas to make your product better even though they are the ones paying for the product in the first place. I can't seem to get my customers to do that. Hmmm wrong business model I guess.

[Anonymous]

Like CAMWorks ( which has a user database for feeds and speeds ) and Solidcam ( which has iMachining and settings for its aggressiveness on roughing ), HSMWorks should use a database and equations for which feeds and speeds should be automatically calculated when creating toolpaths. If not purely automatic, it should be a very good starting point or option for the CAM user. Things that need to be taken into account for such calculations are: The machine used, the workpiece material, the cutting tool used, depth of cut, width of cut, diameter of cutter, and ... any other ideas that come into play? Well, method of holding the workpiece would be another, but it's hard to quantify such things as these. Using flood coolant, no coolant, spray cooling, etc. .. is another factor. The cutting tool is another uncertainty - whether it's new and sharp, or old and worn. The code of the HSMAdvisor software would be a good place to start to adapt to HSMWorks. As of now, the only thing Adaptive Clearing depends on is the cutter diameter and nothing else! Obviously improvements can be made, but it might take an enormous database and much research to calculate the best speeds and feeds under all conditions. Well, you get the idea. Again, there's obviously a lot of uncertainties when trying to calculate the optimum feeds and speeds, but at least something better can be done to automatically get the CAM programmer in a good range.

[Anonymous]

While I haven't used HSMAdvisor, I've had great results with the web-based FSWizard, and it's my go-to calculator. I like that it gives you deflection, torque, cutting force, horsepower, etc. About the only thing it's lacking is accounting for variable helix angles, but I feel you can get very well within the ballpark with one number.

To do this very well, even more data would be needed. When programming, I will sometimes reference the torque and horsepower performance curves for the machine spindles the job will be running on. A 15HP machine is not 15HP at all RPMS. That's a peak at a very specific RPM. If you're running at the top of the RPM range, the actual horsepower (and especially the torque) may be significantly less than the rated maximums. 

This is one of those things where it would be nice if everyone in the industry just got along and shared data in a standard format that helps everyone do their job better, but unfortunately, not all manufacturers publish comprehensive performance curves for their spindles.

Long story short though, it would be very nice to have the option you propose. Say I have a job running on a 6k RPM spindle, with many operations that run at 6k RPM (and could go higher) but not all of them. Now I want to run the same job on a 10k RPM machine that just became available and get the job done faster. I don't want to have to edit every operation to do that. You could go with an override at the machine control, but that would be a blanket bandaid to all operations, which is only good if all of your operations can run faster without maxing the SFM for the material/tool combo, which not all of them can, especially if running HSS tools or hard materials. So, I'm back to two separate setups, one for each machine, where the feeds and speeds for each operation are tailored to each machine.

Not to speak for Autodesk, but from a conceptual standpoint, I imagine there would be a myriad of use cases and plausible scenarios, causing this to be a longer-term idea to implement, to cover every one of them. It would be cool if they figured out how to do it well.

[al.whatmough]

I need to mark this as Future consideration.

That said, please keep the conversation going on this here.  We will come back to it.

A few things we need to solve first.

• Support Machine configurations in all products (WIP this QTR)
• Shared tool library for all product (WIP for this QTR)
• Support cutting data (AKA recipes) in the tool library (WIP for next QTR)