Category: Science

While pulling together a talk on OpenSCAD modeling (more on this later), I ran off a batch of calibration and “torture test” objects, with the intent of seeing how my somewhat modified M2 performs. The short answer is that you (well, I) can’t ask for anything better…

Using my OpenSCAD module based on nophead’s polyholes to adjust low-vertex polygons by a constant +0.2  mm produces results that are within ±0.1 mm of the nominal value for holes larger than 3.0 mm:

That level of as-printed cleanliness is typical: no stringing, no hair, no misplaced globs, no retraction problems. Basically, the plastic shape on the platform matches the mathematical shape on screen.

Goaran’s Calibration Block came out fine, except for the intended-to-be-impossible overhangs:

All of the linear features are with ±0.1 mm of nominal; both the 0.5 and 0.25 mm walls came out at 0.40 mm, because that’s the thread width. Slic3r doggedly puts a thread down the middle of hair-fine walls, which I think is a Good Thing.

The holes came out less than 0.3 mm undersize, which is about what you’d expect because they’re not pre-distorted and have far too many sides. The 1.0 and 0.5 mm diameter holes are present, but just barely visible; those simply aren’t reasonable sizes for this technology.

The bottom view shows a few strings in the bridge test area and more detail of the overhang:

Grouping the overhangs like that produced a flat surface that tended to curl upward, so the final slopes don’t match the design. In round numbers, the M2 can handle something like a 60° overhang reasonably well.

Cymon’s 3DHacker demo object came out OK, even the severe overhangs in the legs of the digit 3:

The top view shows the shape in the box looks fine, but with some curls in the main structure. The arch closed over a few random strands, so it’s rougher than I’d like:

The spires are lumpy and there’s more striation than I’d like, but this lies well outside the realm of stuff that I build. If I were doing it for real, I’d add some support structures here & there.

A new Tux Cookie Cutter is perfect:

The wall stacks up neatly to the single-thread blade on the top, with none of the retraction glitches found in the Thing-O-Matic version:

So, all in all, I’d say there’s not much room for improvement.

Now, to coerce LinuxCNC into producing similar results on the same hardware, then proceed onward from there…

The original M2 Z axis motor required extremely low acceleration and speed settings, because it produced barely enough torque to lift the weight of the Z stage + HBP + glass platform. The new motor can produce about twice as much torque, so it should perform much better: all of the additional torque can go to accelerating that weight.

I weighed all the bits and pieces while I had the M2 apart, although I forgot to weigh the motor + leadscrew separately:

• 2.2 kg – Z stage including Z motor
• 290 g – old Z motor + leadscrew + nut
• 220 g – motor similar to new motor minus leadscrew
• 963 g – HBP + glass + clips

So, in round numbers, the whole assembly weighs about 3 kg = 29 N = 6.6 pounds. That’s surprisingly close to my original guesstimate of 3 kg = 7 pounds; I round in the worse direction when there’s only one significant figure.

With the new motor in place, the rods & leadscrew lubed up, and the platform in place, it’s not quite heavy enough to fall under its own weight; it would just barely fall with the old motor. The slightest touch moves it along, though, which means that the angle of friction is just over the lead angle.

The thread form is 30° trapezoidal, so the pitch diameter for an 8 mm OD thread is about PD = 7.2 mm. For an 8 mm lead thread, the lead angle is 19.5° = arctan(8 mm / π · 7.2 mm). Wikipedia’s entry on leadscrews reports the coefficient of friction for oily steel on bronze is between 0.1 and 0.16 for a buttress thread. This thread is trapezoidal, the nut isn’t worn in, the alignment’s probably off a bit, and so forth and so on; so let’s say the angle of friction is 20° and the coefficient of friction is 0.35.

If the new motor can produce, let’s suppose, 500 mN·m of torque, then the upward force on the stage will be:

(2 T) / (PD tan(lead angle + friction angle)) = 1 N·m / (7.2 mm x 0.84) = 165 N

In the ideal world of physics, applying 165 N to a 3 kg stage should accelerate it at 55 m/s² = 55000 mm/s² = 5 G.I don’t believe that for a moment, either, particularly because stepper motor torque drops off dramatically at higher speeds.

However, that suggests that, at a rational acceleration, the maximum stepper motor speed could very well be limited by the Marlin 40 kHz step frequency limit to 100 mm/s = (40000 step/s) / (400 step/mm) = 6000 mm/min.

Given that I’m running the XY motors at 5000 mm/s², I set the Z acceleration to 5000 mm/s² and discovered that it would stall on the way to 100 mm/s. Backing off to 2000 mm/s² worked better, so I tweaked the Marlin configuration thusly:

#define HOMING_FEEDRATE {75*60, 75*60, 30*60, 0}  // set the homing speeds (mm/min)

#define DEFAULT_MAX_FEEDRATE          {450, 450, 100, 94}    // (mm/sec)
#define DEFAULT_MAX_ACCELERATION      {5000,5000,2000,10000}

Now that’s more like it…