Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Roadmap for better a settings generator #75

Open
JensDyvik opened this issue Feb 4, 2021 · 5 comments
Open

Roadmap for better a settings generator #75

JensDyvik opened this issue Feb 4, 2021 · 5 comments

Comments

@JensDyvik
Copy link
Member

The settings generator we have in the current version of Bark Beetle is ok, but far from great. And it does not work well on machines that are either much weaker or much more powerful than a shopbot. It works best on milling bits diameter 3-8mm. Smaller bits gets too fast feedrates, and larger bits gets too slow feedrates, but also too deep (aggressive) pass depths.

The settings generator takes information from the user about which type of material is being cut and bit type, and outputs calculated feedrate, pass depth etc:

image

In an ideal world you want to spin the bit as fast as you can (max RPM), so you can move as fast as possible (high feedrate), while also cutting as deep as you can (deep pass depth). This gives the highest possible material removal rate (productivity).

The tricky thing with automatic milling settings is that for smaller milling bits it is the bit itself that is the limiting factor, while for larger bits it is the machine. A large bit can handle deep passdepths and high feedrates, but a machine frame might not be able to resist the vibrations sufficiently, or a spindle might not have sufficient torque to spin the bit at the while moving so fast and deep. An ideal settings generator would take information from a machine profile about the max cutting performance of a machine. this can be used to ensure that the calculated material removal rate is not more than the machine can handle.

Maximum and minimum cutting speed (the speed of the bits knife edge traveling though the material during a rotation) should also be taken into account. This is a combination of spindle speed and bit diameter. Two examples:

  • Large surfacing bits in wood (30mm diameter): If the 30mm bit spins at 18 000 RPM it will build up lots heat very quickly when the machine enters a corner (in corners and other sharp direction changes a machine will slow down according to acceleration/deceleration parameters in order to avoid jerky movements that creates imprecision, deviation from toolpath). The result is that the chipload is super small for a moment while passing the corner, and the high surface speed of the knife of the bit creates lots of heat. This induces burn mark on the wood and will create premature wear of the bit. Surfacing bits are often run around 10 000 RPM with a correspondingly lower feedrate for this reason.
  • Small bits in aluminum: Aluminum cutter better with a relatively high cutting speed. So cutting with a 6mm bit at 18 000 RPM might give better results than a 3mm bit at 18 000 RPM, even though you are asking a lot more of the machine with the 6mm (twice the bit width, twice as high feedrate and twice as deep pass depth results in 8 times as material removal rate). for this reason pass depths with a 3mm bit should be extra shallow to compensate for a tricky cutting situation with lower cutting speed than ideal, or lots of cooling can be used to compensate (I think cooling should be outside the scope of our next gen settings generator).

To summarize:

  • An auto settings generator should know about machine stiffness and max and min cutting speeds for different materials next to the current inputs
  • Ideal cutting settings are first generated based on bit type, material and max rpm available
  • If the calculated ideal settings results in too high of a material removal rate for a given machine, that pass depth is reduced until the load becomes acceptable (in wood this might first be triggered with a 10 or 12mm bit, while in aluminum maybe already with a 3mm bit).
  • If the calculated ideal settings results in too high cutting speeds for a given material, the RPM and corresponding feedrate will be lowered
  • If the calculated ideal settings results in too low cutting speeds for a given material, the pass depth will be lowered.

Another factor is finish quality (rough and fast cut with lots of vibration and clearing cutting marks, or slow and smooth with smoother surface finish). This can be achieved quite easy with a slider.

I have shared these thoughts with Leo McElroy (who is behind our cousin cam BarkBeetleJS inspired, by our original BarkBeelte for Rhino/Grasshopper). He is interested in helping develop this. And maybe implementing it in Kiri too. We have made a small start here. I think a python library or similar that we could use in all versions of BarkBeetle on all platforms could be very interesting. Does anyone have any thoughts, inputs and comments on our next gen settings generator?

@Siemenc
Copy link
Collaborator

Siemenc commented Feb 4, 2021

Interesting thoughts and good summary of some common problems.

What about cut depth? Sometimes materials are thinner or cutting depths are more shallow than the pass depth that gets calculated and in those cases you don't get that much deflection, especially on shallow passes. But I guess this is more of a missed opportunity to optimize speeds rather than it being a problem so maybe something for the future to think about.

@JensDyvik
Copy link
Member Author

Thats a good point Siemen. Leo and I did some work on the basic settings generator yesterday. One good approach could be to compare thickness of the material being cut too the estimated max pass depth, and then boost the feedrate accordingly up to for instance max 50% feedrate boost. A tricky part is that in some instances the slow feedrate is about surface finish/cut quality more than not loading the machine too much. More experiments and thinking to do :)

@mikeFandA
Copy link

It may be worth considering the material density and part-holding method too. The stiffness of the part as a whole during machining will contribute greatly to the resonance created during cutting. Even on a production machine a long flute cutter in hardwood will howl like a wild animal and leave some mild undulations in the surface finish. Hard to quantify, but the relative size, weight and secureness of the material could be some possible parameters which have some input into the cut depth and spindle RPM.

@JensDyvik
Copy link
Member Author

Thank you for the input Mike! I agree with you that tool sickout, material density, part hold down/fixturing strength and part integrity would be great (and sophisticated) to take in into account in the auto settings. So far we have approached the challenge of these variables by having slightly conservative auto settings. This is not ideal, since it slows overall productivity. But the slider that allows for fast tweaking of the autosettings have been great and at least allows for fast compensation of long tool sickout or weak fixturing:

image

I am uncertain about what would be the best way to approach getting the necessary data into Bark Beetle with minimum effort for the user. For advanced machining centers with toolchange, I guess the data of the tool sickout could extracted from machine control (with compatibility and protocol challenges I guess). But for cheaper machines I dont know. Do you have any thoughts?

We have discussed earlier about auto calibration through having the cnc mill mill sample nibbs out of the stock and analyze with sensors (vibration and pressure). But thats a huge physical computing project on its own.

@mikeFandA
Copy link

No problem, happy to help! The material qualities could be an optional input to give faster cutting, so if the user doesn't input anything it defaults back to the conservative settings. Overall that would need a fair bit of experimentation and tweaking, but even the high-end softwares like Powermill and MasterCam require you to build functional data dependant on your setup. SO could be a could space for a community page for people to share their experiences of what works and not.

An easy way for tool depth is like you say to use a simple sensor and pull the data through the machine control, but that's pretty heavy on the grasshopper interface. One way would be to build a tool profile as you would on Powermill for example, where you do a 2d model of your tool properties for the software. The most straightforward way is to use a depth gauge, but they could also home the machine and use a clock to measure the travel, or perhaps a set of 3D printed gauge blocks. With that last method after you home your machine with your selected tool you just slide in the blocks and add up the total and pop it in, don't need to be printed of course could be bits of ply or whatever nominally reliable material you have lying around. Its an indicative value after all, I'll have a think about something a bit more clever.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants