Roughing ?

[Xylotica]

Hi !

I am working on a milling definition, and this time, it's not just fooling around.
I need to generate a first "Roughing" pass, and then a surfacing pass.
For the later, I can see how KUKA|prc can do a better job than even dedicated milling software because it is in fact real 6 axis milling, and I can mill with the milling bit normal to my workpiece at all times if I want (provided that I can avoid colisions).

Yet, the  "Divide surface" component has two major drawbacks :
-It works on a surface, not on a polysurface, and of course not on a mesh.
-It derives the trajectories from the isocurves which is similar to the way rhino builds meshs, but as we all know, has lots of drawbacks and sometimes produce really bad results.

Now for the roughing, it's got to be made into a definition by the user ; there doesn't seem to be a KUKA|prc component that will do this.
So this is a wishfull call in case someone has already worked on this, because although it's an interesting problem to solve with Grasshopper, I suspect it is going to gobble up all my programming time.

I know there is a plug-in called IO that will supposedly make "one-click" roughing, surfacing and pocketing.
Unfortunately, it is too expensive for me, and really, I am quite suspicious when a tool claims to do complex stuff with "a simple click".

Cheers,

[Johannes @ Robots in Architecture]

Hello,

Roughening also does not seem like a one-click solution to me ;)
The main problem with roughening is that the calculations take quite a lot of time, which does not really fit into the concept of Grasshopper. Personally I use SprutCAM for regular roughening as it's a nice software and free for universities - a component for G-code import is included with KUKA|prc. I guess the  cheapest way to get high-quality toolpaths would be via Autodesk Fusion 360, which is apparently free for students, enthusiasts, hobbyists, and startups. It shouldn't be hard to get the G-code into KUKA|prc and I can also help you with it.

Best,
Johannes

[Xylotica]

It's funny that you mention Fusion 360 because I am currently downloading it....
Let's see...

[ludo]

hello,
have you try the 5 axis maker software? http://5axismaker.com/5x/software/
They developp a gh definition for milling 3d shapes

see more detail in their website "5 axis maker.com"

Ludo

[Johannes @ Robots in Architecture]

Hmm... I haven't tried it out yet, but it seems that for the roughening they just import a polyline that they got from somewhere else.
I'm quite sure that a CAM tool for GH would be very nice niche for anyone like RhinoCAM who already has got a working Rhino integration.

Best,
Johannes

[Xylotica]

Thanks Ludo, Johannes,

some more testing to do then...

I will also try a "brute force approach to roughing (yes, roughing Johannes:).
I call it the "Drill fury" method : First I use MeshMachine from Kangaroo to produce a nice "geodesic" mesh on top of my Brep.
From the vertices of that mesh, which I reorder with "Sequential closest point", I generate a big bunch of drilling operations which are really performed by the custom "Tool Axis Offset" component.
Since I set the resolution of the mesh very tight, the sum of all those drillings should approximate the surface pretty closely.
Then, I can add a surfacing pass to smooth things out.

I tried to use the traditional LIN trajectories between points instead of drilling, but the "Sequential closest point" is not smart enough and joins "clusters" of points.
Between two "clusters", the path goes in straight line through my part :(

[Xylotica]

Hi Johannes,

I am trying to use the "Import NC" component with a .nc file generated by Fusion 360, but it seems that the curvy trajectories are transformed into straight ones.
See Attached...

[Johannes @ Robots in Architecture]

Hello,

Probably the CIRcular movements use a different syntax. As a intermediary solution you could try to disable circular movements in Fusion. Which postprocessor are you using in Fusion?

Best,
Johannes

[Xylotica]

Hmm... There are zillions of post-processors listed.
Actually , I picked the one that was there by default.
By any chance, would you know one which is compatible with the "Import CNC" component ?
I have yet to find the option to disable circular movements in Fusion.

I tried "Freemill" from "RhinoCAM" ; up to now, with the .nc files I exported, I only get "1. Solution exception:Insufficient points for an interpolated curve" error messages.

I'm also wondering whether I can shift (translation) KUKA|prc commands in case I need to adjust the height of may part for instance...

Cheers,

[Johannes @ Robots in Architecture]

Hello,

Basically that is a matter of parsing text - the component expects a certain format, and if it doesn't get the data it expects you will get a strange result or no result at all.
The logic of parsing most G-codes is not too difficult - split each line by some separator and if the first letter of a fragment is X, then set it as the X-value etc.
I believe the Mach3 postprocessor somehow worked last time I tried it, so give that a try. If not, please send me the G-code via eMail.

Best,
Johannes

[Xylotica]

Hi Johannes,

may I suggest a slightly different and perhaps more flexible approach ?
If there was a robust component that would simply generate a polyline from the G-code, then it would possible to tweak the said polylines at will (move, rotate,...) and use them with the basic LIN or PTP components.

I find it frustrating to SEE the trajectories I need in FUSION or in RhinoCAM and not being able to retrieve them as geometry.

Cheers,

[Johannes @ Robots in Architecture]

Hello,

You can get the planes out of KUKA|prc components and move them around etc.
Regarding the polyline, while that would basically work, it also means that you lose all the speed settings, i.e. that the tool will have a constant speed and therefore be really, really slow outside of the material.

Best,
Johannes

[Xylotica]

Hi Johannes,

My idea was to have a more simple import component that would produce at least a polyline.
For now, I have tested the "Import G-code" component with many "flavors" of .nc files, and it never worked.
I can understand how tough it is to make a robust importer when you have to deal with all these variants, but I imagine that if you just focus on getting the polyline right , it should work all the time.

Once I have a polyline, I can always split it and assign various speeds.
Tedious perhaps, but at least certain to get the job done...

Here's a video of my yesterday's milling, using a geodesic mesh to generate the path :

https://youtu.be/yowcbKy3Bco

Cheers,

[Johannes @ Robots in Architecture]

Hello,

Hmm...  The KUKA|prc G-code component is really only made for importing G-code from SprutCAM, via the included postprocessor. As such, I'm actually in favor of it producing errors when reading "other" G-code - otherwise you might actually import a wrong file and damage your tool, or a workpiece that has been milled for hours.
Anyway, as a custom solution please find attached a small C# component that reads text files. It splits every line according to defined characters, and if a block starts with X, it will take all following numbers as the X-coordinate etc. It will need some customization if there is e.g. an empty space between X and the coordinate.
Hope that helps - and thanks for sharing the nice video!

Best,
Johannes

[Xylotica]

Thanks Johannes for the component , I'll try it out soon.
You might want to document the fact that the Gcode should have been made in the "SprutCam" flavor.
It will definitely save time for the first-time users.

Cheers !