Processing power issue with current toolpath strategy

Replies to This Discussion

Permalink Reply by Justin Michael Bush on July 23, 2017 at 1:35pm

I own (what I consider) very expensive CAM software. It's good, but it doesn't always do what I want it to. I wouldn't have bought it had I known that I would start learning grasshopper and some coding shortly after. It doesn't support scripting, and I can just see a lot of improvements I could make. Maybe I could sell it? Beyond that there is value in solving the problem for myself, and sometimes people just want to see how good of a wheel they can make.

Permalink Reply by Joseph Oster on July 21, 2017 at 10:30am

Your logic looks sound to me.  The bottleneck is the 'BLX' so reducing the number of samples around the circle would help.  I replaced 'Curve Div Length (0.0100)' with 'Circle Div Count', set to "10", instead of the 40 points on each circle from that length setting.  But that doesn't change the fact that precision takes more processing time.

I made a little change in EndmillToolpath_2017Jul21b.gh to show the difference between the point on the curve and the adjusted point based on the 'BLX'/tool collision; red shows minimal difference, blue shows maximum.  The tool will follow the tops of these cylinders:

Attachments:

• EndmillToolpath_2017Jul21b.gh, 21 KB
• EndmillToolpath_2017Jul21a.gh, 22 KB

Permalink Reply by Joseph Oster on July 21, 2017 at 10:48am

P.S.  Interesting to note the range of adjustments; "0.052" max:

Permalink Reply by Joseph Oster on July 22, 2017 at 12:40pm

I studied your bounding box solution and, while it is somewhat slow (~4.4 secs.) to 'Project' the circles to the surface, seemed at first like a very accurate solution with better speed.  However, I noticed that the range of solutions was far greater than the code I posted.  When I added the bounding box approach to my earlier code (with a small improvement, using 'DeBrep V (Vertices)', I noticed many of the gradient colored cylinders were much taller than expected, based on the projected circles...

I believe the problem is due to the fact that 'Project' returns a slightly longer list of curves than was supplied to it!  Which creates an offset and miscalculations.  Same thing happened when I tried extruding the circles up and getting 'BBX' curves where the tool bit intersects the surface; slow (19.5 secs.) and a longer list of results than input.  Bummer.

Permalink Reply by Joseph Oster on July 22, 2017 at 1:06pm

I replied too soon.  Managed to come up with a fix (yellow group) for the "bad data", the unwanted increase in number of results from 'Project' and 'BBX'.  By partitioning the circles, then using 'Join' and 'List Item' (in case there are still two results per circle after 'Join'), I got the same number of bounding boxes as the original list of circles and the results are back in the same (smaller!) range as before.

Attachments:

• EndmillToolpath_2017Jul22a.gh, 30 KB

Permalink Reply by Joseph Oster on July 22, 2017 at 3:57pm

Here is a better way(?) to deal with the extraneous results from 'Project' circles and intersect cylinders (which otherwise agree very closely on adjustment "domain bounds").  Just set 'Union Box' on the 'BBox' so the partitioned (unflattened) curve bits for each circle/cylinder are included; when there is more than one per circle, it makes no difference:

Attachments:

• EndmillToolpath_2017Jul22b.gh, 30 KB

Permalink Reply by Joseph Oster on July 22, 2017 at 5:30pm

I have no idea why this tool path is shaped as it is?  An obvious next step, though, is parallel offset curves.  This code opens with 'offset paths' 'Count' slider at 10.  WARNING!  Takes 36+ seconds to open!!!  That time goes up as you increase the count, and interesting offset curves (crosscut!) happen when count is in the mid to high twenties.

There is an anomaly to be aware of at the switchback points on the path; best seen in top view, the blue curves are the new, adjusted tool paths.  See how they have no discontinuity at that point?

Also, some tool-bit-size areas are not touched by the tool path at this setting (1=100%) of the '%Tool Diameter' slider:

P.S.  Coverage is improved considerably with '%Tool Diameter' slider at 0.5 (50%).  26 offsets take 1.6 minutes.

Attachments:

• EndmillToolpath_2017Jul22c.gh, 35 KB

Permalink Reply by Joseph Oster on July 22, 2017 at 6:26pm

Fixed a mis-wire to 'Cls', but not the switchback discontinuity issue, if there is one?  This model runs in ~33 secs.; it demonstrates the quirks of extreme offset using a low path count (15), thanks to wide spacing (3X tool diameter).

Attachments:

• EndmillToolpath_2017Jul22d.gh, 28 KB

Permalink Reply by Joseph Oster on July 22, 2017 at 7:28pm

This version replaces standard GH 'Offset' curve with the Clipper plugin ('PolyOffset'), as recommended by David Rutten, June 9, 2017:

for GH1 I recommend using the Clipper plugin, I'm planning on adding the clipper code directly to GH2 so it is accessible natively.

Much better offset/inset curves!  Added a 'Tolerance' slider...  Fast!  ~15+ seconds to open:

With '%Tool Diameter' set to 0.5 (50%) and 'Count' set to 100, time is ~1.5+ mins, though there are three distinct spot anomalies that need further examination...

Attachments:

• EndmillToolpath_2017Jul22e.gh, 39 KB

Permalink Reply by Justin Michael Bush on July 23, 2017 at 2:39pm

Wow, lots to cover.

Joseph, was there a reason for replacing div length by div count in your first reply? Is it faster? How are y'all getting the speed measurements of these different methods?

This surface and curve are arbitrary.

Tom, that was a great idea with the bounding box. I am not opposed to coding some or all of this. I started learning some java, c#, and python, have taken a few tutorials on grasshopper c# scripting, but haven't really dove in with coding grasshopper/rhino yet.

With that said, I've had some ideas, and have worked on the ballmill portion a little bit. With the ball mill I was playing with how many points to populate the surface with, and looking at the subtraction of the ballmill from the surface. I was thinking you could do it in multiple passes, using a relative few points on the first pass, finding the center of the intersection and then either using that point or that point and some number created around it for the next pass. Haven't tried it yet, but might work!

Or what about a recursive (EDIT: iterative?) approach where the cutter location is approximated, tested to see if it intersects the surface, then moved in increments until it is no longer intersecting?

Not sure if there is a difference between moving the cutter or creating a new one at each spot, but I changed the definition a bit to move rather than creating new geometry (though I suspect it is essentially doing the same thing?).

Joseph, that's awesome. Thanks for mentioning clipper, I didn't realize DR suggested it over GH native offset function.

Thanks so much for all the help guys!

Attachments:

• Endmill and Ballmill.gh, 39 KB

Permalink Reply by Joseph Oster on July 23, 2017 at 3:20pm

Joseph, was there a reason for replacing div length by div count in your first reply?

No good reason at all, makes no difference.

How are y'all getting the speed measurements of these different methods?

'File | Preferences | Widgets | Show Profiler widget'

Regarding a "ball mill", you could apply that shape to 'BBX' instead of the 'intersect cylinders' code I left in previous posts.  Disabled group because it's slow, but it's very accurate, using the same bounding box around the intersected curve(s).

And yeah, you could use Anemone to implement iterative attempts to avoid intersection, raising the tool by 'Z_incr' each time, but detecting those intersections can be CPU-intensive.

Permalink Reply by Joseph Oster on July 23, 2017 at 4:23pm

On second thought, using 'BBX' and 'BBox' won't work with the "ball mill" as it does with cylinders...  Iteration is the only method I can think of, testing for 'BBX' or perhaps solid intersection (if it is faster?  the surface can become a solid).

• ‹ Previous
• 1
• 2
• Next ›
• Page