Category: Science

Three firmware constants (seem to) control the acceleration applied to each axis, presented here in their original form:

#define DEFAULT_MAX_ACCELERATION      {9000,9000,30,10000}    // X, Y, Z, E maximum start speed for accelerated moves. E default values are good for skeinforge 40+, for older versions raise them a lot.
#define DEFAULT_ACCELERATION          3000    // X, Y, Z and E max acceleration in mm/s^2 for printing moves
#define DEFAULT_RETRACT_ACCELERATION  3000   // X, Y, Z and E max acceleration in mm/s^2 for r retracts

I do not pretend to understand their interaction and, pursuant to that discussion, some tests and measurements seem to be the only way to find out what’s happening. However, estimating some masses and guesstimating motor performance can put some boundaries on the problem.

Based on weighing a slightly larger stepper motor and the hot end, the complete extruder assembly may weigh (OK, mass) about 600 grams, which I’ll round up to 1 kg to cover bending the filament guide tube and friction. In order to accelerate the extruder carriage at 9000 mm/s^2, the X axis stepper motor force must be:

F = ma = 1 kg * 9 m/s2 = 9 N

The pulley drives 36 mm of belt per revolution, so the effective diameter = 11.5 mm and the radius = 5.7 mm. That means the motor torque will be:

50 mN·m = 9 N * 5.7 mm

I don’t have specs for the Makergear motors, but similar motors have pull-in torques in the 200 to 300 mN·m range, which is flat out to 1000 (full)step/s and decreases to zilch as the speed approaches 10000 (full)step/s. Because the motors run in 1/16 microstep mode, Marlin’s peak 40000 (micro)step/s rate works out to 2500 (full)step/s, where the motor pull-in torque is maybe half of the maximum.

The motor pull-out torque falls off to nothing around 1000 (full)step/s = 16000 (micro)step/s, which suggests you can’t slow the stages down nearly as fast as you speed them up, at least beyond about 10000 (micro)step/s.

All of that depends on the motor current, of course, and that depends on the amount of heat you’re willing to generate in the motors. I really must build a better dynamometer.

Assuming the Y stage + heater + glass weighs 4 pounds = 2 kg, the numbers are twice as large, but they’re in the same ballpark.

I tried a few values for the Z acceleration and settled on something slightly larger, but that won’t apply to a different motor.

I have no way to estimate the force required to drive the filament, but the gearbox multiplies the motor torque by a factor of 5, so there’s a speed-torque tradeoff lying in wait.

I modified the acceleration constants to bring the overall limits in line with the per-axis values:

#define DEFAULT_MAX_ACCELERATION      {9000,9000,75,10000}
#define DEFAULT_ACCELERATION          10000		// X, Y, Z and E max acceleration in mm/s^2 for printing moves
#define DEFAULT_RETRACT_ACCELERATION  10000		// X, Y, Z and E max acceleration in mm/s^2 for r retracts

Changing the last two values from 3000 to 10000 produced a dramatic increase in acceleration, so those numbers do act as overall limits on the per-axis values in the first line.

Because the motion planner ramps the velocity up at the maximum possible acceleration (reduced, as needed, to accommodate the motor with the lowest acceleration involved in the motion), higher acceleration values allow the motor to reach the desired speed sooner, so shorter motions run faster.

For example, reaching 200 mm/s² from a standing start requires 6.7 mm at 3000 mm/s² and 2.2 mm at 9000 mm/s². Braking to a stop requires the same distance, assuming the pull-out torque allows it. Contemporary motion planners that can match velocities around corners where straight-line segments join will allow higher sustained speeds, so they don’t require slowing to a dead stop.

But, of course, the 3D printer’s overall structure must be rigid enough to restrain the reaction forces caused by high accelerations and the printer must be anchored well enough to not sidle off the table. The M2 can handle a single high-speed move, but chaining multiple moves together shakes the steel chassis rather violently; that happens when you select the Slic3r “Avoid crossing perimeters” option.

Knowing the number of motor steps required to move an axis by 1 mm, the next step is to figure out how fast each axis can possibly move, given the restrictions of the Marlin firmware driving the motors.

Dan Newman pointed out that Marlin runs with a maximum 10 kHz interrupt rate, with up to four steps issued per interrupt. The constant controlling (or at least defining) that is in Configuration_adv.h (with a comment that seems irrelevant to the M2’s setup):

#define MAX_STEP_FREQUENCY 40000       // Max step frequency for Ultimaker (5000 pps / half step)

Below the 10 kHz rate, the step interrupt occurs whenever the next step must happen, so it does not have a constant frequency. Above 10 kHz, the steps (seem to) emerge in bursts, so there’s likely a good bit of jitter that I should measure. In any event, there’s an obvious loss of resolution at high speeds, which is a problem common to all variable-frequency pulse generators that’s worse for relatively low-frequency software generators used in high-speed applications.

In any event, these numbers show the absolute maximum possible speed for each axis:

• X and Y axes: 450 mm/s = (40 k step/s) / (88.89 step/mm)
• Z axis: 100 mm/s = (40 k step/s) / (400 step/mm)
• Extruder: 94.3 mm/s = (40 k step/s) / (424.4 step/mm)

Due to the low torque available from the Z axis motor, the actual maximum speed seems to be around 30 mm/s = 1800 mm/min. After I replace the motor, I’ll measure the actual performance and see what’s reasonable.

One could quibble about the extruder, as the extrusion multiplier affects the final speed. The extruded thread squirts out at a pretty good clip if the motor turns at full speed:

2350 mm/s = (1.75 mm)2 / (0.35 mm)2 * 94 mm/s

It’s not clear the hot end can melt plastic fast enough to keep up with that pace more than momentarily, but I haven’t measured that yet.

However, if the X and Y axes both move at 450 mm/s, then the nozzle moves at 640 mm/s = √2 * 450 mm/s relative to the platform, so the maximum extruder speed while printing will be roughly:

26 mm/s = (640 mm/s) * (0.35 mm)2 / (1.75 mm)2

That assumes the printed thread has the same cross-section area as the nozzle, which is roughly true for my choice of output:

• Thread: 0.1 mm² = 0.4 mm wide * 0.25 mm thick
• Nozzle: 0.096 mm² = pi * (0.35 mm)² / 4

If you bake the extrusion multiplier into the step/mm value, then compute the maximum speed without applying the same multiplier in slic3r, the plastic should come out of the nozzle at the same speed.

So the speed setup looks like this:

#define DEFAULT_MAX_FEEDRATE          {450, 450, 30, 94}    // (mm/sec)

After that exchange, I dabbed some Oatey PVC Purple Primer/Cleaner on two PLA slabs:

The active ingredient involved in PLA bonding is tetrahydrofuran, which makes up anywhere from 10 to 40% of the primer (the MSDS gives a broad range). The primer immediately marred the PLA surface, which is exactly what you want in a solvent adhesive.

After an overnight clamping, I couldn’t pull or peel that joint apart: the two slabs had become one. That’s unlike the paint stripper test that didn’t bond well at all. Good enough for me.

Obviously, you’d prefer Clear Primer for natural PLA, but Purple Primer is what I had on hand.

Given that this stuff has no solid content, I think it’s more suitable as a PLA adhesive that the thicker PVC Cement. However, clear cement would be less likely to run along the thread seams and ruin the surface finish outside the joint than water-thin primer.

Tradeoffs, tradeoffs… but now I can build things from PLA subassemblies!