-
Notifications
You must be signed in to change notification settings - Fork 118
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
[Feature idea] Smart adjustor of tool speed #69
Comments
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: |
Thanks for tips! |
Hi guys, not sure if you are aware of that, but we also have this feature allready :) 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. |
Was not aware of that. Time to play and then Wiki time. |
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. |
I actually tested it very few because i didn't have much time for that. Best to do some tests 'in the air' first. |
Yep, doing that now... |
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. |
Wow! This is a "top secret" level knowleges. Пользователь vilemnovak [email protected] писал:
|
Wow! Again. Пользователь Jeff Doyle [email protected] писал:
|
Sorry for hiding this :) i wanted to do more tests of this and never found the time to do that... |
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] писал:
|
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. |
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. |
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... |
just commited an addition where edge creases are also used-just for visualisation. |
just also changed the way this gets used. |
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. |
ok, will try a merge. |
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. |
Niiiiice! This is really looking as it should :) Well, the question is how we merge stuff afterwards if we both work on same part of code :) |
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. Пользователь Jeff Doyle [email protected] писал:
|
By milling some oak I broked many carbide mills (R0.5 carbide each for 2-3$).
![img_20160607_195028](https://cloud.githubusercontent.com/assets/1148481/15866980/c42f1990-2ce9-11e6-9092-b162164eaa34.jpg)
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)
![100_load](https://cloud.githubusercontent.com/assets/1148481/15833009/6296c19a-2c2d-11e6-841d-55f8c8a75ba1.png)
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)
![1st_furrow](https://cloud.githubusercontent.com/assets/1148481/15833345/14bb3ec2-2c2f-11e6-9c48-f918db25d1b5.png)
It seems tool speed here should be equal to plunge speed.
50-70% (cutting load)
![2_nd_furrow](https://cloud.githubusercontent.com/assets/1148481/15833539/f0030168-2c2f-11e6-8e1f-193eb3fe0d4d.png)
1st half of a Cross toolpath.
The second half of a Cross toolpath has the minimum cutting load (10-20%)
![back_movemnt](https://cloud.githubusercontent.com/assets/1148481/15833680/825d6260-2c30-11e6-8841-953f4be9aa07.png)
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.
The text was updated successfully, but these errors were encountered: