# Frequently Asked Questions (/docs/lib/faq)





<Accordions>
  <Accordion title="What is Kinetra? How do &#x22;Kinetra Printer&#x22; and &#x22;KinetraMCU&#x22; fit in?">
    Kinetra is the project and the set of libraries for motion control applications.
    Kinetra Printer is the 3D‑printer firmware built on that base.
    KinetraMCU is the reference MCU implementation.
  </Accordion>

  <Accordion title="How is Kinetra different from Klipper or Marlin?">
    Kinetra draws a hard boundary between host and MCU (both process and license). It favors board‑specific MCU builds over one generic firmware and avoids re‑flashing MCUs in lock‑step with host releases. On the wire, KinetraMCU speaks a register‑based (fieldbus‑style) protocol rather than ad‑hoc commands.
    Kinetra is a ground up redesign using current state of the art hardware and software methods.
  </Accordion>

  <Accordion title="What hardware will be supported first?">
    Initial target is the BTT Octopus with TMC5160s for initial release, then broader board coverage. The goal is to ship something that prints well on common, capable hardware and expand from there.
  </Accordion>

  <Accordion title="Will I need to update MCU firmware often?">
    No. Kinetra explicitly avoids frequent MCU updates tied to host changes. Occasional updates may happen, but device behavior should remain stable across controller versions.
  </Accordion>

  <Accordion title="Does Kinetra require EtherCAT? What's the communication model?">
    A KinetraMCU instance will be treated like an EtherCAT‑style device: deterministic cycles, register‑mapped IO, and descriptor‑based discovery/config. EtherCAT is first‑class, and bridging modules can be used where needed—no hard lock‑in.
  </Accordion>

  <Accordion title="Can I reuse existing Klipper MCUs or accessories within Kinetra Printer?">
    Direct reuse of a Klipper MCU isn't planned. Some accessories that speak Klipper protocols may be bridged or re‑targeted, but the preference is Kinetra‑native or EtherCAT‑style devices for clean discovery/config and timing guarantees.
  </Accordion>

  <Accordion title="What performance targets are you aiming for?">
    On a Pi 5, the target control cycle is around 500 μs, with room to go lower using kernel/driver tuning. On MCUs, timer hardware (e.g., repetition counters) enables step rates far beyond typical host‑bit‑banged approaches.
  </Accordion>

  <Accordion title="How do device discovery and configuration work? Is hot‑plug planned?">
    Devices describe their resources (EtherCAT‑style). Discovery aims to be robust, but not everything is auto‑detectable—there is always a safe "not detected" fallback with manual configuration. Hot‑plug is planned where feasible; real‑time safety wins if there's a trade‑off.
  </Accordion>

  <Accordion title="Which advanced features are in scope soon?">
    Real‑time capabilities: resonance compensation, live encoder feedback and lag detection (including extruder), closed‑loop/servo control, and a modern motion planner (aligned with ideas pioneered in Prunt). For 3D printers an MPC temperature control library will ship via a Rust port of the existing Marlin/Klipper work.
  </Accordion>

  <Accordion title="When will it be ready?">
    When it's good. Near‑term: reach Klipper/Marlin‑parity on targeted hardware; then land the more ambitious features. Quality and correctness drive the schedule.
  </Accordion>
</Accordions>