​LDraw.org maintains a ​library of Lego part models upon which a number of related tools such as ​LeoCAD, ​LDView and ​LPub rely.

I packaged the 2023-06 parts library for Fedora 38 to install to /usr/share/ldraw; it should be straight-forward to adapt to other distributions.

The *.noarch.rpm files are the ones to install, and the .src.rpm contains everything so it can be rebuilt for another rpm-based distribution.

ldraw_parts-202306-ec1.fc38.src.rpm​

ldraw_parts-202306-ec1.fc38.noarch.rpm​
ldraw_parts-creativecommons-202306-ec1.fc38.noarch.rpm​
ldraw_parts-models-202306-ec1.fc38.noarch.rpm​

See also LDrawPartsLibrary.

​Sabaton released a bunch of new lyric videos and some new history videos. The SabatonIndex is updated with links to that new content.

I recently discovered heat-set threaded inserts. These little bits of brass provide a way to use bolts in 3D-printed plastic parts.

The idea is that you create a plastic part with a slightly-undersized hole where the insert will go, and then using a soldering iron with a specialized tip, you heat the insert, which softens the plastic enough that you can press it into the part. Once the plastic cools, the insert is firmly embedded in the part. The inserts have internal threads which a machine screw / bolt can be screwed into. They have sharp teeth features at opposing angles on the outside, so they remain firmly embedded in the part and can't themselves unscrew.

I bought a set of soldering iron tips for this purpose from ​Virtjoule (​via Amazon). The set of brass tips came in a plastic tray which had obviously been 3D-printed.

But there was no lid for the tray. So I threw together a 3D model of a lid for it (OpenSCAD, STL)

and printed it in "transparent" PLA.

That fits nicely and helps to keep the set of tips together:

Being able to quickly create a lid for a box is not something I had anticipated doing with a 3D printer, but in retrospect, it's an amazingly obvious application.

And then there's the intriguing aspect that it's useful to a business creating packaging for a specialty product. In this case, the US-based company is in a business where they are applying 3D-printed parts, and are selling a tool they themselves created and use. So they've found an additional use of infrastructure they already had, and a market for a product they had created for their own use. I think that's really neat.

There are some tools you figure will be useful, but it is difficult to really justify investing in them before you have them. And then you get it anyway, and discover how much more useful it is than you envisioned. Getting a 3D printer was that sort of experience for me; I knew I'd find it useful, but I hadn't realized just how useful. Using OpenSCAD and some calipers, I have managed to create replacement parts or useful gizmos that would not have occurred to me prior to owning a 3D printer.

Here is just one example.

A friend of my wife had Mouse Trap, a kids' board game built around a ​Rube Goldberg contraption.

Unfortunately, she had lost the seesaw piece, which meant that the contraption could not work.

As it so happened, we also had the game, though it did have some differences.

The seesaw from our game still worked with hers.

So I grabbed my calipers, and threw together a quick approximation of our seesaw in OpenSCAD,

and printed it out.

The resulting seesaw, though not as brightly colored as the rest of the game, did work, and fixed her game.

If you want to print your own, here are the OpenSCAD model and the STL.

​Sabaton released a few new lyric videos and a couple of new history videos. The SabatonIndex is updated with links to that new content.

​LDraw.org maintains a ​library of Lego part models upon which a number of related tools such as ​LeoCAD, ​LDView and ​LPub rely.

I packaged the 2023-03 parts library for Fedora 36 to install to /usr/share/ldraw; it should be straight-forward to adapt to other distributions.

The *.noarch.rpm files are the ones to install, and the .src.rpm contains everything so it can be rebuilt for another rpm-based distribution.

ldraw_parts-202303-ec1.fc36.src.rpm​

ldraw_parts-202303-ec1.fc36.noarch.rpm​
ldraw_parts-creativecommons-202303-ec1.fc36.noarch.rpm​
ldraw_parts-models-202303-ec1.fc36.noarch.rpm​

See also LDrawPartsLibrary.

With a laptop and a 4K monitor, I wind up with a large number of windows scattered across my screens. The general disarray of scattered and randomly offset windows drives me nuts.

I've done some work to address this problem before (here and here), which I had been referring to as "quicktile". But that's what KDE called its implementation that allowed snapping the window to either half of the screen, or to some quarter. On Windows, there's a Power Tool called "Fancy Zones" that also has a few similarities. In an effort to disambiguate what I've built, I've renamed my approach to "Quick Grid Zones".

Since the last post on this, I've done some cleanup of the logic and also ported it to work on Windows.

This isn't a cross-platform implementation, but rather three implementations with some structural similarities, implemented on top of platform-specific tools.

• Linux KDE - KDE global shortcuts that call a Python script using xdotool, wmctrl, and xprop
• Mac OS - a lua script for ​Hammerspoon
• Windows - an ​AutoHotKey2 script

Simple demo of running this on KDE:

Grab the local tarball for this release, or check out the QuickGridZones project page.

​LDraw.org maintains a ​library of Lego part models upon which a number of related tools such as ​LeoCAD, ​LDView and ​LPub rely.

I packaged the 2023-02 parts library for Fedora 36 to install to /usr/share/ldraw; it should be straight-forward to adapt to other distributions.

The *.noarch.rpm files are the ones to install, and the .src.rpm contains everything so it can be rebuilt for another rpm-based distribution.

ldraw_parts-202302-ec1.fc36.src.rpm​

ldraw_parts-202302-ec1.fc36.noarch.rpm​
ldraw_parts-creativecommons-202302-ec1.fc36.noarch.rpm​
ldraw_parts-models-202302-ec1.fc36.noarch.rpm​

See also LDrawPartsLibrary.

​LeoCAD is a CAD application for building digital models with Lego-compatible parts drawn from the ​LDraw parts library.

I packaged (as an rpm) the 23.03 release of LeoCAD for Fedora 36. This package requires the LDraw parts library package.

Install the binary rpm. The source rpm contains the files to allow you to rebuild the packge for another distribution.

leocad-23.03-ec1.fc36.x86_64.rpm​

leocad-23.03-ec1.fc36.src.rpm​

The Problem:

I have a ​Creality Ender-3 Pro that came with a 32bit 4.2.2 motherboard. The firmware on these boards can be updated by booting from a correctly prepared uSD card containing compatible firmware. (This is done by "the bootloader", which I will refer to as the "second-stage bootloader" hereafter because there is a first-stage bootloader in ROM which jumps to the second-stage bootloader at the beginning of flash, which in turn handles any firmware upgrade and then jumps to the firmware later in the flash. Being pedantically precise is important when dealing with machines at this low level.)

But if something goes wrong with a firmware upgrade, you can be faced with a device that shows only a blank screen, and very little to go on when trying to diagnose why it won't flash a correct firmware.

If the board does not attempt to flash, and boots into the existing working firmware, you should see the splash screen about 2 seconds after power is applied. If the board successfully flashes the updated firmware, you should see a blank screen for about 15 seconds, and then the splash screen of the new firmware. If the board does not attempt to flash and the existing firmware is broken, you will see a blank screen forever. If the board flashes a broken firmware, you will also see a blank screen forever.

I'm not the only one who ran into this issue, and I found a lot of advice online regarding this, but the second-stage bootloader on this board seems to be rather finicky, which led to people drawing apparently erroneous conclusions about what they did to fix their machines.

The documentation mentions that you should use a uSD card 8GB or smaller. But I have found that a properly-prepared 512MB uSD card does not work either. So it appears that there is also a lower bound to the uSD card size somewhere between 8GB and 512MB.

It is commonly believed that the firmware file must be named firmware<number>.bin, where <number> is a number different from what was previously flashed. I found that the requirement is that the file be named <something>.bin, where <something> is different from what was previously flashed. For example, I was able flash the firmware from a file named Ender-3 Pro- Marlin2.0.1 - V1.0.1 - TMC2225 - English.bin

And to be explicit, it only tracks the most recently flashed filename. If you have two uSD cards, one with firmware1.bin and the other with firmware2.bin, you can boot from them alternately, and successfully re-flash each time.

I have also seen people suggest using an 8.3 filename (limiting oneself to 8 character filename and 3 character bin extension). However, the firmware correctly identified that Ender-3 Pro- Marlin2.0.1 - V1.0.1 - TMC2225 - English2.bin differed from Ender-3 Pro- Marlin2.0.1 - V1.0.1 - TMC2225 - English.bin and flashed the image.

I found people talking about using a freshly formatted or brand new uSD card, and frequently people blamed cheap uSD cards as being faulty, including the uSD card that came with the printer. It appears to me that this is misattributing to the uSD hardware what is really a problem with the second-stage bootloader. Starting with an 8GB uSD card containing a correct firmware file, I would wind up with a blank screen. Taking that same 8GB uSD card, wiping the entirety of it with zeros, creating a vfat filesystem on it, copying that same firmware file to it, and flashing from that would reliably succeed. Writing an image of the previous filesystem to the uSD card would reliably recreate the blank screen problem. So the problem was clearly with the data, not with the hardware.

It appears that the history of the filesystem must play a role in the blank screen problem. The original uSD card, with all files deleted, and a correct firmware file copied to it, was causing the blank screen problem. I must conclude that the second-stage bootloader is looking at deleted file entries, or the data blocks for the firmware file were fragmented in some way that confused it, or... something. My attempts to produce a filesystem from scratch that would exhibit this behavior were not successful.

I've seen instructions about having to create a partition on the uSD card at exactly the right place. However, I found I could reliably flash the board with no partitioning of the device.

Solution

At this point, I can reliably flash the board with this process:

Fully wipe and format the device by running these commands as root:

dd if=/dev/zero bs=1G of=/dev/mmcblk0
mkfs -t vfat /dev/mmcblk0
sync

Caution: Ensure that you use the correct device name for your system (/dev/mmcblk0 was the device on my machine); using the wrong device could wipe and reformat your entire laptop.

When using the SD card slot on my laptop, the sync was superfluous, but when using a USB uSD card adapter, it would aggressively cache the writes and the bulk of the time was spent waiting on the sync. (That process takes about 12 minutes on my machine with the uSD card that shipped with the printer.)

Mount the device, then copy the firmware file to it as firmware1.bin, unmount the device. Insert it into the board, power on, and wait for it to flash and boot into the new firmware. If it does not attempt to flash, rename the firmware file and try again.

Caveats:

While debugging this, I attempted many scenarios with various parts of the system disconnected, such as all the motors, switches, sensors, and heaters. In order to get a handle on the variables, I did my testing to draw the conclusions in this article with the motherboard connected to the LCD screen, all other components disconnected, and powered by the micro USB port. I did verify that I was able to flash the firmware with the LCD screen disconnected; i.e., with the only connection to the board being the micro USB cable to power it. I did not see any indication that the board behaved differently with everything disconnected vs with everything properly connected and installed in the printer. But with the number of flaky oddities I saw in working through this, such context is important to capture.

I have upgraded my Ender-3 Pro with the ​4.2.7 silent motherboard, and ran into the same blank screen problem when trying to flash it to support the ​CR Touch. I was able to recover it using the same techniques above.