I didn’t look at your code this time because of this incorrect claim in your first try:
Join the curves to get rid of the duplicates.
Instead of two images of your code, are you aware of this feature to “Export Hi-Res Image”?
As you wish. For me these are all exercises in learning (from/with) each other.
- the comments, show me what was wrong, what could have been better. And I am happy with each and all of them. And to be honest, I like your comments: sharp, precise, unforgiving. I do not learn much from comments what say, that i did my best and keep going on that way.
- I grant everyone an answer/discussion to their question. That is why I am happy when my first reaction (sometimes after days) gives a stream of other reactions. That is the best the questioner can wish for.
I am aware, could not find it. Will use that. (Goes the same for “faint” in stead of “hidden” for Wire Display, as I read short time ago in one of your comments). Thanks.
1 Like
Here is another solution using only the main brep and vectors. The untrim may not work for some shapes. Once you add the rads to your curves I expect a number of changes will be needed. The middle edge pockets use a a component I did not like. I found a much better solution when I was finishing the script, but I did not go back to fix this. I assumed you may redefine the problem parameters.
POCKET-brad.gh (85.4 KB)
The curves you wanted are in the entwine.
These problems are best solved by postulating a part with all the various problems or modelling steps you may take. Inno, Martin, and Jospeh are brilliant with this stuff, so I am sure we will all help a bit more. Anything other than vases is interesting to me.
In addition to this being the dxf input I assume this might be part of the instructions for the machine operator. If so, I think you are underestimating what you can do with grasshopper. I added some parametric text to plant some ideas. It would be very easy to automate this to be much more useful, and output a CAD file in Rhino. Text tags will not work for that, but there are other options. If you want low tech you can print a .pdf file of your custom preview screen.
Am I correct you are not making typical cabinetry or other wood parts? If so, I understand using oddball software for your CAM work. I think you have outgrown VCarve, and Fusion for that matter. I know that is a big step based on what you described, but it will never get better. I argue with our plant guys all the time, and they keep spending countless hours needlessly on drawings that could be automated. At this point everything from part numbering to file naming is important if CNC cutting is key to your daily production. When I used Solidworks we had parametric toolpath routines. With a few clicks we could change the parts, and the tool paths would be re-calculated. That only works if you have parts with similarity. I know these packages are expensive to maintain, but I bet if you track how much time your team wastes finding information or re-making parts you could find it pays for itself.
1 Like
Hi there!
I’ve collected a few pieces that are fairly representative of what we machine in the workshop most of the time. Your definition works pretty well on less complex parts, but on curved parts it doesn’t work. Do you have any idea why?
PARTS.3dm (6.2 MB)
Hello, thank you for your reply.
I’m well aware that Grasshopper would allow me to do much more than the problem described here. It’s just that we don’t have anyone in the company with the necessary skills at the moment. Your idea of adding parametric elements to facilitate the work of our machinist is interesting.
While searching the forum, I came across an old post by someone who had worked on a problem similar to mine and who had succeeded in placing the 2D lines on layers according to the depth of the pockets. This is typically something that could be useful to me, so I’m going to work on it. (From 3D parts to 2D CNC machining curves)
Your .gh definition is rather complex for my current knowledge, so I’ll take a closer look when I have time.
Thanks a lot!
Grouping into layers for each operation and depths of cut is the route I would go with Vcarve and your number of staff. That can all be automated.
Ideally one would get the script robust enough so it would be a cluster that needs very little skill. I understand the problem with staff and GH. Grasshopper is far different from other software in many respects. If you code fails in some cases there are people in this forum that could code anything that might not work with CSharp or Python.
Is it common not to show rads at the corners? I assume these parts fit together so it seems important? Maybe they all get dog bone cuts. The only reason I ask is that will affect the number of curves in closed shapes.
We don’t actually draw dogbones in 3D, but only in 2D drawings. We already have a good plug-in/script to do this, and our machinist can also take care of it if required with Vcarve.
Ok, that would drive me bonkers. I know how to add dog bones in Vcarve.
I found the diameter of some of your circles were out a little. I assume this is a simple error that is common, so I am rounding this in the script I am working on when time permits. It has some interesting steps to organize the data. I will share at some point.
1 Like
I have had a fast look to the new, more complex, parts you have posted
the following is not valid anymore 
with parts showing pockets at several different heights, like this random one:
in order for the offset (magenta) to be allowed, the original (green) surface edge could lay on the edge of the bottom face but also on the edge of any pocket deeper than the green one (for instance here, all the inside curves overlapping the blue part can also exist, despite not falling over an edge of the bottom face)
I mean this portion of curves I have highlighted in red, that wouldn’t exist if we were comparing the green surface only to the bottom one:
all in all this is an interesting problem where I think a lot of problem solving and weird out of the box thoughts can be applied 
I’m gonna have some fun with it
I have this thought of this being a sort of entirely 2D problem, probably some Region Union might be involved at a certain point: the 3D structure of the Brep is relevant just on the very first steps of the definition, where you really need to retrieve a data tree listing all the horizontal surfaces of the Brep branched by Z-coordinate
after that it’s just a matter of comparing stuff
the interesting thing is, let’s say a given brep is represented by this data tree:
{0;0} (bottom face/faces)
{0;1} (lower pocket/pockets)
{0;2} (higher pocket/pockets)
{0;3} (top face/faces)
half of the job is already done
you just need to find a reliable way to offset all the portion of curves of {0;2} (higher pockets) that lie on any boundary-edge of either {0:1} (lower pockets) or {0;0} (bottom faces)
1 Like
I worked on this project for a few hours yesterday. Mainly out of interest to see if I could improve my skills grouping the data. My approach is to look at the bottom plane and top planes separtely. I have only looked at the bottom plane in the script below. I split the problem into boundaries, thru pockets, and holes.
PARTS-brad.3dm (2.7 MB)
PARTS-brad.gh (53.6 KB)
I decided to try to work with all the parts in your file at the same time. This was only done to improve my own skills with this amount of data. Obviously, working with one part at a time would be easier; however, I found it was not that difficult except for a few steps that took some time searching to find a solution. One could group the parts based on thickness quite easily if you are working with mutliple thicknesses at one time.
When I used VCarve I found the most tedious task was grouping all the holes for drilling operations. It was very easy to miss holes or select a hole that was the incorrect size. I decided to let GH solve that problem by grouping all the holes for each part. I also added some text in gh showing the hole sizes.
The next problem was baking the geometry into rhino. This seems like another step where humans could make mistakes. I had AI help me write a script to map the parts into unique layers based on the geometry and sub-layer names I added to the output data. I am not a wizard at python scripting, so someone with more skills could likely make that code more robust or look at options so one script could be used for all cases. I tried to randomize the colors of the layers, but it is not working quite like I want. One could go one step farther with this and add a small amount of code to automatically create the file your machinst needs. The part numbering and file naming scheme could be easily automated so the file name tells the operator a lot of information about the part. That is how it is done in the mechancial world. All of that will depend on your operation needs.
Bake Script:
Baked Geometry:
Rhino Layers from Script:
I am interested to see what Inno is working on. I did not quite follow his ideas, so I am sure I will learn something new. I may look at this a little more, but this could be where I stop.
I know this may seem complicated. I think you can get the script to work for all cases so the users only input new geometry and click run. If I were in your shoes I would eventually hire an expert to take a deep dive into your code and make it work exactly as you want. Anytime we have hired someone it pays off over the years.
Good luck.