[Feature idea] Smart adjustor of tool speed

[taras-ko]

By milling some oak I broked many carbide mills (R0.5 carbide each for 2-3$).

So I've beign thinking how to reduce breakage 'flow' of my instruments. And I want to know your opinion on that.

Idea of "smart" :) tool speed adjustor.

Well. This algorithm should 'know' how much material tool is cutting in any node its toolpath. Suppose we will measure this parameter in percentage of tool cutting surface (tool cutting load)
For example (for cross strategy.):
100% (cutting load) - tool is plunging into the cutting material

As I know plunge speed adjustion is already implemnted in blendercam.

100% (cutting load) - tool is cutting the first furrow (or line. If it's a correct translation)

It seems tool speed here should be equal to plunge speed.

50-70% (cutting load)
1st half of a Cross toolpath.

The second half of a Cross toolpath has the minimum cutting load (10-20%)

Here we can cut the material at a full speed

I think cutting point percentage can be found based on detecting of intersection of tool object and generated simulation mesh.
Here is a sketch of an idea. I know that's not easy to implement, but I just wanted to share the idea for future development. Thanks.

[ghost]

I know there are some high end cam packages that have this feature and it would be nice if we could implement this in Blendercam.

The work around I use is to do roughing passes with larger, stronger bits until there is only about 0.020" (0.5mm) thickness left in the final passes. Then I use the finishing bit at a much lower travel speed and adjust the rpm to get a proper chip load. Another thing I do is check the tool path direction with the grain of the wood especially with hardwoods. I use climb cutting instead of conventional for the final finish passes because there is much less side load on the bit and there is much less tear out.

Lots of guides on the internet. I like Onsrud's routing guide, it has some good tips:
http://www.onsrud.com/files/pdf/LMT-Onsrud-CNC-Prod-Routing-Guide.pdf

[taras-ko]

Thanks for tips!

[vilemduha]

Hi guys, not sure if you are aware of that, but we also have this feature allready :)
It's called 'adjust feedrate by simulation', and it happens automatically when you simulate and re-export the path.It's not much tested and could use some love though, but just to give you some hints:

The simulation is currently image based. Each simulated vector computes how much of an depth image is eaten. This load information is then transferred into a shape key of the mesh(because storing arrays on the mesh is limited to 32k length) This has an advantage too - you can preview the adjusted speeds when switching to this shape key. It could probably use some smoothing (only downwards regarding speed.

[ghost]

Was not aware of that. Time to play and then Wiki time.

[ghost]

Ok, I had seen the code for this in exportGcodePath() but didn't realize I had to run the simulation after the operation calculation then do gcode export. Also didn't realize that the simulation was doing the feed adjustment although should have when looking at the code.

Just tried it out and it works although haven't actually cut anything using the resultant g-code.

[vilemduha]

I actually tested it very few because i didn't have much time for that. Best to do some tests 'in the air' first.

[ghost]

Yep, doing that now...

[ghost]

I have had a lot of fun playing with this. Vilem has done a nice job in implementing this. Can't believe its been there all this time and I never really noticed it.

I have done some simple tests and some air cutting. Looks good so far. Tomorrow I will do some actual cutting in some scrap spruce.

I like how the load is placed in the shape key y axis, x axis is relative position in path, and z axis is the feed reduction. Its fairly easy to set up a plot to see the tool load and the corresponding reduction in feed rate. Here is a plot of one of my tests:

The top graph is the feed rate reduction, a value between 1.0 and 0.0. A value of 1.0 means there is no feed reduction, 0.5 is 1/2 feed reduction (half feed rate).

The bottom graph is the load on the tool based on the volume of material the tool has to cut at that position. You can see how the feed rate reduces when the load increases above a certain threshold.

[taras-ko]

Wow! This is a "top secret" level knowleges.

Пользователь vilemnovak [email protected] писал:

Hi guys, not sure if you are aware of that, but we also have this feature allready :)
It's called 'adjust feedrate by simulation', and it happens automatically when you simulate and re-export the path.It's not much tested and could use some love though, but just to give you some hints:
The simulation is currently image based. Each simulated vector computes how much of an depth image is eaten. This load information is then transferred into a shape key of the mesh(because storing arrays on the mesh is limited to 32k length) This has an advantage too - you can preview the adjusted speeds when switching to this shape key. It could probably use some smoothing (only downwards regarding speed.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[taras-ko]

Wow! Again.

Пользователь Jeff Doyle [email protected] писал:

I have had a lot of fun playing with this. Vilem has done a nice job in implementing this. Can't believe its been there all this time and I never really noticed it.
I have done some simple tests and some air cutting. Looks good so far. Tomorrow I will do some actual cutting in some scrap spruce.
I like how the load is placed in the key frame y axis, x axis is relative position in path, and z axis is the feed reduction. Its fairly easy to set up a plot to see the tool load and the corresponding reduction in feed rate. Here is a plot of one of my tests:

The top graph is the feed rate reduction, a value between 1.0 and 0.0. A value of 1.0 means there is no feed reduction, 0.5 is 1/2 feed reduction (half feed rate).
The bottom graph is the load on the tool based on the volume of material the tool has to cut at that position. You can see how the feed rate reduces when the load increases above a certain threshold.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[vilemduha]

Sorry for hiding this :) i wanted to do more tests of this and never found the time to do that...

[taras-ko]

I just thought that our discussion and all other issues listed here is a good wiki how to use blendercam. For newbies is much more helpful to read here than an outdated regular wiki

Пользователь vilemnovak [email protected] писал:

Sorry for hiding this :) i wanted to do more tests of this and never found the time to do that...
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[ghost]

So, this is basically the same as #45 except its done by the simulation instead of the user and the info is store in a shape key instead of the crease data of the mesh.

[ghost]

Some how I missed the last two comments by Vilem in #45 where he spells out how this is already done or at least implemented but not well tested.

[vilemduha]

And as you mentioned it - I also think something like edge creases is a great way to visualise the load which we are after- However it would be best if visible in the Object mode, in Editmode it is a problem because of big paths...

[vilemduha]

just commited an addition where edge creases are also used-just for visualisation.
Jeff, I am very curious about your milling experiences, how this works. i thought maybe some kind of smoothing will be needed. Also, the results are dependent on simulation quality currently...

[vilemduha]

just also changed the way this gets used.
before it used a fraction (0.5) of the maximum load.
Now it uses the averaged load as a limit, anything with load larger than that will be slowed down. Max value of slowdown is 0.1, because slow speeds cause overheat on the other side. All this should be configurable in the interface probably?

[ghost]

The two simple examples I cut today went okay. Spindle RPM was too high when there was a feed reduction to 50% as I got some wood burning in that area. I may look at reducing spindle rpm when feed reduces in order to maintain chip load. Will make this a user selectable option. I did make the threshold (default=0.5) and minimum feed reduction (default=0.4) as ui properties for the simulation so I could play. Maybe useful for others.

Since the load calculation gets averaged over 10 iterations, the feed rate change is not to bad. No big jumps or drops but my tests were simple.

Its too bad vertex colour does not work for mesh lines any more. Back in 2003 I used to use that feature. If I duplicate and then extrude the path mesh in the vertical I am able to use vertex colours. I may try hard coding this and have it generate the load/feed mesh after the simulation. Will post a pick when I get it looking right.

[ghost]

ok, will try a merge.

[vilemduha]

Jeff, because you are also testing, I will not touch this code anymore now - feel free to adjust things as comfortable and usable as you wish.
Regarding Vertex coloured mesh, I thought exactly the same way, because now it's the only way. If maybe colours would be possible for curves, then curves could become optimal for storing CAM paths..

[ghost]

Continue touching the code :). I am still playing and not sure where I am going with this.

Here is the load mesh using vertex colours if the user selects "Generate load mesh" in the simulation options:

Green is a load below minimum load threshold, yellow is just above threshold, orange is about 75% max load and red is max load. I was going to represent feed rate as vertical height but still toying with it.

[vilemduha]

Niiiiice! This is really looking as it should :)
I'd suggest maybe rather extrude the new vertices perpendicular to the path vector(either in Z plane or X plane of each vector)
maybe feedrate could be simply another vertex color channel? Thickness might be also good, let's see :)

Well, the question is how we merge stuff afterwards if we both work on same part of code :)

[taras-ko]

Very impressive! I want to share some thoughts with you. We also can add the notion of tool wearing and tool profiling. For example. As I know carbide tool is losting its sharpness lineary depending on type of cutting material. So here we can add couple params for each tool: 1 - tool wearing measured in volume of cutted material. 2 - tool sharpness measured in percents. Also each tool path should have type of material to be cutted.
Well, ok. We have a new carbide spherical mill. Suppose I want to cut many oak wood. So I can cut it with full speed. We can get this speed from technical data sheets. When my tool became blunt, so its sharpness will be 50% I denefinitely shouldn't cut it on the full speed. So overall maximum tool speed will decline while cutting.

Пользователь Jeff Doyle [email protected] писал:

Continue touching the code :). I am still playing and not sure where I am going with this.
Here is the load mesh if the user selects "Generate load mesh" in the simulation options:

Green is a load below minimum load threshold, yellow is just above threshold, orange is about 75% max load and red is max load. I was going to represent feed rate as vertical height but still toying with it.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[taras-ko]

Hi, guys. Back to the discussion.
I tested "Adjust feedrate with simulation" feature and it works! Yep, it decreases feedrate according to tool workload. But there need to add one extra property control for this feature.

As you can see, algorithm did feedrate adjustments. On the "hardest" toolpath areas 'crease' parameter has been modified from 0.0 to 0.30-0.35 and feedrate has been downshifted accordingly (I guess by 30-35% percents of default feedrate).
It's not enought for my type of material (oak). I need to downshift feedrate on these toolpath pieces by 70-80-90% . As can be seen from the picture above I changed the crease parameter to be more 'bright magenta' color, and it's my preferable value on such pieces of toolpath.
So I think we need to add an option which will set the crease/tool workload "override function" (linear, exponential, logariphmic etc) for this feature.

What is your suggestion on that? Thanks.