I’m using the 3dSurface function to rough out a contour shape with multipass and the offset cutting pattern. The attached model and photoare just a small model to illustrate the problem. The actual piece I want to mill is much bigger (approx 80cm long) I’m using a 16mm end mill for the roughing stage which doesn’t cut in the centre part of the cutter so ramp in is essential for the start of all new cuts.
As can be seen in the photo, the ramp entry dressup doesn’t get applied above the first step down level. Is there anyway to correct this or does someone have a suggestion for a workaround?
Evening,
Looking at the example image you provided, I suggest manually creating a set of 3D Surface ops & Ramp Entry dressups, one set per step down. The first op will be Start Depth with Final Depth set to first step down level, with RE dressup added. Second op will use Final Depth of previous op as Start Depth, and the second step down level as its Final Depth, with RE dressup added. Continue this process for each step down you have. Just a suggestion.
Cheers,
Russell
OS: Windows 10 build 19045
Word size of FreeCAD: 64-bit
Version: 0.22.0dev.35639 (Git)
Build type: Release
Branch: main
Hash: f315314569aee5334fd0e69a49aab33684a802ba
Python 3.10.13, Qt 5.15.8, Coin 4.0.2, Vtk 9.2.6, OCC 7.6.3
Locale: English/United States (en_US)
Installed mods:
* FC_SU
* freecad.gears 1.0.0
* freecad.pathred
* Z_MacroStartup
Thank you Russel for your suggestion, sorry it taken me so long to reply, I’ll have a play with those ideas to see if it helps. The only thought I had with the suggested strategy is that the cut on each layer will go over already cut material with each layer?
Evening.
I wrote a script to test the idea I presented in my previous post, but the outcome was not as expected. This led me to some manual testing of the 3D Surface operation. My testing suggests that there is a bug related to the application of the StartDepth on the paths generated. As I lower the StartDepth value toward the FinalDepth value, I would expect the higher paths above the StartDepth value to disappear. This is not occurring in my tests. Given this information, I do not suggest trying the idea because the bug renders the idea ineffective.
Cordially,
Russell
OS: Windows 10 build 19045
Word size of FreeCAD: 64-bit
Version: 0.22.0dev.35639 (Git)
Build type: Release
Branch: main
Hash: f315314569aee5334fd0e69a49aab33684a802ba
Python 3.10.13, Qt 5.15.8, Coin 4.0.2, Vtk 9.2.6, OCC 7.6.3
Locale: English/United States (en_US)
Installed mods:
* FC_SU
* freecad.gears 1.0.0
* freecad.pathred
* Z_MacroStartup
Russell, I can confirm your test, with a start depth lower than the top of the model, the top of the model still gets cut.
There is in any case, some strange behaviour occurring with the 3d surface function. On my attached model, large inefficient loops that are raised to some kind of ‘safe’ height are generated to move the cutter over already cut material instead of moving in a straight line to the next position to be cut. The worst thing about these loops is that they end up in the G-code as G1 moves and not G0 moves. The Height of these loops in the final G-code is neither the set safe height nor the clearance height set in the 3d surface settings. (for reference, safe height is set to 11.034mm, clearance height is set to 13.034mm, height in the g-code of the loops 12.000mm, maximum height of the model 8.034mm).
It seems this function needs considerable work to not only get it working properly, but to improve the efficiency in calculating paths. The attached model is just a test model to demonstrate the problems, the actual model I wish to mill is much larger and even with the tolerance settings relaxed, each calculation is taking over half an hour. Any thoughts on what a solution to this might be, both short term and long term?
As a work around for the inefficient loops, I thought about writing a script to go through the generated g-code to find the blocks of G1 moves that have a Z height of 12.000mm and remove those moves between the first and last, change the Z height to clearance, then make both of them a G0 move. This still doesn’t solve the problem of the lack of lead in in certain areas.