Kossel Homing Simulator

Inspiration

Delta printers are mechanically expressive: three independent carriages move on vertical rails while six fixed-length rods keep the effector level. Homing is the clearest expression of that mechanism. Each carriage rises, reaches its own top switch, and stops with a short mechanical click.

I could not keep another full-size Kossel in a small Japanese living room, so I decided to preserve that experience as a virtual machine.

What it does

Kossel Homing Simulator is a browser-based digital twin of an Anycubic Kossel Linear Plus. It accepts G-code, renders the complete mechanism in Three.js, and executes G28 by driving three motor/belt/carriage chains until each carriage physically actuates its own modeled microswitch. Fixed-length parallel rods then determine the effector pose through delta kinematics.

The dashboard exposes live machine state, temperatures, endstops, motion health, and a Moonraker-like API subset. The primary Build Week result is its endstop sound: the click is emitted by the same simulation event that latches the switch, rather than by a separate animation timeline.

How it was built

The project combines a deterministic FastAPI simulation loop with React, TypeScript, React Three Fiber, and Web Audio. The machine geometry is grounded in a captured Klipper configuration, the Anycubic assembly manual, and attributed Kossel CAD assets.

For the microswitch, a reduced-order model estimates stored spring energy, contact velocity, impact timing, and structural modes. The browser synthesizes filtered broadband contact energy plus damped contact/lever, switch-housing, and mount/tower responses. Every event is deterministic and includes its tower, simulation timestamp, force, energy, modal frequencies, and bounce timing.

How Codex and GPT-5.6 were used

This is an honest extension of an existing simulator. The immutable starting-point-v1 tag contains the pre-Build Week machine, dashboard, kinematics, homing motion, motor audio, and deliberately simple switch tone.

During Experiment 01, Codex with GPT-5.6 Sol inspected the assembly manual and existing code, researched the switch mechanism, derived the reduced-order acoustic model, implemented a typed backend/frontend event contract, connected sound to physical endstop latching, and added tests and technical documentation. Its key contribution was keeping assumptions, simulator state, Web Audio, TypeScript types, and verification coherent across the repository.

Primary Codex Session ID: 019f7f2e-e7a5-75c3-a5ed-e9a28769d5be.

Challenges and decisions

To be honest, Codex with GPT-5.6 Sol handled the difficult technical work. My own challenge was simpler: paying for the GPT account from a tight hobby budget. That is only partly a joke.

The important engineering decision was not simply to make the sound brighter. Codex had to decide what the available evidence could actually support. The result is explicitly a real-time reduced-order model, not a claim of calibrated finite-element or acoustic simulation. Internal masses, stiffnesses, damping, and bounce timing remain engineering estimates until a physical switch is measured.

The other key decision was synchronization. The backend emits an acoustic event only in the branch that detects sufficient switch travel and latches a tower. The frontend consumes every unseen sequence, preserving the timing when several contacts arrive in one WebSocket update. Visual motion, endstop state, and sound therefore share one source of truth.

Accomplishments

• A complete, inspectable delta-printer homing mechanism rather than a toolhead animation.
• Independent physical endstop sensing and smooth carriage stopping.
• A deterministic, source-separated snap-action transient synchronized to actual simulated contact.
• A portable one-command judge path with backend tests and frontend production build verification.
• Clear provenance separating the pre-existing simulator from the Build Week GPT-5.6 contribution.

And yes: technically, everything in the list above was implemented by Codex with GPT-5.6 Sol. I supplied the Kossel, the obsession, and many rounds of "that is not カチッ yet."

What is next

The next step is to grow this homing experiment into a fuller physical Kossel in cyberspace. I want more of the machine's behavior to emerge from how its parts are assembled: driver, motor, pulley, belt, carriage, rods, effector, hotend, frame, and fans. That includes more realistic motor sound derived from motor and belt dynamics, fan-driven airflow and cooling, thermal behavior, and filament flow.

I also want to calibrate the current microswitch model against a measured physical SS-style switch using microphone recordings, high-speed contact timing, damping estimation, and material-specific mount measurements. The goal is not only to make the virtual Kossel look real. It is to build simulated printer functions that behave like the real machine in its own cyber space.

Built With

• codex
• fastapi
• gpt-5.6-sol
• klipper
• python
• react
• three.js
• typescript
• web-audio-api