My Z-Probe prototype used a standard sized servo. Of course, this kind of servo seems a little bit oversized for this use. Thus, I looked around for smaller alternatives.
I found some nice micro servos on ebay:
These servos not only are tiny, they are also cheap. I bought 3 of them for 4 Euros a piece.
I started to redesign the printed parts of the z-probe prototype. But compared to these micro servos, the mechanical construction was huge. Too huge!
After thinking about this for a while, I found a solution: Keep it simple!
Here’s what I came up with:
It’s basically just the servo with an opto endstop pcb glued to it…
Its smaller, it’s simpler, it’s adjustable and it works great.
Here’s a how to build the probe:
I also simplified the z-probe firmware, based on the latest G3Firmware. Since the firmware now natively supports servos (for the Unicorn pen plotter), I was able to reduce the code patches to just a few lines for the z-probe commands.
Unfortunately I wasn’t able to update my forked firmware repository on GITHub. I’m (still) really uncomfortable with using git! Each time, it’s a pain in the ass to merge new revisions from the remote repository with my forked repositories (locally and/or on GITHub). I’m pretty sure, that this is supposed to be easy, but there always are problems, errors or conflicts. And I’m still looking for a good tutorial for these hacker tasks…
Anyway, until I’m in the mood to check out git again, here are the few code changes necessary to support the z-probe in the newest firmware revision:
I’m still struggling with some code in Pleasant3D, which I’d like to get in order before releasing the open source parts. I hope I find some time for this during my upcoming vacation. I’ll be in Corsica for 2 weeks and although I plan to get some rest from computers, I guess I’ll find some time to relax from all the sun and beach by searching bugs in Pleasant3D :)
Anyway, here’s a short movie of a new feature I implemented some weeks ago:
Although there seem to be some issues with more complex DAE files, the import of “printable” objects usually works very reliable.
Today, I release Pleasant3D v2.0 to the public and when reading the list of changes, most people might ask why there’s such a big step in the version number:
What’s new in Pleasant3D v2.0:
More intuitive (trackball) view rotation
Panning views with right mouse button drags
Well, as you might have guessed already, that’s not all. The main change is that I finally merged the former other, larger project and Pleasant3D to … well, Pleasant3D v2.0. So the missing point in the above list is:
Initial release of “the real Pleasant3D”
Back in June 2009, after I ordered my MakerBot Deluxe Kit, I was in state of anticipation and impatience, most of you other MakerBot operators probably know from own experience: The order’s finally placed, but it takes 4 to 6 weeks until the kit eventually ships.
I read all reports on building and operating a MakerBot in the internet (there wasn’t that much blogs on this back then) and of course, I downloaded ReplicatorG and Skeinforge to play around with them.
As a (very) long time and hardcore Mac user and developer, I quickly thought about a nicer, cleaner and faster way to produce GCode and eventually print objects than ReplicatorG and Skeinforge.
Don’t get me wrong: I think Skeinforge is a really amazing piece of software, it’s ability to process “incorrect” 3D objects and the GCode it creates is just great. I also think that MakerBot Industrie’s decision to provide cross platform support on the software side with ReplicatorG as printing software and Skeinforge as GCode generator is absolutely great and important (I’m still struggling with my Mendel because the native Reprap software currently doesn’t really support Macs).
But I also think, that it would be nice to have an alternative – not that universal, but maybe better – way to handle 3D processing for printing stuff.
That’s why I started to develop Pleasant3D, to play around with something during waiting for the MakerBot Kit to arrive.
My plan was to create a tool to not only provide a native way to preview STL and GCode files, but also to transform STL files to GCode.
I didn’t (and don’t) want to provide another cross platform tool for those tasks, struggling with GUI and performance tradeoffs caused by the need of portable code. I explicitly decided to develop a high performance, native GUI tool for the system I’m working on (which is obviously Mac OS X, sorry Windows and Linux users), using all cutting edge technologies available in the most recent OS (which is Mac OS X 10.6, sorry PPC and Leopard users).
My first approach was, to port Skeinforge’s open source Python code to native Objective-C code. I started with Skeinforge’s Carve tool and it was a disaster. Not only it was kind of uncreative and boring to port existing code to another programming language, but the resulting code was also even slower than the original code.
The reason for that is, that each programming language has it’s pros and cons. One of Python’s pros is, that it’s very fast in creating objects. Unfortunately, creating objects in Objective-C (like C++ also based on C) isn’t its fastest feature. So by porting the Carve code 1:1 to Objective-C, the code still used the original algorithms, based on the creation of zillions of objects during carving a 3D object. Not a good idea in ObjC.
The Carve tool is the first step in processing a 3D object for 3D printing. It slices the object horizontally. For comparison I used a nice object from Thingiverse: Eggcup With Salt & Shell Trays
Carving this STL file (containing 5486 triangles) takes about 9 seconds in Skeinforge (0.4mm layer thickness, 2.8GHz Intel Core 2 Duo MacBook Pro):
When carving the same file with my first version of the ported Carve tool, it took more than 12 seconds with the native code!
So I started to optimize the ported code, implemented caching collection classes, reusing memory and objects whenever possible and so on.
I finally got a version of the native Carve tool, running faster than the Python script:
Speeding up the carving process by factor 2.3 doesn’t sound too bad, but I couldn’t believe that this would be the best possible result. Especially since the porting process was really boring!
So I threw away the whole thing and started from scratch again. This time by creating my own, new algorithms and pulling all the stops Snow Leopard provides: GCD & OpenCL.
I called the new tool “Slice”. Changing to a new algorithm and OpenCL really paid off. But see for yourself:
That’s more like it: 39ms, 230x the speed of Skeinforge…
Present and future
Please don’t throw away Skeinforge yet! Pleasant3D is at a very, very early stage. It’s fragile. It needs clean STL files with normals. And there’s not a complete set of tools yet. The whole thing still needs a lot work.
Pleasant3D v2.0 is still the same tool we love and know for viewing STL and GCode files (including moving/rotating/resizing STL objects). It also contains the same QuickLook plugins for STL and GCode. All these features are more or less stable.
In addition to that, there’s a new kind of document: The P3D document
You create a tool chain by dragging & dropping available tools from the toolbox panel to the tool bin. Each tool gets its input from the previous tool’s output. If you change settings in a tool at the begin of the tool chain, the results of these changes automatically “ripple” through the whole tool chain. With the current speed of the few available tools, this happens almost instantly.
Here’s a teaser video of the whole thing:
The Slice&Dice part of Pleasant3D isn’t ready for prime time yet! It’s work in progress.
I decided to publish it anyway, since I’d appreciate any help with the tools and printer drivers.
So here’s the deal:
Pleasant3D is a free download (as usual). The GUI part of the project is still kind of semi-closed source (more on this some other time).
However, all tools are implemented as plugins. So are the printer drivers. And they will be will be open source. I’m currently working on a way to publish the sources. Very likely they’ll be available through public access to a Mercurial repository.
You can start developing tools right away. All you need is a copy of Pleasant3D v2.0 (or later), a working installation of Xcode v3.2.1 (or later) and the following shell script:
Copy Pleasant3D to your /Applications folder (no subfolders!). Then run the InstallDevSupport script:
Open a Terminal window
Go to the folder containing the InstallDevSupport script (cd <path to InstallDevSupport.sh>)
Run the script (sh InstallDevSupport.sh)
Enter your admin password
Re-launch Xcode after that. When you now create a new project in Xcode, there should be a Pleasant3D project template available. Use this template to create a new Pleasant3D tool project. Please read the ReadMe.txt file inside the new project folder for important additional information.
In addition to the sources of the current tools, I’ll try to provide some additional sample code as soon as possible.