If you cut your teeth on Z-80 assembly and have dabbled in other assembly languages, you might not find much mystery in creating programs using the next best thing to machine code. However, if you have only used high level languages, assembly can be somewhat daunting. [Shikaan] has an introductory article aimed to get you started at the “hello world” level of x86-64 assembly language. The second part is already up, too, and covers control structures.
You can argue that you may not need to know assembly language these days, and we’ll admit it’s certainly not as important as it used to be. However, there are unusual cases where you really need either the performance or the small footprint, which is only possible in assembly language. What’s more, it is super useful to be able to read assembly from your high-level tools when something goes wrong.
Of course, one of the problems is that each assembly language is different. For example, knowing that the x86 assembly doesn’t completely transfer to ARM instructions. However, in most cases, the general concepts apply, and it is usually fairly easy to learn your second, third, or fourth instruction set.
As we get older, our eyes get worse. That’s just a fact of life. It is a rite of passage the first time you leave the eye doctor with a script for “progressive” lenses which are just fancy bifocals. However, a new high-tech version of bifocals promises you better vision, but with a slight drawback, as [Sherri L. Smith] found.
Remember how users of Google Glass earned the nickname “glassholes?” Well, these new bifocals make Google Glass look like a fashion statement. If you are too young to need them, bifocals account for the fact that your eyes need different kinds of help when you look close up (like soldering) or far away (like at an antenna up on a roof). A true bifocal has two lenses and you quickly learn to look down at anything close up and up to see things far away. Progressives work the same, but they transition between the two settings instead of having a discrete mini lens at the bottom.
The new glasses, the ViXion01 change based on what you are looking for. They measure range and adjust accordingly. For $555, or a monthly rental, you can wear what looks like a prototype for a Star Trek visor and let it deduce what you are looking at and change its lenses accordingly.
Of course, this takes batteries that last about ten hours. It also requires medical approval to be real glasses and it doesn’t have that, yet. Honestly, if they worked well and didn’t look so dorky, the real use case might be allowing your eye doctor to immediately download a new setting as your vision changes. How about you? How much odd headgear are you willing to wear in public and why?
If you want to smooth out the top surface of your FDM 3D prints, you can try ironing. Many slicers allow you to set this option, which drags the hot printhead through the top surface with a tiny bit of plastic to smooth out the extrusion lines. However, a recent paper explains how non-planar ironing can provide a better result.
Usually, non-planar printing requires rotating the print bed in addition to the normal linear motion. However, you can also manipulate the layer height in real time to create bulges in the 3D print. This is the approach taken by Curvislicer, which shares authors with this paper. Another approach is to build a part conventionally but add non-planar printing to the last few layers.
The non-planar ironing is a variation of the latter technique. After slicing, the top layer of g-code passes through a Python script. The results on a test object look very impressive. We’d be interested to see how some more complex shapes look, though.
Of course, it looks like all you need is an ordinary printer, a modified copy of Slic3r, and the script, so if you try it yourself, let us know what you think. It would be great to smooth prints without extra chemicals and post-processing. While you can get good results, it is a lot of work.
[Mikrowave1] wanted to build an authentic 1930s-style ham radio station that was portable. He’s already done a regenerative receiver, but now he’s starting on a tube transmitter that runs on batteries. He’s settled on a popular design for the time, a Jones push-pull transmitter. Despite the tubes, it will only put out a few watts, which is probably good for the batteries which, at the time, wouldn’t have been like modern batteries. You can see the kickoff video below.
According to the video, these kinds of radios were popular with expeditions to exotic parts of the world. He takes a nostalgic look back at some of the radios and antennas used in some of those expeditions.
The Jones oscillator originates with [Frank Jones, W6AJF] and was quite popular in the day, as he was well-known in ham radio circles then. Normally, these took a dual triode and a crystal along with some passive components. In this case, though, the transmitter will use two type 30 tubes. If you missed the series on the receiver, that’ll give you something to watch while you wait for the next installment on the transmitter.
Automated musical instruments aren’t a new idea. From water chimes to player pianos, they’ve been around for a while. But we can’t remember the last time we saw a player ukulele. [Zeroshot] shows us one, though, and it uses an Arduino. You can see and hear it in the video below.
Honestly, with all the stepper motors, linear rails, and belts, we thought it looked like a 3D printer, at least up at the business end. [Zeroshot] thought it would be easier to build a robot than to actually learn to play the instrument. We aren’t sure we agree.
The first problem was automating both picking strings and strumming. Then, you needed a way to press down on the strings at each fret. Solenoids can act like your fingers. With the mechanics in place, it is all software, right? There were quite a few unexpected little hardware wrinkles.
The solenoids don’t move along the fretboard, so it limits the range a bit. Also, the mechanical noises sometimes seem to drown out the instrument, but it does work. Kind of. We don’t think we are going to see AI buskers anytime soon.
Don’t have a ukulele? Do you have a GameBoy? If you are building an automated ukulele, you might as well add LEDs.
There was a time when building a telescope was a rite of passage for budding astronomers, much as building a radio was the coming age for electronics folks. These days, many things are cheaper to buy than build, even though we do enjoy building anything we can. Orion was a big name in telescopes for many years. Their parent company also owned Meade and Coronado, both well-known optical brands. A recent video from [Reflactor] brought it to our attention that Orion abruptly ceased operations on July 9th.
We always hate to hear when well-known brands that serve a big part of our community vanish. According to [Reflactor], people who have telescopes with the company for repair are likely to never see them again. [Dylan O’Donnell] also had a video about it (see below), and, as he notes, at that time, the website was still operating, but it’s gone now. To add further fuel to the fire Sky & Telescope ran an article on July 12th saying that Meade was also on the chopping block, although at the time of this writing, their site is still online.
You have to wonder what problems you might have selling telescopes today. Many people live where there is light pollution. We’d like to think there are still people who want to ponder the universe from their backyard, though.
There are still people selling telescopes, so presumably, one of them — maybe Celestron — will take up the slack. Or maybe we’ll see a resurgence in telescope homebrewing.
It is hard to imagine what a mainframe or supercomputer can do when we all have what amounts to supercomputers on our desks. But if you look at something like IBM’s mainframe Telum chip, you’ll get some ideas. The Telum II has “only” eight cores, but they run at 5.5 GHz. Unimpressed? It also has 360 MB of on-chip cache and I/O and AI accelerators. A mainframe might use 32 of these chips, by the way.
[Clamchowder] explains in the post how the cache has a unique architecture. There are actually ten 36 MB L2 caches on the chip. There are eight caches, one for each core, plus one for the I/O accelerator, and another one that is uncommitted.
A typical CPU will have a shared L3 cache, but with so much L2 cache, IBM went a different direction. As [Clamchowder] explains, the chip reuses the L2 capacity to form a virtual L3 cache. Each cache has a saturation metric and when one cache gets full, some of its data goes to a less saturated cache block.
Remember the uncommitted cache block? It always has the lowest saturation metric so, typically, unless the same data happens to be in another cache, it gets moved to the spare block.
There’s more to it than that — read the original post for more details. You’ll even read speculation about how IBM managed a virtual L4 cache, across CPUs.
[Michelle Hampson] reports in IEEE Spectrum that Chinese researchers may improve self-driving cars by mimicking how the human eye works. In some autonomous cars, two cameras use polarizing filters to help understand details about what the car sees. However, these filters can penalize the car’s vision in low light conditions.
Humans, however, have excellent vision in low-lighting conditions. The Retinex theory (based on the Land Effect discovered by [Edwin Land]) attributes this to the fact that our eyes sense both the reflectance and the illumination of light. The new approach processes polarized light from the car’s cameras in the same way.
The images pass through two algorithms. One compensates for brightness levels, while the other processes the reflective properties of the incoming light. They mounted cameras on real cars and drove them in actual dim environments to test everything out.
The result? Studies show that the approach improved driving accuracy by approximately 10%. However, the algorithms require extensive training on difficult-to-obtain data sets, so that is one challenge to adoption.
Self-driving cars certainly need improving. Oddly enough, navigation can be done with polarizing filter cameras and a clear view of the sky. Or, you can look under the road.
[MIKROWAVE1] claims he’s not a radio repair guy, but he agreed to look at a malfunctioning Hallicrafters S-120 shortwave receiver. He lets us watch as he tries to get it in shape in the video below. You’ll see that one of his subscribers had done a great job restoring the radio, but it just didn’t work well.
Everything looked great including the restored parts, so it was a mystery why things wouldn’t work. However, every voltage measured was about 20V too low. Turns out that the series fuse resistor had changed value and was dropping too much voltage.
That was an easy fix and got three of the radio’s four bands working. The fourth band had some problems. Fixing some grounding helped, but the converter tube was weak and a new replacement made it work much better.
There were some other minor issues, but in the end, the radio was back to its original glory. We have to warn you that restoring old radios can be addictive. The good news is, thanks to the Internet, you don’t have to figure it all out yourself or find a local expert who will take an apprentice. Hallicrafters was a huge name in the radio business after World War II, and, for that matter, during the war, too.
It is common these days to have a soldering iron where you can set the temperature using some sort of digital control. But how accurate is it? Probably pretty accurate, but [TheHWCave] picked up a vintage instrument on eBay that was made to read soldering iron temperature. You can see the video below, which includes an underwhelming teardown.
The device is a J thermocouple and a decidedly vintage analog meter. What’s inside? Nearly nothing. So why did the meter not read correctly? And where is the cold junction compensation?
The probe seemed okay when used with a modern meter. However, driving the meter directly showed a problem. It seemed like something was wrong with the meter’s movement.
Pulling the meter out revealed a handwritten label identifying the meter as having a full-scale deflection of just over 27 millivolts and using a 0.5 ohm external resistor. Unsurprisingly, the old meter had some issues with the thermocouple.
Pulling the meter showed that the compensation was actually inside the meter casing. The meter’s problem was due to these extra components: an NTC thermistor and a custom wire-wound resistor. Changing the resistor fixed the box. This time, he put the two components outside the meter housing in the vast space of the nearly empty case.
Today, we take measuring temperature for granted. Only the cheapest meters lack temperture measurement and you can use other techniques like IR sensors, too. But this was an interesting look at how it was done “back in the day” and an interesting repair, too.
Thermocouples are an old standby for measuring high temperatures. With modern tech, it is pretty simple to compensate them.
While version control used to be reserved for big corporate projects, it is very mainstream these days. You can attribute much of that to Git, the software that has nearly displaced other version control. Git works well, it is versatile, and it scales well. It is easy to use as an individual developer or as part of a worldwide team. But Git is also one of those things that people don’t always study, they just sort of “pick it up” as they go. That motivated [Glasskube] to create “The Guide to Git I Never Had.”
If you are ready to click away because you are not a software person, hang on. Git is actually useful for many different kinds of data, and there are a number of hardware projects that use Git in some form. That’s especially true if the project has some code associated with it, but there are projects that consist of PCBs, reverse engineering documentation, or schematics.
Simplistically, Git tracks a bunch of files and lets you rewind in time to answer the question: what did this look like a month ago? Or a year ago? However, the real power lies in producing and merging branches.
For example, you might be working on a product and decided to add feature “A.” Meanwhile, your partner decides to work on feature “B.” No problem. You can each work in your own separate branch and get everything working. You don’t even have to be connected to a server until the very end.
When either of you are ready, you can merge your branch with the main branch. Often, this can be done automatically, but Git knows when it is in over its head and will ask for help. When you are both done merging, both of your changes are “live.” If you do it right, Git can also help answer the question: why did we make that change two years ago? It is surprising how often that’s important.
When you think of Sony, you probably think of a technology company that’s been around forever. However, as [Asianometry] points out, it really formed in the tough years after World War II. The two people behind the company’s formation were an interesting pair. One of them was a visionary engineer and one was a consummate businessman.
While it is hard to imagine today, securing a license to produce transistors was difficult in the early days. What’s worse is, even with the license, it was not feasible to use the crude devices in a radio.
The devices were poor by today’s standards, and while transistors would work at audio frequencies for hearing aids, getting them to work at AM radio frequencies was a challenge. The Sony founders had to decide whether to use alloy transistors or grown crystal transistors.
Western Electric did not want to share its crystal-growing technology, so in 1954, the team created an alloy transistor. However, it failed to work well at radio frequencies, so they shifted to growing crystals, which seemed more amenable to scaling. One of the team tried using phosphorous and indium doping and created a transistor that could work at higher frequencies. But there was a problem.
Despite the transistor’s superior performance, they couldn’t make another one. Common wisdom at the time was that phosphorus doping was a dead end, but it had worked once. It just took time to find the right way to do it. By 1955, they produced usable transistors, even though the yield was at around 5%.
Texas Instruments beat them to market with a transistor radio, the Regency TR-1, in 1954, but in 1955, they produced the TR-55. Of the five transistors inside, some were alloyed transistors, and some were grown crystals. The factory had to hand-select crystal transistors to make each unit work. The radios were on sale for about 19,000 yen (the TR-1 cost about 50 bucks; recall that in 1954, that was nearly $600 in today’s money). Adjusting for inflation, in today’s money, a Japanese teenager would shell out about $850 for the TR-55.
The TR-55 wasn’t the first Sony radio to have transistors. The TR-52 was a prototype, but it had case problems and never made it into the hands of the public. The radio didn’t make it to the United States until 1957. By then, Texas Instruments, Raytheon, and GE all had radios available, too.
It is a fascinating look into the history of an iconic electronics brand and a window into another world that, honestly, wasn’t that long ago. We couldn’t help but note similarities with Apple, who also had a businessman and engineer combination. Sony would go on to innovate in a number of areas, including optical data storage.
[Peter Demchenko] wanted to use a low power TS555 in an ESR meter design. The problem is, he needed to handle significant current sink requirements for cases where the capacitor under test had a low ESR. The TS555 wasn’t up to the task.
However, [Peter] made an interesting observation. the output pin of the device can sink or source current. However, the discharge pin is exactly the same output but can only sink current.
But what if you tied them together? Using some equalizing resistors, that’s exactly what he did, and this roughly doubles the rated current sink capability. According to [Peter], you do make the circuit more sensitive to power supply variations, but that could be an acceptable trade, depending on your application.
The meter schematic confused us for a moment because the R3 and R4 designations are corrupted. Both the equalizing resistors, it appears, are 110 ohms. The schematic legend should read “R3 110” not “3 110.” The same for R4 which appears as “4 110.”
Last time I tried to convince you that, if you haven’t already, you should try running your 3D printer with Klipper. There are several ways to actually make it work.
The first thing you need is something to run the Klipper host. Most people use a Raspberry Pi and if you already have one that runs OctoPrint, for example, you might well use it. Just tuck your SD card away in case you give up and install a fresh Linux system on a new card.
The Creality Sonic Pad has issues, but it does work.
However, a Pi isn’t your only option. You should be able to make it work on nearly anything that runs Linux. We’ve even seen it running on Windows under WSL. If you have an old laptop that can run Linux, that would work, too. We’ve even heard it works on a Chromebook.
The other option is to get a “pad.” Several vendors make touchscreens with some Linux single-board computer bundled together with Klipper preinstalled. For example, there is the Creality Sonic Pad, along with similar devices from other 3D printing companies.
If you decide to go that route, you might want to make sure it is easy to install your own software easily. Some pads, like the Creality unit, are notorious for having so much customization that they don’t lend themselves to upgrades unless they come from the manufacturer. In some cases, you can wipe out the stock firmware and install a normal operating system, but at that point, you could probably just buy a Pi and a touchscreen, right?
Installation
If you use something like a pad, it probably has a menu option to provide prebuilt firmware for your printer. Typically, you let it save the code to an SD card or a USB stick and then you are expected to flash it to your printer which, of course, depends on what kind of printer you have.
If you are rolling your own, you use a menu configuration program something like building a Linux kernel. If you have a pre-built configuration file, it will probably tell you in its comments what things you should pick. You need to know, for example, the type of CPU your board has, the bootloader offset, and if you are connecting via USB or serial. You can find details on the Klipper project pages.
KIAUH makes installing Klipper and supporting programs painless.
Installing the Linux side is easy because there is a nice script called KIHUH. The easiest thing to do is clone the Git repository and run it. From there, you can install Klipper, Moonraker, Fluidd, Mainsail, and some other things, too.
The real trick isn’t installing the software. The challenge is creating a proper configuration file for your printer. If you have a totally stock and popular printer, you’ll probably be in luck. But, how many of us can say that?
Start with the GitHub list to see if your printer or board is there. Even if it isn’t an exact match for your hardware, it will give you a start. For example, my custom printer is a Fysetc Spider, but the canned configuration is for a core XY machine, which means I have to make changes.
Even if you get a pad that claims to be “plug and play,” don’t count on it. For example, a Creality Sonic Pad’s instructions for installing with a Creality Ender 3 first asks you to take the printer apart to determine the type of motherboard you have. That’s not really plug and play! Any deviation from the stock machine is likely to require you to change the default profile.
Ch…Ch…Ch…Changes
In addition to just setting things up to match my exact hardware, I also needed to adjust the extruder step count. That has to be simple, right? Most firmware requires you to plug in the number of steps per millimeter of filament.
Klipper, on the other hand, wants to know how many millimeters extrude from a full rotation of the stepper. If you know how many steps (and microsteps) your printer uses, you can easily calculate either number from the other. For example, if you have 200 steps per rotation and 16 microsteps, that’s 3200 steps total. If your current steps per millimeter is 100, then your Klipper “rotation distance” is 3200/100=32.
Configuration Example
I had another major change to make. My printers have a non-standard filament sensor that detects the filament moving. That way, it can detect not only broken filaments but jammed filaments, too.
To install it, I had to add a few lines to my printer.cfg file and restart Klipper. Since I have more than one printer with the same sensor, I put all the lines in a single file and then included it in each printer. So the printer.cfg change was very simple:
This defines a few macros you can use elsewhere. Like Python, the indentation matters. You can organize your files using [include], and that’s especially useful if you have multiple printers that can share files.
Reference
So, how do you know what’s available? The Klipper reference. It will show you all the configuration sections you can use and what can possibly go in them. Don’t forget that some features — like print status notifications — will be in the Moonraker configuration which is a separate document.
Since the system is in Python, you can hack on it to your heart’s content. Just back up first. For example, you can add some custom Python scripts in the klipper/extras directory, like the one that can run arbitrary system commands from G-code.
Tinkering is what most of us like the best, and there’s plenty of opportunity to tinker with here. Klipper is also a good way to put new life in a very old printer since what runs on the printer is very simple, and all the heavy lifting is done elsewhere.
Klipper can easily do adaptive bed leveling, for example. If you can work in Python, it is also easy to experiment with things like exotic sensors.
While classroom learning isn’t for everyone, one awesome benefit of the Internet is that you have a variety of college classes available to you, even if they aren’t for credit. You can virtually audit classes from institutions around the world on just about any topic you can think of. Of course, the topic we think of is practical electronics and that happens to be the title of a class from [Dr. Bill Newhall] of the University of Colorado. You can watch the first part in the video below. So far, there are two lectures available but more are coming as the class is ongoing right now.
[Dr. Newhall] is one of us. He’s a ham radio operator and a pilot, as well as an electrical engineer. This class is aimed at others who need to understand electronics in another context. It reminded us of the genesis of one of our favorite books — also from a professor — The Art of Electronics.
The course material promises to cover topics ranging from solar and battery power sources, power conversions, IoT and RF communications, sensors, and DC motor control. Of course, there will also be sections on microcontrollers and associated hardware.
Just like a real class, the first lecture has a lot of housekeeping information, but you might want to skim it anyway. But if you want to get to the electronics, the second video won’t disappoint. While it covers a lot of ground that is probably familiar to most Hackaday readers, it is a good review and there’s more coming in the future lectures.
I have several 3D printers, and I’ve always been satisfied with using either Repetier or Marlin on all of them. There are a few other firmware versions that could run on my hardware, but those two have been all I’ve needed. Sure, it was painful for a while having to juggle features to fit the firmware image onto the smaller microcontroller boards. Now that Marlin supports big 32-bit boards however, that hasn’t been a problem. But recently, I’ve been on a program to switch everything to Klipper.
In this post, I’ll tell you why I did it and give you some data about why you might consider it, too.
The Landscape
Marlin is written in C and burned into a 3D printer’s flash memory. It does a lot. It receives G-code commands, interprets them, and translates them to meaningful actions on the hardware. Modern versions handle automatic transformations to account for lumpy beds, input shaping to reduce shaking, and linear advance to produce better prints.
It might seem simple to control a 3D printer, but there are lots of little details to take into account. For example, if you are moving the head between two XY coordinates and you expect a certain flow rate, then you have to figure out how fast to turn the steppers to get the right amount of plastic out over that time. You also may have to retract before you start a move, make sure temperatures are stable, and transform the actual coordinates based on bed leveling data. There’s a lot going on.
Klipper does the exact same job, but it does it differently. On the 3D printer board is a tiny piece of software that does very little. It’s a bit like a device driver for the printer. All by itself, it does nothing. But it can handle very basic commands that describe how to move the machine.
All the rest of the processing you expect to happen now runs on some Linux computer. That is very often a Raspberry Pi, but it could be a spare laptop, your desktop computer, or anything that will run a reasonable Linux install. Several vendors even sell single-board computers with touchscreens made specifically for running this part of Klipper.
However, even though a screen is nice, you don’t really need it. I’ll talk about that more later.
The Problem
Historically, Klipper was a way to break out of the limitations of using tiny 8-bit controller boards with limited memory. These days, you can get plenty of powerful 3D printer controller boards, so that isn’t as much of an issue as it used to be.
Instead, I have another problem. The build. One of my printers is a custom printer that doesn’t really match any other printer in the world. So, I have to build my own version of Marlin. That’s actually not very hard to do. However, there are two things that are very annoying. First, you have to flash the firmware. The printer uses DFU, and I have brought out the “bootload” switch, but it is still a pain, and I possibly will brick the printer if I make a mistake. A recoverable brick, but still.
But the real problem is keeping my version of Marlin up to date with the official version. The version I have running now is old enough to not have some of the cool features, so I would have to merge the mainline in with my fork. Can it be done? Of course. But it’s awkward, and the longer you wait, the worse it gets.
For a recent 3D printing class I sometimes teach, I picked up two cheap printers that had great support for Klipper, so they were my guinea pigs before I attempted to switch over to the custom printer.
I should note that Klipper, I think, appeals to people who like tweaking settings and editing configuration files. Since you’re reading Hackaday, there’s a good chance that describes you. But if you despise opening a Bash shell and entering text, you might think about avoiding Klipper. While the UIs do a good job of protecting you from most of this, there’s going to be times when you’ll need to get your hands dirty.
Is Klipper the Solution?
You do have to flash a small program over to your board to run Klipper, but once you do it, you very likely will never do it again. If you are dissatisfied, you can flash Marlin back and there’s no harm done. Just make sure you can get your hands on a stock firmware image for your printer before you start making any changes. In my case, I do have the ability to go back to Marlin if I ever wanted to. But at this point, the only reason I’d make the switch back was if I planned on selling the machine to a beginner.
After that one flash, all the other setups for anything you want to do are done through Linux, mostly through a simple configuration file. There are also web-based and touchscreen-based GUIs, but everything is really in a file. The code, too, is mostly in Python, so making a change or adding something is relatively simple, especially if you are comfortable with Linux. The hardware stub and a small part of the host is in C, however.
If you aren’t comfortable with Linux, the user interfaces will help. You can even use them to edit your configuration files in your browser, so it is possible to have no idea how to use Linux and still get by.
Klipper Architecture
I was going to draw a diagram of the Klipper architecture, but [Sineos] beat me to it, so I borrowed this one from the Klipper discourse group’s documentation.
[Sineos] created this diagram for the Klipper knowledge baseAt the top right is the Klipper firmware — that’s the stub that executes basic commands on the hardware. The box on the bottom right indicates that you can even treat the computer Klipper is running on as a hardware host, and — what isn’t shown — is that Klipper can manage multiple controller boards (more on that later).
The final red block is the host, and that’s where all the real processing occurs. It reads G-code and worries about bed level, temperature, and so on. One of the key features is that you control it with macros, which could look like G-code or something else.
Custom G-Code
For example, suppose you want to create a new G-code, say G12345. As far as I know, that’s not a legal G-code. But you can define a macro named G12345 and make it do whatever you want. You can also define macros for real G-codes if you want. So, defining G28 would allow you to take over how the printer homes itself.
You can also have a macro named HACKADAY_LOGO or FILAMENT_CHANGE and stick those in your G code to make Klipper do anything you want. You can even do programming language constructions like for loops and if/then/else in your macros.
Klipper is almost completely concerned with reading input codes and spitting out basic movements. A lot of system management falls to Moonraker, which talks to Klipper for you and communicates with the Web, MQTT, Home Automation, and more. A configuration file is also used to set up Moonraker. So for example, if you want a text message when your print is complete, Moonraker can do that. It also can keep your system up to date.
User Interfaces
It also communicates with user interfaces. For example, if you have a touch screen, it also talks to the system via Moonraker. However, the user interface is usually a web browser viewing pages provided by Fluidd or Mainsail. In fact, you can run both on different ports and use either one you like at any time. The browser doesn’t have to be on the machine you have Klipper on, by the way. In that way, it is like OctoPrint, which you can also use if you like.
OctoPrint has many features but can be heavy to run. For whatever reason, most people seem to run Fluidd or Mainsail, even though it is possible to use OctoPrint and benefit from its many plugins and features. Moonraker can even be made to mimic OctoPrint — so slicers that know how to send jobs to Octoprint can also send jobs to Klipper.
Here’s a look at part of Fluidd’s main page (you can, of course, configure and theme it):
Part of the Fluidd main page during a print.
The Next Trick… Juggling!
I mentioned earlier that Klipper can control multiple boards. Some new bed sensors, for example, are their own computers, and Klipper can talk to them directly.
For another example. Suppose you have a board with lots of stepper drivers, and you decide to build a printer with four extruders. Later, you decide you want filament run-out sensors for each one, but your board doesn’t have enough input ports. No problem! Just get a second cheap board, flash it with the stub firmware, and tell Klipper about it. There’s no reason those sensors have to be on the same board as the other electronics. If you are running on a Raspberry Pi, there may be times when you want the Pi to not only run the main Klipper code but also host I/O devices, and that’s the function of that bottom block.
Next Steps
In the next installment, I’ll tell you more about how you can get started and a few things to look out for. If you already use Klipper, let us know your favorite tricks in the comments.
We covered Klipper way back in 2017, and it has come a long way since then. Of course, there are other ways to speed up your 3D prints.
Using a disk drive today is trivial. But back “in the day,” it was fairly complex both because the drives were simple and the CPUs were not powerful by today’s standards. [Thomas] has been working on a 68000 Mac emulator and found that low-level floppy information was scattered in different places. So he’s gathered it all for us in one place.
Low-level disk access has a lot of subtle details. For example, the Mac calibrates its speed control on boot. If your emulated drive just sets the correct speed and doesn’t respond to changes during calibration, the system will detect that as an error. Other details about spinning disks include the fact that inner tracks are shorter than outer track and may require denser recordings. Laying out sectors can also be tricky since you will lose performance if you, for example, read sector one and then miss sector two and have to wait for it to come back around. Disk sectors are often staggered for this reason.
Adding to the complexity is the controller — the IWM or Integrated Woz Machine — which has an odd scheme for memory mapping I/O. You should only access the odd bytes of the memory-mapped I/O. The details are all in the post.
In a way, we don’t miss these days, but in other ways, we do. It wasn’t that long ago that floppies were king. Now it is a race to preserve the data on them while you still can.
In the early days of 3D printers, most builds used smooth rods and bearings that rode on them. But these days, printers are shipping with either V-slot extrusions with Delrin wheels or linear rails. Which is best? Everyone seems to have an opinion, but [Spencer] decided to compare them using some well-defined experiments, and he shares his results in the video below.
Common wisdom is that linear rails create a better print quality, but [Spencer] didn’t really find that much difference. He does admit, however, that he isn’t an expert on setting up linear rails, so perhaps there’s something he could have done better. He did note that the rails were quieter but that, for both cases, the noise generated by the moving rails was only a small fraction of the total noise generated by the printer. The rails were also more stable in terms of resonance. Input shaping can help overcome that, though, so it probably isn’t that important in a modern printer.
What do you think? Are linear rail upgrades worth it? Let us know in the comments. We’ve been 3D printing long enough that we are hard-pressed to complain much about any of the prints we produce today on printers that cost a fraction of what we spent on our first ones.
Of course, you could go with string. Putting rails together with or without slots is its own art form.
You’ve probably heard that a 3D printer is capable of producing its own replacement parts. Sometimes, that even includes upgraded or improved versions of the parts it was originally built with. But sometimes, it’s hard to figure out what improved really means. Think about air ducts that cool the part after printing. In theory, it should be easy to design a new duct. But how does it perform? Empirical testing can be difficult, but [Mike] shows how you can simulate the airflow so you can test design changes and validate assumptions before you print the actual part.
Of course, this wouldn’t only apply to printer ducts. You might also get some tips if you want to model airflow for PC cooling, hot air soldering, or other air-related projects. The free version of the software has some limitations, but it was surprisingly capable.
We also enjoyed how [Mike] used fluid to visualize the actual patterns and compared it to the simulation. The trick is using a compound from a kid’s science project kit, and it seems to work very well. Of course, you could just grab your smartphone. This might be worth thinking about if you are building a laser cutter air assist, too.