Current Status
The bulk of my time has been spent on trying to get a good toolpath coverage when both waterline and parallel finishing are being used. This turned out to be difficult to calculate quickly and accurately- the two characteristics always oppose one another. After trying about six different approaches I think I’ve got a good approach. The photo below shows the current status. You’ll see that there is some overlap between the two but there is very little “spiking” near the threshold like the previous versions.
In the course of doing this I’ve made a number of decisions that will probably cause controversy. The photo below shows one such case..
Older versions of MeshCAM would have cleared each top separately and then gone to the flat bottom. The new version sees each surface as a connected flat surface and machines them all together. This is the biggest change in the toolpath algorithms- the way that surface angles are classified. I can make it more like before but there will be the tradeoff of accuracy and speed. Comments are welcome but the photos above show what will be in the next release that I’ll post here (not on the main download page).
I’ve moved on to the pencil machining for now. This should go quickly- maybe a week- and will totally eliminate the ZMap from all finishing toolpaths. It’s been a long path but it’s finally coming to a point where it can be shared in a more public release.
Comments
5 Responses to “Current Status”
I personally didn’t like how Meshcam flitted about before, I’d have prefered it to machine all one level and then move down to the next anyway.
From the look of the picture there is a total overlap of cutting on vertical surfaces between parallel and waterline (or is that what you were meaning?)
Anyway it’s looking good and I can’t wait to try it out.
Steve
I never liked the “flitting” before either but I never felt like I had enough resolution in the toolpath information to make it cleaner. Now that I’ve reimplemented it I see how it could have been improved but that’s in the past now.
The total overlap above is the worst case and would not occur on a more sculptured surface like the shot above it. There will almost always be more overlap than before since the new methods are “greedy” - they expand to cover all the area that could be considered their domain. Some of the transition areas between the waterline and parallel contain areas that both algorithms will try to machine to eliminate little spikes that were there before. The simulations that I’ve run in CutViewer show a much improved surface finish compared to previous versions- even in the transition areas.
Looking mighty good, Robert! I like the goodly overlap between waterline and parallel. How will you handle the switchover in the machining dialog?
And I really like the way you are keeping the cutter on the surface in the second screenshot.
I’ve been using 6628, and really like the parallel finishing. I was planning to post some results of varying the triangles on a test piece, but had some machine problems (the Z motor started slipping, but only about .00005″ on each Z-axis move so it only showed up with a lot of contouring moves, exactly what I was generating…) so all my test results were invalidated. I will redo them now that I’ve fixed the machine.
Do you plan to keep the oversampling parameter for roughing, or will that eventually go zmapless too? As it is now, I am generating the roughing toolpath independently of the finishing, because I’ll set a 15 oversampling with a, say, .15″ stepover for roughing just to get smoother toolpaths, but if I do the finishing in the same calculation the oversampling freezes the PC when it does the “legacy” zmap.
Best regards,
Randy
The oversampling will be changed to a quality slider for roughing that would represent an oversampling range of 3-20 since the roughing requires a minimum of 3 ( It happens under the covers if you put a lower number in). Since roughing stepovers tend to be larger I think upping the maximum to 20 would not lead to out-of-memory problems and would let people like you get really nice toolpaths. If I do this I think I can remove any trace of a mention of a ZMap from the documentation and simplify the process for new users.
On a longer time line I can combine the new waterline and the pocket code I write a few months ago to write a totally new roughing system. It’ll be a while before I’m confident enough in the new system to attempt that.
Right, so that’s a worst case situation. Don’t get me wrong, I think it’s great and with an I’ve no problem with tool paths overlapping as that’s the best way to ensure a good transition.
I see on the top picture it’s overlapping because the toolpath is being kept as a continuous path rather than stop start which like you said should be faster and smoother.
Steve