Jeff Epler's blog

19 November 2016, 19:08 UTC

Monoprice Select Mini 3D Printer Review


As my long-time readers may recall, a few years ago I bought a Rostock MAX and never had any success with it. Ultimately, I had to admit to myself that I was not enough of a tinkerer to actually use a DIY 3D printer.

Then earlier this year I heard about the MP Select Mini. Everyone seems to agree on the basics: It is a printer that you can literally take out of the box and get an OK print out of, but on the other hand it is a printer with a lot of limitations and is perhaps less durable than you'd wish.

At $200 for the printer itself, I felt I could give it a try. My actual order price was $234.79 shipped, with a 1kg spool of filament.

Things initially started out rocky: I had intended to order PLA, but ordered ABS by mistake. ABS is harder to print with, and honestly the Select Mini seems to be somewhere between "marginal" and "useless" with ABS. Initially, my prints did not adhere at all, but later after tweaking I had limited success. At the same time, I decided I simply had to order a spool of PLA, and paid extra to be sure it would be delivered on Friday (yesterday).

Hoo boy, PLA simply prints wonderfully on this printer. I haven't fine-tuned the printer (such as making sure I'm not under- or over-extruding) but "art" prints like the Lucky Cat and technical but not dimension-critical prints like the hinged filament oiler come out looking and feeling great. I'm using 150um layer thickness, so everything is banded, but all the axes keep position perfectly, the extruder works well so far, overhangs consistently look good, and there are a minimum of snots.

On the other hand, before a closely dimensioned print like the E3D extruder adapter or mechanically mating pieces like the nautilus gears will work, I will have to do some fine tuning of the extrusion parameters.

I'm keeping a spreadsheet of every usable print and every expense. So far, including the print on the table, I've spent around $23 per print. Once I work through my initial list of ideas, I'll be down to $11/print or so.

Unfortunately, I made the mistake (twice!) of ordering black filament, so prints are really not photogenic. On my to-buy list are natural/clear PLA and some non-black, non-white PLA. I do have a small gallery of my prints on google photos: https://goo.gl/photos/Q71HRLSxzLvqSdt7A

The single biggest piece of advice I wish I'd had right away was: if you get underextrusion with clicks from the extruder during the first layer, the bed is too high; it's not that the nozzle is clogged or any other problem with the hot end. Stop panicing and turn the setscrews another 1/6 turn.

Summary: for me, this is an excellent printer. It lets me get down to the business of learning the software end of things, and the most mechanically difficult things I have had to do so far are level the bed and change the filament. If that sounds like the relationship you'd like to have with an entry-level 3D printer, consider the Select Mini.

Software: Debian Jessie, OpenSCAD 2014.03, Cura 2.3.1, Printrun.git

Community: MP Select Mini wiki, thingiverse, freenode #reprap

[permalink]

16 November 2016, 2:04 UTC

Monoprice Select Mini, sight unseen


Some observations on the files that can be seen inside the firmware update file "m200-160615.rar" from Malyan Systems:
  • update.bin is clearly a modified version of Marlin, under the GPL3 license. Of course, neither monoprice nor Malyan Systems are offering the source
  • lcd.bin has some heavy indications of being based on the ESP8266. There's LGPL stuff in there, more license violation ahoy.


Other thoughts based on obsessive googling:

  • I've tentatively IDd the low current connectors as JST "XH" series with 2.5mm pitch (rated 3A)
  • And the high current connectors as JST "VH" series with 3.96mm pitch (rated 10A)
  • why are there no photos of the UI controller board?
  • The STM32 pins for the UI controller board are probably PA9/PA10 AKA USART1_TX/RX. Easy to sniff.
  • Logic section voltage is supplied by XL1509-3.3, a buck-mode switching regulator with a fixed 3.3V output.
  • Many parts in the HV section have part numbers that indicate they might work with a power rail higher than 12V (some people have mentioned using 13.2V)

[permalink]

11 October 2016, 20:16 UTC

git merge-pr: A tiny github integration script


This is a little script I cooked up a few months ago, then hacked on a little bit this week. It provides a convenient shortcut to locally fetch or merge the changes in a github pull request. It doesn't require any special privileges (e.g., github account, API key) to use, unlike other alternatives like github-cli (ghi).

Files currently attached to this page:

git-merge-pr2.9kB

# Quick commandline tool for fetching and/or merging github pull requests.
#
# Steps for use:
# 
# Once per computer or user, depending on location:
#     Install the program `jq`; debian package name `jq`
#
#     Place this in the system directory shown by `git --exec-path` or in any
#     directory listed on your $PATH, typically including $HOME/bin
#
#     You can (re)name it what you like, except that the name must begin
#     "git-".  If the script name includes "pull" or "merge", invoking it will
#     do a merge.  Otherwise, it will do a "fetch", leaving the branch for you
#     to inspect at FETCH_HEAD
#
#     (you can create the second copy with e.g. `ln -s`)
#
# Once for each clone:
#     Configure the github project, e.g.,
#         git config github.project linuxcnc/linuxcnc
# 
# To merge or fetch an individual pull request, just specify it by number:
#     git merge-pr 144
#
# If you put a copy / symlink as git-fetch-pr, you can also
#     git fetch-pr 144
#
# To act on a pull request associatred with another fork of this project,
# specify the name of the fork:
#
#     git fetch-pr jepler/linuxcnc#37
#
# This script does NOT check that you are merging the pull request to the
# branch requested on github.
#
# License: CC0 https://creativecommons.org/share-your-work/public-domain/cc0/
#          Also commonly called "Public Domain"

[permalink]

17 September 2016, 16:08 UTC

LinuxCNC on BeagleBone Black, Raspberry Pi, Odroid U3, Odroid XU4


For several years, LinuxCNC has compiled and passed its testsuite on common ARM hardware.

That leaves several missing parts for a good LinuxCNC experience actually running hardware:

  • UIs that perform well
  • Hardware drivers
  • Dependable realtime kernels
  • Prefabricated OS images
  • Volunteers to maintain these ports

As far as UI performance, Mesa with LLVMPipe has made great strides since the first time I tried AXIS on a BeagleBone, and CPU improvements don't hurt either; performance on boards from Pi on up is pretty good now. You can also choose a previewless UI like touchy or gscreen. And, of course, remote NML works again in version 2.7, so you can run your UI on a different machine than your realtime (though this still has plenty of rough corners / papercuts).

Hardware drivers are beginning to trickle in. 2.7 has hm2_spi, which works on any preempt-rt with good /dev/spidev hardware drivers. Unfortunately, out of 3 systems I've tried (U3, XU4, and PI3), none had good spidev hardware drivers out of the box. I have a kernel git with patched U3 and XU4 drivers, which give good performance on U3 and low to adequate performance on the XU4. Our master branch has a userspace spi driver for PI-family CPUs (hm2_rpspi), and a GPIO-only driver for BBB (bb_gpio). One LinuxCNC developer is working on a BBB PRU firmware which provides a hostmot2 register-compatible interface, but that's not available yet. Based on my experience porting MachineKit's BBB GPIO driver to LinuxCNC, the difficulty of doing so is low, so if MK has a hardware driver you'd like to see in LinuxCNC, it's not the worst place you could start with contributing to LinuxCNC. Please remember to credit MachineKit authors by name in your LinuxCNC pull request, and also verify license compatibility.

For almost all of these boards, you can find various realtime patch sets, github repositories, debian packages, and so on. In my experience, they don't always work, which makes for a frustrating experience. If you want to use LinuxCNC 2.7, you need to find a PREEMPT-RT kernel; for our master branch, you can use PREEMPT-RT, Xenomai, or RTAI, depending whether your hardware driver needs a syscall interface in realtime (hm2_spi does, for example; hm2_rpspi and bb_gpio do not)--if you do, then PREEMPT-RT is your only choice.

The Machinekit fork of LinuxCNC offers pre-built realtime kernels and prefabricated OS images, and in my experience it is easy to to start with their image, remove machinekit and install LinuxCNC from source. Unfortunately, I was unable to find where they publish their kernel source or the scripts they use to generate the kernel packages and images. This means that the LinuxCNC project can't build on their packaging and distro-building work. I'll update this space if any little birds tell me where these resources can be found, because it would be a big help for a volunteer who wanted to get these kernel packages or OS images distributed from linuxcnc.org with LinuxCNC preinstalled.

That brings me to the last point: linuxcnc.org doesn't compensate anyone for their work on LinuxCNC. Current developers have all their time and motivation eaten up by supporting existing platforms, so without new volunteers, we simply don't have the time and motivation to make these first-rate, like we do for standard x86 systems. Join us and help make the LinuxCNC you want to use.

[permalink]

19 August 2016, 14:38 UTC

Will an Electric Vehicle save on CO₂ emissions anyway?


Warning: Betteridge's Law Applies

tl;dr: Compared to a hybrid like the Toyota Prius, the incremental emissions for a Tesla using typical US electricity sources are higher. They just don't occur at the car's tailpipe.

After recently asking whether a person with my habits could ever save money driving a Tesla instead of a Prius, I also wondered about per-mile emissions. Others have investigated the extra costs of EV manufacture and disposal (many elements of which apply to a hybrid as well), while my research is only about the incremental CO₂ emissions created by whatever energy inputs the vehicle needs.

Here's the spreadsheet itself, which includes links to sources for each number.

The top result is that the source of electricity makes a huge difference: China (major electricity source: coal) has 9x the emissions per kWh than France (major electricity source: nuclear). Canada has under 50% the emissions of the US, and I was happy to see that my local electrical utility is 10% under the US national average.

Using EPA fuel economy and the 2015 US mix, I calculate 47.7 lb CO₂/100 miles in the Tesla, and 40.0 in the Prius.

Of course, if you're comparing the Tesla to an "average" US car, it's a different story: The 2014 fleet economy for passenger cars is 31.5MPG, leading to emissions of 71.11 lb CO₂/100 miles.

If you're living in a country that has more nuclear or "renewable" energy, like France, you'll also come out ahead: with only 0.26 lb CO₂/kWh in 2008, a Tesla would put only 21% as much CO₂ into the atmosphere as a Prius running on gasoline.

I also took a stab at how Clinton's clean energy plan would change the numbers. My first guess is that it woud lower the lb CO₂/kWh by around 1/3, which still doesn't make us as clean as Canada's 2008 mix.

Finally, I checked how a Prius would do running on E85, assuming that carbon-neutral ethanol production were actually possible. This brings the prius down to 8.34 lb CO₂/100mi, within spitting distance of the cleanest electricity of countries I surveyed, 8.21 lb CO₂/100mi running a Tesla off the French grid.

[permalink]

17 August 2016, 12:51 UTC

Imagine (software developer version)


Imagine there's no malloc,
It's easy if you try
No free below us,
Above us only sky
Imagine all the software
Working right today

Imagine there's no build step
It isn't hard to do
Nothing to cause link errors
No compiler flags too
Imagine all the software
Passing its testsuite

You may say I'm a dreamer
but I'm not the only one
I hope some day you'll join us
And the world will live as one

Imagine no mutexes
I wonder if you can
No atomic intrinsics
Threadsafe data structures
Sharing all the world

You may say I'm a dreamer
but I'm not the only one
I hope some day you'll join us
And the world will live as one

With apologies to John Lennon

[permalink]

11 August 2016, 22:07 UTC

Does an electric car make economic sense?


Warning: Betteridge's Law Applies

I drive 8000 miles a year in a car with 45MPG actual fuel efficiency (2013 Prius). We paid somewhere around $23000 for it. If I drive this car for 15 years, I'll buy around 2700 gallons of gas.

Compare this to the (discontinued) Prius Plugin Hybrid with MSRP of about $30000. Imagine that I could have done all my driving in electric mode, and that its efficiency is ∞MPGe. I'd break even on the $7000 higher initial price if the average gas price is $2.56. Sounds plausible that I could save money that way, right?

But of course I couldn't go everywhere in "all-electric" / "charge depletion" mode, probably only about 2000 miles/year out of my 8000 miles/year would fall into this category (in-city driving 200 days a year at 10 miles/day). So now I'm only saving only about 670 gallons of gas *OVER THE COURSE OF OWNING THE CAR FOR 15 YEARS*. This is only break-even if gas is $10/gallon.

But of course, the plug-in hybrid is not ∞MPGe, it's 110MPGe, so I'm still buying electricity equivalent to 270 gallons of gas over the course of owning the car to drive those 30000 miles, meaning I only saved 400 gallons of gas, making the break-even gas price $17.50/gallon.

But MPGe is actually "miles per 33.7kWh". 33.7kWh of electricity costs $3.17 in my local market at summer rates, or $1.88 at winter rates, an average of $2.31 (only 4 months are "summer"). So that's $623 in electricity to operate the thing in electric mode for 30,000 miles, pushing the break-even gasoline price up to $19.

And don't get me started on the all-electric Tesla Model S, the car that costs as much as two or three priuses and still can't drive from Lincoln to Denver. Or rather, I could, if I stop to use charging stations at a few key locations on I-80, which from what I read can charge a car at a rate of about 30 miles per hour...

[permalink]

10 August 2016, 11:56 UTC

LinuxCNC on Beagle Bone Black


Last month, I worked on Xenomai support in LinuxCNC just so I could list it as a feature bullet. What should happen this month but a visit from old-time LinuxCNC developer jmk, who was trying to get a HAL-based virtual control panel running on a Beagle Bone Black, for which there's a quite decent Xenomai kernel build available. (I think we have the MachineKit folks to thank for that)

By my standards, the Beagle Bone Black is quite under-powered; for instance, its 512MB RAM is too little to even build some of the source files in LinuxCNC; and even if it did (with an added swap file, for instance) the build times can be nigh-intolerable.

So starting with a wheezy image with xenomai kernel intended to run MachineKit, together we've hacked together a configure time flag to add the configure flag "--hal-only", and ported the MachineKit hardware driver "hal_bb_gpio" over to LinuxCNC. For the moment this lives in the linuxcnc.org branch jepler/master/halonly but hopefully it can be cleaned up and merged to master branch before long.

And what is jmk working on? Apparently it's something that will be used by the Tesla Orchestra in an upcoming performance.


[permalink]

19 March 2016, 23:35 UTC

New Desktop 2016

All older entries
Website Copyright © 2004-2014 Jeff Epler