After Dan Newman nudged me a bit in the comments to the Z axis calculations, I walked through the constants in Marlin’s Configuration.h file to see if they were all consistent. The earlier values sufficed to get going, but a bit of pondering suggested some tweaks.

The motor microstepping mode determines the number of (micro)steps per motor (single)step:

#define MICROSTEP16

That single constant implies all motors must run in the same microstepping mode. Typical stepper motors have 200 full step/rev = 1.8°/step, so 1/16 microstepping means 3200 step/rev.

However, each motor can have a different “gear” ratio that converts from motor rotation to linear distance, so you must measure or calculate the actual values.

For the X and Y axes, the motor pulleys have 18 teeth and the belt pitch is 2 mm/tooth, so one motor revolution drives the belt:

36 mm = 18 teeth * 2 mm/tooth

M2 – X axis motor pulley

Each revolution requires 3200 steps, so the X and Y stages move at:

88.888 step/mm = 3200 step / 36 mm

Makergear uses 88.88 step/mm, rather than the rounded 88.89, but the difference across 250 mm amounts to 2.5 steps, so it doesn’t matter.

For the Z axis, the four-start leadscrew moves the stage 8 mm, so:

400 step/mm = 3200 step / 8 mm

M2 Z axis bearing – shimstock bushing

The situation with the extruder drive isn’t quite so clear, because the actual filament movement depends on the effective diameter of the drive pulley’s teeth engaging the filament. Mechanically, the extruder motor runs a 5:1 gearbox, so each drive pulley rotation requires 16000 (micro)steps.

The filament drive pulley has 22 teeth and a 12.0 mm OD = 37.7 mm circumference:

424.4 step/mm = 16000 step / 37.7 mm

M2 – Filament Drive Gear

That’s measured at the tooth tip. If you think of the filament as being a belt, then you’d expect it to move precisely that distance… except that the teeth dig into the filament, so the effective diameter comes out a bit smaller and the step/mm value a bit higher.

Makergear’s default 471.5 step/mm is, indeed, larger, but the ratio of the two values seems both oddly familiar and eerily exact:

0.900 = 424.4 / 471.5

The “packing density” Fudge Factor (yclept extrusion multiplier by slic3r) that accounts for the difference between the drive gear OD and the actual filament motion runs around 0.9, with passionate arguments justifying more specific values. It looks like Makergear baked that number into the firmware, so the nominal slic3r extrusion multiplier should be pretty close to 1.0.

After a few quick measurements while getting the printer running, I settled on extrusion multiplier = 0.9, so the actual step/mm value in effect for the extruder works out to:

424.4 = (471.5 step/mm) * 0.9

Now, that would seem to imply that the filament skates along the top of teeth, but that’s not the case:

M2 extruder – filament embossing

So, for whatever reason, the effective diameter of the drive pulley matches its actual OD. That will surely vary with a number of imponderables, including the setting for the clamp screw holding the bearing against the filament and drive pulley.

Being that type of guy, I favor baking the actual drive pulley OD into the firmware (because I can actually measure that value), then using the extrusion multiplier to account for the difference. I’ve heard cogent arguments to the contrary, but, for my purposes, the proper value for the extruder should 424.4 step/mm, with a corresponding extrusion multiplier change to 1.00 in slic3r’s configuration.

I wouldn’t be surprised in the least to discover:

• I’m multiplying where I should be dividing (or the other way around)
• There’s a squaring / rooting operation hidden somewhere in there (area vs length)
• Another obvious blunder has tripped me up

Selah.

The best orientation for the Z-minimum switch seems to be slightly angled back:

M2 – Z min limit switch

I used an M4x0.7 socket head cap screw for the height adjustment, with a Nylock nut below the stage:

M2 – Z min limit screw

The assembly instructions show a hex head screw, but the item numbers don’t match the BOM listings. The SHCS lets me hold it firmly in position with the ball-end driver provided in the M2 tool kit while adjusting it:

• 1/4 turn (the handle is square-ish) = 0.7/4 = 0.175 mm
• 1/6 turn (the shaft is hex) = 0.12 mm
• 1/12 turn (you can do it!) = 0.06mm
• less than that is probably fooling yourself.

I printed a pair of tomlombardi’s  7 mm wrenches, which work well for adjusting the Nylock nut underneath the Z axis stage:

M2 – 7 mm wrenches

The left end of the top wrench didn’t adhere to the glass plate, but the business end of the wrench came out OK.

I adjusted the screw to trip the switch with the nozzle 1.0 mm above the platform, then feed that offset in using a G92 Z1.0 instruction in my customized Start G-Code.

However, the most accurate way to set the switch height involves measuring the as-printed thickness of the skirt extrusion around the object. The average value should be 0.25 mm (for my current slic3r settings, anyhow) and all sides should be equally thick: adjust the screw to change the average and adjust the platform screws to remove any tilt. You’ll quickly accumulate a pile of skirt threads, but they make good tchotchkes when you give a presentation on your new toy:

M2 skirt extrusions

You could fiddle with the G92 value to make the average thickness come out right, but I favor making the machine as accurate as possible, so that the software begins from a known-good mechanical setting.

Despite the profusion of surface-finish and print quality test objects, I really care about the dimensions of a 3D printed object, because I tend to build widgets rather than art objects. These two objects, from walter’s Hole and Column Test Print, produce calibrated holes and columns from 0.20 mm to 10.00 mm in diameter, incrementing by 0.20 mm, that should slip neatly together:

M2 – walter hole-column test

Of course, they didn’t, but they came surprisingly close for a first attempt.

The 0.20 and 0.40 posts simply aren’t there, because they’re too small to print with a 0.35 mm diameter nozzle. The 0.60 through 1.40 mm posts were present, albeit fugly, and posts larger than that looked increasingly better.

Although all the holes were present, in the sense that you could see a disturbance in the top and bottom infill pattern, the first visibly open hole appeared at the 0.80 mm spot… and it was immeasurably small. Some holes had misplaced perimeter strands stretching across the openings, which is probably due to excessive speed from my fiddling around with the numbers.

Measuring them with a digital caliper, with no effort at finding the best orientation, then slapping the data into a Libreoffice spreadsheet, produces an interesting graph:

M2 – Initial Hole and Post Diameter Calibration

Above about 3 mm diameter: posts are 0.1 mm too small and holes are 0.3 mm too small. Around 2 mm, posts are too big and holes are way too small. What’s important: above maybe 2.5 mm, the error is essentially constant and does not scale with diameter, so a simple Finagle Constant (or two) can solve (most of) the problem.

Some experiments involving slic3r’s small-perimeter speed seem in order; it was 25 mm/s for these pieces.

More care in measurement would produce better answers, but the real question is whether you can produce holes and columns with known sizes; the answer (as expected) remains “with some care”. That’s not surprising; I expect to have an M2 + PLA version of the small hole diameter Finagle Constant that I’ve been using with Skeinforge + Thing-O-Matic; the correction will certainly fall in the same ballpark.

The slic3r configuration:

; generated by Slic3r 0.9.8 on 2013-04-01 at 16:20:49

; layer_height = 0.25
; perimeters = 1
; top_solid_layers = 3
; bottom_solid_layers = 3
; fill_density = 0.10
; perimeter_speed = 100
; infill_speed = 300
; travel_speed = 500
; scale = 1
; nozzle_diameter = 0.35
; filament_diameter = 1.70
; extrusion_multiplier = 0.9
; perimeters extrusion width = 0.40mm
; infill extrusion width = 0.40mm
; first layer extrusion width = 0.39mm

The source code comes from the Thingiverse customizer as bare G-Code, so there’s not much point in reproducing it here.