One of my favorite authors is Greg Egan, and that's in great part because of how in many stories he starts with known physics, adds a twist, and follows it to its logical conclusion within the story's setting.
A particular idea he's used a few times is the idea that portions of the universe could potentially contain "time-reversed" regions. From our point of view, for instance, a time-reversed star absorbs photons, and if we could observe biological phenomena they would likewise go in reverse. (See e.g., the short story The Hundred Light-Year Diary)
From our point of view, the universe began billions of years ago with the big bang, and as far as I know all present observations are compatible with zero or negative curvature. This apparently gives an infinite amount of time to come in the future, though only a finite portion of that future can support baryonic life like ours.
So what does cosmology look like for the time-reversed universe, and what are their "big problems"? I don't have enough background in basic physics and cosmology to give a really good answer to this question, but here are some things that occur to me:
- How to reconcile the apparent flatness of the universe with the observed cosmic blue-shift
- If the universe has an infinite past, and the baryonic era has been going on for at least 1036 years, why are there no other observable civlizations?
- Were natural laws different in the distant past? Why and when did baryogenesis occur, given that in the present day the creation rate of protons is so small as to be unmeasurable? Ultra-low energy / density physics will presumably be an area of great interest in understanding the origins of the universe.
- At the same time, high energy physics will be of interest in understanding the fate of the universe. Scientists learn that in the high-energy future, the laws of physics themselves break down ("unify" in our terminology).
- Some models will predict a "deflation" process that begins when a certain mass/energy density is reached, rapidly collapsing the observable universe and obviously destroying all intelligent life in the process. Unfortunately, the models will be unable to predict the specific energy density.
- I'm not sure what the time-reversed CMB looks like. A white-hot wall that indicates "deflation" is already going on in the distant parts of the universe, an approaching wavefront that clearly dooms all intelligent species?
- What, if anything, happens after the great singularity at the end of time?
I reviewed this entry-level 3D printer soon after I got it. Now I've been using it for nearly two months and over 100 prints and I wanted to post some updates. I do continue to feel that this is a good printer for me, and for anyone who would like to start 3D printing without spending much money and without building a machine from parts. (on the other hand, you do have to endure the learning curve that comes with modeling and slicing software on your PC, which I was interested to do)
The printer continues to give me very usable results in PLA, some adequate results (but with lots of stringing) in PETG, and useless results in ABS. I've been doing PLA on painter's tape and a cold bed; PETG on painter's tape with gluestick and 75C bed. First layer adhesion is just fine, removal is sometimes finicky.
The original hot end continues to work, though I did have one pretty close call when the old filament broke during a filament change, leaving the old filament stuck in the hot end, unwilling to move forward or back. Ultimately, I disassembled the hot end so that the heat break was not in the heatsink, then heated the heatbreak+nozzle assembly to 250C from the front panel. As soon as it was possible to do so, I pushed the filament through using an allen wrench of the right cross-section. After this, I experienced more minor jams during my next few filament changes; I think there is some remaining filament melted to the inside of the heat break further up than it ought to be. But it does continue working, extruding properly.
(I've tried using the atomic method to clean it up inside, but I just can't find that sweet spot where the PLA is pullable but not too melted)
On the software side, I am getting more comfortable with Cura and OpenSCAD and I've been able to contribute a few designs to thingiverse, a few remixes but mostly original items. The firmware of the machine itself is adequate, though you do have to get used to a few quirks. The main quirk occurs when you want to print again immediately: Cura writes out an ending sequence like: Turn off heaters, wait 5 minutes, turn off fan. After "turn off heaters", the front panel UI acts like the part is done and returns to the main screen. But if you actually try to print something again immediately, the 5 minute wait is still going on and doesn't seem possible to cancel. At this point, it's easiest to just power-cycle the printer. (But it's good enough that I don't care to spend weeks figuring out how to replace the control's firmware with a proper, source-available firmware, or replace the whole control with linuxcnc, despite the superficial feasibility of either option)
As far as modifying the printer itself, I haven't done (or had to do) much. The fan sounds pretty bad, and sometimes the whole machine rattles pretty loudly when moving; I probably could do something about this by either making sure all the screws are well-tightened and/or trying some of the vibration-reducing designs on Thingiverse. I haven't had to change anything about the wiring or electronics; overheating is not a problem in my 20C house (but just wait for summer..). I did print a little "filament guide nut" that goes at the entry to the bowden tube, and a spinner for the extruder just so I can see at a glance that it's working properly, but that's just about it.
This year our mileage was higher primarily due to taking a ~1000 mile road trip in western Nebraska and Colorado. Ingrid also started driving the Prius more and her own (now sold) car less on evenings and weekends.
Just like I wrote in 2015, I believe main thing lowering the fuel economy is short winter drives. My drive to and from work is just 2.5 miles per direction, and I often drive a similar distance to and from lunch. In winter, that's too little distance for the car to warm up to the point that it enters the fuel-saving EV mode while stopped at lights.
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
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)
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:
# 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"
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.
Update, 2017/3: A little bird has told me that the machinekit images use these scripts to build their OS images, but the kernel source remains elusive. It looks like they come from http://repos.rcn-ee.com/debian but while there are debian source packages for e.g., lxqt-sudo there aren't for e.g., linux-image-3.8.13-xenomai-r76.
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.
All older entries
Website Copyright © 2004-2014 Jeff Epler