This may not be quite a traditional Gallery post but I wanted to showcase something I’ve been working on. First off, thank you to @gmack and @Julien (and others!) for their incredible contributions to the two feeds and speeds calculators that I initially used. What I’ve created here is just trying to take the SFPF calculator that I believe was modified from the NYCCNC calculator and make a really nice to use web app. Taking it one step further, I offer (dumb) optimizations. Check out my short demo walking through the calculator:
Note: please make sure to set HD as your quality otherwise it may look really blurry.
There are definitely still bugs, but what is super exciting about this calculator is the “Optimization” feature. What this does is it allows you to specify a range of chipload, woc, and doc along with a number for each and then it calculates feeds & and speeds for every combination of values, compares it against the constraints and sorts the highest material removal rate to the top. This is essentially equivalent to creating a manual spreadsheet hundreds or thousands of times and manually comparing the spreadsheets. Instead, you specify the constraints and you automatically can answer questions like “given the capacity of my machine, what is the DOC I should use given X material while doing slotting (i.e. 100% WOC engagement)”. I actually wrote an identical optimization script in Python but found myself wanting something a bit more user friendly that didn’t require running code directly. Hence the UI.
Would love any and all feedback based on the demo video! There is a lot of potential for enhanced calculations. One thing I’ve thought about adding is one of those graphs that shows force as the endmill rotates, similar to Millalyzer. I haven’t quite found the need for that myself though. Also the calculator does not yet support spindles, but that would be pretty easy to change.
I haven’t yet published the calculator to an actual website (running on localhost). I was considering Github Pages but it doesn’t support SPA routers very well (need to look into this more). In any case, a big goal of this would be that we could have community contribution by creating materials and cutters in the tool that we could make be defaults. That way when someone new to Shapeoko / Nomad joins they can use the calculator to get a really good starting point for various scenarios. Not sure if that is too far fetched and people actually care about calculating feeds & speeds as much as I do. I know once you have them set you’re pretty much good to go.
Very sleek UI!
I wish I had the web skillz to do something similar.
Some initial random thoughts:
some folks will like to have metric units
some folks (guilty as charged) will like to use a mix of imperial and metric, but I’m not sure there is an elegant way to support that while not cluttering the UI
I find myself optimizing feeds and speeds very differently for “regular” toolpaths (large WOC, low DOC) and for adaptive toolpaths (potentially also large WOC low DOC, but I like to leverage the ability to use much deeper DOC). Since the core of your app is auto-optimization, would it be worth including those two approaches in the exploration of the solution space ?
you’ll probably also need to have an option for “roughing vs finishing” ? i.e. optimize MRR vs. optimize deflection.
I think the most elegant solution for mixed units would just be a toggle on the main UI to display in IN or MM. MD made the mistake back in the '80s with Unigraphics of having 2 different part units, and it’s been a thorn in our foot ever since. I would recommend saving all data in metric/millimeters, and just allowing the user to toggle the display so they could read and enter values in either unit.
another cool option is inline conversions. If the display is metric, you could enter 0.25in, and the app shows & saves it as 6.35mm.
An option to classify an entry as end-cut or side-cut would be very nice.
A super cool option would be “Export to CC csv” so you can dump it to a CC tool database
A thought on units: Have a drop-down next to each number and allow choosing the unit for them individually, and have a master control which changes them en masse.
Thanks so much for the feedback everyone! Definitely some great ideas here.
These are all great points and I’ll have to think of a good robust solution. Funny enough I do use metric units in Fusion 360 but because all of my tools are in inches I find it a bit easier to use inches for the actual calculations. I do in fact enter in inch values into Fusion and it just converts them to mm for me. I think the easiest solution would be to have a toggle for metric or imperial but store everything in a single format. The other options would be nice but would require more time to implement on.
I could be wrong on this, but I feel like both of those use cases can actually be covered with the current optimization, although perhaps not perfectly.
What I have found is that Adaptive Toolpaths use high DOC and low WOC because it does in fact maximize material removal rate. There are certainly other roughing toolpaths you may want to make, for instance a slotting rough toolpath. For that particular toolpath I simply set WOC to 100% and ask for the largest DOC I can get while keeping machine forces and power percents below a certain threshold. Then for the finishing toolpath I typically just do full depth for whatever is left (i.e. 0.25mm or 0.5mm). With the roughing toolpaths I am using I actually specify that I want machine force % to be pretty conservative, so I don’t actually have a lot of deflection even in the roughing. However you are welcome to increase the machine force % and max deflection and just use the calculator to ensure any finishing paths have a chipload > 0.001" so it isn’t rubbing.
I’m not sure you can quite “optimize deflection” because at minimum deflection you are essentially just cutting nothing. However, you can certainly set constraints that you want deflection % below a very small number, and then to maximize MRR given that very small deflection desired.
If you similarly want to optimize for a toolpath with large WOC and low DOC, that can also be done by just changing the min and max for woc and doc according to the thresholds you’d like to stay in.
I will say for finishing toolpaths I haven’t really optimized much because I figure I am cutting so little material that my biggest risk is just rubbing, so I try to just ensure I leave enough stock to leave for that finishing path (a good tip I heard in a NYC CNC video).
Hey folks, it’s been quite a while and I haven’t made any progress on making this tool better as I’ve been distracted with other stuff. BUT I did go ahead and get it published to a spot where people can play around with it, if you’d like: feeds-and-speeds
Feel free to poke around or add issues that you think are preventing you from using the tool. I imagine one big one for power users would be the lack of ability to add a spindle. Right now only router is supported but it shouldn’t be too hard to add support for spindles. Also it is all in inches currently. I imagine it would be a bit more difficult to support multiple units of measure (but not impossible).
If this tool seems unuseful, please say so and I can stop tinkering with it. It’s just meant to be a step up from a spreadsheet and gives you the ability to optimize (i.e. fill out hundreds of spreadsheets almost instantly).
I recognize that maybe this topic should be moved out of gallery since it did have pictures at first but is now more just a discussion. I’m looking into optimizing by feeds and speeds a bit more as I think I’m being a bit conservative, but what is unclear to me is what is a good max power % and max machine force % of the router to use? I’ve been making sure it is <= 25%, but I’m not sure if that is too conservative? I believe on @gmack 's spreadsheet if it gets above 40-50% it starts getting yellow, but I’m not sure what that actually means practically… I imagine you want to keep deflection lower unless you’re ok with doing some extra finishing passes. Any thoughts? cc @Julien
I guess folks that are likely to use such calculators, are also very likely to use the roughing+finishing approach (a.k.a. “the right way”), and will likely want to use the calculator mainly to max out their MRR in the roughing pass.
As you mentioned, for finishing passes there is nothing to optimize since there is so little material being removed, and one usually likes to be conservative on finishing passes anyway.
I would of course let @gmack comment on the rationale for the specific power thresholds values in his spreadsheet, but to me the yellow zone is just a warning that one enters the MRR range where the spindle/router power may start to be a main limiting factor (when it’s very often deflection that becomes a problem first, long before power)
A 25% power target for roughing passes seems too conservative indeed, 50-60% is probably more sensible (or let the user pick a value?)
Thanks for the quick reply @Julien! I tried out 40% (it’s cutting right now) and it seems to be doing just fine. I still kept the deflection pretty low (<20%). Next time I plan to try 50-60% of the power / machine force to see how it does. Curious if you think there’s a decent upper limit for deflection? Given that I will do a finish pass, I figure deflection could also be higher. I have max deflection at 0.001in and then it is doing 20% of that maximum (per how @gmack’s calculator works). So probably could even increase that to 80-100% and leave it to the actual deflection value (0.001in)?
The user can in fact choose a value and constrain the optimization problem however they want. That’s actually 99% of the reason I made the calculator.
I chose the first row, which maximizes MRR. But I’m really just trying to gauge upper limits to target. Sounds like 50%-60% for spindle/router power and machine force is a good target, and perhaps just setting the actual deflection I can live with per my finishing pass and setting max deflection percent to 100% would be fine. Would you agree / disagree based on your experience?
PS I tried this out because I am doing an adaptive cut with a pretty low DOC (the actual feature isn’t very deep) so I wanted to speed up the program a bit. Turns out I was being really conservative regardless of the DOC. So that’s why you see in my constraints I set DOC to be a single value rather than a range.
