https://github.com/zaggo/PleasantMill

As you might guess from the version number, this firmware isn’t finished yet and probably still has some bugs to fix (help’s highly appreciated, BTW :).

As mentioned before, I use a Seeduino Mega and some Pololu A4983 stepper motor drivers.

One recent addition on the hardware side was a 24V/6.3A power supply. I also glued some small heat sinks on the A4983 chips.

Then I increased the current to 1.68A, the max current, the stepper motors (SY42STH47-1684B) are rated for. Driving the steppers at 24V/1.68A enabled me to dramatically increase the top feedrate for the machine (about 1800mm/min instead 600mm/min). Unfortunately, the little heat sinks weren’t enough and the thermal shutdown of the A4983 kicked in after a few minutes. So I had to lower the current to about 1.2A again (and the max feedrate to 1100mm/min).

As you can see in the image at the top of this page, I’m still using a messy bread board for the electronics. As soon as I have the feeling to know the main issues with the whole shebang, I’ll build some kind of Seeeduino Mega shield, of course.

Right now, I plan to put the stepper motor drivers on a separate daughter PCB, somehow integrated in some kind of big ass heat sink.

If anyone knows a good way to cool the tiny A4983 chips on the Pololu breakout boards, please let me know!

—

The just published firmware release contains code for the G2/G3 commands (arcs) and for several drilling cycles (G81, G82, G83, G85, G89 and G73, see video below).

The drilling cycle commands also recognize the L (loop) parmeter, which is nice to drill multiple holes in a row. Just switch to incremental positioning (G91) and use something like G81 X10 Y0 Z-12 R1 L7 to drill 7 holes along Y=0mm, 10mm apart and 12mm deep. Don’t forget to switch back to absolute positioning (G90) after :)

I also added the M6 (tool change) command. Of course, I have no automatic tool changer (and I don’t really plan to build one). On the Pleasant Mill, the M6 command pauses the G-code processing and displays a message on the LCD, containing the tool number, requested by the G-code program and waiting for feedback from the operator.

For example, the line

M6 T3

results in

I even wrote some code to save a “tool database” in the Seeeduino’s EEPROM, so the LCD would say something like “Insert tool: 3mm drill bit”, but this code doesn’t work properly yet.

Both, the drilling cycles and the tool change command are showed off in the following video:

And here’s the G-code, I sent to the machine during the video:

G21
G90
G0 Z3
G0 X2 Y2 ; Simple drilling cycle
G91
G81 X6 Y0 Z-8 R2 F300 L4
G90
G0 X2 Y7 ; Drilling cycle with dwell
G91
G82 X6 Y0 P500 L4
G90
G0 X2 Y12
G4 P1000 ; Peck Drilling cylce
G91
G83 X6 Y0 Q2 L4
G90
G0 X2 Y17; Peck drilling cycle, high speed
G91
G73 X6 Y0 Q3 L4
G90
G0 X2 Y22 ; Drilling cycle, slow retract
G91
G85 X6 Y0 L4
G90
G0 X2 Y27; Drilling cycle with dwell, slow retract
G91
G89 X6 Y0 P500 L4
G90
G0 X0 Y-25 Z19.5 ; Tool change position
M6 T2 ;  Change Tool
G0 X2 Y32
G91
G81 X6 Y0 Z-5 R2 L4
G90
G0 X2 Y34
G91
G81 X6 Y0 Z-5 R2 L4
G90
G0 X0 Y25 Z13.5


—

I also implemented the commands G54 to G59. Each of these commands switches the machine to one of 6 “work coordinate systems” (WCSs). These are 6 user defined “zero positions”, saved in the machines EEPROM.

To define a WCS, use the “Jog XZ”, “Jog Z” and “Jog AB” functions in the mill’s UI (“Cartesian”) to move to the desired position. Then choose the menu command “Set WCS” to save this position in the EEPROM. You also can view already saved positions with the “Show WCS” command.

When writing G-code, you can then use one of the commands G54 to G59 to load the previously saved positions as zero positions.

In order to get the whole WCS stuff working, you need to “home” the machine once (either by sending the G28 command or by choosing “Find home” from the Cartesian menu in the UI). This is necessary to give the firmware an idea of the machine’s absolute zero position. If you try to save a WCS position in the UI or to use G54 to G59 without homing, an error is displayed.

Don’t get me wrong, I’m still happy with printing 3D stuff in plastic. As matter of fact, I used far more printed parts during the build of my new CNC mill than I had planned in the beginning. But there are quite some situations, when printed plastic just isn’t the best choice material for an object.

That’s where usually laser cutters, plasma torches and water jets come in. Or, in case of a poor, lone DIY warrior, a home made CNC mill.

The plan

I looked for an open source CNC machine which would be able to mill wood (mostly plywood and MDF), acrylic and maybe even aluminum.

The internet is full of DIY CNC mills, but only a few people publish plans and/or enough technical data. There are some kits, but I didn’t want buy a kit, since I already had many parts for a CNC mill lying around (high torque stepper motors and Pololu A4983 motor drivers from a dead end project of mine, waiting for recycling, a bunch of precision rods from old scanners and printers). Also I love to plan and build stuff by myself.

Eventually I stumbled upon the website of the Mantis CNC mill. This mill is open source and kits are available for sale.

I liked the compact size and use of wood for the main construction. However, there are several things, I don’t like:

• For my taste, there’s way too much glueing involved in the construction. Although this makes the build process easier, glueing stuff together with epoxy means also there won’t be any chance for adjustments later. They even glue one of the stepper motors to the back of the machine….
• The Z axis construction is made for a -glued in- custom spindle. No easy way to attach other tools, like a Dremel or maybe an extruder on the machine.
• The Mantis’ work area was a little bit too small for me.
• The whole construction and plans are in imperial measure. No offense, but I’m a very happy user of the metric system.

That said, I used the Mantis plans as base for my own, custom plans.

I slightly scaled the parts up and “rounded” them to the next metric measure. The 10″x4″ build platform became a 300 x 150 mm build platform and so on.

In order to keep track of the changed parts and the construction as a whole, I constructed the machine in a 3D application:

I also changed the construction of the Z axis in order to provide a more versatile base for different tools. The Z stepper motor sits on top of the Z axis in my construction (and isn’t glued to the back of the X axis plate).

Bodywork

Based on my 3D drawing, I wrote a BOM for the wooden parts. I use 16mm MDF and the whole material cost less than 10€ in my local hardware store (already cut to size).

Here are some pictures from the build process. Building a LCD (and a micro joystick switch) directly into the machine was part of the plan from the beginning.

Problems

One thing, I wasn’t sure about were the bushings. Since they uses bush bearings in the original Mantis construction, I ordered some sintered bronze bushings together with the acme threads.

Despite all precautions and match drilling all holes for the precision rods, I wasn’t very happy with the results when first assembling the x axis.

The slide was much too sluggish (see following video). So I decided to go back to proven mechanics and designed Mendel-style linear bearings for all three axis.

Since there isn’t too much room for the bearings (especially at the Z axis), I designed the printed ball bearing retainers as low profile as possible. The “inner” ball bearings are halfway sunk in the base plate.

This not only keeps the assembly as low as possible, but also guarantees the same height reference for the fixed bearings (the axle sits directly on the plate). All upper bearings are adjustable.

Here’s a short video with a comparison of both bearing styles. I guess, bush bearings are only usable when the whole construction is manufactured by CNC machines…

I published the STL files for the linear bearings on Thingiverse.com: http://www.thingiverse.com/thing:8480

Build platform

The build platform is (same as in the Mantis construction) a sandwich of two boards of the same size. The linear bearings and the acme rod are attached to the lower board. That way, the upper board can be easily replaced in case of an accident or maybe if a heated build platform is needed in the future.

I drilled a grid of 4mm holes in the upper board, each with its own drive-in nut. The grid then can be used to easily attach a workpiece on the build platform by using scew clamps or directly bolting the piece down.

The tool

As spindle, I attached my Dremel to the Z stage. I printed an upper and lower clamp on my Makerbot Cupcake, which hold the Dremel gentle and tight on the Z axis.

The electronics

For a while I planned to use RAMPS electronics from UltiMachine to drive the three steppers (and any extruders in the future). But ever since I looked in the store, the PCB was out of stock. In addition to that, I already had a Seeeduino Mega lying around, which I liked to use for this job and which is not shield compatible with the Arduino Mega. Finally I needed some custom connections for the LCD, the joystick switch and the emergency stop button, I built into the mill.

So I decided to go for my own, custom RAMPS shield for the Seeeduino Mega.

Based on the open source design of the UltiMachine RAMPS electronics, I started to design the new Seeeduino shield.

The board design is far from finished yet! Meanwhile I started to put the electronics onto a big breadboard on the backside of the mill.

As soon as the circuits are working correctly and the schematics are fully tested, I’ll manufacture the final shield PCB. But this might still take a while and I’ll definitely write at least one other blog post about this topic.

So far, the breadboard contains only three Pololu A4983 boards for the steppers, as well as connectors for three endstop switches and some additional components for the LCD and switches.

I currently use mechanical endstops for the three axes. I’m still not sure if I’m happy with these. Maybe I’ll switch to opto endstops later, since I have the feeling, that they are much more accurate.

The software

I used the newest version of the RepRap firmware as a starting point. I very much like the acceleration feature for the cartesian system. Originally I thought I’d use the RepRap firmware more or less unchanged and just add code for the LCD and switches.

But it turned out quickly, that I’d need to make bigger changes to the firmware in order to implement some features I planned (e.g. jogging with the joystick switch etc.).

One thing came to another, I started to re-write some parts, added some code in the G-Code parser which is important for milling (G2, G3, G81 etc.). Then I started to throw out obsolete code and to redesign other code in order to implement stuff more object oriented…

Long story short, the firmware tuns out to be more based on the RepRap firmware than to be just an extended variant.

I have plans to go even further and to try to implement G41/G42 functionality (Cutter Radius Compensation). In order to do so, the G-Code parser needs a lot changes and extended functionality.

In order to keep my focus on the functionality important for milling, all 5D-extruder support is currently removed from the firmware. I’ll definitely add this code again later, when the milling code is working.

I’ll also publish my version of the firmware as open source, of course. But I’ll need some more time to further stabilize and clean up the code  before that. Please stay tuned.

The movie

Finally, here’s a video of the mill’s first real cut and a short demo of the LCD menu system of the current firmware:

I need a tripod stand for my iPhone 4.

Fortunately, there’s a nice design for one of these, ready for download on Thingiverse: http://www.thingiverse.com/thing:4335

A minor problem with this object is, that Bradley Rigdon, the creator of this design, owns a couple of Dimension 3D printers. Since these professional printers automatically print with support material, large overhangs and such are no problem for them. And there are some large overhangs in the iPhone 4 tripod design…

It’s no secret, that the standard MakerBot Cupcake doesn’t have a second extruder for printing support material. Nonetheless, some people (including yours truly) recently started experimenting with Skeinforge’s built-in support stucture feature. It turns out, that these support structures don’t necessarily need a second extruder with dedicated support material.

Keen to experiment, I turned on the support feature in Skeinforge and sliced the downloaded STL (BTW, which needed resizing by factor 25.4, since the original STL was exported in inches).

In the relatively old version of Skeinforge, I still use for several reasons (v2009-11-06), the support settings are part of the Raft preferences:

I printed the generated gcode in white ABS with my -more or less- standard MakerBot.

Removing the support structures after printing is relatively easy as long as you choose “Support on Exterior only” in the above settings.

Besides the relative coarse bottom side (which was likely more a problem with some Skeinforge settings unrelated to the support structure), the main problem with the printed object was the tiny wall on one side. You’ll know which wall I mean and what’s the problem when you compare the following picture with the object’s STL-screenshot above:

One thing I learned in the last year, printing 3D objects with my MakerBot: avoid printing single, tall, thin walls in upright position, unless you want to break them away later (intensionally or unintensionally…).

The missing wall on the above object broke away when I tried to attach the object to my iPhone for the first time.

The easiest solution for such a problem is usually to print the object “on its side”, i.e. rotate the whole thing by 90°:

But in this case you’d run right into the next problem: Now you’d need to manage the 90° overhang (marked with the red circle). In order to use Skeinforge’s support structures for that, you’d need to switch the “Support Material Choice” setting to “Support Everywhere” (instead of “Support on Exterior only”). But removing those “inside” supports after printing isn’t easy and the support structures would likely degrade the surface of the rail on the upper side of the object, critical for the fit of the iPhone.

My solution for the dilemma was to print the object only slightly rotated:

I started with 30° rotation from the upright orientation. Since I used support structures anyway, the weird angle shouldn’t be a problem to print. By choosing a rotation angle smaller than 45° the resulting additional overhangs of the former vertical walls shouldn’t need additional support (Skeinforge automatically don’t generate support structures for those overhangs; see “Support Minimum Angle” in the above settings).

By rotating the object, the iffy wall is now also sliced in an angle, which greatly improves its stability:

The print looked ok on first sight…

… and the stability of the printed object was indeed greatly improved.

But unfortunately, printing the 30° overhangs didn’t work very well:

I did some additional adjustments in the Skeinforge settings:

To give the curved lower part more plastic to stick on, I changed the “Thread Sequence Choice” (Fill Preferences) from the default value “Perimeter > Loops > Infill” to “Loops > Infill > Perimeter”.

I also reduced the rotation of the object from 30° down to 15°, which still should be enough to give the front wall sufficient stability:

This time, the print looked good:

The refined settings seem to do the trick.

Here’s the printed part after breaking away the support material:

And here’s a comparison of all three different prints (left to right: 15°, 30°, 0°):

The stability-improved vertical (diagonal) structure  (from left to right: 0°, 30°, 15°):

One more lineup (left to right: 0°,  30°, 15°):

And now to an interesting question: Does the part work?

See for yourself:

Looking good!

After the successful first test, I coated the whole thing with liquid rubber (Plasti Dip):

The rubber coating isn’t needed for grip (of the iPhone). But I thought, a little bit color couldn’t hurt. And also I like the rubbery texture on printed objects :)

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:

v2/src/shared/Commands.hh:
105 105 #define SLAVE_CMD_GET_SP			32
106 106 #define SLAVE_CMD_GET_PLATFORM_SP		33
107 107
    108+#define SLAVE_CMD_ENGAGE_Z_PROBE		128
    109+
108 110 #endif // SHARED_COMMANDS_H_

v2/src/Extruder/Host.hh:
18 18 #ifndef HOST_HH_
19 19 #define HOST_HH_
20 20
   21+// ZProbe settings
   22+// 750ms
   23+#define ZPROBE_TIMEOUTINTERVAL ((micros_t)750000L)
   24+
   25+// Angles in Degree
   26+#define Z_PROBE_ENGAGE_ANGLE  0
   27+#define Z_PROBE_DISENGAGE_ANGLE 50
   28+
21 29 void runHostSlice();

v2/src/Extruder/Host.cc:
149 149 			to_host.append8(RC_OK);
150 150 			return true;
    151+		case SLAVE_CMD_ENGAGE_Z_PROBE:
    152+			{
    153+				uint8_t angle = ((bool)from_host.read8(2))?Z_PROBE_ENGAGE_ANGLE:Z_PROBE_DISENGAGE_ANGLE;
    154+				board.setServo(1,angle);
    155+				micros_t endDelay = board.getCurrentMicros()+ZPROBE_TIMEOUTINTERVAL;
    156+				while(board.getCurrentMicros()<endDelay); // Wait for Servo
    157+				board.setServo(1,-1); // Switch Servo off
    158+			}
    159+			to_host.append8(RC_OK);
    160+			return true;
151 161 		case SLAVE_CMD_GET_SP:
152 162 			to_host.append8(RC_OK);
153 163 			to_host.append16(board.getExtruderHeater().get_set_temperature());

The ReplicatorG patch can be also simplified (no more EEPROM preferences for the Z-Probe). But I didn’t find time for this yet. For the time beeing, you can simply use the patched version from here.

Well, I still have 2 servos left…

I wonder what I can do with one of these and a slightly modified version of this thing, directly glued to the servo arm. I’m pretty sure it’ll work just as fine as that thing, only with 16 parts less…

Keep it simple!

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”

Foreplay

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).

Failure

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.

Success

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 deal

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:

InstallDevSupport.zip

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.

You can download Pleasant3D v2.0 from the Pleasant3D download page.

That’s it for now. Stay tuned for more shortly.

The quick update was necessary due to a nasty bug in v1.1 which caused wrong positioning of STL objects in some cases. This issue is fixed in v1.2. I also smoothed out some remaining problems with the 64-bit build. So if your computer supports 64-bit applications, Pleasant3D v1.2 will be one of them…

Finally I added automatic update checking (thanks to the Sparkle framework). From now on, when I  screw up a version (as I did with v1.1), you won’t need to manually download a new versions a few days later. The automatic update window will pop up and offer an easy one-click update. :)

However, if you’re still on v1.0 or v1.1, you definitely want download Pleasant3D v1.2 manually.

I’m happy to announce the release of Pleasant3D v1.1.

There are some awesome new features in the new version:

• Pleasant3D now includes QuickLook plugins for STL and GCode files!
• The preview views are now zoomable.
• Objects can now be rotated by arbitrary angles.
• … and many more.

Check out Pleasant3D’s brand new home page for a full feature list.

I recorded a short movie, showing off the new features of Pleasant3D v1.1:

Thanks’s to all of you, sending me feedback!

Pleasant3D v1.1 is available for free download here: http://www.pleasantsoftware.com/developer/pleasant3d

As soon as the base shape of an object becomes more complex, things go likely wrong: Most of the time, the more complex perimeter lines don’t stick and ripped off the build surface by the passing nozzle.

To solve this problem, I played around with several parameters of the gcode files, like feed rate and flow rate.

It turns out that, if extruded “slow enough”, also complex shapes are easily printable without a raft.

After testing this for a while by post-processing gcode files manually (i.e. editing the gcode files in a text editor), I started to write a new tool for the skeinforge tool chain.

By integrating a ‘Raftless’ tool into skeinforge, I not only save a lot of time (it’s rather time consuming to edit gcode files each time before printing), but I’ve also much more (and easy!) control over what to slow down. Although it’s possible to change each single line of gcode in a text editor, it’s quite a challenge to navigate through thousands of ‘G1 X Y Z F’ lines without getting lost or insane.

Anyway, I just finished a new tool for the skeinforge tool chain:

“Raftless”

Raftless is a script to prepare a gcode file for raftless printing.

The default ‘Activate Raftless’ checkbox is off, since the mutual exclusive ‘Raft’ script is activated by default. In order to use the Raftless script, you want to desactivate the Raft script first. If both scripts, Raft and Raftless, are activated, the Raftless script (which runs after the Raft script) automatically detects the already created raft. In this case, the Raftless script is skipped and a warning message is printed to the console.

The “1st Perimeter Feed Rate over Feed Rate” preference defines the feed rate during the extrusion of the 1st layer’s perimeter lines. The preference is a ratio of the normal extrusion feed rate as configured in the ‘Speed’ script. The default value is .5, which means half the normal feed rate.

The “1st Perimeter Flow Rate over Flow Rate” preference is the ratio of the filament feedrate during the extrusion of the 1st layer’s perimeter lines. Since the feed rate is slower than normal, you might want to reduce also the flow rate in this case. This preference is a ratio of the normal flow rate (as configured in the ‘Speed’ script). The default is 1. (same flow rate as normal).

If “Add Extrusion Intro” is on, an additional straight extrusion line is added to the start of the first perimeter. This line starts at the coordinates ‘Extrusion Intro Max X Absolute’/'Extrusion Intro Max Y Absolute’. These both values are absolute (positive) values. The script automatically negates one or both of these values, according to the location of the first regular extrusion.

Please note, that Add Extrusion Intro doesn’t check for collisions with the perimeter lines. If necessary, you want to change the max X/Y values manually.

Here’s a video of printing an object without a raft (yes, the gcode file was created with the Raftless tool…):

If you’re interested in raft-less printing, you should definitely give the ‘Raftless’ tool a try.

Download the Raftless Python source

I wrote the Raftless script based on the most recent version of skeinforge (“created at 2009-11-06″) as included in the not-released-yet newest Replicator G version. In the meantime, you can download this version of skeinforge from the public Makerbot GITHub repository. Please note, that all unreleased software in this repository is per definition ”beta”. So: no guarantees.

In order to install the Raftless script within the skeinforge tool chain, copy raftless.py in the skeinforge_tool/craft_plugins folder. Then edit  skeinforge_tool/profile_plugins/extrusion.py and add the Raftless script to the tool chain sequence by inserting ‘raftless’ into the tool sequence  in getCraftSequence(). The best place is at the end of the sequence, right before ‘export’.

Any feedback is highly appreciated!

Here’s another short movie of the display in action:

I cleaned up my modifications in the extruder controller firmware and pushed my changes to a branch on the makerbot/G3Firmware github repository. You find the modifications in the “zaggoLCD” branch.

Next up: Trying an alternative solution with the LCD connected to the motherboard’s I2C bus…