We can make our 3D-printed parts even more capable when we start mixing them with some essential “mechanical vitamins.” By combining prints with screws, nuts, fasteners, and pins, we get a rich ecosystem for mechanism-making with capabilities beyond what we could simply print alone.
Today I’d like to share some tips on one of my favorite functional 3D-printing techniques: adding heat-set inserts. As someone who’s been installing them into plastic parts for years manually, I think many guides overlook some process details crucial to getting consistent results.
Make no mistake; there are a handful of insert guides already out there [1, 2]. (In fact, I encourage you to look there first for a good jump-start.) Over the years though, I’ve added my own finishing move (nothing exotic or difficult) which I call the Plate-Press Technique that gives me a major boost in consistency.
Join me below as I fill in the knowledge gaps (and some literal ones too) to send you back to the lab equipped with a technique that will give you perfectly-seated inserts every time.
In the middle of the East Coast’s slow broil in the summer of 2018, a curious phenomenon surfaced. As a tropical air mass settled in and smothered the metropolitan New York area, a certain breed of stock speculator began feeling the financial heat as the microwave signals linking together various data centers and exchanges began to slow down. These high-frequency traders rely on getting information a fraction of a second before other traders see the same thing and take advantage of minuscule price differences to make money hand over fist.
While you won’t catch us shedding many tears over the billions these speculators lost during the hot spell, we did find the fact that humidity can slow microwave propagation enough to make this a problem for them a fascinating subject, enough so that we covered it in some detail at the time. While financial markets come and go and the technology to capitalize them changes at a breakneck pace, physics stays the same, and it can make or break deals with no regard to the so-called fundamentals.
So it was with great interest that we happened upon Tom Scott’s recent video outlining how one new stock exchange is using physics to actually slow down stock trades, in an attempt to gain a competitive advantage over the other exchanges. In light of the billions lost over the summer to propagation delays amounting to a mere 10 microseconds, we couldn’t help but wonder how injecting a delay 35 times longer using a “magic shoebox” was actually good for business. It turns out to be an interesting story.
For all the advances in medical diagnostics made over the last two centuries of modern medicine, from the ability to peer deep inside the body with the help of superconducting magnets to harnessing the power of molecular biology, it seems strange that the enduring symbol of the medical profession is something as simple as the stethoscope. Hardly a medical examination goes by without the frigid kiss of a stethoscope against one’s chest, while we search the practitioner’s face for a telltale frown revealing something wrong from deep inside us.
The stethoscope has changed little since its invention and yet remains a valuable if problematic diagnostic tool. Efforts have been made to solve these problems over the years, but only with relatively recent advances in digital signal processing (DSP), microelectromechanical systems (MEMS), and artificial intelligence has any real progress been made. This leaves so-called smart stethoscopes poised to make a real difference in diagnostics, especially in the developing world and under austere or emergency situations.
Representatives from SpaceX, Blue Origin, and United Launch Alliance participated in a forum last week held by NASA to determine the future of humans on the moon. This isn’t just how they will live, how long they will stay, or what they will do; no, this is far more interesting: this was how humans will travel from lunar orbit from the surface of the moon. The future of the next generation of lunar lander is being determined right now.
The plan right now is entirely unlike Apollo, which sent a pair of spaceships in orbit around the moon, sent one to the surface, then returned to the mother ship for the trip back to Earth. Instead of something somewhat simple, the next era of lunar exploration will happen from a gateway orbiting in cis-lunar space. What makes this so amazing is how weird the orbit is, and the reasons behind it.
Our digital world is so much more interactive than the paper one it has been replacing. That becomes very obvious in the features of Jupyter Notebooks. The point is to make your data beautiful, organized, interactive, and shareable. And you can do all of this with just a bit of simple coding.
We already leveraged computer power by moving from paper spreadsheets to digital spreadsheets, but they are limited. One thing I’ve seen over and over again — and occasionally been guilty of myself — is spreadsheet abuse. That is, using a spreadsheet program to do something I probably ought to write a program to do. For those times that you want something quick but want something more than a spreadsheet, you should check out Jupyter Notebooks. The system is most commonly associated with Python, but it isn’t Python-specific. There are over 100 languages supported — many community-developed. You can even install a C++ interpreter backend for it. Because of the client/server architecture, it is very simple to share notebooks with other users.
You can — in theory — use Jupyter for anything you could use Python for. In practice, it seems to get a lot of workout with people analyzing large data sets, doing machine learning, and similar tasks.
The Good: Simple, Powerful, Extensible
The idea is simple. Think of a Markdown-enabled web page that can connect to a backend (a kernel, in Jupyter-speak). The backend can run on your machine or remotely and will support some kind of language — often Python. The document has cells that line up vertically (like a single wide spreadsheet column). For example, here’s a simple notebook I created to explain how a bunch of sine waves add up to a square wave:
It’s no secret that I rather enjoy connecting things to the Internet for fun and profit. One of the tricks I’ve learned along the way is to spin up simple APIs that can be used when prototyping a project. It’s easy to do, and simple to understand so I’m happy to share what has worked for me, using Web2Py as the example (with guest appearances from ESP8266 and NodeMCU).
Barring the times I’m just being silly, there are two reasons I might do this. Most commonly I’ll need to collect data from a device, typically to be stored for later analysis but occasionally to trigger some action on a server in the cloud. Less commonly, I’ll need a device to change its behavior based on instructions received via the Internet.
Etherscan is an example of an API that saves me a lot of work, letting me pull data from Ethereum using a variety of devices.
In the former case, my first option has always been to use IoT frameworks like Thingsboard or Ubidots to receive and display data. They have the advantage of being easy to use, and have rich features. They can even react to data and send instruction back to devices. In the latter case, I usually find myself using an application programming interface (API) – some service open on the Internet that my device can easily request data from, for example the weather, blockchain transactions, or new email notifications.
Occasionally, I end up with a type of data that requires processing or is not well structured for storage on these services, or else I need a device to request data that is private or that no one is presently offering. Most commonly, I need to change some parameter in a few connected devices without the trouble of finding them, opening all the cases, and reprogramming them all.
At these times it’s useful to be able to build simple, short-lived services that fill in these gaps during prototyping. Far from being a secure or consumer-ready product, we just need something we can try out to see if an idea is worth developing further. There are many valid ways to do this, but my first choice is Web2Py, a relatively easy to use open-source framework for developing web applications in Python. It supports both Python 2.7 and 3.0, although we’ll be using Python 3 today.
At the turn of the 21st century, it became pretty clear that even our cars wouldn’t escape the Digital Revolution. Years before anyone even uttered the term “smartphone”, it seemed obvious that automobiles would not only become increasingly computer-laden, but they’d need a way to communicate with each other and the world around them. After all, the potential gains would be enormous. Imagine if all the cars on the road could tell what their peers were doing?
Forget about rear-end collisions; a car slamming on the brakes would broadcast its intention to stop and trigger a response in the vehicle behind it before the human occupants even realized what was happening. On the highway, vehicles could synchronize their cruise control systems, creating “flocks” of cars that moved in unison and maintained a safe distance from each other. You’d never need to stop to pay a toll, as your vehicle’s computer would communicate with the toll booth and deduct the money directly from your bank account. All of this, and more, would one day be possible. But only if a special low-latency vehicle to vehicle communication protocol could be developed, and only if it was mandated that all new cars integrate the technology.
Except of course, that never happened. While modern cars are brimming with sensors and computing power just as predicted, they operate in isolation from the other vehicles on the road. Despite this, a well-equipped car rolling off the lot today is capable of all the tricks promised to us by car magazines circa 1998, and some that even the most breathless of publications would have considered too fantastic to publish. Faced with the challenge of building increasingly “smart” vehicles, manufacturers developed their own individual approaches that don’t rely on an omnipresent vehicle to vehicle communication network. The automotive industry has embraced technology like radar, LiDAR, and computer vision, things which back in the 1990s would have been tantamount to saying cars in the future would avoid traffic jams by simply flying over them.
In light of all these advancements, you might be surprised to find that the seemingly antiquated concept of vehicle to vehicle communication originally proposed decades ago hasn’t gone the way of the cassette tape. There’s still a push to implement Dedicated Short-Range Communications (DSRC), a WiFi-derived protocol designed specifically for automotive applications which at this point has been a work in progress for over 20 years. Supporters believe DSRC still holds promise for reducing accidents, but opponents believe it’s a technology which has been superseded by more capable systems. To complicate matters, a valuable section of the radio spectrum reserved for DSRC by the Federal Communications Commission all the way back in 1999 still remains all but unused. So what exactly does DSRC offer, and do we really still need it as we approach the era of “self-driving” cars?
