Author Archives: David Guill

Product Review: Banana Pi

A little while back, I was asked by someone from LeMaker to review the Banana Pi. I was sent a total of four Banana Pi boards, along with related accessories.

Here’s what one set looked like:

Banana Pi with Accessories

As far as I know, the SATA cable and case are generally sold separately.

Unboxed, here’s what the Banana Pi looks like (banana for scale):

Banana Pi for Scale

Here’s a Banana Pi next to a Raspberry Pi Model B:

RPi with BPi 1 RPi with BPi 2

Functionally, the main things that distinguish this board from a Raspberry Pi Model B are as follows:

  • More RAM (1 GB vs 512 MB)
  • A faster SoC, with 2 cores (Allwinner A20 vs Broadcom BCM2835)
  • Power and reset buttons
  • Onboard SATA
  • Onboard USB OTG port
  • Onboard IR receiver
  • Higher price tag – as of 10/31/2014, they’re $58.99 on
  • It draws more current, making it slightly more difficult to power reliably. Plenty of adapters are available that fit the bill, but one that works with a Raspberry Pi or smart phone won’t necessarily provide it with enough current. A common recommendation I’ve seen is to use an adapter with at least a 2A current rating. Or you could go bigger and power several Banana Pis at once.

Hardware-wise, the Banana Pi seems to be roughly on-par with a platform like the Hummingboard-i2, Hummingboard-i2eX, or Cubieboard2. But I can’t make that comparison properly, as I don’t have access to any of those.

Initial observations:

  • Build quality generally seems very good. It’s at least on par with or slightly better than the RPi 256 MB and early RPi 512 MB (also made in China). At the very least, the solder joints look really good on the units I received.
  • The layout of the Banana Pi seems like it was probably inspired by the Raspberry Pi model B (RPi B). With some exceptions, its ports are positioned very similarly. Given the differences in SoC and RAM, I’m sure the traces are actually laid out very differently, but its functional similarities should be good for a lot of hobbyists who want a drop-in CPU upgrade for the RPi B.
  • The Banana Pi is slightly larger than the Raspberry Pi, by a few millimeters in both directions. This is a small difference, but it could potentially matter in applications where a Raspberry Pi would fit tightly. Sorry, your Raspberry Pi case probably won’t work for it.
  • The network and USB ports are properly lined up, just as they are now on the RPi B+. The misaligned ports were always an annoyance for me in designing around the RPi B, so I’m glad neither outfit decided to keep that feature of its layout.
  • The SD card socket is a metal jacket type similar to the one I use when I rework a 512 MB RPi B for my Raspberry Pi cluster. Jacketed SD card sockets are less prone to letting the SD card warp from heat, so I’d call this a plus. The RPi B+ also uses a jacketed type socket now, but of the micro SD variety.
  • The Allwinner A20 CPU is quite a bit larger than the Broadcom CPU used on the RPi. It’s mounted on the bottom of the PCB, as opposed to the top. I’m sure this is because the top is pretty crowded with ports and such. But I’m interested in whether or not this makes it inconvenient for anyone to keep it cool enough.
  • On the RPi, the single RAM chip was mounted on the top of the CPU in a package-on-package (POP) configuration. On the Banana Pi, the RAM is in two separate chips next to the CPU. This configuration is probably a lot better for cooling than a POP configuration would be.
  • When the Banana Pi is turned on, its indicator LEDs are pretty bright, especially the green one. The LEDs tend to blink a lot. It’s a little bit distracting if it’s in your field of vision while you’re trying to use it. Some users have considered this to be a great annoyance, but I see it as minor. It’s bright enough that I’d recommend considering a smoked acrylic case in place of a clear one or some method of dimming the LEDs. It’s not a big enough issue that it should be a factor in deciding which mini PC to buy.

Fully assembled, this is what the Banana Pi looks like in its acrylic case:

Banana Pi in Case Top Banana Pi in Case Bottom


The package I received included a specialized SATA cable with a power connection to power it. It only appears to support 5V power; the drawback to this is that it likely won’t work with a lot of SATA drives without an external power adapter, due to the loss of 12V power. (3.3V isn’t such a big loss.) With an external adapter, I was able to read from a WD10JPVT I had on-hand.

Through dmesg, I found that the onboard SATA controller appears to be routed through USB (which appeared to be USB 2.0). I don’t think this is at all unusual for one of these hobby boards, but it should be considered if you’re planning to buy a hard drive to use with it. I’d recommend not paying extra for drive performance.

SD Card Support

I couldn’t get the Banana Pi to work with the Kingston SD4/8GB SD cards I use with the Raspberry Pi model B. Luckily, it works with the Kingston SD10V/16GB SD cards that  I originally bought to try with the RPi B (They didn’t work with the RPi B.) It must be really tough to make these boards support all SD cards.

OS Support

I learned from my experience with the Hi802/GK802 (for which software support never fully matured) that hobby platforms like these are no better than their software support. If software support dries up before at least one mature OS image emerges, the platform can become worthless. Conversely, extensive software support (especially software that’s poorly supported elsewhere) can provide the user with far greater benefit than hardware specifications alone provide.

I believe this explains both the continued success of the Raspberry Pi, in the face of better-performing rival platforms, and the thinking behind LeMaker’s OS image page. They seem to be doing a pretty good job so far of supplying OS images to use with the Banana Pi. Presently, there are links for 13 different operating systems. It’s a good sign that so many operating systems already run on the Banana Pi. However, it’s a little worrisome that most of the download links utilize free file hosting services. It would add credibility to LeMaker to consider hosting their own files, even if they just provide a .torrent and seed each file with severely limited upload bandwidth, in addition to the existing free hosting.

I don’t expect to try every OS available, but I tried a few of them.

Raspbian (Banana Pi version)

By far, I spent the most time with this OS, simply because of my familiarity with it on the Raspberry Pi. It seemed very much like Raspbian on the Raspberry Pi, except that a freshly imaged SD card booted straight to an LXDE desktop. The background background was bright yellow with a Banana Pi graphic in the center. I think this is a nice touch, but you’ll want to customize it. It’s otherwise very similar to the standard Raspbian image.

The default username is ‘bananapi’. For security reasons, this is probably slightly better than ‘pi’, but it does mean you’ll be typing a longer username. If you plan to set up your own user account anyway, this doesn’t mean much to you.

The version of raspi-config on this image has been customized a little. I tried the menu option to expand the SD card image and it worked fine. I’m guessing other software-related options like keyboard configuration should also work. Hardware-related options like memory split were still available in the menus, but I’m not sure if these have been fixed to work on the Banana Pi; they might not even do anything at all.

Aptitude (Debian’s package manager, a front-end for apt) works pretty much the same on this image as it does on the Raspbian image you’d get from Out of the box, it’s also configured to use as its repository. With it configured this way, you’re getting binaries compiled for ARMv6. It seems to work fine. However, for performance reasons, I’d prefer to have the option to use a repository with binaries compiled for ARMv7.

Browser performance (with Chromium) was a little better than what I’ve come to expect from the Raspberry Pi. For example, typing into the search box for a Google search stuttered a lot less. This leads me to believe the Banana Pi is probably a little more suitable than the Raspberry Pi for use as a low-power substitute for a desktop PC.

I spent some time trying to get Mupen64Plus to compile and run. In theory, it should work, since the Mali 400 driver supports OpenGL ES 2.0. I gave up after doing far more than a more casual user would be able to do. (I think my failure was the result of structural changes to Raspbian’s file system, not a shortcoming of the Banana Pi.) I still think it should be possible to get it to work. It’s something I’d like to see, since there are a few N64 games that don’t run on the Raspberry Pi and a few more that don’t work very well. I expect more of them should run on the faster SoC of the Banana Pi.


Without trouble, this image booted to a similar yellow desktop (also LXDE) as the Banana Pi version of Raspbian. I didn’t spend much time in this OS, as I discovered that graphic performance was worse than the Raspbian image. Still, it did work.


This was another variant that booted to a similar desktop as Raspbian and Lubuntu. I had only planned to try it out quickly and realized soon that my habits (formed using many variants of Debian) and lack of experience with Zypper (OpenSuse’s package manager) worked against me. As a consequence, I didn’t get very far with it after I had it booted. Still, it was yet another OS that booted to a desktop and seemed to work fine. It would probably be great for someone who prefers the Suse way of doing things.

Bananian states the following: “The main focus is to provide a lightweight headless platform for home servers, small webservers, ownCloud hosting, Linux based wifi access points, NAS systems, monitoring devices, etc.”

The fresh image booted to login prompt without difficulty. Logging in takes the user (root only on a fresh installation) to a shell. I expect it would probably be possible to get a graphical desktop working on it, but there isn’t much point given the availability of Raspbian for Banana Pi.


Overall, I like the Banana Pi. Since it performs a bit better (due to it having more/faster RAM and dual core SoC), I think it’s better as a desktop replacement than the Raspberry Pi. It still won’t be blazing fast, but it should be enough for checking email and web browsing – at least for sites that aren’t script heavy.

OS support for the Banana Pi is very good at this stage. It will be great to see LeMaker continue expanding it. What they’ve done so far is more than you get from a lot of mini PC platforms (for example, the Hi802/GK802). I think OS support for the Raspberry Pi is still more mature, of course, but it’s an older platform.

Since I have 4 Banana Pis, I expect to try distributed applications on them. I’ll post something about that as soon as I’m able.

Related product links:

Update: What I’ve Been Up To

The past several months have been a whirlwind of the following:

  • Searching for a job
  • Putting various aspects of my life in order post-college, including sorting and fixing a lot of stuff that just wasn’t important enough to take care of while I was a student, but definitely is now that I’m not
  • Back-to-back: A nearly-free trip to Cabo and then a trip to Illinois for my sister’s wedding
  • Dealing with treatment and surgery for a torn peroneal tendon in my left ankle

Job Search

I have the unfortunate circumstance that I have a gaping hole on my resume from August 2002 to December 2008, primarily due to the tech crash that followed the World Trade Center attacks of 9/11/2001. When I graduated with my BSEE in August 2002, new graduate unemployment in my field was over 50%. There was a deluge of laid-off, experienced engineers, all clamoring to take any job, even entry level.

I was also living in my hometown of Mattoon, IL after college. In spite of my eagerness to relocate, this did not help my odds of getting a job. Between August 2002 and December 2008, countless applications and resumes sent out yielded a total of five honest-to-goodness electrical engineering job interviews. I applied for other types of jobs too, but none of that ever bore fruit, not even a single interview. I did a bit of temping, taught myself to code, and even consulted on a Second Life game called Tringo, which earned a mention in the Wall Street Journal.

Since I earned my MBA and MSCE and finished 2 graduate internships with major semiconductor manufacturers, interviewers care about that employment gap slightly less. I’ve had about a half dozen interviews since December 2013, mostly with solid companies. Getting those interviews is still challenging, enough that each one I get feels just like I imagine winning the Little Lotto would. I do my best for every interview to show that I’m a great candidate, but I’ve not had any offers yet.

I’ve recently started working with a couple of recruiters, so hopefully this will also help in my search. I’m sure I’ll find something, as I have the talent and skill and I’m working to demonstrate it in every possible way (e.g., this site and projects I can demo in interviews), but there’s probably still a lot of work ahead before I’m employed.

Fixing Stuff

Just like nearly everyone else of the “handy” persuasion, I have a backlog of unfinished projects. No matter how hard I work to minimize that backlog, there will always be a few things. But, to put it simply, I have too much of that stuff right now, partially as a consequence of getting advanced degrees and not having the time to sort through stuff. As I’ve had the time, I’ve been working to do something about it since I graduated in December.

In late July, I took on my cache of damaged electronics and small appliances. As a result, I did a half dozen or so major restorations and repairs. I think some of them are worth posting on here. I’ll surely have time to do some of that over the next several weeks.

Of course, I also gave away some things, donated others to Goodwill, recycled some, and just plain threw some it out. All of that helps too.


As I said above, I traveled to Cabo and Illinois several months ago.

The Cabo trip was wonderful. It was part of a service award that my wife, Teri, won at work. We were able to extend it to 9 days total. It was so nice to get away and spend some quality time on a beach again. We hadn’t had that kind of a vacation in about five years. I’ll probably post something more about that eventually.

And a short visit to my hometown of Mattoon is always interesting. At the very least, it’s nice once in a while to go back and visit places like the local Burger King. My hometown isn’t a very exciting place, but it’s still pretty unique.


Until 3 weeks ago, I’d been tolerating a split peroneal tendon in my left ankle for between 16 months and 5 years. I have a few guesses about when and how I injured it, but none stand out enough that I’m certain of the cause. It was likely an injury of attrition, resulting from too much walking and not enough time for the tendon to repair itself. I do walk around quite a lot.

Once I knew what the injury was, I did my best to let it heal on its own. But that isn’t easy with a torn tendon. The human body is generally amazing at healing itself and indicating that it needs a rest. Tendons are an absolute exception – the pain goes away far more quickly than they heal, tempting the risk of further injury. With a tendon in the ankle, it’s especially tough, because life frequently presents scenarios where the choice is to either take a fall or undo weeks of healing. And that’s just what you get for walking around; anything requiring more exertion is a greater risk.

Six weeks ago, after trying to let the torn tendon heal on its own, I decided to have it surgically repaired. This wasn’t an easy choice, since it meant up to six weeks without walking. As of today, I’ve been out of surgery for three weeks. It’ll still be another three weeks before I can use my left leg for walking or even holding up my body weight. After that, I get to walk in one of those huge boots for two more weeks. Then, it’s on to physical therapy, to learn to use my left ankle properly again.

Since I’m mostly going to be sitting over the next three to five weeks, I’ll hopefully also finally get to spend some more quality time with the Pi cluster too.

SD Card Issues

I’ve had 16 Pis running for about a week (with 16 GB SD cards) with no trouble. I’ve been running them with only 2 of 4 intake fans to maintain a power-to-airflow ratio that’s close to what I should expect from having all 40 of them running. I’ve been seeing case temperatures of roughly 31 °C (88 °F) and core temperatures of up to 77 °C (171 °F). 77 °C seems kind of hot to me, but it’s still acceptable for a BCM2835 core. I’ve read that 85 °C is supposed to be their limit, but this announcement by the Raspberry Pi foundation seems to indicate that 85 °C is an acceptable steady-state operating temperature.

Two nights ago, I decided to bring the remaining 24 Pis online. This required that I use 24 of my 8 GB SD cards . I didn’t anticipate any problems. I flashed 24 fresh 8 GB cards, brought the other 2 intake fans back online, and booted the remaining 24 Pis.

I went to the work of assigning static IPs to all of them. (Managing 40 machines through SSH without assigning static IPs is a hassle.) But, an hour or so in, I had to hard reset the whole system. As it came back online, I noticed that some machines didn’t appear to be booting up properly. (Their indicator lights were staying red.)

After a lot of trial and error to try to get these machines to boot, I realized that a whole bunch of the SD cards had warped, as shown in the photo below:
Warped SD Cards


Since the biggest group of them failed, I’ve noticed that a couple of stragglers have also warped to the point that they no longer work. This is important to note, because I’ve been running the system with no filters and with the left side of the case off, which greatly increases airflow. So the warping is continuing, in spite of the fact that they’re probably at no more than 55 °C now.

I’m not really sure what to blame for this. The Pi’s SD card socket doesn’t back the card when it’s fully inserted, which seems like a weakness in the design that would allow this to happen. However, Kingston rates these SD4 series cards for 85 °C and I have a hard time believing that any of them got over 70 °C at any time. There’s also the fact that the 16 GB cards haven’t had the same problem, which leads me to believe this is specifically an issue with the SD4/8GB. Either way, I’m pretty sure the solution is to add a clip to the socket to back the SD card so it doesn’t warp.

Progress at Compiling Mesos

I’ve been in the process of trying to get a good compile of Mesos on the Raspberry Pi for about 3 1/2 weeks now. I decided to document the challenges of this, in case it might help anyone else who is trying to do the same thing.

My first approach was to try compiling on a single Raspberry Pi. I used the recommended “make -j”, which uses an exorbitant amount of memory. (It was a big mistake to not look up the “-j” option.) I frequently got the nearly-useless error “g++: internal compiler error: Killed (program cc1plus)” mixed in with what appeared to be continued attempts to compile. After a great deal of searching, I found this was caused by the system running out of memory.

Memory Error

My impression at the time was that simply adding more swap memory wouldn’t be enough to allow the job to proceed to the end, so I decided to try to cross-compile instead. I spent about  a week trying to get Crosstool-NG to build a cross-compile toolchain that would run under Windows. It appears to be unable to do so, in spite  of the fact that it tries so very hard. I managed to get it to run to completion with settings that should have generated a working toolchain, but the files it generated were garbage. I intend to pick up this effort again later, after I get a few other things compiled. If I get it to work, I intend to document the process from start to finish, which apparently no one has done yet. (There are a lot of bits-and-pieces sets of instructions out there, but even the best of them skip steps that are necessary to make it work.)

After giving up on Crosstool-NG, I went back to trying to compile on a single Pi. I expanded the swap memory available to it. After some experimentation, I arrived at the conclusion that a 6 GB swap file was necessary. This seemed to be enough for the compile to run. I allowed it to continue to run for 3 1/2 days like this, but finally decided it was taking too long.

Memory While Compiling Mesos

In hindsight, adding a 512 MB swap file probably would have been enough if I’d used “make -j2″ instead of “make -j”.

This is when I decided to try getting distcc going on a subset of my 40 Pis. Even with the troubles I’ve had with distcc, I probably should have done this sooner. I set it up on 16 Pis (1 master + 15 slaves). Using this distcc cluster, I succeeded in compiling mesos for the first time on 3/6. It can compile mesos-0.16.0 in about 3 hours. At the time, this was a wonderful thing to see:

Mesos 0.16.0 Compile Finished

Before this will even work, the mesos source code has to be edited in several places to remove/replace Intel-specific assembly code. I also had to install gcc-4.7 (it is not necessary to remove gcc-4.6). I will document code changes in greater detail at a later date.

A pure distcc build results in the following errors during “make check”:

Python Remote ReplicaTest.Promise Error

I discovered that it’s possible to get ExamplesTest.PythonFramework to pass by deleting the mesos-0.16.0/build/python directory and re-running “make -j2″ without distcc:

Python Local

It only takes a few hours to finish it again. But it still baffles me that this would make any difference at all. With every instance of distcc running on a Pi (with the same OS, compiler, and configuration), I should get the same result regardless of which machine is compiling which part. At present, my only guess is that distcc is deciding not to pass along my CFLAGS and CXXFLAGS. But the only documented precedents I found for this would not apply in this situation.

I’m currently trying to find the source of the ReplicaTest.Promise test failure. I believe this failure is also related to discrepancies in how distcc compiles code remotely vs a purely local compile. However, I don’t know yet which parts of mesos will need to be compiled locally before it will work, or if compiling it all locally will even be enough.

Why the Raspberry Pi?

Several questions have been posed about my 40-node cluster design (e.g., “Why build a Raspberry Pi cluster?”). I’ve decided to provide a little of the history of my project, and some thoughts on its possible future.


I first had the idea of building microcontroller-based cluster in early 2002. At the time, I was working with Motorola 68k microcontrollers in my senior design project for my BSEE at SIUC. I knew that such a cluster would have been nothing more than a novelty, as microcontrollers were entirely insufficient for running the software used by the supercomputers of the day. But the idea stuck; since that time, I occasionally checked the market for tiny platforms that might be sufficient for running industry-standard software. At one point, I even considered building a cluster of smart phones.

I think the first really promising mini-computer platform I saw was either the BeagleBoard or Pandaboard, either of which still costs over $100. While these were both awesome hobby platforms, they were pricier than what I’d hoped for and they had a lot of hardware I didn’t need, which also made them unnecessarily large. On the other hand, the Pi’s circuit board was about the size of a credit card and only cost $35. If you wanted a tiny, inexpensive platform like this with an Ethernet port (not wireless) in early-to-mid-2012, the Raspberry Pi was the best, hands down.

I knew about the Raspberry Pi in early 2012, but initially held off on ordering because I didn’t want the hassle of getting around the one-per-customer restriction. I didn’t learn that they’d lifted the restriction until 6/29/2012. After some debate, I ordered my first 5 Pis on 7/1. By then, Allied Electronics’ site already “estimated delivery time will be 10–12 weeks”. At the time, I had only planned to build a 5-node cluster, or maybe even 16-node if they were really suited to it.

While I was waiting for my first 5 Pis to arrive, I learned of the now-infamous 64-node Lego Pi cluster. And this is when it really started to sting that my 5 Pis hadn’t arrived yet. My Pis were not shipped until the day before Allied started shipping with 512 MB of RAM. (Allied, seriously, Y U NO ship the 512 MB version to the customers who patiently waited almost 4 months?) But I already knew by that time that I wanted at least 16 nodes in my cluster; I immediately ordered 11 more.

Had I received my Pis in July, I would have had several months to work with them before things turned busy for me in the fall. I had 5 Pis in late October of 2012, but didn’t get to play with them much over the following 11 months. The rest of that time was eaten up by internship responsibilities and thesis work. Of course, I don’t regret prioritizing that stuff; it had to come first. I didn’t get to seriously work on finishing my cluster until September 2013. Pi clusters were all over the Internet by then, some of them very well-constructed.


In spite of how long it took for my Raspberry Pis to arrive, I don’t regret choosing it. I admit, Broadcom’s announcement that they had open-sourced the BCM2835 video drivers has really sweetened the deal, because this should mean there will eventually be OpenCL drivers. However, this is not to say I’d still choose the Pi if I were starting this project now. If I had to make the same choice right now, I might choose the BeagleBone Black or wait for the official release of the Hummingboard, both of which should be compatible with my case design. There are also a number of other quad-core i.MX6 platforms on the market now. None of them with Gigabit Ethernet are near the Pi’s price point and size yet, but I expect that to change in the future. The i.MX6 has already had OpenCL support for a while though, which makes any suitable platform based on the i.MX6 appealing.

Many have asked why I would building a cluster based on smaller platforms, such as the Pi, suggesting that I could test distributed algorithms with hundreds of virtual machines, such as Docker or EC2 instances. Obviously, this is true. In the future, I’m sure I’ll set up a virtual cluster as well. But a Pi cluster is what I’ll be using for now, as there are benefits to testing on real hardware, even if it isn’t the target hardware for the software in question.


I built my cluster primarily for software testing, but bigger players, such as  DellHP, and Intel are preparing for the day when data centers are filled with microservers. In a setting where redundancy is important, this makes a great deal of sense.

When I planned my cluster, I intended to create something upgradeable. The case I designed is easily adaptable to other platforms that are roughly the size of the Pi and it would also be easy to use Gigabit switches (e.g., the Cisco SG102-24-NA) in place of the 10/100 switches I used. With a better power card design and more powerful mini-computers (e.g., the Hummingboard), it would be much faster. This means the same case could support 192 processor cores and 80 GB of RAM. Just imagine what will be possible when similar platforms based on 8-core or 16-core ARM or Atom SoCs are available.

Laser Cutter Tips

In the course of making my 40-node Raspberry Pi cluster, I learned quite a lot about working with a CNC laser cutter. These are a few of the tips I have for making laser-cut parts that I used for this project.

Tip 1: Acrylic Prep

Before cutting parts, first prep a suitable piece of your acrylic.

Tip 1 - Add soap and water to your acrylic Tip 1 - Spread soap and water across the acrylic surface Tip 1 - Make sure surface is thoroughly coated

  1. Peel one side of your acrylic. It’s best to peel the blank side, so you can easily identify your material later.
  2. Apply soap to the peeled side, as shown in the pictures. You can use mostly water with a little soap. I’ve found that more soap is better for keeping vaporized acrylic from condensing back on the workpiece, but less soap is a little easier to rinse off. Find the balance that works best for you.
  3. Place the acrylic on the cutting bed with the paper side down.

Don’t prep all of your acrylic at once, as the paper/film tends to protect it a lot better from scratches than .soap does.

Tip 2: .svg Color Codes

I generally use the following guidelines to color code my .svg files:

  • Cyan: 1st pass – Lightly etch at minimum power
  • Red: 2nd pass – Interior holes – Cut all the way through
  • Blue: 3rd pass – Edges – Cut all the way through
  • Green: Alignment guides, etc. – do not cut (0 passes)
  • Black: Notes – do not cut (0 passes)

Black and green are interchangeable. So are blue and red, so long as your grid is reasonably level. With this in mind, I occasionally break my color code a little in some files.

Tip 3: Watch Your Job

The following video is one I shot to give an idea what the process of laser cutting looks like. Don’t watch it all, unless it just entertains you. However, keep in mind that you need to keep a close eye on your cutting jobs while they run to ensure that your cuts are good and to be sure your workpiece or laser cutter hasn’t caught fire. Yes, that does happen occasionally! Be prepared for it!

Tip 4: Dealing with Errors

You can see in the above video that I made an error in laying out my cut, causing some of the lines for one of my parts not to cut in my first run. (The first run ends at 12:34, at which point my second camera also stops recording.) I remedied this with a second run, where I set all of the already-cut lines to a single color, sent the cut job to the driver software again, and set that color to 0 (zero) passes. This is shown in the 4 screenshots included below. Use this technique if you happen to forget something and you don’t want to waste material. Just remember not to move your workpiece before you cut the remaining lines!

Laser Cut Error Step 1  Laser Cut Error Step 2 Laser Cut Error Step 3  Laser Cut Error Step 4

Tip 5: Wash and Dry

After your acrylic is cut, peel your parts, wash them, and dry them with lint-free cloth. Even the “lint-free” microfiber cloths you see in local stores can put out quite a lot of lint while you work. Experiment a little, in very good lighting, before choosing drying cloths for a big project. You’ll be more happy with the end result that way.

A technique I found useful was to pre-dry parts with a large high-quality terry cloth towel, then buff them off with a microfiber towel. This worked better than using microfiber alone, because the terry towel could hold a lot more water.

In the last pass of drying/buffing a part, reduce lint by passing over the part in one direction, as opposed to going back and forth over it.

Tip 6: Measuring Kerf

Many parts will simply work better if you adjust them for kerf (effective width of the laser beam as it cuts). The required adjustment will vary depending on your model of laser, the settings you’re presently using, how clean your laser is, and how well it’s currently focused. Consequently, I can’t adjust for this offset in my files. However, the following procedure has worked well for me so far:

  1. Cut six to eight 5 mm circles out of your chosen acrylic. If you cut eight, you can afford to lose two.
  2. Measure the width of these circles with a caliper. Record the list of results.
  3. Toss out the highest and lowest measurements.
  4. Average the remaining values. (You should get something a little less than 5 mm.)
  5. Subtract the average from 5 mm. (You should hopefully get a fractional value.)
  6. Divide by 2. (We only want to adjust by half of the beam width.)
  7. Adjust by 80% of this value.

As an example, suppose the average circle measured 4.80 mm. That would mean the width of the beam was 0.20 mm. Halving that value gives us a beam radius of 0.10 mm. 80% of that values is 0.08 mm, which is how much we should adjust by.

Do not simply adjust by the full radius of the beam, because some of the parts would be overly tight and a few of them simply would not fit. Even with my procedure, you may need to sand some of your tighter parts down a little if you’re working with little margin for error. An emery board is good for this if they’re close. A rotary tool with a small sanding drum is better if they are not.

Once you’ve found an offset that works well with your laser and settings, it will likely work well for a large number of cuts, so long as nobody dirties up your laser or ruins its calibration.

Tip 7: Adjusting Kerf

In Inkscape, I adjust for kerf with the following procedure, as I’ve found it to be very precise:

Step 1: Create a resizing rule – I generally use a horizontal and vertical line, each as long as the resizing width, connected at one point. But use what works best for you. It should have no fill and a very narrow stroke width, such as 0.002. The width you choose should depend on how well you can see a narrow stroke when you’re fully zoomed in.

Kerf Adjustment 1

Step 2: Select the exact poly line in question by using the “edit paths by nodes” tool. Reduce the stroke width to the same narrow poly line width you used above. Keep this poly line selected with the “edit paths by nodes” tool.

Kerf Adjustment 2

Step 3: From the “Path” menu, select “dynamic offset”.

Kerf Adjustment 3

Step 4: Near the newly-appeared white diamond, move the resizing rule (from step 1) in line with the poly line that needs adjustment. Check one last time to be sure you’re adjusting in the correct direction. Blue lines should generally be adjusted outward, while red lines should generally be adjusted inward.

Kerf Adjustment 4

Step 5: Drag the white diamond until the poly line has been fully resized. This can be a slow process, but don’t let go of the diamond until the poly line is where you want it. With practice, you can learn to get it where you want it in 2 or 3 “ticks” of the offset resizer. If you can’t seem to get it exactly where you want it, aim for resizing a little less instead of a little more. Also, don’t worry about the funny rounded corners – they won’t matter in the end.

Kerf Adjustment 5

Generally, you can get the resizing extremely close with this method. However, if you can find a way to get the inset and outset tools to work equally well for your purposes, I suggest using those instead.

Tip 8: Cut Extras of Small Parts

Small parts more easily get lost through the grid and during processing before they’re glued in place. But your current laser cutting job will often have small parts and some slightly larger cutout holes. When possible, place one or two extra of each small part in smaller cutout holes. The material in these holes would usually end up being waste material anyway, so the only real cost for making spares is the laser time.