Jeff Epler's blog

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

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]

Will an Electric Vehicle save on CO₂ emissions anyway?

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]

Imagine (software developer version)

[permalink]

Does an electric car make economic sense?

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]

LinuxCNC on Beagle Bone Black

(M)(L)

overnight latency: 19us base / 76us servo

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]

LinuxCNC: Which kernel, which package?

It's getting complicated to decide how to install LinuxCNC! With the upcoming 2.8 release, you will have your choice of support for three realtime kernels (and generic/vanilla kernels for simulator mode):

1. RTAI
2. PREEMPT-RT
3. Xenomai

Like LinuxCNC 2.7, there are two package flavors:

1. linuxcnc (kernel-module-based)
2. linuxcnc-uspace (userspace-based)

And here's a matrix of kernel support vs package flavor that we hope to have in 2.8:

.. there are two main caveats to that list:

1. Running kernel version must exactly match what LinuxCNC was compiled for (one of the biggest hassles with RTAI using the kernel module model)
2. linuxcnc-uspace Packages from buildbot don't actually have RTAI support now, but self-built packages will, as long as the package with lxrt development files is installed (rtai-modules-*)

As you can see, linuxcnc-uspace is better (at least on paper) than the old rtai-kernel-based approach, it's more versatile in terms of RTOS support, and it's never tied to a specific kernel version.

One thing we don't know yet is: how much additional latency or jitter is introduced by using LXRT ABI instead of kernel module ABI? I hope it's little enough that we can consider dropping the kernel module realtime model altogether for LinuxCNC 2.9 or so.

So I propose the following steps for deciding which flavor of LinuxCNC to use, if you're building our master branch:

1. Choose linuxcnc-uspace with the realtime kernel of your choice

[permalink]

Star Trek: Beyond as a 4-episode mini arc

S3E9: Toxic Humanity

One of the Teenax who attacks Kirk becomes ill after the attack, because human blood is toxic to Teenax. McCoy places Teenax (all the Teenax are called Teenax; they insist that as they speak it, each name is distinct) in stasis but cannot cure it. However, the Fabona (who look like 9' tall sunflower plants) offer a second artifact with healing powers. This time, the Teenax choose to overlook the fact that the artifact may be "stolen" in order to save the life of their countryman.

B plot: Scotty plays a practical joke on Keenser, but its race is unfamiliar with the concept. Keenser takes it in stride, but an attempt to reciprocate the practical joke goes awry.

B2 plot: Kirk's upcoming birthday; subspace communication with Commodore Paris about promotion to a desk job.

S3E10: Starbase Boondoggle

B plot: Billed as the Federation's largest engineering effort to date, Yorktown Station is not all it is hyped to be. Problems range from wonky comms to broken replicators. "At least the gravity stayed on this time!" quips Sulu's partner (whose name we actually learn) when the lights fail during a romantic dinner.

S3E11: Altamid Part 1

S3E12: Altamid Part 2

As we watch the time-lapse construction of NCC-1701-1, voice overs:

Kirk: That ship is beautiful. Too bad I'll never fly her.
Paris: She's is yours if you want her. Perhaps your promotion was just a glitch in the Yorktown's computers

Spock: [stilted language that he was "illogical" to dump Nyota]
Nyota: If that's an apology, I accept.

(My friend Michael wants me to add: and then they find out the new Enterprise is too big to fit in the passage from the construction dock to space)

Here ends season 3

[permalink]

Installing and testing jessie-backports realtime kernels from debian archive

TL;DR

How to use backports

First, find the kernels (or other packages) in the search interface at snapshot.debian.org. In the case of jessie-backports, look for versions that say ".bpo" or ".bpo8".

I found 3 realtime kernels that seemed interesting, based on 4.1, 4.4, and 4.6, so I came up with these lines for a file in /etc/apt/sources.list.d:

# Kernel 4.1
deb   http://snapshot.debian.org/archive/debian/20150911T214227Z jessie-backports main
deb-src   http://snapshot.debian.org/archive/debian/20150911T214227Z jessie-backports main

# Kernel 4.4
deb http://snapshot.debian.org/archive/debian/20160328T221517Z/ jessie-backports main
deb-src http://snapshot.debian.org/archive/debian/20160328T221517Z/ jessie-backports main

# Kernel 4.6
deb http://snapshot.debian.org/archive/debian/20160620T042742Z jessie-backports main
deb-src http://snapshot.debian.org/archive/debian/20160620T042742Z jessie-backports main

Then, update without checking whether the packages are out of date:

sudo apt-get  -o Acquire::Check-Valid-Until=false  update

and request that the packages get installed, e.g., for 4.6:

sudo apt-get install -t jessie-backports  linux-image-4.6.0-0.bpo.1-rt-amd64 linux-headers-4.6.0-0.bpo.1-rt-amd64

(you can omit -headers if you don't use any nonstandard kernel modules)

Now you have to remove or comment out the backports lines, because otherwise subsequent apt-get updates without special flags will (rightfully) error right out:

E: Release file for http://snapshot.debian.org/archive/debian/20150911T214227Z/dists/jessie-backports/InRelease is expired (invalid since 279d 3h 56min 3s). Updates for this repository will not be applied.

Latency results

Kernel 4.1 (4.1.0-0.bpo.2-rt-amd64)

linuxcnc latency-histogram --nobase: 11.5us max latency in 3 minutes

Kernel 4.4 (4.4.0-trunk-rt-amd64)

nvidia X driver loaded. This may harm realtime results.

linuxcnc latency-histogram --nobase: 135.2us max latency in 2 minutes

(this is perfectly adquate latency for mesa hardware, by the way!)

Kernel 4.6 (4.6.0-0.bpo.1-rt-amd64)

linuxcnc latency-histogram --nobase: 126us max latency in 11 hours

nvidia kernel driver temporarily blacklisted.

linuxcnc latency-histogram --nobase: 9.4us max latency in 2 minutes

(note to self: why does the size and layout of the latency window change when my desktop resolution changes?)

[permalink]

Saturday Software Project: VIC 20 Incremental Game

linuxcnc: Getting to the compile errors on freebsd

Capital Laundry Services document leak

Bye Bye Netflix (blacklisting he.net ipv6)

New Desktop 2016

Literal copying of GPL code into ZFS on Linux

Ancho Reyes Hot Chocolate

Coolest C Preprocessor Trick of the Year