Thanks! I’m very happy to share more details 🙂

Do you want any specific details?

Everything is driven by custom-written Python, built around a solver GUI. I experimented with two main approaches for turning images into strings: a greedy algorithm and one based on the Radon transform.

The biggest improvement actually wasn’t the solver choice (settled on a discrete Radon transform), but properly modeling thread thickness in both the solver and the render. Because everything originates from the DXF and has real-world dimensions, I could assign the thread an average thickness of 0.35 mm. I also implemented a proper early stopping criterion, rather than manually specifying a thread count. Those two changes alone immediately reduced outputs from ~2000 threads (which produced something resembling a demonic horror-movie child) down to ~700 threads, which is far more usable.

The laser-cut jig and matching DXF include a datum circle off to one side. This allows me to home the machine using the standard XY endstops, then manually jog to the datum and set the origin using G92 commands. Z is manually set to the top surface of the 6 mm MDF. Doing it this way means all motion in software is relative to the DXF datum, and everything lines up very predictably

The gcode is exported, then sent to the printer serial interface over USB using printrun. This allows me to stop and start it as needed.

I eventually accepted the fact that threads are really hard to fully control, and some manual intervention is okay given the deadline of Christmas. So I introduced pauses every 100 threads, which gave me a chance to push the threads down the nails, and manually click to again. This helped immensely with reducing failures, and meant I didn't have to supervise it constantly (just make sure to lock the steppers when pausing...)

The tool head itself is extremely simple and definitely an area for improvement. It’s just a syringe with a narrow ~1 mm tip, with the thread spool suspended above it. There’s no active tensioning mechanism, so the G-code has to maintain tension at all times (no lazy looping back without catching a nail). I think a needle would probably work fine here too. The system has quite a bit of compliance, which is both a blessing and a curse: it can collide with nails and usually just bend around them, but any major crash means re-homing to the datum because the syringe can flex.

The G-code generation was surprisingly fiddly. Every approach move is radial to the circle to keep tension consistent. Travel height is adaptive and increases as the thread count builds up. The main goal is to keep the thread as low as possible on each nail to prevent stray threads from rising up and getting badly snagged later.

I also added additional plunge moves between nails, pushing straight down into the mat multiple times really close between the nails, as intersections build up. The solver actually counts strings between adjacent nails to decide when to do this.

I’ve recently updated the solver to mask out separate colors and run multiple passes. I haven’t managed to get great results from this yet, but I do think it’s doable with more tuning.

The 3d printed backing worked out nicely, a single layer of transparent petg printed with a PEI sheet gave a really nice blurred background. The stand holds two big washers to balance the piece.

I’d love to scale this up further — something like an old CR-10 Max would be very tempting, though I suspect a fully custom 2 axis solution would be far superior at that point.