Tag: M2

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…

In order to get the crash-test dummy stepper running on the X axis, I had to increase the FERROR and MIN_FERROR values by about two orders of magnitude from their defaults, which suggested I didn’t understand what I was doing and should run some numbers. I don’t profess to know how this works under the hood, though, but what follows seems to make sense.

Background reading:

• Following Error
• Software Step Generation
• Ini file
• Mesa Cards

Software step generation (which I’m not using) has an obvious limitation: the real-time software can produce at most one pulse per interrupt, so the maximum interrupt rate limits the maximum speed. The normal maximum rate is half a pulse per interrupt (the rising and falling edges occur on successive interrupts), but the software step generator can also produce a complete step pulse in a single interrupt; I don’t know the interaction between minimum step pulse width and interrupt period.

The maximum interrupt frequency / minimum interrupt period depends on the interrupt latency jitter, which seems to run around 5 to 10 μs for PC hardware that’s usable with software step generation. Assuming the pulse itself requires a few microseconds, then the minimum period seems to be around 20 to 25 μs, which limits the maximum step frequency to about 40 or 50 kHz. The Marlin firmware has an upper limit of 40000 step/s.

For comparison, a 50 μs base period works fine for the Sherline CNC mill, which tops out at 0.4 inch/s → 6400 step/s → 156 μs/step. That’s one reason converting a CNC mill to a 3D printer doesn’t work well; “normal” 3D printer speeds overtax leadscrews.

However, (I think) the fixed interrupt timing produces horrible period granularity: a 20 μs interrupt period = 50 kHz step frequency means that the next lower frequency with regular pulses is 25 kHz. Any speed requiring pulses between 25 kHz and 50 kHz will (I think) get irregular step timing that is, on the average, correct. That resembles Marlin’s multiple steps per interrupt bunching, without the fixed clumps.

To avoid all that, I’m using a Mesa 5i25 FPGA board that generates step timing in hardware based on a multi-megahertz clock. The specs don’t include a maximum step rate or granularity, but all indications are that it works wonderfully well; I plan to do some measurements to see what’s happening.

Assuming that the 5i25 can emit stepper pulses pretty much exactly when they’re supposed to happen, then the critical timing events depend on the servo loop period, for which everyone seems to use the default 1 ms. At each of those interrupts, the motion controller figures out what the stepper frequencies should be for the next period and twiddles the 5i25 to make them happen.

If, at the end of the next millisecond, the actual (calculated) and projected positions don’t match up, then the motion controller triggers a following error. This all happens in software, as there’s no actual position feedback from the motors.

Assuming that the required stepper pulse rate doesn’t exceed the maximum frequency, (I think) there’s only one point where a following error can happen: at the junction between constant-acceleration and constant-velocity motion. The worst case (seems to be) a G0 move that ramps upward from a dead stop to the maximum allowed speed with the maximum allowed acceleration for an axis. Recall that RepRap firmware seems to use the same code for G1 and limits the G0 speed to whatever the most recent F defined, so you tend to not find G0 commands in RepRap-family G-Code.

The Trajectory Control doc suggests that the planner uses half the maximum defined acceleration while blending path segments. I used the full acceleration, which seems reasonable for single, non-blended motion.

I don’t know if the motion planner forces the junction to fall exactly at an interrupt time, but if it doesn’t, then the axis could accelerate for nearly a whole period after it should start the constant-velocity part of the path. The incremental distance would be:

x = 1/2 a t2

Assuming 10 m/s acceleration, the excess distance would be 0.005 mm after 1 ms. The default FERROR value in PNCConf, which applies during rapid motion, turns out to be 0.0050 mm; I did see following errors as the motion begins, so I think that’s what triggers them.

On the other end of the motion, where the motor slows at a constant acceleration to a dead stop, I think the final position may have a jitter of ±1 motor (micro)step, so the MIN_FERROR value must be at least twice as large as the minimum step size. The M2 runs at 88.9 step/mm (with 1/16 microstepping), so 1 step = 0.011 mm. The default MIN_FERROR in PNCConf is 0.0005 mm (half a micron!) and following errors happened quite predictably at the end of motion.

Sooooo, increasing MIN_FERROR by two orders of magnitude brought it to 0.0500 mm, a bit over the 0.022 = 2 * 0.011 required to cover the ±1 step endpoint error. Because I didn’t really understand what I was doing (and may not, even now), I had been changing both of the following error limits by factors of 10, and that last change turned out to be just enough.

While working all that out, I changed the M542 stepper brick DIP switches to use 1/20 microstepping, which increases the XY resolution to (36 mm/rev) / (4000 step/rev) = 0.009 mm/step → 111.1 step/mm. That doesn’t make any practical difference, but it pushes the XY step size below ten microns, which is certainly good for bragging rights. Yes, I know all about the lack of position accuracy from a microstepping motor, but work with me on this.

Based on those numbers, I picked:

• FERROR = 0.050 mm
• MIN_FERROR = 0.020 mm

Given that 3D printing involves gooey molten plastic laid down in half-millimeter strips, micron-scale error limits really don’t make much practical difference, but at least now (I think) I understand a bit more about the error boundaries.

Also, these limits have nothing to do with the G61.x Exact Path / G64 Path Blending G-Code commands, which tell the motion planner how much slop to allow when computing the path. Given all that gooey plastic, running with something like G64 P0.1 Q0.1 might improve the overall speed quite a bit.