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.

It was aluminum.

It turns out, that my mill is able to cut aluminum. But man, that was loud!

The quiet before the storm:

Tools & Settings:

• 2mm aluminum
• Dremel 400 Digital
• Tungsten carbide 3mm mill bit
• 20000 RPM
• Feedrate 100 mm/minute
• .3 mm depth per cut
• lots of cutting oil

I guess I could increase the feedrate a bit, but I should lower the depth per cut to probably .2mm

All in all, I’m very exited. But really: It was LOUD!!

[Update 05/14/11]

And here’s the inevitable video:

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:

Anyway, since I’m relatively new to flying radio controlled stuff, I still crash the thing more than I fly it. Recently things really went out of control and I crash landed my Quadrocopter in a forrest, 450m away from its start position.

About 4 hours search time later (on the next day), my brother in law (who was part of  the little search party) found the crashed thing. Of course, since the (LiPo) batteries were (still) connected for about 24 hours, they were fully discharged (and thus damaged). Also the Quadrocopter’s props and frame were damaged. But on the bright side, we were able to recover all motors and the (rather expensive) electronics, including the FPV related stuff (AV transmitter, camera).

Although it might be possible to repair the broken original frame, I decided to rebuild the Quadrocopter from scratch. And of course, I printed all custom plastic parts on my MakerBot :)

There aren’t many parts needed for a Quadrocopter’s frame: It’s more or less just four arms with the motors attached to one end and a center plate on the other end, forming the typical X shape.

The center plate is also where most of the electronics are mounted: the Quadrocopter’s gyroscope controller (which stabilizes the whole thing when airborne), the battery pack and, of course, the RC receiver. The four ESCs (Electronic Speed Controllers), driving the brushless motors, are mounted directly on the arms (i.e. nearby the motors).

In my case, due to flying the whole thing with FPV, there is need for some additional electronic components: an AV transmitter, a camera and the OSD (On Screen Display), consisting of three  separate PCBs. The OSD isn’t mandatory for FPV, but it’s quite handy to see the battery’s remaining capacity, the Quadcopter’s GPS position and height and such, overlaid in the transmitted video.

So here’s the design I came up with:

For the arms, I use 10x10mm wood profiles. It’s cheap, it’s light weight and it’s tough!

The four arms (each 25cm long) fit into the holes on the center plate. They are hold in place by  M3x25mm bolts, for which I drilled a 3mm hole through each arm after inserting them into the center plate. The exact positions of the holes are already printed into one side of the center plate.

The motors are bolt to small platforms which are attached to the outer end of the four arms:

I used M3x20mm nylon bolts (not printed…) to secure the motor platforms.

The separate holders for the additional electronics (AV transmitter and OSD main PCB) are attached to their respective mounting places on the side and the back of the center plate. The RC receiver and the Gyroscope/Main controller are mounted on top of the platform with double-sided adhesive tape (the Gyro with additional rubber foam padding to reduce vibrations):

The FPV camera is mounted on the front of the center plate. Above it (on the left side in the following picture), the OSD’s GPS receiver is mounted on the top of the center plate (double-sided adhesive tape):

As mentioned before, the ESCs (which control the brushless motors) are mounted directly on the arms. So is the RC receivers additional antenna unit:

On the bottom side, you can see a x-shaped structure. This holds the third (and final) PCB of the OSD, containing the current measurement unit which allows the OSD to measure and display up to 50A current. The x-shaped holder and the velcro tape for later holding the battery pack are bolt down to the center plate with help of the four M3x25 bolts (see above).

Well, that’s about it, so far:

The feet in the above picture are currently simply four pieces of 6mm aluminum pipe. I plan to replace these by 6mm carbon rod, with nice, printed landing plates:

Unfortunately, these aren’t ready, yet. I’d like to build these with some kind of suspension in order to soften rough landings. But I’m still in process to design a simple, light weight and effective way to build this…

That leaves me with a last important question:

Will it blend fly?

The whole Quadrocopter, including the full FPV equipement, battery pack and preliminary feet weights only about 650 gramms, which is well under the theoretical maximum flying weight (including payload) of the original Gaui 330XS hardware.

Unfortunately, it’s raining outside, so I couldn’t test it in the wild. But I couldn’t resist to do a short hovering test in my living room. You must know, that my living room is rather small and stuffed with furniture, so it’s kind of hard to do test flights there, especially for a not-so-experienced pilot as myself.

But see for yourself:

Well, this looks promising!

So far I’m quite happy with the results of 3D printing structural parts for a Quadrocopter. The parts are quite sturdy, yet light weight. And if  I’ll brake any part of the Quadrocopter in the future, the replacement is always just a quick print away!

Of course, I’ve published the designs of the printed parts on Thingiverse: http://www.thingiverse.com/thing:4812

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!

Since a while it rattles a lot during printing, so at least I wanted to remove the X/Y stages from the bot, in order to clean the rods and to tighten all bolts.

I also wanted to find a better solution for the heated build platform’s cables. Until now, they somehow dangled in the back of the Makerbot on their way up to the extruder controller board.

After removing the X/Y stage from the bot, I saw another problem which needed to be solved:

Not only the acrylic build surface looks like reaching its end of life (it’s still the very first one, which came with the Makerbot kit more than a year ago), the main problem is that the whole platform has far too much play. Although my heated build platform is rather heavy (6mm aluminum + 3 big power resistors), I remember that this was also a problem with the original, unheated, wooden build platform.

I decided to bolt the aluminum plate directly to the Y stage with one central screw:

In order to be able to easily remove the print stage, I got rid of the acrylic build platform (bolt to the aluminum plate before). Instead I tried three different “interface” sheets.

The first try was a aluminum cover for the build platform. I folded the cover out of .5mm aluminum sheet with Kapton tape as surface:

To cut a long story short: It didn’t work. The cover wasn’t easy to install and remove from the build platform and it was impossible to get a good, leveled surface.

Next, I tried a piece of transparent LDPE. I had some leftovers of this from building the second filament box. I attached the LDPE with some foldback clips to the heated build platform.

It worked relatively well. However, the LDPE degenerates rather quick:

Also I have the problem that there are only very few spots on the build platform where foldback clips can be used without blocking the build platform’s movement. Since LDPE heavily warps when heated, there just weren’t enough clips to hold it down to the flat aluminum.

Finally, I cut a sheet of thin glass (from a cheap picture frame) to 10x10cm. Like the aluminum sheet, I used Kapton tape as “interface” material for the ABS. So far, this build surface seems to work great. The glass is nicely flat and leveled and keeps it that way when heated. And two foldback clips are enough to securely attach the surface to the aluminum plate:

Now, with the aluminum platform bolt down to the y stage, I was able to use a piece of ribbon cable to connect the cables from the platform with the x stage:

There was a connector on one end of the ribbon cable (it used to be a part of an old PC’s RS232 access), I glued this end of the cable to the y stage. After soldering a compatible connector to the platform’s wires, I was able to connect the heated build platform in a way which allows easy removal if needed.

Up until half way, I glued the ribbon cable to the x stage’s edge. Then the cable runs inside the drag spring from the x stage to the outside of the Makerbot. I already had the drag spring installed about a year ago to guide the y stepper motor’s and the y end stops’ cables.

Here’s a short video of the ribbon cable during a print:

It works great!

After playing around with my Mendel for a while, I very much like the autohoming feature of it’s firmware.

When I browsed the current Makerbot firmware, I was surprised to find support for automatic homing, ready to use. As far as I know, this code is currently not used by ReplicatorG, right?

Anyway, having endstops installed for the X and Y stage, it’s no problem to autohome these stages with the current firmware.

Just send the G-Codes G28, G161 or G162 with information on the axis to the Makerbot:

G28 is the “normal” ‘return to home’ G-code, also used by the RepRap firmware. However, in the Makerbot firmware, there are two more variants of the homing functions:

G161 is ‘home negative’, which means, that the respective stages are moved in direction of the MIN endstop until they reach the end of the line. Currently, G28 and G161 are exactly the same in the Makerbot firmware.

G162 is ‘home positive’, which means, that the respective stages are moved in direction of the MAX endstop until they reach the end of the line.

Concerning the X and Y stage, you might use either of them to bring the Makerbot into a “well known position”. If you have installed all four MIN/MAX endstops for the X&Y stages, that is.

In case you have only one endstop per axis you should call G161 for those axes with a MIN endstop and G162 for those axes with a MAX endstop.

My Makerbot, for example, has only one endstop per axis: MAX on the X axis, MIN on the Y and Z axes. So in order to home my Makerbot, I’d send

G162 X
G161 Y Z

The Z-axis endstop isn’t as easy to install as the X/Y endstops. Depending on the build platform and/or extruder or frostruder you’re using, the Z-axis endstop needs to be adjusted for the correct height.

Quite a while ago, I already tried some possible solutions on my Makerbot. Back then, I designed the Z-stage endstop trigger (my very first published thing on Thingiverse!). I also designed  a X-stage endstop trigger and an adjustable Z-stage endstop trigger. But since I wasn’t too happy with the results, I never published these.

I always thought, that the best way to do homing of the z-stage would be a probe as near as possible to the nozzle, sensing the actual build surface.

I also did some test on this back a year ago, but again the results weren’t too promising:

The main problem is, that the probe needs to be retractable during the print process. A year ago I tried to solve this with a manual retraction mechanism. But it didn’t work reliably. Also, adjusting the probe wasn’t very easy.

More than a year later, I learned a lot about electronics, microcontrollers and embedded systems programming…

So here’s what I came up with:

The Z-Probe

This new design contains a standard endstop PCB and a needle-like sensing-probe. The head of the sensor is motorized retractable with help of a standard servo.

The Z-Probe is designed to be mounted behind/under the extruder on the z-stage:

That way, the Z-Probe is able to sense the build platform only 1-2 cm from the nossle.

The servo, lowering and rising the sense-pin, is controlled by the extruder controller board. There are two digital pins on the extruder controller board v2.2, currently unused on a Makerbot (D9 and D10).

These pins are ready to use with a servo. Just plug the servo connector to the 3 pins of D9. Make sure to put the black wire (GND) on the pin marked with “-”:

Of course, some firmware/host software changes are needed in order to drive the Z-Probe.

The D9 and D10 pins are even PWM enabled. So usually it’s quite easy to add support for servos on an Arduino controller.

Unfortunately, since v2 of the extruder controller firmware Adam from Makerbot Inc. decided to move away from the Arduino IDE and API. The firmware is now “native AVR”, i.e. no more access to the Arduino libraries. Of course, there are several valid reasons to abandon the Arduino IDE, especially when projects grow and get more complex. But this also makes it harder  to “hack” the software.

What’s even worse: The current firmware already uses the hardware timer of the ATMega, which ususally drives the PWM pins D9 and D10. So I needed quite a while to understand how to solve these problems.

I think, I’ve found a way to solve the problem with the timer. The current firmware uses this timer for a general software interrupt routine. So I hooked the servo driver for the z-probe into the same interrupt routine.  So the servo PWM signal now is created by the CPU in software (and not by the hardware PWM driver). I tried some other ways around this timer conflict, but this was the only way both, the servo and the rest of the firmware, are working. I guess it’s not the best idea to mess around with one of the firmware’s central timers…

After solving these problems, I was able to extend the firmware with a new class “ZProbe”. This class handles the lowering and raising of the ZProbe hardware.

The upper and lower positions of the ZProbe are configurable in the extruder’s EEPROM preferences (well, they will be, as soon as I’ll find the bug which currently prevents the firmware to write new values to the preferences…).

In order to control the Z-Probe from within Replicator-G and -even more important- from within G-Code files, I added some new “M-Codes” to the GCode-Parser: M140, M141 and M142

M140 “Engage Z-Probe”: This M-Code lowers the Z-Probe into working position.

M141 “Disengage Z-Probe”: This M-Code raises the Z-Probe into parking position.

M142 “Adjust Z-Proble Angle”: This M-Code takes a S argument and moves the Z-Probe’s servo int the given angle (e.g. M142 S45 moves the servo to 45°). This code is intended for internal use only.

One thing to keep in mind is, that the zeroed Z-stage with engaged Z-Probe mustn’t be moved in X or Y direction. Since the Z-Probe pin touches the build surface in this case, moving the build platform could cause scratches in the build surface or -worse- damage of the Z-Probe itself. So always either disengage the Z-Probe or raise the Z-stage a little before moving the X/Y stage.

Here’s the G-Code for a complete autohome sequence on a Z-Probe equipped Makerbot:

G21 (Metric FTW)
G91 (relative positioning)
G0 Z7.0 (move up the z-stage for security)
M141 (Disengage Z-Probe)
G90 (Absolute Positioning)
G162 X (home positive)
G161 Y (home negative)
G92 X0 Y0 (Reset reference position)
G0 X-55.0 Y20.0 (Center ** Z-Probe-Pin **)
G92 X0 Y-25 (Reset reference position)
M140 (Engage Z-Probe)
G161 Z F500 (home negative [fast])
G92 Z0 (Reset reference position)
G0 Z2.0 (Back up z-stage 2mm)
G161 Z F25 (home negative [slow])
G92 Z0 (Reset reference position)
M141 (Disengage Z-Probe)
G1 F150 (Reset Z-speed)
G0 Z1 (backup Z for Y move)
G0 Y0 (center Y *** Nozzle ***)
G0 Z0 (return Z to zero)

Of course, this G-Code would need to be adjusted if the Makerbot has an other endstop configuration than mine. Also the ‘move to center’ distance is likely different on each Makerbot.

Here’s a video, showing my Makerbot while running the above G-Code:

As you can see, the Z-Probe just works, even if the height of the build platform was changed. No manual adjustmens needed. This is not only a nice feature for operators using differnt types of build platforms or surfaces, it also might be quite useful for people using the brand new Automated Build Platform.

You want?

First and frontmost: This is all still in a very early stage, both hardware and software.

I released the printable parts for the Z-Probe on Thingiverse: http://www.thingiverse.com/thing:4093

The design is for use with a Futaba servo S148. That’s the servo I found in my junk box. I guess each servo has a different size. So the design might be more a draft for your own design. I plan to try the same thing with a smaller (and cheaper) “micro servo” in the future. I hope I’ll find the time to create a parametric OpenSCAD design until then.

Since it’s still a prototype, the servo is currently glued to the base plate with some hot glue.

Both, the new extruder firmware as well as the extended ReplicatorG host software, are available on GitHub. I forked both projects from Makerbot:

G3Firmware: http://github.com/zaggo/G3Firmware

ReplicatorG: http://github.com/zaggo/ReplicatorG (ZProbe branch)

Please remember: This is all beta (at best). As mentioned above there’s still a known bug with saving the Z-Probes EEPROM settings.

Feel free to improve!

With a second working 3d printer in the house, I needed an extra filament spindle box. It was easy enough to build the first one for my Makerbot, so why not build a second, improved one?

The most wanted improvement was a window.

It turns out, that it’s not only nice looking but sometimes also important to see what’s going on inside the box. So I changed the design slightly to sport a window on the front.

Since it turned out, that the second disk above the filament spool on the turntable isn’t really needed (the spindle’s construction is self-supporting and the box’s top keeps the filament on the spindle), I recycled the spare plywood disk in the second filament box: It got promoted to be the turntable. (If you don’t have an extra plywood disk at hand, see here how to cut the disk out of a rectangular sheet of plywood with a Dremel).

Needing even less wooden parts (no front side, no plywood for the turntable), the remaining material was even cheaper to get. Including the sheet of transparent plastic (“Hobby Glass”, a sheet of 2mm transparent LDPE, 25x50cm), the whole stuff cost me less than 5€ (!).

Here’s the updated part list for the box:

There were some requests for detailed drawings, so here you go:

(These drawings are also available as PDF. I added them to thing 3640 on thingiverse.com.)

The change in design is, that -instead of a front wall- there’s a groove for a sheet of transparent plastic (or acrylic, or glass, or whatever).

If you got a circular saw, the grooves are quite easy to make: Adjust the circular saw blade’s height to about half the MDF thickness (i.e. if you use 10mm MDF, adjust the saw to 5mm). Then use the saw’s stop to saw the groove 10mm from the front side of the bottom, top, left and right parts (I hope I’ve got the technical terms about right in English…).

If you don’t have a circular saw at hand (I don’t!), you might use a Dremel to cut the grooves. That’s slightly more work and probably not as exact, but it’s good enough:

After cutting the grooves and drilling all holes, the assembly of the box is quite easy. I used some glue for additional stability.

Then I did measure the final width of the front window (including the depth of the grooves).

Cutting the LDPE sheet was very easy: After slightly slitting the sheet with a box cutter, the sheet can be broken at a table’s edge. It’s like cutting glass, only with a knife and without the cullets.

Now I was able to mark the final height of the window:

Another LDPE-cut later, the box was almost finished:

I didn’t change the inner construction of the box. So all printed parts, ball bearings and rods are the same as in the first box.

I added one last improvement to the box’s turntable: Since the filament roll tends to loosen up a little bit on the turntable, it can happen that some loose filament “falls” from the turntable. That’s usually not a big problem, but it could lead to a turntable-jam.

To avoid that, I used some paper (160g/m²) to build kind of a “cake setting ring” around the turntable (maybe one could actually use a real cake setting ring for this?).

The paper ring catches the loose filament windings, but it doesn’t interfere with the unwinding mechanism itself.

Besides some delays due to massive lack of time, the main problem was, that I couldn’t manage to build a working extruder to print with PLA. There were several attempts to build the original “direct stepper” extruders. These failed because I haven’t had a high torque stepper motor back then.

Some experimental geared extruder designs followed. None of them really worked.

There was even a try to mount a Printruder II on the Mendel (which generally works great). However, I used the Printruder II to test an experimental “insulator less” hot end – … which was a fail :)

Finally I printed different versions of Wade-inspired geared extruders. In the meantime I received two “RepRap-tested” high torque stepper motors (SY42STH47-1684B), so this shouldn’t be an issue anymore. But it was…

Since early tests on mine, to get the RepRap host software running on my Mac, weren’t too promising (I somehow managed to build and launch it, but there were a lot errors and GUI issues), I decided to install the Makerbot firmware on the Mendel boards and use it with ReplicatorG.

When doing first tests, I ran into problems with the motor driver chips on the extruder board. They ran really, really (really!) hot within seconds when driving the extruder’s stepper motor. When reducing the motor’s current by reducing the PWM value, the problem got slightly better (but the chips still got really hot). But  also the stepper motor lost most of it’s torque (and  the extruder got jammed again).

Finally, a reader of this blog (“renoir”, thank you!) wrote a comment on the blog post “Well, …no!”, linking to Tony Buser’s “RepRap host on Mac OS X Snow Leopard” blog post. This nice, short instructions solved most of the problems I had with running the RepRap host software earlier (I guess, Adrian also improved the software’s compatibility in the past half year).

Anyway, having the RepRap host software up and running on my Mac, there was no reason not to try the geared stepper extruder again, this time with the “originally intended” firmware. Behold: It worked like a charm, the motor driver chips’ temperature gets only to about 40-45°C.

I still don’t what went wrong (or what I did wrong) when trying to use the stepper extruder with the Makerbot firmware. But it works just great with the RepRap firmware.

So having a Mendel, printing with the RepRap host software, I am somehow puzzled about how to generate usable gcode with it. When using the host software’s built-in gcode generator, I always end up with fancy 5D gcode, but printing objects with a fill rate of about 80-90%. I searched the settings, I browsed the RepRap wiki, I googled the forums… no word on how to configure the gcode generator in order to be able to change basic (and important) settings like “fill rate” or “raft / no raft” or anything. I cannot believe, that the official RapRap gcode generator works like “one size, fits all”. Does anyone know more about this? Renoir? Tony?

What I did find was the hint to use Skeinforge to generate gcode for the Mendel. I tried this, but so far, I wasn’t able to generate working gcode  for the Mendel with it. For the Makerbot, I still use an older version of Skeinforge (v2009-11-06). My settings for this version are well tested and fine tuned. Also my raftless tool works very well with this version. Since this old version doesn’t support 5D gcode generation yet, I downloaded a more recent version (2010-06-29). But somehow I couldn’t manage to generate usable gcode with this version. Also the newer versions of Skeinforge seem to be much less liberal with “unproven meshes” in STL files. I ran into a lot of non-recoverable errors with some of my STL files (which work well with the old 2009-11-06 version).

I also tried to use Erik’s 3D-to-5D-Script with gcode I generated with the old Skeinforge version. But the resulting gcode wasn’t printable. I guess, I need to read more on the use of this script…

Generally, I’m surprised how hard it is to find instructions or how-tos on generating gcode for Mendel. Maybe I looked in the wrong places. I googled a lot in the past few days, but besides some posts with partial Skeinforge settings I couldn’t dig up much.

Any hints or links are highly appreciated!

As you know, I’m working on the long term project, using Mecanum wheels for a robot with omnidirectional driving capabilities.

Today, I received the gear motors for my Mecanum wheel chassis prototype:

These are 12V gear motors with a 1:50 gear reduction. The spindles are running at approx. 104 RPM.

To drive these motors from an Arduino Duemilanove, I use the motor shield from ladyada.net (at least for the prototypes).

Here’s a short video of testing the controller/motor setup:

Already having printed all 4 Mecanum wheels, I thought I would be nice to assemble the whole shebang and give it a test drive.

Well, there were some bumps on the road.

When designing the Mecanum wheel, I planned to use them with stepper motors. Although it’s generally nice to have exact control of the (stepper) motors’ RPM, I’m sure that the wheels’ slipping on the ground is quickly killing this advantage. Because of the much simpler controller electronics, I switched over to the above mentioned gear motors.

The main problem here: The stepper motors have a 5mm spindle, the gear motors have 6mm spindles. Thus, I ended up with 5mm bores in the wheels for the 6mm gear motor spindles.

I re-drilled the center bores in the Mecanum wheels with a 6mm drill. After that, the wheels fit on the motor spindles but -of course- now the captive M3 nuts for the spindle set screws didn’t fit anymore.

To solve this problem, I needed to file down 4 M3 nuts to about half their height:

Although this solved the problems with the changed spindle diameter, the whole process most likely didn’t enhance concentricity of the wheels. Printing a new wheel (without the rollers), takes more than an hour. Cleaning up the printed object, glueing in the ball bearings and assembling the rollers takes at least another hour. Since it’s a prototype anyway, I  chose to go with the fast, easy and maybe less precise solution.

I mounted the four motors with some quick and dirty printed clamp assemblies to a plywood base plate.

The clamps were printed relatively quick and they give me some freedom in (re-) adjusting the motor/Mecanum wheel positions. However, this sort of mount mechanism might not be ideal for long time use.

And here’s what the first prototype looks like:

The black Mecanum wheel in the front right is the first I printed. I had no liquid rubber then and I didn’t find the time and mood to completely disassemble the wheel in order to apply the liquid rubber to the rollers, yet.

The Arduino controller runs a pretty simple test sketch in the following movie, to test the four general drive modes (forwards, backwards, left, right):

Now I need to beef up the robots sensors and firmware. I really like the idea to add a gyroscope to recognize wanted and unwanted direction changes. And, of course, the thing definitely needs some kind of collision sensors…

As you might know, 4 Mecanum wheels are needed to build a functional omni-directional chassis. So far I finished only two (at least two others weren’t usable due to failed prints, normally because of filament jams…).

One big problem is still, that due to ABS shrinkage, Makerbot fabrication tolerances and printing with 45° overhang, the holes for the ball bearings are always slightly too small.

Until now I used a Dremel to manually grinding the holes a little bit bigger (as seen here and here). The biggest problem with that (besides the boring work) was that when grinding manually, you never get the final holes exactly round.

Earlier this year, I allowed myself buying a nice, new drill press:

Ever since I wondered, if it would be possible to machine finish the holes for the ball bearings with it. I happen to have a 13mm drill (which is the OD of the 624 ball bearings), so the only thing I’d need would be a jig to position the Mecanum wheel resp. the printed hole exactly centered and horizontal under the drill.

So why not simply print such a jig?

Here’s what I designed:

I then screwed the printed jig on a piece of wood, adjusted it on the drilling table and clamped the whole assembly down: