Robots in Architecture Forum

Robots in Architecture, Art, and Design => General Discussion => Topic started by: Wall-E on February 02, 2016, 02:48:34 PM

Title: Roughing ?
Post by: Wall-E on February 02, 2016, 02:48:34 PM
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,

Title: Re: Roughing ?
Post by: Johannes @ Robots in Architecture on February 02, 2016, 02:58:49 PM
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
Title: Re: Roughing ?
Post by: Wall-E on February 02, 2016, 05:01:38 PM
It's funny that you mention Fusion 360 because I am currently downloading it....
Let's see...
Title: Re: Roughing ?
Post by: ludo on February 02, 2016, 05:02:54 PM
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
Title: Re: Roughing ?
Post by: Johannes @ Robots in Architecture on February 02, 2016, 05:17:36 PM
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
Title: Re: Roughing ?
Post by: Wall-E on February 02, 2016, 06:48:28 PM
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 :(
Title: Re: Roughing ?
Post by: Wall-E on February 04, 2016, 05:34:49 PM
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...
Title: Re: Roughing ?
Post by: Johannes @ Robots in Architecture on February 04, 2016, 07:17:56 PM
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
Title: Re: Roughing ?
Post by: Wall-E on February 04, 2016, 09:38:13 PM
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,
Title: Re: Roughing ?
Post by: Johannes @ Robots in Architecture on February 05, 2016, 07:50:18 AM
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
Title: Re: Roughing ?
Post by: Wall-E on February 05, 2016, 11:54:34 AM
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,
Title: Re: Roughing ?
Post by: Johannes @ Robots in Architecture on February 05, 2016, 03:43:06 PM
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
Title: Re: Roughing ?
Post by: Wall-E on February 06, 2016, 07:11:15 PM
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 (ftp://youtu.be/yowcbKy3Bco)

Cheers,
Title: Re: Roughing ?
Post by: Johannes @ Robots in Architecture on February 06, 2016, 07:47:19 PM
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
Title: Re: Roughing ?
Post by: Wall-E on February 06, 2016, 09:44:50 PM
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 !
Title: Re: Roughing ?
Post by: Johannes @ Robots in Architecture on February 07, 2016, 04:23:15 PM
Hello,

The description gives rather detailed instructions on how the G-code is supposed to look like, though:

Imports 5-Axis NC code. Use G01 for LINear movements with XYZAC and empty spaces between. F is assumed to be the speed in mm/min. Use G02 and G02 for arcs, with IJK being the center point in absolute coordinates. A suitable postprocessor for SprutCAM can be generated by right-clicking the component and choosing the appropriate option. In SprutCAM, use the '5-Axis Toolhead A,C' machine for optimal results.

Best,
Johannes
Title: Re: Roughing ?
Post by: Wall-E on February 07, 2016, 05:39:08 PM
Hi Johannes,

I'm a bit confused...
The help text for the component suggests that the G-code should be generated from 3D printer utilities ;the inputs "Enable / Disable the extruder" seem to sugest this as well.
These utilities are not suitable for milling of course.

Now you mention detailed instructions (where are they ?) saying that sprutCam  can generate suitable .nc files.
Since I will only do milling occasionnaly, I don't plan to invest in an exepensive software like this.
I hope I can generate proper code from FreeMill (from RhinoCam).
I'm not too keen on using AutoDesk software, so I will probably ditch Fusion.

Cheers,
Title: Re: Roughing ?
Post by: Johannes @ Robots in Architecture on February 07, 2016, 05:44:53 PM
Hello,

Now you're looking at two different components! There is one for 5-Axis (SprutCAM) and one for 3D-printing.
Most, if not all CAM software allows you to define your own postprocessor so you can create G-code that exactly fits your machine. That is why I've included the instructions.
I've attached one exemplary, valid G-code for the 5-axis import.

Best,
Johannes
Title: Re: Roughing ?
Post by: Wall-E on February 07, 2016, 05:52:14 PM
Me stupid.
Title: Re: Roughing ?
Post by: Wall-E on February 08, 2016, 10:23:16 AM
OK, back after testing with the right component.

Using FreeMill, I tested a large bunch of .nc types, and no luck, either with the C: component or the G-code input component.
I can see obvious reasons for it not to work ; most of these  :
-do not put empty spaces between coordinates
-do not put all the coordinates on each line ; if a coordinate (Z generally) is constant throughout many points, the Z value will be given once only
-Some add a "N value" on each line
-Etc...

Now, KUKA|prc being within the Rhino ecosystem, wouldn't it make sense to add a "Output postprocessor for..." RhinoCam or MAdCam which are Rhino plug-ins ?
Not sure about MadCam, but RhinoCam at least has a free version.

Or maybe, instead of making a CAM program-specific post-processor, why not make the "G-code import" component compatible with a very popular post-processor which is likely to be found in most CAM programs ?

Cheers



Title: Re: Roughing ?
Post by: Johannes @ Robots in Architecture on February 08, 2016, 10:42:47 AM
Hello,

Did you take a look at the previously posted C# component? You are able to set the spacing etc. It's also not a problem if a value is only given once, it will buffer it. The script is not protected, i.e. you can modify it according to your requirements.
I'm happy to work with RhinoCAM and MadCAM, but so far there has been little interest.
What do you believe is the most commonly supported 5-axis postprocessor?

Best,
Johannes
Title: Re: Roughing ?
Post by: Wall-E on February 08, 2016, 10:55:35 AM
Hi Johannes,

Yes, I tried the C# component on all the attached .nc files, with no luck.
I'll try to tweak it, although C# is quite alien to me.

So there's little interest in Rhino-compatible CAM ?
Wow... maybe there's little interest in CAM then, or maybe I'm the only wide mouthed KUKA|prc user...
Now if I mirror the question : why would there be a bigger interest in SprutCAM which does not offer a free version and does not work within Rhino ?
Just curious as to why SprutCam is such a wise choice...

As for the most commonly supported 5-axis post-processor... Gosh... all these post-processor names are based on brands and machine names, not number of axii.
Since I'm such a rookie regarding milling, maybe the best idea would be to conduct a poll within a milling forum.
Let's see what I can find...
Title: Re: Roughing ?
Post by: Johannes @ Robots in Architecture on February 08, 2016, 11:24:17 AM
Hello,

I meant that I was e.g. in touch with RhinoCAM and there was little interest from them in a more direct way of getting data from their system to the robot.
Don't forget that a major part of the business model of CAM companies is selling customized postprocessors to their customers.
SprutCAM is included because we've been working on it and it has got a very nice postprocessor generator.
KUKA|prc mostly grows through our projects and research, and it's the same case here.

And for your G-Code samples: You can just replace (via Notepad or similar) any X with "X ", any Y with "Y " etc. and I think that it should work. I've also slightly modified the C# component (attached).

Best,
Johannes
Title: Re: Roughing ?
Post by: Johannes @ Robots in Architecture on February 08, 2016, 11:25:00 AM
...I tested it with the AXYZ.nc file, by the way.
Title: Re: Roughing ?
Post by: Wall-E on February 08, 2016, 11:37:37 AM
I just read a few articles on the subject, and it seems that post-processors and their many variants is a subject of trouble in the milling business.
Tried the new C# component with "AXYZ.nc" ; still  no joy.
Made a version with spaces. No luck either.

Did it work on your side ?
Title: Re: Roughing ?
Post by: Johannes @ Robots in Architecture on February 08, 2016, 12:22:34 PM
Here's the combination of files that definitely got some output.
Just note that your G-code is very tiny, either using centimeter or inches as units (I guess).

Best,
Johannes
Title: Re: Roughing ?
Post by: Wall-E on February 08, 2016, 01:14:08 PM
Johannes,

EDIT : it works ; silly me put the GH file path instead of the .nc
(couldn't delete the attached file ; therefor had to admit being stupid again)

This should give me a neet (and free) 3-axis roughing workflow.
For the surfa├žing, I'm really happy with the use of MeshMachine ; I just need to code the re-ordering of the vertices so that it makes a suitable path for the tool.
I made the polyline path for my fin mold by hands...

Cheers,


Title: Re: Roughing ?
Post by: Wall-E on February 08, 2016, 01:20:49 PM
Johannes, could you send me a sample of "valid" .nc file ?
One that can be read by the "Import G-code" component.
That way, I can look for the FreeMill post-procssor that comes closest, and start from there.

Thanks !
Title: Re: Roughing ?
Post by: Johannes @ Robots in Architecture on February 08, 2016, 05:26:36 PM
Hello,

I attached it to Reply #17, above!
It shouldn't be a big problem to implement e.g. a 3-Axis Mach3 G-code import into KUKA|prc. The only thing that can be annoying are the CIR movements.

Best,
Johannes
Title: Re: Roughing ?
Post by: Wall-E on February 08, 2016, 09:30:46 PM
Hey Johannes,
 I opened the sample you sent me (Ring01uten...) and I find that the trajectory is inside the robot, so I thought it would be a good exercice to learn how to move KUKA|prc commands.
Obviously, it works well for the linear movements, but the not the circular movements.
Maybe a special "Transform" component dedicated to commands could be handy, or is it just that I got all muddled again ?

Cheers,
Title: Re: Roughing ?
Post by: Johannes @ Robots in Architecture on February 08, 2016, 09:40:08 PM
Hello,

An important concept of using a robot are local coordinate systems. You calibrate them via three points (Startup/Calibrate/Base/Three Points) and get XYZABC values that define how your local coordinate system is placed in relation to the robot. Every base (= local coordinate system) also has got a number.
In the KUKA|prc settings you then enter the base number and the approximate values (only the number is written into code, i.e. you don't have to got for tenths of millimeters as it will only affect the simulation.
This way, you do not have to arbitrarily move your commands around space, but just define with the robot where the Rhino coordinate system would be in physical space.
With milling, ideally work in a way that your coordinate system is on top of the workpiece and the geometry below, as this makes it easy to reference the workpiece.

Hope that helps!
Johannes
Title: Re: Roughing ?
Post by: Wall-E on February 08, 2016, 10:15:19 PM
It does help indeed.

I know the concept of base, and have defined a couple of them just for practice.
But since I never absolutely needed to define a custom base, and I am mostly experimenting very different things for the moment, I assumed it was wise to keep using the Base 0 which is defined in my case as the robot's "world" coordinate system.
I can understand why it makes sense to use bases, although I fear it can also lead to trouble if referencing the wrong base.
It happened to me once, and I thought it would probably be a good idea to expose this as an input parameter, just like the tool, instead of being insite the KUKA|prc settings, you know, for the goofballs like me.

Cheers,
Title: Re: Roughing ?
Post by: Johannes @ Robots in Architecture on February 08, 2016, 10:18:13 PM
Actually just because of that I do NOT want to expose it as a parameter, as it should be entered "consciously" rather than as an arbitrary slider value!

Best,
Johannes
Title: Re: Roughing ?
Post by: Wall-E on February 08, 2016, 10:26:11 PM
I understand...
Maybe the tool number and the base number could just be displayed on the component somehow...as a reminder.
Making programs involves a lot of "Save as", and you can easily forget that you don't have the proper base if the number is hidden from view, don't you think ?
Title: Re: Roughing ?
Post by: Wall-E on February 25, 2018, 08:27:01 PM
Stuck with CIRC movement problems again, with the Fusion post-processor : "Start point equal to mid-point".
Can't seem to get the circles straight ? Ha ha.
Title: Re: Roughing ?
Post by: Johannes @ Robots in Architecture on February 26, 2018, 07:46:49 AM
Hello,

I replied to your other post!

Best,
Johannes