I’m trying to Slice a partial dome, but when I do the data is duplicated and it runs twice and the centers of the circles are offset, so they don’t stack properly? What am I missing? Please help Thank you in advance.
Slice Test.gh (116.5 KB)
I’m not sure what you’re trying to achieve, but it works fine.
p.s I do not recommend flattening everything, you erase data doing that, basically
The Contour component has a known bug where it creates duplicate curves. I’m not sure which versions this affects, your script works correctly here.
-Kevin
This affects 7.22 and 7.23.
-wim
Looking more closely at your file, there is a problem where you feed the output of the Contour component into the Plane input of the Circle component.
It works correctly after the change @dfytz1 shows.
-Kevin
I’m using the latest versions of Rhino and Grasshopper … @kev.r is there a work around? Is there any other change @dfytz1 made? even when I unflatten
the layers are still duplicated.
And when I run it though the simulator all the circles start off of this point instead of the center of the circles so the dome is offset?
The off center issue is better illustrated When I contour the curves in Rhino … why are the curves generated off of this point and not the center?
Thank you very Much
Slice Test_Dfytz1.gh (108.6 KB)
Slice Test_Dfytz2.gh (103.9 KB)
It seems, 2 extra planes appear when contour point is set to z = 0, basically coplanar with your dome base. Issues like that often appear in grasshopper, when you have to deal with coplanar geometry. But again, why do you have to use curve as a plain? 
@dfytz1 Thank you for your insight … the answer to your question is I need to learn how to slice this type of shape, if there’s no work around its easy enough to delete the extra coordinates. Is there an easy solution to my other issue, the last image I posted? how do we make sure the Circles contour off the center instead of the edge? Thank you!
So 7 SR24 solves the double contour issue, but I still could use some assistance in figuring out why how to array off of the center of the circles rather than the point on the edge. Thank you!
I would not use the contour curves as a plane input, this is unreliable.
This is from your original file:
You are already using a Deconstruct Arc component to get the radii of your circles. Use it’s Base Plane output to locate the centers of your circles.
Also, why are you generating circles to use as the Point input to the Deconstruct component?
Here’s how I would do this:
Slice Test_kr.gh (103.1 KB)
-Kevin
@kev.r Thank you so Much! Next question, why does it now work right in Rhino and Grasshopper, but when I copy to coordinates into a simulator the inner circle is offset?
And the reason why I am generating circles to use and the Point input is its the only way I know how to generate the shape, but its not arraying off the center … do you have an alternative way to generate the coordinates?
What is this “simulator”?
What kind of machine are you generating gcode for?
The only thing you’re using the Circle component for is as the input to the Deconstruct Pointcomponent. You have all the data you need at the outputs of the Deconstruct Arc component. What shape are you trying to generate?
What is “not arraying off the center”? The Deconstruct Arc Base Plane outputs all have the same centers (X,Y coordinates).
Generate what coordinates? As I have explained, you already have the coordinates for the centers of the circles at the Base Plane output from the Deconstruct Arc component.
-Kevin
this simulator is NC Corrector, free G-Code editor.
Its for a 3D Printer … yes all the points have the same X,Y coordinates and it looks right in Rhino, but when I load the coordinates to nc-corrector, instead of a ring (as it appears in Rhino) the shape is offset as shown in the image.
So you could have a problem with Rhino or a problem with the simulator. How are you transferring the data from Rhino to the simulator? You need to look at that intermediate data and relate it to the original GH data you are creating. If they are the same then the problem is in the simulator and/or the import, if they are different you have an issue with the export.
In any troubleshooting scenario it’s good to find ways to binary chop the problem like this in order to identify where the issue lies (although there may be more than one issue, of course).
@jeremy5 I’m copying “data only” from Grasshopper to Notepad ++ , saving, then opening the file in the simulator … Whether in Grasshopper, Notepad ++ or the Simulator the coordinates are identical in all three.
That would imply that the simulator assigns a different meaning to (some of) the co-ordinates. For example, and I deliberately use an example that doesn’t apply to your model, it may be that one program describes a square by its first corner and the vector that takes you to the opposite corner while another program describes the same square by its centre and a vector to a corner. The discrepancy between corner and centre causes an offset.
You need to look at how each co-ordinate is interpreted in the simulator.
@jeremy5 its starting each circle at a point along the edge instead of the center … need to figure out how to center it.
Came up with this after some googling and experimenting:
Slice Test_kr2.gh (107.5 KB)
It seems that the G03 command starts the arc at current position and ends at the point (X, Y, Z points) you supply (look at your previous attempts, the first arc is drawn from the 0,0,0 position to the first coordinate you supplied). You need to supply some move commands (G0) and it seems more reliable to make the circles in 2 segments.
Move → First Half Of Circle → Second Half Of Circle → Repeat
No guarantees on the accuracy of this, just what I’ve figured out from searching and experimenting a bit. Seems like a pretty complex topic.
-Kevin