Hi,
I want to mill pockets effectively with minimal overlap. But I can select any pocket method - there will be always some regions which the mill doesn’t reach.
I have to set the “step over” value to 50% to reach everything. Even a 60% value isn’t enough. What I’m doing wrong?
Does anybody else have that problem?
Best Regards,
Hans
Yes, this can happen. I am afraid the only solution at the moment is to use a smaller stepover.
Are you working on a solution?
I have tried several ideas but I haven’t yet found a reliable solution.
You have added several very nice features like simulation and so on. So I can’t really imagine that it would be a problem for you to to find a solution.
What a pity that it’s not an open source project. So I can only offer you my help and support!
Unfortunately I can’t really afford to open source SheetCam. It’s my main source of income. However I am thinking of retiring in the next few years. Open sourcing SheetCam at that point is one of the options I am considering.
What do you think of providing the functions that include the pocket algorithms so that me or other users can help to fix this?
Recently I Just wanted to mill a rectangular zig-zag-pocket with minimal overlap. No chance! I don’t how, but your algorithm manages that always some rest material is being left. I simply can’t understand why that simple task is so erroneous. Just a little gcode script would do this better.
In my company we are thinking of buying some CAM software. When I only cut contours I really liked the software. But now when I am milling pockets I get annoyed that a bought this piece of software. Unfortunately in this stage I can’t recommend it.
One solution that I think of is to to try one extra pass on spiral pocket that has a 50% overlap after you cant fit any more passes with overlap over 50%.
Or pretend the the cut along the outline is centered over the outline when doing the zig-zag part if overlap is over 50%
Unfortunately I can’t do that. Pocketing is not really a standalone piece of code. You would need access to most of SheetCam’s internals to make any sense of it.
Recently I Just wanted to mill a rectangular zig-zag-pocket with minimal overlap. No chance! I don’t how, but your algorithm manages that always some rest material is being left. I simply can’t understand why that simple task is so erroneous. Just a little gcode script would do this better.
A generic pocketing algorithm that can handle any shape you throw at it is surprisingly difficult. As you say, for a simple rectangle it would be pretty trivial to do it in a script. However it all becomes a lot more difficult when faced with arbitrary shapes. By the way, for a simple rectangle you may be better off using a facing operation followed by an inside offset to clean up the edges.
Or maybe you can do a distinction of cases. If shape == rectangular then do a simple algorithm that works with bigger overlaps. That’s may no good style but I think rectangular pocket appear quite often.
And a post check whether material is remaining would also be helpful. So there would be no need for manually checking this.
A workaround could be to specify the maximum overlap and let the program find the biggest value for overlap where all material is being removed.
Only decrement the overlap in a loop starting at the specified maximum value down to the value where all material is removed.
I need to take another look at pocketing. I’ll see what I can do.
But that’s what I wanted to avoid if I understood you right.
But then my pocket will be to big or how do you mean it?
Thank you, I really appreciate that!
Sorry for the confusion. That was just some suggestions aimed to the developer, Les. Not very well thought out.
Hope not to get too much on your nerves with my pockets.
But lately I was milling wood and I was wondering if it is possible to optimize the trajectory.
I simplified the part to make it clear. The left hand pocket part is machined from inside (1) so outside what is good. But the right hand part is machined from outside (2) to inside (3). This leads to breaking of the last remaining piece of material in the middle.
Can that behaviour be improved by e.g. path rules or similar?
If not you may could have it mind while refactoring the pocketing algorithm…
The spiral pocket does it’s best to avoid doing a blind plunge into the work. It tries to start on edges so there is more room for the chips to clear.
Point 2 is an edge while point 3 is not. As far as breakout is concerned, starting at point 3 would potentially be worse. When it finishes cut 3 it will now be cutting a thin unsupported vertical wall which would be pretty likely to break off.
The next release will have a shiny new zigzag pocketing algorithm that is good for step overs up to 95%. I’ve been working on it flat out for the last week and it’s now looking pretty good. I’ve been putting some time into trying to break it and so far every test drawing I’ve thrown at it has been filled with no missed areas at 95% step over. I’m aiming to get the release out in the next few days.
As far as breakout is concerned, starting at point 3 would potentially be worse. When it finishes cut 3 it will now be cutting a thin unsupported vertical wall which would be pretty likely to break off.
Yes you are right I didn’t think about that.
But a solution would be to cut first 3 then 2 and then go to 1 and machine all remaining from there.
The next release will have a shiny new zigzag pocketing algorithm that is good for step overs up to 95%. I’ve been working on it flat out for the last week and it’s now looking pretty good. I’ve been putting some time into trying to break it and so far every test drawing I’ve thrown at it has been filled with no missed areas at 95% step over. I’m aiming to get the release out in the next few days.
Very suitable to Christmas. Great!
Please tell me if you are just prior to release it. Then I will send you my current state of the german translation file
But a solution would be to cut first 3 then 2 and then go to 1 and machine all remaining from there.
Yes that would work but it means two blind plunges, which the algorithm tries to avoid. In many cases this approach would also increase the number of rapid repositioning moves.
The zigzag pocket doesn’t have this problem. You never end up with unsupported areas unless they are in your drawing. Even then it supports them as much as possible until the last cut pass.
Assuming the rest of my testing goes well I hope to release an update today or tomorrow.
The new release has a new zigzag pocket operation ‘Zigzag pocket 2’ which uses the new algorithm. Give it a try and see what you think.
If it works out this will replace ‘Zigzag pocket’.