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.

Breadboard Vise

On 14 August 2015, Hackaday mentioned the 3D printed breadboard vise described in this blog post by Pat Regan.  If you haven't already, please read Pat's post.  Everything that follows assumes you've memorized that post, including the embedded video.

For me, this was a revelation.  I had previously been using plywood, double-sided tape, duct tape and modeling clay to hold my breadboard in place and keep everything else in close proximity.  A real mess that often resulted in jumpers getting dislodged or completely lost.

So I wrote Pat and asked him to sell me a Breadboard Vise, and to my surprise he said "OK"!  He offered me the one pictured in his blog post and video, but also said that if I didn't mind waiting a bit, there were a few tweaks he'd like to make.  Of course I chose to wait!

Well, my vise arrived today (31 August 2015), and I immediately filled it with the main components of a two-part project I've been working on:

That's an ESP-12 on top, and a RasPi2 with PiCam below, with a Pi breadboard breakout in the center.  That PiCam had been flipping around and getting in the way.  Not any more!  Needless to say, the vise works exactly like it does in Pat's video.

A close look at the image will show that the RasPi2's power, HDMI and audio connectors are blocked by the vice jaw.  I tried rotating the Pi 90 degrees (I don't need the Ethernet or lower USB connectors), but the vise jaws won't extend quite that far.  If your board's narrowest dimension is greater than about 2.5", then it won't fit.

There are two workarounds; a hard one and an easy one.  The hard one is to design a jaw that has cutouts for the RasPi connectors, while still being strong enough to hold the board securely.  The second (and easier) workaround is to mount the RasPi to an adapter plate (nylon standoffs and a hunk of perf board), and put that in the vise.  Or maybe 3D print a RasPi carrier that could also serve as the base of a RasPi enclosure.

Opening Pat's files in OpenSCAD shows relatively few lines of code are needed to describe each part (the vise jaw and the vise base).  Though this was my first time using OpenSCAD, I did notice some key design items:

1. A fudge-factor in the code shows it took some experimentation to find the optimal clearance for the arms of the vise jaw to slide easily into the base while not being loose.
2. The bottoms of the vise jaws do not reach down to the bottom of the base.  This ensures the jaws can be easily opened even if the base is fastened down.
3. The bottom of the base is solid.  While this increases filament use and print time, it ensures the breadboard is securely held, and that the vise arms won't snag from below.

 As Pat mentioned in his post, he went to great lengths to have a single jaw design that would work in all four locations in the base while still being strong and completely functional.  After the idea itself, this is my favorite aspect of the design.

I'm still not sure why the vise arms don't snag or jam when moving in and out of the base, even when slightly cocked.  The clearances are part of it, but it must also have something to do with how the part was printed, or perhaps how FDM printing itself works.  Anyhow, I like it!  This vise is effortless to use.

And in case you were wondering if you should trust your breadboard and other boards to a 3D printed vise held together with rubber bands, here's the money shot, taken with the board held upside-down at waist level:

You'll notice I'm not using the breadboard retention rubber band Pat uses in his video:  The version of the base he sent me (which may not be the one on Thingiverse or Github) retains the breadboard just fine without it, though the slot will probably remain for another iteration or so.. The screw holes are also visible, where were also added since the original design.

I was going to mention some minor printer issues that are visible in the vise Pat sent, but there's no need to, since they don't affect vise operation in the least.  That's another credit to Pat's design, which to me means it should be printable by just about anyone on just about any printer, perhaps using just about any rigid filament.

Want one of your own?  If you lack a 3D printer, Pat will be selling various versions of his vise on Tindie. I'll update this post when his store goes live.

Me, I think Pat should consider going straight to Kickstarter and get injection molds made.  I absolutely believe all Makers will soon think it is silly to have a prototyping breadboard without a board vise.

The definition of a hobby like 3D printing is much like the definition of a boat: A hole into which you throw money.  Once in a while you see someone make something that suggests maybe his hobby should return some of that money.  I really hope this project enables some great things for Pat!

That's really all I have to say about Pat Regan's Breadboard Vise.  It is a sensational solution to a persistent problem.

But there's more I'd like to say about Pat.  We averaged an email a day during the two weeks between the Hackaday post and when my vise arrived.  He has been a very generous correspondent, taking me through his process, his equipment, and his own experiences with 3D printing and the 3D printing community.

Prior to seeing this vise, I had no intention of getting a 3D printer.  Not any more!  I think just I needed to see a project I absolutely needed, one that made ideal use of a 3D printer.  Having seen Pat's design, and starting to play with OpenSCAD and slic3r, my prior excuse of lacking mechanical engineering skills no longer applies: Pat has shown me it's mainly geometry and math, and the willingness to make some bad parts along the way.