2025, the year I made hp-sim5

I spent 2025 simulating Hangprinter.

Before 2025 I envisioned giving normal people economically useful machines via the Hangprinter Project and its community, kind of like this:

The improvement loops were weak, this didn't work well enough. My updated understanding is that AIs will get robots first, before normal people gets them:

This is the way for every product or project. AI is powerful and it is not going away.

So I'm adapting the Hangprinter Project to the AI future. In 2024 I wanted to automate the whole Hangprinter Project, starting with support agents (see hp-support and Hangprinter Knowledge Hub). In 2025 my focus has shifted from "automate the Hangprinter Project" to "insert Hangprinter into the new age". AIs are not independently self-improving yet, so neither is Hangprinter.

But the intelligence explosion is still expanding, and whatever the AIs can't see, control, or optimize will soon be left in a category that has no name yet but will be described as unoptimized, hobbyist, micro-scale, handi-craft, uneconomical, manual, niche, old-fashioned, antique, part of History, slow, weak, hard, dumb, irrelevant, you get the idea.

What Does it Mean for Hangprinter to "Fit Into the AI Age"?

What we call AI can be often be described as "simulating an interesting process", most often based on process output examples, and then harvesting some artifacts, side-effects or breadcrumbs dropped from the simulation.

The most relevant AIs of 2024 simulated text generation, the process previously known as "writing". They can also simulate "thinking", "painting", "speaking", "trading", "driving", "walking" and so on. Even evolution and the weather are simulated all the time. We just call it "hw design" and "weather forecasts". Sometimes, if the simulations are very static, simple, or bare-bones we sometimes call them "optimization" or "statistical regressions".

So for Hangprinter to merge with the singularity we need to fully embrace the simulation paradigm. Complex simulations of complex processes. Making Hangprinter available to AI in 2025 simply meant building a simulation environment, and ignoring the physical parts of the project altogether.

Everything will be done in this simulation environment: The hardware, the software, the physics, the gcode execution. We can even imagine debugging market dynamics down to individual businesses and so on. Our physical machines and their outputs will simply be side effects from this perspective.

So I named the simulation environment "hp-sim" and went into the rabbit hole of creating it. My community engagement stats that were already declining since 2021 went to zero in 2025. No Twitter, no Youtube, no email, (almost) no blog posts.

The focus has paid off.

What Have I Delivered?

Simulating Hangprinter in 2025 is very hard. (In 2024 is was impossible, in 2027 it will probably be trivial.) The resulting hp-sim5 repo is called hp-sim5 because four attempts before it failed:

• hp-simulator-chrono (22 Jan, 2025 - 27 Jan, 2025). I invented ANCF rope simulation in here. Interesting, maybe even novel and realistic to model a line as one or a few thin weak beams in parallel, with separately tunable bending stiffness and axial (pull) stiffness. Friction between strands add bending resistance. However, way too slow for realtime. RIP.
• hp-sim2 (Feb 11, 2025 - Feb 12, 2025). An attempt to extract a core of Chrono simulator into modern C++ to speed things up. RIP.
• hp-sim3 (Feb 23, 2025). An attempt to use a template for Isaac Lab projects, and shoe-horn Hangprinter in there to get reinforcement learning (RL) control going. Failed because the environment didn't have any primitives for ropes/lines/cables. RIP
• hp-sim4 (Mar 3, 2025 - Apr 2, 2025). An attempt to build ropes in Isaac Sim (the physics environment that Isaac Lab uses). Failed because the physics engine was too heavily geared towards rigid bodies, and good lines could not be contructed as chains of rigid bodies. RIP

Luckily, hp-sim4 led me to Mattias Müller's work on rope simulations. First his long distance joints and later his XPBD and CableJoints, which was performant and physically accurate cable simulations. Finally, exactly what hp-sim needed.

No open source implementations of CableJoints existed, so for ca two and a half months (Apr 3, 2025 - Jun 24, 2025), I implemented a 2d version of a CableJoints and an XPBD physics engine. Inputs, outputs, rendering, double implementations in Python and Javascript, CI testing, user interaction, constraints, friction, etc. End-to-end, specialized to our needs.

Then, with the Slideprinter modelled, lines and all, it needed control software. We needed a 3d printer firmware inside the simulator. I spent 10 days implementing a custom firmware that work both with the Python and the Javascript CableJoint libraries.

I knew I needed real firmware though, so after Summer (September 9 and one week onwards) I tried to simulate a realtime AVR processor on my desktop machine and run Klipper on it. I could not reliably simulate a realtime chip on my non-realtime linux kernel. No matter how much buffering and other synchronization I added, I could never make that combo deterministic. I even installed a realtime version of the linux kernel on my desktop before finally backing off from the idea of simulating the whole AVR processor.

Klipper already had rudimentary Hangprinter support and good tools for running or debugging on host. So adding basic Klipper firmware control via "batch dump files", basically just long lists of motor commands and time stamps, was very easy. I spent ca 1 month improving the user interface, adding different Slideprinter designs, implementing quality control, support for parallel simulations etc.

The quality control made it possible to track if a firmware change improved print quality or not, so it was time to improve firmware. I spent one weeks developing two brand new flex compensation algorithms and implementing them into Klipper (Oct 10, 2025 - Oct 17, 2025). It's way better than the legacy flex compensation in every way. Details here: a Klipper PR.

Now, Klipper is great but I didn't want it to be the only firmware in hp-sim. I wanted hp-sim to support ReprapFirmware as well. However, ReprapFirmware had no support for running on host (desktop machines) or dumping lists of time stamped motor commands. I wrote a roadmap and went on to spend a full month on adding ReprapFirmware batch mode support (Oct 19, 2025 - Nov 20, 2025).

With the new flex compensation algorithms, both Klipper and ReprapFirmware almost supported 8 anchors. They just lacked a proper forward transform. So I spend one week (Nov 25, 2025 - Dec 1, 2025) implementing a forward transform thats way way superior in every way, compared to what was available before.

On Dec 1 2025 Klipper got the remaining parts of Hangprinter support that only ReprapFirmware had before (buildup compensation, block-and-tally style gearing, etc).

At this point I charged ahead with improving auto calibration. Hangprinter has had a kind of working auto calibration since 2017, but it had many problems. Ironically, it was labor intensive and kind of unreliable.

Auto calibration is a dynamic process where one gcode is sent, then some time passes, physics happens (is simulated), a measurement is done and handled, then some more lines of gcode etc. Clearly, the "batch mode" dumps of motor commands I had been using did not suffice for developing auto calibration.

I spent four days (Dec 2, 2025 - Dec 5, 2025) implementing a "server mode" that let's the host version of ReprapFirmware run idle and wait for gcodes sent to its http endpoint (I also built the whole http server).

One of the problems of the old autocal was that it could not collect good data automatically. So I spent three days (Dec 7, 2025 - Dec 9, 2025) scripting the interactions (sending gcode, wait, read reply etc) for collecting structured encoder data from a large area of a non-calibrated Slideprinter (or later also Hangprinter++).

Another one of the problems of the old autocal was that it was too slow so I developed a new idea for autocalibration on Dec 9 and spent seven days (Dec 10, 2025 - Dec 16, 2025) implementing it and comparing it to the previous autocal method. The results so far are promising, the new feature based method runs 10x faster and has the same accuracy as the (new improved version of the) old method. The new method also succeeds every time, while the old one often needs a couple of tries. Which one will perform best in 3d and with more diverse setups remains to be seen.

Stop and Breathe

All of this work, from Jan 22 to today (Dec 17) was greatly sped up by various AI tools but also by the simulation itself. Being able to test things right in the simulation has made experiments 10x cheaper, faster, and more pleasant. I've literally run hundreds of experiments that helped my understanding of Hangprinter's software and mechanics, each of which would have either been impossible or taken at least one day to do physically.

Where is HP5?

Still left to do is:

• Upgrading all of hp-sim from 2d to 3d.
• Implementing spool simulation that includes realistic line buildup.
• An actual physical HP5 design, with BOM, suggested layouts and verification of various design decisions in simulation.
• A hp-sim mode to conduct batches of parallel experiments.
• Support for rotational degrees of freedom. (6dof)

If you want you can go and play with the simulation here Try clicking around. Many UI details are undocumented. I'm especially not proud of "Trace enabled, then triple right-click". Some instructions on how to use the simulation is scattered around the repo.

I'm including prompts and responses from the hp-sim5 repo here.

- tobben

2025-12-17T12:00:00Z Torbjørn Ludvigsen I spent 2025 simulating Hangprinter.

Promps and Code

I've attempted AI coding for 2-3 years now, and my mind is increasingly blown. Two or three LLMs later I think we'll start swapping out coding (in formal language) with prompting (in natural language) even more than we already do. I have some insights about how this might look.

The model doesn't think in English. Run the same prompt in Norwegian and English and you get similar behavior. The internal state isn't words but a shared feature space: text maps into it and back out again. If that space drives behavior, reproducibility depends on the inputs that shape it. Prompts and context are part of the build recipe.

In open codebases, compiler flags and build scripts are public, versioned, and replayable. Treat prompts the same way so anyone can rebuild the state that produced a change - GCC-style self-hosting for model-assisted code.

Formal languages map cleanly. They are precise, testable, and often mutually translatable, so they fit the internal representation. Hence model -> code -> compiler -> machine code starts to look like a bootstrap loop: models generate code that generates more code. Like RepRap and compilers, it self replicates and will obviously grow geometrically (or exponentially, or just "explode"). We must, as usual with these tech developments, join the ustoppable wave, prepare for the explosion, and try to maybe steer the explosion towards ethical and humane outcomes.

To keep that loop trustworthy, record prompt, context, model version, and decoding settings alongside the emitted code, just like pinning toolchains and build flags. If the code is open, the prompt recipe should be open too, for the same reasons we publish Makefiles and CI specs.

What the loop actually looks like. Day to day: human or model -> prompt -> model -> code or text -> compiler/interpreter -> machine code -> processor -> result. I judge the result, adjust prompt or context, and try again.

Models don't retain a whole program across calls, so source code remains the durable representation we share. To make that code self-reproducible, store the prompt/context bundle next to each commit, along with the exact model and decoding settings. Do it via a git hook or a hook in your LLM framework.

This doesn't replace code; it records how this version came to be and makes the repo rebuildable end-to-end, not just at the compiler boundary. We should bake an AI into every repo via the knowledge and intent we keep with it

- tobben

2025-10-08T12:00:00Z Torbjørn Ludvigsen I've attempted AI coding for 2-3 years now, and my mind is increasingly blown. Two or three LLMs later I think we'll start swapping out coding (in formal language) with prompting (in natural language) even more than we already do. I have some insights about how this might look.

Simulation and HP5 Work

So I made a Slideprinter simulation, check it out at hangprinter.org.

It's really cool because it simulates many aspects of a real machine:

• I wrote a whole library to simulate the lines. Check out hp-sim5. This has been a grueling multi-month effort. Good cable/line simulation is not widely available from anywhere else.
• The simulation runs on a state-of-the-art XPBD time loop that stays close to physical reality.
• The move commands comes from real Klipper, with a real Hangprinter config.
• Klipper can stream commands to the simulaton too (only recommended if a real mcu is attached, or you run klipper_mcu on a realtime linux kernel).
• The simulated steppers can lose steps; their torque varies with speed and load.
• Spools can be clicked, grabbed, and pulled with your mouse or touch screen.
• Simulation speed can be cranked up 100s of times beyond realtime for faster experiments.
• The logo print simulation tracks millions of individual step pulses and micrograms of deposited material.
• It's implemented both in Javascript and in Python.
• The whole machine and its simulation scene and config is described in a file format called USD, see slideprinter.usda, which enables us to be data-driven, but also compatibility with various 3d modelling, reinforcement learning, and simulation softwares such as Blender and Isaac Sim.
• The cable solver models slack, stretch, wrap, and friction straight from that USD geometry, keeping the kinematics honest.
• The Python build can hand off the same solver to NVIDIA Warp, so long jobs can use the GPU.

I think simulations are most important part of the Hangprinter Project. I'd like to automate the hardware design and fw configuration. We just now became able to quantify comparisons between Hangprinter hardware+config setups. Just measure how close the tool head is to an optimal route at all times, compared to the exact positions in the gcode file. Optimize over CAD parameters and config values, and write a simple cost function.

So I'll keep focusing on simulation, not hardware. But it's good to have ideas of cost regardless, especially since we have to integrate tightly with a firmware in order to simulate. The firmware implies ceirtain hardware which implies cost.

Cost Estimates

I computed some BOM cost estimates for various alternatives for the HP5 today. It includes three versions I've been thinking about. All cost estimates assume Swedish taxes and shipping, plus a 10% inflation in all prices since 2021. The full spreadsheet is available here.

Baseline v5 (Roughly HP Performance)

This is the machine that the HP4 prototype was always meant to be. ODrive S1 boards, Motion tracking with Arducam, Duet3 6XD board etc. Cost: 2500 USD

Software work required: We'd need to implement the Duet CAN Protocol in the ODrive firmware, which is hard, and the machine will be useless until it's done. We could dodge this hard sw work with 5 x 1XD boards, but that brings total cost up by 384 USD, to 2840 USD and defeats some of the purpose with the HP5/HP Performance.

Duet HCL Nema v5 (Roughly HP Convenience)

The smallest change to get away from BLDC and ODrive, dodging protocol implementation work and cost, sacreficing performance. The 5 x ODrive S1s are swapped with Duet's closed loop stepper drivers (Duet3 Expansion 1HCL), and the 5 x BLDC motors are swapped for a standard set of Nema17 motors. Cost: 1750 USD If we skip the encoders for this option, cost is down to ca 1600 USD.

Software work required: We would need to do implement torque mode in the expansion board and Duet CAN Protocol. That shouldn't be too hard, and the machine can be useful without it as well.

Klipper Driven HP5 (Roughly HP Core)

No closed loop control, no torque mode. The Duet3, the 5 x ODrive S1s, and the 5 x BLDC motors are swapped with 5 microcontroller units and 5 Nema17 motors. The 5 microcontroller units will be driven by Klipper running on the Raspberry Pi 5 via CAN and a USB to CAN bridge. Also, include one load sensor per anchor is included in this Klipper driven version. Cost: 1050 USD Adding closed loop to the Klipper Driven HP5 could come as cheap as 5x20 = 100 USD (source) bringing total cost up to 1150 USD.

Software work required: A lot. Klipper's Hangprinter support is very basic. But although its a lot of work, none of the work is very hard, since it's mainly re-implementation into Python, and we have the simulator to quickly test everything. The machine is potentially useful even without software upgrades, since the basic Hangprinter support in Klipper already does work.

Thoughts

The Duet options might still make sense for those who need performance and with the minimal changes compared to something that has been built proven to work (the HP4 prototype). The Klipper option makes most sense to work on for people who want to go cheap and develop, and still maintain the possibility of adding performance later.

- tobben

2025-09-24T12:00:00Z Torbjørn Ludvigsen So I made a Slideprinter simulation, check it out at hangprinter.org.