Archive for October, 2013

Notes to myself: Lulzbot TAZ n00b guide

A work in progress…

Critical Specs:
Bed size / Build envelope: 298mm (X) * 275mm (Y) * 250mm (Z)
Nozzle diameter: 0.35mm (shipping default; others available)
Filament diameter: The TAZ’s extruder expects 3mm filament. However, not all off-the-shelf filament will be exactly this diameter; the discrepancy could affect print quality in severe cases (see notes later).

The Parts:

-RAMBo – all-in-one Arduino-compatible controller + stepper/heater/etc. driver board (all-in-one variant of RAMPS)
–Marlin – firmware used by RAMPS/RAMBo boards
-Extruder (motor/gearing for filament control, plus hot end)
–Hot End (nozzle, barrel and heater): Budaschnozzle

PC Software:
For open-source 3D printers, this comes typically in 2 parts: a printer interface program and a slicing program. The slicer converts STL to G-code, and the interface is what actually drives the printer (usually includes homing, viewing/adjusting temperatures, and sending the generated G-code to the printer).

Printer controller / interface: TAZ ships with Pronterface, but others are available.

Slicer: TAZ ships with the aptly-named Slic3r, but again, others are available.

Common Problems

Printer “shriek” followed by severe height problems when printing (head crashing into bed or printing in midair) – This is the ONE issue that gave me the most grief. The issue in brief is that the TAZ’s Z-axis (2-motor gantry on high-friction leadscrews) must be driven quite slowly compared to the other two axes, or else the motors will stall. However, most slicers (including the Slic3r configuration that comes with the printer) insist on moving every axis at the maximum possible speed for all non-printing moves (and often even printing moves). In general, this is accomplished by generating G-code specifying arbitrarily high feedrates (F999999 or whatever) and expecting the firmware to limit these moves to a sane speed. For some reason, these limiting values are either missing or incorrectly set on the printer firmware end, so the Z axis motors stall when performing the initial home-raise-position-lower move at the beginning of the print. This results in a number of highly irritating problems such as printing in midair (if it stalls more during the lowering portion), or the nozzle dragging across the bed and shredding the crap out of any films/coatings thereupon (stalled more/entirely during the raise portion), or putting the entire gantry out of whack (if the motors on either side stalled by different amounts – have fun with this one!).

Some more discussion of this issue at .

To fix it: At the time of this writing (10/2013), you have to rebuild and reflash the firmware after tweaking some settings. In brief: Download the appropriate firmware sourcecode for your printer here, along with the Arduino IDE from the same page (they specifically endorse and host v. 1.01, but any recent version should in theory work). Oh yeah, and for you Windoze users, some kind of tool for opening .bzip2 archives. I recommend 7-Zip. (Great utility, but be wary of fake/spam download links from their file host when downloading…) Unzip the firmware files, go into the configuration.h file and uncomment the //#define EEPROM_SETTINGS and //#define EEPROM_CHITCHAT lines. This will let you set maximum speeds using an M code (to be explained later). While you’re in there, may as well sane up the default values too. Scroll up and lower the Z value for DEFAULT_MAX_FEEDRATE (the values are X, Y, Z and Extruder, respectively). The default is 10, which for my printer is too fast. On mine, a value of 5 was slow enough but excited some nasty resonance that caused the whole printer to buzz angrily. In the end I ended up with 4.2, which provided much smoother operation. (YMMV of course.)

Open the Arduino IDE, and from there open “marlin.ino” in the firmware files. Set the board as “Arduino Mega 2560” (Tools -> Board) and the serial port used by your printer (Tools -> Serial Port), press the Upload button and cross your fingers.

Assuming everything worked, you can now use M commands to set speed limits for each axis. Use:

M203 X### Y### Z### E###

to set speeds, and M503 to display the current values (if EEPROM_CHITCHAT is enabled). You can add this code to your slicer’s startup routine to ensure the speeds are not overridden by other users or software settings (most slicers have a place to add custom G-code before and after the slicer output.)

NOTE: Pay careful attention to expected units. The M command expects (by default?) values in mm/min., whereas if you set a default in the firmware as above, this value is expected in mm/sec. Particularly braindead slicers and/or host software might even set your machine into Imperial mode, blech.

Print does not stick to bed / breaks loose – Very common, and semi-related to the curling issue below. The big thing to check is the nozzle height when printing the first layer. It should be basically touching, smooshing the initial layer down nice and flat. The output should not look like a round bead of toothpaste being squeezed out of a tube. Check bed leveling, Z screw and repeatability, etc. Next things are to play around with the bed temperature and possibly extrusion temperature. Ensure the bed is fully up to temp before printing. For parts with low bed contact area or small protrusions that get caught and lifted, you can try various software-generated adulterations (raft or brim) to help with adhesion. These are typically autogenerated by the slicer program at your command. A raft is a solid-fill first layer covering typically a bounding box around the footprint of the print, followed by a sparse layer that allows for breaking the raft off afterward. A brim is a widening of all features on the first layer (as if your print were a bit melty and thrown at the bed with some force) to increase the surface area and move any “peel point” away from your actual part geometry. Brims are good to help stick down thin features that are prone to being lifted during the early print passes. After removal, the thin brim can be easily cut off with an X-Acto knife.

UPDATE: I tried the “lulzjuice” (acetone glue) trick, and it seems to work beautifully – completely solved my adhesion problems! Basically, for printing ABS, dissolve a bit of filament in some acetone, and wipe/brush a thin layer onto the buildplate before printing. Acetone has a low boiling point, so if you have a heated buildplate, do this *before* heating it up to avoid a bubbly mess. The flip side is that unsticking the print (intentionally) can be a little harder – if all else fails, try hitting it with coldspray (or an inverted can of computer duster).

Edges of print peel / curl away from bed while printing – Caused by a combination of poor adhesion to the bed and changing temperature. Check all of the stuff for the previous problem, then see what you can do about controlling the rate of cooling (overall or between layers). Try lowering the extruder temp slightly or raising the bed temp(?), dealing with any sources of cold breezes (enclosing the build area if necessary), or fiddling with software-based thermal controls (delays between layers, etc.).

Fat, floppy, and/or blobby print (edges extending beyond where they “should have been”) – Often a side-effect of the edges peeling upward and pushing the outer surfaces up toward the nozzle (the excess material has nowhere to go but outward…). If there is no peeling problem, most likely too much material is being extruded. See “Filament Diameter Problems” below…

Filament Diameter Problems – Use good, red-handled calipers to measure the filament diameter in several places – it may be a bit fatter or thinner than the nominal dimension, especially extra-cheap or noname-brand stuff. A fraction of a mm difference may not sound like much, but considering that’s being squeezed down from, say, 3mm to 0.35mm, it can become significant! Most slicers have a means for compensating for the filament diameter.

Popping sounds from extruder during print – Trapped humidity in filament (think popcorn) – try gentyl baking or storing in a drybag when not used for extended periods.

Trouble bridging – The extruded filament should be getting “pulled” slightly during print; not “pushed” (i.e. travel rate should slightly exceed the extrusion rate). See “Filament Diameter Problems” or related compensations offered by your slicer.

Hole diameters in printed parts – plastic may “squish out” a bit during extrusion, causing your hole diameters to be slightly narrower than expected. Assuming the amount of extrusion is actually correct (see several of the above), I’ve heard of folks compensating with an Excel table of expected vs. achieved hole size (it might calculate this) – don’t know where to get this though.

Tim Tears It Apart: Sensitech TempTale4(R) data logger

One of these devices appeared in a large shipment of temperature-sensitive raw materials at my work, amid a pile of dry ice chips. While I don’t know the MSRP or actual retail price of this gadget, the shipper packs one in with every order and tacks on $60-70 for it as a line-item; nonreturnable as far as I know.

So, we can’t return it and we can’t read it out, so what do we do?

I think you know what we do :p

TempTale4 Front Panel

TempTale4 Front Panel

The device is aimed at exactly this application – telling if your temperature-sensitive stuff stayed within a defined temperature band during all phases of shipping and handling. With timestamps, you could probably tell exactly which party in the shipment chain screwed the pooch. There is a fancy term for this kind of tracking – cold chain certification.

As far as interfaces go, it doesn’t get much more simple. A button to start logging, a button to stop logging, a simple LCD display, and a couple blanks to enter a shipper’s name and the PO# of the shipment. The current temperature and recording status (started / stopped) is displayed on the LCD. If the temperature went outside the allowed band while recording, an alarm symbol (bell) also appears. A pair of LEDs exposed through the front panel allow the device to be configured and recorded data to be read out to a PC via an optical doohicky (more on this later).

TempTale4 rear cover removed, showing the plastic 'cage' that holds the battery pack in place

TempTale4 rear cover removed, showing the plastic ‘cage’ that holds the battery pack in place

The enclosure is a basic 2-piece sandwich, with the half-thickness (.031″) PCB fixed into the front by 3 screws. A separate plastic ‘cage’ holds the battery pack in place; fingers on the backside clip around the edges of the PCB. The entire weight of the battery pack – and impact loads it imparts during rough shipping – are borne solely by the PCB and ultimately those 3 screw points. They might not anticipate extremely rough shipping for cold-chain cargoes (although a broken logger could be spun as a rough-shipping-detection “feature”).

On the plus side, note the O-ring ensuring a water-resistant seal between the case halves. Any other case openings are covered by the front overlay “sticker”, eliminating any fluid intrusion paths.

Battery cage removed

Battery cage removed

Battery pack removed. That piece of double-stick tape really ties the room together.

Battery pack removed. That piece of double-stick tape really ties the room together.

The battery pack is Zip-tied to the plastic “cage”, although not to the PCB or any part of the case. A piece of foamy double-stick tape helps hold and cushion the battery pack where it sits against the PCB. This and the overlay sticker on the front suggest this device is intended for enforcing low temperatures. High-temperature overlays and even double-stick tape exist, but it’s pretty fancy stuff. This tape isn’t fancy.

The battery pack consists of two series-connected Tadiran lithium primary cells (AA size), with a nominal 7.2V output. Now, in an industry that is constantly pushing toward ever lower voltages to reduce power consumption, this is weird! Especially for a gadget that needs to go a long time without a battery change. A single 3.6V cell will easily power a 1.8-3.3V device, and maintain this output voltage until nearly depleted. Some wild guesses at the reason behind the unusually high voltage:

1) High-current operation at very low temperatures. This shouldn’t be an issue during normal operation (just datalogging should use very little current on average), but if someone wanted to read it out over the optical interface in the Arctic, it may be another story. This may provide extra headroom against the inevitable cold-battery voltage sags that would occur as the transmit LED fires.

2) Voltage-happy LCD? Some LCDs require a higher voltage such as this to operate (usually generated by an onboard charge pump circuit), but these are typically graphical matrix LCDs (many independent rows/columns) – the rows/cols are typically energized one at a time, and to refresh the entire display faster than the eye can perceive flicker, each one is on for only a very short time – higher voltages help them reach their final dark/light state within that time and retain it until the next refresh. I can’t imagine this little segment LCD having such a requirement.

3) They needed 2 batteries to get the milliamp-hours up regadless, and wiring them in series was easier/cheaper (no worries about cell balancing). This is not an ideal way to get more mAh (increasing resistive losses in the series-connected pair, and conversion losses in any regulator, especially linear/LDO), but I suppose it works well-enough, and the price is right.

Bottom side of PCB exposed

Bottom side of PCB exposed

With the battery pack out of the way, we can see the bottom side of the PCB. Not much there! A couple things to note though:

1) A secret button hidden inside the device. As it turns out, this button resets/clears the device for reuse. The entire LCD will blink every segment for a couple minutes, then the device is factory-fresh again (probably).

2) No components apart from the secret button, but a fair number of empty pads (non-stuffed components).

PCB removed - rear of LCD accessible

PCB removed – rear of LCD accessible

Top of PCB. Notable points incude "secret" magnetic switch, accessible programming header, and an overall dearth of actual components.

Top of PCB. Notable points incude “secret” magnetic switch, accessible programming header, and an overall dearth of actual components.

Finally, we get to the topside of the PCB, the actual meat of the device! Erm, wait a minute, where’s all the meat?

The $70 pricetag notwithstanding, it should be becoming clear that this device is cheap-cheap-cheap to make. The bill of materials consists mainly of a few pushbuttons, a small handful of discretes and a glob-top MCU/ASIC. The segment LCD and an EEPROM in the top-left of the photo (a note on the manufacturer’s web site says it could be 2KB or even a whopping 16KB of storage) complete the ensemble. I have to snicker a bit about that after testing a 32GByte uSD card in my own day-job datalogger design the same day, but again, this device is designed to be throwaway cheap, and 640k (ahem, 16k) ought to be enough for anybody – for temperature data, anyway. (The astute reader will see “32K” stamped on the chip; either a clever misdirection or these loggers have grown more spacious than the web site lets on.)

Some notable points:

1) The temperature sensing element appears to be a simple RTD – no thermocouple or even brand-name digital sensor, but probably accurate enough.

2) The glass tube designated S3 is a magnetic reed switch. This almost certainly is used to trigger entry into the download/configure mode, either with a magnetic wand or a magnet built into a monolithic reader device that aligns to the LEDs.

3) The LCD is affixed to the top shell, not the PCB, and contact is made by an elastomer strip (zebra strip). Don’t lose this!

4) The neat row of capacitors at the bottom of the photo (C2, C3, C10 ~ 13) are probably part of a charge pump circuit for the LCD. There goes that theory about the battery voltage.

5) As with the bottom side, note the prevalence of non-stuffed component pads. Aside from a good handful of discretes, there are spots that appear to accept a second RTD temperature sensor and a humidity sensor. Most likely, this same board and ASIC become the “TempTale4 Humidity” with the addition of these components.

6) Besides the holes for extra sensors, pay particular attention to the two – two! – sets of non-stuffed headers (J1, J2). The latter pins directly into the globtop, suggesting the likely possibility of an in-circuit programming header (or even JTAG, holiest of holy grails).

See-thru view of front case, showing button flexures and a small opening in the plastic to bring the temperature sensor closer to the outside environment.

See-thru view of front case, showing button flexures and a small opening in the plastic to bring the temperature sensor closer to the outside environment.

In this final photo, you can see the shell cutouts as they relate to the overlay sticker. The temperature sensor normally sits in the small notch in the middle, leaving only the thin bit of sticker between the sensor and the outside environment.

A new feature: “Tim Tears It Apart”!

So, as you might have guessed, I’m an electronics engineer, and I like to tear things apart – especially gadgets. I don’t usually post about it, because a) someone else has probably already posted a teardown of that gadget, and b) I’m lazy as balls.

But then I realized a good teardown is not all about the pretty pictures, but reverse-engineering the mind and intentions of the original designer. After about a deca*cough* some time in the industry, at the age where I tell kids to get off my lawn*cough* pull up their damn pants, I’m getting a pretty decent feel for not just how a gadget works, but why it works the way it does – i.e. the budgetary constraints, schedule pressures and technical constraints behind specific design decisions. So maybe it is worth posting those teardowns after all :p

I can’t guarantee it’ll be a frequent feature, but there are a few torn-apart gadgets I could throw my 2 cents in on.

Notes to myself: Test a Bluetooth Low Energy device on Raspberry Pi, the quick way

Testing if the new nRF8001-based Mosquino BLE shield I built actually works.
With the unmodified library and example code, it purports itself to the a Nordic heartrate monitor.


Much of the below based on Michael Saunby’s blog post on checking out a TI SensorTag.

Install bluez and hcitool (plus any dependencies). As of today, current version available from a stock raspbian is 4.99-2. NOTE: “gksu synaptic” from the console to get a working graphical package manager, if you’re into that sort of thing. (“Gtk-WARNING **: cannot open display: :0” probably means you used sudo instead of gksu; bad dog.)


$ sudo hcitool hci0 up
$ sudo hcitool lescan

If all goes well, output like:

LE Scan …
DF:32:3A:73:A3:1C Nordic HRM V1.0
DF:32:3A:73:A3:1C (unknown)

If that’s your device, congratulations, it’s working!

Connecting to it…

$ gatttool -b DF:32:3A:73:A3:1C –interactive
[ ][DF:32:3A:73:A3:1C][LE]> connect
[CON][DF:32:3A:73:A3:1C][LE]> char-read-hnd 0x01
Characteristic value/descriptor: 00 18

Don’t ask me how to find out the handles your device supports or what the resulting data means; that’s an exploration for another day…

Bonus trick: make the computer beep everytime it gets an advertising packet:

$ sudo stdbuf -oL hcitool -i hci0 lescan | while read; do beep -l 20 -f 1000; done

Good for range testing (I have not tested it).