Adaptive Path/CAM Operation

[JulianTodd]

As you've asked so nicely, I'll try to explain it. Even though I'm really bad at drawing in Gimp.

engage2.png (50.79 KiB) Viewed 2006 times

I usually thought of cutting width (as a proportion of the tool diameter) instead of cutting angle. Then the cutting width multiplied by the cutting length equals the cutting area, because the circular curve at the start and end of the area is the same. So you are calculating the same thing, but in a more complicated way.

It's okay for the cutting width to vary within a tolerance. You can probe with a straight line segment from the circle of the cutter a small distance in from the point of engagement pointing in the direction of travel, and find where it enters uncut stock. This is where you must have your the next sample.

This protects from over-cutting the stock. But you also need to take smaller steps (and turn to the right) when it is undercutting stock, but this is not so important. You are free to control the turning radius when going to the right, because in high speed machining it's better to undercut the stock than to make a sharp change in direction. Playing these two factors together, it's possible for it to nearly always pick the optimal step at each point and rarely have to resample.

We should talk about C++ and python and stuff, and maybe you can call me sometime if you like. I developed this algorithm for about 10 years on and off, so we can discuss how to future-proof its structure, with toolpath reordering, etc. You seem to have got ahead on the linking part, as we had a very difficult time working without any model of the cleared area (we could probe it with circles and lines, but didn't have an area model). See here for how much trouble we had: https://www.freesteel.co.uk/wpblog/2014 ... g-motions/

I'll see if I can set up Visual Studio, but I don't think I want to do C++ for pleasure after 20 years at it. I am pretty sure, like all heavy CAM algorithms, it should run outside the main process. Most commercial CAM algorithms are run by saving the triangles and boundaries to a file and starting up a separate process. It can communicate progress and results through the stdout or a socket stream. This means they don't bring down the whole CAD system when they crash, and are easier to test and debug in isolation. And for future proofing, it meant it could be distributed to the cloud and potentially run instantaneously if separated well enough. It's too difficult to develop code like this when it is behind a huge UI that needs to be booted up at every iteration.

[jbi]

I am not an user of the Path or Adaptive Path workbench, but would it be possible to limit the g-forces on the path?
So considering each axis acceleration/deccelartion limits of the milling machines and optimizing the toolpaths (also generating toolpaths which have as less as possible rapid moves) for that. I have already seen a paper and I think they were talking on 2nd? order bsplines as toolpaths. I am not sure if such feature exist in commercial CAM programs, but it would definitly lower the requirements on the machines, or give heavier older machines nearly the same material removal rate than newer high speed machining centers. Something like this http://www.mmscience.eu/archives/MM_Science_201219.pdf. Maybe this would broaden the interest on Path/Adaptive Path and FreeCAD in general also for industrial usage.
I have already seen big machines machining 3m diameter parts jerking around at high speed and the only reason for that I can imagine are bad toolpath generating strategies.

[JulianTodd]

G-forces are determined by the minimum curvature radius. This means that splines -- although they look good to the eye -- are inefficient because they have a minimum curvature radius at a single point. The most efficient toolpath (from the point of view of G-forces) is made from a sequence of circular arcs and straight segments that always join tangentially. Then you always know what the curvature is. I have recently worked out the mathematics for fitting arcs to toolpath curves: https://www.freesteel.co.uk/wpblog/2016 ... done-easy/

Controllers also have a turning limit and will automatically fit arcs between two segments that are long and colinear (short little segments break them). The algorithms they use are not available. If they were, we would be able to tune the toolpaths to work better for them.

Changing the toolpath position (by smoothing it) cannot be done safely as it can create gouges. It is especially dangerous when you have a series of passes that are very similar (like waterline slices or raster/parallel finishing passes), where the smoothing function can suddenly fit in a larger radius than the pass next to is for a slight change in shape. This causes unpredictable unevenness along the surface, and also gouges of the stock where suddenly a lot of metal gets cut on the next pass. The safest way to avoid these is to apply a protection fillet to every corner in the pocket which is a few millimetres larger than the radius of the cutter.

[jbi]

I was thinking on adaptive roughing toolpath generation minimizing energy consumption (doing as less as possible acceleration/deccelartion) while maintaining high material removal. Mabye a combination of commonly used offset toolpath but with optimized curvatures and constant engagment angle. Just some thoughts of mine. I do not want to hijack this valuable thread or topic, and may this is already discussed somewhere else.

[kreso-t]

As you've asked so nicely, I'll try to explain it. Even though I'm really bad at drawing in Gimp.

engage2.png

I usually thought of cutting width (as a proportion of the tool diameter) instead of cutting angle. Then the cutting width multiplied by the cutting length equals the cutting area, because the circular curve at the start and end of the area is the same. So you are calculating the same thing, but in a more complicated way.

It's okay for the cutting width to vary within a tolerance. You can probe with a straight line segment from the circle of the cutter a small distance in from the point of engagement pointing in the direction of travel, and find where it enters uncut stock. This is where you must have your the next sample.

This protects from over-cutting the stock. But you also need to take smaller steps (and turn to the right) when it is undercutting stock, but this is not so important. You are free to control the turning radius when going to the right, because in high speed machining it's better to undercut the stock than to make a sharp change in direction. Playing these two factors together, it's possible for it to nearly always pick the optimal step at each point and rarely have to resample.

We should talk about C++ and python and stuff, and maybe you can call me sometime if you like. I developed this algorithm for about 10 years on and off, so we can discuss how to future-proof its structure, with toolpath reordering, etc. You seem to have got ahead on the linking part, as we had a very difficult time working without any model of the cleared area (we could probe it with circles and lines, but didn't have an area model). See here for how much trouble we had: https://www.freesteel.co.uk/wpblog/2014 ... g-motions/

I'll see if I can set up Visual Studio, but I don't think I want to do C++ for pleasure after 20 years at it. I am pretty sure, like all heavy CAM algorithms, it should run outside the main process. Most commercial CAM algorithms are run by saving the triangles and boundaries to a file and starting up a separate process. It can communicate progress and results through the stdout or a socket stream. This means they don't bring down the whole CAD system when they crash, and are easier to test and debug in isolation. And for future proofing, it meant it could be distributed to the cloud and potentially run instantaneously if separated well enough. It's too difficult to develop code like this when it is behind a huge UI that needs to be booted up at every iteration.

Thanks.

I've executed again the performance analysis on my code and it turns out that "calculating cut area" actually takes less than 50% of the total processing time with the current version, so performance gain would not be all that great as I hoped by changing it to simpler way (at best would be 2 times faster if simpler method of area calculation would take no time at all - which is not likely), and it would require considerable efforts to change it now (integration with the remaining code, fine tuning and polishing again etc). Accuracy and reliability of the algorithm, as it is, seem to be good so I don't expect the results/output would be better. Considering all that I decided to leave it as it is for now. The rest of the stuff you do seem to be similar to what I am doing, what you call "sampling" is actually very similar to what I call "angle vs area iterations" using the successive approximation + linear interpolation to get fast convergence to the correct angle. In my case the initial sample is also guessed correctly in most of the cases (more than 50%) and when not, it usually takes only 2-3 resamples/iterations to correct it.

About running the alg. outside the main process - I don't see a big problem with that, since this algorithm does not have complex external interface/API and does not have many dependencies (only the clipper lib and C++ standard libraries), it is not that much of a problem to wrap it into separate host process or add some different bindings (i.e. to adapt it to be used as nodejs module, host it as a HTTP service accessible via HTTP/JSON or SOAP API, or even add a COM wrapper, etc.). It is integrated into FreeCAD as in-process component since this is the way FreeCAD works with Path operations.

[schnebeck]

HI,

when milling a part with Adaptive Op a few days ago I noticed a tessellation effect on a larger rounded contour. I know there is this slider to choose between accuracy and speed but I only need more accuracy for this final profile path. Is it possible to use the global path config accuracy settings for this final profiling path?

Bye

Thorsten

[dubstar-04]

HI,

when milling a part with Adaptive Op a few days ago I noticed a tessellation effect on a larger rounded contour. I know there is this slider to choose between accuracy and speed but I only need more accuracy for this final profile path. Is it possible to use the global path config accuracy settings for this final profiling path?

Bye

Thorsten

Hi Thorsten,

Tesselation artifacts are expected with adaptive strategies as they are aimed at roughing.

Normal work flow would be to follow the adaptive operation with a finishing operation to clean up.

Thanks,

Dan

[schnebeck]

Hi Dan,

Freecads Adaptive-Op includes a finishing profile operation.

Bye

Thorsten

[kreso-t]

Hi Dan,

Freecads Adaptive-Op includes a finishing profile operation.

Bye

Thorsten

I could probably increase the accuracy just for the finishing part without affecting the overall performance. I'll see what I can do.

BR,
K.

[kreso-t]

Hi Dan,

Freecads Adaptive-Op includes a finishing profile operation.

Bye

Thorsten

I could probably increase the accuracy just for the finishing part without affecting the overall performance. I'll see what I can do.

BR,
K.

Can you provide some images or additional info about the tessellation effect you are seeing? Currently with default settings finishing path should be accurate up to 12.5 um what should be better than the accuracy and resolution of most hobby machines (i.e. 200 steps per revolution stepper motor and 1605 ball-screw, without counting micro-stepping which is usually not very accurate). I tried to confirm it by increasing the tessellation settings in the FreeCAD Part Design module to the point that is takes like half minute to draw simple cylinder on the screen and then under large zoom try to measure the max error of the adaptive finishing path (using a sketch) against it, and I get about 13um i.e.:

Selection_057.png (9.09 KiB) Viewed 1832 times

(these lines are actually part of 45mm radius circle)