OctoPrint is a full-stack web application for controlling and monitoring 3D printers. In production it runs as a Python server that exposes a Flask-based REST API and a SockJS/WebSocket real-time channel, while serving a Knockout.js single-page frontend. The core system talks to printers over serial connections through a stateful connector, parses G-code for print-time and filament analysis, manages file storage across local/SD/printer backends, coordinates slicing jobs, captures and renders timelapses, and enforces granular permissions with user/group management. It is a monolith with a deeply embedded plugin architecture: mixins (StartupPlugin, SettingsPlugin, BlueprintPlugin, EventHandlerPlugin, etc.) and hook dictionaries let third-party code extend nearly every layer, from API routes to G-code processing to the UI. The primary entry points are the `octoprint` CLI (serve, config, user, plugins, timelapse, analysis), the package's `__main__.py`, and the server initializer that wires together settings, logging, plugins, event management, and printer connectivity. Data flows center on the frontend interacting with REST/WebSocket endpoints, which delegate to core managers: `FileManager`, `SlicingManager`, `PrinterStateConnection`, `EventManager`, `Timelapse`, and the serial connector. External dependencies include sarge/pyserial for serial and process execution, ffmpeg for timelapse rendering, requests for update checks and plugin repository access, and optional network services (announcements, tracking, discovery). The codebase contains an extensive test suite spanning unit tests, HTTP API tests, serial parser tests, and Playwright end-to-end tests, plus thorough Sphinx documentation. OctoPrint is actively maintained, with recent commits, a large issue tracker, and a mature contributor ecosystem. The backend uses modern Python packaging, Pydantic schemas, and pinned dependency ranges, but the frontend carries significant legacy weight: Knockout.js, jQuery, Bootstrap 2/3-era assets, and deprecated API methods marked for removal in 3.0.0. This mixed state makes the project solidly engineered but with noticeable technical debt. It is not a data-research repository; the data it handles is operational telemetry, G-code metadata, user settings, and printer state, all serving real-time control rather than analytical workloads.
ESP3D is a feature-rich embedded firmware for ESP8266/ESP32 microcontrollers, designed to serve as a Wi-Fi/Ethernet bridge and full-featured controller for 3D printers, CNCs, and similar equipment. The firmware provides a modular architecture with support for multiple network protocols (HTTP, WebDAV, FTP, Telnet, WebSocket, Bluetooth), a web-based user interface, file system management (SD card, flash filesystems like LittleFS/SPIFFS), sensor integration (DHT, BMP280), Lua scripting, and graphical displays via LVGL or TFT_eSPI. It includes a comprehensive command system (ESPxxx commands) for configuration and control, with authentication levels and persistent settings. The codebase demonstrates solid engineering for an embedded Arduino project, with clear separation of concerns between core services (serial, network, display, filesystem) and a message-passing inter-module communication pattern. It bundles many well-known third-party libraries (LVGL 8.2.0, TFT_eSPI 2.5.43, SdFat 2.2.3, EspLuaEngine, arduinoWebSockets) directly in the repository, ensuring reproducible builds but also creating a maintenance burden. The firmware is actively maintained with a responsive issue tracker and regular commits, though the reliance on pinned library versions and heavy conditional compilation introduces some technical drift.
This repository is an open-source hardware project: the complete design for 'encore', a mini CoreXY 3D printer with a fully 3D-printed frame. Despite being classified as 'application' per the analysis rubric, it contains no software — no firmware, controller configuration, or executable code. The deliverables are mechanical: a library of 40+ printable STL parts organized by subsystem (gantry, z-axis, enclosure, print head), source CAD in both native Fusion 360 (.f3z) and neutral STEP (.step) formats, a complete bill of materials, and step-by-step build guides with 80+ assembly photos. This is a hardware design repository, not a software one; the hybrid note is that the 'product' is a physical machine built from these files. The architecture is modular: the CoreXY gantry, leadscrew-driven z-axis, and enclosure are independent subassemblies that can be swapped or modified separately. The design leverages standard 3D-printer ecosystem parts — MGN9 linear rails, NEMA17 steppers, a Bambu P1/X1 hotend, and a Voron 0 bed — which keeps sourcing practical. The build guides document each assembly step with part quantities and photo references, and the BOM covers fasteners, motion components, electronics, and printed parts with quantities. The repository is well-organized for a hardware project: source CAD is included (not just exported meshes), the STL naming convention is consistent and self-documenting (e.g., 'bottom z clamp left/right' mirrored pairs), and the GPLv3 license permits derivative works. Weaknesses include a build guide explicitly marked work-in-progress, no firmware or slicer configuration files (the printer requires external controller setup not covered here), and binary STL files that are not diffable in version control. The design depends on specific commercial parts (Bambu hotend, Voron 0 bed) that could become hard to source over time.