Einen TD-1 für Hueforge bauen – (Teil1)

Vor einiger Zeit hat mich @JoeMuc im Fediverse auf HueForge aufmerksam gemacht. Eine neue Art Bilder in 3D zu drucken. Es ist nicht so aufgebaut wie bei klassischen Litophane, sondern eine eigens erstelle Software von Steve Lavedas, einem ziemlich pfiffigen Typen.

Transform your 2D images into stunning, photo-like 3D prints
HueForge is a software that uses a technique called filament painting to make detailed prints without requiring a multi-material 3D printer.”

Das Ganze kann dann so aussehen:

Ein Eichkat3r - halbwegs komplett in einem Bilderrahmen
Ein Eichkat3r – halbwegs komplett in einem Bilderrahmen


Hier hat Joe auch schon darüber geschrieben: KlickMich

Der so genannte TD-1, dessen Idee von Ajax kam, ist ein kleines Gerät, welches mit Sensoren ausgestattet ist um die so genannte Transmission Distance zu bestimmen. Dieser Wert spiegelt die Fähigkeit Licht durch 3D Druck Filament scheinen zu lassen wider.
Das klingt erstmal schräg, aber wenn man weiß, dass HueForge darauf angewiesen ist, dann ergibt es Sinn. Denn schwarzes Filament schimmert ja noch durch weißes Filament hindurch, wenn es hauchdünn drüber gedruckt wird.

Solche Bilder sind manchmal nur 1.24mm dick. Das muss man sich echt mal vorstellen. Eine Schicht ist dann dabei oft nur 0.08mm dick. Und das kann man zuhause herstellen. WOW!

Weißes Filament lässt sehr viel mehr Licht durch als schwarzes und auch wenn HueForge mit einer großen Datenbank von Filamenten und deren TD-Werten daher kommt, ist es elementar zu wissen, dass TD bei der Herstellung irgendwie eine Rolle spielt. Das heißt, dass z.B. Bambulab Basic “Jade White” bei der einen Spule einen TD-Wert von 5 hat, aber bei der nächsten Spule aus der gleichen Bestellung 4.4. (selbst innerhalb einer Spule kann sich der Wert verändern, aber das führt dann doch zu weit)

Letztendlich ist es aber immer gut zu wissen, was man wirklich für ein Filament zuhause hat mit dem man “malen” möchte.

Ajax hat letztendlich ein Gerät entwickelt womit es sehr einfach ist den entsprechenden TD-Wert zu bestimmen.
Und da einerseits nicht jeder viel Geld für ein fertiges Produkt, oder ein PCB-Set hat, wo man sich nur noch das Gehäuse drucken und die PCBs löten muss, was man auch importieren müsste, hat er auch einen Weg zum Self-Sourcing ermöglicht.

Das heißt:

  • Eine Liste mit den benötigten Sensoren usw.
  • ihr druckt das Gehäuse zuhause selbst
  • ihr bastelt und lötet das alles selbst zusammen
  • ihr installiert die Software auf das “Mainboard”
  • ihr “aboniert” für einen Monat Ajax’ Patreon für 10€, um eine Lizenz zu erhalten

Alles in allem eigentlich eine faire Sache, wenn man bedenkt, dass ein fertiges Gerät 80€ plus Zoll und Import, ein PCB-Set um die 40€ und die Selbstbauvariante (wenn man keine Fehler macht) ca. 20-25€ inkl. Lizenz kostet.

Ich persönlich würde auch immer die Selbstbau-Option bevorzugen, denn einerseits lernt ihr was und zum anderen könnt ihr, wenn irgendwas schief läuft, einfach eine neue LED oder ein neues Display verwenden.

Die PCB-Variante scheint, auch wenn es gut durchdacht ist, gerade beim Display eine kleine Schwachstelle zu haben. Diese feinen OLED-Displays brechen super leicht und auch ich habe 4 Stück “verloren” bevor mein TD-1 wirklich lief.

Hier kommt auch schon die Einkaufsliste – alle Sensoren usw. unbedingt ohne angelötete Stiftleiste organisieren:

  • Microcontroller – RP2040-Zero by WaveShare
  • RGB-Sensor – TCS3472
  • Luminosity Sensor – TSL2561
  • Display – SSD1306 0.91 OLED
  • 2x NeoPixels- SK6812 RGBNW (ihr braucht zwar nur zwei, aber bestellt einfach gerne mal 10)
  •  Schalter – 6x6x4.3mm
  • 1x Ball Bearing – 7mm (kann man kaum einzeln kaufen, sind aber nicht teuer)
  • Rainbow Ribbon Cable (davon hat man ja vermutlich eh schon einiges zuhause)
  • 4x Schrauben – M3x6mm BHCS
  • 2x Schraubenn – M3x10mm BHCS

Die NeoPixels sehen so aus – bestellt gerade 10 oder mehr, wenn ihr Euch nicht sicher seid, denn die haben mich neben den Displays, wovon ich ja auch einige während der Herstellung kaputt gemacht habe echt Nerven gekostet!

2x NeoPixels- SK6812 RGBNW

Dann noch ein Lötkoblen und ruhige Hände und schon kann es los gehen.

Demnächst schreibe ich dann darüber, wie ich die Teile dann zusammen “geklöppelt” habe und wie dann der erste Druck aussah.

Wahnsinnig spannender Cliffhanger, oder? ODER?

Update: in einer ersten Version dieses Beitrags habe ich einen Fehler gemacht und HueForge, welches von Steve entwickelt wird, Ajax zugeschrieben.

Danke vielmals an @Mawoka für den Hinweis.

[Teil 2] Spoolman – Klipper Installation

English below:

Die Installation von Spoolman auf dem Raspberry (oder MKS-Mainboard), wo Klipper drauf läuft ist so simpel wie so viele andere Klipper-Plugins – es wird lediglich ein auf Debian basiertes Image vorrausgesetzt.

sudo apt-get update && \
sudo apt-get install -y curl jq && \
mkdir -p ./Spoolman && \
source_url=$(curl -s https://api.github.com/repos/Donkie/Spoolman/releases/latest | jq -r '.assets[] | select(.name == "spoolman.zip").browser_download_url') && \
curl -sSL $source_url -o temp.zip && unzip temp.zip -d ./Spoolman && rm temp.zip && \
cd ./Spoolman && \
bash ./scripts/install_debian.sh

So wird es zumindest in der Anleitung beschrieben.

Ich hingegen habe ich mich dazu entschlossen Spoolman auf einem anderen Host mit Hilfe von Docker zu installieren, da ich eh eine VM in meinem Netzwerk habe, die diverse Docker-Container bereit stellt.

Ich wiederhole einfach nur noch schnell einmal die Grundinstalltion, wie ich sie auch schon im Teil 1 von der Spoolman-Anleitung beschrieben habe.

Die entsprechende docker-compose.yml sieht dann in etwa so aus:

version: '3.8'
services:
  spoolman:
    image: ghcr.io/donkie/spoolman:latest
    restart: always
    volumes:
      # Mount the host machine's ./data directory into the container's /home/app/.local/share/spoolman directory
      - type: bind
        source: ./data # This is where the data will be stored locally. Could also be set to for example `source: /home/pi/printer_data/spoolman`.
        target: /home/app/.local/share/spoolman # Do NOT change this line
    ports:
      # Map the host machine's port 7912 to the container's port 8000
      - "7912:8000"
    environment:
      - TZ=Europe/Berlin# Optional, defaults to UTC

Wenn man also den Container installiert und am Laufen hat, dann reicht eine einfache Änderung der moonraker.conf in Klipper um Spoolman hinzuzufügen:

# moonraker.conf

[spoolman]
server: http://192.168.10.123:7912
#   URL to the Spoolman instance. This parameter must be provided.
sync_rate: 5
#   The interval, in seconds, between sync requests with the
#   Spoolman server.  The default is 5.

Und in die printer.cfg wird dann noch folgendes ergänzt:

# printer.cfg

[gcode_macro SET_ACTIVE_SPOOL]
gcode:
  {% if params.ID %}
    {% set id = params.ID|int %}
    {action_call_remote_method(
       "spoolman_set_active_spool",
       spool_id=id
    )}
  {% else %}
    {action_respond_info("Parameter 'ID' is required")}
  {% endif %}

[gcode_macro CLEAR_ACTIVE_SPOOL]
gcode:
  {action_call_remote_method(
    "spoolman_set_active_spool",
    spool_id=None
  )}

Und das war es schon – nach einem Neustart von Klipper sieht es dann so aus:

Es gibt sogar eine Integration in Home Assistant um sich dort auch die Spulen anzeigen zu lassen.

Die Einrichtung ist relativ einfach und quasi selbsterklärend.
Hier gibt es die entsprechenden Infos: Home Assistant Spoolman

PS: Damit man auch die QR Codes, die man mit Spoolmann erstellt und ausgedruckt hat lesen kann, braucht es zwingend eine https-Verbindung zu Spoolman. Das ist seitens der Browserhersteller wie Mozilla oder Google so vorgegeben.

Ich habe das ganz einfach per Nginx Proxy Manager gelöst in dem ich eine neue Subdomain angelegt habe und diese dann per Letsencrypt mit einem SSL-Zertifikat ausgestattet habe.
Aber nun ist Spoolman offen aus dem Internet erreichbar?
Ja, aber mit Hilfe einer Access List (z.B. local-only) im Nginx Proxy Manager und der entsprechenden Einstellung bei der Subdomain, dass diese Access List benutzt werden soll, habe ich so eine HTTP-Auth Passwortabfrage eingerichtet und nur Personen mit entsprechendem Passwort kommen an das Webinterface von Spoolman.

@maxheadroom hat das aber auch irgendwie in seinem Traefik-Container lösen können und schreibt hier darüber: Klick

English version:

The installation of Spoolman on the Raspberry Pi (or MKS mainboard) running Klipper is as simple as so many other Klipper plugins – it only requires a Debian based system.

sudo apt-get update && \
sudo apt-get install -y curl jq && \
mkdir -p ./Spoolman && \
source_url=$(curl -s https://api.github.com/repos/Donkie/Spoolman/releases/latest | jq -r '.assets[] | select(.name == "spoolman.zip").browser_download_url') && \
curl -sSL $source_url -o temp.zip && unzip temp.zip -d ./Spoolman && rm temp.zip && \
cd ./Spoolman && \
bash ./scripts/install_debian.sh

At least that’s how it’s described in the instructions.

However, I decided to install Spoolman on another host using Docker, as I already have a VM in my network that provides various Docker containers.

I’ll just quickly repeat the basic installation as I described in part 1 of the Spoolman guide.

The corresponding docker-compose.yml then looks something like this:

version: '3.8'
services:
  spoolman:
    image: ghcr.io/donkie/spoolman:latest
    restart: always
    volumes:
      # Mount the host machine's ./data directory into the container's /home/app/.local/share/spoolman directory
      - type: bind
        source: ./data # This is where the data will be stored locally. Could also be set to for example `source: /home/pi/printer_data/spoolman`.
        target: /home/app/.local/share/spoolman # Do NOT change this line
    ports:
      # Map the host machine's port 7912 to the container's port 8000
      - "7912:8000"
    environment:
      - TZ=Europe/Berlin# Optional, defaults to UTC

So if you have the container installed and running, a simple change to moonraker.conf in Klipper is enough to add Spoolman:

# moonraker.conf

[spoolman]
server: http://192.168.10.123:7912
#   URL to the Spoolman instance. This parameter must be provided.
sync_rate: 5
#   The interval, in seconds, between sync requests with the
#   Spoolman server.  The default is 5.

And the following is then added to printer.cfg:

# printer.cfg

[gcode_macro SET_ACTIVE_SPOOL]
gcode:
  {% if params.ID %}
    {% set id = params.ID|int %}
    {action_call_remote_method(
       "spoolman_set_active_spool",
       spool_id=id
    )}
  {% else %}
    {action_respond_info("Parameter 'ID' is required")}
  {% endif %}

[gcode_macro CLEAR_ACTIVE_SPOOL]
gcode:
  {action_call_remote_method(
    "spoolman_set_active_spool",
    spool_id=None
  )}

And that’s it – after restarting Klipper, it looks like this:

There is even an integration in Home Assistant to display the reels there too.

The setup is relatively simple and virtually self-explanatory.
You can find the relevant information here: Home Assistant Spoolman

PS: In order to be able to read the QR codes that you have created and printed with Spoolman, an https connection to Spoolman is required. This is specified by browser manufacturers such as Mozilla or Google.

I solved this quite simply using Nginx Proxy Manager by creating a new subdomain and then equipping it with an SSL certificate using Letsencrypt.
But now Spoolman is openly accessible from the Internet?
Yes, but with the help of an access list (e.g. local-only) in the Nginx Proxy Manager and the corresponding setting in the subdomain that this access list should be used, I have set up an HTTP-Auth password query and only people with the corresponding password can access the Spoolman web interface.

However, @maxheadroom has also been able to solve this somehow in his Traefik container and writes about it here: Click

[Teil 1] Spoolman – track your filament… hab ich noch grünes PETG?

English below:

Neulich bin ich durch Zufall im Discord vom Mainsail-Projekt auf “Spoolman” gestoßen. Ein Klipper-Plugin, von dem ich bis dato noch nie was gehört habe, welches dazu gedacht ist endlich ein wenig Ordnung in sein vorhandenes Filament zu bringen.

In einer Datenbank werden Hersteller, Farbe, Art und Gewicht Deiner Filamente getrackt und mit Hilfe des Klipper-Plugins wird der Verbrauch direkt subtrahiert. So kannst Du weitestgehend genau sagen, wie viel Du noch von Filament X hast und kannst entscheiden, ob Dein nächster Druck damit noch möglich ist oder ob Du lieber nachbestellen solltest oder eben in einer anderen Farbe drucken möchtest.

Das Projekt findest Du hier: https://github.com/Donkie/Spoolman
… und es lässt sich sehr leicht anhand der Anleitung dort installieren.

Ich habe es als Docker-Version installiert, da ich auf einem meiner Hosts eh mehrere Docker-Projekte laufen habe.

Und so sieht die docker-compose.yml aus:

version: '3.8'
services:
  spoolman:
    image: ghcr.io/donkie/spoolman:latest
    restart: unless-stopped
    volumes:
      # Mount the host machine's ./data directory into the container's /home/ap>
      - type: bind
        source: ./data # This is where the data will be stored locally. Could a>
        target: /home/app/.local/share/spoolman # Do NOT change this line
    ports:
      # Map the host machine's port 7912 to the container's port 8000
      - "7912:8000"
    environment:
      - TZ=Europe/Berlin # Optional, defaults to UTC

Wenn man alles also eingerichtet hat, beginnt man damit seine Filamente zu erfassen.

Ich rate dazu zunächst mit den Herstellern anzufangen und sich dann über die einzelnen Filamentsorten bis hin zur einzelnen Spule zu arbeiten.

Um auch die Dichte der jeweiligen Filamentsorten richtig zu erfassen, emofehle ich diese Webseite:
https://www.simplify3d.com/resources/materials-guide/properties-table/

Dort steht unter Density für die jeweilige Sorte auch der entsprechend richtige Wert. Bei PLA wäre das zum Beispiel: 1,24 g/cm³

Am Ende sieht es dann in etwa so aus:

Und wie man sehen kann, habe ich überhaupt kein grünes PETG Filament. 😀

Im nächsten Teil werden wir dann mal sehen, wie das Ganze dann in Klipper integriert wird und wie einfach es dann ist selbst bei einem Filamentwechsel während des Drucks die entsprechenden Spulen auszuwählen.

English:

[Part 1] Spoolman – track your filament… do I still have some green PETG left?

I recently came across “Spoolman” by chance in the Mainsail project’s Discord. A Klipper plugin that I had never heard of before, which is designed to finally bring some order to your existing filament.

The manufacturer, color, type and weight of your filaments are tracked in a database and the consumption is subtracted directly with the help of the Klipper plugin. This way you can tell exactly how much of filament X you have left and can decide whether your next print is still possible with it or whether you should rather reorder or print in a different color.

You can find the project here: https://github.com/Donkie/Spoolman
… and it is very easy to install using the instructions there.

I installed it as a Docker container because I have several Docker projects running on one of my hosts anyway.

And this is what docker-compose.yml looks like:

version: '3.8'
services:
  spoolman:
    image: ghcr.io/donkie/spoolman:latest
    restart: unless-stopped
    volumes:
      # Mount the host machine's ./data directory into the container's /home/ap>
      - type: bind
        source: ./data # This is where the data will be stored locally. Could a>
        target: /home/app/.local/share/spoolman # Do NOT change this line
    ports:
      # Map the host machine's port 7912 to the container's port 8000
      - "7912:8000"
    environment:
      - TZ=Europe/Berlin # Optional, defaults to UTC

Once you have set everything up, you can start to record your filaments.

I recommend starting with the manufacturers first and then working your way through the individual filament types right down to the individual spools.

To correctly record the density of the respective filament types, I recommend this website:
https://www.simplify3d.com/resources/materials-guide/properties-table/

There, under Density, you will also find the correct value for the respective type. For PLA, for example, this would be: 1.24 g/cm³

In the end, it looks something like this:


And as you can see, I do not have any green PETG filament at all. 😀

In the next part, we will see how the whole thing is integrated into Klipper and how easy it is to select the appropriate spools even when changing filament during printing.

klipper-backup | save your config @ github

English below:

Wenn man immer mal wieder an den Einstellungen bei Klipper in den Konfigurationen herum spielt, dann wäre es doch toll, wenn es regelmäßige Backups gibt, die extern gespeichert werden.

Auf der Suche nach einer einfachen Lösung bin ich über folgende Seite gestolpert:
https://github.com/Staubgeborener/klipper-backup

Als erstes installiert man sich auf dem Raspberry oder direkt auf einem Drucker, wie in meinem Fall einem Neptune 4 Plus, git.

sudo apt update
sudo apt install git

Und jetzt schon fast das Wichtigste:

git config --global credential.helper store

Denn mit diesem Befehl wird der Token, den wir im Laufe der weiteren Installation erstellen werden, auch lokal zur Autentifizierung dient, gespeichert.
(Das war auch der Grund, warum ich immer wieder Fehlermeldungen beim Ausführen des Skripts erhalten habe.)

Also falls ihr so etwas wie “remote: Invalid username or password.” oder ähnliches bei der Ausführung des Scripts erhaltet, dann liegt es daran, dass git zumindest auf dem Elegoo Neptune 4 Board nicht direkt das Passwort speichert.

Wir erstellen uns bei Github ein neues Repository und einen Personal Access Token, dem wir Schreibrechte usw. geben.

Dann beginnen wir mit der eigentlichen Installation:

git clone https://github.com/Staubgeborener/klipper-backup.git && chmod +x ./klipper-backup/script.sh && cp ./klipper-backup/.env.example ./klipper-backup/.env

als nächstes bearbeiten wir die .env Datei mit einem Editor (z.B.) vim / nano etc.

nano klipper-backup/.env

Den frisch erstellten Github-Token kopieren wir an die Stelle “github_token=”, schreiben unseren Github-Benutzernamen an die enspechenden Stelle und tragen natürlich auch unser Github Repository ein.

Dann sieht es in etwa so aus:

github_token=ghp_xxx
github_username=noccis-github
github_repository=elegoo_neptune4backup
branch_name=main
commit_username="mks"
commit_email=""

# Indivdual file syntax:
#  Note: script.sh starts its search in $HOME which is /home/{username}/
# Using below example the script will search for: /home/{username}/printer_data/config/printer.cfg

path_printercfg=klipper_config/printer.cfg

# Backup folder syntax:
#  Note: script.sh starts its search in $HOME which is /home/{username}/
# Using below example the script will search for: /home/{username}/printer_data/config/*
# `/*` should always be at the end of the path when backing up a folder so that the files inside of the folder are prop$
#path_klipperdata=printer_data/config/*
path_klipperdata=klipper_config/*

Hier ist wir erstemal soweit fertig und wenden uns der moonraker.conf in Klipper zu.

Hier fügen wir folgendes hinzu und speichern die Datei:

[update_manager klipper-backup]
type: git_repo
path: ~/klipper-backup
origin: https://github.com/Staubgeborener/klipper-backup.git
managed_services: moonraker
primary_branch: main

Aber wir wollen das ganze ja auch noch ein wenig automatisieren:
Und deshalb erstellen wir einen neuen Service:

sudo nano /etc/systemd/system/klipper-backup.service

und dorthin kopieren wir:

[Unit]
Description=Klipper Backup Service
#Uncomment below lines if using network manager
#After=NetworkManager-wait-online.service
#Wants=NetworkManager-wait-online.service
#Uncomment below lines if not using network manager
#After=network-online.target
#Wants=network-online.target

[Service]
User={replace with your username}
Type=oneshot
ExecStart=/bin/bash -c '/home/mks/klipper-backup/script.sh "New Backup on boot $(date +%%D)"'

[Install]
WantedBy=default.target

Denkt bitte daran, die entsprechenden Werte und Pfade auf Euer Umfeld anzupassen.

Wir reloaden den Deamon und starten dann den Service:

sudo systemctl daemon-reload
sudo systemctl enable klipper-backup.service
sudo systemctl start klipper-backup.service

Optional kann man natürlich noch einen Cron installieren, der dann beispielsweise alle 4 Stunden ein Backup macht.

crontab -e

und hier wird dann folgendes eingefügt:

 */4 * * * $HOME/klipper-backup/script.sh

Aber via Mainsail oder Fluid ein Update anzustoßen wäre ja auch irgendwie praktisch. Also machen wir das in der printer.cfg möglich:

[gcode_macro update_git]
gcode:
    RUN_SHELL_COMMAND CMD=update_git_script

[gcode_shell_command update_git_script]
command: bash -c "bash $HOME/klipper-backup/script.sh"
timeout: 90.0
verbose: True

Fertig!

Und in Fuidd sieht das dann so aus:

Um sicher zu gehen, dass auch alles richtig funktioniert, könnt Ihr dann das Script direkt im Terminal einmal ausführen:

bash $HOME/klipper-backup/script.sh

Falls dort eine Passwortabfrage kommen sollte, dann einfach den Token, den Ihr Euch auf Github erstellt habt, nutzen und so sollte auch keine weitere Abfrage mehr kommen.

Viel Spaß!

English Version:

If you play around with the Klipper settings in the configurations from time to time, then it would be great if there were regular backups that are saved externally.

While looking for a simple solution, I stumbled across the following page:
https://github.com/Staubgeborener/klipper-backup

The first step is to install git on the Raspberry or directly on a printer, such as a Neptune 4 Plus in my case.

sudo apt update
sudo apt install git

And now almost the most important thing:

git config --global credential.helper store

This is because this command is used to save the token that we will create during the rest of the installation, which is also used locally for authentication.
(This was also the reason why I kept getting error messages when running the script).

So if you get something like “remote: Invalid username or password.” or something similar when running the script, it’s because git doesn’t save the password directly, at least on the Elegoo Neptune 4 board.

We create a new repository at Github and a personal access token, which we give write permissions etc. to.

Then we start with the actual installation:

git clone https://github.com/Staubgeborener/klipper-backup.git && chmod +x ./klipper-backup/script.sh && cp ./klipper-backup/.env.example ./klipper-backup/.env

Next, we edit the .env file with an editor (e.g. vim / nano etc.)

nano klipper-backup/.env

We copy the newly created Github token to the place “github_token=”, write our Github user name in the appropriate place and of course enter our Github repository.

Then it looks something like this:

github_token=ghp_xxx
github_username=noccis-github
github_repository=elegoo_neptune4backup
branch_name=main
commit_username="mks"
commit_email=""

# Indivdual file syntax:
#  Note: script.sh starts its search in $HOME which is /home/{username}/
# Using below example the script will search for: /home/{username}/printer_data/config/printer.cfg

path_printercfg=klipper_config/printer.cfg

# Backup folder syntax:
#  Note: script.sh starts its search in $HOME which is /home/{username}/
# Using below example the script will search for: /home/{username}/printer_data/config/*
# `/*` should always be at the end of the path when backing up a folder so that the files inside of the folder are prop$
#path_klipperdata=printer_data/config/*
path_klipperdata=klipper_config/*

Here we are ready for the first time and turn to the moonraker.conf in Klipper.
Here we add the following and save the file:

[update_manager klipper-backup]
type: git_repo
path: ~/klipper-backup
origin: https://github.com/Staubgeborener/klipper-backup.git
managed_services: moonraker
primary_branch: main

But we also want to automate the whole thing a little:
And that’s why we’re creating a new service:

sudo nano /etc/systemd/system/klipper-backup.service

and that’s where we copy:

[Unit]
Description=Klipper Backup Service
#Uncomment below lines if using network manager
#After=NetworkManager-wait-online.service
#Wants=NetworkManager-wait-online.service
#Uncomment below lines if not using network manager
#After=network-online.target
#Wants=network-online.target

[Service]
User={replace with your username}
Type=oneshot
ExecStart=/bin/bash -c '/home/mks/klipper-backup/script.sh "New Backup on boot $(date +%%D)"'

[Install]
WantedBy=default.target

Please remember to adapt the corresponding values and paths to your environment.

We will reload the Deamon and then start the service:

sudo systemctl daemon-reload
sudo systemctl enable klipper-backup.service
sudo systemctl start klipper-backup.service

Optionally, you can of course install a cron, which then makes a backup every 4 hours, for example.

crontab -e

and the following will be inserted here:

 */4 * * * $HOME/klipper-backup/script.sh

But triggering an update via Mainsail or Fluid would also be somewhat practical. So we make this possible in the printer.cfg:

[gcode_macro update_git]
gcode:
    RUN_SHELL_COMMAND CMD=update_git_script

[gcode_shell_command update_git_script]
command: bash -c "bash $HOME/klipper-backup/script.sh"
timeout: 90.0
verbose: True

Done!

And in Fuidd it looks like this:

To make sure that everything is working properly, you can run the script directly in the terminal:

bash $HOME/klipper-backup/script.sh

If you are asked for a password, just use the token you created on Github and you should not be asked for another one.
Have fun!

Igniting the 3D Printing Spark

Reviving Blogs in the Age of Filaments and Firmware

Welcome to our digital workshop, where we’re here to boldly declare that the blog is not just alive; it’s buzzing with the energy of extruders, bed leveling, and firmware updates!

In a world saturated with fleeting trends, our corner of the internet is dedicated to exploring the dynamic universe of 3D printing and all things filamentous.

Amidst the sea of social media snippets, we’ve carved out a space to delve deep into the intricacies of Klipper, Filaments, HueForge, and the diverse array of printers gracing our creative landscapes – from the iconic Ender and precision-driven Prusa to the innovative Elegoo.

This isn’t just a revival; it’s a celebration of the resounding hum of 3D printers, the aroma of freshly loaded filaments, and the heart wrenching suspension of firmware upgrades.

As we unravel the mysteries of Klipper, traverse the vivid palette of filaments, and navigate the ever-expanding galaxy of 3D printers, our blog emerges as a haven for enthusiasts seeking more than just cursory glances at the latest prints.

Join us in this renaissance of blogging, where pixels and layers intertwine to weave a narrative of precision and passion. This is not merely a proclamation; it’s an invitation to explore the nuanced world of 3D printing, where each filament strand and firmware tweak contributes to our collective odyssey.

Stay tuned as we embark on a journey through the interconnected realms of technology and creativity. The blog is not just a vessel of expression; it’s a thriving ecosystem where Klipper codes dance, filaments unfurl, and printers hum in harmony.

The adventure begins, and the 3D printing saga unfolds before your digital eyes.