CNC Mill Concept: Goals, Philosophy & System Architecture
Contents
Introduction
Goals
Constraints
Design Philosophy
Explicit Non-Goals
Documentation Scope
System Architecture
Subsystems
Communication Topology
Architecture Diagram
Subscribe for New Projects
Introduction
This post is part of the CNC Mill Concept hub. It covers the top-level goals and constraints that shaped every subsequent design decision, the philosophy that governs tradeoffs throughout the machine, and the system architecture that partitions responsibility across the five main subsystems.
Goals
The machine targets fixed-bed CNC milling of aluminium and steel. The primary requirements are:
Machining accuracy and repeatability: ≤ 10 µm.
Apartment-compatible operation: low airborne noise emission and low structure-borne vibration transmitted to the building.
High observability: the machine state must be measurable, not assumed.
Graceful degradation: the preferred failure response is feed reduction or spindle adaptation, not part scrap.
Constraints
The residential context imposes hard limits that rule out common heavy-machine approaches:
Floor load: residential building limit of approximately 150–200 kg/m². No concrete or mineral-cast bed.
Total machine mass: must remain controlled — mass is not a free variable for stiffness.
Safety: no reliance on software for safety-critical functions.
Noise: noise-sensitive environment is a primary constraint, not an afterthought.
Availability: downtime is acceptable; accuracy is prioritised over uptime.
Design Philosophy
A small number of principles govern the design wherever competing approaches exist:
Accuracy over brute stiffness: geometry and load path optimisation are preferred over added mass.
Observability over assumption: if the machine state cannot be measured, the design is incomplete.
Time-scale separation: fast dynamics (vibration, chatter), slow dynamics (deflection, compliance), and supervisory decisions (feed and spindle adaptation) are handled at distinct layers and must not be conflated.
Fail-safe by construction: the safety system is hardware-only and independent of all firmware.
KISS: complexity is only introduced where it provides a measurable benefit.
Explicit Non-Goals
The following are out of scope for the current phase. They may be revisited later but are not considered when making current design tradeoffs:
Custom servo drives or inverters.
Glass scale feedback.
Active vibration cancellation.
Fully temperature-controlled machine enclosure.
Predictive health monitoring.
Documentation Scope
This concept documentation covers design intent, architectural decisions, subsystem placement and purpose, and the boundaries between mechanical, electrical, control, and safety layers. It does not include CAD geometry, manufacturing drawings, assembly procedures, or firmware implementation details.
System Architecture
The machine decomposes into five subsystems with clearly separated responsibilities. Keeping these boundaries strict is what allows each layer to be reasoned about independently.
Subsystems
Motion control — Duet 3 6HC: kinematics, motion planning, step generation, and G-code execution. No supervision or state estimation.
Host — Raspberry Pi: Duet services, web interface, plugins, logging and visualisation (Grafana). No real-time control.
Real-time supervision — ECU (master PCB): sensor fusion, machine state estimation, feed and spindle supervision. No trajectory planning.
Distributed sensing — sensor PCBs: zonal architecture with local signal preprocessing and event-based reporting over CAN-FD. No global decision-making.
Safety chain: hardware-only, electrically independent, directly actuates power contactors and pneumatics. Overrides all other systems.
Communication Topology
Pi ↔ Duet: native Duet architecture (services, UI, plugins).
ECU ↔ Pi: SPI or UART for configuration, data logging, and visualisation.
ECU ↔ Duet: GPIO signals for low-latency macro triggering.
ECU ↔ Sensor PCBs: CAN-FD, event-driven with heartbeat monitoring.
ECU ↔ Spindle servo drive: RS-485.
Safety chain: electrically independent, directly actuates power and pneumatics.
Architecture Diagram
Fig. 1 shows the full system with all subsystems and communication links.
Figure 1: System architecture: Duet motion controller, ECU supervisor, distributed sensor PCBs, Raspberry Pi host, and hardware safety chain with their communication links.
Get Notified of New Articles
Subscribe to get notified about new projects. Our Privacy Policy applies.