1. Got a question or need help troubleshooting? Post to the troubleshooting forum or Search the forums!

Linux software for the Robo 3D R1+ (and other 3D printers)

Discussion in 'Software' started by Rod Smith, Nov 25, 2017.

  1. Rod Smith

    Rod Smith Member

    Nov 7, 2017
    Likes Received:
    It's been two weeks since I received my Robo 3D R1+ printer. When I asked on this forum about Linux support, I received little in the way of detailed information, so I thought I'd write up my findings in over two weeks of investigation of this issue. (I began looking into it before ordering the printer.)

    I've tried, to varying degrees, six programs (plus some dabbling with OctoPrint's slicer plug-in):

    • ideaMaker
    • CraftWare 1.14 beta #32757
    • Slic3r 1.2.9
    • MatterControl 1.7
    • Repetier-Host 2.0.5
    • Cura 3.0.4

    I describe my experiences with each of these slicers in turn, with some opening comments and discussion at the end. Note that this post emphasizes the Linux versions of these programs. They may perform differently on other platforms. This is especially true of the programs' stability, which is abysmally poor, on average, under Linux.

    Note that I'm a Linux expert -- I've written over twenty books on the OS and work in the industry. Thus, although I'm still very new to 3D printing, if you've got Linux-specific questions, please feel free to ask me.

    General Setup

    My plan from the beginning was to use OctoPrint running on a Raspberry Pi to control my printer; however, I began with an attempt to set up Robo's default/recommended MatterControl under Linux (Ubuntu 17.04, to be precise) to talk directly to the printer. This seemed like a much simpler approach than using OctoPrint; however, I ran into problems with this attempt because of what I eventually learned were permissions issues. When the Robo was plugged into the computer, Ubuntu's configuration gave it a device file, /dev/ttyACM0, with ownership by root:dialout; but my normal user account was not a member of the dialout group, and so could not access the printer. The solution is fairly simple: Add the regular Ubuntu login user to the dialout group. Note that the details of the solution may vary from one distribution to another; distributions differ in how they set up accounts and permissions, so non-Ubuntu distributions may require slightly different solutions. The symptom of failure, at least in MatterControl, is that the program never progresses beyond an "attempting to connect" message.

    Eventually, I set up my Raspberry Pi (mine is a version 3 model B with built-in Wi-Fi) using the OctoPi 0.14 image. This was easy to set up, at least for me. (My Linux experience helps.) Other pages, like this one, describe OctoPi setup, so I won't cover this topic in detail. When I plugged in the printer, OctoPi detected it fine, although I did need to configure some settings details, such as the build size. (I used 222x245x200mm, XxYxZ, based on figures I found online somewhere. I used the same figures in all of the below programs.)

    If you're completely new to 3D printing, you should be aware that there are basically three things that need to be done to print, although you may need just one program to get started:

    • Design an object -- This task is done with 3D modeling software such as AutoDesk's AutoCAD or the open source FreeCAD. If you download .stl files from Thingiverse or some other site, this task has already been done for you.
    • Slice an object -- This step converts a model file in .stl or some similar format into g-code, which is a layer-by-layer description of the object suitable for printing. The programs described in this post are all slicers, which do this task -- and often the next. (Note that slicers can be further broken down into the slicing library, which does the bulk of the work; and their user interface front-ends, which enable you to control them. Some slicer front-ends enable a selection of different back-end libraries, but for the most part I ignore this distinction in this post.)
    • Send the file to the printer -- This task can be accomplished by a slicer that directly controls a printer (but that must be connected and running throughout the entire print); by sending a file via a network connection to a network-enabled printer or to a computer running OctoPrint; or by putting the file on an SD card and having the printer read it. In that last case, you must still have some means of telling the printer to read the file from the SD card. In the case of the Robo 3D R1+, this will normally be done via MatterControl or some other slicer program, although many users have add-on control panels to help with this task. In my case, I'm using OctoPrint, which effectively adds Wi-Fi features to the Robo 3D R1+. Thus, my testing of direct connections between slicers and the Robo is minimal at best; I've tested this only with MatterControl. Others might or might not work to directly control the printer.

    Note that OctoPrint both simplifies and complicates configuration of a 3D printer. Because it's network-enabled, there's no need to dedicate a computer to controlling the printer or use sneakernet to move files over to the printer, 1980s-style. OTOH, it's an extra thing to configure and that can go wrong. Also, most slicers can't "talk" directly to OctoPrint. This might necessitate saving sliced g-code files to disk and then loading them onto OctoPrint using its Web interface; however, there is a workaround: You can set up a file server (such as NFS or Samba) on the OctoPrint box and then save g-code files from the slicer to the /home/pi/.octoprint/watched directory (or perhaps /home/pi/.octoprint/uploads, although the latter requires re-loading the OctoPrint Web page to register the upload). You'll still need to initiate a print using the OctoPrint Web UI, but transferring the file is marginally easier this way.

    In addition to getting the printer to work in a minimal way, I found that I had to invest considerable time in tuning its parameters. Getting the Z-axis correction setting correct (via the M565 g-code command) was particularly tricky; see this thread for a summary and links to some other resources -- and thanks to mark tomlinson and WheresWaldo for help on this and other issues! In fact, I'm still fine-tuning my configuration; but these issues aren't particularly Linux-specific, so I won't dwell on them here....

    I currently use Ubuntu 16.04 on my main desktop, with Ubuntu 17.04 installed on a laptop I've been using in the same room as the printer. Thus, most of my testing is under Ubuntu 16.04, but some is under Ubuntu 17.04. Other distributions may behave differently, and of course this detail is important when it comes to software installation.

    The following sections describe the slicer programs I've tried, in more-or-less the order of my preference for them. I've tried a variety of 3D models with all the slicers, some of which are simple or even trivial, and others of which are not. Two in particular are 3D Benchy, which is a fairly standard 3D printing benchmark; and this Homo erectus skull model, which proved extremely challenging for most of the slicers. I've actually printed the 3D Benchy model from the first four of the below slicers. I've printed the Homo erectus model, or variants of it, at 40% scale, from ideaMaker and CraftWare, and I attempted a full-scale print from ideaMaker, but it failed because of broken supports about 2/3 through the print -- a frustrating experience!


    This is a fairly new slicer, distributed for free by Raise3D, which sells its own printers. You can download ideaMaker here. This program can be used with other manufacturers' products, but of course you're subject to the manufacturer's whim; they might decide to charge for the program or restrict it to their own printers in the future.


    • IdeaMaker is fast at slicing (probably the fastest I've tried).
    • IdeaMaker has a fast user interface -- it seems to make good use of OpenGL. I had problems once, though; ideaMaker became very slow, and I had to reboot to fix the problem. I suspect that Cura put OpenGL into a state that was causing errors, so I'm reluctant to blame this one on ideaMaker.
    • This program was the most stable of those I've tried. It has crashed once or twice, but not on a regular basis, which is better than can be said for some others.
    • IdeaMaker provides manual supports, which are often helpful, and sometimes necessary, to get a good print.
    • IdeaMaker's sliced files are most likely to print successfully, in my experience. This seems to be because its first-layer speed settings apply to skirts, brims, and rafts; with some other slicers, these features print at warp speed, which causes all manner of problems. IdeaMaker produced the best Benchy results in my tests.
    • Its default rafts peel off relatively easily and cleanly.
    • IdeaMaker's print time estimates are more accurate than others, and print times are often a bit shorter.
    • The program has a repair feature that warns about errors in .stl files and enables their repair. (Other slicers seem to handle some of these errors OK -- or maybe they're the cause of some of the crashes I've experienced....)
    • The program has a "lay flat" feature to drop a specific surface onto the print bed. It's buried in the menus, though.
    • IdeaMaker is available as 64-bit .deb file.


    • IdeaMaker has awkward slicing settings -- you need to modify templates to make changes that are likely to be necessary for individual prints (e.g., infill percentage, filament temperature, etc.). These templates hold most such options in one big data set. Compare this with Slic3r, which separates settings into "print," "filament," and "printer," with each configuration type saveable as a separate template. Consider a scenario in which you want to print regularly at three resolutions ("print") with four filaments on two printers. With ideaMaker, this would require 24 templates in a long list. With Slic3r, it would require 9 templates, 2-4 in each of three categories. The latter approach is much more manageable.
    • When saving sliced g-code file, if the ".gcode" extension is omitted, the save fails and it becomes necessary to re-slice the model.
    • Per-layer settings are limited; AFAIK, the program can adjust only fan speed, not extrusion temperature, infill, etc. (I've seen claims that per-layer extrusion temperature adjustment is coming for version 2.7, though.)
    • If supports are added to a model but disabled in a print template, the program asks every time the model is sliced whether to add the supports. This gets annoying fast.
    • The program provides few infill options (just grid and recilinear).
    • When saving a .gcode file, ideaMaker also saves a binary .data file. This seems to confuse OctoPrint when you save the files to the watched subdirectory, resulting in the .gcode file not appearing as a print option. Saving to the uploads subdirectory works fine, although the .data file takes up disk space unnecessarily.

    General comments

    Its speed, stability, and print reliability make this my favorite of the lot, although its UI can be aggravating and it's missing a few features I'd like it to borrow from other programs. It's handled every model I've given it, although it did begin crashing when slicing the Homo erectus model at one point, I suspect because of a particular set of slicing options. (It sliced fine at other times.)
    mark tomlinson and WheresWaldo like this.
  2. Rod Smith

    Rod Smith Member

    Nov 7, 2017
    Likes Received:
    CraftWare 1.14 beta #32757

    Like ideaMaker, CraftWare has been released as free (as in beer), but not open-source, software by a printer manufacturer, in this case the Hungarian CraftBot. It can be downloaded here. It provides a UI similar to ideaMaker's or Cura's, but it's a little rough around the edges, including one hideous display bug (see below).


    • CraftWare's standout feature is a preview when adjusting slice settings. This preview shows you what effect some (but not all) slice settings will have, such as adjusting the first-layer height or the infill pattern. This is great for newbies!
    • The program is fast at slicing (but not quite as fast as ideaMaker).
    • CraftWare seems to be roughly as stable as ideaMaker, although it's got a few more bugs (see below).
    • Craftware enables editing of manual supports.
    • The program has a prominent "drop plane" feature to drop a specific part of the model onto the print surface.
    • It's available as a 32-bit .deb file (see below)


    • The program suffers from a "beach ball" rendering bug when slicing -- a large multi-colored sphere is superimposed on the slice display, blocking most of it at any given moment, making the slice preview nearly useless. I saw claims in a forum thread from over a year ago that this bug has been fixed, but the fixed version doesn't seem to have been released yet. The bug report indicates that it's more common on some displays than on others. Perhaps I've been unlucky, but it shows up on both my computers. FWIW, this bug seems to exist on all platforms -- Linux, macOS, and Windows.
    • Although the program is generally stable and capable of slicing models, it choked badly and crashed on one -- the top portion of a kitchen sponge rack. Both ideaMaker and Slic3r handled this model fine.
    • Per-layer settings are limited; you can disable the fan for the first n layers, but that's about it.
    • Model rotation and move features seem awkward (but maybe that's just because I've used ideaMaker more).
    • 32-bit binaries!? Really? Sure, I was able to install them, but what year is this, 2000? A Linux newbie might have problems fixing 32-bit library dependency problems.
    • With some models, printing is spastic -- the printer lays down one short line, then moves halfway across the bed, lays down another line, moves another short distance, lays down a short line, move back to close to the first position, lays down a line, etc. This needlessly increases print times and could increase stringing (although in practice it doesn't seem to do so).
    • Its rafts stick too well to the model, although they aren't as bad as MatterControl's. There are detailed raft options in the slicer, so this problem might be correctable.
    • As with ideaMaker, all slicing options are glommed together in one mega dialog box, and can be stored as templates. Getting to this dialog box doesn't take as many steps, though, so there is that plus.

    General comments

    This program's strengths are similar to those of ideaMaker, but its slice preview "beach ball" bug is close to being a deal-breaker. Its Benchy wasn't quite as good as ideaMaker's, but I think with a little tweaking it could be improved. Its standout feature is its graphical preview of slicer settings, which I found very helpful in learning what they all mean.

    Slic3r 1.2.9

    This is an open source slicer program, with a Web page here. As an open source program that's not developed by any printer manufacturer, there's little chance that it will go to a for-pay model or that Robo users will be left out in the cold by a future printer-specific update.


    • This is a truly open source (GPLv3) program.
    • It's available as a Debian package in the Ubuntu repository, so there's no need for unusual installation steps.
    • The slicing preview is easily accessed from a tab on the main window, rather than buried several UI layers, as with ideaMaker.
    • Slic3r provides the ability to adjust temperatures for first vs. later layers (but not more finely than that).
    • The UI features good separation of settings into print, filament, and printer, with each set saveable as separate templates.
    • Slic3r can upload directly to OctoPrint (but can't control OctoPrint), even without setting up a file server.


    • The program provides no manual supports, and auto supports tend to overdo it.
    • Slic3r sometimes "loses" its model, requiring a quit and restart.
    • I was able to load my Homo erectus model, but it was very slow, and I was unable to fully slice it (the program hung and eventually crashed).
    • The program is generally slow, both in its UI and in its slicing operations.
    • There's no undo feature.
    • Slic3r's object rotation features are very primitive -- you must type in numbers, first selecting the rotate option from a menu!
    • The first layer tends to print too fast, which produces bed adhesion problems. There are likely settings to fix this issue, but I haven't yet found them.

    General comments

    Slic3r's stability is average -- it's not as good as ideaMaker or CraftWare, but it's better than the others I've tried. Although it's different from most others, I've come to prefer its user interface model, with the exception of some very primitive aspects, like its poor rotation options. If it were faster and more stable, it might become my favorite. I haven't yet tried it with rafts. Note that, because Slic3r is an open source program that's included with most distributions, it should be possible to install it directly on a Raspberry Pi running OctoPrint. I haven't yet tried this, though. Also, given the limited CPU power of a Raspberry Pi and Slic3r's poor showing at slicing speed, I expect that this combination would be excruciatingly slow with any but the simplest of models.

    MatterControl 1.7

    Like Slic3r, MatterControl is an open source (BSD 2-clause) project; however, it's not included in the Ubuntu package set, so it must be installed separately (see below). Its Web page is here. This is (or was?) the official software provided by Robo, but their Web site provides download links only for the Windows and macOS versions.


    • MatterControl provides a simple and direct user interface, which is good for beginners.
    • The program has produced decent prints without too much tweaking of options.
    • MatterControl can talk directly to the Robo R1+ printer, including uploading firmware.
    • The program seems to give an option of the slicer library to use, but on mine, it lists only MatterSlice.
    • MatterControl is available as a Debian package from its maintainers (but see below).


    • Its rafts stick too well to prints. In some cases, I've been unable to fully remove rafts.
    • The simple user interface lacks options for adjusting some important features, like raft details that might fix raft problems.
    • The program is slow. (It relies on C#/mono, despite being distributed as a Debian package.) I don't think it's quite as slow as Slic3r, though.
    • MatterControl is prone to crashing. (It crashed when slicing the Homo erectus skull model, among other times.)
    • It provides no manual supports, just automatic supports. I haven't used the automatic supports enough to know whether they're well-calibrated to actual needs.
    • Under Ubuntu 17.04, it hangs upon importing a new model; it must be killed and started up again, whereupon the imported model appears in the queue. (This does not happen under Ubuntu 16.04; I suspect a mono issue.)

    General comments

    I started out with this one, and it was OK at first; but I quickly moved on to ideaMaker. I used to fall back to MatterControl if I had problems getting a print to work, but now I use CraftWare or Slic3r for that.

    Repetier-Host 2.0.5

    I've used this software the least of any of the programs described here, so this summary is pretty sparse. Repetier-Host is free (as in beer) but not open-source. The developers' "About Us" page describes development as being a "full-time hobby." See here for the main page.


    • Offers choice of slicers -- curaengine, slic3r, and slic3r prusa edition are options.
    • Probably more, but my experience is very limited.


    • This is another mono application; it ships as a .AppImage file
    • I don't see a way to specify manual supports.
    • As with Slic3r, this program provides primitive object rotation features -- you must type in numbers to rotate an object.

    General Comments

    I haven't yet actually attempted to print anything with this one. It seems to have a fair amount of power, but still be missing some important features, like manual supports and good object rotation. I haven't attempted to load the Homo erectus skull "torture test" model, so I don't know how it would cope with it.

    Cura 3.0.4

    Ultimaker is the hardware developer behind this software. Like ideaMaker and CraftWare, Cura is available for free and can be used with many printers, but you're still subject to its manufacturer's whims. You can download it here. I've used it relatively little because of the first "con," so I have relatively little to say about it. Note that Robo has switched from MatterControl to Cura as its default software for its newer models; but this seems to be a step down for Linux users.


    • Cura features a relatively simple UI, which is good for beginners.
    • The program automatically slices the model once it is loaded.
    • It can talk to OctoPrint without the use of network file shares.


    • In my testing, Cura HUNG THE COMPUTER ONCE, AND HUNG X ANOTHER TIME! This is impressive -- and inexcusable! This factor alone means Cura is unacceptable for use with Linux.
    • The program takes a ridiculous ~45 seconds to launch on my main desktop system. (I haven't tried it on my laptop.)
    • Once loaded, Cura is slow, both in its UI and in its slicing.
    • I see no way to specify manual supports.
    • There's no obvious way to center a model; this made it very difficult to center my Homo erectus torture-test model at full scale. (It fits in the Robo R1+'s build volume, but only when rotated in certain ways.)
    • The program ships as a .AppImage file; there's no Linux installer.

    General Comments

    I've been unable to get a successful print out of Cura; however, given the program's impressive ability to take down my main working system, I haven't really given it much effort. (The two or three attempts I've made ended up with the print head tearing up the first layer; I suspect overextrusion or Z-axis problems.)


    I've listed these programs in my order of preference; however, my preferences might change with more experience or with new versions of any of the above

    I've given a fair amount of weight to the programs' handling of the Homo erectus "torture test" model; only ideaMaker and CraftWare seemed to be able to handle it. (I haven't tried with Cura or Repetier-Host, though.) With less challenging models, Slic3r and MatterControl both become more competitive, particularly if there's little need for manual supports, careful rotation of the model, or other intermediate or advanced features.

    I didn't see RPM files for any of these programs, except for Slic3r. If you're using Ubuntu, or conceivably another Debian-based distribution, the .deb packages of ideaMaker, CraftWare, and MatterControl can help with installation; but if you're using Fedora, OpenSUSE, Gentoo, or some other non-Debian-based Linux distribution, a Debian package will need to be converted with the alien utility, and might not install thereafter. For these distributions, the .AppImage format used by Cura and Repetier-Host is likely to be easier to install -- but these look like the least desirable slicers, in my experience.

    The speed and stability of ideaMaker, and to a lesser extent CraftWare, make them the clear winners in this comparison; however, Slic3r has some features that make it appealing, particularly for non-Debian-based distributions.

    OctoPrint provides a slicer plugin module, so in theory, you can do away with the slicer software running on a regular computer, and simply pass the .stl file to OctoPrint. OctoPrint's slicer, though, is Cura's backend, and configuring it requires passing a .ini file from an old version of Cura. I tried feeding it the cura.cfg file from my Cura 3.0.4 installation, and the OctoPrint Web UI seemed happy and was able to slice a file; however, it failed to print in the same way my native Cura prints did -- by tearing up the first layer. Perhaps investing more time in it would make this option workable, but I'm unmotivated to do so. Even if it worked, I see no way to fine-tune options on a per-print basis except by using Cura to prepare a new set of configuration options to send to OctoPrint as a new template, and that would be more awkward than using a slicer on my desktop or laptop computer and then uploading the finished .gcode file. Also, of course, the limited CPU power on a Raspberry Pi means that slicing any but very simple models would likely take an annoyingly long time.

    I hope somebody finds this tome useful. I'm still learning these programs, but I feel I've got enough experience with them to be able to pass on some knowledge.
    mark tomlinson and WheresWaldo like this.
  3. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Feb 21, 2013
    Likes Received:
    Probably because there are few people using Linux with their Robo3D :) As a guess at least...
    Thanks for the detailed write up! This is exactly what we need, folks to be the pioneer and document the saga.

Share This Page