searching GNU CNC Gcode generator

hi guys

to design stuff i am using rhino.

now i am looking for a GNU gcode generator to
run a marlin powered CNC with it.
what i am looking for is pretty much Slic3r only
for CNC and not 3d printing

regards red

Good luck with that.

CNC is subtractive manufacturing, and must take in more variables than additive manufacturing (3d printers).

Machining away material requires a different approach, and will need dedicated firmware.
Plus some kind of CAM software to develop the tool path, along with a post to generate the G-code for the intended platform (machine).
Then there's stuff like work holding for the stock (material), that has to be taken in account while programming.
Not to mention the tool selection. Most items require multiple tools to complete features in a very specific order of operations.

As a Journeyman CNC machinist/ Moldmaker, it's easy for me to machine almost anything from anything to specified tolerances and surface finish.
Oh yea, and there's always a dozen or more ways to machine something.

Check out the CNC area of these forums for better help:
[forums.reprap.org]

Toolpath generation for subtractive manufacturing is called CAM. There are some open source CAM packages available, but they are quite limited.

Be aware that unlike 3d print toolpath generation, CAM is a very complicated process that can cause a lot of expensive damage if done incorrectly. The software is not automatic and requires considerable experience to use.

Also note that most 3d printing control boards will not support enough of the G-Code standard to be useful for anything beyond extremely basic milling.

... you can start with LinuxCNC - [linuxcnc.org]

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

I'm using Fusion360 to design parts and generate CNC toolpath in Mach3-compatible mode.
My mill runs a DuetWifi with RRFirmware. There are a few commands it doesn't know ( yet ) and ignores them. DC42 will implement them in one of the next RRF versions.
For now, I have to edit the file manually or do some initialisation stuff from the web-interface's command line. No big deal.

Quote
prot0typ1cal
Machining away material [...] will need dedicated firmware.

Not really. For basic CNC machining one needs (synchronized) G1, F and some spindle on/off means. Bonus scores for G0 and G92. All 3D printing firmwares I'm aware of support this. In fact, all of them are pretty overfeatured for something as simple as CNC milling.

CNC milling specials like cutter compensation are nice and dandy, but useful for manually written programs, only.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
redblunt
now i am looking for a GNU gcode generator to

AFAIK it's not a GNU project, still it's Open Source and looks pretty promising: [www.youtube.com]

Apparently FreeCAD developed a reasonable decent path generation recently.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
Traumflug
CNC milling specials like cutter compensation are nice and dandy, but useful for manually written programs, only.

I'm thinking more about work offsets, probing (not the z-bed kind), tool tables, etc... CNC without support for toolchange is extremely painful.

Quote
691175002

Quote
Traumflug
CNC milling specials like cutter compensation are nice and dandy, but useful for manually written programs, only.

I'm thinking more about work offsets, probing (not the z-bed kind), tool tables, etc... CNC without support for toolchange is extremely painful.

And silly little things like circular interpolation...

Quote
691175002
I'm thinking more about work offsets, probing (not the z-bed kind), tool tables, etc... CNC without support for toolchange is extremely painful.

I thought we were talking about milling here. Machines coming with a tool changer (what a luxury) most likely have a firmware already, no need to replace that one.

Quote
prot0typ1cal
And silly little things like circular interpolation...

RepRap firmwares do support circular interpolation. Even if this isn't needed, because G-code generators happily generate code without G2/G3, doing the interpolation as part of the generation.

I've done this dozens of times, just recently I milled a nice molding cavity with my WolfStrap. G-code generated with Catia, probing done manually, controller Gen7 v1.2, firmware Teacup. Worked flawlessly.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

It's nice firmware is being constantly developed/improved. Might have to make a mill (4-axis) for myself now

Yea, cutter compensation isn't a requirement, though can be very handy in a production environment where consistency in tooling diameter isn't guaranteed (wear, sharpening, etc.)
Not that that is the type of work a DIY mill would be subject to.

Tool length and work offsets are all very useful, even if you don't have a tool changer. You are the tool changer, and work piece placement is always a variable, even if it can be worked around if you know where the part is relative to machine travel BEFORE programming.

For 5-axis milling, 3d cutter comp is insane. Doubt if any 3d printer firmware is willing to spend the effort to implement.

Blah blah blah yea

Quote
Traumflug
I thought we were talking about milling here. Machines coming with a tool changer (what a luxury) most likely have a firmware already, no need to replace that one.

At the hobby level you still toolchange since machining with one cutter isn't a ton of fun. Generally the program will pause and raise the spindle so you can manually swap the tool. If your toolholders repeat in Z you can just look up the new offset and continue; otherwise you can probe the new tool against a height setter and then continue the program.

3D printer controllers also lack basic features such as responsive jogging (since clicking a jog button just sends a G1 command over serial) so even picking up the edge of a part with an edge-finder is really painful. Its the kind of stuff you might not notice if you've never seen it before, but it really slows down the workflow if you are used to mill-specific controllers (which are honestly no more expensive than 3d printer controllers if you have an old PC available).

Edited 1 time(s). Last edit at 10/24/2017 12:53PM by 691175002.

Quote
prot0typ1cal
handy in a production environment

This is RepRap, so hobbyists, no production environment.

Quote
prot0typ1cal
work piece placement is always a variable, even if it can be worked around if you know where the part is relative to machine travel BEFORE programming.

Didn't expect to have to explain such simple things to people talking about production environments.

Work piece placement isn't a variable. X and Y is known from the cutter before, for the first cutter a rather coarse placement is sufficient. Z is simply set (see the hint on G92) after touching the workpiece with the cutter manually. Instead of adjusting tool length one simply moves the coordinate system. Tooltip == Z0 at the touching point is easy to remember, so one generates G-code for that. Has always worked, from ancient non-CNC mills to MAHO with Phillips 232 controller to modern Homags to hobbyist machines like WolfStrap or Mantis.


It's disappointing that such discussions are needed to get feet of owners of $100,000 machines back down to the floor. Such discussions shy people away from tasks they can perfectly do with the tooling they already have or with low budget investments.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
691175002
Its the kind of stuff you might not notice if you've never seen it before

Believe me, I've done this hundreds of times and never needed a tool changer or "responsive" jogging or cutter compensation or length offset or whatever reasons you try to find here for keeping people away from milling.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
Traumflug
Believe me, I've done this hundreds of times and never needed a tool changer or "responsive" jogging or cutter compensation or length offset or whatever reasons you try to find here for keeping people away from milling.

My intention is not to keep people away from milling, it just doesn't make sense to recommend 3d printer electronics for milling when there are alternatives which are more suitable for the task. The only reason to use 3d printer firmware for a mill is familiarity.

LinuxCNC/Mach are low cost or free, and support feedrate/spindle override, proper backplots, the full G-code spec, etc. Mach3 and LinuxCNC also come with conversational/wizards which is a huge timer saver.

I also have experience with low end machines and shoddy conversions, and I think you might find that fully featured software makes the experience more pleasant.

[i.imgur.com]

[i.imgur.com]

[i.imgur.com]

I should clarify that for a certain machine size it doesn't make sense to lug a full parallel port PC around with the machine. If your steppers are small enough to be run off a4988s or whatever the single-board solutions are using nowadays a 3d printer board will be much more compact.

Edited 1 time(s). Last edit at 10/24/2017 01:49PM by 691175002.

Quote
691175002
it just doesn't make sense to recommend 3d printer electronics for milling when there are alternatives which are more suitable for the task.

Let's see what the original question was:

Quote

[...] to run a marlin powered CNC with it.

Apparently he already has such a machine. And now some people here come along with "stop it, doesn't make sense". Nah.

Sure it does make sense! Go ahead!


LinuxCNC is fine if one plans to build an entire new machine, including a dedicated controller PC. Huge investment in terms of time and money. And because it's such a huge investment, mills with printer controllers exist. Much easier. LinuxCNC misses the KISS principle.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

... it's not so big a problem to add a tool-exchanger into Marlin - it's simply a sequence of G-Codes, what can be done with user-buttons in Pronterface, or added as new function into the firmware.

I've modified Marin4Due and Pronterface with different new functions, "tool-boxes", changing between camera and two dispensers, signalizing status-infos per RGB-LED's, setting or reading I/O-ports for triggering program sequences, and more.

So stop complaining, get involved in the theme ...

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

Quote
Traumflug

Quote
prot0typ1cal
handy in a production environment

This is RepRap, so hobbyists, no production environment.

Quote
prot0typ1cal
work piece placement is always a variable, even if it can be worked around if you know where the part is relative to machine travel BEFORE programming.

Didn't expect to have to explain such simple things to people talking about production environments.

Work piece placement isn't a variable. X and Y is known from the cutter before, for the first cutter a rather coarse placement is sufficient. Z is simply set (see the hint on G92) after touching the workpiece with the cutter manually. Instead of adjusting tool length one simply moves the coordinate system. Tooltip == Z0 at the touching point is easy to remember, so one generates G-code for that. Has always worked, from ancient non-CNC mills to MAHO with Phillips 232 controller to modern Homags to hobbyist machines like WolfStrap or Mantis.

It's disappointing that such discussions are needed to get feet of owners of $100,000 machines back down to the floor. Such discussions shy people away from tasks they can perfectly do with the tooling they already have or with low budget investments.

No need to bring me down to Earth. What I was discussing is conveniences, not necessities. Give me the choice between a knee mill or a 5 axis CNC, I'll pick the one I can get the job done faster.

Work piece placement is a variable. That's why there's work offsets. Finding the work piece before programming can be done, so you know where it is in machine coordinates. It's just easier to program offline to work piece zero and offset to that location once you're on the machine rather than bouncing back-n-forth. Unless you prefer to move to a machine XY and then program everything in G91 incremental. G92 can be a work around, which you are effectively making your own G54+ work offset .

And BTW, working on adding a handle jog to RRF currently on a RADDS/Due with PanelDue 3d printer. Only to help dial in my axis for now, and have the intention on light CNC milling in the future.
Think it's really a PanelDue firmware issue, and not RRF, as the IO already exists on the RADDS. Should be just a matter of presenting the correct user interface that monitors the A and B pulses. Atleast that's my approach ATM.



Edited 1 time(s). Last edit at 10/24/2017 04:48PM by prot0typ1cal.

Quote
Traumflug
LinuxCNC misses the KISS principle.

Nice Kelly Johnson reference

Quote
691175002
At the hobby level you still toolchange since machining with one cutter isn't a ton of fun. Generally the program will pause and raise the spindle so you can manually swap the tool. If your toolholders repeat in Z you can just look up the new offset and continue; otherwise you can probe the new tool against a height setter and then continue the program.

I think RepRapFirmware can probably already do that. You can set up macro files on the SD card that are run when you do a tool change, and there is a command to display a message and wait for the user to acknowledge it before proceeding, that you could include in the macro file.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

... It's not so hard to setup a "industrial level" machine with the RepRap-firmwares - actually one of my customers is presenting a new ultrasonic cleaning system with 3 cleaning and one drying baths and an integrated 2-axis positioning and handling system which can grip, slew and release the baskets by manual control or fully-automatic by executing GCode-macros.

I've programmed the software first in OpenAPC in some weeks -- but when the complexity of the graphical IDE got too confusing for the service guys, the project coordinators asked me, if it would be possible to switch to another "more common" programming base before the exhibition - so I reprogrammed the software from scratch in 4 days and changed the Marlin4Due-firmware too for some special functions and handshake-modes ...

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

... not so "hot" anymore - check the date of the last post

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

Quote
VDX
... not so "hot" anymore - check the date of the last post

I believe it's just a company bot spamming their products across CNC/3D-printing related forums..

---

http://www.marinusdebeer.nl/

... suspected it too ... but, let's see -- otherwise it's two mouseclicks away from the bin

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]