Ed Nisley's Blog: Shop notes, electronics, firmware, machinery, 3D printing, laser cuttery, and curiosities. Contents: 100% human thinking, 0% AI slop.
Although chain mail provides a good test of the M2’s setup and slicing parameters, it doesn’t offer much in the way of infill. To test that, I designed a holder for the cap of the bulk laundry detergent container:
Detergent Cap Holder – in place
The container must rest on its side, but if you snap the cap back in place, detergent will ooze out between the cap and the container and drip on whatever’s below. The never-sufficiently-to-be-damned Whirlpool high-efficiency front loading washer vibrates like crazy during the spin cycle, shaking anything from its top to the floor. The cap must sit in a cup to catch the inevitable ooze down its side, the wire shelf already has a bunch of other crap on it, and I needed a bulky test object, soooo ….
We regard that detergent container and its cap as a botched design.
Anyhow.
The holder has pair of holes in its back surface for the copper (!) hangers:
Detergent Cap Holder – solid model – rear
I stripped a length of 10 AWG wire, straightened & annealed it, bent up a pair of hooks, then hammered them just flat enough to work-harden the copper, and they were all good.
Printing that massive block with 20% infill showed that the nozzle collected enough PETG during the first few layers to leave a substantial booger behind:
Detergent cup holder – oxidized PETG
Fortunately, that was the only one and it ended up on the inside, tucked out of sight.
The PETG deposit on the outside of the nozzle gradually darkens from the original magenta to brown, which I’m pretty sure means that it’s oxidizing / decomposing / going bad. There’s no obvious way to remove the booger during the print; I’ve taken to wiping the nozzle after each object, while it’s still hot and the PETG remains flexible.
Because the nozzle didn’t accumulate any more PETG during the rest of the print, it’s not a constant problem, but I have seen boogers several times so far.
Perhaps continued refinement of the slicing parameters will help? One can always hope…
The OpenSCAD source code:
// Detergent Cap Holder
// Ed Nisley KE4ZNU - March 2015
Layout = "Show"; // Show Build
//-------
//- Extrusion parameters must match reality!
ThreadThick = 0.20;
ThreadWidth = 0.40;
HoleWindage = 0.2;
Protrusion = 0.1; // make holes end cleanly
function IntegerMultiple(Size,Unit) = Unit * ceil(Size / Unit);
//-------
// Dimensions
RecessX = 45.0; // cap recess
RecessDia = 55.0;
RecessDepth = 10.0;
RecessSides = 16*4;
BaseThick = 5.0; // block thickness below cap
PinDia = 2.5;
PinLength = 20.0;
PinOC = 65.0;
PinInset = 7.0;
PinZ = BaseThick;
Block = [RecessX,PinOC + 2*PinInset,30.0]; // overall block size (X to cap center)
FairingRadius = Block[2] - RecessDepth - BaseThick;
//-------
module ShowPegGrid(Space = 10.0,Size = 1.0) {
RangeX = floor(95 / Space);
RangeY = floor(125 / Space);
for (x=[-RangeX:RangeX])
for (y=[-RangeY:RangeY])
translate([x*Space,y*Space,Size/2])
%cube(Size,center=true);
}
module PolyCyl(Dia,Height,ForceSides=0) { // based on nophead's polyholes
Sides = (ForceSides != 0) ? ForceSides : (ceil(Dia) + 2);
FixDia = Dia / cos(180/Sides);
cylinder(r=(FixDia + HoleWindage)/2,h=Height,$fn=Sides);
}
module Holder() {
difference() {
union() { // main shape
translate([-Block[0]/2,0,Block[2]/2])
cube(Block,center=true);
cylinder(d=Block[1],h=Block[2],$fn=RecessSides);
}
for (j=[-1,1]) // mounting pin holes
translate([-(Block[0] + Protrusion),j*PinOC/2,PinZ])
rotate([0,90,0]) rotate(180/6)
PolyCyl(PinDia,PinLength + Protrusion,6);
translate([0,0,Block[2]]) // fairing arc
rotate([90,0,0])
cylinder(r=FairingRadius,h=2*Block[1],center=true);
translate([Block[0]/2,0,Block[2]/2 + RecessDepth + BaseThick]) // flat top
scale([1,2,1])
cube(Block,center=true);
translate([0,0,BaseThick])
cylinder(d1=RecessDia,d2=1.1*RecessDia,h=Block[2]);
}
}
//-------
// Build it!
//ShowPegGrid();
if (Layout == "Show") {
Holder();
}
if (Layout == "Build") {
translate([0,0,0])
rotate([0,0,0])
Holder();
}
Chain Mail – PETG on nozzle – platform switch clearance
The clearance under that switch lever doesn’t amount to much…
The patch came out looking pretty good, though:
Chain Mail – 4-wide – PETG hairs – bridging
The small red blob on the right side of the nozzle in the first picture tells a tale: the nozzle tends to pull fine hairs from one perimeter to the next, despite 1 mm of retraction. Fiddling with the retraction on subsequent patches didn’t improve matters.
Even though the infill isn’t overstuffed, the nozzle tends to collect and redeposit small amounts of PETG as it travels over the surface. Those small blobs turn into fine hairs when the nozzle moves from one island to the next.
Reducing the bars from six threads to four threads shows that bridging (at 25 mm/s and 0.9 flow rate) seems messier than PLA:
Chain mail – 4 strand PETG bridging
Despite that, all the links came out OK and the sheet was reasonably flexible. After some fiddling with speeds and patterns, these small-link patches popped off the platform easily and were just as flexy as the PLA sheet below them:
Changing from PLA to PETG with a V4 hot end and 24 V power required several slicing adjustments, some of which weren’t at all obvious. It’s not all settled down, but what you see here comes from a bunch of test objects and tweaks that you’ll see over the next few days; this is basically a peek into the future.
M2 V4 Calibration Objects
The obvious changes:
Extrusion temperature: 250 °C
Platform temperature: 90 °C
Hot PETG seems rather sticky and produces hair-fine strings that aren’t due to poor retraction. Running at 230 °C is possible, but the strings are nasty. The V4 hot end shouldn’t run over 250 °C; fortunately, some tests suggest the stringing doesn’t Go Away at 260 °C, so moah powah! isn’t required.
Hair spray on glass works well above 90 °C and not at all below 80 °C. A stick of Elmer’s Washable Glue Stick, chosen because it was on the Adhesive Shelf, produced exactly zero adhesion at any platform temperature I was willing to use. Its “washable” nature surely contributed to the failure; you want something that’s gonna stick with you forever.
The eSun PETG filament diameter varies from 1.63 to 1.72 mm, which seems like a lot compared to the MakerGear PLA I’d been using; I’ve told Slic3r to run with 1.70 mm. In practice, it doesn’t seem to matter; the average over a meter works out to 1.70, I haven’t seen any abrupt bulges, and the objects come out fine. This spool arrived late last year, early in eSun’s production, so perhaps they’ve smoothed things out by now.
A few iterations of thinwall box building put the Extrusion Multiplier at 1.11, producing a spot-on 0.40 mm thread width at either 0.20 or 0.25 mm thread thickness.
Infill:
Infill overlap: 10%
Max infill: 40%
Infill pattern: 3D Honycomb
Top/bottom pattern: Hilbert Curve
Combine infill: 3 layers
The first attempt at a solid box (left of center, first row) became so overstuffed I canceled the print; the top bulges upward. A few parameter tweak iterations produced the perfect 100% filled solid box to its right, but in actual practice a 40% 3D Honeycomb will be entirely strong enough for anything I build.
Reducing the overlap from 15% to 10% reduced the obviously overstuffed junction just inside the perimeter threads.
Cooling:
Fan for layers below 20 s
Minimum layer time: 10 s
Minimum speed: 10 mm/s
PETG wants to go down hot, but printing a single thinwall box requires that much cooling to prevent slumping. Might be excessive; we shall see.
Speeds:
First layer: 15 mm/s
External perimeters: 25 mm/s
Perimeters: 50 mm/s
Infill: 75 mm/s
Travel: 300 mm/s
Slower XY speeds seem to produce better results, although those values aren’t based on extensive experience.
The first layer doesn’t work well at higher speeds, with acute corners and edges pulling up as the nozzle moves away. Using the Hilbert Curve pattern not only looks pretty, but also ensures the nozzle spends plenty of time in the same general area. Higher platform temperatures work better, too, and I may goose the 40 V supply a bit to improve the 0.2 °C/s warmup rate.
The travel speed went up from 250 mm/s in an attempt to reduce stringing, but it may be too aggressive for the Y axis with the new 24 V supply. On very rare occasions, the Y axis stalls during homing, despite not changing the speeds in the startup G-Code, and I’m still accumulating experience with that.
Bridging isn’t nearly as clean as PLA. After some tinkering, a bridge speed of 25 mm/s and flow of 0.90 seems to work, but some chain mail patches suggest there’s plenty of room for improvement.
Mechanically, PETG is softer and more resilient than PLA, with a much higher glass transition temperature. Larger objects with 40% infill are essentially rigid and smaller objects are bendy, rather than brittle.
On the whole, PETG seems like it will work well for the stuff I build, although magenta isn’t my favorite color…
CAUTION: Don’t use this Slic3r configuration unless:
After installing things like imagemagick and mjpg_streamer on the Raspberry Pi, I exhumed a quartet of Logitech cameras from the heap to see how they worked. None bear any identification, apart from a tag on the cable, so here’s what I found out for later reference.
They’re all reasonably good for still pictures, if you don’t mind terrible initial exposures. The default program works OK:
fswebcam -d /dev/video0 -r 320x240 image.jpg
On the other hand, getting any streaming video requires searching through the parameter space, which wasn’t helped by the total lack of documentation. The Arch Linux wiki has a useful summary of camera & drivers, with pointers to additional lists-of-lists. The OctoPrint repo documents the mjpg-streamer plugin parameters.
So, we begin…
This camera, one of two identical cameras in the heap, has a clip that used to fit on the upper edge of a laptop display:
Logitech QuickCam for Notebook Plus – front
One has a tag:
Logitech QuickCam for Notebook Plus – tag
To make the tag data more useful for search engine inquiries:
M/N: V-UBG35
P/N: 861228-0000
PID: CE64105
From lsusb:
Bus 001 Device 008: ID 046d:08d8 Logitech, Inc. QuickCam for Notebook Deluxe
With Raspbian on the RPi, 640×480 video tears and stutters, leaving 320×240 as the least-worst alternative:
The cameras don’t support YUYV at all and the video quality is mediocre, at best, but they do have a manual focus ring that lets you snuggle the camera right up against the subject.
This ball camera:
Logitech QuickCam Pro 5000 – on tripod
Has a tag:
Logitech QuickCam Pro 5000 – tag
Which reads:
M/N: V-UAX16
P/N: 861306-0000
PID: LZ715BQ
From lsusb:
Bus 001 Device 009: ID 046d:08ce Logitech, Inc. QuickCam Pro 5000
It requires YUYV at 320×240 (on the Pi) and nothing else works at all:
It produces even worse video than the Notebook camera.
This HD 720p camera has C130 scrawled on the front in my handwriting:
Logitech HD Webcam C510 – front
And a tag:
Logitech HD Webcam C510 – tag
Bearing this text:
M/N: V-U0016
P/N: 860-000261
PID: LZ114SF
The scrawled C130 doesn’t match up with what lsusb reports:
Bus 001 Device 010: ID 046d:081d Logitech, Inc. HD Webcam C510
It produces very nice results in many resolutions, using YUYV mode, although I think its native resolution is 1280×720 and that works perfectly on the Pi:
Given that I’m throwing all the balls in the air at once:
V4 hot end / filament drive
24 VDC motor / logic power supply
PETG filament
It seemed reasonable to start with the current Marlin firmware, rather than the MakerGear version from long ago. After all, when you file a bug report, the first question is whether it happens with the Latest Version.
Marlin has undergone a Great Refactoring that moved many of the constants around. I suppose I should set up a whole new Github repository, but there aren’t that many changes and I’ve gotten over my enthusiasm for forking projects.
Anyhow, just clone the Marlin repo and dig in.
In Marlin_main.cpp, turn on the Fan 1 output on Arduino pin 6 that drives the fans on the extruder and electronics box:
pinMode(6,OUTPUT); // kickstart Makergear M2 extruder fan
digitalWrite(6,HIGH);
You could use the built-in extruder fan feature that turns on when the extruder temperature exceeds a specific limit. I may try that after everything else works; as it stands, this shows when the firmware gets up & running after a reset.
In Configuration_adv.h, lengthen the motor-off time and set the motor currents:
I missed the max & min position settings on the first pass (they’re new!), which matter because I put the origin in the middle of the platform, rather than the front-left corner. Marlin now clips coordinates outside that region, so the first thinwall calibration box only had lines in Quadrant 1…
Running some PETG filament through the M2’s new V4 extruder drive produced nice indentations from the drive gear:
PETG filament indentations – front view
The square-looking indentation at the far left came from having the filament sit unmoving for an hour or so. There’s a smaller indentation to the left of that from a partially engaged gear tooth.
The side view:
PETG filament indentations – side view
That’s with the adjusting screw cranked 1/2 turn inward from what felt like first contact.
It’s an M4 screw with 0.7 mm pitch, so each turn moves the extruder pressure arm 0.35 mm. However, the bearing actually pressing the filament against the drive gear is 1/3 of the distance from the fulcrum to the screw:
M2 V4 Filament Drive – front view
Sooooo the bearing should move more-or-less 1/3 as far as the screw, modulo the arm bending, the fulcrum not actually being a pivot, and suchlike: 0.35 mm at the screw should push the gear 0.1 mm into the filament.
Squinting at the filament through a measuring magnifier says the indentations are 0.30 mm deep, which means the screw moved 1.0 mm after the actual “first contact” with the filament. That’s not surprising: PETG filament seems soft and easily indented, the force required to dent the filament doesn’t amount to much, plus there’s plenty of mechanical advantage from my fingers through the screwdriver to the filament.
Turning the screw another half turn certainly won’t mash the drive gear teeth another 0.1 mm into the filament, though, because the force increases dramatically as the dent goes deeper into the filament.
My M2 dates back to early 2013 and arrived with a 12 V platform power brick and a 19 V brick for everything else. I replaced the platform with a hotrod version, used a DC-DC SSR to control the high-current path, drove it from a 48 V brick dialed back to 40 V, and left the 19 V brick alone.
Recent M2s use a single 24 V brick for everything, including the motors and V4 hot end, so I decided to ditch the 19 V supply when I installed the new hot end. The stock 12 V fans depended on PWM to reduce the 19 V supply to something tolerable, but, with 24 V ball bearing fans being cheap & readily available, I replaced all three.
I bashed a pair of angled brackets from a random heatsink fin to hold the extruder & platform fans together:
M2 V4 Extruder – 24 V fans
All of that hangs from the single screw in the lower left corner of the upper fan, which has worked well enough and never given any trouble, despite my misgivings.
They’re much quieter than the original fans, perhaps as a result of operating at their rated voltage without PWM trickery. In theory, the fan mounted horizontally in the electronics box should survive longer with ball bearings, but the original sintered-bearing fan didn’t complain too much.
The Smell of Molten Projects in the Morning 