More Pocketing
April 12, 2007 · Filed Under MeshCAM Development
I got the island code working pretty well. It took a while since I went back to clean up some of the hacked-together test code that I wrote earlier. Islands only took a couple dozen lines of code but they aren’t totally worked out yet.
The shot above shows one of the outstanding problems where a pocket, in purple, and an island, in red, nearly coincide. This case causes some problems currently but I don’t expect much trouble resolving it.
Comments
7 Responses to “More Pocketing”
Robert, the roughing in 5934 is already looking pretty good. I have not had as much time to play with it as I would like (I’m currently “on loan” to another division of my company and my commute time is 2 hours each way…) but the code is looking good on the “real world” models I’m working with.
On this blog entry, I don’t understand the second illustration. There is the same purple pocket outline as the first illustration with the small square island, but there is a second red square that intersects the purple pocket outline. What is the physical meaning of this? Are the red and purple outlines at different Z depths (in which case there are undercuts anyway)? I see that the outer red square has toolpaths offset to the outside. If it is intended to be an island, what is its enclosing pocket?
I’m glad that the current roughing is working well. I hope to be able to add the pocket roughing as another option in the near future.
You caught me- the second model can’t really happen in a physical part since you can’t have an island within an island without another pocket contour in between. However, the algorithm though should handle it fine if it was working correctly. The offsets outside the bigger red square are invalid and should have been trimmed away. I can’t say I know why it’s happening but it shouldn’t be a big problem.
Robert, the large red square isn’t an island of the purple pocket since it overlaps the purple polygon. So the triangular portion of the large red square that is outside the purple polygon has a winding number of 1, the portion of the purple polygon outside the red square also has a winding of 1, and the overlapping part of them has a winding of 2. So the pocket is the union of the large red square and the purple polygon. The only island is the small red square. That is, if I understand your link on winding numbers and offsets correctly.
You’re correct - I’m using the term “island” more loosely as a way to denote a region that should not be cut. The method I’m using is made up of boolean operations on polygons rather than the exact method outlined in the paper. The winding number calculations do happen but they are embedded within the polygon library that I’m using when I call for a polygon union or intersection. I prefer to make the algorithm robust against all cases- even those that should never happen- because you can never predict that odd cases that can occur in real world use. Things that can “never happen” do end up happening because of floating point calculations that get rounded in ways you don’t fully control.
There’s been a lot of interest I’ve received on this topic so I may end up writing something up when I’m done since, so far, this seems to be the easiest way to implement such an algorithm.
OK, that sounds good, Robert. Dare I ask whether the concept could also be used to enforce “machining regions” (i.e. machine only within the boundary or machine only outside the boundary) that might be defined on-the-fly (like the supports in your two-sided machining?)
Another roughing item that would be very nice, would be to make sure that the outer perimeter of a part is roughed all around, when the stock boundary lies less than a cutter radius outside the part boundary. As it sits now, I need to lie to Meshcam to make sure that the stock is at least [one cutter radius one roughing stepover stock to leave] larger than the part on all sides before Meshcam will rough the whole part perimeter. That goes for finishing too as it is now, in my experience.
oops, that was supposed to be [one cutter radius plus one roughing stepover plus stock-to-leave] but the plus signs got filtered out…
I put some code in there a while ago for the machining regions but I’ve never written a proper UI to let people define them. The problem in my mind is that once you let people define a region they’ll want or need to define multiple regions. Then they’ll need to define different machining operations for each region. This is all good stuff that I would love to add but it really changes the UI and potentially the target market for MeshCAM which, up until now, has been the users who are new to machining and need a simple interface or people who want to generate a toolpath quickly without a half an hour of picking region curves, toolpaths, etc. like you’d have to do on a higher-end CAM package. I’ve been toying with a way to do all of this advanced stuff via scripting so that the advanced behavior can be loaded only for users who need or want it.
Letting the cutter move more freely to cover the whole stock is a more simple problem that I just haven’t gotten around to fixing since it is so easy to lie to MeshCAM.