Search

[Johannes @ Robots in Architecture]

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

[Xylotica]

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,

[Johannes @ Robots in Architecture]

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

[Xylotica]

Me stupid.

[Xylotica]

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

[Johannes @ Robots in Architecture]

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

[Xylotica]

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...

[Johannes @ Robots in Architecture]

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

[Johannes @ Robots in Architecture]

...I tested it with the AXYZ.nc file, by the way.

[Xylotica]

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 ?

[Johannes @ Robots in Architecture]

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

[Xylotica]

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,

[Xylotica]

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 !

[Johannes @ Robots in Architecture]

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

[Xylotica]

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,