I was pretty much set on buying the SKR Pro v1.2 and use the Marlin firmware, but now I’m unsure! As CAM software, I’d prefer to use either Fusion360 or more likely MeshCAM and neither seem to have post-processors for the MPCNC with Marlin. Grbl seems to have better support across the board.
As a macOS user I’m currently restricted to only few options, when it comes to CAM software and I really dislike Fusion. I use Rhino and Blender for my modelling needs.
MeshCAM thus seems like an obvious choice. It’s also reasonably priced.
Am I overlooking something here? Does anybody have some experience with Marlin and MeshCAM?
For years the guffy post processor was the one used for Fusion 360. Recently Don Gamble forked the project and made significant improvements (Thanks Don). You can find a link to his latest version in this topic. Note his version of the post processor also supports GRBL if you end up with that firmware.
Before answering your question, I did some searching, and found no reference to someone using MeshCAM with Marlin. On the other hand, it is possible that the output of one of the MeshCAM post processors is generic enough that it will work with Marlin. I found this to be true for Easel.
If you have MeshCAM, consider generating some g-code and attaching it to a post. We can take a look and give you a good idea about using it with Marlin. According to this page, output from the Mach3 and Shapeoko post processors are the most generic and therefore have the best chance of working.
Edit: Just stumbled on this six-year-old post by Ryan. He had it working on what I assume was Marlin, which reinforces the .idea that one of the post processors is generic enough to use with Marlin.
Edit2: Just found another post of a MeshCAM user. He did his mods to the model in MeshCAM and then exported the model to EstlCAM to generate the g-code.
Yes, I found some pretty old posts here and in some other forums that point that out, too. However, I’d hoped that someone could share a more recent account or workflow.
That’s super nice of you!
However, I probably won’t waste my MeshCAM trial period, before I have finished my MPCNC build, which will probably take me another couple of weeks. I’m not going to buy MeshCAM, until I know that it works.
The Mach3 and Shapeoko post-processor seem to be compatible with Grbl only. I’m rather looking for Marlin compliant gcode.
Here’s another, more recent forum post that - like @Ryan’s -, points out that the TurboCNC V3 post-processor from MeshCAM might work:
It seems like the gcode header needs to be changed though. I guess I could potentially automate that with a Python script, a post-post-processor so to speak.
Thanks for your reply.
If nobody else chimes in, I’ll try to clear things up myself and will keep this thread updated with my findings!
I just took a look. Just know you will absolutely need the “pro” version. 2D pockets are a very, probably, the most common thing you will do. Post processors are extremely easy to write, they say they will do it for you for free. You might want to email and see how responsive they are to that claim. Really all we need that is any different is speed broken out on each line and the ability to control XY, and Z speeds independently, including rapids.
Looks like if you choose that software you will be going at it mostly alone. I have no real memory of anyone around here running it, or how it does.
A MAC alternative would be onshape, Free for hobbyists, pretty expensive if you need to pay. Estlcam seems to reportedly work fine under parallels so I highly highly recommend going that route. At least at first. CAM can be the steepest learning curve on this whole project if we know what you are running we can easily steer you to a working project, after that feel free to venture out. Last thing you want is a new machine, new software, new post processor…you will never know where the issue whne you have one.
I wasn’t exactly sure what they meant by the “2D Pocket Toolpath” feature that is only available in the pro version. Doesn’t this just apply when you import a two-dimensional drawing (e.g. DXF) and want to define pockets where “holes” or voids are drawn? Couldn’t this easily be circumvented by simply importing a mesh (e.g. STL) that has the pockets, holes, and everything modelled?
What? Where have you read that. I’m going to email them and see.
Noted. What exactly are rapids?
Also noted.
OK, but Parallels is €79.99, Windows 10 Home €136.99 (if I get an official license), and EstleCAM €60, which amounts to €276, which is more expensive than MeshCAM (unless I get the pro version) for a non-native macOS workflow. Honestly, I doesn’t seem worth the hassle.
Yes, I get that. Fusion360 is still an option, if I can’t get MeshCAM to work.
Thank you very much for your detailed reply! It’s appreciated.
“Rapids” means rapid movements which are typically non-cutting movements to reposition the router. Because MPCNC uses a leadscrew for Z and belts for the X and Y, the maximum feedrate for the Z axis is significantly smaller than for X and Y. That is why the Ryan indicates that the Rapids need to be broken out separately. You could limit X and Y feedrates to the same limit as Z to get around the problem, but your cutting will take longer.
Estlcam uses it to define spindle speed. Likely that’s a default speed that was left behind when the pen tool that he used was defined. If you don’t give your machine direct control of the spindle, it doesn’t do anything in Marlin. (Well, it probably sets a pin somewhere, but if it’s not connected, it doesn’t matter.)
I heard back from GRZ Software, the creators of MeshCAM.
Concerning Marlin compatibility, they wrote that I could try the Grbl post-processor, since it “outputs very basic gcode”.
Generally, they recommend to use Grbl instead, because “people have a hard time using ‘normal’ gcode meant for CNC machines with Marlin”. Whatever that means?
There was no talk of adapting a post-processor to my needs or similar.
Concering the 2D contour toolpath and 2D pocket toolpath being only available to pro version users, I seem to have been right. This only concerns gcode generation from two-dimensional CAD files. If you load a three-dimensional object with pockets and holes everything should work fine! They recommend to simply do a “roughing and unified finshing toolpath”.
What do you guys think of running the mpcnc (with dual endstops) with Grbl? Is this even possible?
There are certainly GRBL releases that support things like the dual endstops, though we’ll be limited in how much support we can give you for it here.
Honestly, I’d stick with the V1 supported Marlin release, until or unless you are familiar enough with the software chain and firmware to make your own modifications. I know that there are people here using Fusion360 for CAM and exporting that to MPCNC machines. Less certain about MeshCAM, but it doesn’t sound like they want to “go there.” I’d bet on it not being too difficult to convert though.
If it absolutely has to be GRBL, I’d probably look at something like Bart Dring’s 6-pack controller which can manage 6 motors (2x X, 2x Y, 1x Z) though you’ll need a couple of the 4x input modules. 4x endstops + touch plate, so minimum 5 inputs) and maybe the relay module for spindle control.
You could hedge your bets and go with a Rambo board instead of an SKR Pro. According to this topic, there is a GRBL version that runs on a Rambo board and supports dual endstops. So you could start with Marlin, and if you needed to go to GRBL, you would have that option without buying a new board.
This, is a popular mantra when you talk to experienced Cnc folks about getting in to it. I heard it a few times myself… still curiosity prevailed and I gave both a try. I stuck with grbl, but I bet more than half the folks who try the same would not. It is what it is… folks made decisions a while back about supporting Marlin vs grbl, and Marlin was chosen since most folks entering Cnc here have printer experience… not because Marlin is better at Cnc, grbl is hands down. In fact I think the mpcnc project alone is responsible for making Marlin jump through Cnc hoops (the major proportion of the new Cnc related Marlin changes of late are there due to Ryan and the gang doing their thing).
Edit… bottom line it certainly would not be a dumb idea to get a board supported by Ryan… they can all run grbl if you wanted to try that sometime… but if you start off with a non supported board, even if it is the best for grbl… you could make your baptism into Cnc more painful that it is already going to be.
Yeah, that’s a big fear. I for instance have some C++ and general coding experience, as well as advanced CAD and 3D modelling skills, however I’m pretty inexperienced when it comes to homebrew CNC stuff and electronics. I’ve done some small Arduino and ESP32 projects but that’s it. I’ve done lots of 3D printing over the last 5 or 6 years though.
Thanks for another reply, Dan! Especially for recommending the 6-pack controller.
True, thanks. Although the Rambo boards seem to be disliked for some reason.
I’m curious, why did you stick with it and why do you think most people would not?
Yeah, seems like sound advice! Thanks for your input.
From my reading of this this forum, I have a different perception. The Rambo is viewed at the tried and true, very robust workhorse of a board, vs the SKR Pro as the flashy newcomer. I’ve see people on this forum make hardware mistakes with the Rambo that would fry other boards, and it comes out unscathed. The SKR Pro with its 32-bit processor and hardware math support edges out the Rambo on fast(er) laser burning, but I’ve never seen any indication that that the SKR Pro is better at CNC Router speeds.
You are now choosing a board and an ecosystem because of a piece of software you have not tried, and honestly has not shown up around here very much at all over the years. What about kiri:moto?
I hope this doesn’t come off poorly but most CAM software packages have a guide to making your own post processor and allow you to make changes. If they do not have that or basic Marlin PP then you might want to reconsider. I have written PP’s for CAM packages I have never even used. I am a amateur programmer at best but they are simple they only involve outputting numbers in a specific order. Marlin might not be the absolute best Firmware for CNC but it has to be the second most common in the non-pro space (it might even be the most common simply because of the number of boards supported).
Once the firmware is chosen and the board is picked, getting it working is a bit of a hurdle. After that though, you honestly never actually need to change it (unless you want some fancy new feature in the firmware) and the PP is behind the scenes. Every job you will interact with the CAM package so that is the most important choice. Most any board will work and will quickly become an after thought to your actual projects.
I haven’t made my final choice yet, but understand that as a macOS user I came across MeshCAM and it seemed like a sound program and very beginner friendly, from what I’ve seen in videos, even more than the Windows-only EstlCAM, which I’ve also taken a look at. I’ve even tried to virtualize it with Crossover and Wine, but both attempts didn’t work.
What about it? Cura is my favorite slicer for 3D printing.
You’re right, but Fusion360 seems to be my only alternative and I’ve yet to test if their TurboCNC V3 post-processor does work with Marlin indeed. I’m currently busy building the table that the MPCNC will sit on, which might be more work than actually assembling the machine.
Fully understood. We are all just trying to point out you are going down a path few here, if any have taken. If you choose that path, we won’t be the best place to get help.
It has CAM functionality.
It is not.
We have two fully functioning Fusion post processors available fully tested, linked on the milling basics page. I am not sure if that Turbo is one of them.
This was to point out I find it odd that they will not expand their PP’s to include a Marlin version, it is not complicated from my past experiences writing and editing a few of them.
The Guffy’s/Don’s post processor for Fusion 360 I pointed you to above should work on the Mac. Custom post processors for Fusion 360 are installed as plain text files, so I assume they are either dynamically compiled, or the code is interpreted. Either should work for the Mac environment.
