Regenerating 3D lines after nesting operation

[James_Richters]

I am trying to use Grasshopper to solve an issue I am having with a CNC workflow. I have some parts that need holes drilled at a compound angle on a 4+1 CNC machine (5 Axis, 4 CNC Axis + 1 Mechanical Axis). In order to drill holes at a compound angle, I need a reference plane that is at the compound angle, I also find it helpful to have a tilt line that represents the centerline of the drill bit for verification.
I normally just draw this information in Rhino and send it to vectorcam where I can create the NC code for this. But now I have a job that is too difficult to fit the parts on a sheet manually, so I am using an on-line subscription service called Nest and Cut to do the nesting for me. Nest and Cut finds good solutions for my nesting, but it requires a DXF Lines and Arcs file in and it exports a DXF file. Since it is only concerned with 2D nesting, it forces everything to Z=0 and so when I get the file back, all my 3D tilt lines and lines I would use to create the reference plane are now useless as everything is at Z=0.

So I came up with a possible solution. My drilled holes are all at 10 degrees away from vertical, so in Rhino I drew the tilt line and made it go from Z=1.5" to Z=-1.5 and put points on different layers on the ends of it. I also drew reference lines for the plane and put points on that as well, also on different layers. I have all the points that at are at Z=1.5 on a layer named 1_5 and all the points that are at Z=-1.5 on a layer named -1_5. I also put points and lines to create the plane on other layers so I can make sense of it when it gets back from nesting all flat. It looks like this:

When I run Nest and Cut, it does a very good job of figuring out how to arrange parts on a sheet I get this result:

but everything is flat at Z=0

So I made a Grasshopper script that filters out all the points and moves them to the correct Z heights, and builds the plane and lines from the Z corrected points:

So my script works perfectly… but only by accident… it’s dependent on the DXF file being in the correct order and it’s just dumb luck that it works at all. I can prove this by deleting one point then creating a new point and putting it on the correct layer… now it’s out of sequence and it doesn’t work right.

So I’m wondering how I can modify my Grasshopper Script to be foolproof and work because of the way the input geometry is connected and not just because it so happened to be in the right sequence.
All the points that belong together are connected with lines, so I got all the lines in a list, and then I got all the start and end points:

But now I don’t know how to finish it… I need to move the start and end points either up or down by 1.5inches, but to know which is which, what I need to do check each start and end point and see if it has a matching point in the 1_5 or -1_5 layers. If it’s in the 1_5 I need to move it up by 1.5 inches. If it’s on the -1_5 layer, I need to move it down by 1.5 inches… then just connect them… since my lists I’m using were created by finding the start and end points of the line, the results will be correct even if the points on the 1_5 and -1_5 layers got mixed up, or if the lines ended up backwards. I just don’t know how to do the check to see if each start/end point is also in the 1_5 list or the -1.5 list

I am using Elefront to filter things and for some reason I can’t internalize data with that, so I’m including both the Rhino and Grasshopper files. My intention is that I would just do a select all on the Rhino drawing and bring everything into Grasshopper
CBC Center SHEET_001_QTY_4.3dm (2.5 MB)
Fix Tilt Lines and Planes.gh (148.4 KB)

I appreciate any help on this.

James

[gordonleibowitz]

If your main issue is that you are losing track of pieces when you send them to nest and cut, i would recommend trying opennest which you can find on food4rhino. This will let you keep all your geometry in rhino/grasshopper. It also has a neat feature that will move and additional geometry with the pieces that are nested. For example if you have part name or some other reference geometry on a part you can move that part name to the nested location. There is also a great tutorial online (I believe by the developer).

OpenNest

OpenNest: Introduction | #01 Nesting Objects with Text in Rhino

[James_Richters]

Thanks for the suggestion, But I have tried OpenNest, and it just can’t find solutions that Nest and Cut finds. I have also own RhinoCAM which includes nesting, and it also can’t do as well as Nest and Cut, that’s why I pay a monthy fee for Nest and Cut even though I own RhinoCAM that I paid for and also have OpenNest and things like DeepNest.IO I have tried SO many nesting programs.

The problem is that I have a lot of large triangular shapes, and it needs to rotate them freely to get them to fit. I’ve tried setting rotations in nest and cut to 360 to allow 1 degree rotation accuracy, but it still can’t do as well as nest and cut. Nest and Cut can produce this for me:

It manages to find solutions with 6 large triangles in a sheet, when I try this exact same thing with anything else, I only get 4 or 5 large triangles, but I know I can get 6, and nest and cut does this right out of the box, I don’t need to fiddle with any settings or do anything, it just works!
Most all nesting programs work GREAT if you have a ton of small shapes you want to fit into a sheet, but when you have very large shapes with odd angles and you need free rotations to get them in, then they can’t achieve the same results.

Also as far as I can tell, both RhinoCam’s nesting and OpenNest also require 2D geometry and end up having the same issue I am having with Nest and Cut… My 3D lines are flat when it’s done, and any surfaces are also gone. nesting programs work with 2D lines and arcs, they do not want any surfaces at funny angles, or 3D lines… everything comes out of nesting programs 2D, and I need my 3D references to drill holes at compound angles.

[gordonleibowitz]

Two solutions for ya. First is kind of a fluke where I rotated the sheet 90 degrees and that made open nest put everything on one sheet. Must have something to do with the rotation of the pieces?

Second, you can achieve the grouping of points you are looking for with the closest points component as shown in the file and then sort by layer name to get reliable data organization. The only caveat is that I had to move two of your points marked by the cyan spheres in the rhino file because they were not closer than the point arrangement of the neighboring set. So if you do this again you can just make all the points a little closer so that the point group is reliably distinct.

CBC Center SHEET_001_QTY_4.3dm (2.6 MB)
Fix Tilt Lines and Planes.gh (163.1 KB)

[James_Richters]

@gordonleibowitz

First is kind of a fluke where I rotated the sheet 90 degrees and that made open nest put everything on one sheet

Yes, that particular nest I need only 20 parts of, so I just did 5 identical parts on each sheet, it only uses 4 sheets, so I have a rectangle left over.

This one I need 60 of each part, there are 2 each of 3 parts on a sheet, so I get 6 big triangles on a sheet. this is the kind of thing that Nest and Cut can do and I haven’t found anything else that comes close to it. Even if I set my part spacing to 0.2 with Open Nest, it can’t do it. The problem is the maximum value of 10 for rotations… that means it smallest increment it can rotate something is 36 degrees, and that’s not enough. Nest And Cut has a free rotate. I’m not sure if it has some resolution, it only has options for 0,45,90,180 and ALL… and all is some very small increment.

708366_SHEET_001_QTY_30.3dm (1.6 MB)
Fix Tilt Lines and Planes 2.gh (129.7 KB)

@gordonleibowitz

Second, you can achieve the grouping of points you are looking for with the closest points component as shown in the file and then sort by layer name to get reliable data organization.

Thank you for this solution. I’m still trying to figure out how it works, but I think I get the general idea.

@gordonleibowitz

The only caveat is that I had to move two of your points marked by the cyan spheres in the rhino file because they were not closer than the point arrangement of the neighboring set.

That is really strange… because all my points and lines all come from multiple instances of the same block. I just smash the blocks right before I export everything… so they should all be the same relative distances apart. Here’s what that part of my Rhino drawing looks like:

Original.3dm (1.5 MB)

[gordonleibowitz]

@James_Richters

so they should all be the same relative distances apart.

The situation arises because in this instance the cyan sphere is closer to the red sphere than the yellow sphere. So when the closest points alogrithm runs it wanted to use the point at the cyan sphere in the construction of the plane.

@James_Richters

I’m still trying to figure out how it works, but I think I get the general idea.

Here’s a version with a little more description.
Fix Tilt Lines and Planes.gh (161.6 KB)

[James_Richters]

@gordonleibowitz

yan sphere is closer to the red sphere than the yellow sphere

Ohhh I see… It’s getting the closest points. but those from the wrong set happen to be closer. that’s kind of what I was trying to do, but I was trying to see if the points were connected with a line to determine if they were part of the same group… The purple lines share a common end point, so I’ve been trying to group them by their end points. this would take care of the problem because even if the 2 sets were way closer to each other than the distance to the points, they would not share a common end point.

Here’s how far I got with that… I’m filtering out by layer, then filtering lines, then getting all the end points… then… well I don’t know… I’m trying to orgainize them into groups that share a common point, I did union to get common points, but I don’t know where to go next to organize them into groups.

[inno]

It’s an interesting problem!

but is also full of things so maybe I didn’t understand the main point…

I noticed in general the line that defines the rotation axis for your drilling planes, is -of course- consistently longer than the other one (because the other is the projection on an angle)

isn’t that enough data to reverse the position of each plane, expecially knowing that the plane angle is 10° ?

here is a try, let me know your thoughts (it takes the curve from Geometry Pipeline on your original Rhino file drawing)

@James_Richters

CBC Center SHEET_001_QTY_4.3dm (2.5 MB)

[edit]

(by the way… I sketched this in 5 minutes so it’s FAR from optimized… there are for sure double or even triple components here and there that could be trimmed out)

I got it partially wrong I missed the part like "starting from just the layer named “Sheet” in my Rhino file…

anyway, by filtering the Sheet layer for curves with correct length, it looks like producing the right result but again only for luck

what I would do to make it more reliable is to draw ONLY the +1.5 inches length curve, in such a way you know the direction the final result should be…

2D_nesting_to_3D_axis.gh (18.8 KB)

[James_Richters]

@inno

It’s an interesting problem!

Yes, I’ve been trying to find a solution, but my knowledge of grasshopper is fairly limited.

@inno

I noticed in general the line that defines the rotation axis for your drilling planes, is -of course- consistently longer than the other one (because the other is the projection on an angle)

Yes, they started off exactly the same length, it’s a funny length because it’s where the line intersected a plane at Z=0.25

@inno

isn’t that enough data to reverse the position of each plane, expecially knowing that the plane angle is 10° ?

Yes I thought that should be the case as well, I thought I could make a plane flat and rotate it up 10 degrees on the longer line. but I got all confused with that with details like how to make sure I’m rotating on the correct side of the line. It sounds like that is what you are thinking.

Thanks for the file, I’m going to open it now and see how it works.

[inno]

I think I have edited my previous post just while you were replying, sorry for that, please check the reuploaded file which actually works only on the “Sheet” layer, but still produce good results only because all your original planes had Y axis coming in +Z direction instead of being mixed

if they were mixed, I think there was no way to tell which was the right direction with the available data on the layer “Sheet”

[James_Richters]

I think I was replying at the same time, I will re-download it.

I didn’t mean I wanted to use layer sheet… I meant I wanted to just attach the whole drawing to the grasshopper script and filter by whatever layers were needed. The final Grasshopper file is also going to separate the top from the bottom and do other things. so, what I meant to say was I just wanted to import all geometry into grasshopper. It’s fine to filter out whatever layers are needed.
Layer ‘Sheet’ is just the rectangle that represents the sheet of material to be cut.

[inno]

Here is a version with “error recognition” which draws a sphere if the projection of the hole doesn’t fall within a certain distance (0.01 units) from the closest point in the 1_5 layer

2D_nesting_to_3D_axis_error_recognition.gh (21.7 KB)

for instance, if I draw the drill lines of length 1.6 instead of 1.5 this is what I see on the screen, each sphere is an error in the orientation of the plane (fake error of course)

---

I guess the reason it works fine is because when you have generated the planes from which the two curves where taken (one curve projected, the other already on XY plane) you have always generate planes with Y axis-curve going toward +Z

this means that whatever situation you are in, those shorter curves that indicate the projection of the Y plane will always go toward +Z

to be 100% sure of this, and have reliable results with the current files, I think we should have a look to the GH definition that you have used to generate the guide curves, but I truly believe things will be ok as they are

[James_Richters]

@inno

to be 100% sure of this, and have reliable results with the current files, I think we should have a look to the GH definition that you have used to generate the guide curves, but I truly believe things will be ok as they are

The guide curves are produced by making copies of the same block and putting them where they go with the “orient” command in Rhino… so they are all identical copies of each other.

I think I am over complicating it by trying to draw the tilt line… the plane is harder to draw and once you have the plane, the tilt line is easy to draw in. Maybe it would help identify which line is which if you knew the meaning of the points I drew. Here is the meaning of the relevant layers for making the plane:

Layer 0_0 is a layer of yellow points at the drill start position, this is the exact point where the tip of the drill bit will first touch the material. These points would stay at Z=0

Layer Screw_Plane is the purple lines that are where the plane should be. They both use the point on layer 0_0

Layer 0_0_X is a layer of orange points at the other end of the Screw_Plane line which should be the rotation axis for the plane. These points would stay at Z=0

Layer 0_25_Y is a layer of light blue points at the end of the other Screw_Plane line. If those points were raised by 0.25" they would be in the correct position to draw the plane using the line between the yellow and orange points as one edge of the plane and the light blue point as the 3rd point.

[James_Richters]

@inno

this means that whatever situation you are in, those shorter curves that indicate the projection of the Y plane will always go toward +Z

Yes this would always be the case, as they are all copies of the same block… the end of that shorter curve would always need to be raised by exactly 0.25"

[inno]

@James_Richters

The guide curves are produced by making copies of the same block and putting them where they go with the “orient” command in Rhino… so they are all identical copies of each other.

if that is the case, if in your original original block the curve indicates the projection of a Y axis that was always raising toward +Z direction, then it will be the very same identical case everywhere on your drawing, and so by using the definition I provided you can easily identify the exact axis of each hole

however you orient them, you will always be in this case:

[James_Richters]

@inno I think your method of joining all possible curves then exploding them is really a clever way to group the lines that connect to each other in their own groups. I’ve been trying all kinds of convoluted ways to achieve this list in a way that guarantees that I get the correct lines in the groups.

Edit: I think all I really need is those 2 lines, I don’t think I need any of the points or anything else… once I have the plane, I could easily just draw the tilt line in

[inno]

@James_Richters

I think all I really need is those 2 lines, I don’t think I need any of the points or anything else… once I have the plane, I could easily just draw the tilt line in

100% agree with you but what is life without a little bit of “let’s spread some hundreds more components on GH canvas here and there…” hahaha

[James_Richters]

@inno I finally figured out how your script works; I learned a lot while following it through. I was wondering why the error checking needed to be 0.01, then I realized that you used the 1.5 as the length of the line, but it’s really that the end point has a Z value of 1.5 I just put in the actual length of the line and now it’s very accurate.
I also need that plane in my final output so that was easy enough to add in.

@gordonleibowitz Thank you for your help as well! I also learned a lot seeing how you did things.

[James_Richters]

This is working pretty well now, I appreciate everyone’s help!
I added a C# Script to export the grasshopper geometry directly to a new Rhino 5 file (my CAM isn’t compatible with 7) Anyway, the export is working great, but it has one odd behavior I can’t figure out… Whenever I toggle the ‘export’ input, it runs twice… every time.

I even tried making it a push button, it still always runs twice!

Here’s the script and the file I’ve been testing with:
2D_nesting_to_3D_axis_error_recognition.gh (37.0 KB)
708366_SHEET_001_QTY_30.3dm (1.6 MB)

Any ideas how to make it only run once?

[inno]

I would try replacing the boolean toggle with a simple button