Finding my way with Cura 10.06

I’ve been using Cura as my go-to 3D-printer slicer for quite some time now. Compared to Slic3r, it’s faster and produces more optimized G-Code (using the same settings in both slicers, Cura’s prints were faster for me- but as always, YMMV). However, Cura provides less tweakable options than Slic3r, so it takes some getting used to.

So, I was using Cura 10.04 under OSX (10.10 and 10.11), and all was nice and good. Suddenly, I wild bug appeared. As shown in the picture below, Cura uses some text overlays on the 3D-viewer to display information: print duration, filament usage, estimated cost, type of view, etc. On my machine, all text overlays were suddenly gone! Rebooting, reinstalling, re*ing, etc, didn’t seemed to solve the issue. And, needless to say, using a slicer without the aforementioned infos is quite frustrating.

cura_missing_overlays

Left: Fully functional Cura, with text overlays in 3D-view (image courtesy Tom’s Guides). Right: My wild bug in action – bye, text overlays.

Furthermore, this bug seemed to afflict only a handful of unlucky bastards: Google pointed me to one unanswered forum entry, and to one GitHub issue ticket. The latter got a response from one of Cura’s developers, which stated that they’re “not working on a fix, as we will be repacing the whole UI in a few months, which no longer uses this old font rendering code”.

All right then. The dev’s answer was posted mid-April 2015, so I figured a new version should already exist. Indeed, in the list of beta releases, Cura 10.06 was available for download. I grabbed it and got going.

The UI got heavily revamped, and lots of options were made available (bringing a Slic3r-y level of tweakability to Cura). A quick tour in Cura’s Preferences > Settings allows you to select which options you want to edit in the main window. No need for much detail here, as the help pop-ups on each option make the whole experience nicely intuitive.

cura_1006_ui

Cura 10.06 revamped UI.

Unfortunately, as new options were added, others were lost. When first configuring Cura, you need to add a printer. In previous versions, you could choose from a list of models or just go with a “generic” machine – to which you’d add dimensions and other relevant informations. This option is no longer readily available – you have to pick a model from the list! Having a DIY printer that looks like nothing on the list, I was quite frustrated. For test purposes, I picked the Prusa-i3 preset (though my printer uses a bed roughly four times as big).

On top of that – and that was the killer for me – there is no option to edit the Start/End G-Code procedures. While this sounds trivial/useless for most off-the-shelf printers, it won’t (probably) work with a custom machine (e.g., like mine). For instance, due to the form and size of my printer’s bed, I can’t go homing XYZ like a Prusa-i3 would do (and as the preset G-Code insists on doing).

After shelving Cura 10.06 for some days, I stumbled on this page on the RepRap Wiki. It shed some precious light on the workarounds required to solve these (and other) problems. As it turns out, much of Cura’s printer configurations are set in JSON files – a file per printer model, stored in Cura’s installation folder, under resources > machines. To add my custom printer, I’ve copied the prusa_i3.json preset to a new custom_3dcnc.json in the same folder, and went on editing it. The JSON entries are pretty self-explanatory:

Changing the id and name fields makes your custom printer appear on Cura’s list. Also note: AFAIK, you need a STL model for your printer’s bed (commenting out the field platforms won’t work). By default, they’re stored under resources > meshes. I could reuse one, but I’ve simply exported my printbed’s STL from my CAD program.

Configured Cura (with my printer's crazy-ass printbed on display).

Configured Cura (with my printer’s printbed being displayed).

Last, but not least, machine_start_gcode and machine_end_gcode are what I was looking for. Add the G-Code inside a single pair of quotes, with commands spaced with a newline character (\n) and you should be golden. Save the file, reload Cura, and you’re good.

’til next time.

PCL library with Kinect under OSX 10.11

This last week, I dug up my trustworthy Kinect for a spin. I’ve been wanting to mess around with the PCL (Point Clouds) library for some time, so I decided to give it a shot.

Installation on OSX using Homebrew is fairly straigthforward, as shown in their documentation. However, I want to make sure that I have support for the Kinect (the Xbox 360 model).

Side note on Kinect support: To get data off of your Kinect, you can use the OpenNI library (which handles Kinect “1”).  OpenNI2 does exist, but it handles only the Kinect “2” and Occipital’s Structure Sensor. I’ll be using OpenNI here, because it’s supported directly by PCL. However, for standalone applications, I’d greatly recommend libfreenect (also available through Homebrew), which is fast, lightweight, and very easy to use.

So, we’ll be using Homebrew to get the following libraries: Boost, Flann, Qt4, GLEW, VTK and last but not least, OpenNI (1 and 2, just for argument’s sakes).  Run:

brew update
brew install boost flann qt glew vtk openni openni2

Grab a coffee, ’cause this will take some time. Now, to install PCL, you may want to check the available options (brew options pcl), then install it with at least the following settings:

brew install pcl --with-openni --with-openni2

Great, if nothing intensely wrong happened midway, you should be golden. Now, at that point I was eager to get some Kinect-demo up an running, which led me to PCL’s openni-grabber page (go ahead, visit the page). They are kind enough to supply the C++ file and a CMakeLists.txt to compile it. It compiled fine, but crashed hard every time I tried to use it, spitting the message:

Assertion failure in +[NSUndoManager _endTopLevelGroupings], /Library/Caches/com.apple.xbs/Sources/Foundation/Foundation-1256.1/Misc.subproj/NSUndoManager.m:359
2016-01-06 12:50:51.779 openni_grabber[42988:7013866] +[NSUndoManager(NSInternal) _endTopLevelGroupings] is only safe to invoke on the main thread.

Now, I don’t know if this happens under other platforms. After wasting some days struggling with this, I realized what the heck was going on. Let’s take a look at the non-working supplied code. In the header section, we see:

It uses the PCL’s Cloud Viewer, which has been long deprecated (meaning that this example is very out-of-date). Secondly, we see that the grabber’s functionality is based on a callback, defined here:

The cloud_cb_ callback function is called every time a new data packet arrives from the Kinect. This is fine, but the showCloud() command updates the display of the point cloud from within the callback, witch is what’s creating our "...is only safe to invoke on the main thread..." error. To fix that, the callback should only update the cloud’s data, while the cloud itself must be displayed with a call placed on the main thread. The fixed code I came up with looks like this:

Now, the callback cloud_cb_ only updates the cloud’s data, not touching the UI. The drawing happens in a loop inside the SimpleOpenNIViewer::run(). Since the callback and the loop are handling the same data set asynchronously, I’ve added a mutex around the critical sections to avoid any issues (the nice CPP wrapper  stolen from libfreenect’s examples, thanks!). To compile it, the following CMakeLists.txt should do the trick:

The results are not astounding: the RGB data is slightly out of place with the depth data, but I believe this is a problem internal to PCL, since my Kinect is properly calibrated. To use only the depth data in the code above, simply replace all instances of pcl::PointXYZRGBA with pcl::PointXYZ.

kinect_pcl_view
’til next time!

Using CMake and Qt Creator 5.5.1

Well, things have been dead around here. So, to keep things running, I’ve decided to post some less important content, mostly as notes-to-self (ya know, when you spend the weekend trying to get something to work, only to forget how you did it a month later). To avoid purging hard earned pseudo-knowledge, I’ll try to create the habit to write it down here.

So, for my first post in this (otherwise endless) series: how to use CMake with and IDE.

CMake is a nice cross-platform utility that generates Makefiles for C/C++ applications. It will automatically search for include files, libraries, generate configurable source code, etc, etc. A simple CMakeLists.txt file looks like this:

This neatly handles dependencies and configurations in a much more platform-independent way. Nice tutorials on CMake are available here.

As the kind of guy that can’t cope with VI(M) (sorry, I’m just to dumb for it), I generally gravitate towards programming-with-IDEs. I began searching for an IDE that had decent CMake integration. “Eclipse can handle it, for sure”, I thought. Nope. I was disappointed to find out that Eclipse not only lacks native CMake support, but there seems to be no plugins that handle it. CMakeBuilder was widely referenced online, but it seems that it is no longer available (using Eclipse to  query www.cmakebuilder.com/update/ yields no results).

Qt Creator ended up being the go-to solution. AFAIK, is the only well supported cross-platform GUI that handles CMake natively. Suppose we have the test_project folder, with a main.cpp and the CMakeLists.txt I’ve shown above. Use Qt Creator to open a file or project:

open_file_qt_creatorOpen the CMakeLists.txt. You’ll be prompted to run CMake (which you can skip, if you wish). After running the wizard, the left project pane will look something like this:

wrong_project_pane

Neither the project name nor source files will be displayed, which is a bummer. This seems to be an issue with Qt Creator >5.0. There’s an fairly easy fix. Add the aux_source_directory command to your CMakeLists.txt:

Run Qt’s import wizard now, and the result will be as expected: project name will be featured, together with listed source files.

qt_creator_cmake_pane_ok

 

Great. Hit ⌘B and watch the build magic happen.

’til next time.