Creality Ender spool holder upgrade

I've been using my 3D printers a lot recently and as is the case with pretty much any tool, heavy use shows up flaws.

The spool holder that ships with the Ender models is a simple large diameter plastic tube. Which kind of works but I've realised this has a couple of problems.


The standard spool holder simply doesn't hold the 0.5Kg reels I have, the diameter is too large. More importantly there's a lot of friction that means it pulls the filament tight and I think on a couple of occasions has caused it to snap. I tried adding some shiny tape but it didn't really help.

A long time back I made a freestanding spool holder for my old Ormerod and I was using that for the 0.5Kg reels but the filament snapping is very annoying on a long print as the Enders have no filament sensor.

To fix this I spent a little time today knocking up a similar arrangement to the standalone holder for the Enders that goes in place of the tube. It's some 3D printed parts, 608-RS bearings, M8 studding and nuts. Now the spool moves completely freely and filament falls off the spool nicely rather than being pulled tight.

Job done.

OctoPrint PSU control

I've been using my Creality printers with OctoPrint running on Raspberry Pis for a little while now and it's made them really seamless to drive. One last thing has been bugging me, I want the printers to switch off at the end of a long print. A very quick look online shows there's a plug-in for this so I ordered a couple of cheap SSRs and today spent a little while setting this up.


The plug-in can be configured with a GPIO pin it then uses to turn power on/off and I selected pin 8. This meant I could solder up a very simple straight three pin header with 5V, GND and pin 8 next to each other.

There is a tiny gotcha with this choice in that pin 8 is GPIO14 which is used for the serial console on the Pi by default. So you have to use raspi-config and disable both the console and serial hardware in the 'Interfacing options' menu.

With that done, it was simple to configure the pin in PSU control and check it would turn the SSR on/off. This worked immediately but I found that the action was 'inverted' and the plug-in has a convenient tick-box that fixes that.

To manage the printer power I took the existing IEC mains lead and carefully stripped the outer sheath, exposing the individual wires. That made it easy to break the live connection and have it switched by the SSR without having joins in the earth and neutral.

So this was safe to have floating around on my bench, I designed a 3D printable enclosure and have published it on Thingiverse. This enclosure will obviously work for any use of these little SSRs and I'm tempted to buy a few more to have in stock for future projects. The cable channel is the right diameter for typical IEC leads and grips it when you tighten the cover down.

Creality Ender 3 camera mount

I've been using my Ender 3 a lot and am very impressed with it. Teamed up with Octoprint it's just great. Better 3D printers are legion but this will do me for the foreseeable future.

Octoprint supports a USB webcam for remote print monitoring and I've been using one of my stash of old Xbox LiveCams for this.

However I got tired of having it gaffa taped to a jar nearby as I kept knocking it out of alignment. To stop this I made a little mount which works quite nicely, so I stuck it on Thingiverse.

All it needs is some double sided tape to hold it on the printer and a sticky pad for the camera. Should work with any old webcam with a flat base.

I started out designing something to fix with the bolts that secure the Y stepper motor but realised they're too short to use and have any meat to the print. This version fits reasonably snugly so the tape doesn't really take much load.

LILYGO TTGO T-Wristband

This is the LilyGo TTGO T-Wristband that turned up today, catchy name.

LilyGo are known for producing a lot of 'maker friendly' development boards where they cram a lot of useful stuff together on a board in various combinations, lots of it based around the ESP8266 or ESP32.

Chances are there's a combination that might not be exactly what you want, but close enough you don't need to build something up from scratch or a tangle of different modules. Want an E-paper display, OLED display, LORA radio, Cellular connectivity, LiPo charging circuit and ESP or some random combo of 2-3 of these on one board they probably make it. It's all cheap and cheerful AliExpress/Banggood fare and I've bought a few things from them over the years.

This here is closer to an actual product, it's a 'fitness band' looking much like one of the sea of cheap BLE ones available for attaching to your phone but it's maker friendly with a programming cable and apparently usable code for all the components on GitHub.

Based around the ESP32 it's probably not the best platform for something like this as it's too power hungry, but it should be something I can program myself.

I have plans to tie it into my mesh network and directly deliver messages over ESP-Now with no need for a phone.

This is a kind of speculative purchase, I may not find the time to get the code in order for when I need it, but it was cheap as chips and if it does work it will be great.

If it does work I may buy 2-3 more.

ESP32-CAM case, selfie lens and mount - part 1

Poundland (the major UK 'dollar store') had selfie lenses for 50p so I picked up a few to play with on my stash of ESP32-CAM modules.

I've 3D printed a mount that protects the board and lines up the lens perfectly with the existing camera. The lens is an interference fit, at least on my printer, and screws in firmly.

Initial testing seems positive as it really expands the field of view. It's never going to rival a GoPro but makes the module much more versatile. You can buy a wide angle cameras for the ESP32-CAM but typically you have to buy that separately, almost doubling the cost so this was a cheaper way to get similar effect.

It also gives it a 'big lens' look rather than the pinhole camera of the usual module. Which is the aesthetic I want.

I still need to design a back to the case but this should give me a robust housing for these things. Different backs could have different options including a battery holder and switch.

The flash LED is exposed close to the lens but this would work better with a bit of acrylic rod acting as a light pipe and make it possible to make the whole thing passably waterproof with some thought.

The nasty thing with the LED is it shares a pin with the SD card interface so if you access the card it flashes. This is a problem. I have no idea who would have thought that was a good idea, it's not like there aren't any free pins. Fine if you use the camera over the network but makes the flash useless in situations you want to write to SD and if it's battery powered will chew power. Just why?

Mesh networked computer terminals with RFID logon - part 5

After a chunk of work I've got file syncing working fully. The code does a simple manifest of everything on the SD card except for the irritating "System Volume Information" directory Windows puts on there if you view the card on a Windows system.

As my mesh network isn't designed to be high bandwidth and I'm not expecting the files on there to change often, this is a slow, lightweight process. After all it's only running on an ESP8266, don't expect BitTorrent.

The steps the mesh takes to sync are broadly...

• Recursively iterate the whole file system on the SD card
• Open each file and do a CRC16 of it
• Store the full path and filename, size and CRC16 in a data structure
• Write this to a simple flat file to save this across restarts. Each file is given a sequence number starting at one that increments with each change
• Once all the files have been read, XOR all their CRC16s together and store it
• The total number of files and this XOR of the CRC16s are advertised periodically by each node flooding the whole mesh
• If a node receives a XOR that doesn't match its own it asks for the CRC16, size and sequence number of each file on the other node, one at a time
• Some simple if/then/else logic decides if it needs the other node's version of the file
• Files are transferred 64 bytes at a time in a TFTP-esque manner
• Once the XOR and number of files match the two nodes are considered synced and stop
• To detect change from an initially synced state, if a file is changed the new CRC16, size and sequence number are flooded to the whole mesh immediately
• Notification of deleted files use a similar mechanism and stay in the data structure
• There are timeouts and retries on the various steps in the process so it will fail fairly gracefully and restart

This is probably full of edge case horrors and has no way to handle file conflict resolution. I don't care, this is not an enterprise class distributed file system, it's a bunch of microcontrollers in a field that I need to have the same files on, mostly, and stay in sync, mostly.

Watch the awesome log output!

Mesh networked computer terminals with RFID logon - part 4

This is another little update, I have basic file transfers working, woohoo!

There is no authentication but some basic sanity checking of the data, ie. is the packet from the station it expects, for a file it expects and the chunk it expects next. It's pretty much like TFTP but done over my proprietary mesh network stuff.

I'm currently only shipping 64 bytes at a time, inefficiently packed too, so it's going to suck for large files but the process works and will chunk through a queue of files happily grabbing them.

Now the code needs cleaning up and to allow for things like failed transfers.

I also need to go back to the file manifest handling as it handles change, but not initial seeding. However this is a really positive step forwards.

Mesh networked computer terminals with RFID logon - part 3

The last couple of days I've been messing around with code for building a 'manifest' of the file system on the SD card then notifying changes to other stations.

This has taken a lot of time as I had a few false starts in my reinvention of this particular wheel. I think I trashed my plan and started again at least three times and it's probably still a quite naive scheme. As things stand it's just notification of change, the other station knows if there's an updated file but there's no method to transfer the file as yet.

Oddly I don't think file transfer will be hard. The way I've put my mesh library together makes it quite easy to push arbitrary data around. It will just need to be chopped up into chunks and sent. Maybe also 'lock' the file to prevent local changes while any transfer occurs, just in case.