A Better Temperature Tower

I finally printed a custom temperature tower that shows the useful "indicated" temperature range for my Ziro Gold PLA filament. The following images show the high temperature to the right, as indicated by the grainy surface, to the low temperature on the left, as indicated by the under-extrusion.

The "Sweet Spot" for this filament is an indicated temperature of 180C.  I did some test prints at 175C and 170C, and the layer adhesion was detectably weaker at 170C.  And the stringiness at 180C was much reduced compared to that seen at 185C.

I want to stay far away from possible layer adhesion issues, so I picked 180C as my new default temperature for this filament.

And here's my Benchy printed at 180C with 0.4 mm nozzle and 0.18 layer height, next to the $5 WalMart 5" desk fan I had blowing on it during the print:

The Benchy had some cotton-candy strings on it, most of which I removed prior to taking the picture.  The biggest differences compared to my prior Benchy are that 1) the stringiness is massively reduced, 2) much more detail is present around all holes and openings, and 3) the smoke stack is just about perfect, which is due to the fan.

While this is a massive improvement, all is not yet perfect.  Tall, thin items, such as the Eiffel Tower, still have a bit more stringiness and a bit less detail than I'd prefer, but I'm attributing that to not having a fan right at the nozzle.  An off-printer fan certainly helps, but it doesn't fix everything.

I really need to dig into the 101Hero Marlin firmware to fix a few things, most importantly the temperature sensor calibration, and also some minor delta geometry tweaks.

Unfortunately, the 101Hero folks have so far failed to identify the Marlin version they are using, along with the configuration files.  That's not only a violation of the GPL, but also a PITA for 101Hero users who simply want to make the printer perform better.

Moron, the Little 3D Printer

Wait.  Did I mean to say "More on the Little 3D Printer"?

No.  No I did not.

My 101Hero has no idea what it's extruder temperature actually is.

The highest possible indicated extruder temperature is 208C. That's as hot as it goes when I set a temperature of 208 or higher.

The internal (firmware) low temperature cutoff is set for about 178C, meaning you get a "Low temperature extrusion prevented" message when trying to print at that temperature or lower.

The Ziro gold PLA filament I'm using has a recommended temperature range of 190C-220C, a range of 30C.  The test prints for the 101Hero all seem to use a temperature of 203C, and with the Ziro filament, the test prints I tried all printed with a dull, sandy finish.

From what Google tells me, dull PLA means over-temperature, essentially cooking it into a runny, stringy mess.

By experimentation, I found that a setting of 185C yields much better-looking prints.

I wanted to understand the accuracy of the temperature indication on my 101Hero 3D printer.  So I chose the Customizable Temperature Calibration Tower from Thingiverse, configured it to cover the range from 208C down to 164C by steps of 4C in a height of 96 mm, which is 12 steps of 8 mm each.

I downloaded the customized model and installed the "Vary Temperature With Height" Cura plugin that came with it.  I then opened the STL file in Cura, selected the plugin and set its values to match the model configuration.

I set the layer thickness to 0.18", with no infill and no top, with only a one-layer base, with a wall thickness of 0.80 (2 layers), and with a starting temperature of 208C.

Then I saved the GCode and started the print.  Which abruptly ended when it tried to print the step at 176C.  Because that value is less than 178C. So instead of printing, it generated countless "low temperature" error messages.

I aborted the print, selected Start/End-GCode -> end.gcode, then inserted an "M302" command to be the next-to-last command in the file.  This command disables the "low extrusion temperature" logic.

I then saved the GCode again and restarted the print, with the following results:

The temperature scale, with hot on the left (bottom) and cold on the right (top).

The legend side, which says: "101Hero / Ziro Gold PLA"

The step test side.

The smooth side.

First, it is important to note that all layers in this test were well bonded together: I tried twisting the tower, and none of the layers separated.  This could be due to having a 2-layer wall - perhaps a single-layer wall would have been a better test, but I wanted to allow lots of time for the temperature to settle early in each step.

Update: I did a single-wall print, and it was very similar to the double-wall, but easier to test the wall quality. Again it was remarkably consistent, with the 184C region maybe being slightly superior.

It is clear that the left end is rough and grainy, a sign of overheated PLA filament. The graininess is not present at (indicated) temperatures of 192C and below.  Ideally, the coolest layer of a temperature tower should show some blobiness due to partial filament melting.  This tells me that I need to repeat the test down to even lower (indicated) temperatures.

The step test side looks best at 184C, though it really doesn't look bad in any of the other steps.  This is the only clue I have that my guessed temperature of 185C is anywhere close to ideal.

If we say an indicated temperature of 185C is near the middle of the range given on the spool label, then the actual extruder temperature is closer to 205C, an error of 20C!

Bottom line, the indicated temperature reading of my 101Hero is insane.

Which doesn't really matter: It's just a number!  So long as I know the right number to use for my prints, it's not a problem.

The lesson here is to always print a temperature tower for each new filament.

Next test: A Speed Calibration Tower.  I've been printing everything at a rate of 10 mm/s because that's what most users have recommended.  But how fast can the 101Hero go, and how bad does it get with increasing speed?

Tiny, Cheap 3D Printer Working!

My ultra-inexpensive 101Hero 3D printer arrived about a month ago with a bad motor.  Fortunately, another owner had started a group-buy for better replacement motors, which I joined, and which had arrived just before the printer.  I replaced the bad motor, though I had to swap the pink and orange wires in the connector to get it to rotate in the right direction.  I probably should replace them all, but I want to see how long the other two original motors will last.

I covered the build plate with the horrible yellow masking tape that came with the printer, because the blue tape I had was dried out and I didn't want to wait to get more.

I set up Cura using the 101Hero config file provided by the manufacturer.

Next, I followed the abundant setup advice on the 101Hero User Forum (the site is independent of the 101Hero manufacturer).

I added rubber bands to the arms to reduce the looseness/shakiness of the print carriage.  The arms are so flexible that putting the rubber bands in the middle caused bending (which would throw off the geometry), so I put them up near the top of each arm pair.  The rubber band tension was as low as I could get it and still have them stay in place.

I did a few 1-3 layer prints to calibrate the printer (and use up some of the questionable white filament that came with it).

Despite the print bed being level and at the right height, I still had adhesion issues, so I made the first layer 50% thicker (rather than do a brim or raft).

I then switched to this inexpensive PLA filament from Amazon because I could get it delivered the same day for free (via Amazon Prime).  It came well packaged, including a zip-lock storage bag.

Then I tried my first "real" print, a tiny phone stand.  The print is completely functional, but is far from perfect.

I saved the GCode, primed the extruder until the new color came out, then started the print.  I waited four long hours, hovering over the machine like a husband during a delivery.

The resulting print was strong (good layer adhesion), but does have issues.  Here's what it looks like:

  

   


Here's what I observed, and what I think it means.

• Not in photo: The skirt (the outline printed around the part to prime the extruder) was almost completely missing, and the little bit that was there was thread-thin.  This happened despite priming the extruder moments before starting the print.  Extrusion rate too low?  Blocked extruder nozzle?
• Print is fuzzy. I removed most of the fuzz prior to taking the photos, but some is still visible in the interior.  Too little retraction?  Temperature too high?
• Bottom has a combination of adhesion failure and Elephant's Foot.  Easy: I screwed up the calibration.  And I really should get some blue tape.  Any other factors?
• Fill isn't tightly joined to outer wall.  Under-extrusion?  Need to increase fill overlap?
• One layer about 1/4" from the start is totally squished.  Easy: I bumped the printer, hard.
• About halfway up the whole print steps over a bit.  I didn't have a spool stand and the filament was getting pulled tighter and tighter.  This is when I moved the spool onto a stick.  Any other possible factors?
• There are small "waves" crossing multiple layers in the later half of the print.  My guess is I still have filament tension problems that will be fixed by getting a real spool holder.  Are there other causes?

Those are all the defects I see (as a 3D printing newbie).  Are there more?  Are the photos good enough to tell?

I then put Blue Tape on the print bed and rigged an emergency spool holder using a paint roller (which works awesomely):

Print quality immediately improved to an amazing degree.  I then printed the other stand included in the above link (visible above), and then printed a Star Trek TNG communicator badge (which was printing when I took the above photo).  Here's a close-up of it:

The upper surface is a bit rough, but that's no surprise given the 0.18 mm layer thickness.  I may try it again at 0.10.

My next plan is to do some prints for dimensional (geometry) calibration and for temperature calibration (should be done for each filament spool).

So, I wrote a thing...

Updated on 7/17/17 to add detail and improved links, on 7/20 to add other formats, and on 5/31/19 to remove dead links.

In April of 2017 the open-source social network software called Mastodon was covered by a blogger, and I wandered over to take a look.  Mastodon, based on GNU Social supports a network of "instances" that are "federated" in order to share content.  Using a script I wrote, I initially looked for an instance that was closest to me in terms of network delay, and wound up at a now-retired instance and created my first account.  I then started looking around at other instances.  Some instances have specific themes, such as politics, system administration, teaching, sports, and so on.

I soon stumbled upon a Star Trek themed instance called Ten Forward, and created an account there called @Redshirt27, trying to be as generic as possible (by not taking the name of a scripted Star Trek character) yet still represent a known part of the Star Trek universe (the hapless Security folks who tend not to live too long).

I started posting as if I were a very junior Starfleet Security officer reporting aboard the USS Enterprise.  Then, unexpectedly, I fell into a story and the posts started flowing.  I have written no fiction since high school 45 years ago.  I was very surprised as this started happening, but kept typing what popped into my head, letting the story go wherever it went.

Here's what spilled out, all 100 KB of it, over 17,000 words.  Longer than a short story, not quite a novella, what some would call a novelette.

The individual posts are unedited (even typos are left as-is), though I did remove a few early posts that didn't fit the narrative that emerged.

Here's why I'm sharing this: I really, really like it, both the process and the result.  "Proud" would be the wrong word; "Delighted" is a better fit.  I like that I was more of a reader than a writer as this story came out, always surprised by what my character did next.  The only external reference I used was the Memory Alpha site, mainly to get the terminology right and avoid gross mistakes within the Star Trek universe.  (The mistakes that remain are all mine!)

The thing is, I feel I created something here that may add something to Star Trek fandom.  First, I like that this all happens within the head of the single isolated character, in the form of a personal log.  Second, I got to think about some implications of Star Trek technology we take for granted, hopefully in a way that adds depth, not weaknesses.

Finally, I was hoping a sequel would come spilling out on the heels of this first story, but so far I have nothing to move on with.  This may be its own thing, a one-off, and I'm OK with that.

Should I revisit this, clean it up, and flesh it out a bit?  For example, the dates are the actual dates of the posts: Should I convert them to stardates?  Please let me know in the comments, especially about any faults you find, being as kind and gentle as possible so I can more easily listen to and better understand the criticism.

Enjoy!

Update: Whoops!  A second book spilled out!

Update: If you'd like to read the books in other formats, let me know and I'll make it happen.

Bash-ing code

I've been writing a ton of bash scripts lately, and the absence of many high-level language features combined with the lack of a safety net makes it surprisingly difficult for me to quickly write solid code.

But all is not lost! Several great tools have come to my rescue.

The first is ShellCheck, a Haskell program that is straightforward to install on any platform. It not only finds silly mistakes that are difficult to troubleshoot, but it also encourages several best practices.

The second is the Unofficial Bash Strict Mode. Flip a few shell options, modify IFS, and suddenly scripts become much noisier, revealing lots of what's going on behind the scenes in bash.

Next are various hints, tips and tricks for bash debugging. Be sure to dig into the comments and other replies. Lots of gems there. I haven't yet used bashdb, but I'm glad it's there waiting for me.

I do all my other development in Eclipse, so I'm using the ShellEd extension, a older tool that isn't aging well at all, but still does its basic job.

Bash has one terrible "feature" that caught me last week. What do you think the following script will do when passed various input?

#!/usr/bin/env bash
# file: array_test.sh
arr=("$@")
for s in "${arr[@]}"; do
    echo "$s"
done

Try the above code under the following three scenarios:

1: ./array_test.sh one two three
2: ./array_test.sh one two
3: ./array_test.sh one

There's a surprise waiting!  Go ahead, try it. I'll wait. Really, I'll be here when you get back. Promise.

Bash arrays are wonderful, but an array with a single entry behaves the same as a regular variable.  The way to get around this is to always use the array index.  So here's an update of the above code.  Does it perform any different?

#!/usr/bin/env bash
# file: array_test.sh
arr=("$@")
for i in "${!arr[@]}"; do
    echo "${arr[$i]}"
done

Cracked!

Last week I discovered some open outgoing SSH sockets on my "hardened" Red Hat gateway machine.  A little more digging revealed a web server connected to those sockets, but I haven't yet been able to find the files being served.

I'll admit I had become complacent about updating the system, since it had been working with perfect performance.  Being lulled into a false sense of security is no excuse!

I haven't yet had the time to rebuild a hardened server from scratch (it is a ton of work), but the first two quick fixes I did was to disable httpd and to restrict ssh to only my internal NIC by adding a ListenAddress entry to /etc/ssh/ssh_config.

However, I'm not much of a sysop or IT specialist, and I lack any real system hardening knowledge.  Most of what I did was to dumbly follow various "best security practices" advice from distro makers, government agencies, and security companies.

Clearly the crackers are way better at their game than I am at mine.

So I decided to look at what's available in security-focused routers and immediately stumbled upon the Tuirris Omnia Indegogo campaign.  For US$209 (shipping included) I'll get a powerful OpenWRT-based gigabit router and a/b/g/n/ac MIMO access point that includes a monitored honeypot and automatic security updates from a highly-rated Czech provider.

Since the router won't ship until next spring I'll still have to (re)harden my Red Hat box, but after that I'll let the professionals provide my first line of defense.

The Sound of Silence

My Windows 7 home theater PC (HTCP) video and sound outputs both connect to my Sony receiver over HDMI, with the video routed by the receiver to the TV. Both the sound and video quality are excellent.

But there's a problem when switching between programs sourcing sound on the PC: The receiver makes a very loud pop/boom when the first sound is played after startup. After startup, the first couple seconds of program sound (such as a YouTube video) would be missed, though the sound would then continue without the pop/boom.

It took me a while to troubleshoot this phenomenon. It turns out that Windows completely stops outputting digital sound when there is no active sound source. That is to say, it does not output "silence" (a continuous sound stream containing data with a digital value of zero), but instead halts the entire Windows sound subsystem. So, when a program running on the HTPC starts to output sound, the Windows sound system has to be reinitialized, which can take a couple seconds.

At first, I suspected this was a Windows sound configuration issue. I did several searches and found no solution that involved changing system settings. I next looked for utilities or other apps that addressed the issue and found nothing.  Clearly, relatively few people run their sound through a receiver.

Under Linux, the fix would be simplicity itself: Run the sox program and tell it to output zeros.  Since I had Cygwin installed, it took only a moment to find that sox was indeed available under Cygwin, so I installed it, opened a terminal window, and entered the following command:

sox -n -d -q &

Ta-daa!  Problem fixed.  But I'd prefer the solution to be automatic, not manual.

The next step is to get sox to start when the HTPC boots, preferably so it will automatically restart sox if it ever exits.  Under Linux, this kind of thing is handled using cron or one of its successors.  I could install Cygwin cron, but is there a direct way to do this under Windows?

Sure!  Use the Windows 7 Task Scheduler.  You can follow this recipe combined with this one, or one of the many other similar recipes available.  Just be sure to run the task with Administrator privileges, which sox requires to access the sound hardware.