Project Logs

Collapse

• Bringing the brains online: Klipper, quad-Z, and sensorless endstop tuning.

  Nick • 06/14/2026 at 13:40 • 1 comment

  The frame and wiring are done, so this milestone is about the part that turns a
  pile of aluminum and steppers into something that actually moves: the software.

  M3-CRETE runs Klipper on a Raspberry Pi 5, driving a BigTreeTech
  Kraken — the 8-driver board with onboard TMC5160s. That driver count is exactly
  why we picked it: the full machine is 4× Z + 1× X + 2× Y + 1× extruder = 8 motors,
  all on integrated high-current drivers, with the concrete pump handled separately
  (more on that below).

  We're bringing it up in stages instead of flashing one giant config and
  hoping. Stage 1 is just the four Z motors on the first four driver slots, with
  sensorless homing — no limit switches anywhere on the machine. Each Z corner
  drives up into the top brace until its TMC5160's StallGuard fires, and that stall
  point becomes the corner's zero. Four corners, four independent stalls, coplanar
  without a probe (ever gotten wet concrete on an endstop? sensorless isn't
  a flex here — it's the only option that survives the environment.)

  Two things that will bite you on a Kraken
  While verifying pins against BTT's official config, two details jumped out that
  silently wreck a lot of copy-pasted setups:

  The Kraken's onboard drivers use software SPI (PC6/PC8/PC7), not a hardware
  SPI bus.
  Its sense_resistor is 0.022 Ω, not the 0.075 that generic TMC5160 module
  guides use. Get that wrong and every run_current you set is off by ~3.4×.
  
  

  The pump is not a stepper
  The concrete pump is a MAI 2PUMP Pictor, which takes a 0–10 V analog speed
  command — and neither Klipper nor the Kraken has a DAC. The trick: define the
  pump as a Klipper [extruder_stepper] synced to the extruder, route its STEP
  pulse train into a frequency-to-voltage converter, and you get a 0–10 V command
  that tracks extrusion in real time, with pressure-advance to pre-pressurize the
  hose. Start/stop is a separate 24 V line through an opto/relay (0 V doesn't stop
  the pump — it has a minimum-flow deadband). That's a later stage implementation (we demonstatred ove a year ago) , but it's the neat bit, so it gets a mention.

  Open-sourced this round

  
  Full Klipper config + a one-line installer (install.sh) that drops the
  config in, registers it with Moonraker's update manager (so it's click-to-update,
  same as Klipper itself ), installs KlipperScreen, and
  auto-detects the board's serial:
  github.com/sunnyday-technologies/M3-CRETE-FIRMWARE

  
  A plain-language software build guide, written so a complete beginner can
  follow it and so it translates cleanly:
  m3-crete.com/build-guide/software/
  
  

  Where it stands:
  This milestone ends at first motor movement — energize, jog each Z motor, verify
  direction. Setting working current, tuning StallGuard, homing all four corners, and
  the full pre-print qualification are the next guide (validation). It is a
  development platform, not a certified appliance, and it is not printing concrete yet.

  Build along, or tell us what we got wrong — the whole point of doing this in the
  open is that the next builder hits fewer walls than we did.

• # Building a Meter-Scale Parametric CAD Assembly with an AI Coding Agent (and What Actually Worked)

  Nick • 04/30/2026 at 10:40 • 0 comments

  M3-CRETE is an open-source concrete 3D printer. The motion system, the frame, gantry, motors, belts, wheels, every part that moves, was designed in Python using CadQuery, a code-based CAD library. No Fusion 360 was used to *author* the geometry, though Fusion was used extensively to *verify* and refine it.

  The unusual part: an AI coding agent was the primary tool for writing the CadQuery assembly script. Here is what that looked like in practice.

  ## The Setup

  The M3-2 variant of M3-CRETE has a meter-scale build volume on a frame roughly two meters across. Eight plates, dozens of V-wheels, motors, pulleys, idler bearings, belts, and 3D-printed motor brackets. Every part position depends on the frame dimensions, so changing the width means dozens of parts need to move.

  In GUI CAD, that means dozens of manual edits or an elaborate constraint system. In code-CAD, it means changing one number and re-running a script.

  The agent's job: write and maintain that script.

  ## What the Agent Does Well

  **Coordinate math.** The M3-2 frame has four corner posts. Every plate, wheel, motor, and pulley position derives from those four post positions plus offsets. The agent handles this reliably once the conventions are established.

  **Repetitive placement.** Four Z-carriages, each with plates, wheels, a motor, a pulley, an idler, and belt strands. Define the pattern once, the agent replicates it to all four corners with correct mirroring.

  **Refactoring.** When the frame switched from mixed extrusion lengths to a single SKU, the agent rewrote every placement coordinate in a single pass.

  ## The Real Contribution: Self-Verification

  Here is the thing nobody talks about in the AI-does-CAD conversation: how do you know the output is correct?

  We built a verification harness, a second Python script that loads the assembly, extracts every part's bounding box, and runs hundreds of engineering checks against it. Does this plate measure 3 mm thick? Is this wheel engaging the V-groove at the correct depth? Does this belt span from the idler to the motor pulley?

  If any check fails, the harness tells the agent exactly what is wrong. The agent fixes the assembly script and re-runs. No human needs to open Fusion 360 to catch dimensional errors.

  The harness also renders three orthographic views (top, front, side) using matplotlib, no 3D rendering engine required. The agent reads those images and compares them against reference renders. That closes the loop. The agent can see its own mistakes without human intervention.

  The verification approach we built for M3-CRETE was eventually packaged as a standalone open-source tool, [CADCLAW](https://cadclaw.io), so other projects can apply the pattern to their own assemblies.

  ## What the Agent Gets Wrong

  **Mechanical intent.** The agent can place a plate at a coordinate. It does not understand *why* a sandwich joint differs from a butt joint. That understanding comes from the engineer. Every time.

  **Part orientation.** STEP files from component libraries have arbitrary orientations. A motor might be lying on its side. We wrote a probe script to measure bounding boxes before placement, which helps, but orientation errors remain the most common bug class.

  **Session memory.** The agent forgets prior decisions between sessions. We maintain explicit notes and transfer summaries to bridge sessions. It is manual and imperfect.

  ## The Hybrid Approach

  The assembly script evolved from pure parametric generation to a hybrid. It loads the engineer's Fusion 360 export and surgically replaces specific components with parametric versions. That preserves the human's mechanical refinements while keeping the ability to regenerate components from code.

  This is pragmatic engineering, not a purity contest. The human's GUI model is usually better than the agent's parametric recreation. The agent's value is in the verification infrastructure, not in replacing the human's judgment.

  ## What This Buys

  - Assembly geometry that...

  Read more »

• Assembly begins

  Nick • 04/30/2026 at 09:42 • 0 comments

  Starting Assembly - we have printed the motor-mount + spacer pieces so we will begin assembly.  still working on the  small  3d printed retainers to hold the 2040 reinforcement inside the 2-meter 4080 c-beam sections.

View all 3 project logs