Archive3D

Selvinitieret, selvhostet projekt. Bygget og drevet af mig som arkitekt, product owner og reviewer, med AI som en overvåget "lærling" i udviklingsprocessen og i dele af selve produktet.

Archive3D tager en 3D-printet del fra idé til færdig print i én sporbar pipeline: design (parametrisk, CAD eller AI-assisteret), arkivering med versionering, slicing og afsendelse til printer med filamentsporing. Det erstatter spredte filer, manuelle indstillinger og tavs viden med ét søgbart system, hvor hvert print kan spores tilbage til sin kilde.

Tech stack

• Backend: Python 3.12, FastAPI/uvicorn, Pydantic v2, SSE til live-fremdrift (~10.000 linjer i kernepakken, ét API-modul på ca. 4.000 linjer plus 20 afgrænsede moduler)
• Frontend: Alpine.js + Tailwind, Vite-build, Monaco-editor, WebGL-viewere (3D-model og G-code)
• Geometri/CAD: OpenSCAD (headless, Manifold), FreeCAD, Onshape REST API, trimesh/numpy/scipy
• Slicing: Snapmaker Orca og PrusaSlicer, headless på serveren og på en desktop-agent; en fælles pakke til patching af 3MF (orca_patch)
• Enhedsintegration: Moonraker (Klipper, 4-værktøjs toolchanger), OctoPrint, ArchiveFLMT (spolesporing), ArchivePCB (stencil-pipeline)
• AI: DeepSeek via litellm — tagging, semantisk søgning, G-code-analyse og en agentbaseret CAD-designløkke
• Drift: systemd-services og timere, uv-styret Python, TOML-konfiguration (dev/prod), Gitea til versionsstyring, fastlåste/vendorede tredjepartsbiblioteker

Største bedrift At gøre AI-genereret CAD pålideligt nok til at bruge. En sprogmodel, der bliver bedt om at designe en del, melder selvsikkert succes, selv når features stille mangler. Jeg kørte først strukturerede gennemførlighedsstudier, målte fejlmønstrene (fx fejlede 2 af 3 kørsler af en svær kabinet-opgave, hver på sin måde, mens modellen meldte "verificeret"), og byggede derefter produktionsfunktionen efter resultatet: AI'en bedømmer aldrig sit eget arbejde ved at læse sit eget output — systemet måler den faktisk kompilerede geometri i deklarerede feature-punkter og fører resultatet tilbage. Funktionen kører i produktion.

Problemet

3D-print fra hobby til småproduktion er overraskende fragmenteret:

• Design bor i flere værktøjer (OpenSCAD, FreeCAD, Onshape, downloadede 3MF-filer), og kilden til en printet del går let tabt.
• Slicer-indstillinger (kvalitetsprofil, filament pr. værktøj, support, sømme, prime tower) indtastes manuelt for hvert print, hvilket er langsomt og fejlbehæftet. Et multimaterialeprint på en 4-værktøjsprinter multiplicerer fejlmulighederne.
• Ingen ved, hvilken spole der blev brugt, hvor meget der er tilbage, eller om profilens temperatur passer til det faktiske filament.
• At finde "det beslag jeg printede i marts" betyder at bladre i mapper.
• Slicing er bundet til en GUI på én desktopmaskine og kan derfor hverken automatiseres eller køre på en server.

Omkostningen pr. print er ikke dramatisk — det er den akkumulerede friktion, det spildte filament, de fejlslagne print og det forhold, at viden sidder i ét hoved. Det er samme type problem, man finder i mange små udviklingsteams: manuelle overleveringer, ingen fælles sandhedskilde og ingen sporbarhed.

Arkitektur og løsning

Overordnet form. Én FastAPI-service ejer arkivet og udstiller en browser-UI. Omkring den sidder små komponenter med ét formål, der integrerer via HTTP/SSE eller filsystemet:

Dataflow. Design (OpenSCAD / FreeCAD / Onshape / AI / import) → bake til 3MF med kilden indlejret → arkivér som ny version → slice (server, desktop eller manuelt) → G-code parses og valideres mod en preflight-tjekliste → send til printer med spoleopløsning → filamentfradrag via en sidecar-fil.

Designvalg, der er værd at fremhæve

• Filsystemet som database. Arkivet er et almindeligt mappetræ (model/vN/ med 3MF, G-code, thumbnail og metadata.json; projekter er undermapper). Ingen migreringsbyrde, nemt at tage backup af, kan inspiceres med standardværktøjer og kan genskabes, selv hvis applikationen forsvinder. Et bevidst kompromis mod forespørgselskraft, acceptabelt i denne skala.
• Kilden følger artefaktet. 3MF-filen indlejrer den oprindelige .scad/.FCStd-kilde, så "Design" på et arkiveret print genåbner præcis det design, der skabte det. Ny bake giver v2, v3… og bevarer tags og noter.
• Én implementering, tre eksekveringsveje. Server-slice, desktop-headless-slice og åbn-i-GUI bruger samme patching-pakke i stedet for tre separate implementeringer. Erfaringen (også nedskrevet i mine projektnoter): hver ny slicing-parameter skal kobles på alle tre veje — en tilbagevendende regressionskilde, som jeg nu behandler som et eksplicit punkt på tjeklisten.
• Opløs konfiguration, antag den ikke. Slicer-profiler er deltaer over en inherits-kæde; pipelinen opløser dem fuldt ud før slicing, fordi et stille fald tilbage til standardværdier (forkert lagtykkelse) er værre end en fejl.
• Integration uden hård kobling. Moonraker, OctoPrint, ArchiveFLMT og desktop-agenten er alle valgfrie og sat op i TOML; systemet degraderer pænt (statusindikatorer grøn/gul/rød) i stedet for at fejle, når en af dem mangler.
• Fastlås og vendor det skrøbelige. Gridfinity-biblioteket er vendoret på en fastlåst commit med et bevidst manuelt opdateringsscript; desktop-Orca er rullet tilbage til en fast version, efter jeg sporede et nedbrud til en upstream-regression; Pythons virtuelle miljø er bundet til en administreret fortolker, efter en OS-opgradering ødelagde det.
• Svære fejl løst ved roden. Et nedbrud ved server-slicing blev sporet til en reel upstream null-dereference i Orcas headless CLI og rettet ved at patche en vedligeholdt fork bygget fra kildekode — efter at workarounds på konfigurationsniveau viste sig at være blindgyder. Et beslægtet desktop-nedbrud blev løst med versionsfastlåsning frem for flere patches. Jeg dokumenterer også blindgyder, så de ikke gentages.
• Sparsom, ærlig teststrategi. Enhedstest dækker den risikable logik (AI-CAD-tjek, Orca merge/slice, opdeling i flere plader, parsing af OpenSCAD-parametre, Gridfinity-seeding). Meget af UI og enhedsintegration verificeres mod live hardware frem for med mocks — et bevidst valg, som jeg i et team ville stramme op med CI.

AI som lærling

AI har to adskilte roller, og jeg holder dem adskilt.

1. AI i selve produktet (DeepSeek via litellm)

• Tagging og søgning: en natlig batch genererer tags og beskrivelser ud fra OpenSCAD-kilde, 3MF-metadata og mesh-heuristik. Søgningen kører i niveauer fra simple metadatafiltre op til AI-matching på billede plus metadata, så billige forespørgsler forbliver billige.
• G-code-analyse: asynkron AI-kommentar i viewerens sidepanel.
• AI-assisteret design (hovedfunktionen): brugeren beskriver en del i en chat. Systemet laver en plan med featureliste og milepæle, bygger OpenSCAD-scriptet milepæl for milepæl mod den rigtige headless-binær, renderer fire visninger pr. trin og måler den kompilerede geometri i deklarerede feature-punkter. Opfølgende beskeder klassificeres som parametriske (øjeblikkelig variabelrettelse), strukturelle (omplanlæg fra første berørte milepæl) eller tvetydige (spørg, gæt ikke), og AI'en oplyser sin klassifikation. Resultatet gives videre til den almindelige Design/Customize/Bake-vej — mennesket redigerer og godkender det som ethvert andet script.
• Værn lært af måling, ikke antagelser: planlæggerens prompt koder rækkefølgeregler, der er fundet i fejlslagne kørsler (fx skal en udskæring komme efter den afrunding, den overlapper, ellers fylder afrundingen den stille op igen). En reservemodel bruges, hvis planlæggeren "spiraler" uden at levere en parsbar plan. Den stærkere planlægningsmodel bruges ikke til byggetrin, fordi den ikke kan se billeder og fejler lydløst frem for højlydt.

2. AI i udviklingsprocessen (human-in-the-loop)

Jeg styrer arbejdet — krav, arkitektur, afvejninger, accept — og bruger en AI-kodeassistent til implementering, med disse arbejdsregler, som jeg håndhæver:

• Stol aldrig på en selvrapporteret "verificeret". Jeg tjekker renders og mesh-data selv; AI'ens succesmelding er ikke et bevis.
• Spike før bygning. To Fase 0-gennemførlighedsstudier (FreeCAD- og OpenSCAD-backend) med de samme benchmark-opgaver gik forud for produktionskode. Resultat: den fælles rodårsag var manglende tjek pr. feature, og den billigere, headless backend var den, der skulle i produktion.
• Vedvarende projekthukommelse og specifikation. En levende specifikation, daterede statusnotater og en notefil fastholder beslutninger, blindgyder og konventioner, så kontekst overlever mellem sessioner, og assistenten ikke gentager gamle fejl.
• Mennesket ejer de risikable handlinger. Alt med hardware, eksterne tjenester eller uigenkaldelige ændringer bekræfter jeg selv; assistenten tester i scratch-miljøer.
• Dokumentation som biprodukt. Specifikation, README og statusnotater opdateres med dato, når funktioner leveres.

Lederens refleksion

Det her har projektet lært mig, og det kan overføres direkte til et udviklingsteam:

1. AI øger gennemløbet, men flytter flaskehalsen til verifikation. Den værdifulde kompetence er at designe tjek, der ikke afhænger af AI'ens egen vurdering. I et team betyder det reviewstandarder, automatiserede acceptkontroller og en kultur, hvor "værktøjet siger, det virker" aldrig er slutningen på samtalen.
2. Mål, før du forpligter dig. Et lille, tidsbegrænset studie med defineret benchmark gav en databaseret beslutning (og et ærligt "3 kørsler er en start, ikke en pålidelighedsmåling") på få dage. Den vane sparer måneder på større satsninger.
3. Hold menneskets beslutningspunkter eksplicitte. AI'en klassificerer, foreslår og bygger; mennesket godkender og ejer resultatet. At definere, hvor den streg går — pr. funktion og risikoniveau — er en ledelsesopgave, ikke en teknisk eftertanke.
4. Foretræk kedelig, inspicérbar arkitektur. Filsystemlagring, valgfrie integrationer, fastlåste afhængigheder og én fælles implementering bag flere indgange er uglamourøst, men det gør, at et lille team kan forstå, fejlsøge og overdrage systemet.
5. Skriv blindgyderne ned. At dokumentere det, der ikke virkede (og hvorfor), var den billigste måde at undgå dyre gentagelser på — for mig, for en AI-assistent og lige så meget for nye kolleger.
6. Integration er der, hvor indsatsen går hen. Det meste af vanskeligheden var ikke algoritmer, men hardware, værktøjsversioner, udokumenteret adfærd og lydløse fejl. En leder, der planlægger for degraderede tilstande, statussynlighed og versionsfastlåsning fra start, sparer teamet for de værste overraskelser.

Ærlige begrænsninger. Systemet er single-user og selvhostet, bygget over ca. seks måneder (april–oktober 2026). Det har ingen CI, begrænset automatiseret testdækning af UI- og enhedslagene og ingen adgangsstyring for flere brugere. I en virksomhed ville jeg tilføje netop de ting først. Det, projektet viser, er tilgangen: afgrænset problem, målte beslutninger, eksplicit arkitektur og AI brugt som en overvåget accelerator frem for en autoritet.