La pieces des resistances

Continued a bit with the red filament, but it didn't go long before there was underextrusion. After +Tim Hatch pointed out a possible electronics problem, I carefully checked the filament after pulling it, and indeed there wasn't really any sign of stripping, nor did the bolt have filament pieces on it. Time to see if I have a loose connection.

Occurs to me I've occasionally had the Z axis move surprisingly slowly, only to go at full speed again shortly after. That could be a microstepping error on the Z axis.

There's not that much information on the microstepping setup on the Melzi, but judging from +nop head's comment on this video, the Z axis microstepping is controlled by R20, and the E equivalent is R24 (Melzi board diagram).

Looking at the resistors up close doesn't reveal any obvious flaws, but if Tim is right, this is just slightly flaky, and that's unlikely to show up.

Interestingly, neither X nor Y has shown any problems like this. I guess I will have to try soldering these two as carefully as possible.

If I can't get them soldered, my alternative is to get them at least into a stable state - by cutting them. That, I think, will turn my 1/16th microsteps into 1/8th, losing some precision in the process. (Or would I need to replace with a different resistor?) I would need to adjust the steps per mm, which is reasonably easy, but would it make the motors run hotter? Require more amps? Make them be able to go faster? I don't know.

Reasons to strip, #4: Misalignment

As mentioned, printing to close to the bed stripped the filament again last night. While I was (and somewhat still am) suspicious that the white filament strips more easily than the red or purple, I just noticed a curious thing when about to clean the hobbed bolt:

Notice how the white parts, the filament stripped into pieces making the teeth slip, is not evenly distributed across the the teeth? That's probably because I have taken off one of the washers from the gear mount, and now the teeth are not aligned with the filament any more - which means less pulling power and more stripping. That can explain quite a bit - and it's amazing I got the fan duct as far as I did.

See the bolt at the top? Not aligned at all. A wonder anything worked.

So the filament might not be to blame. To paraphrase Dr. House: "It's not the filament! It's never the filament!"

So the right procedure for mounting the hobbed bolt and idler is:

Put in bolt with gear.
Check that the teeth align with the holes for the filament (they didn't) and add/remove washers as required.
Mount bearing and fixating nut on the other side.
Put in filament (loosely mounting the idler can help)
Mount idler.
Tighten idler screws to where the windings are almost touching.

Also: A stovetop cleaner held loosely but moved quickly is great for popping off stuck prints.

Today's calibration is 0.5mm Z offset with 21C, 1022 hPa, 85% humidity.

My greatest fan!

With a beautiful test cube under my belt, it was time for total hubris: Printing the duct fan. Also, one possible explanation for the stripping is that the fan blows on the hotend, cooling it down and causing back pressure. This is my first 4-hour print and it worked, until towards the top it started to underextrude, and then eventually, right at the very top, it stripped. Le sigh.

It's my greatest fan... duct.

Total strippage

The nut traps were just about perfect - I had to hammer in a couple of the nuts, but then they would fall out.

Around the nozzle, the print was into thin air, and it shows.

More amazingly, this bridge was built across nothing, and it worked. Printers are magic.

This is the crazy backup solution in case the printed one doesn't work: Cut two old ones to match up.

Somewhat bummed by the renewed stripping, I decided to try attaching this duct anyway. It was fiddly work, with very small tolerances. I had to add a washer on the inner screws due to the stripping having cut a bit off the height. Otherwise, the X belt would hit the top of the duct. But it actually fit.

Now is the time for... another cube, of course. Yes, it looks nice. The printer has not suddenly become fatally broken. More interestingly, another boat.

Benchy McBenchface, fan duct edition.

The boat came out much better this time, only one weird strip on the hull, only slight cracks on the foredeck.

Still these cracks in top surfaces, like the boxes

You can almost tell what it says

In other news, I am using half-round sticks for hanging posters, with magnets holding them together. For that purpose, I need precision-drilled holes, no more than 3mm deep, right in the center. The obvious thing to do is to design and print a guide. Took me about 2 hours to design a highly parameterized one. I'm getting used to OpenSCAD.

Since I need my laptop for other purposes, I went all the way with the Pi and just started OctoPrint, then uploaded some pieces and started printing, first the guide. Problem with this is that when you start a print from another room, you might forget details like Z calibration and hairspray. All the more reason to get the calibration automated. And of course I need to mount a webcam that can look under the duct. I have the cam, just need to design a thing it can sit on.

New and exciting problems! Well... not so exciting it turned out in the end.

Printing journal (I hope)

Printing glass marker. Temp 22C, 999hPa, 48%, Z offset 0.5.

Whether due to me interfering with the early stages of a print, or something fatally breaking, I don't know, but the printer now doesn't take commands. I had done calibration, and before starting a print, I turned off the extruder and on the bed. The print started as normal, except when it had heated the bed and gone into heating position for the extruder, it didn't set the extruder temperature.

Several variations of turning things on and off later, the extruder temperature still didn't get set, and occasionally even homing didn't seem to take. The temperature is measured fine, though.

Now keeping careful log:

Closed Pronterface and kept the printer off for 5 seconds. Connected, which took seconds, then it didn't register homing.

After I had written the above, it homed. I started a print, it went straight into heating position, then didn't set temperature.

RepRapPro has a lengthy article about what can go wrong related to temperature. However, I can set temperatures manually, so it's not fully dead.

When I turn on debug communications, I get wrong-looking output:

>>> M105
SENDING:M105
T:22.5 E:0 W:?

There should be more in there - also the temperature listing on the left is missing the target, it shows the same as above. The graphs show about 20C for the extruder, though

Manually set extruder to 120 and bed to 60. No apparent increase in temperature.

Tried lifting the Z axis to better feel the extruder, but it didn't budge. Homing didn't work either. Turned off everything and went to have brunch.

Later I used my laptop for a print, and it went totally smooth (the print process, not the print itself):

It's a piece that fits on a standard IKEA glass so we can tell which is whose

Coming back even later. Z offset 0.5, and I was able to set the temperature for that (since I don't want old filament on the hotend to influence the offset). Temperature 21C, humidity 994hPa, moisture 36% (outside). When printing, no temperature gets set. Weird. Maybe Pronterface is just being stupid and it's time to try...

Octoprint!

I already installed it a while back. Starting it gave a webserver at port 5000, with a security check (http only, though, so not that useful). The settings are pretty nice, but there's no obvious way to set a Z offset, which I need until I get autocalibration in. Homing is split between X/Y and Y. I copied over the start/end commands, and added commands on connection to prepare for calibration.

There's a Slic3r plugin on GitHub, but right now I'll just reuse the GCode.

Like Pronterface, this doesn't like to say where the printer currently thinks it is. Again, no heating happens. The following commands were sent:

Send: N0 M110 N0*125
Recv: ok
Send: N1 G28*18
Recv: ok
Send: N2 G1 Z5 F5000*6
Recv: ok
Send: N3 M107*38
Recv: ok
Send: N4 M190 P60*89
Recv: ok
Send: N5 M104 P220*99
Recv: ok
Send: N6 G28*21
Recv: ok
Send: N7 G1 Z5 F5000*3
Recv: ok
Send: N8 M109 P220*99

The N* is just line numbers. The M190 P60 is setting bed temperature, and the *38 is a checksum. So that looks fine. (Yes, it homes twice, due to extra start GCode I pasted in). Sending it manually does nothing, nor does the temperature controls work. There's still temperature data coming back, though.

Tried powercycling the printer in case it had got into a stuck state (waiting for a temperature that never goes anywhere?). Now it won't connect. Restarting Octoprint doesn't help. 

Restarted Pi and printer both. On start, it nicely connects, gets ready to calibrate, and shows the actual temperature and targets after M105 commands. I can use the controls to set the target, and that works (OctoPrint doesn't poll that often, so the curves are more jagged, but it doesn't do the confusing autoscale).

Sending the commands above in sequence worked fine, until N4, where it just ignored it. Still sending back full temperature reports, though. The N8 M109 P220*99 command is the killer. The argument apparently should be S220, not P220, according to RepRapWiki. That's Slic3r's fault - which makes sense, then, since the laptop uses a different version of Slic3r.

And there, in one of the printer settings, lies the answer: It was set to a different GCode flavor. Why this happened now, I have no idea, but after switching it to Marlin, it works perfectly. Another cube came out just right:

Still slight gappiness in the top, but otherwise nice.

Moving to extruder #2

Just printing some prints:

GlassMarker - a small piece designed to sit on the rim of a water glass, so we can tell which glass is whose. I'm trying for a fit that makes it not move along the rim.

And now the white filament stripped. Curiously it can still extrude in reverse, but stops when it extrudes forward to a certain spot. But as promised earlier, this means it's time to switch to the mount I paid for.

Getting the support out was relatively easy, certainly more so than with my own print. A bit of digging around the edges, then push, and it went pop. The flat nut trap was a perfect fit. However, the deep nut traps were a different issue - they were just slightly too small on the sides, on the order of 1/10th of a millimeter. This is well within the promised spec, but a problem here. Dremeling it out didn't work well, so I went and got a set of tiny files from Conrad. It took a bit of work, but not onerously much, and now the nut traps are perfect. Apart from one I filed a bit too much, I'm never going to get those nuts out again.

Assemble, assemble, I know how this goes, so of course I forget to put in the nut under the motor. Disassemble, disassemble, nut, assemble, assemble. Hm, that cable looks messy - oops, I turned the entire thing 360 degrees and now the cable is twisted. Fortunately it was easier to fix this, and I took the opportunity to at least affix the cables:

With everything in, a first test just extruding into thin air looks pretty good. Time for a test piece. Today's Z offset: 0.4mm. Today's weather: Pressure 1018, humidity 63% (outside), temperature 21 (inside). Result:

Slightly overextruded still, I will need to go back and twiddle the Z_STEPS_PER_MM. That was at 0.5 extruder multiplier, trying again at 0.4 just because. Came out with really nice sides, but the top still a bit overdone. And the corners are flattened, maybe my acceleration is too high:

Doing one at 0.3 just to see how far down I can go. Cutting 25% off the material ought to be plainly visible... but no! Curiously, lowering the extrusion multiplier even more doesn't change the amount of filament used. And by now, neither does increasing it - even though further up in the log I see other values: The first (at 0.5) used 190mm, the rest used 158mm.

Interlude: Test extrusion art

Later: Mystery solved. I was setting the Z offset when I thought I was changing the extrusion multiplier, because they both ended up at 0.4. Good thing I didn't print with that.

Acceleration is actually set rather low already, compared to the Marlin defaults. I should use the M201 command to vary them.

Updated the firmware to not have a fudge factor on E_STEPS_PER_MM, and set extrusion multiplier back to 1.0. New Z offset in the evening is 1.3 (!), at 20C, 1007 pressure, 51% humidity.

And I couldn't really wish for a better print. Time to try a boat - 3DBenchy (McBenchface?) seems to be all the rage for a tougher test. Slicing it took almost 8 minutes, I suspect the slicing speed is the weak point of the Pi, and should be offloaded onto something else.

First boat print came off partway through the print:

Another try at boat didn't stick at all. Double-checking the amount of filament extruded gives... odd results. At first it's pretty close, then after more tests it becomes less and less precise, and eventually I end up with a correction factor of almost a factor 2. After that, it measures consistently correct. For now.

Another boat. The problem, now that I observe the print, is that the overhanging corners tend to curl up, and then they eventually cool down, harden, and get bumped into by the next layer. Pop! goes the print... but not this time! Bogons work.

Most discussions of curling is about curling at the bed, not at overhangs. Some suggestions are more fan (mainly), better cooling, and maybe less infill/printing faster (!). Possibly the fan blowing all over causes the print head temperature measurement to be off, which can make things really unpredictable. Maybe I should get back to the fancy fan ducts.

Some boat details:

I'm pretty sure there shouldn't be holes like that.

The first layer was more or less printing into thin air. I'm amazed it stuck.