Thing-O-Matic: Companion Cube Print Quality vs. Speed

Companion Cubes* being nice handouts, at least in certain circles, I printed three arrays of nine. This being an opportunity for Science, they’re printed at 25, 40, and 50 mm/s, all with 100 mm/s moves.

Cube array - 25-100
Cube array - 25-100

They’re scaled to about 16 mm on a side, making them about as small as anything you’d want to print. With a 0.66 mm extrusion width (0.33 mm thick and 2.0 w/t, they’re only 24 threads wide, which doesn’t allow for much detail. Here’s the top of one printed at 25 mm/s:

Cube top - 25
Cube top - 25

And at 50 mm/s:

Cube top - 50
Cube top - 50

Obviously, the faster cube turned out uglier. The 40 mm/s cubes look a whole lot like the 50 mm/s ones, which means the best printing quality occurs well below that.

The front at 25 mm/s:

Cube front - 25
Cube front - 25

And at 50 mm/s:

Cube front - 50
Cube front - 50

The odd shadows on either side of the central bump become more obvious at an oblique angle. At 25 mm/s:

Cube front oblique - 25
Cube front oblique - 25

And at 50 mm/s:

Cube front oblique - 50
Cube front oblique - 50

This confirms a suspicion I’ve had for a while that the XY stages don’t have the positioning accuracy required for this level of detail when printing at any reasonable speed: they tend to oscillate slightly after changing position. I think acceleration limiting would help this, but I have no way to prove that. I know a more rigid mechanical assembly would help a lot, but there’s no way to get there from here.

Obviously, slowing down will improve the overall quality. I’m printing at high speeds to see what goes wrong; I have no objection to reducing the speed to a crawl in order to wring the best quality out of the hardware.

Moving at 100 mm/s, however, definitely reduces the opportunity for ooze. Even with Reversal, sometimes the nozzle dribbles a bit and very fast moves tend to produce a hair-fine thread that’s easily removed from the finished object. In this case, all three sets of nine cubes printed with no threads at all.

These were printed with Reversal set to 25 rev/min, 110 ms in and out, and no early motion. That eliminates suck-out as the extruder reverses while the nozzle approaches the end of the thread, but still leaves a zit at the endpoint where the nozzle moves to the start of the next thread:

Cube rear oblique - 25
Cube rear oblique - 25

The zits appear identical with faster print speeds, so they don’t depend on anything other than Reversal.

The other two sides of each cube look about the same.

For completeness, here’s the bottom at 50 mm/s:

Cube bottom - 50
Cube bottom - 50

Comparing that with the top suggests that Skeinforge used bridging fill, rather than surface fill.

(*) They’re actually Weighted Storage Cubes, as they lack the hearts found on Companion Cubes. My Shop Assistant asserts that if you cuddle them enough, they’ll grow hearts…

26 thoughts on “Thing-O-Matic: Companion Cube Print Quality vs. Speed

  1. “…I think acceleration limiting would help this, but I have no way to prove that.”

    Oh, come on, how come you have not hooked this up to EMC yet?!? :-)

    Serious question, though. Anything preventing someone from doing this without too much trouble?

    – Steven Ciciora

    1. how come you have not hooked this up to EMC yet?!?

      I keep asking myself that very same question. After all, it’s sitting on a shelf next to the Sherline, it’s connected to the same PC that runs the Sherline… and there’s a spare parallel port already hacked into the PC.

      What’s standing in the way is that I’ve finally gotten the printer working the way it should. What I want to do now is get back to some of the other projects I’ve had on the back burner for the last five months: believe it or not, I didn’t buy the printer just to improve it!

      doing this without too much trouble?

      Here’s what it would take:

      • Wire stepper driver boards to PC parallel port
      • Build Arduino interface for temperatures and MOSFETs (cannibalize EC?)
      • Write filter / scripts to adapt RepRap G/M codes to EMC2 dialect
      • Build ladder logic / HAL modules to control temperatures
      • Tune for best picture

      Then the overall workflow would go like this:

      • Build correctly positioned / sized 3D model of the part
      • Convert to STL
      • Slice with Skeinforge (not using ReplicatorG) to get G-Code
      • Run filter / convert to EMC2 G-Code
      • Run Axis to print the part

      There’s no reason Skeinforge couldn’t produce EMC2 G-Code directly, but there are some functions EMC2 doesn’t handle yet. Putting a translator shim in between doesn’t require any upstream changes, which seems like a Good Thing all around.

      I’d love to do it. If anybody’d like to finance that effort, we could build a world-class 3D printer pretty quickly… otherwise, it’s going to take a while. [grin]

  2. So you’re traveling at 100 to prevent ooze and not to decrease build times? I’ve been skeptical of fast travel for decreased build times as it kinda freaks me out and the build time decreases is likely low, but if quality can be increased I should look into it.

    1. traveling at 100 to prevent ooze and not to decrease build times

      And because I can

      It really does pull the ooze remaining from fast reversals into a hair, except for cases where the moves are / seem to be scaled to a lower speed along with the actual printing. I don’t know what determines which speed Skeinforge uses.

      You must turn off Comb, because zig-zagging along a hex fill pattern just isn’t good for the printer. Point-to-point fast moves are fine, though.

      fast travel for decreased build times

      It turns out that I print the first layer so slowly (to get perfect adhesion to the platform) and generally print such small parts that even a factor-of-three speed increase for the upper layers doesn’t reduce the build time all that much. Couple that with the decreased quality and, well, speed kills.

      But knowing that the printer can move reliably at those speeds provides some assurance it’ll work perfectly at lower speeds and that counts for a lot.

      1. Fast print speed is one thing, but fast traversal is another and especially if it does not effectively reduce build times. It seems like it is just asking for trouble.

        In addition to the nozzle more likely to hit something without time to soften it I find that fast traversal messes with accuracy of the end point of a thread. Maybe my temps are too low or I don’t dare to traverse fast enough.

        1. the nozzle more likely to hit something

          I ran into that (so to speak) while trying to print the Heart Gear thing: nine different objects on the platform at once. All those spiky gear teeth curled upward during printing and the nozzle clobbered them unmercifully. After a couple of failed print sessions, I got a clue and gave up.

          To my way of thinking, that’s not the printer’s fault: you must design the object (and its layout) with knowledge of how the material will behave and how the printer works. We already avoid overhangs and I think we must also avoid features that inherently curl upward as they cool.

          I’ll try building that one again, but one piece at a time: the nozzle will remain inside the gear, so it won’t have an opportunity to clobber the teeth from the outside. That’s the plan, anyway.

          fast traversal messes with accuracy of the end point of a thread.

          That suggests the motor can’t decelerate the stage fast enough and is losing steps. Speed kills!

  3. The oscillation is definitely there on my CupCake with the lowrider:

    This showed up as an artifact, but it makes me think a test piece and a little math could reveal the resonant frequency for each stage, and that might point the way to a solution.

    Hooking one bot to the EMC would be fun for one person. Getting acceleration curves into the code would be awesome for a bunch of people :)

    1. point the way to a solution

      I think the only way to get better print quality is to build a printer with better rigidity and lower moving mass. Unfortunately, that will cost more and the Thing-O-Matic / Ultimaker designs with plywood and acrylic may be a local optimum: keep the speeds down and accept the build times.

      Getting acceleration curves into the code

      But acceleration really doesn’t belong there; the printer should control its motion, based on its design parameters. The only reason acceleration goes into the G-Code is that an 8-bit microcontroller really can’t handle four-axis blended acceleration in real time along with everything else it’s supposed to be doing.

      1. I disagree that acceleration needs to happen at the gcode level. If the printer is in charge it will have to analyze multiple gcodes in order to get any sort of continuity. Also at the gcode stage information has already been lost. When done at the slicing stage information about the model can be factored into the acceleration.

        Personally I feel the best thing is to make the printer as dumb as possible and handle only step/dir which is how EMC works from what I understand.

        1. make the printer as dumb as possible and handle only step/dir which is how EMC works from what I understand.

          When I say “printer”, I mean the combination of the machinery and EMC2. Viewed from the outside, “the printer” accepts G-Code and produces printed objects. EMC2 controls everything that the printer does; in fact, the trajectory planner does process multiple G-Code moves in order to blend the acceleration profiles.

          That’s unlike the present situation, where RepG translates human-readable G-Code into S3G format, handles part of the motion planning, and depends on the firmware for the rest. That makes “the printer” whatever the firmware does, with RepG talking to it over a surprisingly low-bandwidth USB channel.

      2. The ultimaker design seems to go a long way to lowering the moving mass, the speed he is able to get shows its actually counting for something. I haven’t seen one in personal so I really have no handle on the rigidity.

        Going to a die-cut and bent steel design solves the structural problem at a low per unit cost, which is the approach the UP! printer uses. I would think that was hugely expensive for such a small market but maybe its not as bad in china. I imagine when HP or Xerox comes out with one they’ll do the steel internals with large injection molded outers like everything consumer is done now. Perhaps bfb will do it that way now that they have big corporate backing.

        For us small market people I’ve been thinking about an aluminum composite panel like dibond or alucobond. Its stocked by signage suppliers, is fairly cheap, extremely rigid, and it should move a lot less with temp and humidity changes. The 6mm kind is around twice as dense as plywood. There is also a cheaper version of the same stuff called e-panel using thinner aluminum sheets (8 mil vs 12mil) that I imagine is less dense, only available in 2,3 or 4mm however. It also comes pre-finished and can be worked using regular wood or metalworking tools, or cnc routed, or perhaps laser cut. I keep meaning to try it on our medium sized (1.5KW) CO2 laser, cutting through would be no problem of course but the edge quality is a crap shoot until someone tries it.

        The plywood used on the makerbot seems to be closer to veneered wood than serious plywood. It looks like it has one massive center ply that makes up 90% of the thickness and two very thin but pretty skins. That means its probably a lot less stable than even regular plywood, especially with humidity changes.

        1. speed he is able to get shows its actually counting for something

          Although it seems there’s some trouble with X axis rigidity at high speeds.

          aluminum composite panel

          I like that idea: mostly, stiff and light = good. I bet you could epoxy the whole frame together to get something really rigid, then insert the mechanical bits inside. You’d want to spend some time thinking about how you’d repair / modify the thing, though, so that it’s not really awkward.

          It’ll definitely require some clever mechanical ideas to take DIY 3D printers from where they are now to where we’d like them to be!

    1. Reports from other folks say they work pretty well; I haven’t run the numbers.

      I’m starting to grit my teeth whenever I read the word “awesome”, though…

      1. They’re clearly not as awesome as they could be; we all know that removing the x/y stages would be vastly easier if the x stepper simply had a removable connector like the z stepper. I’m ready to consider that a functional requirement.

        1. a removable connector

          Connectors are good, but connectors are always where intermittent failures creep in. One hopes the next iteration has better (heck, any) adjustability, accessibility, and serviceability… but adding those features inexorably drives the cost (and, thus, the price) up.

  4. Ed,

    Looking good! The wobble you call position accuracy is from your highly unconstrained axes. For discussion see – for an example of graphed motion. I point to that link only for the hand drawn picture representing motion. Not the idea of control through program. A moving mechanical system does not necessarily need electronics or program for good behavior ;-).

    I’d hazard a wag that your graph would be more spikes than chopped tops – & less – smooth motion. Goals should be smooth curves – sinusoidal even with diminishing extremes. Similar to the graph of good PID settings. Fast move – over shoot – smooth motion oscillation tending to optimum center line. Or completely dominated constrained control! But, then we would have to bolt the bot down, apply chains and MO’POWHA!

    Getting some dampning or counter force back into your system will limit some bang at the end of the travel. Newton’s 1st law: Every object in a state of uniform motion tends to remain in that state of motion unless an external force is applied to it.

    Myself, on the stock T-O-M, I really need to dial in SF. I’m too young to print your speeds. [link to my cube photo:, feed rate: 36mm/s, travel rate: 70mm/s ]. I lack the printing knowledge, skill and the X-Y shove, bang, stop, change direction issue you’ve got. Your having freed up your bot’s axes is both good and bad. Good because you are working towards a more refined design. Bad because no resistance is – well – these moving systems do need a little resistance to movement (Back to Newton.). The resultant motions should be smooth, consistent and in both directions (a good medium grease.) – not binding, restrictive, and inconsistent as OEM. You got out the bind now you gotsa put in da smooooove…. (smile)


    1. highly unconstrained axes

      Compared to the starting point, yup, they’re pretty nearly free-floating! Ball-bearing idler pulleys would finish the job.

      Rob’s diagram covers it pretty well. IIRC, EMC2 uses a one-instruction lookahead for acceleration blending, with a controllable position error at the endpoint of the current motion. The velocity profile is trapezoidal, except for short moves that can’t get up to speed where it’s triangular, and the position error allows a non-zero velocity going around the corner at the endpoint.

      There’s no need for an arbitrary minimum velocity: you always accelerate as hard as the limit allows and that’s exactly how fast the velocity will increase. At the endpoints, the specified position error gives you the minimum velocity.

      So, basically, he’s reinventing EMC2’s algorithms. Which is why I think just using EMC2 would be easier and better, but …

      your graph would be more spikes than chopped tops

      Nope, the velocity profile now looks like a sequence of rectangles, because the firmware simply starts spinning the motors at the commanded speeds. The oscillation at the endpoints comes from the bang-bang nature of the motion: full speed until the motors suddenly stop, then a bit of ying-ying-ying while the flexy parts dissipate the energy of a kilogram worth of XY stage.

      If the firmware applied deceleration, then the energy goes back into the motor and the stage arrives at the endpoint with zero velocity (or whatever the blend parameters allow), so that there’s no energy left for the ying-ying. Without controlling the endpoint velocity, there’s no possible damping that can dissipate that energy: it’s an impulse load that’s impossible to wish away.

      these moving systems do need a little resistance to movement

      That’s what the deceleration part of the curve provides: it dumps the kinetic energy back into the motor. You can dissipate energy in frictional resistance all along the way, which implies you’re always putting an unnecessary load on the motor, or you can dissipate it only when required. The pulleys alone provide a fairly high and constant torque load, so there’s still way too much frictional resistance. Better to move freely and dump the energy only when you don’t need it.

      But slobbering STP on the rods does have a certain retro charm… [grin]

    1. Absolutely! In fact, I was fiddling with the OpenSCAD file just now.

      Turns out that the bumps vanish on two sides, so I’m parameterizing the daylights out of it: making the widths & thicknesses into multiples of the wall thickness, which I’ve set to my thread thickness. Plus rounding by Minkowski, which my Shop Assistant figured out for me…

      More later…

      1. Awesome.

        When you have it fixxored, I would be happy to replace my static version with your parameterized one.

  5. Ed,

    Did you ever use the ‘Lash’ command in SF? It seems to be able to program for the backlash of a system.

    1. I haven’t used it, simply because I don’t have any convincing way to measure any backlash that exists.

      In any event, it can compensate only for static backlash by turning the motors just enough to remove the backlash while reversing direction. The wobbulation caused by backlash (or whatever) while moving is a whole ‘nother problem.

Comments are closed.