metadata: version: v1 total_settings: 396 total_modules: 11 last_updated: 2025-11-06 firmware_repo: Smoothieware/Smoothieware source_file: src/docs/smoothieware-v1-config.md modules: - name: Robot & Motion Control description: Core motion settings, planner configuration, and kinematics setting_count: 81 settings: - name: acceleration type: number default: 100 units: mm/s² module: root context: Global setting defined_in: modules/robot/Robot.cpp:228 corresponding_v1: acceleration corresponding_v2: motion control.default_acceleration description: Default acceleration for all axes in mm/s². This is the rate at which the machine accelerates and decelerates during moves. Higher acceleration values allow faster speed changes and shorter move times, but may cause ringing, layer shifts, or mechanical stress. Lower values provide smoother operation at the cost of speed. This setting can be overridden per-axis using the per-actuator acceleration settings. description_bullets: - This is a global default that applies to all axes unless specifically overridden - Per-axis acceleration settings (in actuator configuration) take precedence over this value - Z-axis often benefits from lower acceleration than XY to prevent layer artifacts - Delta printers typically need lower acceleration due to complex kinematics typical_values: - value: 100 description: general purpose - value: 500 description: fast 3D printer - value: 1000 description: light CNC with good mechanics - value: 50 description: heavy machine related_settings: - z_acceleration - per-actuator acceleration settings related_pages: - motion-control - configuring-smoothie - 3d-printer-guide examples: - 'acceleration 100.0 # Default conservative setting' - 'acceleration 500 # Fast 3D printer with good mechanical rigidity' - 'acceleration 1000 # Light CNC mill with precision components' - 'acceleration 50 # Heavy CNC machine or gantry router' - name: default_feed_rate type: number default: 100 units: mm/min module: root context: Global setting defined_in: modules/robot/Robot.cpp:182 corresponding_v1: default_feed_rate corresponding_v2: motion control.default_feed_rate description: Default feed rate for G1 moves when no F parameter is specified. This is the speed at which the machine moves during normal operations (cutting, extruding, or engraving). The value is specified in millimeters per minute and serves as a fallback when G-code doesn't explicitly set a feed rate. Once an F parameter is specified in G-code, that rate persists until changed. description_bullets: - This is only used when G-code omits the F parameter - Most slicers and CAM software specify F in every move, making this rarely used - Still important to set to a safe value as a fallback - Should be within the machine's safe operating range based on max_speeds typical_values: - value: 4000 description: general purpose - value: 6000 description: fast printer - value: 1000 description: slow/precise related_pages: - motion-control - g1 - configuring-smoothie examples: - 'default_feed_rate 4000 # 66.7 mm/s - general purpose' - 'default_feed_rate 100 # Extremely slow fallback for safety' - 'default_feed_rate 6000 # 100 mm/s - fast default' - name: default_seek_rate type: number default: 100 units: mm/min module: root context: Global setting defined_in: modules/robot/Robot.cpp:183 corresponding_v1: default_seek_rate corresponding_v2: motion control.default_seek_rate description: Default rate for G0 rapid moves. This is the speed for rapid positioning moves when the tool is not active (not cutting, extruding, or engraving). G0 moves are non-interpolated rapids that move the machine as quickly as possible between points. This rate should typically be faster than feed rate, limited only by mechanical capabilities and max_speeds. description_bullets: - G0 moves are for rapid positioning, not working moves - Should be set to the maximum safe rapid speed for your machine - Must respect the x/y/z_axis_max_speed limits - In 3D printing, used for travel moves between features - In CNC, used for tool positioning between cuts typical_values: - value: 30000 description: 500 mm/s rapid - value: 15000 description: 250 mm/s moderate - value: 6000 description: 100 mm/s conservative related_settings: - x_axis_max_speed - y_axis_max_speed - z_axis_max_speed related_pages: - motion-control - g0 - configuring-smoothie examples: - 'default_seek_rate 30000 # 500 mm/s for fast positioning' - 'default_seek_rate 15000 # 250 mm/s moderate speed' - 'default_seek_rate 6000 # 100 mm/s conservative for heavy machines' - name: x_axis_max_speed type: number default: 60000 units: mm/min module: root context: Global setting defined_in: modules/robot/Robot.cpp:191 corresponding_v1: x_axis_max_speed corresponding_v2: motion control.x_axis_max_speed description: Maximum allowable speed for the X axis. Smoothie will never exceed this value for X axis movement regardless of requested feed rate. This is a hard limit that protects against mechanical damage, missed steps, or loss of position. The firmware caps any move that would exceed this speed. The value is specified in mm/min but converted internally to mm/s for calculations. description_bullets: - Acts as a safety limit regardless of G-code commands - Should be set based on mechanical capabilities (belts, leadscrews, rigidity) - Too high may cause missed steps or mechanical damage - Too low unnecessarily limits machine performance - For CoreXY/HBot, this applies to the transformed X axis, not individual motors typical_values: - value: 30000 description: 500 mm/s fast - value: 15000 description: 250 mm/s moderate - value: 6000 description: 100 mm/s slow related_settings: - y_axis_max_speed - z_axis_max_speed - max_speed - alpha_max_rate related_pages: - motion-control - stepper-motors - configuring-smoothie examples: - 'x_axis_max_speed 30000 # 500 mm/s - fast Cartesian printer' - 'x_axis_max_speed 15000 # 250 mm/s - moderate speed' - 'x_axis_max_speed 6000 # 100 mm/s - heavy CNC machine' - name: y_axis_max_speed type: number default: 60000 units: mm/min module: root context: Global setting defined_in: modules/robot/Robot.cpp:192 corresponding_v1: y_axis_max_speed corresponding_v2: motion control.y_axis_max_speed description: Maximum allowable speed for the Y axis. Smoothie will never exceed this value for Y axis movement regardless of requested feed rate. This is a hard limit that protects against mechanical damage, missed steps, or loss of position. The firmware caps any move that would exceed this speed. The value is specified in mm/min but converted internally to mm/s for calculations. description_bullets: - Acts as a safety limit regardless of G-code commands - Should be set based on mechanical capabilities (belts, leadscrews, rigidity) - Too high may cause missed steps or mechanical damage - Too low unnecessarily limits machine performance - For CoreXY/HBot, this applies to the transformed Y axis, not individual motors - Often set same as X for symmetric machines, but can differ based on mechanics typical_values: - value: 30000 description: 500 mm/s fast - value: 15000 description: 250 mm/s moderate - value: 6000 description: 100 mm/s slow related_settings: - x_axis_max_speed - z_axis_max_speed - max_speed - beta_max_rate related_pages: - motion-control - stepper-motors - configuring-smoothie examples: - 'y_axis_max_speed 30000 # 500 mm/s - fast Cartesian printer' - 'y_axis_max_speed 15000 # 250 mm/s - moderate speed' - 'y_axis_max_speed 6000 # 100 mm/s - heavy CNC machine' - name: z_axis_max_speed type: number default: 300 units: mm/min module: root context: Global setting defined_in: modules/robot/Robot.cpp:193 corresponding_v1: z_axis_max_speed corresponding_v2: motion control.z_axis_max_speed description: Maximum allowable speed for the Z axis. Smoothie will never exceed this value for Z axis movement regardless of requested feed rate. Typically much slower than X/Y because Z-axis uses leadscrew drives with higher mechanical advantage and less need for speed. For delta printers, all three actuators contribute to Z motion so this should be set higher. The value is specified in mm/min but converted internally to mm/s for calculations. description_bullets: - Z-axis is typically much slower than XY due to leadscrew mechanics - Default of 300 mm/min (5 mm/s) is appropriate for most Cartesian machines - Delta printers need much higher values (6000+ mm/min) as all towers move for Z - Layer change speed in 3D printing is limited by this setting - CNC machines with ballscrew Z-axis can safely go faster typical_values: - value: 300 description: 5 mm/s typical Z - value: 1200 description: 20 mm/s fast Z - value: 6000 description: 100 mm/s delta related_settings: - x_axis_max_speed - y_axis_max_speed - max_speed - gamma_max_rate - z_acceleration related_pages: - motion-control - delta - stepper-motors examples: - 'z_axis_max_speed 300 # 5 mm/s - typical Cartesian/CoreXY Z' - 'z_axis_max_speed 1200 # 20 mm/s - faster leadscrew or ballscrew' - 'z_axis_max_speed 6000 # 100 mm/s - delta printer' - name: max_speed type: number default: -60 units: mm/min module: root context: Global setting defined_in: modules/robot/Robot.cpp:194 corresponding_v1: max_speed corresponding_v2: motion control.max_speed description: Global maximum speed limit applied to all moves. When set to a positive value, limits the combined speed of all axes (the magnitude of the velocity vector). When negative, this limit is disabled and only per-axis max_speeds apply. This is useful for machines where the combined motion speed matters more than individual axis speeds, such as delta printers or when total kinetic energy is a concern. description_bullets: - Negative value (default) disables this limit - When enabled, applies to the vector magnitude of the move - Applies in addition to per-axis limits (the more restrictive limit wins) - Most Cartesian/CoreXY machines leave this disabled (-1) - Delta printers may benefit from this as an overall speed governor - Value is in mm/min, converted internally to mm/s typical_values: - value: -1 description: disabled - value: 30000 description: 500 mm/s - value: 60000 description: 1000 mm/s related_settings: - x_axis_max_speed - y_axis_max_speed - z_axis_max_speed related_pages: - motion-control - delta examples: - 'max_speed -1 # Disabled (rely on per-axis limits only)' - 'max_speed 30000 # 500 mm/s overall speed limit' - 'max_speed 60000 # 1000 mm/s for fast machines' - name: z_acceleration type: number default: null units: mm/s² module: root context: Global setting defined_in: modules/robot/Robot.cpp:264 corresponding_v1: z_acceleration corresponding_v2: actuator.z.acceleration description: Specific acceleration for Z axis movements. When set to a valid number, overrides the default acceleration setting for Z axis only. When set to NAN (not a number) or omitted, the Z axis uses the global default acceleration. This is useful for providing slower/safer Z acceleration without affecting XY speed, particularly important for preventing layer artifacts in 3D printing or Z-axis backlash issues in CNC. description_bullets: - When NAN or unset, Z uses the global default acceleration - Z-axis typically benefits from lower acceleration than XY - Lower Z acceleration reduces layer start artifacts in 3D printing - Helps prevent Z-axis binding or leadscrew whip - Not needed for delta printers (all axes accelerate together) - 'Legacy setting: prefer per-actuator gamma_acceleration in v2' typical_values: - value: 50 description: conservative Z - value: 100 description: moderate - value: 20 description: heavy machine related_settings: - acceleration - per-actuator acceleration settings related_pages: - motion-control - 3d-printer-guide examples: - 'z_acceleration 50 # Half speed of default acceleration' - 'z_acceleration 20 # Very conservative for heavy Z-axis' - '# Omit this setting to use default acceleration for Z' - name: alpha_steps_per_mm type: number default: 80 units: steps/mm module: root context: Per-axis setting (X axis in Cartesian machines) defined_in: modules/robot/Robot.cpp:255 corresponding_v1: alpha_steps_per_mm corresponding_v2: actuator.x.steps_per_mm description: 'Alpha axis (X axis in Cartesian machines): Number of motor steps required to move exactly 1mm along the alpha axis. This is the most critical calibration value and depends on motor steps per revolution (typically 200 for 1.8° steppers), microstepping setting, and mechanical transmission ratio (belt pitch and pulley teeth for belts, thread pitch for lead screws). Incorrect values cause dimensional inaccuracy in all movements. For Cartesian/CoreXY machines, this typically controls the X axis. For delta machines, this controls the first tower.' description_bullets: - Most critical calibration value for dimensional accuracy - Depends on motor (usually 200 steps/rev for 1.8° steppers), microstepping, and mechanical ratio - 'Belt-driven: calculate as (motor_steps_per_rev × microsteps) / (belt_pitch × pulley_teeth)' - 'Leadscrew: calculate as (motor_steps_per_rev × microsteps) / thread_pitch' - GT2 belt with 20-tooth pulley and 1/16 microstepping = 80 steps/mm - Common TR8×8 leadscrew with 1/16 microstepping = 400 steps/mm - Test by commanding 100mm move and measuring actual distance traveled - 'Adjust formula: correct_steps = current_steps × (commanded / measured)' typical_values: - value: 80 description: GT2 belt, 20-tooth pulley, 1/16 microstep - value: 100 description: GT2 belt, 16-tooth pulley, 1/16 microstep - value: 400 description: TR8 leadscrew, 1/16 microstep related_settings: - beta_steps_per_mm - gamma_steps_per_mm - delta_steps_per_mm - epsilon_steps_per_mm - zeta_steps_per_mm - microseconds_per_step_pulse - alpha_max_rate related_pages: - stepper-motors - motion-control - 3d-printer-guide - cnc-mill-guide examples: - 'alpha_steps_per_mm 80 # GT2 belt with 20-tooth pulley, 1/16 microstepping' - 'alpha_steps_per_mm 100 # GT2 belt with 16-tooth pulley, 1/16 microstepping' - 'alpha_steps_per_mm 400 # TR8×8 leadscrew, 1/16 microstepping' - 'alpha_steps_per_mm 160 # XL belt with 20-tooth pulley, 1/16 microstepping' - name: beta_steps_per_mm type: number default: 80 units: steps/mm module: root context: Per-axis setting (Y axis in Cartesian machines) defined_in: modules/robot/Robot.cpp:255 corresponding_v1: beta_steps_per_mm corresponding_v2: actuator.y.steps_per_mm description: 'Beta axis (Y axis in Cartesian machines): Number of motor steps required to move exactly 1mm along the beta axis. This is the most critical calibration value and depends on motor steps per revolution (typically 200 for 1.8° steppers), microstepping setting, and mechanical transmission ratio. For Cartesian/CoreXY machines, this typically controls the Y axis. For delta machines, this controls the second tower. Often the same as alpha_steps_per_mm for symmetric machines.' description_bullets: - Calculate the same way as alpha_steps_per_mm - Often identical to alpha for symmetric XY mechanisms - May differ if Y axis uses different mechanical components - Test calibration by measuring diagonal moves and comparing to Pythagorean distance typical_values: - value: 80 description: GT2 belt, 20-tooth pulley, 1/16 microstep - value: 100 description: GT2 belt, 16-tooth pulley, 1/16 microstep - value: 400 description: TR8 leadscrew, 1/16 microstep related_settings: - alpha_steps_per_mm - gamma_steps_per_mm - beta_max_rate related_pages: - stepper-motors - motion-control - 3d-printer-guide examples: - 'beta_steps_per_mm 80 # GT2 belt with 20-tooth pulley, 1/16 microstepping' - 'beta_steps_per_mm 333.333 # HTD 3M belt with 15-tooth pulley, 1/16 microstepping' - name: gamma_steps_per_mm type: number default: 2560 units: steps/mm module: root context: Per-axis setting (Z axis in Cartesian machines) defined_in: modules/robot/Robot.cpp:255 corresponding_v1: gamma_steps_per_mm corresponding_v2: actuator.z.steps_per_mm description: 'Gamma axis (Z axis in Cartesian machines): Number of motor steps required to move exactly 1mm along the gamma axis. For Cartesian/CoreXY machines, this typically controls the Z axis using leadscrew drives. The default of 2560 is appropriate for common TR8×8 leadscrews with 1/16 microstepping. For delta machines, this controls the third tower and should match alpha/beta values. Z-axis typically has much higher steps/mm than XY due to leadscrew mechanical advantage.' description_bullets: - Z-axis typically uses leadscrews, much higher steps/mm than XY - 'Common values: TR8×8 leadscrew = 2560 (1/16 microstep), TR8×2 = 640, M8×1.25 threaded rod = 2560' - Delta printers should use same value as alpha/beta (all towers identical) - Critical for layer height accuracy in 3D printing - Test by commanding Z movement and measuring with calipers typical_values: - value: 2560 description: TR8×8 leadscrew, 1/16 microstep - value: 400 description: TR8×8 leadscrew, 1/32 microstep - value: 640 description: TR8×2 leadscrew, 1/16 microstep - value: 80 description: delta (same as XY) related_settings: - alpha_steps_per_mm - beta_steps_per_mm - gamma_max_rate - z_acceleration related_pages: - stepper-motors - motion-control - delta - 3d-printer-guide examples: - 'gamma_steps_per_mm 2560 # TR8×8 (8mm pitch) leadscrew, 1/16 microstepping' - 'gamma_steps_per_mm 640 # TR8×2 (2mm pitch) leadscrew, 1/16 microstepping' - 'gamma_steps_per_mm 400 # 5mm pitch leadscrew, 1/16 microstepping' - 'gamma_steps_per_mm 80 # Delta printer (belt drive, matches alpha/beta)' - name: delta_steps_per_mm type: number default: 80 units: steps/mm module: root context: Per-axis setting (A axis, typically first extruder or 4th CNC axis) defined_in: modules/robot/Robot.cpp:255 corresponding_v1: delta_steps_per_mm corresponding_v2: actuator.delta.steps_per_mm description: 'Delta axis (A axis): Number of motor steps required to move exactly 1mm (or 1 degree for rotary axes) along the delta axis. In 3D printers, this is typically the first extruder (E0) and represents steps per mm of filament pushed. In CNC machines with 4th axis, this may be steps per degree of rotation. For extruders, this depends on hobbed bolt diameter, gear ratio (if geared), and microstepping. For rotary axes, depends on gear ratio and motor steps per revolution.' description_bullets: - In 3D printers, typically controls first extruder (E0) - For direct drive extruders, depends on hobbed bolt diameter - 'Common direct drive: ~95 steps/mm with 1.75mm filament, 11mm effective diameter hobbed bolt' - 'Geared extruders (e.g., Titan): ~400-850 steps/mm depending on gear ratio' - For CNC 4th axis (rotary), represents steps per degree - Test by extruding known length and measuring actual filament consumed typical_values: - value: 95 description: direct drive extruder - value: 420 description: 3:1 geared extruder - value: 830 description: Titan extruder - value: 22.222 description: rotary axis (200 steps/rev, 1/16 microstep, 360°) related_settings: - epsilon_steps_per_mm - zeta_steps_per_mm - delta_max_rate - extruder.hotend.steps_per_mm related_pages: - stepper-motors - extruder-guide - 6axis - multiple-extruders examples: - 'delta_steps_per_mm 95 # Direct drive extruder' - 'delta_steps_per_mm 420 # 3:1 geared extruder' - 'delta_steps_per_mm 830 # Titan or BMG extruder' - 'delta_steps_per_mm 22.222 # Rotary 4th axis (steps per degree)' - name: epsilon_steps_per_mm type: number default: 80 units: steps/mm module: root context: Per-axis setting (B axis, typically second extruder or 5th CNC axis) defined_in: modules/robot/Robot.cpp:255 corresponding_v1: epsilon_steps_per_mm corresponding_v2: actuator.epsilon.steps_per_mm description: 'Epsilon axis (B axis): Number of motor steps required to move exactly 1mm (or 1 degree for rotary axes) along the epsilon axis. In 3D printers with dual extruders, this is the second extruder (E1). In CNC machines with 5th axis, this may be steps per degree of rotation. Configuration is identical to delta_steps_per_mm but applies to the second actuator in the sequence.' description_bullets: - In dual-extruder 3D printers, controls second extruder (E1) - Calculate same way as delta_steps_per_mm - Often identical to delta for matching extruder types - May differ if using different extruder mechanism (e.g., direct drive + Bowden) typical_values: - value: 95 description: direct drive extruder - value: 420 description: 3:1 geared extruder - value: 830 description: Titan extruder related_settings: - delta_steps_per_mm - zeta_steps_per_mm - epsilon_max_rate - extruder.hotend2.steps_per_mm related_pages: - stepper-motors - extruder-guide - multiple-extruders - 6axis examples: - 'epsilon_steps_per_mm 95 # Second extruder, direct drive' - 'epsilon_steps_per_mm 420 # Second extruder, geared 3:1' - name: zeta_steps_per_mm type: number default: 80 units: steps/mm module: root context: Per-axis setting (C axis, typically third extruder or 6th CNC axis) defined_in: modules/robot/Robot.cpp:255 corresponding_v1: zeta_steps_per_mm corresponding_v2: actuator.zeta.steps_per_mm description: 'Zeta axis (C axis): Number of motor steps required to move exactly 1mm (or 1 degree for rotary axes) along the zeta axis. In 3D printers with triple extruders, this is the third extruder (E2). In CNC machines with 6th axis, this may be steps per degree of rotation. Configuration is identical to delta/epsilon_steps_per_mm but applies to the third actuator in the sequence.' description_bullets: - In triple-extruder 3D printers, controls third extruder (E2) - Calculate same way as delta_steps_per_mm - Rarely used outside specialized multi-extruder or CNC applications typical_values: - value: 95 description: direct drive extruder - value: 420 description: 3:1 geared extruder related_settings: - delta_steps_per_mm - epsilon_steps_per_mm - zeta_max_rate related_pages: - stepper-motors - extruder-guide - multiple-extruders - 6axis examples: - 'zeta_steps_per_mm 95 # Third extruder, direct drive' - name: alpha_max_rate type: number default: 30000 units: mm/min module: root context: Per-actuator setting (alpha motor maximum speed) defined_in: modules/robot/Robot.cpp:256 corresponding_v1: alpha_max_rate corresponding_v2: actuator.x.max_rate description: 'Alpha motor maximum speed: Maximum speed this individual actuator/motor can achieve in mm/min. This limits the motor speed regardless of commanded feed rate or x_axis_max_speed setting. Should be set based on motor capabilities, driver current, microstepping, and mechanical load. The firmware enforces this as a hard limit on the motor, even if the axis-level geometry would allow higher speeds. This protects against missed steps and mechanical damage. Value is in mm/min and is converted internally to mm/s for calculations.' description_bullets: - Limits the speed of the alpha motor specifically, regardless of other limits - Acts in combination with x_axis_max_speed (the more restrictive limit applies) - Should be set based on motor max RPM, microstepping, and steps/mm - 'Calculate max: (motor_max_rpm / 60) × (360 / steps_per_rev) / (steps_per_mm / microsteps)' - Default 30000 mm/min = 500 mm/s, appropriate for most belt-driven axes - Too high causes missed steps, too low limits machine performance unnecessarily - For CoreXY, this applies to the alpha motor, not the X axis typical_values: - value: 30000 description: 500 mm/s - fast belt drive - value: 15000 description: 250 mm/s - moderate speed - value: 6000 description: 100 mm/s - conservative related_settings: - x_axis_max_speed - alpha_steps_per_mm - beta_max_rate - gamma_max_rate related_pages: - stepper-motors - motion-control - configuring-smoothie examples: - 'alpha_max_rate 30000 # 500 mm/s - fast Cartesian printer' - 'alpha_max_rate 15000 # 250 mm/s - moderate speed' - 'alpha_max_rate 6000 # 100 mm/s - heavy CNC machine' - name: beta_max_rate type: number default: 30000 units: mm/min module: root context: Per-actuator setting (beta motor maximum speed) defined_in: modules/robot/Robot.cpp:256 corresponding_v1: beta_max_rate corresponding_v2: actuator.y.max_rate description: 'Beta motor maximum speed: Maximum speed this individual actuator/motor can achieve in mm/min. Identical in function to alpha_max_rate but applies to the beta motor. Often set to the same value as alpha_max_rate for symmetric XY mechanisms, but may differ if the Y axis has different mechanical characteristics or motor specifications. For CoreXY, this applies to the beta motor, not the Y axis.' description_bullets: - Limits the speed of the beta motor specifically - Often identical to alpha_max_rate for symmetric machines - May differ if Y axis uses different mechanics or motors - Acts in combination with y_axis_max_speed typical_values: - value: 30000 description: 500 mm/s - fast belt drive - value: 15000 description: 250 mm/s - moderate speed - value: 6000 description: 100 mm/s - conservative related_settings: - y_axis_max_speed - beta_steps_per_mm - alpha_max_rate - gamma_max_rate related_pages: - stepper-motors - motion-control - configuring-smoothie examples: - 'beta_max_rate 30000 # 500 mm/s - fast Cartesian printer' - 'beta_max_rate 15000 # 250 mm/s - moderate speed' - name: gamma_max_rate type: number default: 30000 units: mm/min module: root context: Per-actuator setting (gamma motor maximum speed) defined_in: modules/robot/Robot.cpp:256 corresponding_v1: gamma_max_rate corresponding_v2: actuator.z.max_rate description: 'Gamma motor maximum speed: Maximum speed this individual actuator/motor can achieve in mm/min. For Cartesian machines with leadscrew Z-axis, this is often set much lower than alpha/beta (e.g., 300-1200 mm/min) due to mechanical constraints of leadscrew drives. For delta printers where all three motors contribute to Z motion, this should be set to the same high value as alpha/beta. Acts in combination with z_axis_max_speed, with the more restrictive limit applying.' description_bullets: - For Cartesian Z-axis with leadscrew, typically much lower than XY (300-1200 mm/min) - For delta printers, should match alpha/beta values - Limited by leadscrew pitch and safe rotation speed - Too high on leadscrew can cause whip or binding - Acts in combination with z_axis_max_speed typical_values: - value: 300 description: 5 mm/s - typical Cartesian Z - value: 1200 description: 20 mm/s - fast leadscrew - value: 30000 description: 500 mm/s - delta printer related_settings: - z_axis_max_speed - gamma_steps_per_mm - alpha_max_rate - beta_max_rate - z_acceleration related_pages: - stepper-motors - motion-control - delta examples: - 'gamma_max_rate 300 # 5 mm/s - typical Cartesian Z-axis' - 'gamma_max_rate 1200 # 20 mm/s - faster leadscrew or ballscrew' - 'gamma_max_rate 30000 # 500 mm/s - delta printer (matches alpha/beta)' - name: delta_max_rate type: number default: 30000 units: mm/min module: root context: Per-actuator setting (delta motor maximum speed) defined_in: modules/robot/Robot.cpp:256 corresponding_v1: delta_max_rate corresponding_v2: actuator.delta.max_rate description: 'Delta motor maximum speed: Maximum speed for the delta actuator motor in mm/min (or degrees/min for rotary). For extruders, this limits the linear speed of filament feed. Typical values for extruders are 3000-5000 mm/min (50-83 mm/s) to prevent grinding or skipping. For rotary 4th/5th/6th axes, this represents angular velocity in degrees per minute. Setting too high for extruders can cause filament grinding or hotend jamming.' description_bullets: - For extruders, limits filament feed speed to prevent grinding/jamming - 'Typical extruder values: 3000-5000 mm/min (50-83 mm/s)' - For rotary axes, represents degrees per minute - Consider hotend melt rate, not just motor capability typical_values: - value: 5000 description: 83 mm/s extruder - value: 3000 description: 50 mm/s extruder - value: 50000 description: rotary axis related_settings: - delta_steps_per_mm - epsilon_max_rate - zeta_max_rate - extruder.hotend.max_speed related_pages: - stepper-motors - extruder-guide - 6axis examples: - 'delta_max_rate 5000 # 83 mm/s extruder feed rate' - 'delta_max_rate 3000 # 50 mm/s conservative extruder rate' - name: epsilon_max_rate type: number default: 30000 units: mm/min module: root context: Per-actuator setting (epsilon motor maximum speed) defined_in: modules/robot/Robot.cpp:256 corresponding_v1: epsilon_max_rate corresponding_v2: actuator.epsilon.max_rate description: 'Epsilon motor maximum speed: Maximum speed for the epsilon actuator motor in mm/min. For second extruder in dual-extrusion setups, configure same as delta_max_rate. For rotary B axis in CNC, represents maximum angular velocity in degrees per minute. Setting considerations are identical to delta_max_rate.' description_bullets: - For second extruder, typically matches delta_max_rate - May differ if second extruder uses different mechanism - For rotary CNC axes, represents degrees per minute typical_values: - value: 5000 description: 83 mm/s extruder - value: 3000 description: 50 mm/s extruder related_settings: - epsilon_steps_per_mm - delta_max_rate - zeta_max_rate related_pages: - stepper-motors - extruder-guide - multiple-extruders examples: - 'epsilon_max_rate 5000 # Second extruder, 83 mm/s' - name: zeta_max_rate type: number default: 30000 units: mm/min module: root context: Per-actuator setting (zeta motor maximum speed) defined_in: modules/robot/Robot.cpp:256 corresponding_v1: zeta_max_rate corresponding_v2: actuator.zeta.max_rate description: 'Zeta motor maximum speed: Maximum speed for the zeta actuator motor in mm/min. For third extruder in triple-extrusion setups, configure same as delta/epsilon_max_rate. For rotary C axis in CNC, represents maximum angular velocity in degrees per minute. Rarely used outside specialized applications.' description_bullets: - For third extruder, typically matches delta/epsilon_max_rate - Rarely used outside multi-extruder or advanced CNC setups typical_values: - value: 5000 description: 83 mm/s extruder - value: 3000 description: 50 mm/s extruder related_settings: - zeta_steps_per_mm - delta_max_rate - epsilon_max_rate related_pages: - stepper-motors - extruder-guide - multiple-extruders examples: - 'zeta_max_rate 5000 # Third extruder, 83 mm/s' - name: alpha_acceleration type: number default: NAN units: mm/s² module: root context: Per-actuator acceleration override (optional) defined_in: modules/robot/Robot.cpp:257 corresponding_v1: alpha_acceleration corresponding_v2: actuator.x.acceleration description: Per-actuator acceleration override for alpha motor. When set to a valid number, overrides the global default acceleration setting for moves involving the alpha motor. When set to NAN (not a number) or omitted, the alpha motor uses the global default acceleration. This is useful for providing different acceleration characteristics for individual actuators without affecting global behavior. Rarely needed for Cartesian machines where axis-level acceleration (like z_acceleration) is more common. description_bullets: - When NAN or omitted, uses global default acceleration - Rarely needed - most users should use global acceleration instead - More common to use axis-level overrides like z_acceleration - For CoreXY, affects alpha motor specifically, not X axis - 'Setting per-actuator values requires understanding of kinematics: CoreXY/HBot transforms axis motion into motor motion' typical_values: - value: NAN description: use global default - value: 500 description: custom acceleration related_settings: - acceleration - beta_acceleration - gamma_acceleration - z_acceleration related_pages: - motion-control - arm-solutions examples: - '# alpha_acceleration not set # Uses global default (recommended)' - 'alpha_acceleration 500 # Custom acceleration for alpha motor' - name: beta_acceleration type: number default: NAN units: mm/s² module: root context: Per-actuator acceleration override (optional) defined_in: modules/robot/Robot.cpp:257 corresponding_v1: beta_acceleration corresponding_v2: actuator.y.acceleration description: Per-actuator acceleration override for beta motor. When set to a valid number, overrides the global default acceleration setting for moves involving the beta motor. When set to NAN (not a number) or omitted, the beta motor uses the global default acceleration. Identical in function to alpha_acceleration but applies to the beta motor. description_bullets: - When NAN or omitted, uses global default acceleration - Rarely needed for most configurations - For CoreXY, affects beta motor specifically, not Y axis typical_values: - value: NAN description: use global default - value: 500 description: custom acceleration related_settings: - acceleration - alpha_acceleration - gamma_acceleration related_pages: - motion-control - arm-solutions examples: - '# beta_acceleration not set # Uses global default (recommended)' - name: gamma_acceleration type: number default: NAN units: mm/s² module: root context: Per-actuator acceleration override (optional) defined_in: modules/robot/Robot.cpp:257 corresponding_v1: gamma_acceleration corresponding_v2: actuator.z.acceleration description: Per-actuator acceleration override for gamma motor. When set to a valid number, overrides the global default acceleration setting for moves involving the gamma motor. When set to NAN (not a number) or omitted, the gamma motor uses the global default acceleration. For Cartesian machines, this has the same effect as the legacy z_acceleration setting and controls Z-axis acceleration. Most users should use z_acceleration instead as it is more intuitive. description_bullets: - When NAN or omitted, uses global default (or z_acceleration if set) - For Cartesian Z-axis, prefer using z_acceleration setting instead - For delta, this affects third tower and should typically remain NAN typical_values: - value: NAN description: use global default - value: 50 description: custom Z acceleration related_settings: - acceleration - z_acceleration - alpha_acceleration - beta_acceleration related_pages: - motion-control - delta examples: - '# gamma_acceleration not set # Uses z_acceleration or global default' - name: delta_acceleration type: number default: NAN units: mm/s² module: root context: Per-actuator acceleration override (optional) defined_in: modules/robot/Robot.cpp:257 corresponding_v1: delta_acceleration corresponding_v2: actuator.delta.acceleration description: Per-actuator acceleration override for delta motor. When set to a valid number, overrides the global default acceleration setting for the delta actuator. For extruders, this controls how quickly the filament feed can accelerate and decelerate. Lower values reduce the likelihood of filament grinding but may affect print quality by limiting retraction speed. Most users should leave this at NAN to use the global default. description_bullets: - When NAN or omitted, uses global default acceleration - For extruders, affects retraction and filament feed acceleration - Lower values reduce grinding risk but may affect retraction performance - Rarely needs adjustment from default typical_values: - value: NAN description: use global default - value: 500 description: custom extruder acceleration related_settings: - acceleration - epsilon_acceleration - zeta_acceleration related_pages: - motion-control - extruder-guide examples: - '# delta_acceleration not set # Uses global default (recommended)' - name: epsilon_acceleration type: number default: NAN units: mm/s² module: root context: Per-actuator acceleration override (optional) defined_in: modules/robot/Robot.cpp:257 corresponding_v1: epsilon_acceleration corresponding_v2: actuator.epsilon.acceleration description: Per-actuator acceleration override for epsilon motor. When set to a valid number, overrides the global default acceleration setting for the epsilon actuator. For second extruder in dual-extrusion setups, configure same as delta_acceleration if customization is needed. Most users should leave this at NAN to use the global default. description_bullets: - When NAN or omitted, uses global default acceleration - Rarely needs adjustment from default typical_values: - value: NAN description: use global default related_settings: - acceleration - delta_acceleration - zeta_acceleration related_pages: - motion-control - multiple-extruders examples: - '# epsilon_acceleration not set # Uses global default (recommended)' - name: zeta_acceleration type: number default: NAN units: mm/s² module: root context: Per-actuator acceleration override (optional) defined_in: modules/robot/Robot.cpp:257 corresponding_v1: zeta_acceleration corresponding_v2: actuator.zeta.acceleration description: Per-actuator acceleration override for zeta motor. When set to a valid number, overrides the global default acceleration setting for the zeta actuator. For third extruder in triple-extrusion setups, configure same as delta/epsilon_acceleration if customization is needed. Rarely used outside specialized applications. description_bullets: - When NAN or omitted, uses global default acceleration - Rarely used outside specialized multi-extruder setups typical_values: - value: NAN description: use global default related_settings: - acceleration - delta_acceleration - epsilon_acceleration related_pages: - motion-control - multiple-extruders examples: - '# zeta_acceleration not set # Uses global default (recommended)' - name: junction_deviation type: number default: 0.05 units: mm module: root context: Global setting defined_in: modules/robot/Planner.cpp:45 corresponding_v1: junction_deviation corresponding_v2: planner.junction_deviation description: Junction deviation controls cornering speed by defining how much the tool path can deviate from a perfect corner. This replaces traditional "jerk" settings with a more mathematically sound approach. Higher values allow faster cornering but with less precision and potential corner rounding. Lower values ensure precision but require the machine to slow down more at corners. The optimal value depends on mechanical rigidity, desired print quality, and acceptable path deviation. description_bullets: - This is Smoothie's replacement for traditional jerk settings - Lower values = slower corners, more precise path following - Higher values = faster corners, slight path rounding - 0.05mm default balances speed and quality for most machines - Increase for faster prints with acceptable quality loss - Decrease for high-precision work or weak mechanical systems - Too high causes corner bulging in 3D prints or path errors in CNC - Too low causes excessive slowdown and increases print time typical_values: - value: 0.05 description: default - value: 0.02 description: high precision - value: 0.1 description: fast/rough related_settings: - z_junction_deviation related_pages: - motion-control - configuring-smoothie examples: - 'junction_deviation 0.05 # Default balanced setting' - 'junction_deviation 0.02 # High precision mode' - 'junction_deviation 0.1 # Fast mode with less precision' - 'junction_deviation 0.01 # Maximum precision for critical work' - name: z_junction_deviation type: number default: null units: mm module: root context: Global setting defined_in: modules/robot/Planner.cpp:46 corresponding_v1: z_junction_deviation corresponding_v2: planner.z_junction_deviation description: Separate junction deviation for Z axis. When set to a valid number, allows different cornering behavior for moves involving Z-axis motion. When set to NAN (default), Z-axis uses the global junction_deviation value. This is useful for preventing Z artifacts in 3D printing by forcing the nozzle to come to a complete stop at layer changes, or for CNC operations where Z precision is more critical than XY precision. description_bullets: - When NAN, Z uses the global junction_deviation setting - Set to 0.0 to force full stops at all Z direction changes - Useful for eliminating Z-seam artifacts in 3D printing - Important for CNC when Z precision matters more than speed - May increase print time as machine stops at layer changes - Not typically needed for delta printers where Z is not separate typical_values: - value: 0 description: no deviation - value: 0.02 description: slight related_settings: - junction_deviation related_pages: - motion-control - 3d-printer-guide examples: - 'z_junction_deviation 0.0 # Full stop at Z changes (eliminates Z-seam)' - 'z_junction_deviation 0.02 # Slightly more precise than XY' - '# Omit to use junction_deviation for all axes' - name: minimum_planner_speed type: number default: 0 units: mm/s module: root context: Global setting defined_in: modules/robot/Planner.cpp:47 corresponding_v1: minimum_planner_speed corresponding_v2: planner.minimum_planner_speed description: Minimum speed the planner will allow for any move. Prevents extremely slow movements that could cause stepper stalls or uneven extrusion in 3D printing. When set to 0 (default), there is no minimum and the planner can slow down as much as needed. When set to a positive value, the planner will not plan moves slower than this speed, which can help prevent stepper motor stalling at very low speeds but may affect corner quality. description_bullets: - Default of 0.0 disables the minimum speed limit - Useful for preventing stepper stalls on machines with poor low-speed torque - May help with consistent extrusion in 3D printing - Setting too high can prevent the machine from slowing enough for corners - Rarely needs to be changed from default - Value should be well below typical operating speeds typical_values: - value: 0 description: disabled - value: 1 description: minimum crawl related_settings: - junction_deviation - axis max speeds related_pages: - motion-control - stepper-motors examples: - 'minimum_planner_speed 0.0 # No minimum (default)' - 'minimum_planner_speed 1.0 # Prevent very slow moves' - 'minimum_planner_speed 2.0 # Higher minimum for problem motors' - name: planner_queue_size type: number default: 32 module: root context: Global setting defined_in: modules/robot/Conveyor.cpp:77 corresponding_v1: planner_queue_size corresponding_v2: planner.planner_queue_size description: Number of blocks in the planner queue. The planner queue holds upcoming moves and optimizes acceleration/deceleration across them for smooth motion. Larger values allow better speed optimization through more lookahead but consume more RAM. Smaller values use less memory but may result in more speed variations. The minimum recommended value is 8, with 32 being optimal for most use cases. description_bullets: - Larger queue = better motion planning and speed optimization - Smaller queue = less RAM usage - Each block uses approximately 100-150 bytes of RAM - 32 is optimal for most machines - Increase if you see slowdowns on complex curves - Decrease if running out of RAM (rare on LPC1769) - Must be at least 8 for proper operation typical_values: - value: 32 description: default - value: 48 description: more lookahead - value: 24 description: less RAM related_pages: - motion-control - howitworks examples: - 'planner_queue_size 32 # Default optimal size' - 'planner_queue_size 48 # More lookahead for complex paths' - 'planner_queue_size 24 # Reduce if RAM is constrained' - name: queue_delay_time_ms type: number default: 100 units: milliseconds module: root context: Global setting defined_in: modules/robot/Conveyor.cpp:78 corresponding_v1: queue_delay_time_ms corresponding_v2: planner.queue_delay_time_ms description: Milliseconds to wait when the planner queue is full before checking again. This prevents the CPU from spinning in a tight loop when the queue is full and waiting for space. The delay balances responsiveness versus CPU efficiency. Lower values make the system more responsive to new commands when the queue is full, but use more CPU checking. Higher values reduce CPU overhead but may add latency. description_bullets: - Only matters when queue is completely full - 100ms is a good balance for most use cases - Lower values (50ms) = more responsive, slightly more CPU usage - Higher values (200ms) = less CPU overhead, slight latency added - Has no effect on motion quality, only command queueing latency typical_values: - value: 100 description: default - value: 50 description: more responsive - value: 200 description: less CPU related_settings: - planner_queue_size related_pages: - motion-control - howitworks examples: - 'queue_delay_time_ms 100 # Default balanced setting' - 'queue_delay_time_ms 50 # More responsive command handling' - 'queue_delay_time_ms 200 # Reduce CPU overhead' - name: mm_per_line_segment type: number default: 0 units: mm module: root context: Global setting defined_in: modules/robot/Robot.cpp:184 corresponding_v1: mm_per_line_segment corresponding_v2: motion control.mm_per_line_segment description: Maximum length of line segments before splitting into smaller segments. When non-zero, long straight moves are automatically split into segments of this maximum length. This is essential for delta robots (to allow frequent kinematics recalculation) and bed leveling compensation (to apply height adjustments along the move). Set to 0 to disable segmentation. When enabled, affects all linear moves (G1) but not rapids (G0) by default. description_bullets: - Set to 0.0 to disable segmentation (Cartesian without leveling) - 'Required for delta robots: typically 5mm' - 'Required for bed leveling: typically 1-5mm' - Smaller values = more segments = smoother compensation but slower - Larger values = fewer segments = faster but less precise compensation - Not needed for Cartesian without bed leveling - Segments Z moves unless segment_z_moves is false typical_values: - value: 0 description: disabled - value: 5 description: delta printer - value: 1 description: bed leveling related_settings: - delta_segments_per_second - segment_z_moves related_pages: - motion-control - delta - rectangular-grid-calibration-options examples: - 'mm_per_line_segment 0 # Disabled for Cartesian without leveling' - 'mm_per_line_segment 5 # Delta printer segmentation' - 'mm_per_line_segment 1 # Fine bed leveling compensation' - name: delta_segments_per_second type: number default: 0 units: segments/second module: root context: Global setting defined_in: modules/robot/Robot.cpp:185 corresponding_v1: delta_segments_per_second corresponding_v2: motion control.delta_segments_per_second description: For delta robots, an alternative way to specify segmentation based on time rather than distance. When set to a non-zero value, overrides mm_per_line_segment for calculating segment length. The segment length is computed as (move_speed / segments_per_second). This ensures consistent segmentation regardless of move speed, with faster moves getting longer segments and slower moves getting shorter segments, maintaining the target segment rate. description_bullets: - Only used for delta kinematics - When set, overrides mm_per_line_segment calculation - Segment length = move_speed / segments_per_second - 100-200 segments/sec typical for deltas - Higher values = more frequent kinematics calculations = smoother but more CPU - Lower values = less CPU but potentially less smooth motion - Set to 0 to use mm_per_line_segment instead typical_values: - value: 100 description: typical delta - value: 150 description: fast delta - value: 200 description: very fast delta related_settings: - mm_per_line_segment related_pages: - delta - motion-control examples: - 'delta_segments_per_second 100 # Typical delta setting' - 'delta_segments_per_second 150 # Higher rate for smoother motion' - 'delta_segments_per_second 0 # Use mm_per_line_segment instead' - name: mm_per_arc_segment type: number default: 0 units: mm module: root context: Global setting defined_in: modules/robot/Robot.cpp:186 corresponding_v1: mm_per_arc_segment corresponding_v2: motion control.mm_per_arc_segment description: Length of arc segments for G2/G3 circular interpolation moves. When 0 (default), the firmware uses mm_max_arc_error to automatically determine appropriate segment length based on arc radius and allowable deviation. When set to a non-zero value, all arcs are split into fixed-length segments regardless of radius. Fixed segmentation is simpler but less efficient than error-based adaptive segmentation. description_bullets: - 0.0 = use adaptive error-based segmentation (recommended) - Non-zero = fixed segment length for all arcs - Smaller values = smoother arcs but more segments - Larger values = fewer segments but more faceted appearance - Error-based (0.0) is more efficient as it adapts to arc size - Fixed length useful for predictable segment count typical_values: - value: 0.5 description: fine detail - value: 1 description: balanced - value: 0 description: use error-based related_settings: - mm_max_arc_error - arc_correction related_pages: - motion-control - g2 - g3 examples: - 'mm_per_arc_segment 0 # Use adaptive error-based (recommended)' - 'mm_per_arc_segment 0.5 # Fixed 0.5mm segments' - 'mm_per_arc_segment 1.0 # Fixed 1mm segments for faster processing' - name: mm_max_arc_error type: number default: 0.01 units: mm module: root context: Global setting defined_in: modules/robot/Robot.cpp:187 corresponding_v1: mm_max_arc_error corresponding_v2: motion control.mm_max_arc_error description: Maximum allowable deviation from true arc when mm_per_arc_segment is 0. This controls arc segmentation quality versus performance using adaptive segment sizing. The firmware calculates the minimum segment length needed to keep deviation below this threshold. Smaller values create smoother arcs with more segments (slower execution), while larger values create more faceted arcs with fewer segments (faster execution). description_bullets: - Only used when mm_per_arc_segment is 0 - Controls the quality/performance tradeoff for arcs - 0.01mm default is imperceptible for most applications - Reduce to 0.005mm for high-precision work - Increase to 0.02mm for faster processing if quality allows - Small arcs automatically get smaller segments - Large arcs automatically get larger segments typical_values: - value: 0.01 description: default - value: 0.005 description: high precision - value: 0.02 description: faster/rougher related_settings: - mm_per_arc_segment - arc_correction related_pages: - motion-control - g2 - g3 examples: - 'mm_max_arc_error 0.01 # Default quality setting' - 'mm_max_arc_error 0.005 # High precision for critical work' - 'mm_max_arc_error 0.02 # Faster processing, slight quality loss' - name: arc_correction type: number default: 5 module: root context: Global setting defined_in: modules/robot/Robot.cpp:188 corresponding_v1: arc_correction corresponding_v2: motion control.arc_correction description: Number of arc segments before applying geometric correction. When drawing arcs with many small segments, numerical errors can accumulate causing the arc to drift from the intended path. This setting controls how frequently the firmware recalculates from the arc center to correct accumulated error. Lower values apply correction more frequently (more accurate but slightly more CPU), higher values correct less often (faster but potential drift on long arcs). description_bullets: - Controls error correction frequency during arc execution - 5 = correction every 5 segments (default) - Lower values (3) = more frequent correction = more accurate - Higher values (10) = less frequent correction = faster but potential drift - Only matters for long arcs with many segments - Has minimal CPU impact at default value typical_values: - value: 5 description: default - value: 3 description: more frequent - value: 10 description: less frequent related_settings: - mm_per_arc_segment - mm_max_arc_error related_pages: - motion-control - g2 - g3 examples: - 'arc_correction 5 # Default balanced correction' - 'arc_correction 3 # More frequent correction for long arcs' - 'arc_correction 10 # Less frequent for performance' - name: segment_z_moves type: bool default: true module: root context: Global setting defined_in: modules/robot/Robot.cpp:196 corresponding_v1: segment_z_moves corresponding_v2: motion control.segment_z_moves description: Whether to apply line segmentation to Z-only moves. When true (default), pure Z-axis moves are segmented according to mm_per_line_segment like XY moves. When false, pure Z moves bypass segmentation entirely. Setting to false is useful for some bed leveling strategies that need uninterrupted Z moves, or to speed up Z hops and layer changes when segmentation isn't needed. description_bullets: - true = segment Z-only moves (default) - false = Z-only moves bypass segmentation - Affects moves that are pure Z with no XY component - Moves with XY+Z are always segmented based on XY component - Some leveling strategies require this to be false - Can speed up layer changes in 3D printing when false - Delta printers should leave this true related_settings: - mm_per_line_segment - bed leveling strategies related_pages: - motion-control - rectangular-grid-calibration-options examples: - 'segment_z_moves true # Segment all moves including Z (default)' - 'segment_z_moves false # Skip segmentation for pure Z moves' - name: save_g92 type: bool default: false module: root context: Global setting defined_in: modules/robot/Robot.cpp:197 corresponding_v1: save_g92 corresponding_v2: motion control.save_g92 description: Save G92 coordinate offsets to config-override with M500 command. When true, any G92 offset currently in effect will be written to the config-override file when M500 is executed, causing it to persist across reboots. When false (default), G92 offsets are temporary and lost on reset. G92 sets an arbitrary coordinate system offset, essentially redefining what position the machine considers to be a given coordinate. description_bullets: - false = G92 offsets are temporary (default) - true = G92 offsets persist across reboots via M500/M501 - G92 is different from work coordinate systems (G54-G59) - Most users should leave this false for safety - Persistent G92 can cause confusion if forgotten - Useful for machines with fixed fixtures or permanent offsets related_m_codes: - code: M500 description: Save current G92 offset to config-override (if enabled) - code: M501 description: Load saved G92 offset from config-override - code: M503 description: Display current G92 offset related_settings: - save_g54 - set_g92 related_pages: - motion-control - g92-cnc - configuring-smoothie examples: - 'save_g92 false # G92 is temporary (default, safest)' - 'save_g92 true # Persist G92 across reboots' - name: save_g54 type: bool default: true module: root context: Global setting defined_in: modules/robot/Robot.cpp:198 corresponding_v1: save_g54 corresponding_v2: motion control.save_wcs description: Save G54-G59 work coordinate systems to config-override with M500. When true, all work coordinate system offsets (G54, G55, G56, G57, G58, G59) will be written to config-override when M500 is executed, persisting across reboots. When false, WCS offsets are lost on reset. This defaults to true in GRBL mode (for CNC compatibility) and false in RepRap mode (for 3D printer safety). description_bullets: - 'GRBL mode: defaults to true (CNC standard practice)' - 'RepRap mode: defaults to false (3D printer safety)' - Work coordinate systems (WCS) allow multiple coordinate reference points - Common in CNC for multiple part setups or tool offsets - Less common in 3D printing - M500 saves, M501 loads, M503 displays related_m_codes: - code: M500 description: Save current WCS offsets to config-override (if enabled) - code: M501 description: Load saved WCS offsets from config-override - code: M503 description: Display all WCS offsets related_settings: - save_g92 related_pages: - motion-control - g54 - grbl-mode examples: - 'save_g54 false # WCS are temporary (3D printer default)' - 'save_g54 true # Persist WCS (CNC/GRBL default)' - name: set_g92 type: string default: '""' module: root context: Global setting defined_in: modules/robot/Robot.cpp:199 corresponding_v1: set_g92 corresponding_v2: motion control.set_g92 description: 'Set a fixed G92 offset at startup in format "x,y,z". This allows defining a permanent coordinate offset that is applied automatically on boot. Useful for machines with fixed fixtures, permanently mounted work surfaces, or specific coordinate system requirements. The offset redefines what coordinates the machine considers to be at its current position. Example: "10,5,0" means the current position will be considered X10 Y5 Z0.' description_bullets: - Empty string (default) = no automatic G92 offset - Format must be "x,y,z" with comma separators (no spaces recommended) - Applied automatically on boot, before any G-code execution - Different from save_g92 which saves runtime offsets - Useful for fixed work coordinate transformations - Can cause confusion if not documented - Consider work coordinate systems (G54-G59) as alternative related_settings: - save_g92 - save_g54 related_pages: - motion-control - g92-cnc examples: - 'set_g92 0,0,0 # Explicitly no offset' - 'set_g92 10,5,0 # Machine position becomes X10 Y5 Z0 on boot' - 'set_g92 -50,-50,0 # Offset origin 50mm in negative X and Y' - name: arm_solution type: enum default: cartesian module: root context: Global setting defined_in: modules/robot/Robot.cpp:155 required: false corresponding_v1: arm_solution corresponding_v2: motion control.arm_solution description: Specifies the kinematics solution that converts Cartesian coordinates (X, Y, Z) from G-code into actuator motor positions for your machine type. This is one of the most fundamental settings as it determines how the firmware interprets motion commands and calculates the relationship between desired position and motor movements. Each arm solution has its own set of additional parameters that must be configured for proper operation. Changing this requires reconfiguring many other settings and recalibrating the machine. description_bullets: - 'CRITICAL: Must exactly match your physical machine configuration' - 'Most common: cartesian (direct 1:1 motor to axis mapping)' - Each solution requires specific additional parameters - Changing this invalidates most other configuration settings - Incorrect selection can cause dangerous motion behavior - Linear delta requires arm_length, arm_radius parameters - CoreXY/HBot require careful motor direction configuration - SCARA requires arm lengths and offset parameters valid_values: - value: cartesian description: Standard Cartesian kinematics with 1:1 motor-to-axis mapping - value: rotatable_cartesian description: Cartesian with rotatable coordinate system (V1 only) - value: linear_delta description: Linear delta kinematics (Kossel-style delta printers) - value: rotary_delta description: Rotary delta kinematics (delta with rotational joints) - value: hbot description: H-Bot belt-driven kinematics - value: corexy description: CoreXY belt-driven kinematics - value: morgan description: Morgan SCARA arm kinematics - value: rostock description: Alias for linear_delta (Rostock-style delta) - value: kossel description: Alias for linear_delta (Kossel-style delta) - value: delta description: Alias for linear_delta (generic delta) related_settings: - arm_length - arm_radius - x_reduction - z_reduction - arm1_length - arm2_length related_pages: - arm-solutions - cartesian - delta - corexy - hbot - morgan-scara examples: - 'arm_solution cartesian # Standard 3-axis CNC or 3D printer' - 'arm_solution linear_delta # Kossel-style delta printer' - 'arm_solution corexy # CoreXY 3D printer' - 'arm_solution hbot # H-Bot 3D printer' - 'arm_solution morgan # Morgan SCARA arm' - name: x_reduction type: number default: 1 module: root context: Global setting (only for CoreXZ) defined_in: modules/robot/arm_solutions/CoreXZSolution.cpp:11 corresponding_v1: x_reduction corresponding_v2: none (CoreXZ not documented in v2) description: For CoreXZ kinematics only. Reduction factor for the X axis component in the CoreXZ transformation matrix. Controls how much the X motor contributes to X-axis motion. In CoreXZ, two motors work together to control XZ motion similar to how CoreXY controls XY motion. This parameter allows tuning the kinematic transformation to match your mechanical configuration. Typically left at default 1.0 unless you have an unusual CoreXZ design. description_bullets: - Only applies when arm_solution is corexz - Has no effect for other kinematics types - Default 1.0 is correct for standard CoreXZ implementations - Adjusting this changes the X-axis motion contribution ratio - Incorrectly setting this will cause distorted XZ motion related_settings: - z_reduction - arm_solution - corexz - applies only when is related_pages: - arm-solutions - hbot examples: - 'x_reduction 1.0 # Standard CoreXZ configuration' - name: z_reduction type: number default: 3 module: root context: Global setting (only for CoreXZ) defined_in: modules/robot/arm_solutions/CoreXZSolution.cpp:12 corresponding_v1: z_reduction corresponding_v2: none (CoreXZ not documented in v2) description: For CoreXZ kinematics only. Reduction factor for the Z axis component in the CoreXZ transformation matrix. Controls how much the Z motor contributes to Z-axis motion relative to X motion. CoreXZ typically has Z on a leadscrew while X uses belts, creating different mechanical ratios. The default 3.0 reflects common mechanical advantage differences. This should be calculated based on your specific mechanical configuration (belt pitch vs leadscrew pitch). description_bullets: - Only applies when arm_solution is corexz - Has no effect for other kinematics types - Default 3.0 accounts for typical leadscrew vs belt ratio - 'Calculate based on: (Z_steps_per_mm / X_steps_per_mm)' - Incorrectly setting this will cause distorted XZ motion - Z will move too much or too little relative to X related_settings: - x_reduction - arm_solution - corexz - applies only when is related_pages: - arm-solutions - hbot examples: - 'z_reduction 3.0 # Standard ratio for leadscrew Z with belt X' - 'z_reduction 2.0 # Different mechanical configuration' - name: alpha_angle type: number default: 0 units: degrees module: root context: Global setting (only for rotatable_cartesian and experimental_delta) defined_in: modules/robot/arm_solutions/RotatableCartesianSolution.cpp:12 corresponding_v1: alpha_angle corresponding_v2: none (not documented in v2) description: Rotation angle in degrees for rotatable_cartesian and experimental_delta arm solutions. Rotates the entire coordinate plane by this angle around the Z-axis. For rotatable_cartesian, allows using standard Cartesian mechanics with a rotated reference frame, useful for machines where the mechanical axes don't align with the desired work coordinate system. For experimental_delta, provides an angular offset for the alpha tower position. description_bullets: - Only applies to rotatable_cartesian and experimental_delta arm solutions - 'NOTE: When using experimental_delta arm solution, the default is 30.0 instead of 0.0' - Has no effect for other kinematics - Rotates coordinate system around Z-axis - 0° = no rotation (standard alignment) - Positive angles rotate counter-clockwise (from top view) - Useful for machines with mechanically rotated gantries - Rarely needed for standard configurations related_settings: - arm_solution - rotatable_cartesian - experimental_delta - Applies only when is or related_pages: - arm-solutions - delta examples: - 'alpha_angle 0.0 # No rotation (standard)' - 'alpha_angle 45.0 # 45° rotation for diamond-oriented gantry' - name: arm_length type: number default: 250 units: mm module: root context: Global setting (only for linear delta) defined_in: modules/robot/arm_solutions/LinearDeltaSolution.cpp:32 required: false corresponding_v1: arm_length corresponding_v2: linear delta.arm_length description: For linear delta robots only. Physical length of the diagonal connecting rod from the upper carriage hinge point to the lower effector hinge point. This is one of the two critical geometric parameters for delta kinematics (along with arm_radius). Measure carefully from center of upper ball joint to center of lower ball joint. Incorrect values will cause the effector to trace incorrect paths and dimensional inaccuracy across the bed. description_bullets: - 'CRITICAL: Must be measured accurately for proper delta kinematics' - Measure from center of upper hinge to center of lower hinge - Typically 200-400mm depending on delta size - Affects the entire kinematic solution - Incorrect value causes dimensional errors across entire bed - Can be fine-tuned during delta calibration - Use same measurement technique for all three arms related_settings: - arm_radius - arm_solution - linear_delta - delta - kossel - rostock - applies only when is - or related_pages: - delta - delta-calibration-strategy-options - arm-solutions examples: - 'arm_length 250.0 # 250mm diagonal rods' - 'arm_length 217.5 # Common for small Mini Kossel' - 'arm_length 300.0 # Larger delta printer' - name: arm_radius type: number default: 124 units: mm module: root context: Global setting (only for linear delta) defined_in: modules/robot/arm_solutions/LinearDeltaSolution.cpp:34 required: false corresponding_v1: arm_radius corresponding_v2: linear delta.arm_radius description: For linear delta robots only. Horizontal distance from center of bed to the center of each tower's linear rail when the effector is centered at build height. Also called delta radius. This is the second critical geometric parameter for delta kinematics. Together with arm_length, defines the workspace geometry and motion calculations. Incorrect values cause the effector to move in warped paths and dimensional errors increase with distance from center. description_bullets: - 'CRITICAL: Must be measured accurately for proper delta kinematics' - Measure with effector centered at build height - Distance from bed center to tower rail center - Typically 100-200mm depending on printer size - Smaller radius = smaller build area, more height - Larger radius = larger build area, less height - Can be fine-tuned during delta calibration - Also affects maximum reach and reachable height related_settings: - arm_length - arm_solution - linear_delta - delta - kossel - rostock - applies only when is - or related_pages: - delta - delta-calibration-strategy-options - arm-solutions examples: - 'arm_radius 124.0 # Medium-size delta printer' - 'arm_radius 90.0 # Smaller printer like Mini Kossel' - 'arm_radius 150.0 # Large delta printer' - name: delta_tower1_angle type: number default: 0 units: degrees module: root context: Global setting (only for linear delta) defined_in: modules/robot/arm_solutions/LinearDeltaSolution.cpp:36 corresponding_v1: delta_tower1_angle corresponding_v2: none (not documented in v2) description: Angular offset correction for tower 1 position (alpha tower, front-left at nominal 210°). Used during delta calibration to correct for manufacturing tolerances where towers are not perfectly positioned at 120° intervals. Positive values rotate the tower counter-clockwise (from top view). Typically adjusted in small increments during calibration to achieve best dimensional accuracy. Values are usually in the range of -5° to +5°. description_bullets: - Fine-tuning parameter for delta calibration - Corrects for imperfect tower positioning - Adjusted to minimize dimensional errors across bed - Typically very small values (under ±5°) - Start at 0.0 and adjust during calibration - Use auto-calibration routine for best results - Manual adjustment requires iterative testing related_settings: - delta_tower2_angle - delta_tower3_angle - delta_tower1_offset - applies only to linear delta related_pages: - delta - delta-calibration-strategy-options examples: - 'delta_tower1_angle 0.0 # No correction (starting point)' - 'delta_tower1_angle -0.5 # Slight adjustment from calibration' - 'delta_tower1_angle 1.2 # Correction for manufacturing variance' - name: delta_tower2_angle type: number default: 0 units: degrees module: root context: Global setting (only for linear delta) defined_in: modules/robot/arm_solutions/LinearDeltaSolution.cpp:37 corresponding_v1: delta_tower2_angle corresponding_v2: none (not documented in v2) description: Angular offset correction for tower 2 position (beta tower, front-right at nominal 330°). Used during delta calibration to correct for manufacturing tolerances where towers are not perfectly positioned at 120° intervals. Positive values rotate the tower counter-clockwise (from top view). Typically adjusted in small increments during calibration to achieve best dimensional accuracy. Values are usually in the range of -5° to +5°. description_bullets: - Fine-tuning parameter for delta calibration - Corrects for imperfect tower positioning - Adjusted to minimize dimensional errors across bed - Typically very small values (under ±5°) - Start at 0.0 and adjust during calibration - Use auto-calibration routine for best results related_settings: - delta_tower1_angle - delta_tower3_angle - delta_tower2_offset - applies only to linear delta related_pages: - delta - delta-calibration-strategy-options examples: - 'delta_tower2_angle 0.0 # No correction (starting point)' - 'delta_tower2_angle 0.3 # Slight adjustment from calibration' - name: delta_tower3_angle type: number default: 0 units: degrees module: root context: Global setting (only for linear delta) defined_in: modules/robot/arm_solutions/LinearDeltaSolution.cpp:38 corresponding_v1: delta_tower3_angle corresponding_v2: none (not documented in v2) description: Angular offset correction for tower 3 position (gamma tower, back-center at nominal 90°). Used during delta calibration to correct for manufacturing tolerances where towers are not perfectly positioned at 120° intervals. Positive values rotate the tower counter-clockwise (from top view). Typically adjusted in small increments during calibration to achieve best dimensional accuracy. Values are usually in the range of -5° to +5°. description_bullets: - Fine-tuning parameter for delta calibration - Corrects for imperfect tower positioning - Adjusted to minimize dimensional errors across bed - Typically very small values (under ±5°) - Start at 0.0 and adjust during calibration - Use auto-calibration routine for best results related_settings: - delta_tower1_angle - delta_tower2_angle - delta_tower3_offset - applies only to linear delta related_pages: - delta - delta-calibration-strategy-options examples: - 'delta_tower3_angle 0.0 # No correction (starting point)' - 'delta_tower3_angle -0.8 # Adjustment from calibration' - name: delta_tower1_offset type: number default: 0 units: mm module: root context: Global setting (only for linear delta) defined_in: modules/robot/arm_solutions/LinearDeltaSolution.cpp:39 corresponding_v1: delta_tower1_offset corresponding_v2: none (not documented in v2) description: Radial offset correction for tower 1 position. Positive values move the tower away from the bed center, negative values move it toward center. Used during delta calibration to correct for manufacturing tolerances in tower positioning relative to the ideal delta radius. Typically adjusted in small increments (under ±5mm) to achieve best dimensional accuracy across the bed. Works in conjunction with tower angle corrections. description_bullets: - Fine-tuning parameter for delta calibration - Corrects radial tower position errors - Positive = farther from center, negative = closer to center - Typically very small values (under ±5mm) - Start at 0.0 and adjust during calibration - Affects bed size and reachable area - Use auto-calibration for best results related_settings: - delta_tower2_offset - delta_tower3_offset - delta_tower1_angle - arm_radius related_pages: - delta - delta-calibration-strategy-options examples: - 'delta_tower1_offset 0.0 # No correction (starting point)' - 'delta_tower1_offset 1.5 # Move tower 1.5mm away from center' - 'delta_tower1_offset -0.8 # Move tower 0.8mm toward center' - name: delta_tower2_offset type: number default: 0 units: mm module: root context: Global setting (only for linear delta) defined_in: modules/robot/arm_solutions/LinearDeltaSolution.cpp:40 corresponding_v1: delta_tower2_offset corresponding_v2: none (not documented in v2) description: Radial offset correction for tower 2 position. Positive values move the tower away from the bed center, negative values move it toward center. Used during delta calibration to correct for manufacturing tolerances in tower positioning relative to the ideal delta radius. Typically adjusted in small increments (under ±5mm) to achieve best dimensional accuracy across the bed. Works in conjunction with tower angle corrections. description_bullets: - Fine-tuning parameter for delta calibration - Corrects radial tower position errors - Positive = farther from center, negative = closer to center - Typically very small values (under ±5mm) - Start at 0.0 and adjust during calibration - Affects bed size and reachable area related_settings: - delta_tower1_offset - delta_tower3_offset - delta_tower2_angle - arm_radius related_pages: - delta - delta-calibration-strategy-options examples: - 'delta_tower2_offset 0.0 # No correction (starting point)' - 'delta_tower2_offset -1.2 # Move tower 1.2mm toward center' - name: delta_tower3_offset type: number default: 0 units: mm module: root context: Global setting (only for linear delta) defined_in: modules/robot/arm_solutions/LinearDeltaSolution.cpp:41 corresponding_v1: delta_tower3_offset corresponding_v2: none (not documented in v2) description: Radial offset correction for tower 3 position. Positive values move the tower away from the bed center, negative values move it toward center. Used during delta calibration to correct for manufacturing tolerances in tower positioning relative to the ideal delta radius. Typically adjusted in small increments (under ±5mm) to achieve best dimensional accuracy across the bed. Works in conjunction with tower angle corrections. description_bullets: - Fine-tuning parameter for delta calibration - Corrects radial tower position errors - Positive = farther from center, negative = closer to center - Typically very small values (under ±5mm) - Start at 0.0 and adjust during calibration - Affects bed size and reachable area related_settings: - delta_tower1_offset - delta_tower2_offset - delta_tower3_angle - arm_radius related_pages: - delta - delta-calibration-strategy-options examples: - 'delta_tower3_offset 0.0 # No correction (starting point)' - 'delta_tower3_offset 0.7 # Move tower 0.7mm away from center' - name: delta_halt_on_error type: bool default: true module: root context: Global setting (only for delta arm solutions) defined_in: modules/robot/arm_solutions/LinearDeltaSolution.cpp:42 corresponding_v1: delta_halt_on_error corresponding_v2: none (not documented in v2) description: For delta robots (both linear and rotary), controls whether motion halts when kinematic calculation fails due to unreachable position. When true (default), attempting to move to a position that's kinematically impossible will halt the machine with an error. When false, continues with a warning but unpredictable motion. Unreachable positions occur when requesting positions outside the workspace, typically near the edge of the build area or extreme heights. description_bullets: - true = halt machine on unreachable position (default, safest) - false = continue with warning (dangerous) - Unreachable positions are outside the kinematic workspace - Usually caused by G-code requesting positions beyond build area - Can also occur with incorrect arm_length/arm_radius configuration - 'IMPORTANT: Setting to false can cause unpredictable motion' - Recommended to leave at true for safety related_settings: - arm_length - arm_radius - applies to all delta arm solutions related_pages: - delta - arm-solutions examples: - 'delta_halt_on_error true # Halt on unreachable position (recommended)' - 'delta_halt_on_error false # Continue with warning (not recommended)' - name: beta_relative_angle type: number default: 120 units: degrees module: root context: Global setting (only for experimental_delta) defined_in: modules/robot/arm_solutions/ExperimentalDeltaSolution.cpp:26 corresponding_v1: beta_relative_angle corresponding_v2: none (experimental feature not in v2) description: For experimental delta arm solution only. Defines the relative angular position of the beta tower (tower 2). Standard deltas have three towers positioned at 0°, 120°, and 240° around the build area. This setting allows non-standard tower spacing by adjusting where the beta tower is located relative to alpha tower (which is at alpha_angle). Typically 120° for standard delta geometry. Experimental feature for non-standard delta configurations. description_bullets: - Only applies to experimental_delta arm solution - Standard value is 120° for equilateral tower arrangement - Measured relative to alpha tower position - Non-standard values create asymmetric delta configurations - Requires careful kinematic understanding - Most users should use standard 120° related_settings: - alpha_angle - gamma_relative_angle - experimental_delta - applies only to related_pages: - delta - arm-solutions examples: - 'beta_relative_angle 120.0 # Standard delta geometry' - name: gamma_relative_angle type: number default: 240 units: degrees module: root context: Global setting (only for experimental_delta) defined_in: modules/robot/arm_solutions/ExperimentalDeltaSolution.cpp:29 corresponding_v1: gamma_relative_angle corresponding_v2: none (experimental feature not in v2) description: For experimental delta arm solution only. Defines the relative angular position of the gamma tower (tower 3). Standard deltas have three towers positioned at 0°, 120°, and 240° around the build area. This setting allows non-standard tower spacing by adjusting where the gamma tower is located relative to alpha tower (which is at alpha_angle). Typically 240° for standard delta geometry. Experimental feature for non-standard delta configurations. description_bullets: - Only applies to experimental_delta arm solution - Standard value is 240° for equilateral tower arrangement - Measured relative to alpha tower position - Non-standard values create asymmetric delta configurations - Requires careful kinematic understanding - Most users should use standard 240° related_settings: - alpha_angle - beta_relative_angle - experimental_delta - applies only to related_pages: - delta - arm-solutions examples: - 'gamma_relative_angle 240.0 # Standard delta geometry' - name: delta_e type: number default: 131.636 units: mm module: root context: Global setting (only for rotary_delta) defined_in: modules/robot/arm_solutions/RotaryDeltaSolution.cpp:36 corresponding_v1: delta_e corresponding_v2: none (rotary delta not documented in v2) description: For rotary delta arm solution only. End effector triangle side length - the distance between ball joints on the effector platform. In rotary delta designs, the effector is triangular with ball joints at each corner where the connecting rods attach. This parameter defines the size of that triangle, which is a critical geometric parameter for rotary delta kinematics calculations. Must match the physical dimensions of your effector platform. description_bullets: - Only applies to rotary_delta arm solution - Measure center-to-center of ball joints on effector - Part of the fundamental rotary delta geometry - Incorrect value causes position errors - Must be measured very accurately - Rotary delta is experimental/rare configuration related_settings: - delta_f - delta_re - delta_rf - rotary_delta - applies only to related_pages: - rotary-delta - arm-solutions examples: - 'delta_e 131.636 # Default effector triangle size' - name: delta_f type: number default: 190.526 units: mm module: root context: Global setting (only for rotary_delta) defined_in: modules/robot/arm_solutions/RotaryDeltaSolution.cpp:39 corresponding_v1: delta_f corresponding_v2: none (rotary delta not documented in v2) description: For rotary delta arm solution only. Base triangle side length - the distance between servo pivot points on the stationary base. In rotary delta designs, three servo motors are mounted on a triangular base, and this parameter defines the size of that base triangle. This is a critical geometric parameter for rotary delta kinematics. Must match the physical dimensions of your base plate servo mounting positions. description_bullets: - Only applies to rotary_delta arm solution - Measure center-to-center of servo pivot points on base - Part of the fundamental rotary delta geometry - Incorrect value causes position errors - Must be measured very accurately - Typically larger than delta_e related_settings: - delta_e - delta_re - delta_rf - rotary_delta - applies only to related_pages: - rotary-delta - arm-solutions examples: - 'delta_f 190.526 # Default base triangle size' - name: delta_re type: number default: 270 units: mm module: root context: Global setting (only for rotary_delta) defined_in: modules/robot/arm_solutions/RotaryDeltaSolution.cpp:42 corresponding_v1: delta_re corresponding_v2: none (rotary delta not documented in v2) description: For rotary delta arm solution only. Carbon rod length - the length of the connecting rods (parallelogram links) between the servo horn and the effector platform. In rotary delta mechanisms, each servo has an arm (horn) that connects via a parallelogram linkage to the effector. This is the length of those connecting rods, similar in concept to arm_length in linear delta but for the rotary configuration. description_bullets: - Only applies to rotary_delta arm solution - Measure center-to-center of ball joints on the connecting rod - Critical for correct rotary delta kinematics - Incorrect value causes position errors and dimensional inaccuracy - Must match physical rod length precisely - All six rods should be identical length related_settings: - delta_e - delta_f - delta_rf - rotary_delta - applies only to related_pages: - rotary-delta - arm-solutions examples: - 'delta_re 270.0 # Default connecting rod length' - name: delta_rf type: number default: 90 units: mm module: root context: Global setting (only for rotary_delta) defined_in: modules/robot/arm_solutions/RotaryDeltaSolution.cpp:45 corresponding_v1: delta_rf corresponding_v2: none (rotary delta not documented in v2) description: For rotary delta arm solution only. Servo horn length - the distance from the servo pivot point (motor shaft) to the rod connection point on the servo horn. This is the radius of the rotating arm attached to each servo motor. The servo rotates this arm, which pulls/pushes the connecting rods to move the effector. A critical parameter for rotary delta kinematics that affects the mechanical advantage and workspace. description_bullets: - Only applies to rotary_delta arm solution - Measure from servo shaft center to rod connection point - Critical for correct rotary delta kinematics - Affects servo rotation to position translation - All three servo horns should be identical length - Typically much shorter than delta_re related_settings: - delta_e - delta_f - delta_re - rotary_delta - applies only to related_pages: - rotary-delta - arm-solutions examples: - 'delta_rf 90.0 # Default servo horn length' - name: delta_z_offset type: number default: 290.7 units: mm module: root context: Global setting (only for rotary_delta) defined_in: modules/robot/arm_solutions/RotaryDeltaSolution.cpp:49 corresponding_v1: delta_z_offset corresponding_v2: none (rotary delta not documented in v2) description: For rotary delta arm solution only. Vertical distance from the servo pivot plane (the plane where all three servo shafts are located) to the bed surface when the machine is homed. This defines the Z=0 position relative to the mechanical reference point. Used to translate between the kinematic coordinate system and the actual work coordinate system. Must be measured accurately for correct Z positioning. description_bullets: - Only applies to rotary_delta arm solution - Measured with machine in home position - Distance from servo plane to bed surface - Defines the Z=0 reference point - Affects all Z-axis positioning - Can be adjusted to calibrate Z height related_settings: - delta_ee_offs - delta_tool_offset - rotary_delta - applies only to related_pages: - rotary-delta - arm-solutions examples: - 'delta_z_offset 290.7 # Default Z offset' - name: delta_ee_offs type: number default: 15 units: mm module: root context: Global setting (only for rotary_delta) defined_in: modules/robot/arm_solutions/RotaryDeltaSolution.cpp:52 corresponding_v1: delta_ee_offs corresponding_v2: none (rotary delta not documented in v2) description: For rotary delta arm solution only. Distance from the ball joint plane to the bottom of the end effector surface - essentially the thickness of the effector platform. The ball joints attach to the top of the effector, but the tool (nozzle, end mill, etc.) is mounted to the bottom. This parameter accounts for that offset in the kinematic calculations, ensuring the tool tip position is calculated correctly. description_bullets: - Only applies to rotary_delta arm solution - Thickness of effector platform - Distance from ball joint plane to bottom surface - Affects Z-axis positioning accuracy - Must match actual effector dimensions - Typically 10-20mm depending on effector design related_settings: - delta_z_offset - delta_tool_offset - rotary_delta - applies only to related_pages: - rotary-delta - arm-solutions examples: - 'delta_ee_offs 15.0 # 15mm effector thickness' - name: delta_tool_offset type: number default: 30.5 units: mm module: root context: Global setting (only for rotary_delta) defined_in: modules/robot/arm_solutions/RotaryDeltaSolution.cpp:55 corresponding_v1: delta_tool_offset corresponding_v2: none (rotary delta not documented in v2) description: For rotary delta arm solution only. Distance between the effector ball joint plane and the tool tip (nozzle, gripper, etc.). This accounts for how far the actual tool extends below the effector structure. Used primarily in pick-and-place applications to account for varying tool lengths. Positive values indicate tool extends downward, negative values would indicate tool above effector (unusual). description_bullets: - Only applies to rotary_delta arm solution - Distance from ball joint plane to tool tip - Allows compensation for different tool lengths - Important for pick-and-place accuracy - Can be adjusted for different tool types - Affects all Z-axis positioning related_settings: - delta_z_offset - delta_ee_offs - rotary_delta - applies only to related_pages: - rotary-delta - pick-and-place - arm-solutions examples: - 'delta_tool_offset 30.5 # 30.5mm tool extension' - 'delta_tool_offset 45.0 # Longer tool' - 'delta_tool_offset 20.0 # Shorter tool' - name: delta_mirror_xy type: bool default: false module: root context: Global setting (only for rotary_delta) defined_in: modules/robot/arm_solutions/RotaryDeltaSolution.cpp:58 corresponding_v1: delta_mirror_xy corresponding_v2: none (rotary delta not documented in v2) description: For rotary delta arm solution only. Mirror (flip) the XY coordinate system. This is useful for correcting coordinate system orientation without making physical changes to the machine. When true, X and Y axes are mirrored, which is equivalent to viewing the machine from the opposite side. Useful when the physical servo arrangement doesn't match the desired coordinate system orientation. description_bullets: - Only applies to rotary_delta arm solution - false = standard XY orientation (default) - true = mirror XY axes - Useful for correcting coordinate system without rewiring - Equivalent to flipping the view of the machine - Rarely needed unless machine was built backwards related_settings: - rotary_delta - applies only to related_pages: - rotary-delta - arm-solutions examples: - 'delta_mirror_xy false # Standard orientation' - 'delta_mirror_xy true # Mirror XY axes' - name: arm1_length type: number default: 150 units: mm module: root context: Global setting (only for morgan SCARA) defined_in: modules/robot/arm_solutions/MorganSCARASolution.cpp:30 required: false corresponding_v1: arm1_length corresponding_v2: morgan scara.arm1_length description: For Morgan SCARA arm solution only. Length of the first arm segment from the base hinge to the elbow hinge. This is the inner arm of the SCARA robotic arm mechanism. Along with arm2_length, defines the reach and workspace of the SCARA robot. The two arms work together in a planar configuration to position the end effector within a circular or annular workspace. Must match physical arm dimensions precisely. description_bullets: - Only applies to morgan SCARA arm solution - Measure from base pivot center to elbow pivot center - Critical for correct SCARA kinematics - Together with arm2_length defines workspace - Incorrect value causes position errors - All measurements should be precise related_settings: - arm2_length - morgan_offset_x - morgan_offset_y - morgan - applies only to related_pages: - morgan-scara - arm-solutions examples: - 'arm1_length 150.0 # 150mm inner arm' - name: arm2_length type: number default: 150 units: mm module: root context: Global setting (only for morgan SCARA) defined_in: modules/robot/arm_solutions/MorganSCARASolution.cpp:32 required: false corresponding_v1: arm2_length corresponding_v2: morgan scara.arm2_length description: For Morgan SCARA arm solution only. Length of the second arm segment from the elbow hinge to the end effector. This is the outer arm of the SCARA robotic arm mechanism. Along with arm1_length, defines the reach and workspace of the SCARA robot. The maximum reach is arm1_length + arm2_length, while the minimum reach (if reachable) is arm1_length - arm2_length. Must match physical arm dimensions precisely. description_bullets: - Only applies to morgan SCARA arm solution - Measure from elbow pivot center to end effector center - Critical for correct SCARA kinematics - Together with arm1_length defines workspace - Max reach = arm1 + arm2 - Min reach = abs(arm1 - arm2) related_settings: - arm1_length - morgan_offset_x - morgan_offset_y - morgan - applies only to related_pages: - morgan-scara - arm-solutions examples: - 'arm2_length 150.0 # 150mm outer arm (same as inner for symmetric SCARA)' - 'arm2_length 120.0 # Shorter outer arm' - name: morgan_offset_x type: number default: 100 units: mm module: root context: Global setting (only for morgan SCARA) defined_in: modules/robot/arm_solutions/MorganSCARASolution.cpp:34 corresponding_v1: morgan_offset_x corresponding_v2: morgan scara.morgan_offset_x description: For Morgan SCARA arm solution only. X-axis offset of the bed zero position (work origin) from the SCARA tower center (base pivot point). SCARA robots typically have their base pivot at a fixed mechanical location, but the desired work coordinate zero may be offset from this point. This parameter shifts the work coordinate system to place X=0 at the desired location relative to the SCARA base. description_bullets: - Only applies to morgan SCARA arm solution - Defines work coordinate origin relative to SCARA base - Positive values shift work origin in positive X direction - Negative values shift work origin in negative X direction - Used to center working area within SCARA reach - Can be any value within reachable workspace related_settings: - morgan_offset_y - arm1_length - arm2_length - morgan - applies only to related_pages: - morgan-scara - arm-solutions examples: - 'morgan_offset_x 100.0 # Work origin 100mm in X from SCARA base' - 'morgan_offset_x 0.0 # Work origin at SCARA base X position' - 'morgan_offset_x -50.0 # Work origin 50mm in negative X' - name: morgan_offset_y type: number default: -60 units: mm module: root context: Global setting (only for morgan SCARA) defined_in: modules/robot/arm_solutions/MorganSCARASolution.cpp:36 corresponding_v1: morgan_offset_y corresponding_v2: morgan scara.morgan_offset_y description: For Morgan SCARA arm solution only. Y-axis offset of the bed zero position (work origin) from the SCARA tower center (base pivot point). SCARA robots typically have their base pivot at a fixed mechanical location, but the desired work coordinate zero may be offset from this point. This parameter shifts the work coordinate system to place Y=0 at the desired location relative to the SCARA base. description_bullets: - Only applies to morgan SCARA arm solution - Defines work coordinate origin relative to SCARA base - Positive values shift work origin in positive Y direction - Negative values shift work origin in negative Y direction - Used to center working area within SCARA reach - Default negative value positions work area in front of base related_settings: - morgan_offset_x - arm1_length - arm2_length - morgan - applies only to related_pages: - morgan-scara - arm-solutions examples: - 'morgan_offset_y -60.0 # Work origin 60mm in negative Y (front of base)' - 'morgan_offset_y 0.0 # Work origin at SCARA base Y position' - 'morgan_offset_y 100.0 # Work origin 100mm in positive Y' - name: morgan_scaling_x type: number default: 1 module: root context: Global setting (only for morgan SCARA) defined_in: modules/robot/arm_solutions/MorganSCARASolution.cpp:38 corresponding_v1: morgan_scaling_x corresponding_v2: morgan scara.morgan_scaling_x description: For Morgan SCARA arm solution only. Final calibration scaling factor for X axis movement. Used to fine-tune dimensions after mechanical calibration, accounting for arm flexing, backlash, or other non-linear effects. A value of 1.0 means no scaling (100%), values above 1.0 increase movement, values below 1.0 decrease movement. Typically adjusted by measuring actual vs commanded distances and calculating correction ratio. description_bullets: - Only applies to morgan SCARA arm solution - 1.0 = no scaling, 100% nominal (default) - '>1.0 = increase movement (e.g., 1.01 = 1% larger)' - <1.0 = decrease movement (e.g., 0.99 = 1% smaller) - Fine-tuning parameter for final dimensional accuracy - Adjusted after basic calibration is complete - Typical range 0.95-1.05 related_settings: - morgan_scaling_y - arm1_length - arm2_length - morgan - applies only to related_pages: - morgan-scara - arm-solutions examples: - 'morgan_scaling_x 1.0 # No scaling (default)' - 'morgan_scaling_x 1.02 # 2% larger movements in X' - 'morgan_scaling_x 0.98 # 2% smaller movements in X' - name: morgan_scaling_y type: number default: 1 module: root context: Global setting (only for morgan SCARA) defined_in: modules/robot/arm_solutions/MorganSCARASolution.cpp:39 corresponding_v1: morgan_scaling_y corresponding_v2: morgan scara.morgan_scaling_y description: For Morgan SCARA arm solution only. Final calibration scaling factor for Y axis movement. Used to fine-tune dimensions after mechanical calibration, accounting for arm flexing, backlash, or other non-linear effects. A value of 1.0 means no scaling (100%), values above 1.0 increase movement, values below 1.0 decrease movement. Typically adjusted by measuring actual vs commanded distances and calculating correction ratio. description_bullets: - Only applies to morgan SCARA arm solution - 1.0 = no scaling, 100% nominal (default) - '>1.0 = increase movement (e.g., 1.01 = 1% larger)' - <1.0 = decrease movement (e.g., 0.99 = 1% smaller) - Fine-tuning parameter for final dimensional accuracy - Adjusted after basic calibration is complete - May differ from X scaling due to mechanical asymmetry related_settings: - morgan_scaling_x - arm1_length - arm2_length - morgan - applies only to related_pages: - morgan-scara - arm-solutions examples: - 'morgan_scaling_y 1.0 # No scaling (default)' - 'morgan_scaling_y 1.01 # 1% larger movements in Y' - 'morgan_scaling_y 0.99 # 1% smaller movements in Y' - name: morgan_undefined_min type: number default: 0.95 module: root context: Global setting (only for morgan SCARA) defined_in: modules/robot/arm_solutions/MorganSCARASolution.cpp:43 corresponding_v1: morgan_undefined_min corresponding_v2: morgan scara.morgan_undefined_min description: For Morgan SCARA arm solution only. Ratio defining where SCARA position becomes kinematically undefined when the end effector approaches too close to the base tower. SCARA arms have singularity points where the arm configuration is ambiguous or mechanically unstable. This parameter prevents movement through the inner singularity. Value of 0.95 means positions closer than 95% of minimum theoretical reach are forbidden. Higher values are more restrictive (safer). description_bullets: - Only applies to morgan SCARA arm solution - Prevents movement through inner singularity point - 0.95 = 95% of minimum reach (default) - Higher values = more restrictive, larger forbidden zone - Lower values = allow closer approach to base (dangerous) - Protects against mechanically unstable configurations - Machine will refuse moves into forbidden zone related_settings: - morgan_undefined_max - arm1_length - arm2_length - morgan - applies only to related_pages: - morgan-scara - arm-solutions examples: - 'morgan_undefined_min 0.95 # Default safe limit' - 'morgan_undefined_min 0.98 # More conservative, larger forbidden zone' - name: morgan_undefined_max type: number default: 0.95 module: root context: Global setting (only for morgan SCARA) defined_in: modules/robot/arm_solutions/MorganSCARASolution.cpp:45 corresponding_v1: morgan_undefined_max corresponding_v2: morgan scara.morgan_undefined_max description: For Morgan SCARA arm solution only. Ratio defining where SCARA position becomes kinematically undefined when the end effector reaches maximum extension. SCARA arms have singularity points where the arm is fully extended and the elbow joint is locked straight, creating mechanical instability or ambiguous configurations. This parameter prevents movement through the outer singularity. Value of 0.95 means positions beyond 95% of maximum theoretical reach are forbidden. description_bullets: - Only applies to morgan SCARA arm solution - Prevents movement through outer singularity point - 0.95 = 95% of maximum reach (default) - Higher values = more restrictive, limit maximum reach further - Lower values = allow closer approach to maximum extension - Protects against fully extended arm instability - Machine will refuse moves into forbidden zone related_settings: - morgan_undefined_min - arm1_length - arm2_length - morgan - applies only to related_pages: - morgan-scara - arm-solutions examples: - 'morgan_undefined_max 0.95 # Default safe limit' - 'morgan_undefined_max 0.97 # More conservative, reduced maximum reach' - name: real_scara type: bool default: false module: root context: Global setting (only for morgan SCARA) defined_in: modules/robot/arm_solutions/MorganSCARASolution.cpp:46 corresponding_v1: real_scara corresponding_v2: none (not present in v2 morgan implementation) description: For Morgan SCARA arm solution only. Enables real SCARA mode versus Morgan mode, which affects the kinematic calculations. The Morgan SCARA implementation supports two different SCARA variants with slightly different kinematic equations. The exact difference depends on the specific mechanical configuration (joint rotation directions, angle conventions). Setting this incorrectly will cause the arm to move in incorrect paths. description_bullets: - Only applies to morgan SCARA arm solution - false = Morgan mode (default) - true = Real SCARA mode - Affects kinematic calculation methods - Must match your specific SCARA mechanical configuration - Consult SCARA documentation or source code for details - Incorrect setting causes incorrect motion paths related_settings: - morgan - applies only to related_pages: - morgan-scara - arm-solutions examples: - 'real_scara false # Morgan mode (default)' - 'real_scara true # Real SCARA mode for different mechanical config' - name: laser_module_default_power type: number default: 0.8 module: root context: Global setting defined_in: modules/robot/Robot.cpp:209 corresponding_v1: laser_module_default_power corresponding_v2: laser.default_power description: Default S value for laser operations when no S parameter is specified in G-code. Represents laser power as a fraction from 0.0 (off) to 1.0 (full power), or can represent spindle RPM depending on configuration context. When G-code commands like M3 or M4 don't include an S parameter, this default value is used. Also serves as the initial power level before any S commands are received. description_bullets: - 'Fraction: 0.0 = off, 1.0 = full power' - Used when G-code omits S parameter - Also used as initial power at startup - For laser cutting/engraving operations - Can also represent spindle RPM in CNC context - Typical laser default is 0.8 (80% power) - Set lower for testing, higher for production typical_values: - value: 0.8 description: 80% power - value: 0.5 description: 50% power - value: 1 description: 100% power related_m_codes: - code: M5 description: Turn off laser/spindle related_settings: - Laser module settings related_pages: - laser - laser-cutter-guide examples: - 'laser_module_default_power 0.8 # 80% default power' - 'laser_module_default_power 0.5 # 50% default (safer for testing)' - 'laser_module_default_power 1.0 # Full power default' - name: soft_endstop.enable type: bool default: false module: root context: Global setting defined_in: modules/robot/Robot.cpp:287 corresponding_v1: soft_endstop.enable corresponding_v2: none (not documented in v2) description: Enable software endstops that prevent moves beyond configured minimum and maximum boundaries. When enabled, firmware checks every move against the soft_endstop min/max values and refuses moves that would exceed those limits. Provides protection against crashes and lost position without requiring physical limit switches on all axes. Soft endstops only work after the machine has been homed to establish position reference. description_bullets: - false = disabled (default) - true = enforce soft limits - Only active after homing establishes known position - Prevents motion beyond defined workspace boundaries - Useful for machines without physical limit switches - Can prevent crashes during manual jogging or testing - Complements but doesn't replace physical endstops related_settings: - soft_endstop.* - soft_endstop.halt - All other settings related_pages: - endstops - motion-control examples: - 'soft_endstop.enable false # Disabled (default)' - 'soft_endstop.enable true # Enable soft limits' - name: soft_endstop.halt type: bool default: true module: root context: Global setting defined_in: modules/robot/Robot.cpp:288 corresponding_v1: soft_endstop.halt corresponding_v2: none (not documented in v2) description: Controls machine behavior when soft endstop limit is triggered. When true (default), the machine enters HALT state when attempting to move beyond soft limits, requiring user intervention (reset). When false, the move is skipped/truncated but the machine continues operation. Only has effect when soft_endstop.enable is true. HALT mode is safer as it prevents continued operation in an error state. description_bullets: - true = HALT machine on soft limit violation (default, safer) - false = skip move but continue operation - Only matters when soft_endstop.enable is true - true provides maximum safety - false allows continued operation but may mask problems - HALT requires reset (M999) to resume related_settings: - soft_endstop.enable related_pages: - endstops - motion-control - stopping-smoothie examples: - 'soft_endstop.halt true # HALT on violation (recommended)' - 'soft_endstop.halt false # Skip move but continue' - name: soft_endstop.xmin type: number default: null units: mm module: root context: Global setting defined_in: modules/robot/Robot.cpp:290 corresponding_v1: soft_endstop.xmin corresponding_v2: none (not documented in v2) description: Minimum allowed X position for soft endstop enforcement. When set to a valid number, prevents X-axis moves below this value. When set to NAN (not-a-number, the default), this limit is disabled. Only enforced when soft_endstop.enable is true and machine has been homed. Typically set to 0 or slightly negative to account for homing position. description_bullets: - NAN = limit disabled (default) - Set to number to enable minimum X limit - Only enforced after homing - Typically 0 or slightly negative - Prevents crashes into negative X mechanical limits - Must be less than soft_endstop.xmax if both are set related_settings: - soft_endstop.xmax - soft_endstop.enable related_pages: - endstops - motion-control examples: - 'soft_endstop.xmin 0 # Prevent negative X movement' - 'soft_endstop.xmin -5 # Allow 5mm negative for homing offset' - '# Omit or set to NAN to disable' - name: soft_endstop.ymin type: number default: null units: mm module: root context: Global setting defined_in: modules/robot/Robot.cpp:291 corresponding_v1: soft_endstop.ymin corresponding_v2: none (not documented in v2) description: Minimum allowed Y position for soft endstop enforcement. When set to a valid number, prevents Y-axis moves below this value. When set to NAN (not-a-number, the default), this limit is disabled. Only enforced when soft_endstop.enable is true and machine has been homed. Typically set to 0 or slightly negative to account for homing position. description_bullets: - NAN = limit disabled (default) - Set to number to enable minimum Y limit - Only enforced after homing - Typically 0 or slightly negative - Prevents crashes into negative Y mechanical limits related_settings: - soft_endstop.ymax - soft_endstop.enable related_pages: - endstops - motion-control examples: - 'soft_endstop.ymin 0 # Prevent negative Y movement' - 'soft_endstop.ymin -5 # Allow 5mm negative for homing offset' - name: soft_endstop.zmin type: number default: null units: mm module: root context: Global setting defined_in: modules/robot/Robot.cpp:292 corresponding_v1: soft_endstop.zmin corresponding_v2: none (not documented in v2) description: Minimum allowed Z position for soft endstop enforcement. When set to a valid number, prevents Z-axis moves below this value. When set to NAN (not-a-number, the default), this limit is disabled. Only enforced when soft_endstop.enable is true and machine has been homed. Critical for protecting work surfaces, beds, and tool tips from crashing into the bed or table. description_bullets: - NAN = limit disabled (default) - Set to number to enable minimum Z limit - Only enforced after homing - Typically 0 or slightly negative - CRITICAL for preventing bed crashes in 3D printers - Prevents tool crashes in CNC related_settings: - soft_endstop.zmax - soft_endstop.enable related_pages: - endstops - motion-control - 3d-printer-guide examples: - 'soft_endstop.zmin 0 # Prevent negative Z movement (bed crash protection)' - 'soft_endstop.zmin -0.1 # Allow slight negative for probe offset' - name: soft_endstop.xmax type: number default: null units: mm module: root context: Global setting defined_in: modules/robot/Robot.cpp:293 corresponding_v1: soft_endstop.xmax corresponding_v2: none (not documented in v2) description: Maximum allowed X position for soft endstop enforcement. When set to a valid number, prevents X-axis moves above this value. When set to NAN (not-a-number, the default), this limit is disabled. Only enforced when soft_endstop.enable is true and machine has been homed. Typically set to the maximum build/work area dimension in X-axis. description_bullets: - NAN = limit disabled (default) - Set to number to enable maximum X limit - Only enforced after homing - Should match physical workspace size - Prevents crashes into positive X mechanical limits - Must be greater than soft_endstop.xmin if both are set related_settings: - soft_endstop.xmin - soft_endstop.enable related_pages: - endstops - motion-control examples: - 'soft_endstop.xmax 200 # 200mm maximum X travel' - 'soft_endstop.xmax 300 # 300mm build area in X' - name: soft_endstop.ymax type: number default: null units: mm module: root context: Global setting defined_in: modules/robot/Robot.cpp:294 corresponding_v1: soft_endstop.ymax corresponding_v2: none (not documented in v2) description: Maximum allowed Y position for soft endstop enforcement. When set to a valid number, prevents Y-axis moves above this value. When set to NAN (not-a-number, the default), this limit is disabled. Only enforced when soft_endstop.enable is true and machine has been homed. Typically set to the maximum build/work area dimension in Y-axis. description_bullets: - NAN = limit disabled (default) - Set to number to enable maximum Y limit - Only enforced after homing - Should match physical workspace size - Prevents crashes into positive Y mechanical limits related_settings: - soft_endstop.ymin - soft_endstop.enable related_pages: - endstops - motion-control examples: - 'soft_endstop.ymax 200 # 200mm maximum Y travel' - 'soft_endstop.ymax 300 # 300mm build area in Y' - name: soft_endstop.zmax type: number default: null units: mm module: root context: Global setting defined_in: modules/robot/Robot.cpp:295 corresponding_v1: soft_endstop.zmax corresponding_v2: none (not documented in v2) description: Maximum allowed Z position for soft endstop enforcement. When set to a valid number, prevents Z-axis moves above this value. When set to NAN (not-a-number, the default), this limit is disabled. Only enforced when soft_endstop.enable is true and machine has been homed. Important for preventing Z-axis crashes into frame top, gantry, or other mechanical limits. description_bullets: - NAN = limit disabled (default) - Set to number to enable maximum Z limit - Only enforced after homing - Should match maximum safe Z height - Prevents crashes into Z mechanical limits - Important for printers with limited Z travel related_settings: - soft_endstop.zmin - soft_endstop.enable related_pages: - endstops - motion-control examples: - 'soft_endstop.zmax 200 # 200mm maximum Z height' - 'soft_endstop.zmax 400 # 400mm Z travel for tall printer' - name: Player Module description: File playback and control settings setting_count: 0 settings: [] - name: Extruder Module description: Extrusion and retraction settings setting_count: 17 settings: - name: extruder.hotend.enable type: bool default: false module: extruder context: Module instance setting (can have multiple extruders) defined_in: modules/tools/extruder/ExtruderMaker.cpp:39,64 required: false corresponding_v1: extruder.hotend.enable corresponding_v2: extruder.hotend.enable description: Whether to activate this extruder instance. All configuration is ignored if false. Each enabled extruder creates a separate extruder module instance that can be independently controlled. description_bullets: - Multiple extruders can be enabled by creating multiple instances with different names - Each enabled extruder must have valid step_pin, dir_pin, and en_pin configured - Tool selection is done via T0, T1, T2, etc. commands related_settings: - extruder.step_pin - extruder.dir_pin - extruder.en_pin - temperature_control.enable related_pages: - extruder - multiple-extruders - extruder-guide examples: - 'extruder.hotend.enable true # Enable primary extruder (T0)' - 'extruder.hotend2.enable true # Enable second extruder (T1) for dual extrusion' - 'extruder.e3d.enable false # Disable this extruder instance' - name: extruder.hotend.steps_per_mm type: number default: 1 units: steps per mm of filament module: extruder context: Module instance setting defined_in: modules/tools/extruder/Extruder.cpp:96 corresponding_v1: extruder.hotend.steps_per_mm corresponding_v2: extruder.hotend.steps_per_mm description: 'Number of stepper motor steps required to move one millimeter of filament through the extruder. This critical calibration value depends on your stepper motor step angle, microstepping configuration, and extruder gear ratio. The formula is: steps_per_mm = (motor_steps_per_rev × microstepping) / (gear_ratio × pinch_wheel_diameter × π). For a typical setup with 1.8° stepper (200 steps/rev), 1/16 microstepping, 3:1 gearing, and 10mm effective diameter: steps_per_mm = (200 × 16) / (3 × 10 × 3.14159) = 140.' description_bullets: - This is the most critical calibration value for accurate extrusion - Incorrect value causes under-extrusion (too low) or over-extrusion (too high) - Should be calibrated by measuring actual filament movement - Can be temporarily adjusted with M221 (flow rate percentage) typical_values: - value: 140 description: common direct drive - value: 100 description: geared 3:1 - value: 200 description: high-resolution stepper - value: 420 description: Bondtech BMG related_m_codes: - code: M500 description: Save current value to config-override - code: M503 description: Display current value related_settings: - extruder.acceleration - extruder.max_speed - extruder.filament_diameter related_pages: - extruder - extruder-guide - multiple-extruders examples: - 'extruder.hotend.steps_per_mm 140 # Common direct drive with 1.8° stepper' - 'extruder.hotend.steps_per_mm 143.5 # Fine-tuned after calibration' - 'extruder.hotend2.steps_per_mm 420 # Bondtech BMG dual drive extruder' - name: extruder.hotend.filament_diameter type: number default: 0 units: mm module: extruder context: Module instance setting defined_in: modules/tools/extruder/Extruder.cpp:103 minimum_value: '`0.01` (checked in Extruder.cpp:111,263,276 - values below this disable volumetric mode)' corresponding_v1: extruder.hotend.filament_diameter corresponding_v2: extruder.hotend.filament_diameter description: 'Filament diameter in millimeters for volumetric extrusion mode. When set to a value greater than 0.01mm, enables volumetric extrusion where E values in G-code represent mm³ of filament volume instead of mm of filament length. The volumetric multiplier is calculated as: 1 / (π × (diameter/2)²). Set to 0 to disable volumetric extrusion and use linear extrusion mode (E values = mm of filament).' description_bullets: - Most slicers output linear E values (mm of filament), so 0 is the most common setting - Volumetric mode is useful when switching between different filament diameters - Changing this value at runtime with M200 requires careful milestone adjustment - The 0.01mm minimum prevents division by zero and nonsensical values typical_values: - value: 1.75 description: most common - value: 2.85 description: older printers - value: 0 description: disable volumetric mode related_m_codes: - code: M200 description: Display current setting - code: M500 description: Save to config-override related_settings: - extruder.steps_per_mm - extruder.max_speed related_pages: - extruder - extruder-guide examples: - 'extruder.hotend.filament_diameter 1.75 # Enable volumetric mode for 1.75mm filament' - 'extruder.hotend.filament_diameter 2.85 # Enable volumetric mode for 2.85mm filament' - 'extruder.hotend.filament_diameter 0 # Disable volumetric mode (most common)' - name: extruder.hotend.acceleration type: number default: 1000 units: mm/s² module: extruder context: Module instance setting defined_in: modules/tools/extruder/Extruder.cpp:97 corresponding_v1: extruder.hotend.acceleration corresponding_v2: actuator.delta.acceleration description: Maximum acceleration for the extruder stepper motor in mm/s². Controls how quickly the extruder can change speed during extrusion moves. Higher values allow faster speed changes and sharper transitions but may cause skipped steps, grinding, or inconsistent extrusion. Lower values provide smoother extrusion and better flow consistency but slower response to speed changes. description_bullets: - This is independent of the robot's XYZ acceleration - Flexible filaments need lower values (300-600 mm/s²) to prevent compression - Direct drive extruders can typically handle higher values than Bowden - Too high causes grinding or skipped steps during rapid retractions typical_values: - value: 500 description: conservative for flexible filament - value: 1000 description: default, general purpose - value: 2000 description: fast direct drive related_m_codes: - code: M500 description: Save to config-override - code: M503 description: Display current value related_settings: - extruder.max_speed - extruder.retract_feedrate - motion_control.default_acceleration related_pages: - extruder - motion-control - extruder-guide examples: - 'extruder.hotend.acceleration 500 # Conservative for flexible filament' - 'extruder.hotend.acceleration 1000 # Default, general purpose' - 'extruder.hotend2.acceleration 2000 # Fast direct drive extruder' - name: extruder.hotend.max_speed type: number default: 1000 units: mm/s module: extruder context: Module instance setting defined_in: modules/tools/extruder/Extruder.cpp:119 corresponding_v1: extruder.hotend.max_speed corresponding_v2: extruder.hotend.max_speed description: Maximum allowable speed for the extruder stepper motor in mm/s. This is the absolute speed limit for filament movement. The firmware will never move the extruder faster than this speed, regardless of G-code commands or requested feedrates. This limit protects against stepper motor stalling, gear slipping, filament grinding, and excessive extruder torque. description_bullets: - This is a hard limit enforced by the firmware - Should be set conservatively below the point where skipping occurs - Bowden extruders typically need higher values for fast retractions - Direct drive extruders can use lower values (40-60 mm/s) - Too high causes skipped steps and grinding - Too low limits maximum print speed and retraction performance typical_values: - value: 50 description: standard direct drive - value: 80 description: fast direct drive - value: 120 description: Bowden with good path related_m_codes: - code: M203 description: Display current settings for all axes - code: M500 description: Save to config-override related_settings: - extruder.acceleration - extruder.retract_feedrate - extruder.steps_per_mm related_pages: - extruder - extruder-guide - stepper-motors examples: - 'extruder.hotend.max_speed 50 # Standard direct drive extruder' - 'extruder.hotend.max_speed 80 # Fast direct drive extruder' - 'extruder.hotend2.max_speed 120 # Bowden extruder for fast retractions' - name: extruder.hotend.step_pin type: pin default: nc module: extruder context: Module instance setting defined_in: modules/tools/extruder/Extruder.cpp:92 required: false corresponding_v1: extruder.hotend.step_pin corresponding_v2: extruder.hotend.step_pin description: Pin for the extruder stepper motor driver's step signal. Each step pulse moves the motor one microstep according to the driver's microstepping configuration. Must be a valid digital output pin that connects to the STEP input of your stepper driver. description_bullets: - 'CRITICAL: Incorrect pin assignment can cause motors not to move or move the wrong axis' - Pin must be a hardware PWM-capable pin for best performance - Must not conflict with other module pin assignments - Consult your board's pinout diagram for correct pin assignments related_settings: - extruder.dir_pin - extruder.en_pin - extruder.steps_per_mm related_pages: - extruder - pin-configuration - pinout - smoothieboard examples: - 'extruder.hotend.step_pin 2.3 # First extruder step pin' - 'extruder.hotend2.step_pin 2.8 # Second extruder step pin' - 'extruder.spare.step_pin nc # Disabled/not connected' - name: extruder.hotend.dir_pin type: pin default: nc module: extruder context: Module instance setting defined_in: modules/tools/extruder/Extruder.cpp:93 required: false corresponding_v1: extruder.hotend.dir_pin corresponding_v2: extruder.hotend.dir_pin description: Pin for the extruder stepper motor driver's direction signal. Controls whether the motor rotates forward (extrude filament) or backward (retract filament). Append `!` to invert the direction if the motor runs backward during extrusion. description_bullets: - Determines which way the motor rotates (clockwise vs counter-clockwise) - If motor runs backward during extrusion, add `!` to invert - Must not conflict with other module pin assignments - Direction can be tested with small manual extrusion commands related_settings: - extruder.step_pin - extruder.en_pin related_pages: - extruder - pin-configuration - pinout examples: - 'extruder.hotend.dir_pin 0.22 # Normal direction' - 'extruder.hotend.dir_pin 0.22! # Inverted direction (motor was backward)' - 'extruder.hotend2.dir_pin 2.13 # Second extruder direction pin' - name: extruder.hotend.en_pin type: pin default: nc module: extruder context: Module instance setting defined_in: modules/tools/extruder/Extruder.cpp:94 corresponding_v1: extruder.hotend.en_pin corresponding_v2: extruder.hotend.en_pin description: Pin for the extruder stepper motor driver's enable signal. When active, the motor driver is powered and holds position with full torque. When inactive, the motor is unpowered and can be turned freely by hand. Append `!` to invert if your driver enables on LOW signal instead of HIGH. description_bullets: - Most drivers enable on LOW, so `!` is commonly needed - When disabled, motor has no holding torque and can be turned manually - Firmware automatically enables/disables motor as needed - Some drivers don't need enable pin (always enabled) related_settings: - extruder.step_pin - extruder.dir_pin related_pages: - extruder - pin-configuration - pinout - stepper-motors examples: - 'extruder.hotend.en_pin 0.21 # Enable on HIGH signal' - 'extruder.hotend.en_pin 0.21! # Enable on LOW signal (most common)' - 'extruder.hotend2.en_pin 4.29 # Second extruder enable pin' - name: extruder.hotend.x_offset type: number default: 0 units: mm module: extruder context: Module instance setting defined_in: modules/tools/extruder/Extruder.cpp:99 corresponding_v1: extruder.hotend.x_offset corresponding_v2: extruder.hotend.x_offset description: X-axis offset of this extruder's nozzle from the primary extruder (T0) in millimeters. Used only in multi-extruder setups to compensate for physical nozzle spacing. When switching tools with T commands, the firmware automatically applies this offset to maintain correct positioning of printed features. Positive values indicate the nozzle is to the right of the primary extruder. Negative values indicate the nozzle is to the left. description_bullets: - Only relevant for multi-extruder configurations - T0 (primary extruder) should always have offset 0,0,0 - Measure from T0 nozzle tip to this extruder's nozzle tip - Incorrect offset causes misalignment between extruders - Should be calibrated by printing alignment test patterns typical_values: - value: 0 description: primary extruder - value: 25 description: typical dual extruder spacing - value: -18 description: left of primary related_settings: - extruder.y_offset - extruder.z_offset - extruder.enable related_pages: - extruder - multiple-extruders - extruder-guide examples: - 'extruder.hotend.x_offset 0 # Primary extruder (T0) at origin' - 'extruder.hotend2.x_offset 25 # Second extruder 25mm to the right' - 'extruder.hotend3.x_offset -18 # Third extruder 18mm to the left' - name: extruder.hotend.y_offset type: number default: 0 units: mm module: extruder context: Module instance setting defined_in: modules/tools/extruder/Extruder.cpp:100 corresponding_v1: extruder.hotend.y_offset corresponding_v2: extruder.hotend.y_offset description: Y-axis offset of this extruder's nozzle from the primary extruder (T0) in millimeters. Used only in multi-extruder setups to compensate for physical nozzle spacing when nozzles are not aligned along the X-axis only. Positive values indicate the nozzle is behind the primary extruder (toward +Y). Negative values indicate the nozzle is in front of the primary extruder (toward -Y). description_bullets: - Less common than x_offset since most multi-extruder systems align on X-axis - T0 (primary extruder) should always have offset 0,0,0 - Measure from T0 nozzle tip to this extruder's nozzle tip - Should be calibrated with alignment test patterns typical_values: - value: 0 description: most common - value: 5 description: behind primary - value: -5 description: in front of primary related_settings: - extruder.x_offset - extruder.z_offset - extruder.enable related_pages: - extruder - multiple-extruders examples: - 'extruder.hotend.y_offset 0 # Primary extruder (T0)' - 'extruder.hotend2.y_offset 0 # Second extruder aligned on X-axis' - 'extruder.hotend3.y_offset -5 # Third extruder 5mm in front' - name: extruder.hotend.z_offset type: number default: 0 units: mm module: extruder context: Module instance setting defined_in: modules/tools/extruder/Extruder.cpp:101 corresponding_v1: extruder.hotend.z_offset corresponding_v2: extruder.hotend.z_offset description: Z-axis offset of this extruder's nozzle from the primary extruder (T0) in millimeters. Used only in multi-extruder setups to compensate for different nozzle heights when nozzles are not at exactly the same Z level. Positive values indicate the nozzle is higher than the primary extruder. Negative values indicate the nozzle is lower. This affects print quality if extruders have different nozzle lengths. Calibrate carefully to ensure consistent layer heights when switching tools. description_bullets: - 'IMPORTANT: This affects print quality significantly' - Incorrect offset causes first layer problems or crashes into bed - Should be calibrated by printing test patterns with each extruder - Even small differences (0.05mm) can affect print quality - T0 (primary extruder) should always have offset 0,0,0 typical_values: - value: 0 description: most common - value: 0.15 description: slightly higher - value: -0.05 description: slightly lower related_settings: - extruder.x_offset - extruder.y_offset - zprobe.probe_height related_pages: - extruder - multiple-extruders - extruder-guide examples: - 'extruder.hotend.z_offset 0 # Primary extruder (T0) reference height' - 'extruder.hotend2.z_offset 0.15 # Second extruder nozzle is 0.15mm higher' - 'extruder.hotend3.z_offset -0.05 # Third extruder nozzle is 0.05mm lower' - name: extruder.hotend.retract_length type: number default: 3 units: mm module: extruder context: Module instance setting defined_in: modules/tools/extruder/Extruder.cpp:104 corresponding_v1: extruder.hotend.retract_length corresponding_v2: extruder.hotend.retract_length description: Amount of filament to retract during firmware retraction in millimeters. Used by G10 (retract) and G11 (unretract) commands. Retraction pulls filament back to reduce nozzle pressure and prevent oozing/stringing during non-printing travel moves. Bowden extruders need 4-8mm due to longer filament path and tube compression. Direct drive extruders need only 0.5-2mm due to short path between drive gear and nozzle. Too little causes stringing and oozing. Too much causes grinding, air gaps after unretract, and possible clogging. description_bullets: - One of the most important tuning parameters for print quality - Bowden systems need significantly more than direct drive - Start conservative and increase if stringing occurs - Too much retraction can cause jams and grinding - Different materials may need different values typical_values: - value: 0.5 description: direct drive, short - value: 1.5 description: direct drive, typical - value: 4 description: Bowden, short - value: 6 description: Bowden, typical - value: 8 description: Bowden, long tube related_m_codes: - code: M500 description: Save to config-override related_settings: - extruder.retract_feedrate - extruder.retract_recover_length - extruder.retract_zlift_length related_pages: - extruder - extruder-guide - g10 - g11 examples: - 'extruder.hotend.retract_length 1.5 # Direct drive extruder' - 'extruder.hotend.retract_length 6 # Bowden extruder with medium tube' - 'extruder.hotend2.retract_length 4.5 # Bowden with shorter tube' - name: extruder.hotend.retract_feedrate type: number default: 45 units: mm/s module: extruder context: Module instance setting defined_in: modules/tools/extruder/Extruder.cpp:105 corresponding_v1: extruder.hotend.retract_feedrate corresponding_v2: extruder.hotend.retract_feedrate description: Speed at which filament is retracted during firmware retraction in mm/s. Used by G10 command. This is stored and used internally in mm/s, but the M207 F parameter expects mm/min for compatibility with other firmware (the firmware automatically converts by multiplying by 60). Faster retraction reduces stringing by quickly reducing nozzle pressure, but may cause grinding, skipped steps, or filament deformation. Typical values range from 20-60 mm/s (1200-3600 mm/min). description_bullets: - 'NOTE: Config value is in mm/s, but M207 F parameter is in mm/min' - Faster is generally better for reducing stringing - Limited by extruder.max_speed setting - Too fast causes grinding or skipped steps - Flexible filaments need slower speeds (15-25 mm/s) typical_values: - value: 20 description: conservative, flexible filament - value: 45 description: default, general purpose - value: 60 description: fast retraction related_m_codes: - code: M500 description: Save to config-override related_settings: - extruder.retract_length - extruder.retract_recover_feedrate - extruder.max_speed related_pages: - extruder - g10 - extruder-guide examples: - 'extruder.hotend.retract_feedrate 45 # 45 mm/s = 2700 mm/min (default)' - 'extruder.hotend.retract_feedrate 30 # 30 mm/s = 1800 mm/min (conservative)' - 'extruder.hotend2.retract_feedrate 60 # 60 mm/s = 3600 mm/min (fast)' - name: extruder.hotend.retract_recover_length type: number default: 0 units: mm module: extruder context: Module instance setting defined_in: modules/tools/extruder/Extruder.cpp:106 corresponding_v1: extruder.hotend.retract_recover_length corresponding_v2: extruder.hotend.retract_recover_length description: Additional length of filament to extrude when recovering (unretract) beyond the retracted amount. Used by G11 command. Total recover distance = retract_length + retract_recover_length. This compensates for filament that may ooze during travel moves or pressure lost in the nozzle during the retraction pause. Small positive values (0.1-0.3mm) can prevent under-extrusion immediately after retract by slightly over-recovering. Negative values cause under-recovery if too much pressure builds up during retraction. description_bullets: - Most users leave this at 0 (recover exactly what was retracted) - Positive values add extra filament on unretract (over-recovery) - Negative values reduce unretract amount (under-recovery) - Useful for fine-tuning to eliminate blobs or gaps after travel - Start at 0 and adjust only if you see consistent problems typical_values: - value: 0 description: most common, recover exactly what was retracted - value: 0.2 description: slight over-recovery - value: -0.1 description: slight under-recovery related_m_codes: - code: M500 description: Save to config-override related_settings: - extruder.retract_length - extruder.retract_recover_feedrate related_pages: - extruder - g11 - extruder-guide examples: - 'extruder.hotend.retract_recover_length 0 # Most common, exact recovery' - 'extruder.hotend.retract_recover_length 0.2 # Slight over-recovery to prevent gaps' - 'extruder.hotend2.retract_recover_length -0.1 # Slight under-recovery to prevent blobs' - name: extruder.hotend.retract_recover_feedrate type: number default: 8 units: mm/s module: extruder context: Module instance setting defined_in: modules/tools/extruder/Extruder.cpp:107 corresponding_v1: extruder.hotend.retract_recover_feedrate corresponding_v2: extruder.hotend.retract_recover_feedrate description: Speed at which filament is recovered (unretracted) during firmware unretraction in mm/s. Used by G11 command. This is stored and used internally in mm/s, but the M208 F parameter expects mm/min for compatibility with other firmware. This should typically be slower than retract_feedrate to avoid pressure spikes and blobs at the start of extrusion after travel. Typical values range from 8-40 mm/s (480-2400 mm/min), usually 50-80% of retract_feedrate. description_bullets: - 'NOTE: Config value is in mm/s, but M208 F parameter is in mm/min' - Should usually be slower than retract_feedrate - Too fast causes blobs at the start of extrusion after travel - Too slow increases print time and may cause under-extrusion - Default of 8 mm/s is quite conservative typical_values: - value: 8 description: default, conservative - value: 25 description: faster recovery - value: 40 description: very fast related_m_codes: - code: M500 description: Save to config-override related_settings: - extruder.retract_recover_length - extruder.retract_feedrate related_pages: - extruder - g11 - extruder-guide examples: - 'extruder.hotend.retract_recover_feedrate 8 # 8 mm/s = 480 mm/min (default, conservative)' - 'extruder.hotend.retract_recover_feedrate 25 # 25 mm/s = 1500 mm/min (faster)' - 'extruder.hotend2.retract_recover_feedrate 40 # 40 mm/s = 2400 mm/min (very fast)' - name: extruder.hotend.retract_zlift_length type: number default: 0 units: mm module: extruder context: Module instance setting defined_in: modules/tools/extruder/Extruder.cpp:108 corresponding_v1: extruder.hotend.retract_zlift_length corresponding_v2: extruder.hotend.retract_zlift_length description: 'Amount to lift the Z-axis during retraction in millimeters (Z-hop or Z-lift feature). When G10 is executed, the nozzle lifts by this amount after retracting filament. When G11 is executed, the nozzle lowers back before unretraction. Set to 0 to disable Z-lift. Z-lift prevents nozzle dragging across already-printed surfaces, scars and marks during travel moves, and collisions with tall features. NOTE: Z-lift is automatically cancelled if an absolute Z move (G0/G1 with Z parameter) occurs between G10 and G11, preventing conflicts with explicit Z positioning.' description_bullets: - Adds travel time but improves surface quality on travel moves - Useful for preventing nozzle from catching on printed parts - Essential for prints with many tall thin features - 0.2mm is typical for most prints - Higher values needed for very tall or dense prints - Disabled (0) is most common for simple prints typical_values: - value: 0 description: disabled, most common - value: 0.2 description: small lift - value: 0.5 description: medium lift - value: 2 description: tall features related_m_codes: - code: M500 description: Save to config-override related_settings: - extruder.retract_zlift_feedrate - extruder.retract_length - motion_control.z_axis_max_speed related_pages: - extruder - g10 - g11 - extruder-guide examples: - 'extruder.hotend.retract_zlift_length 0 # Z-hop disabled (most common)' - 'extruder.hotend.retract_zlift_length 0.2 # Small Z-hop for cleaner travel' - 'extruder.hotend2.retract_zlift_length 0.5 # Larger Z-hop for tall features' - name: extruder.hotend.retract_zlift_feedrate type: number default: 6000 units: 'mm/min (NOTE: This is the ONLY extruder setting using mm/min instead of mm/s)' module: extruder context: Module instance setting defined_in: modules/tools/extruder/Extruder.cpp:109 corresponding_v1: extruder.hotend.retract_zlift_feedrate corresponding_v2: extruder.hotend.retract_zlift_feedrate description: 'Speed for Z-axis movement during Z-lift operations in mm/min. Used for both lifting (during G10) and lowering (during G11) moves when retract_zlift_length is greater than 0. CRITICAL: This is the ONLY extruder setting that uses mm/min instead of mm/s. The default value of 6000 mm/min equals 100 mm/s (the firmware divides by 60 at line 109: "by_default(100 * 60)->as_number() / 60.0F"). This should typically match your Z-axis max_speed to avoid unnecessary slowdown during Z-hop moves.' description_bullets: - 'CRITICAL: This is the ONLY extruder setting using mm/min instead of mm/s' - Config file value is in mm/min (divide by 60 to get mm/s) - Default 6000 mm/min = 100 mm/s (quite fast) - Should typically match motion_control.z_axis_max_speed - Too fast may cause layer shifts on delta printers or skipped Z steps - Too slow increases print time significantly on prints with many retractions - Only takes effect if retract_zlift_length > 0 typical_values: - value: 6000 description: 100 mm/s, default - value: 9000 description: 150 mm/s, fast printer - value: 4800 description: 80 mm/s, conservative related_m_codes: - code: M500 description: Save current value to config-override - code: M501 description: Reload from config-override related_settings: - extruder.retract_zlift_length - motion_control.z_axis_max_speed - extruder.retract_feedrate related_pages: - extruder - g10 - g11 - motion-control examples: - 'extruder.hotend.retract_zlift_feedrate 6000 # 100 mm/s (default, general purpose)' - 'extruder.hotend.retract_zlift_feedrate 9000 # 150 mm/s (fast delta printer)' - 'extruder.hotend2.retract_zlift_feedrate 4800 # 80 mm/s (second extruder, more conservative)' - name: Laser Module description: Laser control and safety settings setting_count: 10 settings: - name: laser_module_enable type: bool default: false module: laser context: Global module setting defined_in: src/modules/tools/laser/Laser.cpp:53 corresponding_v1: laser_module_enable corresponding_v2: laser.enable description: Controls whether the laser module is activated in Smoothieware. When set to false, the module is completely unloaded to free system resources. When enabled, the laser module supports both laser diodes and CO2 laser tubes for cutting and engraving applications. The module must be enabled before any other laser settings take effect. description_bullets: - If disabled, all other laser configuration settings are ignored. - The module is automatically unloaded from memory when disabled to conserve RAM. - Must be enabled for laser cutting, engraving, or any laser-related operations. related_pages: - laser - laser-cutter-guide - laser-guides - configuration-options examples: - 'laser_module_enable true # Enable laser module for laser cutting/engraving' - 'laser_module_enable false # Disable laser module (default, saves memory)' - name: laser_module_pin type: pin default: nc module: laser context: Global module setting defined_in: src/modules/tools/laser/Laser.cpp:61 deprecated: false corresponding_v1: laser_module_pin corresponding_v2: laser.pwm_pin description: Legacy parameter that specifies the pin controlling the laser through PWM (Pulse Width Modulation). This setting has been superseded by `laser_module_pwm_pin` for improved clarity. If this pin is not connected, the system will check `laser_module_pwm_pin` instead. Only specific pins on the Smoothieboard support hardware PWM required for laser control. description_bullets: - 'CRITICAL: Only hardware PWM pins are supported. Using non-PWM pins will disable the laser module with error message.' - 'If invalid pin is specified, firmware prints error: "Error: Laser cannot use P{port}.{pin} (P2.0 - P2.5, P1.18, P1.20, P1.21, P1.23, P1.24, P1.26, P3.25, P3.26 only). Laser module disabled."' - This parameter is checked first, then `laser_module_pwm_pin` is checked if this is not connected. - Deprecated in favor of the more descriptive `laser_module_pwm_pin` setting. related_settings: - laser_module_pwm_pin - laser_module_ttl_pin related_pages: - laser - pinout - pin-configuration - pwm-capable examples: - 'laser_module_pin 2.5 # Use pin 2.5 for PWM laser control (deprecated)' - 'laser_module_pin !2.5 # Inverted PWM on pin 2.5 (for active-low drivers)' - 'laser_module_pin nc # Not connected, will check laser_module_pwm_pin instead' - name: laser_module_pwm_pin type: pin default: nc module: laser context: Global module setting defined_in: src/modules/tools/laser/Laser.cpp:65 required: false corresponding_v1: laser_module_pwm_pin corresponding_v2: laser.pwm_pin description: The preferred and more descriptive parameter for specifying the PWM control pin for the laser. This pin controls laser power through pulse width modulation, where the duty cycle determines the laser output power from 0% (off) to 100% (full power). Supports inverted logic for laser drivers that require active-low control signals. Only pins with hardware PWM capability can be used. description_bullets: - This is the recommended parameter instead of the legacy `laser_module_pin` setting. - PWM duty cycle directly controls laser power output percentage. - Pin validation occurs at module load time during firmware boot. - 'CRITICAL: Invalid pin selection will disable the laser module with detailed error message showing which pins are valid.' - Inverting pin logic with `!` prefix is useful for some laser driver circuits that are active-low. - The pin's PWM period is configured via `laser_module_pwm_period` setting. related_settings: - laser_module_pin - laser_module_pwm_period - laser_module_ttl_pin related_pages: - laser - pinout - pin-configuration - pwm-capable examples: - 'laser_module_pwm_pin 2.5 # Standard PWM control on pin 2.5' - 'laser_module_pwm_pin !2.5 # Inverted PWM for active-low laser drivers' - 'laser_module_pwm_pin 2.4 # Alternative PWM pin for different board layout' - name: laser_module_ttl_pin type: pin default: nc module: laser context: Global module setting defined_in: src/modules/tools/laser/Laser.cpp:84 corresponding_v1: laser_module_ttl_pin corresponding_v2: laser.ttl_pin description: Specifies an optional TTL (Transistor-Transistor Logic) control pin that provides a simple on/off signal synchronized with laser firing. This pin switches on when the laser fires and off when the laser stops, independent of the PWM power level. This is useful for controlling external laser power supplies, air assist systems, fume extraction fans, or safety interlocks that need a binary on/off signal separate from the proportional PWM power control. description_bullets: - This is a digital on/off signal, NOT PWM - it is either high or low. - Pin state changes only when laser transitions between firing and not firing. - Commonly used to enable/disable air assist compressors or extraction fans. - Can control laser power supply enable pins for additional safety. - Useful for safety interlocks that monitor when laser is active. - Pin is set low (0) when laser is off, high (1) when laser is on (or inverted if `!` prefix used). related_settings: - laser_module_pwm_pin related_pages: - laser - laser-cutter-guide - pin-configuration examples: - 'laser_module_ttl_pin 1.30 # TTL signal on pin 1.30 for air assist control' - 'laser_module_ttl_pin !1.30 # Inverted TTL (active-low) for some control circuits' - 'laser_module_ttl_pin 2.7 # Alternative pin for power supply enable signal' - name: laser_module_pwm_period type: number default: 20 units: microseconds module: laser context: Global module setting defined_in: src/modules/tools/laser/Laser.cpp:96 corresponding_v1: laser_module_pwm_period corresponding_v2: pwm1.frequency description: Sets the PWM period (and thus frequency) for laser control in microseconds. The PWM frequency equals 1,000,000 divided by this period value. This frequency affects how smoothly the laser power can be controlled and must be appropriate for your specific laser driver electronics. The system uses this period to limit the maximum rate of power adjustments to never faster than the PWM frequency or 1kHz, whichever is lower, preventing excessive update overhead. description_bullets: - 'PWM frequency calculation: frequency (Hz) = 1,000,000 / period (µs)' - Default period of 20 µs = 50,000 Hz (50 kHz) frequency - Lower period values = higher frequency = smoother power control - Higher period values = lower frequency = may cause visible pulsing - Some laser drivers require specific frequency ranges - consult driver specifications - Power update rate is automatically limited to minimum of PWM frequency or 1000 Hz - Too high frequency may exceed driver switching capabilities - Too low frequency may cause visible artifacts in raster engraving typical_values: - value: 20 description: 50 kHz, default for most diode lasers - value: 50 description: 20 kHz for some drivers - value: 100 description: 10 kHz for lower frequency - value: 10 description: 100 kHz for very high frequency related_settings: - laser_module_pwm_pin - laser_module_proportional_power related_pages: - laser - laser-cutter-guide examples: - 'laser_module_pwm_period 20 # 50 kHz (default, works for most diode lasers)' - 'laser_module_pwm_period 50 # 20 kHz (lower frequency for some drivers)' - 'laser_module_pwm_period 100 # 10 kHz (even lower frequency, may show pulsing)' - 'laser_module_pwm_period 10 # 100 kHz (very high frequency for fast switching drivers)' - name: laser_module_maximum_power type: number default: 1 module: laser context: Global module setting defined_in: src/modules/tools/laser/Laser.cpp:100 minimum_value: '`0.0` (enforced by confine() function at Laser.cpp:292)' maximum_value: '`1.0` (enforced by confine() function at Laser.cpp:292)' corresponding_v1: laser_module_maximum_power corresponding_v2: laser.maximum_power description: Sets the maximum PWM duty cycle that will be applied to the laser, acting as both a safety limit and calibration parameter. This value represents the highest power output the laser will achieve, even if G-code commands request 100% power. All S-values in G-code are scaled to this maximum. Setting this below 1.0 is useful for laser safety by preventing accidental full-power operation, calibrating the maximum power to match specific material requirements, or protecting lasers that shouldn't operate at their full rated power continuously. This creates a ceiling that cannot be exceeded during normal operation. description_bullets: - Acts as a safety ceiling for laser power - cannot be exceeded by G-code - All power commands are scaled to this maximum value - 'Example: Setting `0.8` means G-code S100% produces 80% actual laser power' - Useful for preventing damage to both materials and laser tube/diode - Allows safe operation below rated maximum to extend laser life - Can be adjusted to account for laser aging or degradation - Combined with minimum_power to define the usable power range - 'WARNING: Does not provide emergency shutoff - use kill switch for safety' typical_values: - value: 0.8 description: 80% max power, common safety limit - value: 0.6 description: 60% max power for lower power operations - value: 1 description: 100% max power, full range - value: 0.9 description: 90% max power for tube longevity related_settings: - laser_module_minimum_power - laser_module_maximum_s_value related_pages: - laser - laser-cutter-guide - laser-warning examples: - 'laser_module_maximum_power 1.0 # 100% power (full range, default)' - 'laser_module_maximum_power 0.8 # 80% max power (common safety limit)' - 'laser_module_maximum_power 0.6 # 60% max power (conservative for new users)' - 'laser_module_maximum_power 0.9 # 90% max power (extends CO2 tube life)' - name: laser_module_minimum_power type: number default: 0 module: laser context: Global module setting defined_in: src/modules/tools/laser/Laser.cpp:106 minimum_value: '`0.0` (enforced by confine() function at Laser.cpp:292)' maximum_value: '`1.0` (enforced by confine() function at Laser.cpp:292)' corresponding_v1: laser_module_minimum_power corresponding_v2: laser.minimum_power description: Sets the minimum PWM duty cycle (baseline power) for the laser during travel moves and as a floor for all laser operations. This is particularly useful for laser diodes that benefit from staying slightly active to prevent thermal cycling and maintain stable operation, or that require a minimum current to remain in their operating range. Also known as "tickle power" or "keepalive power" in some contexts. When proportional power is enabled, the laser uses this power level during G0 (rapid) travel moves. During cutting operations, the actual power is scaled between this minimum and the maximum power setting. description_bullets: - Previously configured via deprecated `laser_module_tickle_power` parameter - Keeps laser diodes thermally stable by preventing complete shutoff - Reduces thermal stress on laser diodes from constant on/off cycling - Some diodes require minimum current to maintain stable emission - Used as baseline during G0 rapid moves when proportional power enabled - Actual cutting power = (maximum_power - minimum_power) × S_value + minimum_power - Set to `0.0` for complete laser shutoff during travel (safer, more common) - 'WARNING: Non-zero values mean laser is always slightly active when module enabled' - Higher values may cause unwanted marking during travel moves typical_values: - value: 0 description: default, laser completely off during travel - value: 0.01 description: 1% keepalive for diode stability - value: 0.02 description: 2% gentle keepalive - value: 0.05 description: 5% higher keepalive for thermal stability related_settings: - laser_module_maximum_power - laser_module_tickle_power - laser_module_proportional_power related_pages: - laser - laser-cutter-guide examples: - 'laser_module_minimum_power 0.0 # Laser completely off during travel (default, safest)' - 'laser_module_minimum_power 0.01 # 1% keepalive for diode thermal stability' - 'laser_module_minimum_power 0.02 # 2% gentle keepalive (common for diode lasers)' - 'laser_module_minimum_power 0.05 # 5% higher keepalive for some diode types' - name: laser_module_maximum_s_value type: number default: 1 module: laser context: Global module setting defined_in: src/modules/tools/laser/Laser.cpp:109 corresponding_v1: laser_module_maximum_s_value corresponding_v2: laser.maximum_s_value description: Defines the S-value in G-code that represents maximum laser power (100%). This scaling parameter allows you to use different S-value ranges in your G-code without changing other laser configuration settings. For example, if set to 1.0, then `S1.0` means full power. If set to 255, then `S255` means full power. This provides compatibility with different CAM software packages that may use different S-value conventions such as 0-1 (fractional), 0-100 (percentage), 0-255 (8-bit), or other scales. description_bullets: - Does not affect actual laser power output, only G-code interpretation - Allows using G-code from different CAM packages without modification - 'Power calculation: requested_power = S_value / maximum_s_value' - 'Example: With maximum_s_value=100, `S50` means 50% power' - 'Example: With maximum_s_value=255, `S128` means approximately 50% power' - 'Example: With maximum_s_value=1.0, `S0.5` means 50% power' - Useful for software that generates integer S-values (0-100, 0-255) - 'Setting to 100 allows percentage-style commands: `S50` for 50% instead of `S0.5`' - Does not change the maximum_power or minimum_power settings typical_values: - value: 1 description: S values 0.0-1.0, default Smoothie style - value: 100 description: S values 0-100, percentage style - value: 255 description: S values 0-255, 8-bit style - value: 1000 description: S values 0-1000 for finer control related_settings: - laser_module_maximum_power related_pages: - laser - supported-g-codes - laser-cutter-guide examples: - 'laser_module_maximum_s_value 1.0 # S values 0.0-1.0 (default Smoothie convention)' - 'laser_module_maximum_s_value 100 # S values 0-100 (percentage style for easier use)' - 'laser_module_maximum_s_value 255 # S values 0-255 (8-bit style, common in some software)' - 'laser_module_maximum_s_value 1000 # S values 0-1000 (finer control, 0.1% resolution)' - name: laser_module_proportional_power type: bool default: true module: laser context: Global module setting defined_in: src/modules/tools/laser/Laser.cpp:94 corresponding_v1: laser_module_proportional_power corresponding_v2: laser.proportional_power description: Enables or disables automatic power scaling based on actual instantaneous movement speed. When enabled (default), the laser power is continuously adjusted proportionally to the current velocity, automatically compensating for acceleration and deceleration phases. This ensures consistent energy density (joules per unit area, or "photons per square millimeter") across the entire cut path, even as the machine speeds up at the beginning of moves, slows down for corners, and decelerates at the end of moves. Disabling this feature results in constant power output regardless of speed variations, which may be desired for certain applications. description_bullets: - 'When enabled, power calculation: actual_power = requested_power × (current_speed / nominal_speed)' - Ensures uniform engraving depth and cutting quality despite speed variations - Compensates for machine acceleration and deceleration automatically - Prevents over-burning in corners where machine slows down - Prevents under-burning at start/end of moves during acceleration - Disable for applications needing constant power regardless of speed (some marking operations) - Works by continuously monitoring the stepper acceleration/deceleration trapezoid curve - Power updates occur at the PWM frequency or 1 kHz, whichever is lower - Can also be controlled at runtime via M221 P command - 'WARNING: Disabling may cause uneven cuts/engraving due to speed variations' related_m_codes: - code: M221 description: Query current power scale and proportional power status related_settings: - laser_module_minimum_power - laser_module_maximum_power related_pages: - laser - laser-cutter-guide - supported-g-codes examples: - 'laser_module_proportional_power true # Enable velocity-proportional power (default, recommended)' - 'laser_module_proportional_power false # Disable, use constant power (for special applications)' - name: laser_module_tickle_power type: number default: 0 module: laser context: Global module setting defined_in: src/modules/tools/laser/Laser.cpp:103 deprecated: false corresponding_v1: laser_module_tickle_power corresponding_v2: laser.minimum_power description: This parameter has been deprecated and replaced by `laser_module_minimum_power`. It originally set a small baseline amount of power to keep the laser "tickled" (slightly active) during travel moves and as a floor for all operations. If you have old configuration files using this parameter, it will still work as it provides the fallback default value for `laser_module_minimum_power` when that setting is not explicitly specified, but you should migrate to using `laser_module_minimum_power` instead for clarity and future compatibility. description_bullets: - DEPRECATED - Use `laser_module_minimum_power` for all new configurations - Kept for backward compatibility with old config files only - Will be used as the default value for `laser_module_minimum_power` if that setting is not present - Same functionality as `laser_module_minimum_power` - sets baseline laser power - May be removed in future firmware versions related_settings: - laser_module_minimum_power related_pages: - laser - laser-cutter-guide examples: - '# Old (deprecated, but still works):' - laser_module_tickle_power 0.02 - '# New (preferred, recommended):' - laser_module_minimum_power 0.02 - name: Temperature Control description: Heating element and sensor configuration setting_count: 38 settings: - name: temperature_control.{name}.enable type: bool default: true module: temperature_control context: Module instance setting defined_in: modules/tools/temperaturecontrol/TemperatureControl.cpp:88 corresponding_v1: temperature_control.{name}.enable corresponding_v2: temperature control.{name}.enable description: Enables or disables the temperature control module instance. You can create as many temperature control modules as needed by giving each a unique name and setting its enable option to true. description_bullets: - Each module instance operates independently - Common instances include `hotend`, `bed`, `hotend2`, and `chamber` - Module names are arbitrary - choose descriptive names - Multiple instances can be created for multi-hotend or multi-zone heating systems related_settings: - heater_pin - thermistor_pin - designator related_pages: - temperaturecontrol - temperaturecontrol-pid - multiple-extruders examples: - 'temperature_control.hotend.enable true # Enable primary hotend' - 'temperature_control.bed.enable true # Enable heated bed' - 'temperature_control.hotend2.enable true # Enable second hotend for dual extrusion' - 'temperature_control.chamber.enable false # Disable chamber heater' - name: temperature_control.{name}.thermistor_pin type: pin default: 0.23 module: temperature_control context: Module instance setting (when sensor is `thermistor`, `ad8495`, or similar analog sensors) defined_in: modules/tools/temperaturecontrol/Thermistor.cpp:60 corresponding_v1: temperature_control.{name}.thermistor_pin corresponding_v2: temperature control.{name}.thermistor_pin description: Specifies which ADC (Analog-to-Digital Converter) pin is connected to the temperature sensor. Smoothieboard provides dedicated thermistor inputs TH1 through TH4 with built-in 4.7kΩ pullup resistors. description_bullets: - Only used when sensor type is `thermistor`, `ad8495`, or other analog sensors - Not used with SPI-based sensors like `max31855` - TH1-TH4 inputs have built-in 4.7kΩ pullup resistors to 3.3V - Consult your board's pinout diagram for correct pin assignments related_settings: - sensor - thermistor - heater_pin related_pages: - temperaturecontrol - pinout - temperaturecontrol-thermistor-choice examples: - 'temperature_control.hotend.thermistor_pin 0.23 # TH1 for primary hotend' - 'temperature_control.bed.thermistor_pin 0.24 # TH2 for heated bed' - 'temperature_control.hotend2.thermistor_pin 0.25 # TH3 for second hotend' - 'temperature_control.chamber.thermistor_pin 0.26 # TH4 for chamber' - name: temperature_control.{name}.heater_pin type: pin default: 2.7 module: temperature_control context: Module instance setting defined_in: modules/tools/temperaturecontrol/TemperatureControl.cpp:163 corresponding_v1: temperature_control.{name}.heater_pin corresponding_v2: temperature control.{name}.heater_pin description: Specifies the output pin used to drive the heater element. This pin controls either an onboard MOSFET or an external Solid State Relay (SSR). Set to `nc` (not connected) for read-only temperature monitoring without heating control. description_bullets: - Use `nc` for temperature monitoring without heating control - Ensure pin can handle the required current/voltage for your heater - Most heater outputs are MOSFET-driven, rated for 12-24V - When set to `nc`, the module becomes read-only (no PID control) related_settings: - thermistor_pin - max_pwm - pwm_frequency related_pages: - temperaturecontrol - mosfets - pinout examples: - 'temperature_control.hotend.heater_pin 2.5 # Primary hotend on MOSFET output' - 'temperature_control.bed.heater_pin 2.7 # Heated bed on large MOSFET' - 'temperature_control.hotend2.heater_pin 2.4 # Second hotend' - 'temperature_control.ambient.heater_pin nc # Read-only ambient temperature' - name: temperature_control.{name}.sensor type: string default: thermistor module: temperature_control context: Module instance setting defined_in: modules/tools/temperaturecontrol/TemperatureControl.cpp:173 corresponding_v1: temperature_control.{name}.sensor corresponding_v2: temperature control.{name}.sensor description: Selects the temperature sensor implementation. Different sensors use different physical principles and require different configuration parameters. description_bullets: - Each sensor type has specific configuration requirements - Thermistors are most common for hotends and beds (up to ~300°C) - Thermocouples handle higher temperatures (up to ~500°C) - RTD sensors provide better accuracy than thermistors - Default is thermistor for backward compatibility related_settings: - thermistor_pin - chip_select_pin - thermistor - beta related_pages: - temperaturecontrol - temperaturecontrol-thermistor-choice - pt100 examples: - 'temperature_control.hotend.sensor thermistor # Standard thermistor' - 'temperature_control.hotend2.sensor max31855 # High-temp thermocouple' - 'temperature_control.bed.sensor thermistor # Bed uses thermistor' - 'temperature_control.chamber.sensor pt100_e3d # Accurate RTD for chamber' - name: temperature_control.{name}.thermistor type: string default: none (uses manual beta/r0/t0 configuration if not specified) module: temperature_control context: Module instance setting (when sensor is `thermistor`) defined_in: modules/tools/temperaturecontrol/Thermistor.cpp:80 corresponding_v1: temperature_control.{name}.thermistor corresponding_v2: temperature control.{name}.thermistor description: Selects a pre-calibrated thermistor from the built-in database, automatically setting Steinhart-Hart coefficients or beta values. This simplifies configuration for common thermistor models. description_bullets: - Predefined models use standard 4.7kΩ pullup (r2=4700) - If your thermistor isn't listed, use manual `beta`, `r0`, `t0` configuration - Use `use_beta_table true` to force beta table instead of Steinhart-Hart - Steinhart-Hart provides better accuracy than beta equation related_settings: - sensor - beta - r0 - t0 - use_beta_table related_pages: - temperaturecontrol - temperaturecontrol-thermistor-choice - steinharthart examples: - 'temperature_control.hotend.thermistor EPCOS100K # Most common thermistor' - 'temperature_control.bed.thermistor Honeywell100K # Alternative thermistor' - 'temperature_control.hotend2.thermistor Semitec # High-quality thermistor' - name: temperature_control.{name}.beta type: number default: 4066 units: Kelvin (K) module: temperature_control context: Module instance setting (when sensor is `thermistor`) defined_in: modules/tools/temperaturecontrol/Thermistor.cpp:91 corresponding_v1: temperature_control.{name}.beta corresponding_v2: temperature control.{name}.beta description: The beta coefficient characterizes the thermistor's resistance-temperature relationship. It's used in the simplified Steinhart-Hart equation (beta equation) to convert resistance to temperature. More accurate than a linear approximation but less accurate than full Steinhart-Hart coefficients. description_bullets: - Only used when not using predefined thermistor - Ignored if using Steinhart-Hart coefficients - Usually specified at 25°C in datasheets - Higher beta = steeper resistance-temperature curve - Consult thermistor datasheet for exact value typical_values: - value: 3950 description: generic 100K - value: 4066 description: EPCOS 100K - value: 4267 description: high-temp thermistors related_settings: - thermistor - r0 - t0 - coefficients related_pages: - temperaturecontrol - temperaturecontrol-thermistor-choice - steinharthart examples: - 'temperature_control.hotend.beta 4066 # EPCOS 100K thermistor' - 'temperature_control.bed.beta 3950 # Generic 100K thermistor' - 'temperature_control.hotend2.beta 4267 # High-temp thermistor' - name: temperature_control.{name}.r0 type: number default: 100000 units: Ohms (Ω) module: temperature_control context: Module instance setting (when sensor is `thermistor`) defined_in: modules/tools/temperaturecontrol/Thermistor.cpp:92 corresponding_v1: temperature_control.{name}.r0 corresponding_v2: temperature control.{name}.r0 description: The nominal resistance of the thermistor at the reference temperature (usually 25°C). This is a fundamental property of the thermistor, typically specified in its part number (e.g., "100K" means 100,000Ω at 25°C). description_bullets: - Usually specified at 25°C (T0) - Part of manual thermistor configuration - Predefined thermistors set this automatically - Must match datasheet specification typical_values: - value: 100000 description: 100kΩ, most common - value: 10000 description: 10kΩ, less common related_settings: - thermistor - beta - t0 - r1 - r2 related_pages: - temperaturecontrol - temperaturecontrol-thermistor-choice examples: - 'temperature_control.hotend.r0 100000 # 100kΩ at 25°C (standard)' - 'temperature_control.bed.r0 10000 # 10kΩ at 25°C (less common)' - name: temperature_control.{name}.t0 type: number default: 25 units: Degrees Celsius (°C) module: temperature_control context: Module instance setting (when sensor is `thermistor`) defined_in: modules/tools/temperaturecontrol/Thermistor.cpp:93 corresponding_v1: temperature_control.{name}.t0 corresponding_v2: temperature control.{name}.t0 description: The temperature at which the thermistor has resistance R0. Almost always 25°C for commercial thermistors, as this is the industry standard reference point. description_bullets: - Standard value is 25°C for virtually all thermistors - Only change if datasheet specifies different reference - Part of manual thermistor configuration - Must match datasheet specification typical_values: - value: 25 description: industry standard reference temperature related_settings: - thermistor - beta - r0 related_pages: - temperaturecontrol - temperaturecontrol-thermistor-choice examples: - 'temperature_control.hotend.t0 25 # Standard reference temperature' - name: temperature_control.{name}.r1 type: number default: 0 units: Ohms (Ω) module: temperature_control context: Module instance setting (when sensor is `thermistor`) defined_in: modules/tools/temperaturecontrol/Thermistor.cpp:94 corresponding_v1: temperature_control.{name}.r1 corresponding_v2: temperature control.{name}.r1 description: Value of resistor in series with the thermistor, if present. Most Smoothieboard configurations use only a pullup resistor (r2) with no series resistor, so this is typically 0. description_bullets: - 'Standard Smoothieboard configuration: r1 = 0' - Only change if using custom thermistor circuit - Board property, not thermistor property - Any positive resistance value if custom circuit uses series resistor typical_values: - value: 0 description: no series resistor, standard Smoothieboard configuration related_settings: - thermistor - r0 - r2 related_pages: - temperaturecontrol - temperaturecontrol-thermistor-choice examples: - 'temperature_control.hotend.r1 0 # No series resistor (standard)' - name: temperature_control.{name}.r2 type: number default: 4700 units: Ohms (Ω) module: temperature_control context: Module instance setting (when sensor is `thermistor`) defined_in: modules/tools/temperaturecontrol/Thermistor.cpp:95 corresponding_v1: temperature_control.{name}.r2 corresponding_v2: temperature control.{name}.r2 description: Value of the pullup resistor connected between the thermistor and VCC. Smoothieboard has built-in 4.7kΩ pullup resistors on thermistor inputs TH1-TH4. description_bullets: - 'Standard Smoothieboard: `4700` (4.7kΩ)' - Only change if using external pullup resistor - Board property, not thermistor property - TH1-TH4 inputs have onboard 4.7kΩ pullups - Changing this requires hardware modification typical_values: - value: 4700 description: standard Smoothieboard related_settings: - thermistor - r0 - r1 related_pages: - temperaturecontrol - temperaturecontrol-thermistor-choice - pinout examples: - 'temperature_control.hotend.r2 4700 # Standard Smoothieboard pullup' - name: temperature_control.{name}.coefficients type: string default: none (uses beta or predefined thermistor if not specified) module: temperature_control context: Module instance setting (when sensor is `thermistor`) defined_in: modules/tools/temperaturecontrol/Thermistor.cpp:130 corresponding_v1: temperature_control.{name}.coefficients corresponding_v2: temperature control.{name}.coefficients description: The three coefficients (c1, c2, c3) of the Steinhart-Hart equation, which provides very accurate temperature calculation across the full operating range. More accurate than beta equation, especially at temperature extremes. description_bullets: - Provides better accuracy than beta equation - Can be calculated from datasheet or measured data - Overrides beta-based calculation - Predefined thermistors use Steinhart-Hart automatically related_settings: - thermistor - beta - rt_curve - use_beta_table related_pages: - temperaturecontrol - temperaturecontrol-thermistor-choice - steinharthart examples: - 'temperature_control.hotend.coefficients 0.000722376862540841,0.000216302098124288,0.000000092640163984 # Custom Steinhart-Hart' - name: temperature_control.{name}.rt_curve type: string default: null module: temperature_control context: Module instance setting (when sensor is `thermistor`) defined_in: modules/tools/temperaturecontrol/Thermistor.cpp:148 corresponding_v1: temperature_control.{name}.rt_curve corresponding_v2: temperature control.{name}.rt_curve description: 'Specify three temperature/resistance pairs from the thermistor datasheet, and Smoothie will automatically calculate Steinhart-Hart coefficients. Best practice: use points at 25°C, 150°C, and 240°C for 3D printing applications.' description_bullets: - Easier than manually calculating coefficients - Use three widely-spaced temperature points for best accuracy - Data available in most thermistor datasheets - Automatically enables Steinhart-Hart calculation related_settings: - thermistor - coefficients - beta related_pages: - temperaturecontrol - temperaturecontrol-thermistor-choice - steinharthart examples: - 'temperature_control.hotend.rt_curve 25.0,100000.0,150.0,1355.0,240.0,203.0 # Auto-calculate from datasheet points' - name: temperature_control.{name}.use_beta_table type: bool default: false module: temperature_control context: Module instance setting (when sensor is `thermistor`) defined_in: modules/tools/temperaturecontrol/Thermistor.cpp:73 corresponding_v1: temperature_control.{name}.use_beta_table corresponding_v2: temperature control.{name}.use_beta_table description: When using a predefined thermistor, force the use of the legacy beta table values instead of the more accurate Steinhart-Hart coefficients. Provided for backward compatibility with older configurations. description_bullets: - Only affects predefined thermistors - Default (false) uses more accurate Steinhart-Hart - Only use if you need exact compatibility with old behavior - Steinhart-Hart provides better accuracy across full temperature range related_settings: - thermistor - coefficients - beta related_pages: - temperaturecontrol - temperaturecontrol-thermistor-choice - steinharthart examples: - 'temperature_control.hotend.thermistor EPCOS100K # Use predefined thermistor' - 'temperature_control.hotend.use_beta_table true # Force legacy beta table mode' - name: temperature_control.{name}.chip_select_pin type: pin default: 0.16 module: temperature_control context: Module instance setting (when sensor is `max31855`) defined_in: modules/tools/temperaturecontrol/max31855.cpp:37 corresponding_v1: temperature_control.{name}.chip_select_pin corresponding_v2: temperature control.{name}.spi_select_pin description: Specifies which pin is used as the chip select (CS) signal for the MAX31855 thermocouple-to-digital converter. Allows multiple MAX31855 devices to share the same SPI bus by using unique CS pins. description_bullets: - Only used with `sensor max31855` - Multiple MAX31855 sensors can share MOSI/MISO/SCK, need unique CS - Pin must be configured as output related_settings: - sensor - spi_channel related_pages: - temperaturecontrol - pinout examples: - 'temperature_control.hotend.sensor max31855 # Use thermocouple' - 'temperature_control.hotend.chip_select_pin 0.16 # CS pin for first thermocouple' - 'temperature_control.hotend2.chip_select_pin 0.15 # CS pin for second thermocouple' - name: temperature_control.{name}.spi_channel type: number default: 0 module: temperature_control context: Module instance setting (when sensor is `max31855`) defined_in: modules/tools/temperaturecontrol/max31855.cpp:42 corresponding_v1: temperature_control.{name}.spi_channel corresponding_v2: temperature control.{name}.spi_channel description: Selects which hardware SPI peripheral is used to communicate with the MAX31855. Smoothieboard has two SPI channels with different pin assignments. description_bullets: - Only used with `sensor max31855` - Each SPI channel has fixed pin assignments - Multiple devices can share one channel using different CS pins related_settings: - sensor - chip_select_pin related_pages: - temperaturecontrol - pinout examples: - 'temperature_control.hotend.sensor max31855 # Use thermocouple' - 'temperature_control.hotend.spi_channel 0 # Use SPI channel 0' - name: temperature_control.{name}.e3d_amplifier_pin type: pin default: none (required when using PT100 E3D sensor) module: temperature_control context: Module instance setting (when sensor is `pt100_e3d`) defined_in: modules/tools/temperaturecontrol/PT100_E3D.cpp:31 corresponding_v1: temperature_control.{name}.e3d_amplifier_pin corresponding_v2: none (PT100 E3D not explicitly documented in v2) description: Specifies which ADC pin reads the analog voltage from the E3D PT100 amplifier. The amplifier converts PT100 RTD resistance to a voltage that can be read by the ADC. description_bullets: - Only used with `sensor pt100_e3d` - Must NOT use thermistor inputs (0.23-0.26) - E3D amplifier provides analog voltage proportional to temperature related_settings: - sensor related_pages: - temperaturecontrol - pt100 - pinout examples: - 'temperature_control.hotend.sensor pt100_e3d # Use PT100 RTD' - 'temperature_control.hotend.e3d_amplifier_pin 1.30 # ADC pin for amplifier' - name: temperature_control.{name}.readings_per_second type: number default: 20 units: Hz (readings per second) module: temperature_control context: Module instance setting defined_in: modules/tools/temperaturecontrol/TemperatureControl.cpp:139 corresponding_v1: temperature_control.{name}.readings_per_second corresponding_v2: temperature control.{name}.readings_per_second description: How many times per second the temperature sensor is read and the PID control loop is executed. Higher values provide faster response but increase CPU load. description_bullets: - Affects PID responsiveness - PID parameters (i_factor, d_factor) are internally scaled by this value - Lower values acceptable for slow-responding systems (heated beds) - Higher values provide tighter control for fast systems - 'Practical maximum: ~40 (CPU load considerations)' typical_values: - value: 10 description: slow systems like beds - value: 20 description: default - value: 40 description: fast-responding hotends related_settings: - p_factor - i_factor - d_factor related_pages: - temperaturecontrol - temperaturecontrol-pid - temperaturecontrol-fine-tuning examples: - 'temperature_control.hotend.readings_per_second 20 # Default for hotends' - 'temperature_control.bed.readings_per_second 10 # Slower for thermal mass of bed' - name: temperature_control.{name}.pwm_frequency type: number default: 2000 units: Hz (Hertz) module: temperature_control context: Module instance setting defined_in: modules/tools/temperaturecontrol/TemperatureControl.cpp:209 corresponding_v1: temperature_control.{name}.pwm_frequency corresponding_v2: '[pwm1] frequency' description: Frequency at which the heater output switches on and off. High frequencies (kHz range) are suitable for MOSFETs. Low frequencies (10-40 Hz) are required for mechanical relays or SSRs to avoid excessive switching. description_bullets: - 'MOSFET control: `1000` - `10000` Hz (typical: 2000)' - 'SSR/relay control: `10` - `40` Hz (typical: 20)' - MOSFETs can switch at kHz frequencies without wear - SSRs and mechanical relays have limited switching lifetime - Lower frequency = more temperature ripple - Too high frequency can cause EMI typical_values: - value: 2000 description: MOSFETs - value: 20 description: SSRs/relays related_settings: - heater_pin - max_pwm related_pages: - temperaturecontrol - mosfets - temperaturecontrol-fine-tuning examples: - 'temperature_control.hotend.pwm_frequency 2000 # 2kHz for MOSFET-driven hotend' - 'temperature_control.bed.pwm_frequency 20 # 20Hz for SSR-driven heated bed' - name: temperature_control.{name}.max_pwm type: number default: 255 module: temperature_control context: Module instance setting defined_in: modules/tools/temperaturecontrol/TemperatureControl.cpp:205 corresponding_v1: temperature_control.{name}.max_pwm corresponding_v2: temperature control.{name}.max_pwm description: Limits the maximum power delivered to the heater by capping the PWM duty cycle. Useful when running a 12V heater from 24V supply, or to limit maximum power draw. description_bullets: - 'For 12V heater on 24V supply: use max_pwm 64 (25% = 6W instead of 24W)' - Also limits PID output maximum - Set i_max to similar value to prevent integral windup related_settings: - heater_pin - pwm_frequency - i_max related_pages: - temperaturecontrol - temperaturecontrol-pid - temperaturecontrol-fine-tuning examples: - 'temperature_control.hotend.max_pwm 255 # Full power (12V heater on 12V supply)' - 'temperature_control.bed.max_pwm 64 # 25% power (12V heater on 24V supply)' - name: temperature_control.{name}.bang_bang type: bool default: false module: temperature_control context: Module instance setting defined_in: modules/tools/temperaturecontrol/TemperatureControl.cpp:202 corresponding_v1: temperature_control.{name}.bang_bang corresponding_v2: temperature control.{name}.bang_bang description: Switches from PID control to simple bang-bang (hysteresis) control. In bang-bang mode, the heater is fully on when below target temperature minus hysteresis, and fully off when above target plus hysteresis. description_bullets: - Bang-bang is simpler and works well for high thermal mass (beds) - PID provides tighter control for low thermal mass (hotends) - Requires `hysteresis` setting when enabled - Good for SSR-controlled heaters (avoids rapid switching) related_settings: - hysteresis - p_factor - i_factor - d_factor related_pages: - temperaturecontrol - temperaturecontrol-pid examples: - 'temperature_control.bed.bang_bang true # Good for heated beds with high thermal mass' - 'temperature_control.bed.hysteresis 2.0 # ±2°C band around target' - 'temperature_control.hotend.bang_bang false # PID for precise hotend control' - name: temperature_control.{name}.hysteresis type: number default: 2 units: Degrees Celsius (°C) module: temperature_control context: Module instance setting (when bang_bang is `true`) defined_in: modules/tools/temperaturecontrol/TemperatureControl.cpp:203 corresponding_v1: temperature_control.{name}.hysteresis corresponding_v2: temperature control.{name}.hysteresis description: Defines the temperature band around the target temperature for bang-bang control. Heater turns on when temperature drops below (target - hysteresis) and turns off when it rises above (target + hysteresis). description_bullets: - Only used when `bang_bang true` - Total temperature swing = 2 × hysteresis - Lower values = tighter control but more frequent switching - Higher values = less switching but more temperature variation typical_values: - value: 1 description: tight control - value: 2 description: default - value: 5 description: loose control, less switching related_settings: - bang_bang - max_pwm related_pages: - temperaturecontrol examples: - 'temperature_control.bed.bang_bang true # Enable bang-bang control' - 'temperature_control.bed.hysteresis 2.0 # ±2°C around target (4°C total swing)' - name: temperature_control.{name}.p_factor type: number default: 13.7 module: temperature_control context: Module instance setting (when bang_bang is `false`) defined_in: modules/tools/temperaturecontrol/TemperatureControl.cpp:218 corresponding_v1: temperature_control.{name}.p_factor corresponding_v2: temperature control.{name}.p_factor description: The proportional term of the PID controller. Determines how aggressively the controller responds to the current temperature error. Higher values produce faster response but can cause overshoot and oscillation. description_bullets: - 'Typical range for hotends: `10` - `20`' - 'Typical range for heated beds: `20` - `50`' - Higher P = faster response, more overshoot - Lower P = slower response, more stable - Use M301 to adjust and test - Start with default and tune if needed typical_values: - value: 13.7 description: hotends - value: 30 description: heated beds related_m_codes: - code: M500 description: Save current PID values to config-override related_settings: - i_factor - d_factor - i_max - bang_bang related_pages: - temperaturecontrol - temperaturecontrol-pid - temperaturecontrol-pid-autotuning examples: - 'temperature_control.hotend.p_factor 13.7 # Default for hotends' - 'temperature_control.bed.p_factor 30.0 # Higher for bed thermal mass' - name: temperature_control.{name}.i_factor type: number default: 0.097 module: temperature_control context: Module instance setting (when bang_bang is `false`) defined_in: modules/tools/temperaturecontrol/TemperatureControl.cpp:219 corresponding_v1: temperature_control.{name}.i_factor corresponding_v2: temperature control.{name}.i_factor description: The integral term of the PID controller. Eliminates steady-state error by accumulating error over time. Internally scaled by `readings_per_second` (PIDdt). description_bullets: - Value in config is actual i_factor, scaled internally by PIDdt - 'Typical range for hotends: `0.05` - `0.3`' - 'Typical range for heated beds: `0.1` - `1.0`' - Higher I = faster elimination of steady-state error, risk of oscillation - Too high I causes overshoot and oscillation - i_max prevents integral windup typical_values: - value: 0.097 description: hotends - value: 0.5 description: heated beds related_m_codes: - code: M500 description: Save current PID values to config-override related_settings: - p_factor - d_factor - i_max - windup related_pages: - temperaturecontrol - temperaturecontrol-pid - temperaturecontrol-pid-autotuning examples: - 'temperature_control.hotend.i_factor 0.097 # Default for hotends' - 'temperature_control.bed.i_factor 0.5 # Higher for bed thermal mass' - name: temperature_control.{name}.d_factor type: number default: 24 module: temperature_control context: Module instance setting (when bang_bang is `false`) defined_in: modules/tools/temperaturecontrol/TemperatureControl.cpp:220 corresponding_v1: temperature_control.{name}.d_factor corresponding_v2: temperature control.{name}.d_factor description: The derivative term of the PID controller. Responds to the rate of temperature change to reduce overshoot and improve stability. Internally scaled by `readings_per_second` (PIDdt). description_bullets: - Value in config is actual d_factor, scaled internally by PIDdt - 'Typical range for hotends: `20` - `200`' - 'Typical range for heated beds: `50` - `300`' - Higher D = stronger damping, reduced overshoot - Too high D makes system sluggish and sensitive to noise - D term acts on rate of change, not error magnitude typical_values: - value: 24 description: hotends - value: 100 description: heated beds related_m_codes: - code: M500 description: Save current PID values to config-override related_settings: - p_factor - i_factor - i_max related_pages: - temperaturecontrol - temperaturecontrol-pid - temperaturecontrol-pid-autotuning examples: - 'temperature_control.hotend.d_factor 24 # Default for hotends' - 'temperature_control.bed.d_factor 100 # Higher for bed stability' - name: temperature_control.{name}.i_max type: number default: max_pwm module: temperature_control context: Module instance setting (when bang_bang is `false`) defined_in: modules/tools/temperaturecontrol/TemperatureControl.cpp:224 corresponding_v1: temperature_control.{name}.i_max corresponding_v2: temperature control.{name}.i_max description: Limits the integral accumulator to prevent integral windup. When the heater is at full power (max_pwm) for extended periods, the integral term would otherwise grow excessively large, causing overshoot when the target is reached. description_bullets: - 'Range: `0` - `255`' - 'Typical: Same as `max_pwm`' - Can be lower than `max_pwm` to reduce overshoot - Prevents integral windup during heating - Usually set equal to max_pwm - If strong overshoot during initial heating, reduce i_max related_m_codes: - code: M500 description: Save current value to config-override related_settings: - i_factor - max_pwm - windup related_pages: - temperaturecontrol - temperaturecontrol-pid - temperaturecontrol-fine-tuning examples: - 'temperature_control.hotend.max_pwm 255 # Full power available' - 'temperature_control.hotend.i_max 255 # Allow I term to reach max_pwm' - 'temperature_control.bed.max_pwm 200 # Limited power for 12V heater on 24V' - 'temperature_control.bed.i_max 200 # Limit I term to match max_pwm' - name: temperature_control.{name}.windup type: bool default: false module: temperature_control context: Module instance setting (when bang_bang is `false`) defined_in: modules/tools/temperaturecontrol/TemperatureControl.cpp:204 corresponding_v1: temperature_control.{name}.windup corresponding_v2: temperature control.{name}.windup description: When enabled, the integral term only accumulates when the output is not saturated (not at 0 or max_pwm). This alternative anti-windup strategy prevents integral accumulation during periods when the controller is at its limits. description_bullets: - 'Two anti-windup strategies: i_max clamping (default) or conditional integration (windup true)' - 'Default behavior (windup false): accumulate always, clamp to i_max' - 'With windup true: only accumulate when output not saturated' - Most users should leave at default (false) related_settings: - i_factor - i_max - max_pwm related_pages: - temperaturecontrol - temperaturecontrol-pid examples: - 'temperature_control.hotend.windup false # Standard i_max clamping mode' - 'temperature_control.bed.windup true # Conditional integration mode' - name: temperature_control.{name}.get_m_code type: number default: 105 module: temperature_control context: Module instance setting defined_in: modules/tools/temperaturecontrol/TemperatureControl.cpp:138 corresponding_v1: temperature_control.{name}.get_m_code corresponding_v2: temperature control.{name}.get_m_code description: Specifies which M-code reports the current temperature for this module. M105 is standard for temperature reporting and returns data for all temperature controllers. description_bullets: - 'Standard: `105` (reports all temperatures)' - All modules typically use M105 - 'Response format: `T:210.0/200.0 B:60.0/60.0`' - First number is current temp, second is target typical_values: - value: 105 description: standard for all temperature controllers related_m_codes: - code: M105 description: Get all temperature readings related_settings: - set_m_code - set_and_wait_m_code - designator related_pages: - temperaturecontrol - supported-g-codes examples: - 'temperature_control.hotend.get_m_code 105 # Standard query command' - 'temperature_control.bed.get_m_code 105 # All use same M-code' - name: temperature_control.{name}.set_m_code type: number default: 104 module: temperature_control context: Module instance setting defined_in: modules/tools/temperaturecontrol/TemperatureControl.cpp:136 corresponding_v1: temperature_control.{name}.set_m_code corresponding_v2: temperature control.{name}.set_m_code description: Specifies which M-code sets the target temperature without waiting. Execution continues immediately after setting the temperature. description_bullets: - 'Hotend standard: `104`' - 'Bed standard: `140`' - 'Custom: Any unused M-code number' - 'Command format: `M104 S200` sets temperature to 200°C' - 'Non-blocking: gcode continues immediately' - Use M109/M190 for wait-until-reached behavior typical_values: - value: 104 description: hotends - value: 140 description: beds - value: 141 description: chambers related_m_codes: [] related_settings: - set_and_wait_m_code - get_m_code related_pages: - temperaturecontrol - supported-g-codes examples: - 'temperature_control.hotend.set_m_code 104 # M104 for hotend' - 'temperature_control.bed.set_m_code 140 # M140 for bed' - 'temperature_control.chamber.set_m_code 141 # M141 for chamber' - name: temperature_control.{name}.set_and_wait_m_code type: number default: 109 module: temperature_control context: Module instance setting defined_in: modules/tools/temperaturecontrol/TemperatureControl.cpp:137 corresponding_v1: temperature_control.{name}.set_and_wait_m_code corresponding_v2: temperature control.{name}.set_and_wait_m_code description: Specifies which M-code sets the target temperature and waits until that temperature is reached before continuing execution. Blocking command. description_bullets: - 'Hotend standard: `109`' - 'Bed standard: `190`' - 'Custom: Any unused M-code number' - 'Command format: `M109 S200` sets temperature and waits' - 'Blocking: no further gcode executed until temperature reached' - Reports temperature every second while waiting - Can be interrupted by kill/halt command typical_values: - value: 109 description: hotends - value: 190 description: beds - value: 191 description: chambers related_m_codes: [] related_settings: - set_m_code - get_m_code related_pages: - temperaturecontrol - supported-g-codes examples: - 'temperature_control.hotend.set_and_wait_m_code 109 # M109 for hotend' - 'temperature_control.bed.set_and_wait_m_code 190 # M190 for bed' - 'temperature_control.chamber.set_and_wait_m_code 191 # M191 for chamber' - name: temperature_control.{name}.designator type: string default: T module: temperature_control context: Module instance setting defined_in: modules/tools/temperaturecontrol/TemperatureControl.cpp:141 corresponding_v1: temperature_control.{name}.designator corresponding_v2: temperature control.{name}.designator description: The letter/identifier that prefixes this module's temperature in M105 responses. Allows host software to identify which heater each temperature reading represents. description_bullets: - Used in M105 responses - 'Format: `designator:current/target @pwm`' - 'Example response: `ok T:210.0/200.0 @180 B:60.0/60.0 @255`' related_m_codes: - code: M105 description: Uses designator in temperature report related_settings: - get_m_code - set_m_code related_pages: - temperaturecontrol - supported-g-codes examples: - 'temperature_control.hotend.designator T # Shows as "T:210/200"' - 'temperature_control.bed.designator B # Shows as "B:60/60"' - 'temperature_control.chamber.designator C # Shows as "C:40/40"' - 'temperature_control.hotend2.designator T1 # Shows as "T1:200/200"' - name: temperature_control.{name}.max_temp type: number default: 300 units: Degrees Celsius (°C) module: temperature_control context: Module instance setting defined_in: modules/tools/temperaturecontrol/TemperatureControl.cpp:159 corresponding_v1: temperature_control.{name}.max_temp corresponding_v2: temperature control.{name}.max_temp description: Hard upper limit for temperature. If the sensor reads above this value, the system immediately halts and turns off all heaters. Critical safety feature to prevent thermal runaway and fire hazards. description_bullets: - 'CRITICAL: Exceeding this triggers immediate HALT' - Set ~20-50°C above maximum operating temperature - 'PTFE-lined hotends: max 260-280°C' - 'All-metal hotends: up to 500°C' - 'Heated beds: typically 120-150°C' - System requires reset or M999 after max_temp violation typical_values: - value: 280 description: PTFE hotends - value: 300 description: default - value: 500 description: all-metal hotends - value: 150 description: heated beds related_m_codes: - code: M143 description: Query current max_temp settings - code: M999 description: Reset after HALT related_settings: - min_temp - runaway_range - runaway_heating_timeout related_pages: - temperaturecontrol - troubleshooting examples: - 'temperature_control.hotend.max_temp 300 # PTFE-lined hotend safety limit' - 'temperature_control.bed.max_temp 150 # PCB bed limit' - 'temperature_control.hotend2.max_temp 500 # All-metal hotend capability' - name: temperature_control.{name}.min_temp type: number default: 0 units: Degrees Celsius (°C) module: temperature_control context: Module instance setting defined_in: modules/tools/temperaturecontrol/TemperatureControl.cpp:160 corresponding_v1: temperature_control.{name}.min_temp corresponding_v2: temperature control.{name}.min_temp description: Hard lower limit for temperature. If the sensor reads below this value, the system halts. Primarily used to detect disconnected or failed thermistors, which typically read very low or infinite resistance (appearing as very low temperature). description_bullets: - Detects disconnected or shorted thermistors - Disconnected thermistor typically reads as very low temperature - System halts if temperature falls below this value - Set to 0 or slightly above room temperature typical_values: - value: 0 description: standard - value: 5 description: detect failures faster related_settings: - max_temp - thermistor_pin related_pages: - temperaturecontrol - troubleshooting examples: - 'temperature_control.hotend.min_temp 0 # Standard minimum' - 'temperature_control.bed.min_temp 0 # Detect sensor failures' - name: temperature_control.{name}.preset1 type: number default: 0 units: Degrees Celsius (°C) module: temperature_control context: Module instance setting defined_in: modules/tools/temperaturecontrol/TemperatureControl.cpp:193 corresponding_v1: temperature_control.{name}.preset1 corresponding_v2: temperature control.{name}.preset1 description: Allows setting a common temperature with a shortcut. When you set temperature to `1.0`, the controller uses this preset value instead. Useful for quickly selecting common temperatures like PLA printing temp. description_bullets: - '`0` = disabled (default)' - '`M104 S1` sets temperature to preset1 value' - Helps avoid typing full temperature repeatedly - Convenience feature for common temperatures typical_values: - value: 0 description: disabled - value: 200 description: PLA - value: 230 description: ABS related_m_codes: [] related_settings: - preset2 - set_m_code - set_and_wait_m_code related_pages: - temperaturecontrol - supported-g-codes examples: - 'temperature_control.hotend.preset1 200 # PLA temperature' - 'temperature_control.hotend.preset2 230 # ABS temperature' - 'temperature_control.bed.preset1 60 # PLA bed temperature' - name: temperature_control.{name}.preset2 type: number default: 0 units: Degrees Celsius (°C) module: temperature_control context: Module instance setting defined_in: modules/tools/temperaturecontrol/TemperatureControl.cpp:194 corresponding_v1: temperature_control.{name}.preset2 corresponding_v2: temperature control.{name}.preset2 description: Second preset temperature slot. When you set temperature to `2.0`, the controller uses this preset value instead. description_bullets: - '`0` = disabled (default)' - '`M104 S2` sets temperature to preset2 value' - Typically used for second-most-common temperature - See preset1 for usage details typical_values: - value: 0 description: disabled - value: 230 description: ABS - value: 240 description: PETG related_m_codes: [] related_settings: - preset1 - set_m_code - set_and_wait_m_code related_pages: - temperaturecontrol - supported-g-codes examples: - 'temperature_control.hotend.preset1 200 # PLA' - 'temperature_control.hotend.preset2 230 # ABS' - 'temperature_control.bed.preset1 60 # PLA bed' - 'temperature_control.bed.preset2 100 # ABS bed' - name: temperature_control.{name}.runaway_range type: number default: 20 units: Degrees Celsius (°C) module: temperature_control context: Module instance setting defined_in: modules/tools/temperaturecontrol/TemperatureControl.cpp:144 maximum_value: '`63` (clamped in firmware: TemperatureControl.cpp:145)' corresponding_v1: temperature_control.{name}.runaway_range corresponding_v2: temperature control.{name}.runaway_range description: Once the target temperature is reached, monitors for temperature divergence. If actual temperature deviates from target by more than this amount for >8 seconds, the system halts. Detects heater failures, thermal runaway, or cooling system problems. description_bullets: - Only active after target temperature reached - Allows brief spikes due to noise - Requires sustained deviation for 8+ seconds - Detects failing heaters or thermal runaway - Set to 0 to disable this protection - Clamped to maximum of 63 in firmware typical_values: - value: 10 description: tight tolerance - value: 20 description: default - value: 30 description: loose tolerance related_settings: - runaway_heating_timeout - runaway_cooling_timeout - runaway_error_range related_pages: - temperaturecontrol - temperaturecontrol-fine-tuning - troubleshooting examples: - 'temperature_control.hotend.runaway_range 20 # ±20°C deviation allowed' - 'temperature_control.bed.runaway_range 10 # Tighter tolerance for bed' - name: temperature_control.{name}.runaway_heating_timeout type: number default: 900 units: Seconds module: temperature_control context: Module instance setting defined_in: modules/tools/temperaturecontrol/TemperatureControl.cpp:149 maximum_value: '`4088` (clamped in firmware: TemperatureControl.cpp:150)' corresponding_v1: temperature_control.{name}.runaway_heating_timeout corresponding_v2: temperature control.{name}.runaway_heating_timeout description: Maximum time allowed from when heating starts until target temperature is reached. If the temperature doesn't reach target within this time, the system halts. Detects underpowered heaters, failed heaters, or inadequate insulation. description_bullets: - Prevents indefinite heating when heater is failing - Beds need longer timeout than hotends (higher thermal mass) - Set to 0 to disable - Checked every 8 seconds (internally stored as timeout/8) - System halts if timeout exceeded - Maximum value is 4088 seconds (68 minutes), clamped by firmware typical_values: - value: 300 description: 5 min, fast hotends - value: 900 description: 15 min, default - value: 1800 description: 30 min, large beds related_settings: - runaway_range - runaway_cooling_timeout - runaway_error_range related_pages: - temperaturecontrol - temperaturecontrol-fine-tuning - troubleshooting examples: - 'temperature_control.hotend.runaway_heating_timeout 900 # 15 minutes for hotend' - 'temperature_control.bed.runaway_heating_timeout 1800 # 30 minutes for bed thermal mass' - name: temperature_control.{name}.runaway_cooling_timeout type: number default: 0 units: Seconds module: temperature_control context: Module instance setting defined_in: modules/tools/temperaturecontrol/TemperatureControl.cpp:152 maximum_value: '`4088` (clamped in firmware: TemperatureControl.cpp:153)' corresponding_v1: temperature_control.{name}.runaway_cooling_timeout corresponding_v2: temperature control.{name}.runaway_cooling_timeout description: Maximum time allowed to cool down to target temperature when reducing temperature. If temperature doesn't reach target within this time, the system halts. Useful for detecting failed cooling fans or thermal runaways during cooldown. description_bullets: - Disabled by default - Less commonly used than heating timeout - Can detect failed cooling fans - Set to 0 to disable - Checked every 8 seconds (internally stored as timeout/8) - Maximum value is 4088 seconds (68 minutes), clamped by firmware typical_values: - value: 0 description: disabled by default - value: 600 description: 10 min - value: 1800 description: 30 min related_settings: - runaway_range - runaway_heating_timeout - runaway_error_range related_pages: - temperaturecontrol - temperaturecontrol-fine-tuning examples: - 'temperature_control.hotend.runaway_cooling_timeout 0 # Disabled (default)' - 'temperature_control.bed.runaway_cooling_timeout 1800 # 30 min cooling timeout if needed' - name: temperature_control.{name}.runaway_error_range type: number default: 1 units: Degrees Celsius (°C) module: temperature_control context: Module instance setting defined_in: modules/tools/temperaturecontrol/TemperatureControl.cpp:156 corresponding_v1: temperature_control.{name}.runaway_error_range corresponding_v2: temperature control.{name}.runaway_error_range description: Defines how close the actual temperature must be to the target to be considered "reached." Used by runaway detection to determine when heating/cooling is complete and steady-state monitoring should begin. description_bullets: - Used to determine when "target reached" - 'Too tight: may never register as reached (noisy sensor)' - 'Too loose: premature transition to steady-state monitoring' - 'Typical: 1-2°C for hotends, 2-3°C for beds' typical_values: - value: 0.5 description: strict - value: 1 description: default - value: 2 description: lenient related_settings: - runaway_range - runaway_heating_timeout - runaway_cooling_timeout related_pages: - temperaturecontrol - temperaturecontrol-fine-tuning examples: - 'temperature_control.hotend.runaway_error_range 1.0 # Within ±1°C to be considered reached' - 'temperature_control.bed.runaway_error_range 2.0 # Within ±2°C for bed (more thermal mass)' - name: Switch Module description: GPIO and PWM control settings setting_count: 18 settings: - name: switch.{name}.enable type: bool default: false module: switch context: Module instance setting defined_in: modules/tools/switch/SwitchPool.cpp:29 corresponding_v1: switch.{name}.enable corresponding_v2: switch.{name}.enable description: Creates and enables a new Switch module instance. When set to `true`, the switch module is active and will respond to configured inputs and control outputs. Set to `false` to disable the switch instance without removing its configuration. description_bullets: - Each switch instance requires a unique name (e.g., `fan`, `psu`, `spindle`) - Disabled switches ignore all inputs and do not control outputs - Parameters for disabled switches are ignored but preserved in configuration related_settings: - switch.{name}.output_pin - switch.{name}.input_pin related_pages: - switch - motion-control - endstops examples: - 'switch.fan.enable true # Enable cooling fan switch' - 'switch.psu.enable true # Enable ATX power supply switch' - 'switch.misc.enable false # Disabled switch preserves config' - name: switch.{name}.input_pin type: pin default: nc module: switch context: Module instance setting defined_in: modules/tools/switch/Switch.cpp:104 corresponding_v1: switch.{name}.input_pin corresponding_v2: switch.{name}.input_pin description: Specifies a GPIO pin that controls the switch state through hardware input. When configured, the pin's state determines the switch's ON/OFF state according to `input_pin_behavior`. The pin is configured as an input with the specified properties. description_bullets: - Input pins are polled at 100ms intervals (10Hz) by SlowTicker (line 203) - When an input pin is configured, the switch becomes input-driven - Input pins set `ignore_on_halt` to `true` automatically (line 112) - Pin state changes trigger switch state changes according to `input_pin_behavior` - Cannot use both input pins and input commands simultaneously (input pin takes priority) related_settings: - switch.{name}.input_pin_behavior - switch.{name}.output_on_command - switch.{name}.output_off_command related_pages: - switch - pin-configuration - endstops examples: - 'switch.fan.input_pin 2.11 # Pin P2.11, no modifiers' - 'switch.estop.input_pin 1.30^ # Pin P1.30 with pullup' - 'switch.door.input_pin 1.29!^ # Pin P1.29, inverted with pullup' - 'switch.psu.input_pin nc # No input pin (command-controlled)' - name: switch.{name}.input_pin_behavior type: enum default: momentary module: switch context: Module instance setting defined_in: modules/tools/switch/Switch.cpp:109 corresponding_v1: switch.{name}.input_pin_behavior corresponding_v2: switch.{name}.input_pin_behavior description: Defines how the input pin controls the switch state. In momentary mode, the switch state tracks the pin state directly. In toggle mode, pin state transitions (low-to-high) flip the switch state. description_bullets: - Only applies when `input_pin` is configured - 'Momentary behavior: switch state mirrors pin state continuously (lines 488, 494-497)' - 'Toggle behavior: only rising edges trigger state change, falling edges ignored (lines 484-485)' - For toggle mode, initial switch state is undefined until first toggle - For momentary mode, initial switch state matches pin state at startup (line 200) - Ignored if no input pin is configured related_settings: - switch.{name}.input_pin - switch.{name}.output_on_command - switch.{name}.output_off_command related_pages: - switch - endstops - killbutton examples: - 'switch.fan.input_pin_behavior momentary # Switch ON while button pressed' - 'switch.light.input_pin_behavior toggle # Button press toggles light on/off' - name: switch.{name}.input_on_command type: string default: '""' module: switch context: Module instance setting defined_in: modules/tools/switch/Switch.cpp:97 corresponding_v1: switch.{name}.input_on_command corresponding_v2: switch.{name}.input_on_command description: Specifies a G-code or M-code command that sets the switch to the ON state. The command is matched against incoming G-code, and when received, the switch turns ON. Supports optional subcode matching via `switch.subcode`. description_bullets: - Commands are parsed as G-code/M-code without parameters (lines 254-262) - 'Subcode matching: Use `switch.subcode` to differentiate multiple switches responding to the same base command' - The `S` parameter can control PWM value for PWM-type outputs (lines 321-322, 340-348) - Commands are queued and executed synchronously with motion (waits for idle before switching) - Cannot be used simultaneously with input pins (input pins take priority) - Empty string effectively disables command-based control related_m_codes: - code: M106 description: Typically used for fan control with S parameter for PWM - code: M3 description: Typically used for spindle on - code: M42 description: GPIO control command - code: M80 description: ATX power supply on related_settings: - switch.{name}.input_off_command - switch.{name}.subcode - switch.{name}.output_type related_pages: - switch - supported-g-codes - motion-control examples: - 'switch.fan.input_on_command M106 # Turn on with M106 (fan on)' - 'switch.spindle.input_on_command M3 # Turn on with M3 (spindle on)' - 'switch.vacuum.input_on_command M10 # Turn on with M10 (custom command)' - 'switch.psu.input_on_command M80 # Turn on with M80 (ATX power on)' - name: switch.{name}.input_off_command type: string default: '""' module: switch context: Module instance setting defined_in: modules/tools/switch/Switch.cpp:98 corresponding_v1: switch.{name}.input_off_command corresponding_v2: switch.{name}.input_off_command description: Specifies a G-code or M-code command that sets the switch to the OFF state. The command is matched against incoming G-code, and when received, the switch turns OFF. Supports optional subcode matching via `switch.subcode`. description_bullets: - Commands are parsed as G-code/M-code without parameters (lines 264-272) - 'Subcode matching: Use `switch.subcode` to differentiate multiple switches' - Commands are queued and executed synchronously with motion (waits for idle before switching) - Cannot be used simultaneously with input pins (input pins take priority) - Empty string effectively disables command-based control related_m_codes: - code: M107 description: Typically used for fan off - code: M5 description: Typically used for spindle off - code: M42 description: GPIO control command - code: M81 description: ATX power supply off related_settings: - switch.{name}.input_on_command - switch.{name}.subcode - switch.{name}.output_type related_pages: - switch - supported-g-codes - motion-control examples: - 'switch.fan.input_off_command M107 # Turn off with M107 (fan off)' - 'switch.spindle.input_off_command M5 # Turn off with M5 (spindle off)' - 'switch.vacuum.input_off_command M11 # Turn off with M11 (custom command)' - 'switch.psu.input_off_command M81 # Turn off with M81 (ATX power off)' - name: switch.{name}.subcode type: number default: 0 module: switch context: Module instance setting defined_in: modules/tools/switch/Switch.cpp:96 corresponding_v1: switch.{name}.subcode corresponding_v2: switch.{name}.subcode description: Specifies a subcode for input command matching. Allows multiple switch instances to respond to different subcodes of the same base command (e.g., `M106.1` vs `M106.2`). Only affects command matching for `input_on_command` and `input_off_command`. description_bullets: - Subcode `0` is the default and matches commands without explicit subcodes - Allows multiple switches to share the same base command but respond to different subcodes - Only evaluated when both `input_on_command` and/or `input_off_command` are set - Subcode is part of the command matching logic (both command letter and subcode must match, lines 297, 304) related_settings: - switch.{name}.input_on_command - switch.{name}.input_off_command related_pages: - switch - supported-g-codes - multiple-extruders examples: - 'switch.fan.input_on_command M106 # First example switch' - switch.fan.input_off_command M107 - 'switch.fan.subcode 0 # Responds to M106/M107 (no subcode)' - 'switch.extruder_fan.input_on_command M106 # Second example switch' - switch.extruder_fan.input_off_command M107 - 'switch.extruder_fan.subcode 1 # Responds to M106.1/M107.1' - 'switch.case_fan.input_on_command M106 # Third example switch' - switch.case_fan.input_off_command M107 - 'switch.case_fan.subcode 2 # Responds to M106.2/M107.2' - name: switch.{name}.output_pin type: pin default: nc module: switch context: Module instance setting defined_in: modules/tools/switch/Switch.cpp:130 corresponding_v1: switch.{name}.output_pin corresponding_v2: switch.{name}.output_pin description: Specifies the GPIO pin that is controlled by the switch. The pin's behavior depends on `output_type` (digital on/off, PWM, hardware PWM, or software PWM). The pin is configured as an output with the specified properties. description_bullets: - Output pin behavior depends on `output_type` setting - Inverted pins (`!`) reverse the logical state (high becomes low, low becomes high) - For hardware PWM (`hwpwm`), pin must be PWM-capable (see PWM-capable pin documentation) - Failsafe behavior can be configured via `failsafe_set_to` for crash/halt conditions (lines 132-136, 148-152, 164-168, 182-186) - Output pins are only used when the switch is not in input-pin mode related_settings: - switch.{name}.output_type - switch.{name}.failsafe_set_to - switch.{name}.halt_set_to related_pages: - switch - pin-configuration - mosfets - pwm-capable examples: - 'switch.fan.output_pin 2.6 # Pin P2.6, active high' - 'switch.psu.output_pin 2.19! # Pin P2.19, inverted (active low)' - 'switch.light.output_pin 1.23 # Pin P1.23' - 'switch.misc.output_pin nc # No output pin (command-only switch)' - name: switch.{name}.output_type type: enum default: pwm module: switch context: Module instance setting defined_in: modules/tools/switch/Switch.cpp:122 corresponding_v1: switch.{name}.output_type corresponding_v2: switch.{name}.output_type description: Defines the output pin control method. Determines whether the output is simple digital on/off, sigma-delta PWM (software PWM using bit-banging), hardware PWM (using MCU PWM peripheral), or software PWM (timer-based software PWM). description_bullets: - 'DIGITAL: Pin is either fully on or fully off, no variable control' - 'PWM (sigma-delta): Software PWM using bit-banging, range 0-255, controlled via `max_pwm` (line 208)' - 'HWPWM: Uses MCU hardware PWM peripheral, range 0-100%, requires PWM-capable pins only (lines 160-173)' - 'SWPWM: Software timer-based PWM, range 0-100%, works on any pin but slower response than hwpwm (lines 175-189)' - For PWM types, `S` parameter in commands sets the PWM value (e.g., `M106 S128`) - Hardware PWM (`hwpwm`) provides the most precise and efficient PWM but is limited to specific pins - Software PWM (`swpwm`) is useful when hardware PWM peripherals are reserved (e.g., for laser modules) - Default value `pwm` is sigma-delta, not hardware PWM despite the name related_settings: - switch.{name}.output_pin - switch.{name}.max_pwm - switch.{name}.pwm_period_ms - switch.{name}.startup_value - switch.{name}.default_on_value related_pages: - switch - mosfets - pwm-capable examples: - 'switch.fan.output_type pwm # Sigma-delta PWM, 0-255 range' - 'switch.led.output_type digital # Simple on/off' - 'switch.servo.output_type hwpwm # Hardware PWM for precise servo control' - 'switch.heater.output_type swpwm # Software PWM, won''t interfere with laser' - name: switch.{name}.output_on_command type: string default: '""' module: switch context: Module instance setting defined_in: modules/tools/switch/Switch.cpp:99 corresponding_v1: switch.{name}.output_on_command corresponding_v2: switch.{name}.output_on_command description: Specifies a G-code command to execute when the switch transitions to the ON state. The command is sent to the G-code parser and executed. Underscores in the command are replaced with spaces to allow multi-word commands. description_bullets: - Commands are executed via the G-code parser (same as console commands, lines 517-523) - Underscores are replaced with spaces before execution (e.g., `M117_Hello_World` becomes `M117 Hello World`, line 281) - Commands execute when switch state changes to ON (either from input pin, input command, or public data request) - Output commands execute in the main loop, not immediately - If both output_on_command and output pin are configured, both execute - Empty string disables command execution related_settings: - switch.{name}.output_off_command - switch.{name}.input_pin - switch.{name}.output_pin related_pages: - switch - supported-g-codes - console-commands examples: - 'switch.estop.output_on_command abort # Abort job on switch ON' - 'switch.door.output_on_command M25 # Pause on door open' - 'switch.vacuum.output_on_command M42_P2.5_S255 # Turn on vacuum via M42' - 'switch.status.output_on_command M117_System_Active # Display message' - name: switch.{name}.output_off_command type: string default: '""' module: switch context: Module instance setting defined_in: modules/tools/switch/Switch.cpp:100 corresponding_v1: switch.{name}.output_off_command corresponding_v2: switch.{name}.output_off_command description: Specifies a G-code command to execute when the switch transitions to the OFF state. The command is sent to the G-code parser and executed. Underscores in the command are replaced with spaces to allow multi-word commands. description_bullets: - Commands are executed via the G-code parser (same as console commands) - Underscores are replaced with spaces before execution (line 282) - Commands execute when switch state changes to OFF (either from input pin, input command, or public data request) - Output commands execute in the main loop, not immediately - 'Special handling: `$J STOP` triggers emergency stop request for continuous jog (only works with input pins, lines 503-506)' - If both output_off_command and output pin are configured, both execute - Empty string disables command execution related_settings: - switch.{name}.output_on_command - switch.{name}.input_pin - switch.{name}.output_pin related_pages: - switch - supported-g-codes - console-commands examples: - 'switch.estop.output_off_command resume # Resume job on switch OFF' - 'switch.door.output_off_command M24 # Resume on door close' - 'switch.vacuum.output_off_command M42_P2.5_S0 # Turn off vacuum via M42' - 'switch.status.output_off_command M117_System_Idle # Display message' - 'switch.jog.output_off_command $J_STOP # Stop continuous jog' - name: switch.{name}.startup_state type: bool default: false module: switch context: Module instance setting defined_in: modules/tools/switch/Switch.cpp:101 corresponding_v1: switch.{name}.startup_state corresponding_v2: switch.{name}.startup_state description: Sets the initial state of the switch when the system boots. When `true`, the switch starts in the ON state. When `false`, the switch starts in the OFF state. For input-pin switches, this setting is overridden by the actual pin state. description_bullets: - For output-type switches, this determines the initial output state (lines 210-246) - For PWM outputs with `startup_state true`, uses `default_on_value` instead of `startup_value` (lines 224-225, 238-239) - For input-pin switches (momentary mode), initial state is read from pin and overrides this setting (lines 197-200) - For input-pin switches (toggle mode), this setting is used as the initial state until first toggle - Does not apply to failsafe or halt conditions (see `failsafe_set_to` and `halt_set_to`) related_settings: - switch.{name}.startup_value - switch.{name}.default_on_value - switch.{name}.input_pin_behavior related_pages: - switch - motion-control examples: - 'switch.fan.startup_state false # Fan off at boot' - 'switch.psu.startup_state true # PSU on at boot' - 'switch.light.startup_state true # Light on at boot' - name: switch.{name}.startup_value type: number default: max_pwm module: switch context: Module instance setting defined_in: modules/tools/switch/Switch.cpp:209 corresponding_v1: switch.{name}.startup_value corresponding_v2: switch.{name}.startup_value description: Sets the PWM value when the switch is in the OFF state (or at startup if `startup_state` is `false`). For SIGMADELTA PWM, this is the 0-255 value. For hardware/software PWM, this is the 0-100 percentage. Also used as the value to set on HALT for HWPWM and SWPWM. description_bullets: - Only applies to PWM output types (pwm, hwpwm, swpwm) - 'For SIGMADELTA: value is scaled by `max_pwm` setting (line 209)' - 'For HWPWM/SWPWM: value is a percentage (0.0 to 100.0, lines 222, 236)' - Used when `startup_state` is `false` or when switch is turned OFF (lines 227, 241) - For HWPWM/SWPWM, this is the value set during HALT condition (lines 71-72, 383, 386, 460, 463) - Ignored for digital output type related_settings: - switch.{name}.startup_state - switch.{name}.output_type - switch.{name}.max_pwm - switch.{name}.default_on_value related_pages: - switch - mosfets - pwm-capable examples: - switch.fan.output_type pwm - 'switch.fan.startup_value 128 # Start at 50% PWM (128/255)' - switch.servo.output_type hwpwm - 'switch.servo.startup_value 7.5 # Servo neutral position (7.5%)' - switch.dimmer.output_type swpwm - 'switch.dimmer.startup_value 0 # Start completely off' - name: switch.{name}.default_on_value type: number default: 0 module: switch context: Module instance setting defined_in: modules/tools/switch/Switch.cpp:223 corresponding_v1: switch.{name}.default_on_value corresponding_v2: switch.{name}.default_on_value description: Sets the PWM duty cycle percentage when the switch is turned ON (without an explicit `S` parameter). Only applies to hardware PWM and software PWM output types. This is the value used when the switch is turned on via command or startup state. description_bullets: - Only applies to HWPWM and SWPWM output types (lines 223, 237) - Ignored for SIGMADELTA (pwm) and DIGITAL output types - Used when switch is turned ON without an explicit `S` parameter (e.g., plain `M106` instead of `M106 S50`) - When `startup_state` is `true`, this value is used instead of `startup_value` (lines 224-225, 238-239) - Can be overridden by `S` parameter in commands (e.g., `M106 S75` sets to 75%, lines 340-348, 355-364) typical_values: - value: 7.5 description: servo neutral 1.5ms pulse at 20ms period - value: 50 description: 50% brightness - value: 100 description: full speed related_settings: - switch.{name}.startup_value - switch.{name}.output_type - switch.{name}.pwm_period_ms related_pages: - switch - pwm-capable - mosfets examples: - switch.servo.output_type hwpwm - switch.servo.pwm_period_ms 20 - 'switch.servo.default_on_value 7.5 # Servo neutral (1.5ms pulse)' - switch.fan.output_type hwpwm - 'switch.fan.default_on_value 100 # Full speed when turned on' - switch.led.output_type swpwm - 'switch.led.default_on_value 50 # 50% brightness when on' - name: switch.{name}.max_pwm type: number default: 255 module: switch context: Module instance setting defined_in: modules/tools/switch/Switch.cpp:208 maximum_value: '`255` (enforced by Pwm class, 8-bit PWM limit)' corresponding_v1: switch.{name}.max_pwm corresponding_v2: switch.{name}.max_pwm description: Sets the maximum PWM value for sigma-delta PWM output. Allows limiting the maximum output power/speed when using PWM mode. The `S` parameter in commands is scaled from 0-255 to 0-`max_pwm`. description_bullets: - Only applies to SIGMADELTA (pwm) output type (line 208) - Ignored for DIGITAL, HWPWM, and SWPWM output types - 'The `S` parameter is scaled: `actual_pwm = S * max_pwm / 255` (line 322)' - 'Example: If `max_pwm` is 128, `M106 S255` will output PWM value of 128 (not 255)' - Useful for limiting fan speed or power to devices that don't need full power - Default 255 means no limiting (full range) typical_values: - value: 128 description: 50% max power - value: 192 description: 75% max power - value: 210 description: 82% max power - value: 255 description: full range related_settings: - switch.{name}.output_type - switch.{name}.startup_value related_pages: - switch - mosfets examples: - switch.fan.output_type pwm - 'switch.fan.max_pwm 255 # Full range (no limiting)' - switch.hotend_fan.output_type pwm - 'switch.hotend_fan.max_pwm 128 # Limit to 50% maximum speed' - switch.case_fan.output_type pwm - 'switch.case_fan.max_pwm 210 # Limit to ~82% maximum speed' - name: switch.{name}.pwm_period_ms type: number default: 20 units: ms module: switch context: Module instance setting defined_in: modules/tools/switch/Switch.cpp:218 corresponding_v1: switch.{name}.pwm_period_ms corresponding_v2: '[pwm1] frequency' description: Sets the PWM period in milliseconds for hardware PWM and software PWM outputs. This determines the PWM frequency. For servo control, typical value is 20ms (50Hz). For other applications, different frequencies may be appropriate. description_bullets: - Only applies to HWPWM and SWPWM output types (lines 218, 232) - Ignored for DIGITAL and SIGMADELTA (pwm) output types - 'HWPWM: Period is converted from milliseconds to microseconds (`value * 1000`, line 219)' - 'SWPWM: Period is used directly in milliseconds (line 233), fractional values are not supported' - Lower period = higher frequency = faster PWM switching - 'For servos: Standard is 20ms (50Hz), some servos support 10ms (100Hz)' - 'For LEDs: Higher frequencies (>100Hz) prevent visible flicker' - 'For heaters: Very high frequencies (1-10kHz) for smooth power control' typical_values: - value: 20 description: 50Hz standard servo - value: 10 description: 100Hz faster servo - value: 5 description: 200Hz for LED dimming - value: 1 description: 1kHz - value: 0.1 description: 10kHz for heater control related_settings: - switch.{name}.output_type - switch.{name}.default_on_value related_pages: - switch - pwm-capable - mosfets examples: - switch.servo.output_type hwpwm - 'switch.servo.pwm_period_ms 20 # 50Hz for standard servos' - switch.fast_servo.output_type hwpwm - 'switch.fast_servo.pwm_period_ms 10 # 100Hz for faster response' - switch.led.output_type swpwm - 'switch.led.pwm_period_ms 5 # 200Hz to avoid visible flicker' - switch.heater.output_type hwpwm - 'switch.heater.pwm_period_ms 0.1 # 10kHz for heater control' - name: switch.{name}.failsafe_set_to type: number default: 0 module: switch context: Module instance setting defined_in: modules/tools/switch/Switch.cpp:123 corresponding_v1: switch.{name}.failsafe_set_to corresponding_v2: switch.{name}.failsafe_set_to description: Defines the pin state to set during a crash, watchdog reset, or debug halt condition. This is a safety feature to ensure outputs are in a safe state when the system fails. Also configures the MRI (Monitor for Remote Inspection) debug behavior. description_bullets: - Only applies to output-type switches (not input-pin switches) - Sets the pin state when system crashes, watchdog triggers, or enters debug mode - Configured via MRI hooks (`set_high_on_debug` or `set_low_on_debug`, lines 133, 135, 149, 151, 165, 167, 183, 185) - Different from `halt_set_to` which handles M112 HALT commands - Can be overridden by `ignore_on_halt` setting - 'CRITICAL: Choose value that puts system in safe state for your hardware' related_settings: - switch.{name}.halt_set_to - switch.{name}.ignore_on_halt - switch.{name}.output_pin related_pages: - switch - emergencystop - killbutton examples: - 'switch.fan.failsafe_set_to 0 # Turn fan OFF on crash' - 'switch.estop.failsafe_set_to 1 # Activate estop on crash' - 'switch.psu.failsafe_set_to 0 # Turn PSU OFF on crash' - 'switch.brake.failsafe_set_to 1 # Engage brake on crash' - name: switch.{name}.halt_set_to type: bool default: false module: switch context: Module instance setting defined_in: modules/tools/switch/Switch.cpp:125 corresponding_v1: switch.{name}.halt_set_to corresponding_v2: switch.{name}.halt_set_to description: Defines the switch state to set during a HALT condition (typically triggered by M112 emergency stop or system halt). When a halt occurs, the switch is set to this state unless `ignore_on_halt` is true. description_bullets: - Only applies to output-type switches (not input-pin switches) - Triggered by M112 emergency stop or system halt events (lines 62-77) - For PWM outputs (HWPWM/SWPWM), `startup_value` is used as the actual value (lines 71-72) - For digital outputs, this boolean directly controls the pin state (lines 69-70) - Can be overridden by setting `ignore_on_halt` to `true` - Different from `failsafe_set_to` which handles crash/debug conditions related_m_codes: - code: M112 description: Emergency stop (HALT condition) related_settings: - switch.{name}.startup_value - switch.{name}.failsafe_set_to - switch.{name}.ignore_on_halt related_pages: - switch - emergencystop - stopping-smoothie examples: - 'switch.fan.halt_set_to false # Turn fan OFF on halt' - 'switch.estop.halt_set_to true # Activate estop on halt' - 'switch.psu.halt_set_to false # Turn PSU OFF on halt' - 'switch.brake.halt_set_to true # Engage brake on halt' - name: switch.{name}.ignore_on_halt type: bool default: false module: switch context: Module instance setting defined_in: modules/tools/switch/Switch.cpp:124 corresponding_v1: none (new in later v1 firmware) corresponding_v2: switch.{name}.ignore_on_halt description: When set to `true`, prevents the switch from changing state during HALT conditions (M112 emergency stop). Useful for switches that should maintain their current state during emergency stops rather than being forced to a specific state. description_bullets: - Automatically set to `true` for input-pin switches (line 112, cannot be overridden) - For output switches, defaults to `false` - When `true`, both `halt_set_to` and `failsafe_set_to` are ignored during halt (lines 64-65) - Useful for non-safety-critical outputs (lights, status indicators, etc.) - Safety-critical outputs should use `false` to ensure proper halt behavior related_settings: - switch.{name}.halt_set_to - switch.{name}.failsafe_set_to - switch.{name}.input_pin related_pages: - switch - emergencystop - stopping-smoothie examples: - 'switch.fan.ignore_on_halt false # Fan controlled by halt_set_to' - 'switch.light.ignore_on_halt true # Light stays in current state' - 'switch.estop.ignore_on_halt false # Estop responds to halt' - 'switch.status_led.ignore_on_halt true # LED not affected by halt' - name: Temperature Switch description: Automatic fan and cooling control setting_count: 10 settings: - name: temperatureswitch.{name}.enable type: bool default: false module: temperatureswitch context: Module instance setting (multiple instances can be created) defined_in: modules/tools/temperatureswitch/TemperatureSwitch.cpp:72 corresponding_v1: temperatureswitch.{name}.enable corresponding_v2: temperature switch.{name}.enable description: Creates and enables a new TemperatureSwitch module instance. When set to true, this module will monitor temperature from a specified TemperatureControl module and automatically control a Switch module based on configured thresholds and trigger conditions. description_bullets: - Multiple temperature switch instances can be configured simultaneously by using different instance names. - Each instance requires a unique module name (e.g., hotend, bed, chamber). - Module will not function unless enabled. - Must be accompanied by valid designator and switch configuration. related_settings: - temperatureswitch.{name}.designator - temperatureswitch.{name}.switch - temperature_control.{name}.designator related_pages: - temperatureswitch - temperatureswitch-options - temperaturecontrol - switch examples: - 'temperatureswitch.hotend.enable true # Enable hotend fan control' - 'temperatureswitch.bed.enable true # Enable bed cooling fan' - 'temperatureswitch.chamber.enable true # Enable chamber exhaust control' - name: temperatureswitch.{name}.designator type: string default: '""' module: temperatureswitch context: Module instance setting defined_in: modules/tools/temperatureswitch/TemperatureSwitch.cpp:78 required: false corresponding_v1: temperatureswitch.{name}.designator corresponding_v2: temperature switch.{name}.designator description: Specifies which TemperatureControl module to monitor by matching its designator character. The temperature switch reads the current temperature from the temperature control module with this designator and uses it to determine when to trigger the switch. If multiple temperature control modules share the same designator, the highest temperature among them is used for comparison. description_bullets: - For backward compatibility, `temperatureswitch.hotend` defaults to designator `T` if not specified (deprecated behavior). - Empty designator string causes the temperature switch to be considered invalid and non-functional. - Case-sensitive matching - `T` and `t` are different designators. - The temperature reading is polled at intervals defined by heatup_poll and cooldown_poll settings. related_settings: - temperature_control.{name}.designator - temperatureswitch.{name}.threshold_temp related_pages: - temperatureswitch - temperaturecontrol - temperaturecontrol-options examples: - 'temperatureswitch.hotend.designator T # Monitor hotend temperature' - 'temperatureswitch.bed_fan.designator B # Monitor bed temperature' - 'temperatureswitch.chamber.designator P # Monitor chamber heater' - name: temperatureswitch.{name}.switch type: string default: '""' module: temperatureswitch context: Module instance setting defined_in: modules/tools/temperatureswitch/TemperatureSwitch.cpp:90 required: false deprecated: false corresponding_v1: temperatureswitch.{name}.switch corresponding_v2: temperature switch.{name}.switch description: Specifies the name of the Switch module to be controlled by this temperature switch. When temperature conditions are met, this switch will be toggled on or off according to the configured trigger mode and inversion settings. The switch must be configured and enabled in the switch module settings before it can be controlled. description_bullets: - The specified switch must exist and be properly configured with output_pin and output_type. - Typically controls one of the small MOSFETs on the Smoothieboard. - The deprecated parameter name `type` is checked as fallback if `switch` is not defined (backward compatibility). - Switch state is only changed when armed (either always armed if arm_mcode=0, or manually armed via M-code). related_settings: - switch.{name}.enable - switch.{name}.output_pin - temperatureswitch.{name}.inverted related_pages: - temperatureswitch - switch - switch-options - mosfets examples: - 'temperatureswitch.hotend.switch fan # Control main cooling fan' - 'temperatureswitch.chamber.switch misc # Control chamber exhaust fan' - 'temperatureswitch.bed.switch small_mosfet4 # Control bed cooling fan on small mosfet 4' - name: temperatureswitch.{name}.threshold_temp type: number default: 50 units: °C (degrees Celsius) module: temperatureswitch context: Module instance setting defined_in: modules/tools/temperatureswitch/TemperatureSwitch.cpp:122 corresponding_v1: temperatureswitch.{name}.threshold_temp corresponding_v2: temperature switch.{name}.threshold_temp description: 'Sets the temperature threshold in degrees Celsius at which the switch state changes. The exact behavior depends on the trigger mode: in "level" mode, the switch turns on above this temperature and off below it; in "rising" mode, the switch triggers when crossing upward through this threshold; in "falling" mode, the switch triggers when crossing downward through this threshold.' description_bullets: - 'Temperature comparison uses: `current_temp >= threshold_temp` for HIGH_TEMP state determination (line 162).' - For typical hotend cooling applications, set this 10-20°C below the hotend operating temperature. - Inverted mode reverses the on/off logic but uses the same threshold comparison. - Temperature is read from the highest value among all temperature controllers matching the configured designator. - The threshold applies regardless of whether the switch is inverted or not - inversion only affects the final switch output state. typical_values: - value: 40 description: low-temperature applications - value: 60 description: standard hotend cooling - value: 80 description: high-temperature safety systems related_settings: - temperatureswitch.{name}.designator - temperatureswitch.{name}.trigger - temperatureswitch.{name}.inverted related_pages: - temperatureswitch - temperaturecontrol - temperatureswitch-options examples: - 'temperatureswitch.hotend.threshold_temp 60.0 # Turn on fan at 60°C' - 'temperatureswitch.bed.threshold_temp 50.0 # Lower threshold for bed' - 'temperatureswitch.safety.threshold_temp 80.0 # High-temp safety cutoff' - name: temperatureswitch.{name}.heatup_poll type: number default: 15 units: seconds module: temperatureswitch context: Module instance setting defined_in: modules/tools/temperatureswitch/TemperatureSwitch.cpp:125 corresponding_v1: temperatureswitch.{name}.heatup_poll corresponding_v2: temperature switch.{name}.heatup_poll description: Defines the polling interval in seconds when the system is in the LOW_TEMP state (below threshold temperature). This controls how frequently the temperature is checked while heating up. A shorter interval provides faster response when temperature rises toward the threshold, but increases system overhead. The polling occurs on the second tick event, so actual timing may vary by ±1 second. description_bullets: - Active when current temperature < threshold_temp (LOW_TEMP state). - Faster polling during heatup ensures timely switch activation. - After temperature crosses threshold, automatically switches to cooldown_poll interval. - Initial state uses heatup_poll interval and performs first check immediately (line 131). - Lower values (e.g., 5-10 seconds) provide quicker response but consume more processing time. - Higher values (e.g., 20-30 seconds) reduce overhead but may delay switch activation. typical_values: - value: 10 description: faster response - value: 15 description: default balanced - value: 30 description: slower response, less overhead related_settings: - temperatureswitch.{name}.cooldown_poll - temperatureswitch.{name}.threshold_temp related_pages: - temperatureswitch - temperatureswitch-options examples: - 'temperatureswitch.hotend.heatup_poll 15 # Check every 15 seconds while heating' - 'temperatureswitch.bed.heatup_poll 20 # Slower polling for bed (less critical)' - 'temperatureswitch.safety.heatup_poll 5 # Fast polling for safety applications' - name: temperatureswitch.{name}.cooldown_poll type: number default: 60 units: seconds module: temperatureswitch context: Module instance setting defined_in: modules/tools/temperatureswitch/TemperatureSwitch.cpp:126 corresponding_v1: temperatureswitch.{name}.cooldown_poll corresponding_v2: temperature switch.{name}.cooldown_poll description: Defines the polling interval in seconds when the system is in the HIGH_TEMP state (at or above threshold temperature). This controls how frequently the temperature is checked while at operating temperature or cooling down. A longer interval reduces system overhead during stable high-temperature operation, while still monitoring for temperature drops that should trigger switch state changes. description_bullets: - Active when current temperature >= threshold_temp (HIGH_TEMP state). - Slower polling during stable operation reduces system load. - After temperature falls below threshold, automatically switches to heatup_poll interval. - Suitable for applications where switch should remain on for extended periods. - Polling occurs on the second tick event, so actual timing may vary by ±1 second. - Higher values reduce processing overhead when temperature is stable above threshold. typical_values: - value: 30 description: frequent monitoring - value: 60 description: default balanced - value: 120 description: infrequent monitoring, minimal overhead related_settings: - temperatureswitch.{name}.heatup_poll - temperatureswitch.{name}.threshold_temp related_pages: - temperatureswitch - temperatureswitch-options examples: - 'temperatureswitch.hotend.cooldown_poll 60 # Check every minute when hot' - 'temperatureswitch.bed.cooldown_poll 90 # Less frequent for bed cooling' - 'temperatureswitch.safety.cooldown_poll 30 # More frequent for safety monitoring' - name: temperatureswitch.{name}.trigger type: string default: '"level"' module: temperatureswitch context: Module instance setting defined_in: modules/tools/temperatureswitch/TemperatureSwitch.cpp:111 corresponding_v1: temperatureswitch.{name}.trigger corresponding_v2: temperature switch.{name}.trigger description: Determines the triggering behavior mode of the temperature switch. This setting controls whether the switch responds to sustained temperature levels, rising temperature edges, or falling temperature edges. The mode fundamentally changes how temperature threshold crossings are interpreted and affects the arming behavior. description_bullets: - '**Level mode:** Switch follows temperature state continuously. When armed and temperature >= threshold, switch is on; when temperature < threshold, switch is off. Remains active as long as armed (lines 176-178).' - '**Rising mode:** Switch activates only when transitioning from LOW_TEMP to HIGH_TEMP (edge detection). Requires arming via M-code for each activation cycle (lines 181-183).' - '**Falling mode:** Switch deactivates only when transitioning from HIGH_TEMP to LOW_TEMP (edge detection). Requires arming via M-code for each activation cycle (lines 186-188).' - Edge-triggered modes (rising/falling) automatically disarm after triggering (line 220-222), requiring re-arming for subsequent triggers. - Invalid trigger values default to "level" mode (line 115). - State changes only occur when temperature crosses the threshold boundary, not during stable states. - Works in conjunction with inverted setting - inversion is applied after trigger logic determines switch state. related_settings: - temperatureswitch.{name}.threshold_temp - temperatureswitch.{name}.inverted - temperatureswitch.{name}.arm_mcode related_pages: - temperatureswitch - temperatureswitch-options examples: - 'temperatureswitch.hotend.trigger level # Continuous fan control (most common)' - 'temperatureswitch.exhaust.trigger rising # Turn on exhaust once when temperature rises' - 'temperatureswitch.safety.trigger falling # Alert when temperature drops unexpectedly' - name: temperatureswitch.{name}.inverted type: bool default: false module: temperatureswitch context: Module instance setting defined_in: modules/tools/temperatureswitch/TemperatureSwitch.cpp:108 corresponding_v1: temperatureswitch.{name}.inverted corresponding_v2: temperature switch.{name}.inverted description: Reverses the normal switch control logic. When enabled, the switch turns off when temperature exceeds the threshold (instead of turning on), and turns on when temperature falls below the threshold. This is useful for heaters or devices that should activate during cooling rather than heating. The inversion occurs at the final switch control stage, after all trigger logic has been evaluated. description_bullets: - '**Normal mode (false):** Temperature >= threshold → switch on; temperature < threshold → switch off' - '**Inverted mode (true):** Temperature >= threshold → switch off; temperature < threshold → switch on' - Inversion is applied in set_switch() function after trigger type determines the desired state (line 225). - Works with all trigger modes (level, rising, falling). - Temperature threshold comparison logic remains unchanged; only the final switch output is inverted. - Useful for controlling heating elements that should turn off when target temperature is reached. - 'Common use case: emergency cooling systems that activate when temperature drops too low.' related_settings: - temperatureswitch.{name}.trigger - temperatureswitch.{name}.threshold_temp related_pages: - temperatureswitch - switch examples: - 'temperatureswitch.hotend.inverted false # Normal: fan on when hot' - 'temperatureswitch.heater_control.inverted true # Inverted: heater off when hot' - 'temperatureswitch.emergency_heat.inverted true # Turn on heater when temp drops below threshold' - name: temperatureswitch.{name}.arm_mcode type: number default: 0 module: temperatureswitch context: Module instance setting defined_in: modules/tools/temperatureswitch/TemperatureSwitch.cpp:118 corresponding_v1: temperatureswitch.{name}.arm_mcode corresponding_v2: temperature switch.{name}.arm_mcode description: Defines a custom M-code command that must be executed to arm the temperature switch before it can trigger. This provides manual control over when the temperature switch is active, preventing unwanted switch activation. Setting to 0 disables the arming requirement, making the switch always armed and operating automatically based on temperature. description_bullets: - '**When set to 0:** Switch is always armed and operates automatically (line 133).' - '**When set to M-code:** Switch starts disarmed and requires manual arming via G-code command.' - '**Arming command:** `M S1` arms the switch (e.g., `M1100 S1`) (line 148).' - '**Disarming command:** `M S0` disarms the switch (e.g., `M1100 S0`).' - '**Level trigger mode:** Switch remains armed and continues operating while armed.' - '**Edge trigger modes (rising/falling):** Switch automatically disarms after triggering once (line 220-222), requiring re-arming for subsequent triggers.' - Provides safety mechanism for critical temperature-dependent operations. - Disarmed switches do not control their associated switch modules (line 218). - Module only registers for G-code events if arm_mcode != 0 (line 138-140). related_settings: - temperatureswitch.{name}.trigger - temperatureswitch.{name}.switch related_pages: - temperatureswitch - console-commands - supported-g-codes examples: - 'temperatureswitch.hotend.arm_mcode 0 # Always armed, automatic operation' - 'temperatureswitch.safety.arm_mcode 1100 # Requires M1100 S1 to arm' - 'temperatureswitch.emergency.arm_mcode 1101 # Manual control via M1101' - name: temperatureswitch.{name}.type type: string default: '""' module: temperatureswitch context: Module instance setting defined_in: modules/tools/temperatureswitch/TemperatureSwitch.cpp:93 deprecated: false corresponding_v1: temperatureswitch.{name}.type corresponding_v2: temperature switch.{name}.switch description: Legacy parameter name for specifying the switch module to control. This parameter has been replaced by `temperatureswitch.switch` but is still supported for backward compatibility with older configurations. New configurations should use the `switch` parameter instead. description_bullets: - Only used as fallback if `temperatureswitch.{name}.switch` is not defined (line 91-93). - Maintained for backward compatibility with configurations from older Smoothieware versions. - Functionally identical to `temperatureswitch.{name}.switch` parameter. - Will be checked if switch parameter is empty string. - Not recommended for new configurations - use `switch` parameter for clarity. related_settings: - temperatureswitch.{name}.switch related_pages: - temperatureswitch - switch examples: - '# Deprecated syntax (still works)' - temperatureswitch.hotend.type fan - '# Preferred modern syntax' - temperatureswitch.hotend.switch fan - name: Spindle Module description: Spindle motor control settings setting_count: 20 settings: - name: spindle.enable type: bool default: false module: spindle context: Module setting defined_in: modules/tools/spindle/SpindleMaker.cpp:29 corresponding_v1: spindle.enable corresponding_v2: spindle.enable (via switch module) description: Enables the spindle control module. When true, the spindle module is loaded and available for G-code control (M3/M5 commands). When false, the module is not loaded and its resources are freed. The spindle module supports three different control types (PWM, analog, modbus) for controlling spindle motors, VFDs, and other spindle-related equipment. related_settings: - spindle.type - spindle.ignore_on_halt related_pages: - spindle-control - cnc-mill-guide examples: - 'spindle.enable true # Enable spindle control' - name: spindle.type type: string default: pwm module: spindle context: Module setting defined_in: modules/tools/spindle/SpindleMaker.cpp:37 corresponding_v1: spindle.type corresponding_v2: spindle.output_type (partial - switch module) description: Selects the spindle control mode. PWM mode provides closed-loop PID control with tachometer feedback for precise RPM control. Analog mode provides simple open-loop PWM output for VFDs and ESCs that accept 0-10V or PWM signals. Modbus mode uses RS485 communication to control Modbus-compatible VFDs (currently supports Huanyang VFDs). valid_values: - value: pwm description: Closed-loop PID control with tachometer feedback - value: analog description: Open-loop PWM/analog control for VFDs and ESCs - value: modbus description: RS485 Modbus control for compatible VFDs related_settings: - spindle.vfd_type - spindle.pwm_pin examples: - 'spindle.type pwm # PID control with feedback' - 'spindle.type analog # Simple VFD control' - 'spindle.type modbus # RS485 VFD control' - name: spindle.ignore_on_halt type: bool default: false module: spindle context: Module setting defined_in: modules/tools/spindle/SpindleMaker.cpp:61 corresponding_v1: spindle.ignore_on_halt corresponding_v2: spindle.ignore_on_halt (via switch module) description: Controls whether the spindle stops when the system halts (emergency stop, limit switch trigger, etc.). When false (default and recommended), the spindle will stop immediately on any halt condition for safety. When true, the spindle continues running during halts. This is a safety-critical setting and should only be enabled in very specific situations where continuous spindle operation during halt is absolutely required. related_settings: - spindle.enable examples: - 'spindle.ignore_on_halt false # Stop spindle on halt (safe default)' - name: spindle.pwm_pin type: pin default: nc module: spindle context: Module setting defined_in: modules/tools/spindle/PWMSpindleControl.cpp:71 corresponding_v1: spindle.pwm_pin corresponding_v2: spindle.output_pin (via switch module) description: PWM output pin for spindle control. Must be a hardware PWM-capable pin (P2.0-P2.5 on Smoothieboard). Used by both PWM and analog spindle types. The PWM signal controls spindle speed either directly (for PWM-capable spindles) or through a VFD's analog input. Pin can be inverted using ! suffix. related_settings: - spindle.type - spindle.pwm_period - spindle.max_pwm related_pages: - pinout examples: - 'spindle.pwm_pin 2.4 # PWM output on P2.4' - 'spindle.pwm_pin 2.5! # Inverted PWM on P2.5' - name: spindle.pwm_period type: number default: 1000 units: microseconds module: spindle context: Module setting defined_in: modules/tools/spindle/PWMSpindleControl.cpp:86 corresponding_v1: spindle.pwm_period corresponding_v2: pwm1.frequency or pwm2.frequency description: PWM period in microseconds, which determines PWM frequency. Frequency = 1,000,000 / pwm_period. Most VFDs and spindle controllers work with 1-50 kHz (20-1000 microseconds). Default 1000µs = 1kHz. Some VFDs require specific frequencies - check your VFD documentation. typical_values: - value: 1000 description: 1 kHz (default, most VFDs) - value: 100 description: 10 kHz (some modern VFDs) - value: 50000 description: 20 Hz (some ESCs) related_settings: - spindle.pwm_pin examples: - 'spindle.pwm_period 1000 # 1 kHz PWM' - name: spindle.max_pwm type: number default: 1.0 module: spindle context: Module setting defined_in: modules/tools/spindle/PWMSpindleControl.cpp:84 corresponding_v1: spindle.max_pwm corresponding_v2: spindle.max_pwm (via switch module) description: Maximum PWM duty cycle as a fraction (0.0-1.0). Acts as both a safety limit and calibration factor. Some spindle controllers (like MC2100) require less than 100% duty cycle for maximum speed (MC2100 uses 0.85 for max speed). Setting below 1.0 limits maximum spindle speed even when G-code requests full power. typical_values: - value: 1.0 description: 100% duty cycle (most spindles) - value: 0.85 description: 85% for MC2100 controllers related_settings: - spindle.pwm_pin examples: - 'spindle.max_pwm 0.85 # MC2100 controller' - name: spindle.feedback_pin type: pin default: nc module: spindle context: PWM spindle type only defined_in: modules/tools/spindle/PWMSpindleControl.cpp:93 corresponding_v1: spindle.feedback_pin corresponding_v2: none (not available in v2) description: Tachometer input pin for closed-loop RPM control (PWM spindle type only). Must be an interrupt-capable pin on Port 0 or Port 2. Receives pulses from a hall-effect sensor, optical encoder, or other tachometer. Used with PID controller to maintain precise RPM. Not required for analog or modbus spindle types. related_settings: - spindle.type - spindle.pulses_per_rev - spindle.control_P - spindle.control_I - spindle.control_D examples: - 'spindle.feedback_pin 0.22 # Tach input on P0.22' - name: spindle.pulses_per_rev type: number default: 1.0 module: spindle context: PWM spindle type only defined_in: modules/tools/spindle/PWMSpindleControl.cpp:55 corresponding_v1: spindle.pulses_per_rev corresponding_v2: none (not available in v2) description: Number of tachometer pulses per spindle revolution. Used to calculate actual RPM from tachometer feedback. Hall-effect sensors typically provide 1 pulse per revolution, while optical encoders may provide many pulses per revolution. Essential for accurate RPM calculation in closed-loop PWM mode. typical_values: - value: 1.0 description: Single hall-effect sensor - value: 2.0 description: Two hall sensors or 2-slot optical disk - value: 12.0 description: 12-slot optical encoder related_settings: - spindle.feedback_pin examples: - 'spindle.pulses_per_rev 1.0 # Single hall sensor' - name: spindle.default_rpm type: number default: 5000 units: RPM module: spindle context: PWM spindle type only defined_in: modules/tools/spindle/PWMSpindleControl.cpp:56 corresponding_v1: spindle.default_rpm corresponding_v2: none (not available in v2) description: Default RPM value used when M3 is issued without an S parameter. If G-code contains "M3" without specifying speed, this RPM will be used. Only applies to PWM spindle type with feedback control. related_settings: - spindle.feedback_pin examples: - 'spindle.default_rpm 5000 # 5000 RPM default' - name: spindle.control_P type: number default: 0.0001 module: spindle context: PWM spindle type only defined_in: modules/tools/spindle/PWMSpindleControl.cpp:57 corresponding_v1: spindle.control_P corresponding_v2: none (not available in v2) description: Proportional term for the PID controller in closed-loop PWM spindle mode. Controls how aggressively the controller responds to RPM error. Higher values provide faster response but may cause oscillation. Lower values provide smoother operation but slower response. Requires tuning for your specific spindle and mechanical setup. related_settings: - spindle.control_I - spindle.control_D - spindle.feedback_pin examples: - 'spindle.control_P 0.0001 # Conservative starting point' - name: spindle.control_I type: number default: 0.0001 module: spindle context: PWM spindle type only defined_in: modules/tools/spindle/PWMSpindleControl.cpp:58 corresponding_v1: spindle.control_I corresponding_v2: none (not available in v2) description: Integral term for the PID controller in closed-loop PWM spindle mode. Eliminates steady-state error by accumulating error over time. Higher values eliminate offset faster but may cause overshoot. Set too high and system becomes unstable. Requires tuning for your specific spindle. related_settings: - spindle.control_P - spindle.control_D - spindle.feedback_pin examples: - 'spindle.control_I 0.0001 # Conservative starting point' - name: spindle.control_D type: number default: 0.0001 module: spindle context: PWM spindle type only defined_in: modules/tools/spindle/PWMSpindleControl.cpp:59 corresponding_v1: spindle.control_D corresponding_v2: none (not available in v2) description: Derivative term for the PID controller in closed-loop PWM spindle mode. Responds to rate of change of error, providing damping to reduce overshoot and oscillation. Higher values provide more damping but may slow response and amplify noise. Often set lower than P and I terms. related_settings: - spindle.control_P - spindle.control_I - spindle.feedback_pin examples: - 'spindle.control_D 0.0001 # Conservative starting point' - name: spindle.control_smoothing type: number default: 0.1 units: seconds module: spindle context: PWM spindle type only defined_in: modules/tools/spindle/PWMSpindleControl.cpp:62 corresponding_v1: spindle.control_smoothing corresponding_v2: none (not available in v2) description: Low-pass filter time constant in seconds for smoothing tachometer readings. Filters out noise and transient fluctuations in the RPM measurement. Higher values provide more smoothing but slower response to actual speed changes. Lower values provide faster response but may amplify tachometer noise. Default 0.1 seconds is suitable for most applications. related_settings: - spindle.feedback_pin - spindle.pulses_per_rev examples: - 'spindle.control_smoothing 0.1 # 100ms smoothing' - name: spindle.min_rpm type: number default: 100 units: RPM module: spindle context: Analog spindle type only defined_in: modules/tools/spindle/AnalogSpindleControl.cpp:30 corresponding_v1: spindle.min_rpm corresponding_v2: none (not directly available in v2) description: Minimum RPM when spindle is enabled (analog spindle type only). When spindle is turned on, speed cannot go below this value. This prevents stalling and ensures minimum cutting speed. If G-code requests speed below min_rpm, this minimum will be used instead. VFDs typically have minimum frequency requirements. related_settings: - spindle.max_rpm - spindle.type examples: - 'spindle.min_rpm 100 # Minimum 100 RPM' - name: spindle.max_rpm type: number default: 5000 units: RPM module: spindle context: Analog spindle type only defined_in: modules/tools/spindle/AnalogSpindleControl.cpp:31 corresponding_v1: spindle.max_rpm corresponding_v2: none (not directly available in v2) description: Maximum RPM at 100% PWM duty cycle (analog spindle type only). This calibrates the PWM output to match your spindle's maximum speed. For example, if your VFD is configured for 24000 RPM maximum and you request 12000 RPM (S12000), the system will output 50% PWM. Essential for accurate speed control with VFDs and ESCs. related_settings: - spindle.min_rpm - spindle.type examples: - 'spindle.max_rpm 24000 # 24000 RPM at 100% PWM' - name: spindle.switch_on_pin type: pin default: nc module: spindle context: Analog spindle type only defined_in: modules/tools/spindle/AnalogSpindleControl.cpp:56 corresponding_v1: spindle.switch_on_pin corresponding_v2: none (can use separate switch in v2) description: Optional digital output pin to enable/disable the VFD or spindle power supply (analog spindle type only). Typically connected to VFD's RUN/ENABLE input via optocoupler. Goes high when spindle is commanded on (M3), low when commanded off (M5). Provides hardware enable signal separate from the PWM speed control. related_settings: - spindle.type - spindle.pwm_pin examples: - 'spindle.switch_on_pin 2.6 # VFD enable on P2.6' - name: spindle.vfd_type type: string default: none module: spindle context: Modbus spindle type only defined_in: modules/tools/spindle/SpindleMaker.cpp:38 corresponding_v1: spindle.vfd_type corresponding_v2: none (not available in v2) description: VFD manufacturer/model when using modbus spindle type. Currently only supports "huanyang" VFDs. Determines the Modbus protocol and register mapping used for communication. Huanyang VFDs must be configured for RS485 control (PD001=2, PD002=2) before use. valid_values: - value: huanyang description: Huanyang VFD (RS485 Modbus RTU) - value: none description: No VFD (default) related_settings: - spindle.type - spindle.rx_pin - spindle.tx_pin - spindle.dir_pin examples: - 'spindle.vfd_type huanyang # Huanyang VFD' - name: spindle.rx_pin type: pin default: nc module: spindle context: Modbus spindle type only defined_in: modules/tools/spindle/ModbusSpindleControl.cpp:33 corresponding_v1: spindle.rx_pin corresponding_v2: none (not available in v2) description: RX (receive) pin for RS485 soft serial communication (modbus spindle type only). Used with TX and DIR pins to communicate with Modbus VFDs. Requires RS485 transceiver chip (MAX485 or similar) between Smoothieboard and VFD. This pin receives data from the VFD. related_settings: - spindle.tx_pin - spindle.dir_pin - spindle.vfd_type examples: - 'spindle.rx_pin 2.6 # RS485 RX on P2.6' - name: spindle.tx_pin type: pin default: nc module: spindle context: Modbus spindle type only defined_in: modules/tools/spindle/ModbusSpindleControl.cpp:37 corresponding_v1: spindle.tx_pin corresponding_v2: none (not available in v2) description: TX (transmit) pin for RS485 soft serial communication (modbus spindle type only). Used with RX and DIR pins to communicate with Modbus VFDs. Requires RS485 transceiver chip. This pin sends data to the VFD. related_settings: - spindle.rx_pin - spindle.dir_pin - spindle.vfd_type examples: - 'spindle.tx_pin 2.4 # RS485 TX on P2.4' - name: spindle.dir_pin type: pin default: nc module: spindle context: Modbus spindle type only defined_in: modules/tools/spindle/ModbusSpindleControl.cpp:41 corresponding_v1: spindle.dir_pin corresponding_v2: none (not available in v2) description: Direction control pin for RS485 transceiver (modbus spindle type only). RS485 is half-duplex, so a single pair of wires is used for both sending and receiving. This pin switches the RS485 transceiver between transmit and receive modes. Typically connected to DE/RE pins on MAX485 chip. related_settings: - spindle.rx_pin - spindle.tx_pin - spindle.vfd_type examples: - 'spindle.dir_pin 2.5 # RS485 direction control on P2.5' - name: Endstops description: Homing and limit switch configuration setting_count: 104 settings: - name: endstop.maxx.axis type: string default: '""' module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:259 required: false corresponding_v1: alpha_* corresponding_v2: endstops.maxx.axis description: 'Which axis this endstop is associated with. Must be one of: X, Y, Z, A, B, or C.' description_bullets: - This is required for each endstop - Multiple endstops can be assigned to the same axis (e.g., min and max) - The axis letter determines which motor/actuator is affected by this endstop - X, Y, Z are the primary Cartesian axes - A, B, C are additional rotary or linear axes (requires more than 3 actuators configured) - If the axis index exceeds the number of configured motors, configuration will fail related_settings: - endstop.maxx.enable - endstop.maxx.homing_direction related_pages: - endstops - endstops-options - 6axis examples: - endstop.minx.axis X - endstop.miny.axis Y - endstop.minz.axis Z - 'endstop.a_home.axis A # For 4-axis machine' - name: endstop.maxx.enable type: bool default: false module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:249 required: false corresponding_v1: Implicit in root-level config (endstop exists if pin defined) corresponding_v2: endstops.maxx.enable description: Enable this specific endstop instance. Each endstop must be individually enabled. description_bullets: - When `false` or omitted, this endstop instance is ignored - When `true`, the endstop is active and its pin is monitored - Multiple endstops can be enabled for the same axis (e.g., both min and max) - All other settings for this endstop are ignored if enable is `false` related_settings: - endstop.maxx.pin - endstop.maxx.axis related_pages: - endstops - endstops-options - guide-endstops examples: - endstop.minx.enable true - endstop.miny.enable true - endstop.minz.enable true - 'endstop.maxx.enable false # Disabled, not used' - name: endstop.maxx.fast_rate type: number default: 100 units: mm/s module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:319 corresponding_v1: alpha_fast_homing_rate_mm_s corresponding_v2: endstops.maxx.fast_rate description: Fast homing speed for this axis. Equivalent to `_fast_homing_rate_mm_s` in root-level config. description_bullets: - Speed at which axis moves during initial fast approach to endstop - Higher speeds reduce homing time - Lower speeds may be needed for mechanical reasons or safety - Z-axis typically uses slower rates (4-10 mm/s) for safety - Deltas should use same rate for all three towers typical_values: - value: 100 description: standard - value: 50 description: delta - value: 10 description: Z-axis - value: 150 description: fast XY related_settings: - endstop.maxx.slow_rate - endstop.maxx.retract - endstop.maxx.max_travel related_pages: - endstops - endstops-options - guide-endstops examples: - endstop.minx.fast_rate 100 - endstop.miny.fast_rate 100 - 'endstop.minz.fast_rate 10 # Slower for Z safety' - name: endstop.maxx.homing_direction type: string default: null module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:303 corresponding_v1: alpha_homing_direction corresponding_v2: endstops.maxx.homing_direction description: Determines if and how this endstop is used for homing. description_bullets: - '`home_to_min` - This endstop is used when homing in the negative direction' - '`home_to_max` - This endstop is used when homing in the positive direction' - '`none` - This endstop is NOT used for homing (limit switch only)' - Setting to `none` allows an endstop to be used only for limit detection, not homing - This provides more flexibility than root-level config which can't disable homing for an endstop - Multiple endstops on the same axis can have different homing directions (e.g., min and max) related_settings: - endstop.maxx.homing_position - endstop.maxx.axis - endstop.maxx.limit_enable related_pages: - endstops - endstops-options - guide-endstops examples: - endstop.minx.homing_direction home_to_min - endstop.miny.homing_direction home_to_min - 'endstop.maxx.homing_direction none # Limit only, not for homing' - name: endstop.maxx.homing_position type: number default: 0 units: mm module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:329 corresponding_v1: alpha_min corresponding_v2: endstops.maxx.homing_position description: Position to set the axis to when this endstop is triggered during homing. Equivalent to `_min` or `_max` in root-level config. description_bullets: - This defines the cartesian coordinate of the endstop in your workspace - Default is 0 for minimum endstops, 200 for maximum endstops - After homing, M206 home offset is added to this value - Only used if `homing_direction` is `home_to_min` or `home_to_max` (not `none`) - For bed-center-origin machines, minimum values may be negative - For Z-max homing, this typically represents the total build height typical_values: - value: 0 description: origin at min - value: 200 description: typical max height - value: -100 description: bed-center origin related_m_codes: - code: M206 description: Set home offset (added to this value) - code: M500 description: Save offsets to config-override related_settings: - endstop.maxx.homing_direction - endstop.maxx.axis related_pages: - endstops - endstops-options - gamma-max examples: - endstop.minx.homing_position 0 - endstop.minz.homing_position 0 - 'endstop.maxz.homing_position 200 # For Z-max homing (200mm build height)' - name: endstop.maxx.limit_enable type: bool default: false module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:296 corresponding_v1: alpha_limit_enable corresponding_v2: endstops.maxx.limit_enable description: Enable hard limit switch monitoring for this endstop during normal operation. Equivalent to `_limit_enable` in root-level config. description_bullets: - When `false` (default), endstop only used during homing - When `true`, endstop acts as hard limit during all moves - 'If triggered during operation: Machine halts, enters ALARM state' - Both min and max endstops can have limit checking enabled independently - More common on CNC machines than 3D printers - 'WARNING: With limits enabled, cannot move off endstop until cleared' related_settings: - endstop.maxx.pin - endstop_debounce_count related_pages: - endstops - endstops-options - emergencystop examples: - endstop.minx.limit_enable true - 'endstop.maxx.limit_enable true # Both min and max as limits' - name: endstop.maxx.max_travel type: number default: 500 units: mm module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:332 corresponding_v1: alpha_max_travel corresponding_v2: endstops.maxx.max_travel description: Maximum distance to travel while searching for endstop. Equivalent to `_max_travel` in root-level config. description_bullets: - Safety limit to prevent indefinite homing if endstop fails - If endstop not triggered within this distance, homing fails with ALARM - 'CRITICAL: Set larger than actual machine travel distance' - 'Failure produces error: "check the max_travel settings"' typical_values: - value: 300 description: small printer - value: 500 description: medium - value: 1000 description: large CNC related_settings: - endstop.maxx.fast_rate - endstop.maxx.axis related_pages: - endstops - endstops-options - guide-endstops examples: - endstop.minx.max_travel 500 - endstop.miny.max_travel 500 - endstop.minz.max_travel 300 - name: endstop.maxx.pin type: pin default: nc module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:252 corresponding_v1: alpha_min_endstop corresponding_v2: endstops.maxx.pin description: Pin assignment for this endstop. Supports the same pin modifiers as root-level configuration (`^` for pull-up, `!` for inverted). description_bullets: - The pin is configured as an input - Pull-up (`^`) is typically enabled for mechanical switches - Inverted (`!`) is used when switch pulls pin low when triggered - If pin is `nc` or not connected, the endstop is disabled even if enable is true related_settings: - endstop.maxx.enable - endstop.maxx.axis related_pages: - endstops - pin-configuration - pinout examples: - endstop.minx.pin 1.28^ - 'endstop.miny.pin 1.26^! # Pull-up and inverted' - endstop.minz.pin 1.24^ - name: endstop.maxx.retract type: number default: 5 units: mm module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:323 corresponding_v1: alpha_homing_retract_mm corresponding_v2: endstops.maxx.retract description: Distance to retract after fast homing before slow approach. Equivalent to `_homing_retract_mm` in root-level config. description_bullets: - Distance to back away from endstop after fast trigger - Must be large enough to fully release the endstop switch - During slow approach, moves `retract * 2` distance to ensure re-trigger - Larger values increase homing time slightly but improve reliability - Z-axis often uses smaller values (1-3 mm) to minimize travel - 'Typical range: 1-10 mm' typical_values: - value: 5 description: standard - value: 2 description: Z-axis minimal - value: 10 description: extra clearance - value: 3 description: balanced related_settings: - endstop.maxx.fast_rate - endstop.maxx.slow_rate related_pages: - endstops - endstops-options - guide-endstops examples: - endstop.minx.retract 5 - endstop.miny.retract 5 - 'endstop.minz.retract 2 # Smaller retract for Z safety' - name: endstop.maxx.slow_rate type: number default: 10 units: mm/s module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:320 corresponding_v1: alpha_slow_homing_rate_mm_s corresponding_v2: endstops.maxx.slow_rate description: Slow precision homing speed for this axis. Equivalent to `_slow_homing_rate_mm_s` in root-level config. description_bullets: - Speed at which axis moves during second, precise approach to endstop - Slower speeds provide better accuracy and repeatability - This determines final homing precision - Z-axis often uses 1-5 mm/s for maximum precision - 'Typical range: 2-25 mm/s' typical_values: - value: 10 description: standard - value: 2 description: high precision Z - value: 20 description: faster - value: 5 description: balanced related_settings: - endstop.maxx.fast_rate - endstop.maxx.retract related_pages: - endstops - endstops-options - guide-endstops examples: - endstop.minx.slow_rate 10 - endstop.miny.slow_rate 10 - 'endstop.minz.slow_rate 2 # Very slow for Z precision' - name: endstop.maxy.axis type: string default: '""' module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:259 required: false corresponding_v1: alpha_* corresponding_v2: endstops.maxy.axis description: 'Which axis this endstop is associated with. Must be one of: X, Y, Z, A, B, or C.' description_bullets: - This is required for each endstop - Multiple endstops can be assigned to the same axis (e.g., min and max) - The axis letter determines which motor/actuator is affected by this endstop - X, Y, Z are the primary Cartesian axes - A, B, C are additional rotary or linear axes (requires more than 3 actuators configured) - If the axis index exceeds the number of configured motors, configuration will fail related_settings: - endstop.maxy.enable - endstop.maxy.homing_direction related_pages: - endstops - endstops-options - 6axis examples: - endstop.minx.axis X - endstop.miny.axis Y - endstop.minz.axis Z - 'endstop.a_home.axis A # For 4-axis machine' - name: endstop.maxy.enable type: bool default: false module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:249 required: false corresponding_v1: Implicit in root-level config (endstop exists if pin defined) corresponding_v2: endstops.maxy.enable description: Enable this specific endstop instance. Each endstop must be individually enabled. description_bullets: - When `false` or omitted, this endstop instance is ignored - When `true`, the endstop is active and its pin is monitored - Multiple endstops can be enabled for the same axis (e.g., both min and max) - All other settings for this endstop are ignored if enable is `false` related_settings: - endstop.maxy.pin - endstop.maxy.axis related_pages: - endstops - endstops-options - guide-endstops examples: - endstop.minx.enable true - endstop.miny.enable true - endstop.minz.enable true - 'endstop.maxx.enable false # Disabled, not used' - name: endstop.maxy.fast_rate type: number default: 100 units: mm/s module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:319 corresponding_v1: alpha_fast_homing_rate_mm_s corresponding_v2: endstops.maxy.fast_rate description: Fast homing speed for this axis. Equivalent to `_fast_homing_rate_mm_s` in root-level config. description_bullets: - Speed at which axis moves during initial fast approach to endstop - Higher speeds reduce homing time - Lower speeds may be needed for mechanical reasons or safety - Z-axis typically uses slower rates (4-10 mm/s) for safety - Deltas should use same rate for all three towers typical_values: - value: 100 description: standard - value: 50 description: delta - value: 10 description: Z-axis - value: 150 description: fast XY related_settings: - endstop.maxy.slow_rate - endstop.maxy.retract - endstop.maxy.max_travel related_pages: - endstops - endstops-options - guide-endstops examples: - endstop.minx.fast_rate 100 - endstop.miny.fast_rate 100 - 'endstop.minz.fast_rate 10 # Slower for Z safety' - name: endstop.maxy.homing_direction type: string default: null module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:303 corresponding_v1: alpha_homing_direction corresponding_v2: endstops.maxy.homing_direction description: Determines if and how this endstop is used for homing. description_bullets: - '`home_to_min` - This endstop is used when homing in the negative direction' - '`home_to_max` - This endstop is used when homing in the positive direction' - '`none` - This endstop is NOT used for homing (limit switch only)' - Setting to `none` allows an endstop to be used only for limit detection, not homing - This provides more flexibility than root-level config which can't disable homing for an endstop - Multiple endstops on the same axis can have different homing directions (e.g., min and max) related_settings: - endstop.maxy.homing_position - endstop.maxy.axis - endstop.maxy.limit_enable related_pages: - endstops - endstops-options - guide-endstops examples: - endstop.minx.homing_direction home_to_min - endstop.miny.homing_direction home_to_min - 'endstop.maxx.homing_direction none # Limit only, not for homing' - name: endstop.maxy.homing_position type: number default: 0 units: mm module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:329 corresponding_v1: alpha_min corresponding_v2: endstops.maxy.homing_position description: Position to set the axis to when this endstop is triggered during homing. Equivalent to `_min` or `_max` in root-level config. description_bullets: - This defines the cartesian coordinate of the endstop in your workspace - Default is 0 for minimum endstops, 200 for maximum endstops - After homing, M206 home offset is added to this value - Only used if `homing_direction` is `home_to_min` or `home_to_max` (not `none`) - For bed-center-origin machines, minimum values may be negative - For Z-max homing, this typically represents the total build height typical_values: - value: 0 description: origin at min - value: 200 description: typical max height - value: -100 description: bed-center origin related_m_codes: - code: M206 description: Set home offset (added to this value) - code: M500 description: Save offsets to config-override related_settings: - endstop.maxy.homing_direction - endstop.maxy.axis related_pages: - endstops - endstops-options - gamma-max examples: - endstop.minx.homing_position 0 - endstop.minz.homing_position 0 - 'endstop.maxz.homing_position 200 # For Z-max homing (200mm build height)' - name: endstop.maxy.limit_enable type: bool default: false module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:296 corresponding_v1: alpha_limit_enable corresponding_v2: endstops.maxy.limit_enable description: Enable hard limit switch monitoring for this endstop during normal operation. Equivalent to `_limit_enable` in root-level config. description_bullets: - When `false` (default), endstop only used during homing - When `true`, endstop acts as hard limit during all moves - 'If triggered during operation: Machine halts, enters ALARM state' - Both min and max endstops can have limit checking enabled independently - More common on CNC machines than 3D printers - 'WARNING: With limits enabled, cannot move off endstop until cleared' related_settings: - endstop.maxy.pin - endstop_debounce_count related_pages: - endstops - endstops-options - emergencystop examples: - endstop.minx.limit_enable true - 'endstop.maxx.limit_enable true # Both min and max as limits' - name: endstop.maxy.max_travel type: number default: 500 units: mm module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:332 corresponding_v1: alpha_max_travel corresponding_v2: endstops.maxy.max_travel description: Maximum distance to travel while searching for endstop. Equivalent to `_max_travel` in root-level config. description_bullets: - Safety limit to prevent indefinite homing if endstop fails - If endstop not triggered within this distance, homing fails with ALARM - 'CRITICAL: Set larger than actual machine travel distance' - 'Failure produces error: "check the max_travel settings"' typical_values: - value: 300 description: small printer - value: 500 description: medium - value: 1000 description: large CNC related_settings: - endstop.maxy.fast_rate - endstop.maxy.axis related_pages: - endstops - endstops-options - guide-endstops examples: - endstop.minx.max_travel 500 - endstop.miny.max_travel 500 - endstop.minz.max_travel 300 - name: endstop.maxy.pin type: pin default: nc module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:252 corresponding_v1: alpha_min_endstop corresponding_v2: endstops.maxy.pin description: Pin assignment for this endstop. Supports the same pin modifiers as root-level configuration (`^` for pull-up, `!` for inverted). description_bullets: - The pin is configured as an input - Pull-up (`^`) is typically enabled for mechanical switches - Inverted (`!`) is used when switch pulls pin low when triggered - If pin is `nc` or not connected, the endstop is disabled even if enable is true related_settings: - endstop.maxy.enable - endstop.maxy.axis related_pages: - endstops - pin-configuration - pinout examples: - endstop.minx.pin 1.28^ - 'endstop.miny.pin 1.26^! # Pull-up and inverted' - endstop.minz.pin 1.24^ - name: endstop.maxy.retract type: number default: 5 units: mm module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:323 corresponding_v1: alpha_homing_retract_mm corresponding_v2: endstops.maxy.retract description: Distance to retract after fast homing before slow approach. Equivalent to `_homing_retract_mm` in root-level config. description_bullets: - Distance to back away from endstop after fast trigger - Must be large enough to fully release the endstop switch - During slow approach, moves `retract * 2` distance to ensure re-trigger - Larger values increase homing time slightly but improve reliability - Z-axis often uses smaller values (1-3 mm) to minimize travel - 'Typical range: 1-10 mm' typical_values: - value: 5 description: standard - value: 2 description: Z-axis minimal - value: 10 description: extra clearance - value: 3 description: balanced related_settings: - endstop.maxy.fast_rate - endstop.maxy.slow_rate related_pages: - endstops - endstops-options - guide-endstops examples: - endstop.minx.retract 5 - endstop.miny.retract 5 - 'endstop.minz.retract 2 # Smaller retract for Z safety' - name: endstop.maxy.slow_rate type: number default: 10 units: mm/s module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:320 corresponding_v1: alpha_slow_homing_rate_mm_s corresponding_v2: endstops.maxy.slow_rate description: Slow precision homing speed for this axis. Equivalent to `_slow_homing_rate_mm_s` in root-level config. description_bullets: - Speed at which axis moves during second, precise approach to endstop - Slower speeds provide better accuracy and repeatability - This determines final homing precision - Z-axis often uses 1-5 mm/s for maximum precision - 'Typical range: 2-25 mm/s' typical_values: - value: 10 description: standard - value: 2 description: high precision Z - value: 20 description: faster - value: 5 description: balanced related_settings: - endstop.maxy.fast_rate - endstop.maxy.retract related_pages: - endstops - endstops-options - guide-endstops examples: - endstop.minx.slow_rate 10 - endstop.miny.slow_rate 10 - 'endstop.minz.slow_rate 2 # Very slow for Z precision' - name: endstop.maxz.axis type: string default: '""' module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:259 required: false corresponding_v1: alpha_* corresponding_v2: endstops.maxz.axis description: 'Which axis this endstop is associated with. Must be one of: X, Y, Z, A, B, or C.' description_bullets: - This is required for each endstop - Multiple endstops can be assigned to the same axis (e.g., min and max) - The axis letter determines which motor/actuator is affected by this endstop - X, Y, Z are the primary Cartesian axes - A, B, C are additional rotary or linear axes (requires more than 3 actuators configured) - If the axis index exceeds the number of configured motors, configuration will fail related_settings: - endstop.maxz.enable - endstop.maxz.homing_direction related_pages: - endstops - endstops-options - 6axis examples: - endstop.minx.axis X - endstop.miny.axis Y - endstop.minz.axis Z - 'endstop.a_home.axis A # For 4-axis machine' - name: endstop.maxz.enable type: bool default: false module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:249 required: false corresponding_v1: Implicit in root-level config (endstop exists if pin defined) corresponding_v2: endstops.maxz.enable description: Enable this specific endstop instance. Each endstop must be individually enabled. description_bullets: - When `false` or omitted, this endstop instance is ignored - When `true`, the endstop is active and its pin is monitored - Multiple endstops can be enabled for the same axis (e.g., both min and max) - All other settings for this endstop are ignored if enable is `false` related_settings: - endstop.maxz.pin - endstop.maxz.axis related_pages: - endstops - endstops-options - guide-endstops examples: - endstop.minx.enable true - endstop.miny.enable true - endstop.minz.enable true - 'endstop.maxx.enable false # Disabled, not used' - name: endstop.maxz.fast_rate type: number default: 100 units: mm/s module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:319 corresponding_v1: alpha_fast_homing_rate_mm_s corresponding_v2: endstops.maxz.fast_rate description: Fast homing speed for this axis. Equivalent to `_fast_homing_rate_mm_s` in root-level config. description_bullets: - Speed at which axis moves during initial fast approach to endstop - Higher speeds reduce homing time - Lower speeds may be needed for mechanical reasons or safety - Z-axis typically uses slower rates (4-10 mm/s) for safety - Deltas should use same rate for all three towers typical_values: - value: 100 description: standard - value: 50 description: delta - value: 10 description: Z-axis - value: 150 description: fast XY related_settings: - endstop.maxz.slow_rate - endstop.maxz.retract - endstop.maxz.max_travel related_pages: - endstops - endstops-options - guide-endstops examples: - endstop.minx.fast_rate 100 - endstop.miny.fast_rate 100 - 'endstop.minz.fast_rate 10 # Slower for Z safety' - name: endstop.maxz.homing_direction type: string default: null module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:303 corresponding_v1: alpha_homing_direction corresponding_v2: endstops.maxz.homing_direction description: Determines if and how this endstop is used for homing. description_bullets: - '`home_to_min` - This endstop is used when homing in the negative direction' - '`home_to_max` - This endstop is used when homing in the positive direction' - '`none` - This endstop is NOT used for homing (limit switch only)' - Setting to `none` allows an endstop to be used only for limit detection, not homing - This provides more flexibility than root-level config which can't disable homing for an endstop - Multiple endstops on the same axis can have different homing directions (e.g., min and max) related_settings: - endstop.maxz.homing_position - endstop.maxz.axis - endstop.maxz.limit_enable related_pages: - endstops - endstops-options - guide-endstops examples: - endstop.minx.homing_direction home_to_min - endstop.miny.homing_direction home_to_min - 'endstop.maxx.homing_direction none # Limit only, not for homing' - name: endstop.maxz.homing_position type: number default: 0 units: mm module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:329 corresponding_v1: alpha_min corresponding_v2: endstops.maxz.homing_position description: Position to set the axis to when this endstop is triggered during homing. Equivalent to `_min` or `_max` in root-level config. description_bullets: - This defines the cartesian coordinate of the endstop in your workspace - Default is 0 for minimum endstops, 200 for maximum endstops - After homing, M206 home offset is added to this value - Only used if `homing_direction` is `home_to_min` or `home_to_max` (not `none`) - For bed-center-origin machines, minimum values may be negative - For Z-max homing, this typically represents the total build height typical_values: - value: 0 description: origin at min - value: 200 description: typical max height - value: -100 description: bed-center origin related_m_codes: - code: M206 description: Set home offset (added to this value) - code: M500 description: Save offsets to config-override related_settings: - endstop.maxz.homing_direction - endstop.maxz.axis related_pages: - endstops - endstops-options - gamma-max examples: - endstop.minx.homing_position 0 - endstop.minz.homing_position 0 - 'endstop.maxz.homing_position 200 # For Z-max homing (200mm build height)' - name: endstop.maxz.limit_enable type: bool default: false module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:296 corresponding_v1: alpha_limit_enable corresponding_v2: endstops.maxz.limit_enable description: Enable hard limit switch monitoring for this endstop during normal operation. Equivalent to `_limit_enable` in root-level config. description_bullets: - When `false` (default), endstop only used during homing - When `true`, endstop acts as hard limit during all moves - 'If triggered during operation: Machine halts, enters ALARM state' - Both min and max endstops can have limit checking enabled independently - More common on CNC machines than 3D printers - 'WARNING: With limits enabled, cannot move off endstop until cleared' related_settings: - endstop.maxz.pin - endstop_debounce_count related_pages: - endstops - endstops-options - emergencystop examples: - endstop.minx.limit_enable true - 'endstop.maxx.limit_enable true # Both min and max as limits' - name: endstop.maxz.max_travel type: number default: 500 units: mm module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:332 corresponding_v1: alpha_max_travel corresponding_v2: endstops.maxz.max_travel description: Maximum distance to travel while searching for endstop. Equivalent to `_max_travel` in root-level config. description_bullets: - Safety limit to prevent indefinite homing if endstop fails - If endstop not triggered within this distance, homing fails with ALARM - 'CRITICAL: Set larger than actual machine travel distance' - 'Failure produces error: "check the max_travel settings"' typical_values: - value: 300 description: small printer - value: 500 description: medium - value: 1000 description: large CNC related_settings: - endstop.maxz.fast_rate - endstop.maxz.axis related_pages: - endstops - endstops-options - guide-endstops examples: - endstop.minx.max_travel 500 - endstop.miny.max_travel 500 - endstop.minz.max_travel 300 - name: endstop.maxz.pin type: pin default: nc module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:252 corresponding_v1: alpha_min_endstop corresponding_v2: endstops.maxz.pin description: Pin assignment for this endstop. Supports the same pin modifiers as root-level configuration (`^` for pull-up, `!` for inverted). description_bullets: - The pin is configured as an input - Pull-up (`^`) is typically enabled for mechanical switches - Inverted (`!`) is used when switch pulls pin low when triggered - If pin is `nc` or not connected, the endstop is disabled even if enable is true related_settings: - endstop.maxz.enable - endstop.maxz.axis related_pages: - endstops - pin-configuration - pinout examples: - endstop.minx.pin 1.28^ - 'endstop.miny.pin 1.26^! # Pull-up and inverted' - endstop.minz.pin 1.24^ - name: endstop.maxz.retract type: number default: 5 units: mm module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:323 corresponding_v1: alpha_homing_retract_mm corresponding_v2: endstops.maxz.retract description: Distance to retract after fast homing before slow approach. Equivalent to `_homing_retract_mm` in root-level config. description_bullets: - Distance to back away from endstop after fast trigger - Must be large enough to fully release the endstop switch - During slow approach, moves `retract * 2` distance to ensure re-trigger - Larger values increase homing time slightly but improve reliability - Z-axis often uses smaller values (1-3 mm) to minimize travel - 'Typical range: 1-10 mm' typical_values: - value: 5 description: standard - value: 2 description: Z-axis minimal - value: 10 description: extra clearance - value: 3 description: balanced related_settings: - endstop.maxz.fast_rate - endstop.maxz.slow_rate related_pages: - endstops - endstops-options - guide-endstops examples: - endstop.minx.retract 5 - endstop.miny.retract 5 - 'endstop.minz.retract 2 # Smaller retract for Z safety' - name: endstop.maxz.slow_rate type: number default: 10 units: mm/s module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:320 corresponding_v1: alpha_slow_homing_rate_mm_s corresponding_v2: endstops.maxz.slow_rate description: Slow precision homing speed for this axis. Equivalent to `_slow_homing_rate_mm_s` in root-level config. description_bullets: - Speed at which axis moves during second, precise approach to endstop - Slower speeds provide better accuracy and repeatability - This determines final homing precision - Z-axis often uses 1-5 mm/s for maximum precision - 'Typical range: 2-25 mm/s' typical_values: - value: 10 description: standard - value: 2 description: high precision Z - value: 20 description: faster - value: 5 description: balanced related_settings: - endstop.maxz.fast_rate - endstop.maxz.retract related_pages: - endstops - endstops-options - guide-endstops examples: - endstop.minx.slow_rate 10 - endstop.miny.slow_rate 10 - 'endstop.minz.slow_rate 2 # Very slow for Z precision' - name: endstop.minx.axis type: string default: '""' module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:259 required: false corresponding_v1: alpha_* corresponding_v2: endstops.minx.axis description: 'Which axis this endstop is associated with. Must be one of: X, Y, Z, A, B, or C.' description_bullets: - This is required for each endstop - Multiple endstops can be assigned to the same axis (e.g., min and max) - The axis letter determines which motor/actuator is affected by this endstop - X, Y, Z are the primary Cartesian axes - A, B, C are additional rotary or linear axes (requires more than 3 actuators configured) - If the axis index exceeds the number of configured motors, configuration will fail related_settings: - endstop.minx.enable - endstop.minx.homing_direction related_pages: - endstops - endstops-options - 6axis examples: - endstop.minx.axis X - endstop.miny.axis Y - endstop.minz.axis Z - 'endstop.a_home.axis A # For 4-axis machine' - name: endstop.minx.enable type: bool default: false module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:249 required: false corresponding_v1: Implicit in root-level config (endstop exists if pin defined) corresponding_v2: endstops.minx.enable description: Enable this specific endstop instance. Each endstop must be individually enabled. description_bullets: - When `false` or omitted, this endstop instance is ignored - When `true`, the endstop is active and its pin is monitored - Multiple endstops can be enabled for the same axis (e.g., both min and max) - All other settings for this endstop are ignored if enable is `false` related_settings: - endstop.minx.pin - endstop.minx.axis related_pages: - endstops - endstops-options - guide-endstops examples: - endstop.minx.enable true - endstop.miny.enable true - endstop.minz.enable true - 'endstop.maxx.enable false # Disabled, not used' - name: endstop.minx.fast_rate type: number default: 100 units: mm/s module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:319 corresponding_v1: alpha_fast_homing_rate_mm_s corresponding_v2: endstops.minx.fast_rate description: Fast homing speed for this axis. Equivalent to `_fast_homing_rate_mm_s` in root-level config. description_bullets: - Speed at which axis moves during initial fast approach to endstop - Higher speeds reduce homing time - Lower speeds may be needed for mechanical reasons or safety - Z-axis typically uses slower rates (4-10 mm/s) for safety - Deltas should use same rate for all three towers typical_values: - value: 100 description: standard - value: 50 description: delta - value: 10 description: Z-axis - value: 150 description: fast XY related_settings: - endstop.minx.slow_rate - endstop.minx.retract - endstop.minx.max_travel related_pages: - endstops - endstops-options - guide-endstops examples: - endstop.minx.fast_rate 100 - endstop.miny.fast_rate 100 - 'endstop.minz.fast_rate 10 # Slower for Z safety' - name: endstop.minx.homing_direction type: string default: null module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:303 corresponding_v1: alpha_homing_direction corresponding_v2: endstops.minx.homing_direction description: Determines if and how this endstop is used for homing. description_bullets: - '`home_to_min` - This endstop is used when homing in the negative direction' - '`home_to_max` - This endstop is used when homing in the positive direction' - '`none` - This endstop is NOT used for homing (limit switch only)' - Setting to `none` allows an endstop to be used only for limit detection, not homing - This provides more flexibility than root-level config which can't disable homing for an endstop - Multiple endstops on the same axis can have different homing directions (e.g., min and max) related_settings: - endstop.minx.homing_position - endstop.minx.axis - endstop.minx.limit_enable related_pages: - endstops - endstops-options - guide-endstops examples: - endstop.minx.homing_direction home_to_min - endstop.miny.homing_direction home_to_min - 'endstop.maxx.homing_direction none # Limit only, not for homing' - name: endstop.minx.homing_position type: number default: 0 units: mm module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:329 corresponding_v1: alpha_min corresponding_v2: endstops.minx.homing_position description: Position to set the axis to when this endstop is triggered during homing. Equivalent to `_min` or `_max` in root-level config. description_bullets: - This defines the cartesian coordinate of the endstop in your workspace - Default is 0 for minimum endstops, 200 for maximum endstops - After homing, M206 home offset is added to this value - Only used if `homing_direction` is `home_to_min` or `home_to_max` (not `none`) - For bed-center-origin machines, minimum values may be negative - For Z-max homing, this typically represents the total build height typical_values: - value: 0 description: origin at min - value: 200 description: typical max height - value: -100 description: bed-center origin related_m_codes: - code: M206 description: Set home offset (added to this value) - code: M500 description: Save offsets to config-override related_settings: - endstop.minx.homing_direction - endstop.minx.axis related_pages: - endstops - endstops-options - gamma-max examples: - endstop.minx.homing_position 0 - endstop.minz.homing_position 0 - 'endstop.maxz.homing_position 200 # For Z-max homing (200mm build height)' - name: endstop.minx.limit_enable type: bool default: false module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:296 corresponding_v1: alpha_limit_enable corresponding_v2: endstops.minx.limit_enable description: Enable hard limit switch monitoring for this endstop during normal operation. Equivalent to `_limit_enable` in root-level config. description_bullets: - When `false` (default), endstop only used during homing - When `true`, endstop acts as hard limit during all moves - 'If triggered during operation: Machine halts, enters ALARM state' - Both min and max endstops can have limit checking enabled independently - More common on CNC machines than 3D printers - 'WARNING: With limits enabled, cannot move off endstop until cleared' related_settings: - endstop.minx.pin - endstop_debounce_count related_pages: - endstops - endstops-options - emergencystop examples: - endstop.minx.limit_enable true - 'endstop.maxx.limit_enable true # Both min and max as limits' - name: endstop.minx.max_travel type: number default: 500 units: mm module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:332 corresponding_v1: alpha_max_travel corresponding_v2: endstops.minx.max_travel description: Maximum distance to travel while searching for endstop. Equivalent to `_max_travel` in root-level config. description_bullets: - Safety limit to prevent indefinite homing if endstop fails - If endstop not triggered within this distance, homing fails with ALARM - 'CRITICAL: Set larger than actual machine travel distance' - 'Failure produces error: "check the max_travel settings"' typical_values: - value: 300 description: small printer - value: 500 description: medium - value: 1000 description: large CNC related_settings: - endstop.minx.fast_rate - endstop.minx.axis related_pages: - endstops - endstops-options - guide-endstops examples: - endstop.minx.max_travel 500 - endstop.miny.max_travel 500 - endstop.minz.max_travel 300 - name: endstop.minx.pin type: pin default: nc module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:252 corresponding_v1: alpha_min_endstop corresponding_v2: endstops.minx.pin description: Pin assignment for this endstop. Supports the same pin modifiers as root-level configuration (`^` for pull-up, `!` for inverted). description_bullets: - The pin is configured as an input - Pull-up (`^`) is typically enabled for mechanical switches - Inverted (`!`) is used when switch pulls pin low when triggered - If pin is `nc` or not connected, the endstop is disabled even if enable is true related_settings: - endstop.minx.enable - endstop.minx.axis related_pages: - endstops - pin-configuration - pinout examples: - endstop.minx.pin 1.28^ - 'endstop.miny.pin 1.26^! # Pull-up and inverted' - endstop.minz.pin 1.24^ - name: endstop.minx.retract type: number default: 5 units: mm module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:323 corresponding_v1: alpha_homing_retract_mm corresponding_v2: endstops.minx.retract description: Distance to retract after fast homing before slow approach. Equivalent to `_homing_retract_mm` in root-level config. description_bullets: - Distance to back away from endstop after fast trigger - Must be large enough to fully release the endstop switch - During slow approach, moves `retract * 2` distance to ensure re-trigger - Larger values increase homing time slightly but improve reliability - Z-axis often uses smaller values (1-3 mm) to minimize travel - 'Typical range: 1-10 mm' typical_values: - value: 5 description: standard - value: 2 description: Z-axis minimal - value: 10 description: extra clearance - value: 3 description: balanced related_settings: - endstop.minx.fast_rate - endstop.minx.slow_rate related_pages: - endstops - endstops-options - guide-endstops examples: - endstop.minx.retract 5 - endstop.miny.retract 5 - 'endstop.minz.retract 2 # Smaller retract for Z safety' - name: endstop.minx.slow_rate type: number default: 10 units: mm/s module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:320 corresponding_v1: alpha_slow_homing_rate_mm_s corresponding_v2: endstops.minx.slow_rate description: Slow precision homing speed for this axis. Equivalent to `_slow_homing_rate_mm_s` in root-level config. description_bullets: - Speed at which axis moves during second, precise approach to endstop - Slower speeds provide better accuracy and repeatability - This determines final homing precision - Z-axis often uses 1-5 mm/s for maximum precision - 'Typical range: 2-25 mm/s' typical_values: - value: 10 description: standard - value: 2 description: high precision Z - value: 20 description: faster - value: 5 description: balanced related_settings: - endstop.minx.fast_rate - endstop.minx.retract related_pages: - endstops - endstops-options - guide-endstops examples: - endstop.minx.slow_rate 10 - endstop.miny.slow_rate 10 - 'endstop.minz.slow_rate 2 # Very slow for Z precision' - name: endstop.miny.axis type: string default: '""' module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:259 required: false corresponding_v1: alpha_* corresponding_v2: endstops.miny.axis description: 'Which axis this endstop is associated with. Must be one of: X, Y, Z, A, B, or C.' description_bullets: - This is required for each endstop - Multiple endstops can be assigned to the same axis (e.g., min and max) - The axis letter determines which motor/actuator is affected by this endstop - X, Y, Z are the primary Cartesian axes - A, B, C are additional rotary or linear axes (requires more than 3 actuators configured) - If the axis index exceeds the number of configured motors, configuration will fail related_settings: - endstop.miny.enable - endstop.miny.homing_direction related_pages: - endstops - endstops-options - 6axis examples: - endstop.minx.axis X - endstop.miny.axis Y - endstop.minz.axis Z - 'endstop.a_home.axis A # For 4-axis machine' - name: endstop.miny.enable type: bool default: false module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:249 required: false corresponding_v1: Implicit in root-level config (endstop exists if pin defined) corresponding_v2: endstops.miny.enable description: Enable this specific endstop instance. Each endstop must be individually enabled. description_bullets: - When `false` or omitted, this endstop instance is ignored - When `true`, the endstop is active and its pin is monitored - Multiple endstops can be enabled for the same axis (e.g., both min and max) - All other settings for this endstop are ignored if enable is `false` related_settings: - endstop.miny.pin - endstop.miny.axis related_pages: - endstops - endstops-options - guide-endstops examples: - endstop.minx.enable true - endstop.miny.enable true - endstop.minz.enable true - 'endstop.maxx.enable false # Disabled, not used' - name: endstop.miny.fast_rate type: number default: 100 units: mm/s module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:319 corresponding_v1: alpha_fast_homing_rate_mm_s corresponding_v2: endstops.miny.fast_rate description: Fast homing speed for this axis. Equivalent to `_fast_homing_rate_mm_s` in root-level config. description_bullets: - Speed at which axis moves during initial fast approach to endstop - Higher speeds reduce homing time - Lower speeds may be needed for mechanical reasons or safety - Z-axis typically uses slower rates (4-10 mm/s) for safety - Deltas should use same rate for all three towers typical_values: - value: 100 description: standard - value: 50 description: delta - value: 10 description: Z-axis - value: 150 description: fast XY related_settings: - endstop.miny.slow_rate - endstop.miny.retract - endstop.miny.max_travel related_pages: - endstops - endstops-options - guide-endstops examples: - endstop.minx.fast_rate 100 - endstop.miny.fast_rate 100 - 'endstop.minz.fast_rate 10 # Slower for Z safety' - name: endstop.miny.homing_direction type: string default: null module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:303 corresponding_v1: alpha_homing_direction corresponding_v2: endstops.miny.homing_direction description: Determines if and how this endstop is used for homing. description_bullets: - '`home_to_min` - This endstop is used when homing in the negative direction' - '`home_to_max` - This endstop is used when homing in the positive direction' - '`none` - This endstop is NOT used for homing (limit switch only)' - Setting to `none` allows an endstop to be used only for limit detection, not homing - This provides more flexibility than root-level config which can't disable homing for an endstop - Multiple endstops on the same axis can have different homing directions (e.g., min and max) related_settings: - endstop.miny.homing_position - endstop.miny.axis - endstop.miny.limit_enable related_pages: - endstops - endstops-options - guide-endstops examples: - endstop.minx.homing_direction home_to_min - endstop.miny.homing_direction home_to_min - 'endstop.maxx.homing_direction none # Limit only, not for homing' - name: endstop.miny.homing_position type: number default: 0 units: mm module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:329 corresponding_v1: alpha_min corresponding_v2: endstops.miny.homing_position description: Position to set the axis to when this endstop is triggered during homing. Equivalent to `_min` or `_max` in root-level config. description_bullets: - This defines the cartesian coordinate of the endstop in your workspace - Default is 0 for minimum endstops, 200 for maximum endstops - After homing, M206 home offset is added to this value - Only used if `homing_direction` is `home_to_min` or `home_to_max` (not `none`) - For bed-center-origin machines, minimum values may be negative - For Z-max homing, this typically represents the total build height typical_values: - value: 0 description: origin at min - value: 200 description: typical max height - value: -100 description: bed-center origin related_m_codes: - code: M206 description: Set home offset (added to this value) - code: M500 description: Save offsets to config-override related_settings: - endstop.miny.homing_direction - endstop.miny.axis related_pages: - endstops - endstops-options - gamma-max examples: - endstop.minx.homing_position 0 - endstop.minz.homing_position 0 - 'endstop.maxz.homing_position 200 # For Z-max homing (200mm build height)' - name: endstop.miny.limit_enable type: bool default: false module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:296 corresponding_v1: alpha_limit_enable corresponding_v2: endstops.miny.limit_enable description: Enable hard limit switch monitoring for this endstop during normal operation. Equivalent to `_limit_enable` in root-level config. description_bullets: - When `false` (default), endstop only used during homing - When `true`, endstop acts as hard limit during all moves - 'If triggered during operation: Machine halts, enters ALARM state' - Both min and max endstops can have limit checking enabled independently - More common on CNC machines than 3D printers - 'WARNING: With limits enabled, cannot move off endstop until cleared' related_settings: - endstop.miny.pin - endstop_debounce_count related_pages: - endstops - endstops-options - emergencystop examples: - endstop.minx.limit_enable true - 'endstop.maxx.limit_enable true # Both min and max as limits' - name: endstop.miny.max_travel type: number default: 500 units: mm module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:332 corresponding_v1: alpha_max_travel corresponding_v2: endstops.miny.max_travel description: Maximum distance to travel while searching for endstop. Equivalent to `_max_travel` in root-level config. description_bullets: - Safety limit to prevent indefinite homing if endstop fails - If endstop not triggered within this distance, homing fails with ALARM - 'CRITICAL: Set larger than actual machine travel distance' - 'Failure produces error: "check the max_travel settings"' typical_values: - value: 300 description: small printer - value: 500 description: medium - value: 1000 description: large CNC related_settings: - endstop.miny.fast_rate - endstop.miny.axis related_pages: - endstops - endstops-options - guide-endstops examples: - endstop.minx.max_travel 500 - endstop.miny.max_travel 500 - endstop.minz.max_travel 300 - name: endstop.miny.pin type: pin default: nc module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:252 corresponding_v1: alpha_min_endstop corresponding_v2: endstops.miny.pin description: Pin assignment for this endstop. Supports the same pin modifiers as root-level configuration (`^` for pull-up, `!` for inverted). description_bullets: - The pin is configured as an input - Pull-up (`^`) is typically enabled for mechanical switches - Inverted (`!`) is used when switch pulls pin low when triggered - If pin is `nc` or not connected, the endstop is disabled even if enable is true related_settings: - endstop.miny.enable - endstop.miny.axis related_pages: - endstops - pin-configuration - pinout examples: - endstop.minx.pin 1.28^ - 'endstop.miny.pin 1.26^! # Pull-up and inverted' - endstop.minz.pin 1.24^ - name: endstop.miny.retract type: number default: 5 units: mm module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:323 corresponding_v1: alpha_homing_retract_mm corresponding_v2: endstops.miny.retract description: Distance to retract after fast homing before slow approach. Equivalent to `_homing_retract_mm` in root-level config. description_bullets: - Distance to back away from endstop after fast trigger - Must be large enough to fully release the endstop switch - During slow approach, moves `retract * 2` distance to ensure re-trigger - Larger values increase homing time slightly but improve reliability - Z-axis often uses smaller values (1-3 mm) to minimize travel - 'Typical range: 1-10 mm' typical_values: - value: 5 description: standard - value: 2 description: Z-axis minimal - value: 10 description: extra clearance - value: 3 description: balanced related_settings: - endstop.miny.fast_rate - endstop.miny.slow_rate related_pages: - endstops - endstops-options - guide-endstops examples: - endstop.minx.retract 5 - endstop.miny.retract 5 - 'endstop.minz.retract 2 # Smaller retract for Z safety' - name: endstop.miny.slow_rate type: number default: 10 units: mm/s module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:320 corresponding_v1: alpha_slow_homing_rate_mm_s corresponding_v2: endstops.miny.slow_rate description: Slow precision homing speed for this axis. Equivalent to `_slow_homing_rate_mm_s` in root-level config. description_bullets: - Speed at which axis moves during second, precise approach to endstop - Slower speeds provide better accuracy and repeatability - This determines final homing precision - Z-axis often uses 1-5 mm/s for maximum precision - 'Typical range: 2-25 mm/s' typical_values: - value: 10 description: standard - value: 2 description: high precision Z - value: 20 description: faster - value: 5 description: balanced related_settings: - endstop.miny.fast_rate - endstop.miny.retract related_pages: - endstops - endstops-options - guide-endstops examples: - endstop.minx.slow_rate 10 - endstop.miny.slow_rate 10 - 'endstop.minz.slow_rate 2 # Very slow for Z precision' - name: endstop.minz.axis type: string default: '""' module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:259 required: false corresponding_v1: alpha_* corresponding_v2: endstops.minz.axis description: 'Which axis this endstop is associated with. Must be one of: X, Y, Z, A, B, or C.' description_bullets: - This is required for each endstop - Multiple endstops can be assigned to the same axis (e.g., min and max) - The axis letter determines which motor/actuator is affected by this endstop - X, Y, Z are the primary Cartesian axes - A, B, C are additional rotary or linear axes (requires more than 3 actuators configured) - If the axis index exceeds the number of configured motors, configuration will fail related_settings: - endstop.minz.enable - endstop.minz.homing_direction related_pages: - endstops - endstops-options - 6axis examples: - endstop.minx.axis X - endstop.miny.axis Y - endstop.minz.axis Z - 'endstop.a_home.axis A # For 4-axis machine' - name: endstop.minz.enable type: bool default: false module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:249 required: false corresponding_v1: Implicit in root-level config (endstop exists if pin defined) corresponding_v2: endstops.minz.enable description: Enable this specific endstop instance. Each endstop must be individually enabled. description_bullets: - When `false` or omitted, this endstop instance is ignored - When `true`, the endstop is active and its pin is monitored - Multiple endstops can be enabled for the same axis (e.g., both min and max) - All other settings for this endstop are ignored if enable is `false` related_settings: - endstop.minz.pin - endstop.minz.axis related_pages: - endstops - endstops-options - guide-endstops examples: - endstop.minx.enable true - endstop.miny.enable true - endstop.minz.enable true - 'endstop.maxx.enable false # Disabled, not used' - name: endstop.minz.fast_rate type: number default: 100 units: mm/s module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:319 corresponding_v1: alpha_fast_homing_rate_mm_s corresponding_v2: endstops.minz.fast_rate description: Fast homing speed for this axis. Equivalent to `_fast_homing_rate_mm_s` in root-level config. description_bullets: - Speed at which axis moves during initial fast approach to endstop - Higher speeds reduce homing time - Lower speeds may be needed for mechanical reasons or safety - Z-axis typically uses slower rates (4-10 mm/s) for safety - Deltas should use same rate for all three towers typical_values: - value: 100 description: standard - value: 50 description: delta - value: 10 description: Z-axis - value: 150 description: fast XY related_settings: - endstop.minz.slow_rate - endstop.minz.retract - endstop.minz.max_travel related_pages: - endstops - endstops-options - guide-endstops examples: - endstop.minx.fast_rate 100 - endstop.miny.fast_rate 100 - 'endstop.minz.fast_rate 10 # Slower for Z safety' - name: endstop.minz.homing_direction type: string default: null module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:303 corresponding_v1: alpha_homing_direction corresponding_v2: endstops.minz.homing_direction description: Determines if and how this endstop is used for homing. description_bullets: - '`home_to_min` - This endstop is used when homing in the negative direction' - '`home_to_max` - This endstop is used when homing in the positive direction' - '`none` - This endstop is NOT used for homing (limit switch only)' - Setting to `none` allows an endstop to be used only for limit detection, not homing - This provides more flexibility than root-level config which can't disable homing for an endstop - Multiple endstops on the same axis can have different homing directions (e.g., min and max) related_settings: - endstop.minz.homing_position - endstop.minz.axis - endstop.minz.limit_enable related_pages: - endstops - endstops-options - guide-endstops examples: - endstop.minx.homing_direction home_to_min - endstop.miny.homing_direction home_to_min - 'endstop.maxx.homing_direction none # Limit only, not for homing' - name: endstop.minz.homing_position type: number default: 0 units: mm module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:329 corresponding_v1: alpha_min corresponding_v2: endstops.minz.homing_position description: Position to set the axis to when this endstop is triggered during homing. Equivalent to `_min` or `_max` in root-level config. description_bullets: - This defines the cartesian coordinate of the endstop in your workspace - Default is 0 for minimum endstops, 200 for maximum endstops - After homing, M206 home offset is added to this value - Only used if `homing_direction` is `home_to_min` or `home_to_max` (not `none`) - For bed-center-origin machines, minimum values may be negative - For Z-max homing, this typically represents the total build height typical_values: - value: 0 description: origin at min - value: 200 description: typical max height - value: -100 description: bed-center origin related_m_codes: - code: M206 description: Set home offset (added to this value) - code: M500 description: Save offsets to config-override related_settings: - endstop.minz.homing_direction - endstop.minz.axis related_pages: - endstops - endstops-options - gamma-max examples: - endstop.minx.homing_position 0 - endstop.minz.homing_position 0 - 'endstop.maxz.homing_position 200 # For Z-max homing (200mm build height)' - name: endstop.minz.limit_enable type: bool default: false module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:296 corresponding_v1: alpha_limit_enable corresponding_v2: endstops.minz.limit_enable description: Enable hard limit switch monitoring for this endstop during normal operation. Equivalent to `_limit_enable` in root-level config. description_bullets: - When `false` (default), endstop only used during homing - When `true`, endstop acts as hard limit during all moves - 'If triggered during operation: Machine halts, enters ALARM state' - Both min and max endstops can have limit checking enabled independently - More common on CNC machines than 3D printers - 'WARNING: With limits enabled, cannot move off endstop until cleared' related_settings: - endstop.minz.pin - endstop_debounce_count related_pages: - endstops - endstops-options - emergencystop examples: - endstop.minx.limit_enable true - 'endstop.maxx.limit_enable true # Both min and max as limits' - name: endstop.minz.max_travel type: number default: 500 units: mm module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:332 corresponding_v1: alpha_max_travel corresponding_v2: endstops.minz.max_travel description: Maximum distance to travel while searching for endstop. Equivalent to `_max_travel` in root-level config. description_bullets: - Safety limit to prevent indefinite homing if endstop fails - If endstop not triggered within this distance, homing fails with ALARM - 'CRITICAL: Set larger than actual machine travel distance' - 'Failure produces error: "check the max_travel settings"' typical_values: - value: 300 description: small printer - value: 500 description: medium - value: 1000 description: large CNC related_settings: - endstop.minz.fast_rate - endstop.minz.axis related_pages: - endstops - endstops-options - guide-endstops examples: - endstop.minx.max_travel 500 - endstop.miny.max_travel 500 - endstop.minz.max_travel 300 - name: endstop.minz.pin type: pin default: nc module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:252 corresponding_v1: alpha_min_endstop corresponding_v2: endstops.minz.pin description: Pin assignment for this endstop. Supports the same pin modifiers as root-level configuration (`^` for pull-up, `!` for inverted). description_bullets: - The pin is configured as an input - Pull-up (`^`) is typically enabled for mechanical switches - Inverted (`!`) is used when switch pulls pin low when triggered - If pin is `nc` or not connected, the endstop is disabled even if enable is true related_settings: - endstop.minz.enable - endstop.minz.axis related_pages: - endstops - pin-configuration - pinout examples: - endstop.minx.pin 1.28^ - 'endstop.miny.pin 1.26^! # Pull-up and inverted' - endstop.minz.pin 1.24^ - name: endstop.minz.retract type: number default: 5 units: mm module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:323 corresponding_v1: alpha_homing_retract_mm corresponding_v2: endstops.minz.retract description: Distance to retract after fast homing before slow approach. Equivalent to `_homing_retract_mm` in root-level config. description_bullets: - Distance to back away from endstop after fast trigger - Must be large enough to fully release the endstop switch - During slow approach, moves `retract * 2` distance to ensure re-trigger - Larger values increase homing time slightly but improve reliability - Z-axis often uses smaller values (1-3 mm) to minimize travel - 'Typical range: 1-10 mm' typical_values: - value: 5 description: standard - value: 2 description: Z-axis minimal - value: 10 description: extra clearance - value: 3 description: balanced related_settings: - endstop.minz.fast_rate - endstop.minz.slow_rate related_pages: - endstops - endstops-options - guide-endstops examples: - endstop.minx.retract 5 - endstop.miny.retract 5 - 'endstop.minz.retract 2 # Smaller retract for Z safety' - name: endstop.minz.slow_rate type: number default: 10 units: mm/s module: endstop context: Module instance setting defined_in: modules/tools/endstops/Endstops.cpp:320 corresponding_v1: alpha_slow_homing_rate_mm_s corresponding_v2: endstops.minz.slow_rate description: Slow precision homing speed for this axis. Equivalent to `_slow_homing_rate_mm_s` in root-level config. description_bullets: - Speed at which axis moves during second, precise approach to endstop - Slower speeds provide better accuracy and repeatability - This determines final homing precision - Z-axis often uses 1-5 mm/s for maximum precision - 'Typical range: 2-25 mm/s' typical_values: - value: 10 description: standard - value: 2 description: high precision Z - value: 20 description: faster - value: 5 description: balanced related_settings: - endstop.minz.fast_rate - endstop.minz.retract related_pages: - endstops - endstops-options - guide-endstops examples: - endstop.minx.slow_rate 10 - endstop.miny.slow_rate 10 - 'endstop.minz.slow_rate 2 # Very slow for Z precision' - name: x_min_endstop type: pin default: nc module: root context: Global setting - Per-axis endstop pin configuration defined_in: modules/tools/endstops/Endstops.cpp:179 corresponding_v1: alpha_min_endstop corresponding_v2: endstops.minx.pin description: Minimum endstop pin for the X axis. The pin is configured as an input with optional pull-up or inverted logic. Setting to `nc` disables this endstop. description_bullets: - The pin monitors the endstop switch state during homing and limit checking - Pull-up resistors are typically enabled for mechanical switches to prevent floating inputs - Inverted logic is used when the switch pulls the pin low when triggered - The endstop is used for homing if `_homing_direction` is set to `home_to_min` related_settings: - _homing_direction - _limit_enable - endstop_debounce_ms related_pages: - endstops - endstops-options - guide-endstops examples: - 'alpha_min_endstop 1.28^ # X-axis minimum endstop on pin 1.28, pullup enabled' - 'beta_min_endstop 1.26^ # Y-axis minimum endstop on pin 1.26, pullup enabled' - 'gamma_min_endstop 1.24^ # Z-axis minimum endstop on pin 1.24, pullup enabled' - 'alpha_min_endstop nc # Disable X minimum endstop' - name: y_min_endstop type: pin default: nc module: root context: Global setting - Per-axis endstop pin configuration defined_in: modules/tools/endstops/Endstops.cpp:179 corresponding_v1: alpha_min_endstop corresponding_v2: endstops.minx.pin description: Minimum endstop pin for the Y axis. The pin is configured as an input with optional pull-up or inverted logic. Setting to `nc` disables this endstop. description_bullets: - The pin monitors the endstop switch state during homing and limit checking - Pull-up resistors are typically enabled for mechanical switches to prevent floating inputs - Inverted logic is used when the switch pulls the pin low when triggered - The endstop is used for homing if `_homing_direction` is set to `home_to_min` related_settings: - _homing_direction - _limit_enable - endstop_debounce_ms related_pages: - endstops - endstops-options - guide-endstops examples: - 'alpha_min_endstop 1.28^ # X-axis minimum endstop on pin 1.28, pullup enabled' - 'beta_min_endstop 1.26^ # Y-axis minimum endstop on pin 1.26, pullup enabled' - 'gamma_min_endstop 1.24^ # Z-axis minimum endstop on pin 1.24, pullup enabled' - 'alpha_min_endstop nc # Disable X minimum endstop' - name: z_min_endstop type: pin default: nc module: root context: Global setting - Per-axis endstop pin configuration defined_in: modules/tools/endstops/Endstops.cpp:179 corresponding_v1: alpha_min_endstop corresponding_v2: endstops.minx.pin description: Minimum endstop pin for the Z axis. The pin is configured as an input with optional pull-up or inverted logic. Setting to `nc` disables this endstop. description_bullets: - The pin monitors the endstop switch state during homing and limit checking - Pull-up resistors are typically enabled for mechanical switches to prevent floating inputs - Inverted logic is used when the switch pulls the pin low when triggered - The endstop is used for homing if `_homing_direction` is set to `home_to_min` related_settings: - _homing_direction - _limit_enable - endstop_debounce_ms related_pages: - endstops - endstops-options - guide-endstops examples: - 'alpha_min_endstop 1.28^ # X-axis minimum endstop on pin 1.28, pullup enabled' - 'beta_min_endstop 1.26^ # Y-axis minimum endstop on pin 1.26, pullup enabled' - 'gamma_min_endstop 1.24^ # Z-axis minimum endstop on pin 1.24, pullup enabled' - 'alpha_min_endstop nc # Disable X minimum endstop' - name: x_max_endstop type: pin default: nc module: root context: Global setting - Per-axis endstop pin configuration defined_in: modules/tools/endstops/Endstops.cpp:179 corresponding_v1: alpha_max_endstop corresponding_v2: endstops.maxx.pin description: Maximum endstop pin for the X axis. The pin is configured as an input with optional pull-up or inverted logic. Setting to `nc` disables this endstop. description_bullets: - The pin monitors the endstop switch state during homing and limit checking - Pull-up resistors are typically enabled for mechanical switches to prevent floating inputs - Inverted logic is used when the switch pulls the pin low when triggered - The endstop is used for homing if `_homing_direction` is set to `home_to_max` - Both min and max endstops can be enabled simultaneously for limit switch functionality related_settings: - _homing_direction - _limit_enable - endstop_debounce_ms related_pages: - endstops - endstops-options - guide-endstops examples: - 'alpha_max_endstop 1.29^ # X-axis maximum endstop on pin 1.29' - 'beta_max_endstop 1.27^ # Y-axis maximum endstop on pin 1.27' - 'gamma_max_endstop 1.25^ # Z-axis maximum endstop on pin 1.25 (common for 3D printers)' - 'alpha_max_endstop nc # Disable X maximum endstop' - name: y_max_endstop type: pin default: nc module: root context: Global setting - Per-axis endstop pin configuration defined_in: modules/tools/endstops/Endstops.cpp:179 corresponding_v1: alpha_max_endstop corresponding_v2: endstops.maxx.pin description: Maximum endstop pin for the Y axis. The pin is configured as an input with optional pull-up or inverted logic. Setting to `nc` disables this endstop. description_bullets: - The pin monitors the endstop switch state during homing and limit checking - Pull-up resistors are typically enabled for mechanical switches to prevent floating inputs - Inverted logic is used when the switch pulls the pin low when triggered - The endstop is used for homing if `_homing_direction` is set to `home_to_max` - Both min and max endstops can be enabled simultaneously for limit switch functionality related_settings: - _homing_direction - _limit_enable - endstop_debounce_ms related_pages: - endstops - endstops-options - guide-endstops examples: - 'alpha_max_endstop 1.29^ # X-axis maximum endstop on pin 1.29' - 'beta_max_endstop 1.27^ # Y-axis maximum endstop on pin 1.27' - 'gamma_max_endstop 1.25^ # Z-axis maximum endstop on pin 1.25 (common for 3D printers)' - 'alpha_max_endstop nc # Disable X maximum endstop' - name: z_max_endstop type: pin default: nc module: root context: Global setting - Per-axis endstop pin configuration defined_in: modules/tools/endstops/Endstops.cpp:179 corresponding_v1: alpha_max_endstop corresponding_v2: endstops.maxx.pin description: Maximum endstop pin for the Z axis. The pin is configured as an input with optional pull-up or inverted logic. Setting to `nc` disables this endstop. description_bullets: - The pin monitors the endstop switch state during homing and limit checking - Pull-up resistors are typically enabled for mechanical switches to prevent floating inputs - Inverted logic is used when the switch pulls the pin low when triggered - The endstop is used for homing if `_homing_direction` is set to `home_to_max` - Both min and max endstops can be enabled simultaneously for limit switch functionality related_settings: - _homing_direction - _limit_enable - endstop_debounce_ms related_pages: - endstops - endstops-options - guide-endstops examples: - 'alpha_max_endstop 1.29^ # X-axis maximum endstop on pin 1.29' - 'beta_max_endstop 1.27^ # Y-axis maximum endstop on pin 1.27' - 'gamma_max_endstop 1.25^ # Z-axis maximum endstop on pin 1.25 (common for 3D printers)' - 'alpha_max_endstop nc # Disable X maximum endstop' - name: x_max_travel type: number default: 500 units: mm module: root context: Global setting - Per-axis homing safety limit defined_in: modules/tools/endstops/Endstops.cpp:173 corresponding_v1: alpha_max_travel corresponding_v2: endstops.minx.max_travel description: Maximum distance the X axis will travel while searching for an endstop during homing. If the endstop is not triggered within this distance, homing will fail and enter ALARM state. description_bullets: - This is a safety feature to prevent the machine from attempting to home indefinitely if an endstop is disconnected or malfunctioning - The axis travels at `_fast_homing_rate_mm_s` speed while searching - If this distance is exceeded, homing fails with error "check the max_travel settings" - 'CRITICAL: Set this value larger than your actual machine travel distance to prevent false failures' - For deltas, this applies to the Z-axis travel distance (all three towers move together) typical_values: - value: 300 description: small printer - value: 500 description: medium printer - value: 1000 description: large CNC machine related_settings: - _fast_homing_rate_mm_s - _homing_direction related_pages: - endstops - endstops-options - guide-endstops examples: - 'alpha_max_travel 300 # X-axis will travel max 300mm looking for endstop' - 'beta_max_travel 300 # Y-axis will travel max 300mm looking for endstop' - 'gamma_max_travel 210 # Z-axis will travel max 210mm (slightly larger than 200mm bed height)' - name: y_max_travel type: number default: 500 units: mm module: root context: Global setting - Per-axis homing safety limit defined_in: modules/tools/endstops/Endstops.cpp:173 corresponding_v1: alpha_max_travel corresponding_v2: endstops.minx.max_travel description: Maximum distance the Y axis will travel while searching for an endstop during homing. If the endstop is not triggered within this distance, homing will fail and enter ALARM state. description_bullets: - This is a safety feature to prevent the machine from attempting to home indefinitely if an endstop is disconnected or malfunctioning - The axis travels at `_fast_homing_rate_mm_s` speed while searching - If this distance is exceeded, homing fails with error "check the max_travel settings" - 'CRITICAL: Set this value larger than your actual machine travel distance to prevent false failures' - For deltas, this applies to the Z-axis travel distance (all three towers move together) typical_values: - value: 300 description: small printer - value: 500 description: medium printer - value: 1000 description: large CNC machine related_settings: - _fast_homing_rate_mm_s - _homing_direction related_pages: - endstops - endstops-options - guide-endstops examples: - 'alpha_max_travel 300 # X-axis will travel max 300mm looking for endstop' - 'beta_max_travel 300 # Y-axis will travel max 300mm looking for endstop' - 'gamma_max_travel 210 # Z-axis will travel max 210mm (slightly larger than 200mm bed height)' - name: z_max_travel type: number default: 500 units: mm module: root context: Global setting - Per-axis homing safety limit defined_in: modules/tools/endstops/Endstops.cpp:173 corresponding_v1: alpha_max_travel corresponding_v2: endstops.minx.max_travel description: Maximum distance the Z axis will travel while searching for an endstop during homing. If the endstop is not triggered within this distance, homing will fail and enter ALARM state. description_bullets: - This is a safety feature to prevent the machine from attempting to home indefinitely if an endstop is disconnected or malfunctioning - The axis travels at `_fast_homing_rate_mm_s` speed while searching - If this distance is exceeded, homing fails with error "check the max_travel settings" - 'CRITICAL: Set this value larger than your actual machine travel distance to prevent false failures' - For deltas, this applies to the Z-axis travel distance (all three towers move together) typical_values: - value: 300 description: small printer - value: 500 description: medium printer - value: 1000 description: large CNC machine related_settings: - _fast_homing_rate_mm_s - _homing_direction related_pages: - endstops - endstops-options - guide-endstops examples: - 'alpha_max_travel 300 # X-axis will travel max 300mm looking for endstop' - 'beta_max_travel 300 # Y-axis will travel max 300mm looking for endstop' - 'gamma_max_travel 210 # Z-axis will travel max 210mm (slightly larger than 200mm bed height)' - name: x_fast_homing_rate_mm_s type: number default: 100 units: mm/s module: root context: Global setting - Per-axis homing speed defined_in: modules/tools/endstops/Endstops.cpp:160 corresponding_v1: alpha_fast_homing_rate_mm_s corresponding_v2: endstops.minx.fast_rate description: Speed at which the X axis moves during the initial fast homing approach. This is the first phase of the two-stage homing process. description_bullets: - The fast rate is used to quickly move the axis to the endstop to minimize homing time - Once the endstop is triggered, the axis retracts by `_homing_retract_mm` distance - After retraction, a slower, more precise approach is performed at `_slow_homing_rate_mm_s` - Z-axis typically uses a slower rate (4-10 mm/s) for safety to prevent bed crashes - Higher speeds reduce homing time but may reduce accuracy if switch bounce is an issue - Speed is limited by motor capabilities and acceleration settings - For deltas, all three tower rates should typically be the same for balanced motion typical_values: - value: 100 description: standard speed - value: 50 description: delta printer - value: 10 description: Z-axis safety - value: 150 description: fast XY related_settings: - _slow_homing_rate_mm_s - _homing_retract_mm - _max_travel related_pages: - endstops - endstops-options - guide-endstops examples: - 'alpha_fast_homing_rate_mm_s 100 # X-axis fast homing at 100mm/s' - 'beta_fast_homing_rate_mm_s 100 # Y-axis fast homing at 100mm/s' - 'gamma_fast_homing_rate_mm_s 10 # Z-axis fast homing at 10mm/s (slower for safety)' - name: y_fast_homing_rate_mm_s type: number default: 100 units: mm/s module: root context: Global setting - Per-axis homing speed defined_in: modules/tools/endstops/Endstops.cpp:160 corresponding_v1: alpha_fast_homing_rate_mm_s corresponding_v2: endstops.minx.fast_rate description: Speed at which the Y axis moves during the initial fast homing approach. This is the first phase of the two-stage homing process. description_bullets: - The fast rate is used to quickly move the axis to the endstop to minimize homing time - Once the endstop is triggered, the axis retracts by `_homing_retract_mm` distance - After retraction, a slower, more precise approach is performed at `_slow_homing_rate_mm_s` - Z-axis typically uses a slower rate (4-10 mm/s) for safety to prevent bed crashes - Higher speeds reduce homing time but may reduce accuracy if switch bounce is an issue - Speed is limited by motor capabilities and acceleration settings - For deltas, all three tower rates should typically be the same for balanced motion typical_values: - value: 100 description: standard speed - value: 50 description: delta printer - value: 10 description: Z-axis safety - value: 150 description: fast XY related_settings: - _slow_homing_rate_mm_s - _homing_retract_mm - _max_travel related_pages: - endstops - endstops-options - guide-endstops examples: - 'alpha_fast_homing_rate_mm_s 100 # X-axis fast homing at 100mm/s' - 'beta_fast_homing_rate_mm_s 100 # Y-axis fast homing at 100mm/s' - 'gamma_fast_homing_rate_mm_s 10 # Z-axis fast homing at 10mm/s (slower for safety)' - name: z_fast_homing_rate_mm_s type: number default: 100 units: mm/s module: root context: Global setting - Per-axis homing speed defined_in: modules/tools/endstops/Endstops.cpp:160 corresponding_v1: alpha_fast_homing_rate_mm_s corresponding_v2: endstops.minx.fast_rate description: Speed at which the Z axis moves during the initial fast homing approach. This is the first phase of the two-stage homing process. description_bullets: - The fast rate is used to quickly move the axis to the endstop to minimize homing time - Once the endstop is triggered, the axis retracts by `_homing_retract_mm` distance - After retraction, a slower, more precise approach is performed at `_slow_homing_rate_mm_s` - Z-axis typically uses a slower rate (4-10 mm/s) for safety to prevent bed crashes - Higher speeds reduce homing time but may reduce accuracy if switch bounce is an issue - Speed is limited by motor capabilities and acceleration settings - For deltas, all three tower rates should typically be the same for balanced motion typical_values: - value: 100 description: standard speed - value: 50 description: delta printer - value: 10 description: Z-axis safety - value: 150 description: fast XY related_settings: - _slow_homing_rate_mm_s - _homing_retract_mm - _max_travel related_pages: - endstops - endstops-options - guide-endstops examples: - 'alpha_fast_homing_rate_mm_s 100 # X-axis fast homing at 100mm/s' - 'beta_fast_homing_rate_mm_s 100 # Y-axis fast homing at 100mm/s' - 'gamma_fast_homing_rate_mm_s 10 # Z-axis fast homing at 10mm/s (slower for safety)' - name: x_slow_homing_rate_mm_s type: number default: 10 units: mm/s module: root context: Global setting - Per-axis precision homing speed defined_in: modules/tools/endstops/Endstops.cpp:161 corresponding_v1: alpha_slow_homing_rate_mm_s corresponding_v2: endstops.minx.slow_rate description: Speed at which the X axis moves during the second, slow homing approach. This is the precision phase of the two-stage homing process. description_bullets: - After the fast approach triggers the endstop, the axis retracts by `_homing_retract_mm` - The axis then approaches the endstop again at this slower rate for more accurate positioning - This slow approach travels `_homing_retract_mm * 2` distance to ensure re-trigger - Slower speeds provide more accurate and repeatable homing positions - 'Typical values: 2-25 mm/s depending on required precision' - Z-axis often uses the slowest rate (1-5 mm/s) for maximum precision - This speed determines the final homing accuracy and repeatability - Too slow increases homing time unnecessarily, too fast reduces precision typical_values: - value: 10 description: standard precision - value: 2 description: high precision Z - value: 20 description: faster XY - value: 5 description: balanced related_settings: - _fast_homing_rate_mm_s - _homing_retract_mm - endstop_debounce_ms related_pages: - endstops - endstops-options - guide-endstops examples: - 'alpha_slow_homing_rate_mm_s 10 # X-axis slow homing at 10mm/s' - 'beta_slow_homing_rate_mm_s 10 # Y-axis slow homing at 10mm/s' - 'gamma_slow_homing_rate_mm_s 2 # Z-axis slow homing at 2mm/s (very slow for accuracy)' - name: y_slow_homing_rate_mm_s type: number default: 10 units: mm/s module: root context: Global setting - Per-axis precision homing speed defined_in: modules/tools/endstops/Endstops.cpp:161 corresponding_v1: alpha_slow_homing_rate_mm_s corresponding_v2: endstops.minx.slow_rate description: Speed at which the Y axis moves during the second, slow homing approach. This is the precision phase of the two-stage homing process. description_bullets: - After the fast approach triggers the endstop, the axis retracts by `_homing_retract_mm` - The axis then approaches the endstop again at this slower rate for more accurate positioning - This slow approach travels `_homing_retract_mm * 2` distance to ensure re-trigger - Slower speeds provide more accurate and repeatable homing positions - 'Typical values: 2-25 mm/s depending on required precision' - Z-axis often uses the slowest rate (1-5 mm/s) for maximum precision - This speed determines the final homing accuracy and repeatability - Too slow increases homing time unnecessarily, too fast reduces precision typical_values: - value: 10 description: standard precision - value: 2 description: high precision Z - value: 20 description: faster XY - value: 5 description: balanced related_settings: - _fast_homing_rate_mm_s - _homing_retract_mm - endstop_debounce_ms related_pages: - endstops - endstops-options - guide-endstops examples: - 'alpha_slow_homing_rate_mm_s 10 # X-axis slow homing at 10mm/s' - 'beta_slow_homing_rate_mm_s 10 # Y-axis slow homing at 10mm/s' - 'gamma_slow_homing_rate_mm_s 2 # Z-axis slow homing at 2mm/s (very slow for accuracy)' - name: z_slow_homing_rate_mm_s type: number default: 10 units: mm/s module: root context: Global setting - Per-axis precision homing speed defined_in: modules/tools/endstops/Endstops.cpp:161 corresponding_v1: alpha_slow_homing_rate_mm_s corresponding_v2: endstops.minx.slow_rate description: Speed at which the Z axis moves during the second, slow homing approach. This is the precision phase of the two-stage homing process. description_bullets: - After the fast approach triggers the endstop, the axis retracts by `_homing_retract_mm` - The axis then approaches the endstop again at this slower rate for more accurate positioning - This slow approach travels `_homing_retract_mm * 2` distance to ensure re-trigger - Slower speeds provide more accurate and repeatable homing positions - 'Typical values: 2-25 mm/s depending on required precision' - Z-axis often uses the slowest rate (1-5 mm/s) for maximum precision - This speed determines the final homing accuracy and repeatability - Too slow increases homing time unnecessarily, too fast reduces precision typical_values: - value: 10 description: standard precision - value: 2 description: high precision Z - value: 20 description: faster XY - value: 5 description: balanced related_settings: - _fast_homing_rate_mm_s - _homing_retract_mm - endstop_debounce_ms related_pages: - endstops - endstops-options - guide-endstops examples: - 'alpha_slow_homing_rate_mm_s 10 # X-axis slow homing at 10mm/s' - 'beta_slow_homing_rate_mm_s 10 # Y-axis slow homing at 10mm/s' - 'gamma_slow_homing_rate_mm_s 2 # Z-axis slow homing at 2mm/s (very slow for accuracy)' - name: x_homing_retract_mm type: number default: 5 units: mm module: root context: Global setting - Per-axis homing behavior defined_in: modules/tools/endstops/Endstops.cpp:164 corresponding_v1: alpha_homing_retract_mm corresponding_v2: endstops.minx.retract description: 'X axis: Distance to retract (move away from) the endstop after the fast homing approach triggers it, before beginning the slow precision approach.' description_bullets: - This retraction ensures a clean re-trigger during the slow approach - Improves homing repeatability by always approaching the endstop from the same direction - The axis moves away from the endstop by this distance at the slow homing rate - During the slow approach, the axis moves `retract * 2` distance to ensure re-trigger - Larger values increase homing time slightly but improve reliability - Must be large enough to fully release the endstop switch - 'Typical values: 1-10 mm depending on endstop type and machine' - Z-axis often uses smaller values (1-3 mm) to minimize travel and prevent bed crashes - If too small, the endstop may not fully release, causing homing to fail typical_values: - value: 5 description: standard - value: 2 description: Z-axis minimal - value: 10 description: extra clearance - value: 3 description: balanced related_settings: - _fast_homing_rate_mm_s - _slow_homing_rate_mm_s related_pages: - endstops - endstops-options - guide-endstops examples: - 'alpha_homing_retract_mm 5 # X-axis retracts 5mm after fast approach' - 'beta_homing_retract_mm 5 # Y-axis retracts 5mm after fast approach' - 'gamma_homing_retract_mm 2 # Z-axis retracts 2mm (smaller retract for safety)' - name: y_homing_retract_mm type: number default: 5 units: mm module: root context: Global setting - Per-axis homing behavior defined_in: modules/tools/endstops/Endstops.cpp:164 corresponding_v1: alpha_homing_retract_mm corresponding_v2: endstops.minx.retract description: 'Y axis: Distance to retract (move away from) the endstop after the fast homing approach triggers it, before beginning the slow precision approach.' description_bullets: - This retraction ensures a clean re-trigger during the slow approach - Improves homing repeatability by always approaching the endstop from the same direction - The axis moves away from the endstop by this distance at the slow homing rate - During the slow approach, the axis moves `retract * 2` distance to ensure re-trigger - Larger values increase homing time slightly but improve reliability - Must be large enough to fully release the endstop switch - 'Typical values: 1-10 mm depending on endstop type and machine' - Z-axis often uses smaller values (1-3 mm) to minimize travel and prevent bed crashes - If too small, the endstop may not fully release, causing homing to fail typical_values: - value: 5 description: standard - value: 2 description: Z-axis minimal - value: 10 description: extra clearance - value: 3 description: balanced related_settings: - _fast_homing_rate_mm_s - _slow_homing_rate_mm_s related_pages: - endstops - endstops-options - guide-endstops examples: - 'alpha_homing_retract_mm 5 # X-axis retracts 5mm after fast approach' - 'beta_homing_retract_mm 5 # Y-axis retracts 5mm after fast approach' - 'gamma_homing_retract_mm 2 # Z-axis retracts 2mm (smaller retract for safety)' - name: z_homing_retract_mm type: number default: 5 units: mm module: root context: Global setting - Per-axis homing behavior defined_in: modules/tools/endstops/Endstops.cpp:164 corresponding_v1: alpha_homing_retract_mm corresponding_v2: endstops.minx.retract description: 'Z axis: Distance to retract (move away from) the endstop after the fast homing approach triggers it, before beginning the slow precision approach.' description_bullets: - This retraction ensures a clean re-trigger during the slow approach - Improves homing repeatability by always approaching the endstop from the same direction - The axis moves away from the endstop by this distance at the slow homing rate - During the slow approach, the axis moves `retract * 2` distance to ensure re-trigger - Larger values increase homing time slightly but improve reliability - Must be large enough to fully release the endstop switch - 'Typical values: 1-10 mm depending on endstop type and machine' - Z-axis often uses smaller values (1-3 mm) to minimize travel and prevent bed crashes - If too small, the endstop may not fully release, causing homing to fail typical_values: - value: 5 description: standard - value: 2 description: Z-axis minimal - value: 10 description: extra clearance - value: 3 description: balanced related_settings: - _fast_homing_rate_mm_s - _slow_homing_rate_mm_s related_pages: - endstops - endstops-options - guide-endstops examples: - 'alpha_homing_retract_mm 5 # X-axis retracts 5mm after fast approach' - 'beta_homing_retract_mm 5 # Y-axis retracts 5mm after fast approach' - 'gamma_homing_retract_mm 2 # Z-axis retracts 2mm (smaller retract for safety)' - name: x_homing_direction type: string default: home_to_min module: root context: Global setting - Per-axis homing behavior defined_in: modules/tools/endstops/Endstops.cpp:167 corresponding_v1: alpha_homing_direction corresponding_v2: endstops.minx.homing_direction description: Determines which direction the X axis moves during homing and which endstop is used. description_bullets: - '`home_to_min` moves the axis in the negative direction and uses the `_min_endstop` pin' - '`home_to_max` moves the axis in the positive direction and uses the `_max_endstop` pin' - When homing to min completes, the axis position is set to the `_min` value plus any M206 home offset - When homing to max completes, the axis position is set to the `_max` value plus any M206 home offset - 'Most Cartesian printers: X and Y home to min (front-left corner), Z homes to max (top)' - CNC mills typically home all axes to minimum or maximum depending on machine design - 'CoreXY: Varies by mechanical design and belt routing' - 'Delta: All three tower endstops should be set to same direction (typically max)' - 'SCARA: Depends on mechanical configuration and workspace' related_m_codes: - code: M206 description: Set home offset (added to homing position) related_settings: - _min - _max - _min_endstop - _max_endstop related_pages: - endstops - endstops-options - guide-endstops examples: - 'alpha_homing_direction home_to_min # Home X to minimum endstop (common)' - 'beta_homing_direction home_to_min # Home Y to minimum endstop (common)' - 'gamma_homing_direction home_to_max # Home Z to maximum endstop (common for 3D printers)' notes: - 'NOTE: `none` is only available in module-based configuration for limits-only endstops' - name: y_homing_direction type: string default: home_to_min module: root context: Global setting - Per-axis homing behavior defined_in: modules/tools/endstops/Endstops.cpp:167 corresponding_v1: alpha_homing_direction corresponding_v2: endstops.minx.homing_direction description: Determines which direction the Y axis moves during homing and which endstop is used. description_bullets: - '`home_to_min` moves the axis in the negative direction and uses the `_min_endstop` pin' - '`home_to_max` moves the axis in the positive direction and uses the `_max_endstop` pin' - When homing to min completes, the axis position is set to the `_min` value plus any M206 home offset - When homing to max completes, the axis position is set to the `_max` value plus any M206 home offset - 'Most Cartesian printers: X and Y home to min (front-left corner), Z homes to max (top)' - CNC mills typically home all axes to minimum or maximum depending on machine design - 'CoreXY: Varies by mechanical design and belt routing' - 'Delta: All three tower endstops should be set to same direction (typically max)' - 'SCARA: Depends on mechanical configuration and workspace' related_m_codes: - code: M206 description: Set home offset (added to homing position) related_settings: - _min - _max - _min_endstop - _max_endstop related_pages: - endstops - endstops-options - guide-endstops examples: - 'alpha_homing_direction home_to_min # Home X to minimum endstop (common)' - 'beta_homing_direction home_to_min # Home Y to minimum endstop (common)' - 'gamma_homing_direction home_to_max # Home Z to maximum endstop (common for 3D printers)' notes: - 'NOTE: `none` is only available in module-based configuration for limits-only endstops' - name: z_homing_direction type: string default: home_to_min module: root context: Global setting - Per-axis homing behavior defined_in: modules/tools/endstops/Endstops.cpp:167 corresponding_v1: alpha_homing_direction corresponding_v2: endstops.minx.homing_direction description: Determines which direction the Z axis moves during homing and which endstop is used. description_bullets: - '`home_to_min` moves the axis in the negative direction and uses the `_min_endstop` pin' - '`home_to_max` moves the axis in the positive direction and uses the `_max_endstop` pin' - When homing to min completes, the axis position is set to the `_min` value plus any M206 home offset - When homing to max completes, the axis position is set to the `_max` value plus any M206 home offset - 'Most Cartesian printers: X and Y home to min (front-left corner), Z homes to max (top)' - CNC mills typically home all axes to minimum or maximum depending on machine design - 'CoreXY: Varies by mechanical design and belt routing' - 'Delta: All three tower endstops should be set to same direction (typically max)' - 'SCARA: Depends on mechanical configuration and workspace' related_m_codes: - code: M206 description: Set home offset (added to homing position) related_settings: - _min - _max - _min_endstop - _max_endstop related_pages: - endstops - endstops-options - guide-endstops examples: - 'alpha_homing_direction home_to_min # Home X to minimum endstop (common)' - 'beta_homing_direction home_to_min # Home Y to minimum endstop (common)' - 'gamma_homing_direction home_to_max # Home Z to maximum endstop (common for 3D printers)' notes: - 'NOTE: `none` is only available in module-based configuration for limits-only endstops' - name: x_min type: number default: 0 units: mm module: root context: Global setting - Per-axis position after homing defined_in: modules/tools/endstops/Endstops.cpp:170 corresponding_v1: alpha_min corresponding_v2: endstops.minx.homing_position description: The cartesian position (coordinate) that the X axis is set to after homing when `_homing_direction` is set to `home_to_min` and the minimum endstop is triggered. description_bullets: - This value defines where "minimum" is in your coordinate system - For most machines, this is 0, but it can be set to any value to define the workspace origin - After homing, the M206 home offset is added to this base position for fine-tuning - For bed-center-origin machines (0,0 at bed center), this is typically negative (e.g., -100 for 200mm bed) - Only used if `_homing_direction` is `home_to_min` - 'The actual position after homing is: `_min` + M206 offset' - This is a base position; fine-tuning adjustments are done with M206 - For standard Cartesian printers with origin at front-left corner, this is typically 0 typical_values: - value: 0 description: origin at min - value: -100 description: bed-center origin for 200mm travel - value: -150 description: centered 300mm bed related_m_codes: - code: M206 description: Set home offset (added to this value) - code: M500 description: Save M206 offset to config-override related_settings: - _homing_direction - _min_endstop related_pages: - endstops - endstops-options - guide-endstops examples: - 'alpha_min 0 # X=0 when homed to minimum (standard)' - 'beta_min 0 # Y=0 when homed to minimum (standard)' - 'gamma_min 0 # Z=0 when homed to minimum' - 'alpha_min -100 # X=-100 when homed (bed center for 200mm bed)' - name: y_min type: number default: 0 units: mm module: root context: Global setting - Per-axis position after homing defined_in: modules/tools/endstops/Endstops.cpp:170 corresponding_v1: alpha_min corresponding_v2: endstops.minx.homing_position description: The cartesian position (coordinate) that the Y axis is set to after homing when `_homing_direction` is set to `home_to_min` and the minimum endstop is triggered. description_bullets: - This value defines where "minimum" is in your coordinate system - For most machines, this is 0, but it can be set to any value to define the workspace origin - After homing, the M206 home offset is added to this base position for fine-tuning - For bed-center-origin machines (0,0 at bed center), this is typically negative (e.g., -100 for 200mm bed) - Only used if `_homing_direction` is `home_to_min` - 'The actual position after homing is: `_min` + M206 offset' - This is a base position; fine-tuning adjustments are done with M206 - For standard Cartesian printers with origin at front-left corner, this is typically 0 typical_values: - value: 0 description: origin at min - value: -100 description: bed-center origin for 200mm travel - value: -150 description: centered 300mm bed related_m_codes: - code: M206 description: Set home offset (added to this value) - code: M500 description: Save M206 offset to config-override related_settings: - _homing_direction - _min_endstop related_pages: - endstops - endstops-options - guide-endstops examples: - 'alpha_min 0 # X=0 when homed to minimum (standard)' - 'beta_min 0 # Y=0 when homed to minimum (standard)' - 'gamma_min 0 # Z=0 when homed to minimum' - 'alpha_min -100 # X=-100 when homed (bed center for 200mm bed)' - name: z_min type: number default: 0 units: mm module: root context: Global setting - Per-axis position after homing defined_in: modules/tools/endstops/Endstops.cpp:170 corresponding_v1: alpha_min corresponding_v2: endstops.minx.homing_position description: The cartesian position (coordinate) that the Z axis is set to after homing when `_homing_direction` is set to `home_to_min` and the minimum endstop is triggered. description_bullets: - This value defines where "minimum" is in your coordinate system - For most machines, this is 0, but it can be set to any value to define the workspace origin - After homing, the M206 home offset is added to this base position for fine-tuning - For bed-center-origin machines (0,0 at bed center), this is typically negative (e.g., -100 for 200mm bed) - Only used if `_homing_direction` is `home_to_min` - 'The actual position after homing is: `_min` + M206 offset' - This is a base position; fine-tuning adjustments are done with M206 - For standard Cartesian printers with origin at front-left corner, this is typically 0 typical_values: - value: 0 description: origin at min - value: -100 description: bed-center origin for 200mm travel - value: -150 description: centered 300mm bed related_m_codes: - code: M206 description: Set home offset (added to this value) - code: M500 description: Save M206 offset to config-override related_settings: - _homing_direction - _min_endstop related_pages: - endstops - endstops-options - guide-endstops examples: - 'alpha_min 0 # X=0 when homed to minimum (standard)' - 'beta_min 0 # Y=0 when homed to minimum (standard)' - 'gamma_min 0 # Z=0 when homed to minimum' - 'alpha_min -100 # X=-100 when homed (bed center for 200mm bed)' - name: x_max type: number default: 200 units: mm module: root context: Global setting - Per-axis position after homing defined_in: modules/tools/endstops/Endstops.cpp:170 corresponding_v1: alpha_max corresponding_v2: endstops.maxx.homing_position description: The cartesian position (coordinate) that the X axis is set to after homing when `_homing_direction` is set to `home_to_max` and the maximum endstop is triggered. description_bullets: - This value defines where "maximum" is in your coordinate system - For Z-max homing (common in 3D printers), this represents the total build height - After homing, the M206 home offset is added to this base position for fine-tuning - Only used if `_homing_direction` is `home_to_max` - Common for Z-axis in 3D printers where Z homes to the top of travel - For Z-max homing, this should equal your maximum Z height - 'The actual position after homing is: `_max` + M206 offset' - 'NOTE: This is NOT related to soft limits (those are set separately via soft_endstop settings)' typical_values: - value: 200 description: 200mm build height - value: 300 description: 300mm travel - value: 250 description: 250mm bed related_m_codes: - code: M206 description: Set home offset (added to this value) - code: M665 Z description: Set max Z height for deltas (also sets gamma_max) - code: M500 description: Save offsets to config-override related_settings: - _homing_direction - _max_endstop related_pages: - endstops - endstops-options - guide-endstops - gamma-max examples: - 'alpha_max 200 # X=200mm when homed to maximum' - 'beta_max 200 # Y=200mm when homed to maximum' - 'gamma_max 200 # Z=200mm when homed to maximum (bed height for Z-max homing)' - name: y_max type: number default: 200 units: mm module: root context: Global setting - Per-axis position after homing defined_in: modules/tools/endstops/Endstops.cpp:170 corresponding_v1: alpha_max corresponding_v2: endstops.maxx.homing_position description: The cartesian position (coordinate) that the Y axis is set to after homing when `_homing_direction` is set to `home_to_max` and the maximum endstop is triggered. description_bullets: - This value defines where "maximum" is in your coordinate system - For Z-max homing (common in 3D printers), this represents the total build height - After homing, the M206 home offset is added to this base position for fine-tuning - Only used if `_homing_direction` is `home_to_max` - Common for Z-axis in 3D printers where Z homes to the top of travel - For Z-max homing, this should equal your maximum Z height - 'The actual position after homing is: `_max` + M206 offset' - 'NOTE: This is NOT related to soft limits (those are set separately via soft_endstop settings)' typical_values: - value: 200 description: 200mm build height - value: 300 description: 300mm travel - value: 250 description: 250mm bed related_m_codes: - code: M206 description: Set home offset (added to this value) - code: M665 Z description: Set max Z height for deltas (also sets gamma_max) - code: M500 description: Save offsets to config-override related_settings: - _homing_direction - _max_endstop related_pages: - endstops - endstops-options - guide-endstops - gamma-max examples: - 'alpha_max 200 # X=200mm when homed to maximum' - 'beta_max 200 # Y=200mm when homed to maximum' - 'gamma_max 200 # Z=200mm when homed to maximum (bed height for Z-max homing)' - name: z_max type: number default: 200 units: mm module: root context: Global setting - Per-axis position after homing defined_in: modules/tools/endstops/Endstops.cpp:170 corresponding_v1: alpha_max corresponding_v2: endstops.maxx.homing_position description: The cartesian position (coordinate) that the Z axis is set to after homing when `_homing_direction` is set to `home_to_max` and the maximum endstop is triggered. description_bullets: - This value defines where "maximum" is in your coordinate system - For Z-max homing (common in 3D printers), this represents the total build height - After homing, the M206 home offset is added to this base position for fine-tuning - Only used if `_homing_direction` is `home_to_max` - Common for Z-axis in 3D printers where Z homes to the top of travel - For Z-max homing, this should equal your maximum Z height - 'The actual position after homing is: `_max` + M206 offset' - 'NOTE: This is NOT related to soft limits (those are set separately via soft_endstop settings)' typical_values: - value: 200 description: 200mm build height - value: 300 description: 300mm travel - value: 250 description: 250mm bed related_m_codes: - code: M206 description: Set home offset (added to this value) - code: M665 Z description: Set max Z height for deltas (also sets gamma_max) - code: M500 description: Save offsets to config-override related_settings: - _homing_direction - _max_endstop related_pages: - endstops - endstops-options - guide-endstops - gamma-max examples: - 'alpha_max 200 # X=200mm when homed to maximum' - 'beta_max 200 # Y=200mm when homed to maximum' - 'gamma_max 200 # Z=200mm when homed to maximum (bed height for Z-max homing)' - name: x_limit_enable type: bool default: false module: root context: Global setting - Per-axis safety feature defined_in: modules/tools/endstops/Endstops.cpp:198 corresponding_v1: alpha_limit_enable corresponding_v2: endstops.minx.limit_enable description: 'X axis: Enables hard limit switch monitoring during normal machine operation (not just during homing). When enabled, if any endstop for the X axis is triggered during a move, the machine will immediately halt and enter ALARM state.' description_bullets: - This is a safety feature to prevent the machine from crashing into the limits of travel - When false (default), endstops are only used during homing - When true, endstops act as hard limits during all moves - 'If triggered during operation: Machine halts, motors disable, heaters turn off' - 'WARNING: With limits enabled, you cannot move off an endstop. After homing, the machine automatically backs off the endstop if limits are enabled' - If a limit is triggered during operation, you must manually clear it before resuming - Requires clearing all limits before machine will operate again - 'CoreXY: Both X and Y motors are monitored when either axis limit is enabled' - Not commonly used on 3D printers (relies on soft limits instead) - More common on CNC machines for crash prevention - Both min and max endstops are monitored if both pins are defined related_m_codes: - code: M119 description: Report endstop status (useful for checking limit triggers) related_settings: - endstop_debounce_count - _min_endstop - _max_endstop related_pages: - endstops - endstops-options - guide-endstops - emergencystop examples: - 'alpha_limit_enable false # No limit checking during X moves (typical for 3D printers)' - 'beta_limit_enable false # No limit checking during Y moves (typical for 3D printers)' - 'gamma_limit_enable false # No limit checking during Z moves (typical for 3D printers)' - 'alpha_limit_enable true # Hard limits enabled on X axis (common for CNC)' - name: y_limit_enable type: bool default: false module: root context: Global setting - Per-axis safety feature defined_in: modules/tools/endstops/Endstops.cpp:198 corresponding_v1: alpha_limit_enable corresponding_v2: endstops.minx.limit_enable description: 'Y axis: Enables hard limit switch monitoring during normal machine operation (not just during homing). When enabled, if any endstop for the Y axis is triggered during a move, the machine will immediately halt and enter ALARM state.' description_bullets: - This is a safety feature to prevent the machine from crashing into the limits of travel - When false (default), endstops are only used during homing - When true, endstops act as hard limits during all moves - 'If triggered during operation: Machine halts, motors disable, heaters turn off' - 'WARNING: With limits enabled, you cannot move off an endstop. After homing, the machine automatically backs off the endstop if limits are enabled' - If a limit is triggered during operation, you must manually clear it before resuming - Requires clearing all limits before machine will operate again - 'CoreXY: Both X and Y motors are monitored when either axis limit is enabled' - Not commonly used on 3D printers (relies on soft limits instead) - More common on CNC machines for crash prevention - Both min and max endstops are monitored if both pins are defined related_m_codes: - code: M119 description: Report endstop status (useful for checking limit triggers) related_settings: - endstop_debounce_count - _min_endstop - _max_endstop related_pages: - endstops - endstops-options - guide-endstops - emergencystop examples: - 'alpha_limit_enable false # No limit checking during X moves (typical for 3D printers)' - 'beta_limit_enable false # No limit checking during Y moves (typical for 3D printers)' - 'gamma_limit_enable false # No limit checking during Z moves (typical for 3D printers)' - 'alpha_limit_enable true # Hard limits enabled on X axis (common for CNC)' - name: z_limit_enable type: bool default: false module: root context: Global setting - Per-axis safety feature defined_in: modules/tools/endstops/Endstops.cpp:198 corresponding_v1: alpha_limit_enable corresponding_v2: endstops.minx.limit_enable description: 'Z axis: Enables hard limit switch monitoring during normal machine operation (not just during homing). When enabled, if any endstop for the Z axis is triggered during a move, the machine will immediately halt and enter ALARM state.' description_bullets: - This is a safety feature to prevent the machine from crashing into the limits of travel - When false (default), endstops are only used during homing - When true, endstops act as hard limits during all moves - 'If triggered during operation: Machine halts, motors disable, heaters turn off' - 'WARNING: With limits enabled, you cannot move off an endstop. After homing, the machine automatically backs off the endstop if limits are enabled' - If a limit is triggered during operation, you must manually clear it before resuming - Requires clearing all limits before machine will operate again - 'CoreXY: Both X and Y motors are monitored when either axis limit is enabled' - Not commonly used on 3D printers (relies on soft limits instead) - More common on CNC machines for crash prevention - Both min and max endstops are monitored if both pins are defined related_m_codes: - code: M119 description: Report endstop status (useful for checking limit triggers) related_settings: - endstop_debounce_count - _min_endstop - _max_endstop related_pages: - endstops - endstops-options - guide-endstops - emergencystop examples: - 'alpha_limit_enable false # No limit checking during X moves (typical for 3D printers)' - 'beta_limit_enable false # No limit checking during Y moves (typical for 3D printers)' - 'gamma_limit_enable false # No limit checking during Z moves (typical for 3D printers)' - 'alpha_limit_enable true # Hard limits enabled on X axis (common for CNC)' - name: endstops_enable type: bool default: false module: root context: Global setting - Master enable for root-level endstop configuration defined_in: modules/tools/endstops/Endstops.cpp:117 required: false corresponding_v1: endstops_enable corresponding_v2: none (endstops always enabled if configured in v2) description: Master enable switch for the traditional root-level endstop configuration method (Method 1). When set to `true`, Smoothieware will load endstop configuration using the `alpha_*`, `beta_*`, `gamma_*` syntax. description_bullets: - When set to `false` (or omitted), Smoothieware will attempt to load the module-based configuration method (Method 2) using `endstop..*` syntax - 'IMPORTANT: Only one method should be used - either set this to `true` and use root-level config, OR set to `false`/omit and use module-based config' - If both methods are configured, Method 1 (this enabled) takes precedence - If no endstops are defined in either method, the module will disable itself - Cannot be changed during runtime, requires restart - Most default configurations use `endstops_enable true` (Method 1) as it is simpler for basic setups related_settings: - alpha_* - beta_* - gamma_* - endstop.*.* - All - endstop settings - all settings related_pages: - endstops - endstops-options - guide-endstops examples: - 'endstops_enable true # Enable traditional root-level endstop configuration' - '# Then use traditional syntax:' - alpha_min_endstop 1.28^ - alpha_max_travel 500 - name: corexy_homing type: bool default: false module: root context: Global setting - Machine kinematics configuration defined_in: modules/tools/endstops/Endstops.cpp:56 required: false corresponding_v1: corexy_homing corresponding_v2: endstops.common.corexy_homing description: Enables CoreXY-specific homing behavior. CoreXY machines have coupled X and Y motors where each motor affects both axes, requiring special homing logic. description_bullets: - When enabled, X and Y axes home individually (one at a time) rather than simultaneously - Both X and Y motors are stopped when either endstop is triggered during homing - Both motors are monitored during homing of either axis - Prevents the complex coupled motion that would occur if both axes homed simultaneously - 'CRITICAL: Must be enabled for CoreXY and H-Bot kinematics to prevent incorrect homing behavior' - Do not enable on Cartesian or Delta machines - Also applies to limit checking when limits are enabled - Cannot be used with `homing_order` (CoreXY always homes individually, overrides homing_order) - Z-axis homing is not affected (remains independent) - During homing, uses the slower of the X and Y fast rates for safety related_settings: - delta_homing - homing_order - alpha_fast_homing_rate_mm_s - beta_fast_homing_rate_mm_s related_pages: - endstops - endstops-options - hbot - arm-solutions examples: - 'corexy_homing true # Enable for CoreXY and H-Bot machines' - '# Do not set for standard Cartesian machines' - name: delta_homing type: bool default: false module: root context: Global setting - Machine kinematics configuration defined_in: modules/tools/endstops/Endstops.cpp:57 required: false corresponding_v1: delta_homing corresponding_v2: endstops.common.delta_homing description: Enables linear delta robot homing behavior. Linear delta machines have three vertical towers that all move to control the XYZ position of the end effector. description_bullets: - When enabled, G28 homes all three towers simultaneously by moving Z axis - All three tower endstops (alpha, beta, gamma) must trigger during homing - Sets XYZ position based on kinematic calculations from tower positions - Applies trim values (`alpha_trim_mm`, `beta_trim_mm`, `gamma_trim_mm`) to correct for endstop position variations - After homing, moves to origin if `move_to_origin_after_home` is true (default for deltas) - 'CRITICAL: Must be enabled for linear delta kinematics to prevent incorrect homing' - Do not enable on Cartesian, CoreXY, or Rotary Delta machines - All three tower homing rates (fast and slow) should be the same for balanced motion - All three towers must home in the same direction (typically max) - Trim values account for small variations in endstop positions between towers - Cannot specify individual axes in G28 (always homes all three towers together) - For deltas, homing is always done in Z-only mode regardless of which axes are specified related_m_codes: - code: M666 description: Set or display delta trim values - code: M665 Z description: Set maximum Z height for delta related_settings: - rdelta_homing - alpha_trim_mm - beta_trim_mm - gamma_trim_mm - move_to_origin_after_home related_pages: - endstops - endstops-options - delta - arm-solutions examples: - 'delta_homing true # Enable for linear delta machines' - alpha_trim_mm 0 - beta_trim_mm 0 - gamma_trim_mm 0 - move_to_origin_after_home true - name: rdelta_homing type: bool default: false module: root context: Global setting - Machine kinematics configuration defined_in: modules/tools/endstops/Endstops.cpp:58 required: false corresponding_v1: rdelta_homing corresponding_v2: endstops.common.rdelta_homing description: Enables rotary delta robot homing behavior. Rotary delta machines use rotating arms instead of linear carriages to control the end effector position. description_bullets: - When enabled, homing behavior is similar to linear delta - All three actuator endstops must trigger during homing - Endstop positions represent actuator angles (in degrees), not cartesian coordinates - Uses forward kinematics to calculate cartesian position from actuator angles - M206 sets theta offset for each actuator (in degrees, not mm) - Homing positions are in degrees (actuator angles) rather than millimeters - RotaryDeltaCalibration module handles M206 and M665 for rotary deltas - 'CRITICAL: Must be enabled for rotary delta kinematics' - Do not enable on Cartesian, CoreXY, or Linear Delta machines - Trim values (`alpha_trim_mm`, `beta_trim_mm`, `gamma_trim_mm`) are in degrees for rotary deltas, not millimeters related_m_codes: - code: M206 description: Sets theta offset in degrees (not mm) for rotary deltas - code: M665 description: Delta-specific calibration related_settings: - delta_homing - alpha_trim_mm - beta_trim_mm - gamma_trim_mm related_pages: - endstops - endstops-options - rotary-delta - arm-solutions examples: - 'rdelta_homing true # Enable for rotary delta machines (e.g., Triton, Katana)' - name: scara_homing type: bool default: false module: root context: Global setting - Machine kinematics configuration defined_in: modules/tools/endstops/Endstops.cpp:59 required: false corresponding_v1: scara_homing corresponding_v2: endstops.common.scara_homing description: Enables SCARA robot arm homing behavior. SCARA (Selective Compliance Assembly Robot Arm) machines use rotating joints to position the end effector. description_bullets: - When enabled, disables arm solution during homing (homes in actuator space, not cartesian space) - Resets arms to plausible minimum angles (-30, 30, 0) before homing to prevent extreme positions - Re-enables arm solution after homing completes - Applies endstop trim if configured - Homing occurs in actuator/joint space rather than cartesian space - Initial reset to (-30, 30, 0) degrees prevents the arm from trying to reach impossible positions - 'CRITICAL: Must be enabled for SCARA kinematics' - Do not enable on Cartesian, CoreXY, or Delta machines - Endstop trim is applied to final actuator position related_settings: - alpha_trim_mm - beta_trim_mm - gamma_trim_mm related_pages: - endstops - endstops-options - morgan-scara - arm-solutions examples: - 'scara_homing true # Enable for SCARA machines' - name: endstop_debounce_count type: number default: 100 module: root context: Global setting - Limit switch noise filtering defined_in: modules/tools/endstops/Endstops.cpp:61 corresponding_v1: endstop_debounce_count corresponding_v2: debounce_ms description: Number of consecutive reads required to confirm a limit switch trigger. This provides debouncing for limit switches (not homing endstops). description_bullets: - When a limit switch is checked, it must read as triggered for this many consecutive samples before it is considered truly triggered - This filters out electrical noise and mechanical bounce - 'IMPORTANT: Only used for limit switches (when `_limit_enable` is true)' - Does NOT apply to homing endstops (use `endstop_debounce_ms` for homing) - Higher values provide more filtering but slower response to limit triggers - Default of 100 is suitable for most mechanical switches - Increase if getting false limit triggers due to noise - Each sample is read at 1kHz (every 1ms) in the ISR - Value of 100 equals approximately 100ms debounce time - Too high may delay limit detection, too low may cause false triggers typical_values: - value: 100 description: default, suitable for most switches - value: 200 description: noisy environment - value: 50 description: fast optical switches related_settings: - _limit_enable - endstop_debounce_ms related_pages: - endstops - endstops-options - guide-endstops examples: - 'endstop_debounce_count 100 # Require 100 consecutive triggered reads (default)' - 'endstop_debounce_count 200 # More filtering for noisy environment' - name: endstop_debounce_ms type: number default: 0 units: ms module: root context: Global setting - Homing endstop noise filtering defined_in: modules/tools/endstops/Endstops.cpp:62 corresponding_v1: endstop_debounce_ms corresponding_v2: endstops.common.debounce_ms description: Debounce time in milliseconds for homing endstops. When an endstop is triggered during homing, it must remain triggered for this duration before being accepted as a valid trigger. description_bullets: - This filters out electrical noise, EMI interference, and mechanical switch bounce during the homing process - 'IMPORTANT: Only used for homing endstops during G28' - Does NOT apply to limit switches (use `endstop_debounce_count` for limits) - Optical endstops typically use 0 (no debounce needed due to clean switching) - Mechanical switches typically use 1-5ms - Higher values reduce false triggers but slow homing response - During fast homing, switch must stay triggered continuously for this duration - During slow homing, provides more reliable trigger detection - 'Typical values: 0-10ms' - Too high may miss brief valid triggers, too low may allow noise triggers - 'NOTE: v2 enforces a minimum of 10ms, v1 allows 0' typical_values: - value: 0 description: optical endstops, no debounce needed - value: 1 description: mechanical switches - value: 5 description: noisy environment related_settings: - endstop_debounce_count - _slow_homing_rate_mm_s related_pages: - endstops - endstops-options - guide-endstops examples: - 'endstop_debounce_ms 0 # No debounce (default, for optical endstops)' - 'endstop_debounce_ms 1 # 1ms debounce for mechanical switches' - 'endstop_debounce_ms 5 # 5ms debounce for noisy environment' - name: home_z_first type: bool default: false module: root context: Global setting - Homing sequence control defined_in: modules/tools/endstops/Endstops.cpp:64 corresponding_v1: home_z_first corresponding_v2: endstops.common.home_z_first description: Controls whether the Z axis homes before or after the X and Y axes. description_bullets: - 'When `false` (default): X and Y home first (simultaneously), then Z homes' - 'When `true`: Z homes first, then X and Y home (simultaneously)' - Homing Z first is useful for machines with auto bed leveling probes that need Z clearance before XY movement - Also useful for gantries that could crash into bed features without Z clearance - Moving beds may need Z in a safe position before XY homing - Does not affect individual axis homing (e.g., G28 Z still homes only Z) - Only affects G28 with no parameters or G28 with multiple axes specified - Ignored if `homing_order` is specified (homing_order takes precedence) - Not applicable to delta machines (they always home all axes together in Z-only mode) - Not applicable to CoreXY (it homes axes individually anyway due to `corexy_homing`) - Z-axis typically homes slower for safety regardless of whether it homes first or last related_settings: - homing_order - corexy_homing - delta_homing related_pages: - endstops - endstops-options - guide-endstops examples: - 'home_z_first false # Home XY first, then Z (default, standard behavior)' - 'home_z_first true # Home Z first to get clearance, then XY (useful for auto-leveling probes)' - name: homing_order type: string default: '""' module: root context: Global setting - Advanced homing sequence control defined_in: modules/tools/endstops/Endstops.cpp:65 corresponding_v1: homing_order corresponding_v2: endstops.common.homing_order description: Specifies a custom homing order, forcing axes to home one at a time in the specified sequence. Must be 3-6 characters specifying axis letters (XYZABC) in desired order. description_bullets: - When specified, each axis homes individually in the given order - Overrides `home_z_first` setting if both are configured - 'IMPORTANT: Any axis not specified in the string will NOT be homed' - If ABC axes exist and need homing, they must be explicitly included - Not valid for delta or rotary delta machines (ignored, deltas must home all together) - Not valid for CoreXY (already homes individually due to `corexy_homing`) - If an axis doesn't have an endstop defined, homing will fail when it tries to home that axis - Useful for machines that require a specific sequence due to mechanical constraints - Empty string uses default behavior based on `home_z_first` setting related_settings: - home_z_first - corexy_homing - delta_homing related_pages: - endstops - endstops-options - guide-endstops examples: - 'homing_order XYZ # Home X, then Y, then Z (one at a time)' - 'homing_order YXZ # Home Y first, then X, then Z' - 'homing_order ZXY # Home Z first, then X, then Y' - 'homing_order XYZAB # For machines with A and B axes' - name: move_to_origin_after_home type: bool default: false module: root context: Global setting - Post-homing behavior defined_in: modules/tools/endstops/Endstops.cpp:66 corresponding_v1: move_to_origin_after_home corresponding_v2: endstops.common.move_to_origin_after_home description: Controls whether the machine automatically moves to the origin (0,0 or 0,0,0) after homing completes. description_bullets: - 'Cartesian default: `false` - Stay at homed position (endstop location)' - 'Delta default: `true` - Move to origin (deltas are typically not at 0,0 after homing due to trim)' - For Cartesian machines with bed-center origin (0,0 is in center), enabling this moves to center after homing - If enabled, `park_after_home` is automatically disabled (mutually exclusive) - Move uses the slower of X and Y fast rates for safety - For deltas, ensures effector is at true 0,0,0 after homing (required due to trim settings) - Only moves XY for Cartesian, XYZ for Delta - Move is done in machine coordinates (G53 G0) to ignore any G92 or WCS offsets - 'NOTE: Deltas default to `true` and should remain `true` to ensure correct positioning' related_settings: - park_after_home - alpha_trim_mm - beta_trim_mm - gamma_trim_mm - delta_homing related_pages: - endstops - endstops-options - delta - guide-endstops examples: - 'move_to_origin_after_home false # Stay at endstops after homing (Cartesian default)' - 'move_to_origin_after_home true # Move to 0,0 after homing (Delta default, or bed-center Cartesian)' - name: park_after_home type: bool default: false module: root context: Global setting - Post-homing behavior defined_in: modules/tools/endstops/Endstops.cpp:67 corresponding_v1: park_after_home corresponding_v2: none (not documented in v2) description: If enabled, moves to a predefined park position after homing instead of moving to origin. The park position is set using G28.1. description_bullets: - This is useful for moving the toolhead to a convenient access position after homing - Keeps the nozzle away from the bed after homing for safety - Useful for positioning for filament loading/unloading - 'IMPORTANT: Mutually exclusive with `move_to_origin_after_home`' - If `move_to_origin_after_home` is `true`, this setting is ignored (forced to `false`) - Park position is set with G28.1 command (saves current position as park position) - G28.1 X## Y## can set park position from config - Only XY coordinates are used for parking (Z is not moved) - Position is saved to config-override if M500 is used after G28.1 - Default park position is 0,0 until G28.1 is executed related_m_codes: - code: M500 description: Save park position to config-override related_settings: - move_to_origin_after_home related_pages: - endstops - endstops-options - guide-endstops examples: - 'park_after_home true # Move to park position after homing' - '# Set park position (in your start gcode or manually):' - '# G28.1 ; Save current position as park position' - '# Or in config-override.g:' - '# G28.1 X150 Y10 ; Set park position to X150 Y10' - name: alpha_trim_mm type: number default: 0 units: mm (for deltas), degrees (for rotary deltas) module: root context: Global setting - Delta/SCARA calibration defined_in: modules/tools/endstops/Endstops.cpp:69 corresponding_v1: alpha_trim_mm corresponding_v2: endstops.common.alpha_trim_mm description: Software trim for alpha tower/joint endstop on delta and SCARA machines. Compensates for small variations in endstop positions between towers. description_bullets: - Positive values move the effective endstop position toward the endstop (shortens tower) - Negative values move the effective endstop position away from the endstop (lengthens tower) - 'IMPORTANT: Only used on delta and SCARA machines - has no effect on Cartesian or CoreXY' - Units are millimeters for linear deltas, degrees for rotary deltas - Used during homing to adjust final position based on physical endstop variations - Set via M666 X## command (saved with M500 to config-override) - 'Typical values: -2.0 to +2.0 mm for linear deltas' - Fine-tune after basic calibration to improve bed levelness - For rotary deltas, values are in degrees, not millimeters - Applied in actuator space, affects cartesian position via forward kinematics - Helps compensate for endstops that are not perfectly aligned typical_values: - value: 0 description: no trim needed - value: 0.15 description: small correction - value: -0.2 description: opposite correction related_m_codes: - code: M666 description: Display all current trim values - code: M500 description: Save trim values to config-override related_settings: - beta_trim_mm - gamma_trim_mm - delta_homing - rdelta_homing related_pages: - endstops - endstops-options - delta - delta-calibration-strategy-options examples: - 'alpha_trim_mm 0 # No trim (default)' - 'alpha_trim_mm 0.15 # Alpha tower 0.15mm shorter' - 'alpha_trim_mm -0.2 # Alpha tower 0.2mm longer' - name: beta_trim_mm type: number default: 0 units: mm (for deltas), degrees (for rotary deltas) module: root context: Global setting - Delta/SCARA calibration defined_in: modules/tools/endstops/Endstops.cpp:70 corresponding_v1: beta_trim_mm corresponding_v2: endstops.common.beta_trim_mm description: Software trim for beta tower/joint endstop on delta and SCARA machines. Compensates for small variations in endstop positions between towers. description_bullets: - Positive values move the effective endstop position toward the endstop (shortens tower) - Negative values move the effective endstop position away from the endstop (lengthens tower) - 'IMPORTANT: Only used on delta and SCARA machines - has no effect on Cartesian or CoreXY' - Units are millimeters for linear deltas, degrees for rotary deltas - Used during homing to adjust final position based on physical endstop variations - Set via M666 Y## command (saved with M500 to config-override) - 'Typical values: -2.0 to +2.0 mm for linear deltas' - Fine-tune after basic calibration to improve bed levelness - For rotary deltas, values are in degrees, not millimeters - Applied in actuator space, affects cartesian position via forward kinematics - Helps compensate for endstops that are not perfectly aligned typical_values: - value: 0 description: no trim needed - value: 0.25 description: small correction - value: -0.15 description: opposite correction related_m_codes: - code: M666 description: Display all current trim values - code: M500 description: Save trim values to config-override related_settings: - alpha_trim_mm - gamma_trim_mm - delta_homing - rdelta_homing related_pages: - endstops - endstops-options - delta - delta-calibration-strategy-options examples: - 'beta_trim_mm 0 # No trim (default)' - 'beta_trim_mm 0.25 # Beta tower 0.25mm shorter' - 'beta_trim_mm -0.15 # Beta tower 0.15mm longer' - name: gamma_trim_mm type: number default: 0 units: mm (for deltas), degrees (for rotary deltas) module: root context: Global setting - Delta/SCARA calibration defined_in: modules/tools/endstops/Endstops.cpp:71 corresponding_v1: gamma_trim_mm corresponding_v2: endstops.common.gamma_trim_mm description: Software trim for gamma tower/joint endstop on delta and SCARA machines. Compensates for small variations in endstop positions between towers. description_bullets: - Positive values move the effective endstop position toward the endstop (shortens tower) - Negative values move the effective endstop position away from the endstop (lengthens tower) - 'IMPORTANT: Only used on delta and SCARA machines - has no effect on Cartesian or CoreXY' - Units are millimeters for linear deltas, degrees for rotary deltas - Used during homing to adjust final position based on physical endstop variations - Set via M666 Z## command (saved with M500 to config-override) - 'Typical values: -2.0 to +2.0 mm for linear deltas' - Fine-tune after basic calibration to improve bed levelness - For rotary deltas, values are in degrees, not millimeters - Applied in actuator space, affects cartesian position via forward kinematics - Helps compensate for endstops that are not perfectly aligned typical_values: - value: 0 description: no trim needed - value: -0.3 description: small correction - value: 0.1 description: opposite correction related_m_codes: - code: M666 description: Display all current trim values - code: M500 description: Save trim values to config-override related_settings: - alpha_trim_mm - beta_trim_mm - delta_homing - rdelta_homing related_pages: - endstops - endstops-options - delta - delta-calibration-strategy-options examples: - 'gamma_trim_mm 0 # No trim (default)' - 'gamma_trim_mm -0.3 # Gamma tower 0.3mm longer' - 'gamma_trim_mm 0.1 # Gamma tower 0.1mm shorter' - name: ZProbe & Leveling description: Bed probing and leveling strategies setting_count: 49 settings: - name: zprobe.enable type: bool default: false module: zprobe context: Global module setting defined_in: modules/tools/zprobe/ZProbe.cpp:63 corresponding_v1: zprobe.enable corresponding_v2: zprobe.enable description: Enables the Z-probe module for surface scanning, automatic calibration, and bed leveling compensation. When enabled, the probe can be used for single-point probing with G30, bed leveling with G32, and various leveling strategies. This setting is required for all leveling strategies to function. description_bullets: - The module is loaded only when enabled; when disabled, the module is deleted to free resources. - At least one leveling strategy should typically be enabled when the probe is enabled. related_settings: - zprobe.probe_pin - all leveling strategy enable settings related_pages: - zprobe - endstops - z-probe-guide - three-point-strategy-options examples: - 'zprobe.enable true # Enable Z-probe functionality' - 'zprobe.enable false # Disable to free memory if not using probe' - name: zprobe.probe_pin type: pin default: nc module: zprobe context: Global module setting defined_in: modules/tools/zprobe/ZProbe.cpp:81 required: false corresponding_v1: zprobe.probe_pin corresponding_v2: zprobe.probe_pin description: Specifies the GPIO pin connected to the Z-probe signal input. The probe is considered triggered when the pin reads high, or low if the inverting modifier is used. Pull-up resistors are typically needed for normally-open microswitch probes to prevent floating inputs. description_bullets: - Common configuration uses inverted logic with pull-up enabled for normally-open microswitch probes. - Inductive and capacitive probes typically don't need pull-ups. - Pin must be on a valid interrupt-capable port. related_settings: - zprobe.debounce_ms - zprobe.enable related_pages: - zprobe - pin-configuration - pinout - sensor-types examples: - 'zprobe.probe_pin 1.28!^ # Inverted with pull-up (typical for microswitch)' - 'zprobe.probe_pin 1.29 # Non-inverted (typical for inductive probe)' - 'zprobe.probe_pin nc # Explicitly not connected' - name: zprobe.debounce_ms type: number default: 0 units: milliseconds module: zprobe context: Global module setting defined_in: modules/tools/zprobe/ZProbe.cpp:82 corresponding_v1: zprobe.debounce_ms corresponding_v2: zprobe.debounce_ms description: Debounce time for the probe pin signal in milliseconds. The probe signal must remain triggered continuously for this duration before being considered a valid trigger. This prevents false triggers from electrical noise or mechanical bounce in switches. A value of 0 disables debouncing. description_bullets: - Set to 1-2ms for noisy mechanical probes or environments with electrical interference. - Piezoelectric probes may need higher values (5-10ms) due to their transient signal characteristics. - Too high a value can reduce probe accuracy by introducing lag. - Debouncing is implemented in firmware at 1kHz polling rate. typical_values: - value: 0 description: no debounce - value: 1 description: 1ms for mechanical probes - value: 2 description: 2ms for noisy environments related_m_codes: - code: M500 description: Save current debounce value to config-override related_settings: - zprobe.probe_pin - zprobe.slow_feedrate related_pages: - zprobe - sensor-types - troubleshooting examples: - 'zprobe.debounce_ms 0 # No debounce (clean signal)' - 'zprobe.debounce_ms 1 # 1ms debounce for mechanical switch' - 'zprobe.debounce_ms 5 # 5ms for piezo probe' - name: zprobe.slow_feedrate type: number default: 5 units: mm/sec module: zprobe context: Global module setting defined_in: modules/tools/zprobe/ZProbe.cpp:139 corresponding_v1: zprobe.slow_feedrate corresponding_v2: zprobe.slow_feedrate description: Speed at which the probe approaches and contacts the surface during actual probing operations. This is the critical speed that determines probe accuracy. Slower speeds provide more accurate and repeatable measurements by reducing momentum and allowing better signal detection, but increase total probing time. description_bullets: - Used during the final approach to the bed surface. - Lower speeds (2-5mm/s) recommended for best accuracy and repeatability. - Higher speeds (8-15mm/s) acceptable for less critical applications. - Speed affects probe triggering consistency and measurement precision. typical_values: - value: 5 description: default, balanced - value: 2 description: high precision - value: 10 description: faster probing related_m_codes: - code: M500 description: Save current slow feedrate to config-override related_settings: - zprobe.fast_feedrate - zprobe.return_feedrate - zprobe.debounce_ms related_pages: - zprobe - z-probe-guide - delta-calibration-strategy-options examples: - 'zprobe.slow_feedrate 5 # Default balanced speed' - 'zprobe.slow_feedrate 2 # High precision for critical measurements' - 'zprobe.slow_feedrate 10 # Faster for large grid leveling' - name: zprobe.fast_feedrate type: number default: 100 units: mm/sec module: zprobe context: Global module setting defined_in: modules/tools/zprobe/ZProbe.cpp:140 corresponding_v1: zprobe.fast_feedrate corresponding_v2: zprobe.fast_feedrate description: Speed for rapid travel moves between probe points during leveling operations. This speed does not affect probing accuracy as it is only used for non-probing moves. Higher values reduce total leveling time for grid-based strategies with many probe points. description_bullets: - Only used for XY travel moves between probe points. - Not used during actual Z probing operations. - Should not exceed the machine's maximum safe travel speed. - Caps the return_feedrate calculation when set to 0 (auto mode). typical_values: - value: 100 description: default - value: 50 description: conservative - value: 200 description: fast machines related_m_codes: - code: M500 description: Save current fast feedrate to config-override related_settings: - zprobe.slow_feedrate - zprobe.return_feedrate - motion_control.default_seek_rate related_pages: - zprobe - motion-control - z-probe-guide examples: - 'zprobe.fast_feedrate 100 # Default speed' - 'zprobe.fast_feedrate 50 # Conservative for heavy machines' - 'zprobe.fast_feedrate 200 # Fast travel for speed-optimized machines' - name: zprobe.return_feedrate type: number default: 0 units: mm/sec module: zprobe context: Global module setting defined_in: modules/tools/zprobe/ZProbe.cpp:141 corresponding_v1: zprobe.return_feedrate corresponding_v2: zprobe.return_feedrate description: Speed for retracting the probe after a successful probe operation. When set to 0, the firmware automatically calculates this as twice the slow_feedrate, capped at the fast_feedrate value. This provides a good balance between speed and safety during probe retraction. description_bullets: - 'Auto-calculation: return_feedrate = min(slow_feedrate * 2, fast_feedrate)' - Manual setting overrides auto-calculation. - Should be fast enough to save time but not so fast as to cause mechanical issues. - Only affects Z-axis retraction speed after probing. typical_values: - value: 0 description: auto - value: 50 description: manual setting - value: 20 description: slower return related_m_codes: - code: M500 description: Save current return feedrate to config-override related_settings: - zprobe.slow_feedrate - zprobe.fast_feedrate - zprobe.probe_height related_pages: - zprobe - z-probe-guide examples: - 'zprobe.return_feedrate 0 # Auto-calculate (recommended)' - 'zprobe.return_feedrate 50 # Manual 50mm/s return speed' - 'zprobe.return_feedrate 20 # Slower return for delicate probes' - name: zprobe.probe_height type: number default: 5 units: mm module: zprobe context: Global module setting defined_in: modules/tools/zprobe/ZProbe.cpp:138 corresponding_v1: zprobe.probe_height corresponding_v2: zprobe.probe_height description: Height above the bed surface where the probe positions itself between probe points during leveling operations. Once the bed's approximate height is known from the first probe, subsequent probes move to this height before traveling to the next XY position. This prevents the probe from dragging across the bed surface. description_bullets: - Must be high enough to clear all bed surface irregularities, clips, and obstacles. - Lower values reduce total probing time but increase risk of collision. - Higher values are safer but slower for multi-point leveling. - This is a Z-height above the triggering point, not an absolute machine coordinate. typical_values: - value: 5 description: default - value: 3 description: low clearance beds - value: 10 description: beds with large irregularities related_m_codes: - code: M500 description: Save current probe height to config-override related_settings: - zprobe.max_z - zprobe.return_feedrate related_pages: - zprobe - three-point-strategy-options - rectangular-grid-calibration-options examples: - 'zprobe.probe_height 5 # Default 5mm clearance' - 'zprobe.probe_height 3 # Low clearance for clean flat beds' - 'zprobe.probe_height 10 # High clearance for beds with clips' - name: zprobe.max_z type: number default: 200 units: mm module: zprobe context: Global module setting defined_in: modules/tools/zprobe/ZProbe.cpp:143 corresponding_v1: zprobe.max_z corresponding_v2: zprobe.max_travel description: Maximum distance the probe will travel downward when searching for the bed surface. This safety limit prevents the probe from crashing into the bed if it fails to trigger, protecting both the probe and the machine. If the probe doesn't trigger within this distance, the probing operation aborts with an error. description_bullets: - Falls back to gamma_max configuration value if not explicitly set. - Should be set to slightly more than the maximum expected Z travel distance. - Acts as a timeout/safety mechanism for probe failures. - Used in both single-point probing (G30) and leveling operations. typical_values: - value: 200 description: 200mm machines - value: 300 description: 300mm machines - value: 500 description: 500mm machines related_m_codes: - code: M500 description: Save current max_z value to config-override related_settings: - zprobe.probe_height - gamma_max - zprobe.reverse_z related_pages: - zprobe - endstops - gamma-max examples: - 'zprobe.max_z 200 # 200mm maximum travel' - 'zprobe.max_z 300 # 300mm for larger machines' - 'zprobe.max_z 100 # 100mm for delta printers (distance from home)' - name: zprobe.reverse_z type: bool default: false module: zprobe context: Global module setting defined_in: modules/tools/zprobe/ZProbe.cpp:142 corresponding_v1: zprobe.reverse_z corresponding_v2: zprobe.reverse_z description: Reverses the Z-axis direction for probing operations. Normally, probes move downward (negative Z direction) to find the bed. Setting this to true makes them move upward (positive Z direction) instead. This is rarely used and primarily intended for specialized machine configurations with inverted Z axes or overhead gantries. description_bullets: - 'Standard probing (false): probe moves down to find bed' - 'Reversed probing (true): probe moves up to find bed' - Does not affect normal motion, only probe moves - Used in conjunction with G30 R parameter for runtime override related_settings: - zprobe.max_z - gamma_homing_direction related_pages: - zprobe - endstops examples: - 'zprobe.reverse_z false # Normal downward probing (standard)' - 'zprobe.reverse_z true # Upward probing (specialized machines)' - name: zprobe.dwell_before_probing type: number default: 0 units: seconds module: zprobe context: Global module setting defined_in: modules/tools/zprobe/ZProbe.cpp:147 corresponding_v1: zprobe.dwell_before_probing corresponding_v2: zprobe.dwell_before_probing description: Pause duration in seconds before starting each probe move. This dwell time allows piezoelectric probes to settle after movement and prevents false triggers from residual vibration. Also useful for servo-deployed probes that need time to reach position. A value of 0 disables the dwell. description_bullets: - Essential for piezoelectric probes (0.1-0.5 seconds typical). - Helps reduce false triggers from mechanical vibration. - Increases total probing time proportionally to number of probe points. - Applied before every individual probe operation. typical_values: - value: 0 description: no dwell - value: 0.2 description: piezo probe - value: 0.5 description: long settling time related_m_codes: - code: M500 description: Save current dwell time to config-override related_settings: - zprobe.debounce_ms - zprobe.slow_feedrate related_pages: - zprobe - sensor-types - z-probe-guide examples: - 'zprobe.dwell_before_probing 0 # No dwell (mechanical switches)' - 'zprobe.dwell_before_probing 0.2 # 200ms for piezo probe' - 'zprobe.dwell_before_probing 0.5 # 500ms for long settling time' - name: leveling-strategy.three-point-leveling.enable type: bool default: false module: leveling-strategy.three-point-leveling context: Module instance setting defined_in: Standard module enable pattern corresponding_v1: leveling-strategy.three-point-leveling.enable corresponding_v2: zprobe.leveling (set to "three point") description: Enables the three-point leveling strategy which probes three user-defined points on the bed to calculate a plane equation. The strategy applies Z compensation during printing to maintain the nozzle parallel to the bed surface, correcting for bed tilt. This is the simplest leveling strategy and works well for flat beds with simple tilt. description_bullets: - Mutually exclusive with delta-calibration strategy (cannot both be enabled). - Requires three probe points to be defined via configuration or M557. - Best for beds that are flat but tilted, not for warped beds. - Applies plane compensation to all moves until cleared with M561. related_m_codes: - code: M561 description: Clear bed plane and disable compensation related_settings: - zprobe.enable - leveling-strategy.three-point-leveling.point1 - leveling-strategy.three-point-leveling.point2 - leveling-strategy.three-point-leveling.point3 related_pages: - zprobe - three-point-strategy-options - delta-calibration-strategy-options - rectangular-grid-calibration-options examples: - 'leveling-strategy.three-point-leveling.enable true # Enable three-point leveling' - name: leveling-strategy.three-point-leveling.point1 type: string default: none (must be explicitly set) units: mm module: leveling-strategy.three-point-leveling context: Module instance setting defined_in: modules/tools/zprobe/ThreePointStrategy.cpp:98 required: false corresponding_v1: leveling-strategy.three-point-leveling.point1 corresponding_v2: three point leveling strategy.point1 description: First probe point coordinates in machine coordinate system, specified as comma-separated X and Y values. The three points should ideally form an equilateral triangle and be positioned as far apart as possible within the printable area for maximum leveling accuracy. This point becomes the Z=0 reference after the first probe. description_bullets: - 'Format: X,Y (e.g., "100.0,0.0")' - Coordinates are in machine coordinate system, not work coordinates - Should be accessible by the probe without collisions - Distance between points affects leveling sensitivity related_m_codes: - code: M500 description: Save current point coordinates to config-override - code: M503 description: Display current point coordinates related_settings: - leveling-strategy.three-point-leveling.point2 - leveling-strategy.three-point-leveling.point3 - leveling-strategy.three-point-leveling.probe_offsets related_pages: - three-point-strategy-options - zprobe - z-probe-guide examples: - 'leveling-strategy.three-point-leveling.point1 100.0,0.0 # First probe point (front)' - 'leveling-strategy.three-point-leveling.point1 30,30 # Corner of build area' - name: leveling-strategy.three-point-leveling.point2 type: string default: none (must be explicitly set) units: mm module: leveling-strategy.three-point-leveling context: Module instance setting defined_in: modules/tools/zprobe/ThreePointStrategy.cpp:99 required: false corresponding_v1: leveling-strategy.three-point-leveling.point2 corresponding_v2: three point leveling strategy.point2 description: Second probe point coordinates in machine coordinate system. Should be positioned to form a triangle with point1 and point3, ideally an equilateral triangle for balanced leveling across the bed surface. The further apart the three points are, the better the leveling accuracy. description_bullets: - 'Format: X,Y (e.g., "200.0,200.0")' - Should be roughly equidistant from point1 and point3 - Must be within probe-reachable area related_m_codes: - code: M500 description: Save current point coordinates to config-override related_settings: - leveling-strategy.three-point-leveling.point1 - leveling-strategy.three-point-leveling.point3 related_pages: - three-point-strategy-options - zprobe examples: - 'leveling-strategy.three-point-leveling.point2 200.0,200.0 # Second probe point (back-right)' - name: leveling-strategy.three-point-leveling.point3 type: string default: none (must be explicitly set) units: mm module: leveling-strategy.three-point-leveling context: Module instance setting defined_in: modules/tools/zprobe/ThreePointStrategy.cpp:100 required: false corresponding_v1: leveling-strategy.three-point-leveling.point3 corresponding_v2: three point leveling strategy.point3 description: Third probe point coordinates in machine coordinate system. Completes the triangle with point1 and point2. The three points define the plane used for bed leveling compensation. Maximum leveling accuracy is achieved when the three points form a large equilateral triangle. description_bullets: - 'Format: X,Y (e.g., "0.0,200.0")' - Completes the triangle for plane calculation - Should maximize triangle area within printable region related_m_codes: - code: M500 description: Save current point coordinates to config-override related_settings: - leveling-strategy.three-point-leveling.point1 - leveling-strategy.three-point-leveling.point2 related_pages: - three-point-strategy-options - zprobe examples: - 'leveling-strategy.three-point-leveling.point3 0.0,200.0 # Third probe point (back-left)' - name: leveling-strategy.three-point-leveling.probe_offsets type: string default: 0,0,0 units: mm module: leveling-strategy.three-point-leveling context: Module instance setting defined_in: modules/tools/zprobe/ThreePointStrategy.cpp:106 corresponding_v1: leveling-strategy.three-point-leveling.probe_offsets corresponding_v2: three point leveling strategy.probe_offsets description: Offset of the probe tip from the nozzle tip in X, Y, and Z dimensions. These offsets are critical for accurate compensation as they tell the firmware where the probe is relative to the actual printing nozzle. Positive X means probe is to the right of nozzle, positive Y means probe is forward of nozzle, positive Z means probe trigger point is above nozzle tip. description_bullets: - 'Format: X,Y,Z (e.g., "0,0,0" or "-5,20,0.5")' - 'X offset: positive = probe right of nozzle, negative = probe left' - 'Y offset: positive = probe forward of nozzle, negative = probe behind' - 'Z offset: positive = probe trigger above nozzle, negative = trigger below' - Critical for accurate bed leveling compensation related_m_codes: - code: M500 description: Save current offsets to config-override - code: M503 description: Display current offsets related_settings: - zprobe.probe_pin - all three point coordinates related_pages: - three-point-strategy-options - zprobe - z-probe-guide examples: - 'leveling-strategy.three-point-leveling.probe_offsets 0,0,0 # Probe at nozzle tip' - 'leveling-strategy.three-point-leveling.probe_offsets -5,20,0 # Probe 5mm left, 20mm forward' - name: leveling-strategy.three-point-leveling.home_first type: bool default: true module: leveling-strategy.three-point-leveling context: Module instance setting defined_in: modules/tools/zprobe/ThreePointStrategy.cpp:109 corresponding_v1: leveling-strategy.three-point-leveling.home_first corresponding_v2: three point leveling strategy.home_first description: Automatically homes the X and Y axes before running the G32 bed leveling probe sequence. Homing ensures the machine is at a known position before probing begins, which is essential for accurate and repeatable leveling. Disable this only if you want manual control over homing or are using work coordinate system offsets. description_bullets: - Executes "G28 X0 Y0" before probing when enabled - Ensures consistent starting position for repeatability - Disable if using WCS offsets or custom homing procedures - Z axis is not homed to avoid probe collisions related_settings: - endstops.alpha_homing_direction - endstops.beta_homing_direction related_pages: - three-point-strategy-options - endstops - zprobe examples: - 'leveling-strategy.three-point-leveling.home_first true # Auto-home before probing (recommended)' - 'leveling-strategy.three-point-leveling.home_first false # Manual homing control' - name: leveling-strategy.three-point-leveling.tolerance type: number default: 0.03 units: mm module: leveling-strategy.three-point-leveling context: Module instance setting defined_in: modules/tools/zprobe/ThreePointStrategy.cpp:110 corresponding_v1: leveling-strategy.three-point-leveling.tolerance corresponding_v2: three point leveling strategy.tolerance description: Maximum acceptable difference in millimeters between the highest and lowest probe points. If the bed is flatter than this tolerance (difference between highest and lowest point is less than this value), no compensation plane is applied as the bed is considered flat enough. Also used to validate the first probe point repeatability. description_bullets: - 'If max_difference < tolerance: bed considered flat, no compensation applied' - 'If max_difference >= tolerance: compensation plane calculated and applied' - Prevents unnecessary compensation on already-flat beds - Also validates probe repeatability on first point - 0.03mm (30 microns) is typical for good quality beds typical_values: - value: 0.03 description: default - value: 0.01 description: high precision - value: 0.05 description: relaxed related_settings: - leveling-strategy.three-point-leveling.point1 - leveling-strategy.three-point-leveling.point2 - leveling-strategy.three-point-leveling.point3 related_pages: - three-point-strategy-options - zprobe examples: - 'leveling-strategy.three-point-leveling.tolerance 0.03 # Default 30 micron tolerance' - 'leveling-strategy.three-point-leveling.tolerance 0.01 # Tight 10 micron tolerance' - 'leveling-strategy.three-point-leveling.tolerance 0.05 # Relaxed 50 micron tolerance' - name: leveling-strategy.three-point-leveling.save_plane type: bool default: false module: leveling-strategy.three-point-leveling context: Module instance setting defined_in: modules/tools/zprobe/ThreePointStrategy.cpp:111 corresponding_v1: leveling-strategy.three-point-leveling.save_plane corresponding_v2: three point leveling strategy.save_plane description: Enables saving the calculated bed plane to config-override when M500 is issued. When enabled, the plane parameters (A, B, C, D coefficients) are saved and can be restored later with M561 using those parameters. This allows you to save a known-good bed level and reload it without re-probing. description_bullets: - 'When enabled: M500 saves "M561 A B C D" to config-override' - 'Plane can be restored with: M561 A B C D' - Useful for saving a good calibration, but bed changes require re-probing - Plane remains in effect until M561 clears it related_m_codes: - code: M500 description: Save plane coefficients to config-override (if enabled) - code: M561 description: Clear plane, or restore with A B C D parameters - code: M503 description: Display current settings including saved plane status related_settings: - leveling-strategy.three-point-leveling.enable related_pages: - three-point-strategy-options - zprobe examples: - 'leveling-strategy.three-point-leveling.save_plane false # Don''t save plane (default)' - 'leveling-strategy.three-point-leveling.save_plane true # Enable plane saving with M500' - name: leveling-strategy.delta-calibration.enable type: bool default: false module: leveling-strategy.delta-calibration context: Module instance setting defined_in: Standard module enable pattern corresponding_v1: leveling-strategy.delta-calibration.enable corresponding_v2: zprobe.calibration (set to "delta") description: Enables the delta calibration strategy for automatically calibrating linear delta printer geometry. The strategy probes seven points (three at towers, three between towers, one at center) and adjusts endstop trim values and delta radius to minimize height differences. This strategy is specifically for delta kinematics and is automatically loaded for delta printers if no other strategy is specified. description_bullets: - Only for linear delta printers (not Cartesian or CoreXY) - Mutually exclusive with three-point-leveling strategy - Automatically loaded as default for delta printers - Calibrates endstop offsets and delta radius parameters - Requires multiple iterations to converge on solution related_m_codes: [] related_settings: - zprobe.enable - arm_solution - leveling-strategy.delta-calibration.radius - (must be linear_delta) related_pages: - zprobe - delta-calibration-strategy-options - delta - arm-solutions examples: - 'leveling-strategy.delta-calibration.enable true # Enable delta calibration' - name: leveling-strategy.delta-calibration.radius type: number default: 100 units: mm module: leveling-strategy.delta-calibration context: Module instance setting defined_in: modules/tools/zprobe/DeltaCalibrationStrategy.cpp:30 corresponding_v1: leveling-strategy.delta-calibration.radius corresponding_v2: delta calibration strategy.radius description: 'Radius in millimeters at which to probe the bed for delta calibration. This determines the size of the circular pattern formed by the seven probe points: three points at the tower positions on this radius, three points between towers on this radius, and one point at center (radius 0). The radius should be as large as possible while staying within the printable area.' description_bullets: - Larger radius provides more accurate calibration data - Must stay within probe-reachable area (considering probe offsets) - Three tower points positioned at 0°, 120°, 240° around circle - Three inter-tower points positioned at 60°, 180°, 300° around circle - Falls back to deprecated zprobe.probe_radius if not set typical_values: - value: 100 description: typical delta - value: 75 description: small delta - value: 130 description: large delta related_m_codes: - code: M500 description: Save current radius to config-override related_settings: - leveling-strategy.delta-calibration.initial_height - arm_radius - arm_length related_pages: - delta-calibration-strategy-options - delta - zprobe examples: - 'leveling-strategy.delta-calibration.radius 100 # 100mm probe radius' - 'leveling-strategy.delta-calibration.radius 75 # Smaller radius for compact deltas' - name: leveling-strategy.delta-calibration.initial_height type: number default: 10 units: mm (absolute Z position) module: leveling-strategy.delta-calibration context: Module instance setting defined_in: modules/tools/zprobe/DeltaCalibrationStrategy.cpp:39 corresponding_v1: leveling-strategy.delta-calibration.initial_height corresponding_v2: delta calibration strategy.initial_height description: Absolute Z machine position in millimeters to move to after homing and before starting the initial bed probe. This height must be high enough that the probe will not hit the bed during the rapid descent phase. This is a critical safety parameter that prevents crashes during the first probe approach. description_bullets: - This is an ABSOLUTE Z machine coordinate, not relative - Should be 5-15mm above expected bed trigger point - 'Too low: risk of probe crashing into bed' - 'Too high: wastes time during descent' - Used for the first "find bed" operation only typical_values: - value: 10 description: default - value: 5 description: low height - value: 15 description: conservative related_settings: - leveling-strategy.delta-calibration.radius - zprobe.slow_feedrate - zprobe.fast_feedrate related_pages: - delta-calibration-strategy-options - delta - zprobe - troubleshooting examples: - 'leveling-strategy.delta-calibration.initial_height 10 # 10mm initial height (default)' - 'leveling-strategy.delta-calibration.initial_height 5 # Lower for known good setup' - 'leveling-strategy.delta-calibration.initial_height 15 # Conservative for first-time setup' - name: leveling-strategy.delta-grid.enable type: bool default: false module: leveling-strategy.delta-grid context: Module instance setting defined_in: Standard module enable pattern corresponding_v1: leveling-strategy.delta-grid.enable corresponding_v2: zprobe.leveling (set to "delta grid") description: Enables the delta grid leveling strategy for height mapping across circular delta printer beds. The strategy probes a grid of points in a circular pattern (skipping corners outside the radius) and stores height offsets. During printing, the firmware interpolates between the nearest four grid points to calculate Z compensation for any XY position. description_bullets: - Specifically for delta printers with circular beds - Creates a height map for compensating non-flat beds - Grid points outside the radius are automatically skipped - Interpolation provides smooth compensation between probe points - Grid data can be saved to SD card and auto-loaded on boot related_m_codes: - code: M374 description: Save grid to /sd/delta.grid - code: M375 description: Load grid from /sd/delta.grid and enable compensation related_settings: - zprobe.enable - leveling-strategy.delta-grid.radius - leveling-strategy.delta-grid.size related_pages: - zprobe - delta-grid-calibration-options - delta - rectangular-grid-calibration-options examples: - 'leveling-strategy.delta-grid.enable true # Enable delta grid leveling' - name: leveling-strategy.delta-grid.radius type: number default: 50 units: mm module: leveling-strategy.delta-grid context: Module instance setting defined_in: modules/tools/zprobe/DeltaGridStrategy.cpp:116 corresponding_v1: leveling-strategy.delta-grid.radius corresponding_v2: delta grid leveling strategy.radius description: Radius of the circular bed area to probe and compensate in millimeters. The grid probes a square region, but points outside this radius are skipped, creating a circular probe pattern. This radius should be at least as large as the maximum printing radius to ensure full bed compensation coverage. description_bullets: - Grid points beyond this radius are not probed or compensated - Should match or exceed maximum print radius - Larger radius covers more area but increases probe time - Circular pattern optimized for delta printer beds typical_values: - value: 50 description: small delta - value: 80 description: medium delta - value: 120 description: large delta related_m_codes: - code: M500 description: Save current radius to config-override related_settings: - leveling-strategy.delta-grid.size - arm_radius related_pages: - delta-grid-calibration-options - delta - zprobe examples: - 'leveling-strategy.delta-grid.radius 50 # 50mm radius' - 'leveling-strategy.delta-grid.radius 80 # 80mm for medium delta' - 'leveling-strategy.delta-grid.radius 120 # 120mm for large delta' - name: leveling-strategy.delta-grid.size type: number default: 7 units: N/A (grid dimension) module: leveling-strategy.delta-grid context: Module instance setting defined_in: modules/tools/zprobe/DeltaGridStrategy.cpp:111 corresponding_v1: leveling-strategy.delta-grid.size corresponding_v2: delta grid leveling strategy.size description: Grid size in both X and Y dimensions, determining the total number of probe points. A size of 7 creates a 7×7 grid = 49 potential probe points (points outside the radius are automatically skipped). Larger grids provide more accurate compensation but increase probing time significantly. description_bullets: - Total probe points = size × size (minus points outside radius) - Larger grids = more accuracy but longer probe time - 'Typical sizes: 5 (fast), 7 (balanced), 9 (accurate)' - Must be odd to have a center point typical_values: - value: 7 description: 49 points - value: 5 description: 25 points - value: 9 description: 81 points related_m_codes: - code: M500 description: Save current size to config-override related_settings: - leveling-strategy.delta-grid.radius - zprobe.slow_feedrate related_pages: - delta-grid-calibration-options - zprobe examples: - 'leveling-strategy.delta-grid.size 7 # 7×7 grid, 49 points (default)' - 'leveling-strategy.delta-grid.size 5 # 5×5 grid, 25 points (faster)' - 'leveling-strategy.delta-grid.size 9 # 9×9 grid, 81 points (more accurate)' - name: leveling-strategy.delta-grid.probe_offsets type: string default: 0,0,0 units: mm module: leveling-strategy.delta-grid context: Module instance setting defined_in: modules/tools/zprobe/DeltaGridStrategy.cpp:124 corresponding_v1: leveling-strategy.delta-grid.probe_offsets corresponding_v2: delta grid leveling strategy.probe_offsets description: Offset of the probe tip from the nozzle tip in X, Y, and Z dimensions. These offsets compensate for the physical displacement between where the probe triggers and where the nozzle actually is. Correct offsets are essential for accurate bed compensation. description_bullets: - 'Format: X,Y,Z (e.g., "0,0,0" or "-10,5,0.2")' - 'X offset: positive = probe right of nozzle, negative = left' - 'Y offset: positive = probe forward of nozzle, negative = behind' - 'Z offset: positive = probe trigger above nozzle, negative = below' related_m_codes: - code: M500 description: Save current offsets to config-override related_settings: - zprobe.probe_pin - leveling-strategy.delta-grid.radius related_pages: - delta-grid-calibration-options - zprobe - z-probe-guide examples: - 'leveling-strategy.delta-grid.probe_offsets 0,0,0 # Probe at nozzle position' - 'leveling-strategy.delta-grid.probe_offsets -10,5,0 # Probe 10mm left, 5mm forward' - name: leveling-strategy.delta-grid.initial_height type: number default: 10 units: mm (absolute Z position) module: leveling-strategy.delta-grid context: Module instance setting defined_in: modules/tools/zprobe/DeltaGridStrategy.cpp:120 corresponding_v1: leveling-strategy.delta-grid.initial_height corresponding_v2: delta grid leveling strategy.initial_height description: Absolute Z machine position in millimeters to move to after homing before starting the grid probe sequence. This safety parameter prevents the probe from crashing into the bed during the initial descent. Must be high enough to clear the bed surface. description_bullets: - Absolute Z coordinate, not relative height - Should be 5-15mm above expected bed surface - Used only for initial positioning before grid probing starts typical_values: - value: 10 description: default - value: 5 description: low - value: 15 description: conservative related_settings: - zprobe.probe_height - leveling-strategy.delta-grid.radius related_pages: - delta-grid-calibration-options - zprobe examples: - 'leveling-strategy.delta-grid.initial_height 10 # 10mm initial height (default)' - 'leveling-strategy.delta-grid.initial_height 5 # Lower for known setup' - name: leveling-strategy.delta-grid.do_home type: bool default: true module: leveling-strategy.delta-grid context: Module instance setting defined_in: modules/tools/zprobe/DeltaGridStrategy.cpp:114 corresponding_v1: leveling-strategy.delta-grid.do_home corresponding_v2: delta grid leveling strategy.do_home description: Automatically homes all axes before running the G31 grid probing sequence. Homing ensures the machine is at a known position before probing, which is essential for repeatable and accurate grid generation. Disable only if you want manual control over the homing process. description_bullets: - Executes full delta home (all towers) before probing - Ensures consistent starting position for grid accuracy - Disable for manual homing or custom pre-probe routines related_settings: - endstops.delta_homing - leveling-strategy.delta-grid.initial_height related_pages: - delta-grid-calibration-options - endstops - delta examples: - 'leveling-strategy.delta-grid.do_home true # Auto-home before probing (recommended)' - 'leveling-strategy.delta-grid.do_home false # Manual homing control' - name: leveling-strategy.delta-grid.save type: bool default: false module: leveling-strategy.delta-grid context: Module instance setting defined_in: modules/tools/zprobe/DeltaGridStrategy.cpp:113 corresponding_v1: leveling-strategy.delta-grid.save corresponding_v2: delta grid leveling strategy.save description: Automatically saves M375 command to config-override when M500 is issued, causing the grid to be loaded from /sd/delta.grid on boot and compensation to be enabled automatically. This allows persistent bed leveling across power cycles without re-probing. description_bullets: - 'When enabled: M500 saves "M375" to config-override' - Grid file must be created first with M374 - On boot, grid is loaded and compensation enabled automatically - Disable to require manual M375 after each boot related_m_codes: - code: M374 description: Save grid to /sd/delta.grid (must do this first) - code: M375 description: Load grid from /sd/delta.grid (auto-added to config-override if save=true) - code: M500 description: Trigger saving M375 to config-override related_settings: - leveling-strategy.delta-grid.enable related_pages: - delta-grid-calibration-options - zprobe - sd-card examples: - 'leveling-strategy.delta-grid.save false # Don''t auto-load grid on boot (default)' - 'leveling-strategy.delta-grid.save true # Auto-load grid on boot' - name: leveling-strategy.delta-grid.tolerance type: number default: 0.03 units: mm module: leveling-strategy.delta-grid context: Module instance setting defined_in: modules/tools/zprobe/DeltaGridStrategy.cpp:112 corresponding_v1: leveling-strategy.delta-grid.tolerance corresponding_v2: delta grid leveling strategy.tolerance description: Probe tolerance for repeatability checks and validation during grid creation. Used to validate that probe measurements are consistent and repeatable across multiple probes of the same point. description_bullets: - Validates probe repeatability during grid creation - Ensures probe quality before grid is accepted - 0.03mm (30 microns) is typical for good probe repeatability typical_values: - value: 0.03 description: default - value: 0.01 description: tight - value: 0.05 description: relaxed related_settings: - zprobe.debounce_ms - zprobe.slow_feedrate related_pages: - delta-grid-calibration-options - zprobe examples: - 'leveling-strategy.delta-grid.tolerance 0.03 # Default 30 micron tolerance' - 'leveling-strategy.delta-grid.tolerance 0.01 # Tight 10 micron tolerance' - name: leveling-strategy.delta-grid.is_square type: bool default: false module: leveling-strategy.delta-grid context: Module instance setting (DEPRECATED) defined_in: modules/tools/zprobe/DeltaGridStrategy.cpp:115 deprecated: false corresponding_v1: leveling-strategy.delta-grid.is_square corresponding_v2: none (feature removed) description: '**DEPRECATED** - This setting is no longer supported and will produce an error if used. For square or rectangular beds, use the rectangular-grid strategy instead of delta-grid.' description_bullets: - Setting this will cause an error message - Use leveling-strategy.rectangular-grid for non-circular beds related_pages: - delta-grid-calibration-options - rectangular-grid-calibration-options examples: - '# Do not use - deprecated and will error' - name: leveling-strategy.rectangular-grid.enable type: bool default: false module: leveling-strategy.rectangular-grid context: Module instance setting defined_in: Standard module enable pattern corresponding_v1: leveling-strategy.rectangular-grid.enable corresponding_v2: zprobe.leveling (set to "cartesian grid") description: Enables the rectangular grid leveling strategy for Cartesian and CoreXY machines. The strategy probes a rectangular area with configurable dimensions and grid density, storing height offsets at each point. During printing, interpolation between the nearest four grid points provides smooth Z compensation across the entire bed. description_bullets: - For Cartesian, CoreXY, H-Bot, and other rectangular bed machines - Creates rectangular height map for non-flat bed compensation - Grid dimensions and point density fully configurable - Supports both fixed-area and two-corners modes - Grid can be saved to SD and auto-loaded on boot related_m_codes: - code: M374 description: Save grid to /sd/cartesian.grid (or cartesian_nm.grid for non-square) - code: M375 description: Load grid from SD and enable compensation related_settings: - zprobe.enable - leveling-strategy.rectangular-grid.x_size - leveling-strategy.rectangular-grid.y_size related_pages: - zprobe - rectangular-grid-calibration-options - pcb-milling - three-point-strategy-options examples: - 'leveling-strategy.rectangular-grid.enable true # Enable rectangular grid leveling' - name: leveling-strategy.rectangular-grid.size type: number default: 7 units: N/A (grid dimension) module: leveling-strategy.rectangular-grid context: Module instance setting defined_in: modules/tools/zprobe/CartGridStrategy.cpp:145 corresponding_v1: leveling-strategy.rectangular-grid.size corresponding_v2: cartesian grid leveling strategy.size description: Default grid size for both X and Y dimensions if grid_x_size and grid_y_size are not explicitly specified. Must be an odd number to ensure a center point exists. This is a fallback value; specifying grid_x_size and grid_y_size directly allows non-square grids. description_bullets: - Used only if grid_x_size and grid_y_size are not defined - Overridden by explicit grid_x_size / grid_y_size settings - Total points = size × size (for square grids) - Must be odd for proper interpolation typical_values: - value: 7 description: 49 points - value: 5 description: 25 points - value: 9 description: 81 points related_m_codes: [] related_settings: - leveling-strategy.rectangular-grid.grid_x_size - leveling-strategy.rectangular-grid.grid_y_size related_pages: - rectangular-grid-calibration-options - zprobe examples: - 'leveling-strategy.rectangular-grid.size 7 # 7×7 grid fallback (default)' - 'leveling-strategy.rectangular-grid.size 5 # 5×5 grid fallback' - name: leveling-strategy.rectangular-grid.grid_x_size type: number default: 7 units: N/A (grid dimension) module: leveling-strategy.rectangular-grid context: Module instance setting defined_in: modules/tools/zprobe/CartGridStrategy.cpp:146 corresponding_v1: leveling-strategy.rectangular-grid.grid_x_size corresponding_v2: cartesian grid leveling strategy.grid_x_size description: Number of probe points in the X dimension, allowing rectangular (non-square) grids. If both grid_x_size and grid_y_size are specified, they override the 'size' setting. This enables different resolutions in X and Y directions for beds with different characteristics. description_bullets: - Allows rectangular grids (different X and Y point counts) - Overrides 'size' setting when specified with grid_y_size - Must be odd number for center point - More points = higher accuracy but longer probe time typical_values: - value: 7 description: default - value: 9 description: more detail in X - value: 5 description: faster related_m_codes: [] related_settings: - leveling-strategy.rectangular-grid.grid_y_size - leveling-strategy.rectangular-grid.size related_pages: - rectangular-grid-calibration-options - zprobe examples: - 'leveling-strategy.rectangular-grid.grid_x_size 9 # 9 points in X direction' - 'leveling-strategy.rectangular-grid.grid_x_size 7 # 7 points in X direction' - name: leveling-strategy.rectangular-grid.grid_y_size type: number default: 7 units: N/A (grid dimension) module: leveling-strategy.rectangular-grid context: Module instance setting defined_in: modules/tools/zprobe/CartGridStrategy.cpp:147 corresponding_v1: leveling-strategy.rectangular-grid.grid_y_size corresponding_v2: cartesian grid leveling strategy.grid_y_size description: Number of probe points in the Y dimension, allowing rectangular (non-square) grids. When specified together with grid_x_size, enables non-square grids tailored to bed dimensions. Must be odd to ensure proper interpolation with a center point. description_bullets: - Allows rectangular grids (different X and Y point counts) - Must be odd for center point - Works with grid_x_size to define grid shape typical_values: - value: 7 description: default - value: 5 description: fewer points in Y - value: 9 description: more detail in Y related_m_codes: [] related_settings: - leveling-strategy.rectangular-grid.grid_x_size - leveling-strategy.rectangular-grid.size related_pages: - rectangular-grid-calibration-options - zprobe examples: - 'leveling-strategy.rectangular-grid.grid_y_size 7 # 7 points in Y direction' - 'leveling-strategy.rectangular-grid.grid_y_size 5 # 5 points for shorter Y axis' - name: leveling-strategy.rectangular-grid.x_size type: number default: none (must be explicitly set) units: mm module: leveling-strategy.rectangular-grid context: Module instance setting defined_in: modules/tools/zprobe/CartGridStrategy.cpp:170 required: false corresponding_v1: leveling-strategy.rectangular-grid.x_size corresponding_v2: cartesian grid leveling strategy.x_size description: Width of the rectangular bed area to probe in the X dimension, measured in millimeters. This defines the total X extent of the probing area. The grid points are evenly distributed across this width. This is a required setting for the rectangular grid strategy to function. description_bullets: - Defines bed width for probing - Grid points evenly spaced across this dimension - Must be set in config, no default - Can be overridden at runtime with G31/G32 X parameter related_m_codes: [] related_settings: - leveling-strategy.rectangular-grid.y_size - leveling-strategy.rectangular-grid.grid_x_size related_pages: - rectangular-grid-calibration-options - zprobe examples: - 'leveling-strategy.rectangular-grid.x_size 200 # 200mm wide bed' - 'leveling-strategy.rectangular-grid.x_size 300 # 300mm wide bed' - name: leveling-strategy.rectangular-grid.y_size type: number default: none (must be explicitly set) units: mm module: leveling-strategy.rectangular-grid context: Module instance setting defined_in: modules/tools/zprobe/CartGridStrategy.cpp:171 required: false corresponding_v1: leveling-strategy.rectangular-grid.y_size corresponding_v2: cartesian grid leveling strategy.y_size description: Length of the rectangular bed area to probe in the Y dimension, measured in millimeters. This defines the total Y extent of the probing area. The grid points are evenly distributed across this length. This is a required setting for the rectangular grid strategy to function. description_bullets: - Defines bed length for probing - Grid points evenly spaced across this dimension - Must be set in config, no default - Can be overridden at runtime with G31/G32 Y parameter related_m_codes: [] related_settings: - leveling-strategy.rectangular-grid.x_size - leveling-strategy.rectangular-grid.grid_y_size related_pages: - rectangular-grid-calibration-options - zprobe examples: - 'leveling-strategy.rectangular-grid.y_size 200 # 200mm deep bed' - 'leveling-strategy.rectangular-grid.y_size 250 # 250mm deep bed' - name: leveling-strategy.rectangular-grid.probe_offsets type: string default: 0,0,0 units: mm module: leveling-strategy.rectangular-grid context: Module instance setting defined_in: modules/tools/zprobe/CartGridStrategy.cpp:184 corresponding_v1: leveling-strategy.rectangular-grid.probe_offsets corresponding_v2: cartesian grid leveling strategy.probe_offsets description: Offset of the probe tip from the nozzle tip in X, Y, and Z dimensions. These offsets are critical for accurate positioning as they tell the firmware where the probe actually is relative to the print nozzle. The Z offset is typically 0 for this strategy as it uses relative height mapping. description_bullets: - 'Format: X,Y,Z (e.g., "0,0,0" or "15,-10,0")' - 'X offset: positive = probe right, negative = probe left of nozzle' - 'Y offset: positive = probe forward, negative = probe behind nozzle' - 'Z offset: typically 0 for rectangular grid strategy' related_m_codes: - code: M500 description: Save current offsets to config-override related_settings: - zprobe.probe_pin - leveling-strategy.rectangular-grid.x_size related_pages: - rectangular-grid-calibration-options - zprobe - z-probe-guide examples: - 'leveling-strategy.rectangular-grid.probe_offsets 0,0,0 # Probe at nozzle position' - 'leveling-strategy.rectangular-grid.probe_offsets 15,-10,0 # Probe 15mm right, 10mm back' - name: leveling-strategy.rectangular-grid.initial_height type: number default: null units: mm (absolute Z position) module: leveling-strategy.rectangular-grid context: Module instance setting defined_in: modules/tools/zprobe/CartGridStrategy.cpp:179 corresponding_v1: leveling-strategy.rectangular-grid.initial_height corresponding_v2: cartesian grid leveling strategy.initial_height description: Optional absolute Z machine position in millimeters to move to before starting the grid probe. If not set (NAN) or ≤0, probing starts from the current Z position. When set to a valid positive value, provides a safety feature by ensuring the probe starts from a known height above the bed. description_bullets: - 'NAN or ≤0: start probing from current position (default)' - 'Positive value: move to this absolute Z before probing' - This is an ABSOLUTE Z machine coordinate - Requires correct Z homing for proper operation - Optional safety feature, not required typical_values: - value: NAN description: disabled, default - value: 10 description: 10mm height - value: 5 description: low height related_settings: - zprobe.probe_height - leveling-strategy.rectangular-grid.do_home related_pages: - rectangular-grid-calibration-options - zprobe examples: - '# leveling-strategy.rectangular-grid.initial_height not set (disabled by default)' - 'leveling-strategy.rectangular-grid.initial_height 10 # Start from 10mm absolute Z' - name: leveling-strategy.rectangular-grid.do_home type: bool default: true module: leveling-strategy.rectangular-grid context: Module instance setting defined_in: modules/tools/zprobe/CartGridStrategy.cpp:154 corresponding_v1: leveling-strategy.rectangular-grid.do_home corresponding_v2: cartesian grid leveling strategy.do_home description: Automatically home before running G31/G32 probing operations (unless in two-corners mode or R1 is specified in the G-code command). Homing ensures the machine starts from a known position for repeatable and accurate grid generation. Can be disabled for manual homing control. description_bullets: - Executes homing before probing sequence - Skipped in two-corners mode - Skipped if R1 parameter present in G31/G32 - Ensures consistent starting position related_settings: - endstops.alpha_homing_direction - leveling-strategy.rectangular-grid.only_by_two_corners related_pages: - rectangular-grid-calibration-options - endstops - zprobe examples: - 'leveling-strategy.rectangular-grid.do_home true # Auto-home before probing (recommended)' - 'leveling-strategy.rectangular-grid.do_home false # Manual homing control' - name: leveling-strategy.rectangular-grid.save type: bool default: false module: leveling-strategy.rectangular-grid context: Module instance setting defined_in: modules/tools/zprobe/CartGridStrategy.cpp:153 corresponding_v1: leveling-strategy.rectangular-grid.save corresponding_v2: cartesian grid leveling strategy.save description: Automatically saves M375 command to config-override when M500 is issued, causing the grid to be loaded from /sd/cartesian.grid (or /sd/cartesian_nm.grid for non-square grids) on boot. Enables persistent bed leveling across power cycles without re-probing every time. description_bullets: - 'When enabled: M500 saves "M375" to config-override' - Grid file must be created first with M374 - On boot, grid automatically loaded and compensation enabled - Requires M374 to save grid before enabling related_m_codes: - code: M374 description: Save grid to /sd/cartesian.grid or /sd/cartesian_nm.grid - code: M375 description: Load grid and enable compensation (auto-added to config-override) - code: M500 description: Trigger saving M375 command related_settings: - leveling-strategy.rectangular-grid.enable related_pages: - rectangular-grid-calibration-options - zprobe - sd-card examples: - 'leveling-strategy.rectangular-grid.save false # Don''t auto-load grid (default)' - 'leveling-strategy.rectangular-grid.save true # Auto-load grid on boot' - name: leveling-strategy.rectangular-grid.tolerance type: number default: 0.03 units: mm module: leveling-strategy.rectangular-grid context: Module instance setting defined_in: modules/tools/zprobe/CartGridStrategy.cpp:152 corresponding_v1: leveling-strategy.rectangular-grid.tolerance corresponding_v2: cartesian grid leveling strategy.tolerance description: Probe tolerance in millimeters for repeatability validation during grid creation. Used to verify that probe measurements are consistent and repeatable, ensuring the grid data is reliable before it is used for compensation. description_bullets: - Validates probe consistency during grid generation - Ensures reliable grid data quality - 0.03mm (30 microns) is typical for good probes typical_values: - value: 0.03 description: default - value: 0.01 description: tight - value: 0.05 description: relaxed related_settings: - zprobe.debounce_ms - zprobe.slow_feedrate related_pages: - rectangular-grid-calibration-options - zprobe examples: - 'leveling-strategy.rectangular-grid.tolerance 0.03 # Default 30 micron tolerance' - 'leveling-strategy.rectangular-grid.tolerance 0.01 # Tight 10 micron tolerance' - name: leveling-strategy.rectangular-grid.only_by_two_corners type: bool default: false module: leveling-strategy.rectangular-grid context: Module instance setting defined_in: modules/tools/zprobe/CartGridStrategy.cpp:155 corresponding_v1: leveling-strategy.rectangular-grid.only_by_two_corners corresponding_v2: cartesian grid leveling strategy.only_by_two_corners description: 'Enables two-corners mode where G31/G32 requires XYAB parameters instead of using pre-configured dimensions. In this mode: XY defines the starting position, A defines width, B defines length from that position. This allows dynamic probe area definition but prevents grid saving. Mode can be toggled at runtime with G32 R1 (enable) or R0 (disable).' description_bullets: - 'When enabled: G31/G32 requires X Y A B parameters' - 'X,Y: start position coordinates' - 'A: width from start position' - 'B: length from start position' - Cannot save grid in this mode - 'Runtime toggle: G32 R1 (enable) / R0 (disable)' related_m_codes: [] related_settings: - leveling-strategy.rectangular-grid.x_size - leveling-strategy.rectangular-grid.y_size related_pages: - rectangular-grid-calibration-options - pcb-milling examples: - 'leveling-strategy.rectangular-grid.only_by_two_corners false # Use fixed grid (default)' - 'leveling-strategy.rectangular-grid.only_by_two_corners true # Enable two-corners mode' - name: leveling-strategy.rectangular-grid.human_readable type: bool default: false module: leveling-strategy.rectangular-grid context: Module instance setting defined_in: modules/tools/zprobe/CartGridStrategy.cpp:156 corresponding_v1: leveling-strategy.rectangular-grid.human_readable corresponding_v2: cartesian grid leveling strategy.human_readable description: Changes the grid display format for M375.1 from raw values to a human-readable table with coordinates. When enabled, the output includes X and Y coordinates for each grid point along with the height value, making it easier to understand and visualize the bed topology. description_bullets: - 'false: raw height values only' - 'true: formatted table with X, Y, Z coordinates' - Only affects M375.1 display output - Does not affect grid functionality or saved format related_m_codes: [] related_settings: - leveling-strategy.rectangular-grid.enable related_pages: - rectangular-grid-calibration-options - zprobe examples: - 'leveling-strategy.rectangular-grid.human_readable false # Raw values (default)' - 'leveling-strategy.rectangular-grid.human_readable true # Formatted table' - name: leveling-strategy.rectangular-grid.height_limit type: number default: null units: mm module: leveling-strategy.rectangular-grid context: Module instance setting defined_in: modules/tools/zprobe/CartGridStrategy.cpp:159 corresponding_v1: leveling-strategy.rectangular-grid.height_limit corresponding_v2: cartesian grid leveling strategy.height_limit description: Maximum Z height in millimeters where bed compensation is applied. Above this height, no compensation is added to Z moves. Used together with dampening_start to create a fade zone where compensation gradually reduces from 100% to 0%. Prevents compensation from affecting tall prints unnecessarily. description_bullets: - Compensation disabled above this height - Requires dampening_start to be set for fade zone - 'NAN: compensation applied at all heights (default)' - 'Positive value: compensation fades out and stops at this height' typical_values: - value: NAN description: disabled - value: 10 description: fade at 10mm - value: 5 description: fade at 5mm related_settings: - leveling-strategy.rectangular-grid.dampening_start related_pages: - rectangular-grid-calibration-options - zprobe examples: - '# leveling-strategy.rectangular-grid.height_limit not set (disabled, default)' - 'leveling-strategy.rectangular-grid.height_limit 10 # No compensation above 10mm' - name: leveling-strategy.rectangular-grid.dampening_start type: number default: null units: mm module: leveling-strategy.rectangular-grid context: Module instance setting defined_in: modules/tools/zprobe/CartGridStrategy.cpp:160 corresponding_v1: leveling-strategy.rectangular-grid.dampening_start corresponding_v2: cartesian grid leveling strategy.dampening_start description: Z height in millimeters where bed compensation begins to fade out. Between dampening_start and height_limit, compensation is linearly scaled from 100% to 0%. This creates a smooth transition zone where compensation gradually reduces, preventing abrupt changes in Z movement. description_bullets: - 'Compensation fade zone: dampening_start to height_limit' - 'Below dampening_start: 100% compensation' - 'Within zone: linear interpolation from 100% to 0%' - 'Above height_limit: 0% compensation' - Requires height_limit to be set - 'NAN: no fade zone (default)' typical_values: - value: NAN description: disabled - value: 5 description: start fade at 5mm - value: 3 description: start fade at 3mm related_settings: - leveling-strategy.rectangular-grid.height_limit related_pages: - rectangular-grid-calibration-options - zprobe examples: - '# leveling-strategy.rectangular-grid.dampening_start not set (disabled, default)' - 'leveling-strategy.rectangular-grid.dampening_start 5 # Start fading at 5mm' - name: leveling-strategy.rectangular-grid.m_attach type: bool default: false module: leveling-strategy.rectangular-grid context: Module instance setting defined_in: modules/tools/zprobe/CartGridStrategy.cpp:157 corresponding_v1: leveling-strategy.rectangular-grid.m_attach corresponding_v2: cartesian grid leveling strategy.m_attach description: Enables manual probe attachment mode for removable probes. Before probing begins, the machine moves to the mount_position and waits for the user to manually attach the probe and trigger it to signal readiness. This allows use of removable probes that are not permanently mounted on the tool head. description_bullets: - Machine moves to mount_position before probing - Waits for user to attach probe and trigger it - Useful for removable probes (like manual touch probes) - Requires mount_position to be defined related_settings: - leveling-strategy.rectangular-grid.mount_position related_pages: - rectangular-grid-calibration-options - zprobe - sensor-types examples: - 'leveling-strategy.rectangular-grid.m_attach false # No manual attachment (default)' - 'leveling-strategy.rectangular-grid.m_attach true # Enable manual probe attachment' - name: leveling-strategy.rectangular-grid.mount_position type: string default: 0,0,50 units: mm module: leveling-strategy.rectangular-grid context: Module instance setting defined_in: modules/tools/zprobe/CartGridStrategy.cpp:194 corresponding_v1: leveling-strategy.rectangular-grid.mount_position corresponding_v2: cartesian grid leveling strategy.mount_position description: Position in machine coordinates where the machine moves and waits for manual probe attachment when m_attach is enabled. Should be a safe, easily accessible position where the operator can comfortably attach the removable probe. Only used if m_attach is set to true. description_bullets: - 'Format: X,Y,Z (e.g., "0,0,50" or "100,100,30")' - Position should be safe and accessible - Only used if m_attach is enabled - Machine waits at this position for probe attachment related_settings: - leveling-strategy.rectangular-grid.m_attach related_pages: - rectangular-grid-calibration-options - zprobe examples: - 'leveling-strategy.rectangular-grid.mount_position 0,0,50 # Default attachment position' - 'leveling-strategy.rectangular-grid.mount_position 100,100,30 # Center of bed, low height' - name: leveling-strategy.rectangular-grid.before_probe_gcode type: string default: '""' module: leveling-strategy.rectangular-grid context: Module instance setting defined_in: modules/tools/zprobe/CartGridStrategy.cpp:210 corresponding_v1: leveling-strategy.rectangular-grid.before_probe_gcode corresponding_v2: cartesian grid leveling strategy.before_probe_gcode description: G-code command to execute before each individual probing operation. Use underscore `_` as space separator in the command string. Commonly used to deploy servo-actuated probes like BLTouch. The underscore characters are automatically converted to spaces before execution. description_bullets: - Executed before every single probe point - Use underscore (_) in place of spaces - 'Example: "M280_S10" becomes "M280 S10"' - 'Common use: BLTouch probe deployment' related_settings: - leveling-strategy.rectangular-grid.after_probe_gcode related_pages: - rectangular-grid-calibration-options - zprobe - sensor-types examples: - '# leveling-strategy.rectangular-grid.before_probe_gcode (empty by default)' - 'leveling-strategy.rectangular-grid.before_probe_gcode M280_S10 # Deploy BLTouch' - name: leveling-strategy.rectangular-grid.after_probe_gcode type: string default: '""' module: leveling-strategy.rectangular-grid context: Module instance setting defined_in: modules/tools/zprobe/CartGridStrategy.cpp:211 corresponding_v1: leveling-strategy.rectangular-grid.after_probe_gcode corresponding_v2: cartesian grid leveling strategy.after_probe_gcode description: G-code command to execute after each individual probing operation. Use underscore `_` as space separator in the command string. Commonly used to retract servo-actuated probes like BLTouch. The underscore characters are automatically converted to spaces before execution. description_bullets: - Executed after every single probe point - Use underscore (_) in place of spaces - 'Example: "M281_S90" becomes "M281 S90"' - 'Common use: BLTouch probe retraction' related_settings: - leveling-strategy.rectangular-grid.before_probe_gcode related_pages: - rectangular-grid-calibration-options - zprobe - sensor-types examples: - '# leveling-strategy.rectangular-grid.after_probe_gcode (empty by default)' - 'leveling-strategy.rectangular-grid.after_probe_gcode M281_S90 # Retract BLTouch' - name: Panel/Display description: LCD panel and interface settings setting_count: 36 settings: - name: panel.enable type: bool default: false module: panel context: Global module setting defined_in: src/modules/utils/panel/Panel.cpp:110 corresponding_v1: panel.enable corresponding_v2: display.enable description: Enables the panel interface module. Panels provide a screen, an encoder wheel and/or a set of buttons, used to control your machine without requiring a computer connection. When enabled, the panel module initializes the LCD driver, configures input devices, and registers for system events to display machine status and accept user input. description_bullets: - Multiple panel types are supported through the `panel.lcd` setting. - If disabled or not configured, the panel module is completely removed from memory. - The panel provides standalone machine control including file selection, temperature adjustment, manual jogging, and G-code execution. related_pages: - panel - panel-guide - panel-options examples: - 'panel.enable true # Enable panel interface' - 'panel.enable false # Disable panel (default)' - name: panel.lcd type: enum default: reprap_discount_glcd module: panel context: Global module setting defined_in: src/modules/utils/panel/Panel.cpp:117 corresponding_v1: panel.lcd corresponding_v2: none (v2 has limited panel support with different panel types) description: Specifies the type of panel connected to the Smoothieboard. Each panel has a specific interface and driver requirements, so the correct panel type must be specified. The value determines which panel driver will be loaded and initialized. Different panels have different pin requirements, button configurations, and display capabilities. description_bullets: - The panel type selection affects which other settings are required or optional. - RRD GLCD does not support SPI CS pin sharing and requires dedicated SPI port. - OLED displays (SSD1306, SH1106) require additional A0 and RST pins for initialization. - Viki2 panels support red/blue LED indicators for heating status. - Universal Adapter supports daisy-chaining multiple devices via busy pin polling. related_pages: - panel - panel-guide - rrdglcdadapter examples: - 'panel.lcd reprap_discount_glcd # Most common panel type' - 'panel.lcd viki2 # Panucatt Viki2 with status LEDs' - 'panel.lcd ssd1306_oled # Small OLED display' - name: panel.spi_channel type: number default: 0 module: panel context: Global module setting defined_in: src/modules/utils/panel/Panel.cpp:145 corresponding_v1: panel.spi_channel corresponding_v2: none (v2 uses different pin notation and SPI configuration) description: Selects which SPI channel to use for panel communication. The Smoothieboard has two SPI channels with different pin assignments. Channel selection affects which physical pins are used for MOSI (Master Out Slave In), MISO (Master In Slave Out), and SCLK (Serial Clock) signals. Most panels use channel 0 by default. description_bullets: - Channel 0 is the default and most commonly used SPI channel. - Channel 1 can be used if channel 0 is needed for other devices. - Both panel and external SD card can share the same SPI channel with different CS pins. - Consult the Smoothieboard pinout diagram to identify available SPI pins. related_settings: - panel.spi_cs_pin - panel.spi_frequency - panel.external_sd.spi_channel related_pages: - panel - pinout - pin-configuration examples: - 'panel.spi_channel 0 # Use default SPI channel (most common)' - 'panel.spi_channel 1 # Use alternate SPI channel' - name: panel.spi_cs_pin type: pin default: nc module: panel context: Global module setting defined_in: src/modules/utils/panel/panels/ReprapDiscountGLCD.cpp:35 corresponding_v1: panel.spi_cs_pin corresponding_v2: PD3 description: Specifies the CS (Chip Select) pin used to select the panel device on the SPI bus. CS allows multiple devices to share the same SPI port by activating only the selected device. When CS is low (active), the panel responds to SPI commands; when high (inactive), the panel ignores SPI traffic. description_bullets: - 'CRITICAL: RepRap Discount GLCD does not support CS and requires being alone on its SPI port.' - ST7565 panels typically use pin 0.16 as default. - Each device on the SPI bus must have a unique CS pin. - Setting to `nc` disables chip select which may cause communication conflicts. related_settings: - panel.spi_channel - panel.spi_frequency related_pages: - panel - pinout - pin-configuration examples: - 'panel.spi_cs_pin 0.16 # Common for ST7565 panels' - 'panel.spi_cs_pin 1.23 # Alternative CS pin' - 'panel.spi_cs_pin nc # No chip select (RRD GLCD only)' - name: panel.spi_frequency type: number default: 1000000 units: Hz (Hertz) module: panel context: Global module setting defined_in: src/modules/utils/panel/panels/ReprapDiscountGLCD.cpp:41 corresponding_v1: panel.spi_frequency corresponding_v2: none (v2 uses different SPI configuration approach) description: Sets the SPI communication frequency in Hertz for the panel interface. Higher frequencies allow faster screen updates and more responsive display refresh, but may cause communication errors if the panel cannot keep up with the data rate. The optimal frequency depends on the panel type, cable quality, and cable length. description_bullets: - Default 1 MHz works reliably for most panels with typical cable lengths. - Higher frequencies (2-4 MHz) can improve refresh rate on fast panels. - Lower frequencies (500 kHz) may be needed for long cables or noisy environments. - Too high frequency causes display artifacts, garbled text, or complete communication failure. - SPI frequency affects both command and data transfer rates to the panel. typical_values: - value: 500000 description: 500 kHz, conservative - value: 1000000 description: 1 MHz, standard - value: 2000000 description: 2 MHz, fast but may cause errors related_settings: - panel.spi_channel - panel.spi_cs_pin related_pages: - panel - panel-options examples: - 'panel.spi_frequency 1000000 # 1 MHz (standard, reliable)' - 'panel.spi_frequency 500000 # 500 kHz (conservative for long cables)' - 'panel.spi_frequency 2000000 # 2 MHz (fast, test for stability)' - name: panel.contrast type: number default: Varies by panel (9 for ST7565/Viki2, 18 for Mini Viki2, 15 for SH1106) module: panel context: Global module setting defined_in: src/modules/utils/panel/Panel.cpp:158 minimum_value: '`0` (lowest contrast, may be invisible)' maximum_value: '`31` (implementation dependent, 31 is common maximum for ST7565-based controllers)' corresponding_v1: panel.contrast corresponding_v2: none (v2 has limited panel support) description: Sets the display contrast value for panels that support contrast adjustment (Viki2, Mini Viki2, ST7565_glcd, and OLED displays). Higher values increase contrast making text darker/more visible, while lower values decrease contrast making text lighter/less visible. Optimal value depends on viewing angle, ambient lighting conditions, and panel characteristics. description_bullets: - Only applicable to panels with contrast control hardware (not RRD GLCD). - Different panel types have different optimal contrast ranges. - Contrast may need adjustment based on room lighting and viewing angle. - Too low contrast makes display unreadable in bright light. - Too high contrast can cause ghosting or reduce display lifespan on OLED panels. typical_values: - value: 9 description: ST7565, Viki2 - value: 15 description: SH1106 OLED - value: 18 description: Mini Viki2 related_pages: - panel - panel-options examples: - 'panel.contrast 9 # Standard for ST7565 and Viki2' - 'panel.contrast 15 # Good for SH1106 OLED' - 'panel.contrast 18 # Default for Mini Viki2' - name: panel.reverse type: bool default: false module: panel context: Global module setting defined_in: src/modules/utils/panel/ST7565.cpp:161 corresponding_v1: panel.reverse corresponding_v2: none (v2 has limited panel support) description: When set to true, reverses the screen display by rotating it 180 degrees. This setting is useful when the panel is physically mounted upside down or when the display orientation needs to be flipped for mechanical reasons. The reversal affects both the pixel addressing and the COM (common) line scanning direction. description_bullets: - Automatically set to true for Viki2 and Mini Viki2 panels due to their physical design. - Does not affect button or encoder operation, only display orientation. - Useful for mechanical installations where the panel must be mounted inverted. - Setting applies to both text and graphics rendering. related_settings: - panel.lcd related_pages: - panel - panel-options examples: - 'panel.reverse false # Normal orientation (default for most panels)' - 'panel.reverse true # Upside down orientation (default for Viki2)' - name: panel.menu_offset type: number default: 0 module: panel context: Global module setting defined_in: src/modules/utils/panel/Panel.cpp:163 corresponding_v1: panel.menu_offset corresponding_v2: none (v2 has different menu navigation approach) description: Configures the number of lines to offset the menu lines by on screen, effectively controlling how many encoder clicks are required to move one menu position. When set to 1, the encoder requires 2 clicks to move one menu line, which is useful for high-resolution encoders that have more detents per revolution. This setting helps adapt encoder sensitivity to user preference and encoder hardware characteristics. description_bullets: - On some panels, this value must be set to 1 for proper operation with high-resolution encoders. - Setting to 1 provides finer control and reduces accidental menu skipping. - Setting to 0 provides faster menu navigation with fewer encoder turns required. - This is an end-user usability setting that depends on encoder hardware and personal preference. related_settings: - panel.encoder_resolution related_pages: - panel - panel-options examples: - 'panel.menu_offset 0 # Standard encoder (1 click = 1 menu line)' - 'panel.menu_offset 1 # High-resolution encoder (2 clicks = 1 menu line)' - name: panel.encoder_a_pin type: pin default: nc module: panel context: Global module setting defined_in: src/modules/utils/panel/panels/ReprapDiscountGLCD.cpp:29 corresponding_v1: panel.encoder_a_pin corresponding_v2: none (v2 uses different pin notation format) description: Specifies the A pin for the rotary encoder wheel. Encoders have two output pins (A and B) that generate quadrature signals as the encoder is rotated. The firmware reads both pins to determine rotation direction and count encoder pulses. The `^` modifier defines menu move direction (when used, inverts the default direction). The `!` modifier inverts the signal polarity. description_bullets: - Encoders require both A and B pins to be configured for proper operation. - Set to `nc` if you use no encoder (button-only panel navigation). - The `^` pull-up modifier is recommended for reliable encoder reading. - Encoder pins must support high-speed input reading (avoid slow I2C-based pins). - Pin inversion (`!`) may be needed depending on encoder hardware design. related_settings: - panel.encoder_b_pin - panel.encoder_resolution related_pages: - panel - pinout - pin-configuration examples: - 'panel.encoder_a_pin 3.25!^ # Port 3 pin 25, inverted with pull-up' - 'panel.encoder_a_pin 1.20^ # Port 1 pin 20, pull-up enabled' - 'panel.encoder_a_pin nc # No encoder connected' - name: panel.encoder_b_pin type: pin default: nc module: panel context: Global module setting defined_in: src/modules/utils/panel/panels/ReprapDiscountGLCD.cpp:30 corresponding_v1: panel.encoder_b_pin corresponding_v2: none (v2 uses different pin notation format) description: Specifies the B pin for the rotary encoder wheel. Encoders have two output pins (A and B) that generate quadrature signals 90 degrees out of phase as the encoder is rotated. The firmware reads both pins together with encoder_a_pin to determine rotation direction and count encoder pulses. The `^` modifier defines menu move direction (when used, inverts the default direction). The `!` modifier inverts the signal polarity. description_bullets: - Encoders require both A and B pins to be configured for proper operation. - Set to `nc` if you use no encoder (button-only panel navigation). - The `^` pull-up modifier is recommended for reliable encoder reading. - Encoder B pin must be on the same port as encoder A pin on some hardware. - Phase relationship between A and B signals determines rotation direction. related_settings: - panel.encoder_a_pin - panel.encoder_resolution related_pages: - panel - pinout - pin-configuration examples: - 'panel.encoder_b_pin 3.26!^ # Port 3 pin 26, inverted with pull-up' - 'panel.encoder_b_pin 1.21^ # Port 1 pin 21, pull-up enabled' - 'panel.encoder_b_pin nc # No encoder connected' - name: panel.encoder_resolution type: number default: 2 module: panel context: Global module setting defined_in: src/modules/utils/panel/Panel.cpp:166 corresponding_v1: panel.encoder_resolution corresponding_v2: none (v2 has different encoder configuration) description: Specifies the number of pulses the encoder emits per physical detent (click position). This value is used to convert raw encoder pulse counts into meaningful menu navigation clicks. Standard encoders typically emit 2 or 4 pulses per detent. Setting this correctly ensures that each encoder click moves the menu by exactly one position. description_bullets: - Default value is typically 2 for standard 20-detent encoders. - High-resolution encoders may use 4 pulses per detent. - Incorrect value causes menu to skip positions or require multiple clicks per movement. - Some panels override this value based on their specific encoder hardware. - This setting is independent of `menu_offset` which provides additional click multiplication. typical_values: - value: 2 description: standard 20-detent encoders - value: 4 description: high-resolution encoders with more pulses per detent related_settings: - panel.encoder_a_pin - panel.encoder_b_pin - panel.menu_offset related_pages: - panel - panel-options examples: - 'panel.encoder_resolution 2 # Standard encoder (most common)' - 'panel.encoder_resolution 4 # High-resolution encoder' - 'panel.encoder_resolution 1 # Low-resolution encoder (rare)' - name: panel.click_button_pin type: pin default: nc module: panel context: Global module setting defined_in: src/modules/utils/panel/panels/ReprapDiscountGLCD.cpp:31 corresponding_v1: panel.click_button_pin corresponding_v2: none (v2 has different button configuration) description: Specifies the pin for the click ("enter" or "select") button on the panel. This button is typically pressed to select menu items, confirm actions, and accept value changes. The `!` modifier inverts the signal polarity (use for active-low buttons). The `^` modifier enables the internal pull-up resistor (recommended for most button configurations). description_bullets: - The click button is the primary selection mechanism for menu navigation. - Most encoder wheels have an integrated click button activated by pressing the encoder shaft. - Active-low buttons (ground when pressed) require the `!` modifier. - Pull-up resistor (`^`) is required unless external pull-up is provided. - Button debouncing is handled automatically by the firmware. related_settings: - panel.back_button_pin - panel.encoder_a_pin related_pages: - panel - pinout - pin-configuration examples: - 'panel.click_button_pin 1.30!^ # Active-low with pull-up (common)' - 'panel.click_button_pin 2.11^ # Active-high with pull-up' - 'panel.click_button_pin nc # No click button' - name: panel.back_button_pin type: pin default: nc module: panel context: Global module setting defined_in: src/modules/utils/panel/panels/ReprapDiscountGLCD.cpp:33 corresponding_v1: panel.back_button_pin corresponding_v2: none (v2 has different button configuration) description: Specifies the pin for the back ("escape" or "cancel") button on the panel. This button returns to the previous menu level or cancels the current operation. On Viki2 panels, this pin may be used for either back button or pause button functionality (configure only one, not both). description_bullets: - The back button allows navigation to higher menu levels without scrolling. - Not all panels have a dedicated back button (some use long-press of click button). - On Viki2, choose either `back_button_pin` or `pause_button_pin`, not both. - Active-low buttons (ground when pressed) require the `!` modifier. - Pull-up resistor (`^`) is required unless external pull-up is provided. related_settings: - panel.pause_button_pin - panel.click_button_pin related_pages: - panel - panel-options examples: - 'panel.back_button_pin 2.11!^ # Active-low with pull-up (common)' - 'panel.back_button_pin 1.22^ # Active-high with pull-up' - 'panel.back_button_pin nc # No back button' - name: panel.up_button_pin type: pin default: nc module: panel context: Global module setting defined_in: src/modules/utils/panel/ST7565.cpp:118 corresponding_v1: panel.up_button_pin corresponding_v2: none (v2 has different button configuration) description: Specifies the pin for the up button which moves up in menus or increments values. This button is typically found on panels without rotary encoders (button-only navigation panels). Not used on panels with encoders such as Viki2, Mini Viki2, and SSD1306 OLED which use encoder rotation for up/down navigation. description_bullets: - Only needed for button-only panels (no encoder). - Panels with encoders (Viki2, Mini Viki2, SSD1306) do not use up/down buttons. - Active-low buttons (ground when pressed) require the `!` modifier. - Pull-up resistor (`^` or external) is required for reliable button detection. - Up/down buttons provide alternative navigation when encoder is not available. related_settings: - panel.down_button_pin - panel.encoder_a_pin related_pages: - panel - panel-options examples: - 'panel.up_button_pin 0.1! # Active-low button' - 'panel.up_button_pin 1.25^ # Active-high with pull-up' - 'panel.up_button_pin nc # No up button (encoder navigation)' - name: panel.down_button_pin type: pin default: nc module: panel context: Global module setting defined_in: src/modules/utils/panel/ST7565.cpp:119 corresponding_v1: panel.down_button_pin corresponding_v2: none (v2 has different button configuration) description: Specifies the pin for the down button which moves down in menus or decrements values. This button is typically found on panels without rotary encoders (button-only navigation panels). Not used on panels with encoders such as Viki2, Mini Viki2, and SSD1306 OLED which use encoder rotation for up/down navigation. description_bullets: - Only needed for button-only panels (no encoder). - Panels with encoders (Viki2, Mini Viki2, SSD1306) do not use up/down buttons. - Active-low buttons (ground when pressed) require the `!` modifier. - Pull-up resistor (`^` or external) is required for reliable button detection. - Up/down buttons provide alternative navigation when encoder is not available. related_settings: - panel.up_button_pin - panel.encoder_b_pin related_pages: - panel - panel-options examples: - 'panel.down_button_pin 0.0! # Active-low button' - 'panel.down_button_pin 1.26^ # Active-high with pull-up' - 'panel.down_button_pin nc # No down button (encoder navigation)' - name: panel.pause_button_pin type: pin default: nc module: panel context: Global module setting defined_in: src/modules/utils/panel/panels/ReprapDiscountGLCD.cpp:32 corresponding_v1: panel.pause_button_pin corresponding_v2: none (v2 has different button configuration) description: Specifies the pin for the pause button which immediately pauses print jobs when pressed. This button provides emergency pause functionality directly from the panel without navigating through menus. On Viki2 panels, this pin may be shared with the back button functionality - configure only one, not both. description_bullets: - Pause button provides immediate print suspension without menu navigation. - On Viki2, you must choose either `pause_button_pin` or `back_button_pin`, not both. - Active-low buttons (ground when pressed) require the `!` modifier. - Pull-up resistor (`^` or external) is required for reliable button detection. - Paused jobs can be resumed from the panel menu or via G-code commands. related_settings: - panel.back_button_pin - panel.click_button_pin related_pages: - panel - kill-pause-button examples: - 'panel.pause_button_pin nc # No pause button (default)' - 'panel.pause_button_pin 2.12!^ # Active-low with pull-up' - 'panel.pause_button_pin 1.28^ # Active-high with pull-up' - name: panel.longpress_delay type: number default: 0 units: milliseconds module: panel context: Global module setting defined_in: src/modules/utils/panel/Panel.cpp:185-190 corresponding_v1: panel.longpress_delay corresponding_v2: none (v2 has different button handling) description: Specifies the delay in milliseconds before a button press is considered a "long press" rather than a normal press. When set to 0, long press detection is disabled and all button presses are treated as normal presses. Long press can trigger alternative button actions on up and down buttons, providing additional functionality from limited button sets. description_bullets: - Setting to 0 disables long press functionality entirely (all presses are normal). - Longer delays reduce accidental long press triggers but slow down intentional long press actions. - Shorter delays make long press more responsive but increase accidental triggers. - Currently only implemented for up and down buttons, not for click, back, or pause buttons. - Long press actions are panel-screen dependent and may not be implemented on all screens. related_settings: - panel.up_button_pin - panel.down_button_pin related_pages: - panel - panel-options examples: - 'panel.longpress_delay 0 # Disable long press (default)' - 'panel.longpress_delay 1000 # 1 second hold for long press' - 'panel.longpress_delay 500 # 0.5 second hold (responsive)' - name: panel.buzz_pin type: pin default: nc module: panel context: Global module setting defined_in: src/modules/utils/panel/panels/ReprapDiscountGLCD.cpp:34 corresponding_v1: panel.buzz_pin corresponding_v2: none (v2 has different buzzer configuration) description: Specifies the pin for the buzzer which provides audible feedback when buttons are clicked and for system alerts. The buzzer produces short beeps to confirm button presses, alert the user to warnings, and indicate completion of operations. If set to `nc`, buzzer functionality is disabled but the panel continues to operate normally without audio feedback. description_bullets: - Buzzer provides tactile confirmation that button presses were registered. - Click sounds are generated at 300 Hz for 60 milliseconds by default. - Buzzer pin must be capable of high-frequency PWM output. - If no buzzer is connected, set to `nc` to avoid wasting processing time. - Some panels have built-in buzzers, others require external piezo buzzer connection. related_settings: - panel.click_button_pin related_pages: - panel - pinout examples: - 'panel.buzz_pin 1.31 # Enable buzzer on pin 1.31' - 'panel.buzz_pin 2.4 # Alternative buzzer pin' - 'panel.buzz_pin nc # No buzzer (silent operation)' - name: panel.red_led_pin type: pin default: nc module: panel context: Global module setting defined_in: src/modules/utils/panel/panels/ST7565.cpp:151 corresponding_v1: panel.red_led_pin corresponding_v2: none (v2 does not support Viki2 panels) description: Specifies the pin for the red LED indicator used on Viki2 panels to indicate heating status. The red LED turns on when the hotend is actively heating, providing visual feedback of heater operation. This LED is only used on Viki2 panels and should be set to `nc` for other panel types. description_bullets: - Only applicable to Viki2 panels which have built-in red/blue status LEDs. - Red LED indicates heating status (on when heating, off when at temperature). - Blue LED and red LED states are mutually exclusive on Viki2. - Other panel types should leave this setting at `nc`. - LED control is automatic based on temperature control module status. related_settings: - panel.blue_led_pin - panel.lcd related_pages: - panel - temperaturecontrol examples: - 'panel.red_led_pin nc # No red LED (default for non-Viki2 panels)' - 'panel.red_led_pin 2.5 # Red LED pin for Viki2' - 'panel.red_led_pin 1.18 # Alternative red LED pin' - name: panel.blue_led_pin type: pin default: nc module: panel context: Global module setting defined_in: src/modules/utils/panel/panels/ST7565.cpp:152 corresponding_v1: panel.blue_led_pin corresponding_v2: none (v2 does not support Viki2 panels) description: Specifies the pin for the blue LED indicator used on Viki2 panels to indicate normal operation status. The blue LED turns on when the system is ready and not actively heating, complementing the red LED for heating status. This LED is only used on Viki2 panels and should be set to `nc` for other panel types. description_bullets: - Only applicable to Viki2 panels which have built-in red/blue status LEDs. - Blue LED indicates normal ready status (on when ready, off when heating). - Blue LED and red LED states are mutually exclusive on Viki2. - Other panel types should leave this setting at `nc`. - LED control is automatic based on temperature control module status. related_settings: - panel.red_led_pin - panel.lcd related_pages: - panel - temperaturecontrol examples: - 'panel.blue_led_pin nc # No blue LED (default for non-Viki2 panels)' - 'panel.blue_led_pin 2.6 # Blue LED pin for Viki2' - 'panel.blue_led_pin 1.19 # Alternative blue LED pin' - name: panel.a0_pin type: pin default: nc module: panel context: Global module setting defined_in: src/modules/utils/panel/panels/ST7565.cpp:114 corresponding_v1: panel.a0_pin corresponding_v2: none (v2 has different panel support) description: Specifies the A0 (also called C/D for Command/Data or D/C for Data/Command) pin required for Viki2 and SSD1306 OLED displays. This pin selects between command mode (low) and data mode (high) for SPI communication with the display controller. The A0 pin controls whether bytes sent over SPI are interpreted as commands or display data. description_bullets: - Required for Viki2, Mini Viki2, SSD1306, and SH1106 OLED displays. - Not used by RepRap Discount GLCD or Universal Adapter panels. - A0 high = data mode (send pixel/text data), A0 low = command mode (send control commands). - Must be connected to the panel's A0/DC/CD pin for proper operation. - Incorrect or missing A0 pin causes display initialization failure or garbled display. related_settings: - panel.rst_pin - panel.lcd related_pages: - panel - panel-options examples: - 'panel.a0_pin nc # Not needed for RRD GLCD' - 'panel.a0_pin 2.6 # Required for Viki2/OLED displays' - 'panel.a0_pin 0.18 # Alternative A0 pin' - name: panel.rst_pin type: pin default: nc module: panel context: Global module setting defined_in: src/modules/utils/panel/panels/ST7565.cpp:110 corresponding_v1: panel.rst_pin corresponding_v2: none (v2 has different panel support) description: Specifies the RST (reset) pin required for some OLED displays (SSD1306, SH1106). This pin is connected to the display's hardware reset input and is used to perform a hardware reset of the display controller during initialization. A hardware reset ensures the display starts in a known state before software configuration. description_bullets: - Required for some SSD1306 and SH1106 OLED displays. - Not typically required for Viki2, Mini Viki2, or ST7565 displays. - Not used by RepRap Discount GLCD or Universal Adapter panels. - 'Reset sequence: drive low for 20µs, then high to release reset.' - Some OLED modules have built-in reset circuits and don't require external RST pin. related_settings: - panel.a0_pin - panel.lcd related_pages: - panel - panel-options examples: - 'panel.rst_pin nc # Not needed for most panels (default)' - 'panel.rst_pin 2.7 # RST pin for OLED displays that require it' - 'panel.rst_pin 0.19 # Alternative RST pin' - name: panel.busy_pin type: pin default: nc module: panel context: Global module setting defined_in: src/modules/utils/panel/panels/UniversalAdapter.cpp:55 corresponding_v1: panel.busy_pin corresponding_v2: none (v2 does not support Universal Adapter) description: Specifies the busy pin used only with the Universal Adapter panel type. This pin can be connected to the adapter to query its busy status before sending commands. The firmware polls this pin before transmitting data to prevent buffer overruns when the adapter is processing previous commands or updating the display. description_bullets: - Only applicable to Universal Adapter panel type. - Not used by any other panel types (RRD GLCD, Viki2, ST7565, OLED). - Busy pin allows flow control between Smoothieboard and Universal Adapter. - When busy pin is high, adapter is processing and should not receive new commands. - If not connected, set to `nc` and firmware will not poll busy status. related_settings: - panel.lcd related_pages: - panel - panel-options examples: - 'panel.busy_pin nc # No busy pin (default for non-Universal Adapter)' - 'panel.busy_pin 2.8 # Busy pin for Universal Adapter' - 'panel.busy_pin 1.23 # Alternative busy pin' - name: panel.alpha_jog_feedrate type: number default: 6000 units: mm/min (millimeters per minute) module: panel context: Global module setting defined_in: src/modules/utils/panel/Panel.cpp:169 corresponding_v1: panel.alpha_jog_feedrate corresponding_v2: none (v2 has different jogging configuration) description: Specifies the X axis (alpha motor) jogging feedrate in millimeters per minute when using the panel's manual control menu. This speed is used when manually moving the X axis using the panel interface without running G-code files. The speed should be set slower than the axis maximum speed for safety and precise manual positioning. description_bullets: - Used only during manual jogging from panel menus, not during G-code execution. - Value is in mm/min (divide by 60 to get mm/s). - Default 6000 mm/min equals 100 mm/s. - Should be significantly slower than `alpha_max_rate` for safe manual control. - Slower speeds provide finer positioning control, faster speeds reduce positioning time. typical_values: - value: 3000 description: 50 mm/s, slow - value: 6000 description: 100 mm/s, standard - value: 9000 description: 150 mm/s, fast related_settings: - panel.beta_jog_feedrate - panel.gamma_jog_feedrate - alpha_max_rate related_pages: - panel - motion-control - endstops examples: - 'panel.alpha_jog_feedrate 6000 # 100 mm/s (standard, default)' - 'panel.alpha_jog_feedrate 3000 # 50 mm/s (precise control)' - 'panel.alpha_jog_feedrate 9000 # 150 mm/s (fast positioning)' - name: panel.beta_jog_feedrate type: number default: 6000 units: mm/min (millimeters per minute) module: panel context: Global module setting defined_in: src/modules/utils/panel/Panel.cpp:170 corresponding_v1: panel.beta_jog_feedrate corresponding_v2: none (v2 has different jogging configuration) description: Specifies the Y axis (beta motor) jogging feedrate in millimeters per minute when using the panel's manual control menu. This speed is used when manually moving the Y axis using the panel interface without running G-code files. The speed should be set slower than the axis maximum speed for safety and precise manual positioning. description_bullets: - Used only during manual jogging from panel menus, not during G-code execution. - Value is in mm/min (divide by 60 to get mm/s). - Default 6000 mm/min equals 100 mm/s. - Should be significantly slower than `beta_max_rate` for safe manual control. - Typically set to same value as `alpha_jog_feedrate` for consistent XY jogging. typical_values: - value: 3000 description: 50 mm/s, slow - value: 6000 description: 100 mm/s, standard - value: 9000 description: 150 mm/s, fast related_settings: - panel.alpha_jog_feedrate - panel.gamma_jog_feedrate - beta_max_rate related_pages: - panel - motion-control - endstops examples: - 'panel.beta_jog_feedrate 6000 # 100 mm/s (standard, default)' - 'panel.beta_jog_feedrate 3000 # 50 mm/s (precise control)' - 'panel.beta_jog_feedrate 9000 # 150 mm/s (fast positioning)' - name: panel.gamma_jog_feedrate type: number default: 200 units: mm/min (millimeters per minute) module: panel context: Global module setting defined_in: src/modules/utils/panel/Panel.cpp:171 corresponding_v1: panel.gamma_jog_feedrate corresponding_v2: none (v2 has different jogging configuration) description: Specifies the Z axis (gamma motor) jogging feedrate in millimeters per minute when using the panel's manual control menu. This speed is used when manually moving the Z axis using the panel interface without running G-code files. Typically set much slower than X/Y axes for safety and precision since Z-axis crashes can damage tooling and workpieces. description_bullets: - Used only during manual jogging from panel menus, not during G-code execution. - Value is in mm/min (divide by 60 to get mm/s). - Default 200 mm/min equals 3.3 mm/s (much slower than X/Y). - Z axis typically moves much slower than X/Y for safety and mechanical reasons. - Should be significantly slower than `gamma_max_rate` for safe manual control. typical_values: - value: 200 description: 3.3 mm/s, standard - value: 300 description: 5 mm/s, faster - value: 600 description: 10 mm/s, fast printers related_settings: - panel.alpha_jog_feedrate - panel.beta_jog_feedrate - gamma_max_rate related_pages: - panel - motion-control - endstops examples: - 'panel.gamma_jog_feedrate 200 # 3.3 mm/s (safe, default)' - 'panel.gamma_jog_feedrate 300 # 5 mm/s (slightly faster)' - 'panel.gamma_jog_feedrate 600 # 10 mm/s (fast for delta printers)' - name: panel.hotend_temperature type: number default: 185 units: °C (degrees Celsius) module: panel context: Global module setting defined_in: src/modules/utils/panel/Panel.cpp:174 corresponding_v1: panel.hotend_temperature corresponding_v2: none (v2 has different panel temperature preset configuration) description: Specifies the temperature preset in degrees Celsius to set the hotend to when using the pre-heating menu item on the panel. This provides a quick-access one-button preset for heating the hotend to a commonly used temperature without manually entering values. The temperature should match your most commonly used filament type. description_bullets: - Default 185°C is suitable for standard PLA filament. - This is a convenience preset, not a temperature limit or safety setting. - Can be temporarily overridden using M104 commands or panel temperature screens. - 'Different filament types require different temperatures (PLA: 180-220°C, ABS: 220-250°C, PETG: 230-250°C).' - Pre-heating allows starting heatup before loading a print file. typical_values: - value: 185 description: PLA - value: 210 description: PLA high temp - value: 230 description: ABS - value: 240 description: PETG related_settings: - panel.bed_temperature - temperature_control.hotend.max_temp related_pages: - panel - temperaturecontrol - extruder examples: - 'panel.hotend_temperature 185 # PLA preset (default)' - 'panel.hotend_temperature 230 # ABS preset' - 'panel.hotend_temperature 240 # PETG preset' - name: panel.bed_temperature type: number default: 60 units: °C (degrees Celsius) module: panel context: Global module setting defined_in: src/modules/utils/panel/Panel.cpp:175 corresponding_v1: panel.bed_temperature corresponding_v2: none (v2 has different panel temperature preset configuration) description: Specifies the temperature preset in degrees Celsius to set the heated bed to when using the pre-heating menu item on the panel. This provides a quick-access one-button preset for heating the bed to a commonly used temperature without manually entering values. The temperature should match your most commonly used filament type. description_bullets: - Default 60°C is suitable for standard PLA filament. - This is a convenience preset, not a temperature limit or safety setting. - Can be temporarily overridden using M140 commands or panel temperature screens. - 'Different filament types require different bed temperatures (PLA: 50-70°C, ABS: 90-110°C, PETG: 70-90°C).' - Pre-heating allows starting bed warmup before loading a print file to reduce total warmup time. typical_values: - value: 60 description: PLA - value: 80 description: PETG - value: 100 description: ABS - value: 110 description: ABS high adhesion related_settings: - panel.hotend_temperature - temperature_control.bed.max_temp related_pages: - panel - temperaturecontrol examples: - 'panel.bed_temperature 60 # PLA preset (default)' - 'panel.bed_temperature 100 # ABS preset' - 'panel.bed_temperature 80 # PETG preset' - name: panel.external_sd type: bool default: false module: panel context: Global module setting defined_in: src/modules/utils/panel/Panel.cpp:141 corresponding_v1: panel.external_sd corresponding_v2: none (v2 has different external SD card configuration) description: When set to true, enables support for an external SD card slot on the panel or a second SD card slot connected to one of Smoothieboard's SPI ports. The external SD card is mounted at `/ext` in the filesystem and can be accessed through the panel file browser. This allows file storage separate from the main Smoothieboard SD card, useful for quick file transfer or additional storage capacity. description_bullets: - External SD card requires dedicated SPI channel and CS pin configuration. - Mounted automatically at `/ext` directory when card is inserted (if sdcd_pin configured). - Panel file browser can navigate both internal SD (`/sd`) and external SD (`/ext`). - Useful for transferring files without removing main SD card. - Card detect pin (sdcd_pin) enables automatic mount/unmount on card insertion/removal. related_settings: - panel.external_sd.spi_channel - panel.external_sd.spi_cs_pin - panel.external_sd.sdcd_pin related_pages: - panel - sd-card examples: - 'panel.external_sd true # Enable external SD card slot' - 'panel.external_sd false # No external SD (default)' - name: panel.external_sd.spi_channel type: number default: 0 module: panel context: External SD subsetting defined_in: src/modules/utils/panel/Panel.cpp:145 corresponding_v1: panel.external_sd.spi_channel corresponding_v2: none (v2 has different SPI configuration) description: Selects which SPI channel to use for the external SD card. The external SD card can share the same SPI channel as the panel if they use different CS pins, or can use a separate SPI channel if interference or timing issues occur. Channel selection determines which physical pins are used for SPI communication with the external SD card. description_bullets: - Can share SPI channel with panel (channel 0) using different CS pins. - Using separate SPI channel (channel 1) avoids any potential SPI timing conflicts. - External SD card and panel both support SPI sharing with proper CS pin configuration. - If panel and external SD share channel, they must have unique CS pins. related_settings: - panel.spi_channel - panel.external_sd.spi_cs_pin related_pages: - panel - pinout - sd-card examples: - 'panel.external_sd.spi_channel 0 # Share with panel (common)' - 'panel.external_sd.spi_channel 1 # Separate SPI channel' - name: panel.external_sd.spi_cs_pin type: pin default: 2.8 module: panel context: External SD subsetting defined_in: src/modules/utils/panel/Panel.cpp:146 corresponding_v1: panel.external_sd.spi_cs_pin corresponding_v2: none (v2 uses different pin notation) description: Specifies the CS (Chip Select) pin for the external SD card. This pin selects the external SD card device on the SPI bus. The CS pin allows the external SD card and panel to share the same SPI channel by ensuring only one device responds at a time. Each device on a shared SPI bus must have a unique CS pin. description_bullets: - Default pin 2.8 is typical for Smoothieboard external SD card connections. - 'CRITICAL: Must be different from `panel.spi_cs_pin` if both use same SPI channel.' - CS pin activates (low) to select SD card, deactivates (high) to release bus. - Choose an available GPIO pin that is not used by other functions. related_settings: - panel.spi_cs_pin - panel.external_sd.spi_channel related_pages: - panel - pinout - sd-card examples: - 'panel.external_sd.spi_cs_pin 2.8 # Standard external SD CS pin (default)' - 'panel.external_sd.spi_cs_pin 1.23 # Alternative CS pin' - 'panel.external_sd.spi_cs_pin 0.6 # Another alternative' - name: panel.external_sd.sdcd_pin type: pin default: nc module: panel context: External SD subsetting defined_in: src/modules/utils/panel/Panel.cpp:144 corresponding_v1: panel.external_sd.sdcd_pin corresponding_v2: none (v2 uses different pin notation and card detection) description: Specifies the SD card detect signal pin for the external SD card slot. When connected, the system automatically mounts the SD card at `/ext` when the card is inserted and unmounts it when the card is removed. This provides convenient hot-swap capability without manual mount/unmount commands. description_bullets: - Set to `nc` if SD card slot does not have a detect pin or if manual mounting is preferred. - Card detect switches are typically active low (require `!` modifier). - Pull-up resistor (`^`) is usually required for reliable card detection. - When card is detected, system automatically runs mount sequence and switches panel to `/ext` directory. - Removing card while in use may cause file system errors; use panel to ensure files are closed first. related_settings: - panel.external_sd - panel.external_sd.spi_cs_pin related_pages: - panel - sd-card examples: - 'panel.external_sd.sdcd_pin 2.13!^ # Active-low detect with pull-up (common)' - 'panel.external_sd.sdcd_pin 1.24^ # Active-high detect with pull-up' - 'panel.external_sd.sdcd_pin nc # No automatic detection (default)' - name: panel.display_extruder type: bool default: false module: panel context: Global module setting defined_in: src/modules/utils/panel/Panel.cpp:202 corresponding_v1: panel.display_extruder corresponding_v2: none (v2 has different display configuration) description: When set to true, the watch screen (main status screen) displays extruder position and temperature information in addition to bed and hotend temperatures. When false, only bed and hotend temperatures are shown to reduce screen clutter. This setting is useful for multi-extruder setups where tracking extruder position is important. description_bullets: - Default false shows only temperatures (simpler display for single extruder). - Setting to true adds E-axis position display (useful for monitoring extrusion). - On small displays (128x64), enabling this may make information harder to read due to crowding. - Multi-extruder setups benefit from extruder position display for troubleshooting. - Does not affect other screens or menus, only the main watch screen. related_pages: - panel - extruder - temperaturecontrol examples: - 'panel.display_extruder false # Show only temperatures (default)' - 'panel.display_extruder true # Show extruder position and temperatures' - name: custom_menu..enable type: bool default: N/A (must be explicitly set) module: panel context: Per custom menu instance setting defined_in: src/modules/utils/panel/screens/CustomScreen.cpp:34 corresponding_v1: custom_menu..enable corresponding_v2: none (v2 does not have custom menu functionality documented) description: When set to true, creates a new custom menu entry for the panel with the identifier ``. You can create any number of custom menu entries as long as they have different names. Each custom menu entry provides a way to execute pre-configured G-code commands directly from the panel without creating a file or using console commands. description_bullets: - 'NOTE: `` is case-sensitive and must match across all three custom menu settings.' - Custom menus appear in the panel's main menu under "Custom" or similar section. - Useful for frequently-used command sequences (homing, preheating, calibration routines). - 'Each custom menu entry requires three settings: enable, name, and command.' - Maximum number of custom menus is limited by available memory (typically 10-20). related_settings: - custom_menu..name - custom_menu..command related_pages: - panel - panel-options - supported-g-codes examples: - 'custom_menu.power_on.enable true # Enable custom menu named "power_on"' - 'custom_menu.preheat_abs.enable true # Enable custom menu named "preheat_abs"' - 'custom_menu.home_all.enable false # Disable this custom menu' - name: custom_menu..name type: string default: N/A (must be explicitly set) module: panel context: Per custom menu instance setting defined_in: src/modules/utils/panel/screens/CustomScreen.cpp:36-37 corresponding_v1: custom_menu..name corresponding_v2: none (v2 does not have custom menu functionality documented) description: Specifies the display name that will appear in the panel's menus for this custom menu entry. Underscores (`_`) in the name are automatically converted to spaces when displayed on screen. Names should be kept short (20 characters maximum) to fit properly on small LCD displays without truncation. description_bullets: - Use underscores (`_`) instead of spaces in configuration (e.g., `Power_On_Home`). - Display converts underscores to spaces (appears as "Power On Home" on screen). - Keep names descriptive but concise (20 characters or less). - Avoid special characters or symbols that may not display correctly. - Name should clearly describe the action that will be executed. related_settings: - custom_menu..enable - custom_menu..command related_pages: - panel - panel-options examples: - 'custom_menu.power_on.name Power_On # Displays as "Power On"' - 'custom_menu.preheat_abs.name Preheat_ABS # Displays as "Preheat ABS"' - 'custom_menu.home_all.name Home_All_Axes # Displays as "Home All Axes"' - name: custom_menu..command type: string default: N/A (must be explicitly set) module: panel context: Per custom menu instance setting defined_in: src/modules/utils/panel/screens/CustomScreen.cpp:40-42 corresponding_v1: custom_menu..command corresponding_v2: none (v2 does not have custom menu functionality documented) description: Specifies the G-code command or command sequence that will be executed when the custom menu entry is selected and clicked on the panel. Underscores (`_`) are converted to spaces, and the pipe character (`|`) is used to separate multiple commands that should be executed in sequence. description_bullets: - Underscore (`_`) substitutes for space in commands and parameters (required). - Pipe (`|`) separates multiple commands for sequential execution. - Commands execute in order from left to right. - 'Example: `M80_S30|G1_X10` becomes `M80 S30` then `G1 X10`.' - All G-codes and M-codes supported by Smoothie can be used. - Complex command sequences can automate common workflows. related_settings: - custom_menu..enable - custom_menu..name related_pages: - panel - supported-g-codes - console-commands examples: - 'custom_menu.power_on.command M80_S30|G1_X10 # Power on, wait 30s, move X to 10' - 'custom_menu.preheat_abs.command M104_S230|M140_S100 # Set hotend 230°C and bed 100°C' - 'custom_menu.home_all.command G28 # Home all axes' - name: Network description: Ethernet and network service settings setting_count: 9 settings: - name: network.enable type: bool default: false module: network context: Global setting defined_in: libs/Network/uip/Network.cpp:126 corresponding_v1: network.enable corresponding_v2: network.enable description: Master enable switch for the entire Ethernet network functionality. When disabled, the network module is completely unloaded to free system resources (approximately 8KB RAM). Must be set to true to use any network features including webserver, telnet, Plan9, or SFTP services. description_bullets: - When disabled, the module deletes itself during initialization to maximize available memory. - When enabled, initializes the uIP TCP/IP stack and LPC17XX Ethernet hardware driver. - All other network.* settings have no effect if this is false. related_settings: - network.webserver.enable - network.telnet.enable - network.plan9.enable related_pages: - network - connecting-smoothie - webserver - telnet examples: - 'network.enable true # Enable Ethernet networking' - 'network.enable false # Disable network to free ~8KB RAM' - name: network.ip_address type: string default: auto module: network context: Global setting defined_in: libs/Network/uip/Network.cpp:156 corresponding_v1: network.ip_address corresponding_v2: network.ip_address description: Configures the IP address assignment method for the Smoothieboard. Can use DHCP for automatic configuration or specify a static IP address. When using "auto", the board will request network settings from a DHCP server. When set to a specific IP address, static configuration is used and both network.ip_mask and network.ip_gateway must also be configured. description_bullets: - Parsed using parse_ip_str() function which validates dotted decimal format (lines 88-104). - 'When "auto": triggers DHCP client initialization (requires UIP_CONF_UDP enabled).' - 'When static: IP is converted to 4-byte array and passed to uIP stack via uip_sethostaddr().' - 'Invalid format displays "Invalid IP address: [value]" error and prevents network initialization.' - DHCP mode displays "Getting IP address...." message on startup. - Static mode displays configured IP address immediately. related_settings: - network.ip_mask - network.ip_gateway - network.hostname related_pages: - network - connecting-smoothie - network-options examples: - 'network.ip_address auto # DHCP automatic configuration (recommended)' - 'network.ip_address 192.168.1.100 # Static IP for home network' - 'network.ip_address 10.0.50.100 # Static IP for industrial network' - name: network.ip_mask type: string default: 255.255.255.0 module: network context: Global setting defined_in: libs/Network/uip/Network.cpp:175 corresponding_v1: network.ip_mask corresponding_v2: network.ip_mask description: Defines the subnet mask for static IP configuration. The netmask determines which portion of the IP address identifies the network and which portion identifies the host. Only used when network.ip_address is set to a static IP (not "auto"). When using DHCP, this setting is ignored and the subnet mask is provided automatically by the DHCP server. description_bullets: - Ignored when DHCP is enabled (network.ip_address = "auto"). - Parsed using parse_ip_str() with 4-octet validation (line 176). - Passed to uIP stack via uip_setnetmask() (line 375). - 'Invalid format displays "Invalid IP Mask: [value]" error and prevents network initialization.' - The gateway address must be within the network defined by IP address + netmask. typical_values: - value: 255.255.255.0 description: Class C, /24 network, 254 hosts - value: 255.255.255.128 description: /25 network, 126 hosts - value: 255.255.0.0 description: Class B, /16 network related_settings: - network.ip_address - network.ip_gateway related_pages: - network - connecting-smoothie - network-options examples: - 'network.ip_mask 255.255.255.0 # Standard Class C network (254 hosts)' - 'network.ip_mask 255.255.255.128 # Smaller subnet (126 hosts, /25)' - 'network.ip_mask 255.255.0.0 # Large Class B network (65534 hosts)' - name: network.ip_gateway type: string default: 192.168.1.254 module: network context: Global setting defined_in: libs/Network/uip/Network.cpp:180 corresponding_v1: network.ip_gateway corresponding_v2: network.ip_gateway description: Specifies the default gateway (router) IP address for static IP configuration. The gateway is used for routing traffic outside the local network. Only used when network.ip_address is set to a static IP (not "auto"). With DHCP, the gateway is provided automatically by the DHCP server along with other network configuration. description_bullets: - Ignored when DHCP is enabled (network.ip_address = "auto"). - Parsed using parse_ip_str() with 4-octet validation (line 181). - Passed to uIP stack via uip_setdraddr() (default router address) at line 371. - 'Invalid format displays "Invalid IP gateway: [value]" error and prevents network initialization.' - Gateway should be reachable on the local network segment defined by IP + mask. - Used by uIP for routing packets to destinations outside the local subnet. typical_values: - value: 192.168.1.1 description: typical home router - value: 10.0.0.1 description: common corporate gateway - value: 192.168.0.1 description: alternate home default related_settings: - network.ip_address - network.ip_mask related_pages: - network - connecting-smoothie - network-options examples: - 'network.ip_gateway 192.168.1.1 # Typical home/office router' - 'network.ip_gateway 10.0.50.254 # Industrial network gateway' - 'network.ip_gateway 192.168.0.1 # Alternative home router default' - name: network.mac_override type: string default: '""' module: network context: Global setting defined_in: libs/Network/uip/Network.cpp:135-151 corresponding_v1: network.mac_override corresponding_v2: none (v2 uses different MAC generation method) description: Allows manual override of the Ethernet MAC (Media Access Control) address. By default, Smoothieboard auto-generates a unique MAC address based on the CPU's serial number using a cryptographic hash. Only set this if you experience MAC address conflicts on your network or need to preserve a specific MAC address after hardware replacement. description_bullets: - 'Auto-generated MAC format: `00:1F:11:02:04:xx`' - '`00:1F:11` - OUI (Organizationally Unique Identifier) for Openmoko' - '`02` - Openmoko allocation for Smoothieboard' - '`04` - Fixed identifier' - Last byte derived from CRC32 hash of CPU serial number (unique per board, lines 72-86) - Custom MAC parsed using parse_ip_str() with base-16 and ':' separator (line 137) - MAC address set via ethernet->set_mac() and uip_setethaddr() (lines 153, 362) - 'Invalid format displays "Invalid MAC address: [value]" error and prevents network initialization' - 'WARNING: Each device on a network must have a unique MAC address. Using duplicate MAC addresses causes network conflicts and connectivity issues.' related_pages: - network - connecting-smoothie - troubleshooting examples: - '# Use auto-generated MAC (recommended - leave blank or omit)' - 'network.mac_override # Blank = auto-generate from CPU serial' - 'network.mac_override 00:1F:11:02:04:A5 # Override if needed for conflict resolution' - name: network.hostname type: string default: none (empty) module: network context: Global setting defined_in: libs/Network/uip/Network.cpp:159-167 corresponding_v1: network.hostname corresponding_v2: network.hostname description: Sets a hostname that is sent to the DHCP server during IP address requests. Some DHCP servers register this hostname in local DNS, allowing you to access the Smoothieboard by name (e.g., "http://smoothie-cnc/") instead of IP address. Only used when network.ip_address is set to "auto" (DHCP mode). Has no effect with static IP configuration. description_bullets: - Only processed when DHCP is enabled (network.ip_address = "auto") - Validated using parse_hostname() function against RFC standards (lines 106-122) - Passed to DHCP client via dhcpc_init(mac_address, sizeof(mac_address), hostname) at line 381 - 'Invalid hostname displays "Invalid hostname: [value]" warning but doesn''t prevent network initialization (line 165)' - Hostname support depends on DHCP server capabilities - not all routers support hostname registration in local DNS - 'Allows access by name if DHCP/DNS server supports it: http://hostname/ instead of http://192.168.1.100/' typical_values: - value: smoothie description: generic - value: cnc-mill description: descriptive - value: laser-cutter description: descriptive - value: printer3d description: no spaces or special chars related_settings: - network.ip_address related_pages: - network - connecting-smoothie - webserver examples: - 'network.ip_address auto # Must use DHCP for hostname' - 'network.hostname smoothie-cnc # Accessible as http://smoothie-cnc/' - 'network.hostname Shapeoko17 # Mixed case allowed' - 'network.hostname laser-cutter # Hyphens allowed in middle' - name: network.webserver.enable type: bool default: false module: network context: Global setting defined_in: libs/Network/uip/Network.cpp:132,297-300 corresponding_v1: network.webserver.enable corresponding_v2: network.webserver_enable description: Enables the built-in HTTP web server on port 80. The web server provides a browser-based control interface for sending commands, monitoring status, uploading G-code files, and managing the SD card filesystem. Requires network.enable to be true to function. The web interface must be separately installed on the SD card. description_bullets: - Initializes HTTP daemon via httpd_init() when enabled (line 299) - Listens on TCP port 80 (standard HTTP) - Routed through app_select_appcall() multiplexer (lines 409-410) - Provides web-based UI for machine control and file management - Uses uIP TCP/IP stack for HTTP protocol handling - Only initialized after network is fully configured (DHCP complete or static IP set) - Web interface files must be installed separately on SD card in /www directory - 'Access via browser: http://[ip-address]/ or http://[hostname]/' related_m_codes: - code: M22 description: Remount SD card (useful after uploading files via web) - code: M20 description: List files on SD card (accessible via web terminal) related_settings: - network.enable - network.ip_address related_pages: - network - webserver - install-web-interface - connecting-smoothie examples: - network.enable true - network.ip_address auto - 'network.webserver.enable true # Enable web interface on port 80' - name: network.telnet.enable type: bool default: false module: network context: Global setting defined_in: libs/Network/uip/Network.cpp:133,303-307 corresponding_v1: network.telnet.enable corresponding_v2: network.shell_enable description: Enables the telnet server on port 23. The telnet service provides a network-based command-line interface that behaves identically to the USB serial console. Allows remote G-code execution and configuration commands over the network. Requires network.enable to be true to function. Multiple concurrent connections are supported up to the UIP_CONNS limit. description_bullets: - Initializes telnet daemon via Telnetd::init() when enabled (line 305) - Listens on TCP port 23 (standard telnet) - Routed through app_select_appcall() to Telnetd::appcall() (lines 413-414) - Provides full command-line access identical to USB serial console - Supports concurrent connections up to UIP_CONNS limit (typically 4-8) - Only initialized after network is fully configured - Commands queue through CommandQueue same as USB serial - 'WARNING: Telnet is unencrypted - only use on trusted local networks' related_settings: - network.enable - network.ip_address related_pages: - network - connecting-smoothie - console-commands - uart examples: - network.enable true - network.ip_address 192.168.1.100 - network.ip_mask 255.255.255.0 - network.ip_gateway 192.168.1.1 - 'network.telnet.enable true # Enable telnet on port 23' - name: network.plan9.enable type: bool default: false module: network context: Global setting defined_in: libs/Network/uip/Network.cpp:134,309-315 corresponding_v1: network.plan9.enable corresponding_v2: none (Plan9 support removed in v2) description: Enables the Plan9 network filesystem server on port 564. Plan9 (9P protocol) allows mounting the Smoothieboard's SD card filesystem directly on your computer's operating system, making it appear as a local drive. This provides convenient file access for uploading G-code and managing files. Requires network.enable to be true to function. Less commonly used than webserver or telnet. description_bullets: - Initializes Plan9 server via Plan9::init() when enabled (line 312) - Listens on TCP port 564 (standard 9P protocol port) - Routed through app_select_appcall() to Plan9::appcall() (lines 418-419) - Can be disabled at compile time with NOPLAN9 flag - Provides filesystem mount capability for direct file access - Only initialized after network is fully configured - Exports entire SD card filesystem over network - 'Mount on Linux: mount -t 9p -o trans=tcp,port=564 [ip-address] /mnt/smoothie' - 'Mount on macOS: Use 9pfuse or similar 9P client' - 'Mount on Windows: Use plan9port or third-party 9P client' related_settings: - network.enable - network.ip_address related_pages: - network - connecting-smoothie - sd-card examples: - network.enable true - network.ip_address auto - 'plan9.enable true # Enable Plan9 filesystem on port 564' - name: Miscellaneous/Root Settings description: System-wide and communication settings setting_count: 24 settings: - name: uart0.baud_rate type: number default: 9600 units: baud (bits per second) module: root context: Global setting defined_in: modules/communication/SerialConsole.cpp:182 corresponding_v1: uart0.baud_rate corresponding_v2: uart console.baudrate description: Baud rate for the default hardware serial port (UART0), labeled "Serial" on the board near the USB connector. This controls the communication speed for the primary serial interface used for communication with host software, terminal debugging, and G-code streaming. description_bullets: - The serial port is initialized early in the boot process for error reporting - If the config file cannot be read, defaults to 9600 baud for emergency communication - UART configuration is applied in `init_uart()` method with 8 data bits, 1 stop bit, no parity - Must match the baud rate configured in your host software (Pronterface, OctoPrint, etc.) typical_values: - value: 9600 description: fallback - value: 115200 description: standard recommended - value: 250000 description: high-speed - value: 230400 description: alternative high-speed related_settings: - second_usb_serial_enable related_pages: - uart - communication - connecting-smoothie examples: - 'uart0.baud_rate 115200 # Standard high-speed rate (recommended)' - 'uart0.baud_rate 250000 # High-speed for faster communication' - 'uart0.baud_rate 9600 # Fallback rate for troubleshooting' - name: second_usb_serial_enable type: bool default: false module: root context: Global setting defined_in: main.cpp:204 corresponding_v1: second_usb_serial_enable corresponding_v2: consoles.second_usb_serial_enable description: Enables a second serial port over the USB connection. This allows you to have two independent serial connections simultaneously, useful for having both a host application (like Pronterface) and a terminal connected at the same time. Both serial ports share the same USB connection but appear as separate COM/tty devices to the host operating system. description_bullets: - If enabled, creates a second USBSerial module instance - Useful for simultaneous connection of multiple host applications - Enables debugging while printing - Allows monitoring status from one port while sending commands from another - 'Windows: Appears as two separate COM ports (e.g., COM3 and COM4)' - 'Linux: Appears as two ttyACM devices (e.g., /dev/ttyACM0 and /dev/ttyACM1)' - 'macOS: Appears as two tty.usbmodem devices' related_settings: - uart0.baud_rate related_pages: - usb - connecting-smoothie - communication examples: - 'second_usb_serial_enable false # Single USB serial port (default)' - 'second_usb_serial_enable true # Enable second USB serial for dual connections' - name: leds_disable type: bool default: false module: root context: Global setting defined_in: libs/Kernel.cpp:111 corresponding_v1: leds_disable corresponding_v2: none (LED control simplified in v2) description: 'Disables the 4 flashing status LEDs on the board. When set to true, all status indication LEDs are turned off, which can be useful for reducing visual distraction or in applications where LED light might interfere with sensors. The setting is inverted internally: `use_leds = !leds_disable`.' description_bullets: - 'LED1: Step generation activity' - 'LED2: USB activity' - 'LED3: SD card activity' - 'LED4: General activity/heartbeat' - Does NOT affect the play LED (controlled separately by `play_led_disable`) - Useful in noise-sensitive environments (e.g., recording studios) - Useful in light-sensitive applications (e.g., photography equipment) - Minimal impact on power consumption related_settings: - play_led_disable related_pages: - smoothieboard - troubleshooting examples: - 'leds_disable false # LEDs enabled (default, shows activity)' - 'leds_disable true # Disable all 4 status LEDs' - name: play_led_disable type: bool default: false module: root context: Global setting defined_in: modules/utils/PlayLed/PlayLed.cpp:27 corresponding_v1: play_led_disable corresponding_v2: system.aux_play_led description: Disables the "play" status LED that indicates when a file is being played from the SD card. When set to true, the LED is turned off. This is separate from the main status LEDs and can be disabled independently. If disabled, the PlayLed module deletes itself to free resources. description_bullets: - Default pin is `4.28!` (inverted) - Can be overridden with `play_led_pin` setting - 'LED behavior when enabled:' related_settings: - leds_disable - play_led_pin - pause_led_pin related_pages: - playled - player - printing-from-sd-card examples: - 'play_led_disable false # Play LED enabled (default, shows playback status)' - 'play_led_disable true # Disable play LED indicator' - name: kill_button_enable type: bool default: false module: root context: Global setting defined_in: modules/utils/killbutton/KillButton.cpp:32 corresponding_v1: kill_button_enable corresponding_v2: kill button.enable description: Enables the "kill" button functionality for emergency halt operations. When enabled, a physical button can be used to immediately halt all machine operations in case of emergency. This is a safety feature that stops all motors and halts command processing, equivalent to sending M112 via G-code. description_bullets: - Also checks deprecated `pause_button_enable` for backward compatibility - Button is polled at regular intervals (configurable via `kill_button_poll_frequency`) - Supports both momentary kill and toggle modes - Button press triggers emergency halt (M112 equivalent) - Hold 2+ seconds can unkill if `unkill_enable` is true - 'Toggle mode: If `kill_button_toggle_enable` is true, first press kills, second press unkills' - 'Safety features: immediate motor stop, command queue flush, halt state entry' - Must be explicitly cleared with M999 or $X (unless toggle mode enabled) related_settings: - kill_button_pin - kill_button_toggle_enable - kill_button_poll_frequency - unkill_enable related_pages: - killbutton - emergencystop - stopping-smoothie examples: - 'kill_button_enable false # No kill button (default)' - 'kill_button_enable true # Enable emergency stop button' - 'kill_button_pin 2.12 # Specify pin for button (required when enabled)' - name: kill_button_pin type: pin default: 2.12 module: root context: Global setting defined_in: modules/utils/killbutton/KillButton.cpp:37 corresponding_v1: kill_button_pin corresponding_v2: kill button.pin description: Specifies the GPIO pin to use for the kill button. The button should be wired between this pin and ground. The pin is configured as input with internal pullup (active low), meaning the button press connects the pin to ground. description_bullets: - Pin is configured as input with internal pullup - Active low (button press connects to ground) - Compatible with normally-open momentary switches related_settings: - kill_button_enable related_pages: - killbutton - pin-configuration - pinout examples: - 'kill_button_pin 2.12 # Default pin assignment' - 'kill_button_pin 2.12^ # Explicit pullup (redundant, default behavior)' - 'kill_button_pin 1.30! # Different pin with inversion' - name: msd_disable type: bool default: false module: root context: Global setting defined_in: main.cpp:65 corresponding_v1: msd_disable corresponding_v2: system.msc_enable description: 'Disables the MSD (Mass Storage Device) functionality when set to true. This prevents the SD card from appearing as a USB drive when connected to a computer. **CRITICAL: This requires a special firmware binary to function** - the standard firmware will ignore this setting. The special firmware binary `firmware-disablemsd.bin` is available at https://github.com/Smoothieware/Smoothieware/blob/edge/FirmwareBin/firmware-disablemsd.bin.' description_bullets: - 'Requires special firmware build: `firmware-disablemsd.bin`' - Standard firmware ignores this setting - 'When false (default): SD card appears as USB drive when connected' - 'When true: SD card only accessible via serial commands (M20, M23, etc.)' - Cannot be changed without firmware replacement - Must recompile firmware to add/remove this feature - 'Use cases: prevent accidental file modifications, dedicated control over file access, embedded installations' - 'Alternative file access when disabled: M20 (list files), M23 (select file), M24 (start print), M25 (pause), M30 (delete)' related_pages: - sd-card - flashing-smoothie-firmware examples: - 'msd_disable false # SD card appears as USB drive (default, requires standard firmware)' - 'msd_disable true # SD card not accessible via USB (requires special firmware-disablemsd.bin)' - name: dfu_enable type: bool default: false module: root context: Global setting defined_in: main.cpp:208 corresponding_v1: dfu_enable corresponding_v2: system.dfu_enable description: 'For Linux developers: enables DFU (Device Firmware Update) mode, which allows you to flash new firmware over USB without requiring a physical bootloader button press or SD card. This is primarily useful for firmware development workflows and rapid iteration. Uses the same USB connection as serial communication.' description_bullets: - Creates a DFU module instance if enabled - Flash new firmware over USB without SD card - No physical button press required for updates - Standard DFU protocol support - 'Tools: `dfu-util` on Linux, various DFU utilities on Windows, `dfu-util` via Homebrew on macOS' - 'Example DFU command: `dfu-util -d 1d50:6015 -D firmware.bin -R`' - 'WARNING: Enabling DFU allows firmware replacement, only enable in trusted environments' related_pages: - flashing-smoothie-firmware - compiling-smoothie examples: - 'dfu_enable false # DFU disabled (default, normal operation)' - 'dfu_enable true # Enable DFU for firmware development' - name: base_stepping_frequency type: number default: 100000 units: Hz (frequency) module: root context: Global setting defined_in: libs/Kernel.cpp:159 corresponding_v1: base_stepping_frequency corresponding_v2: system.step_frequency description: Sets the base frequency of the step ticker in Hz. This is the fundamental rate at which the step generation interrupt runs. All step generation is derived from this base frequency through integer division. The maximum step rate per motor equals base_stepping_frequency ÷ steps_per_mm for that motor. Must be carefully chosen based on maximum expected step rates. description_bullets: - Used to configure the StepTicker frequency - Affects CPU load and maximum achievable step rates - 'Example calculation: 100000 Hz ÷ 80 steps/mm = 1250 mm/s = 75000 mm/min maximum' - 'Too low: Limits maximum speeds and acceleration' - 'Too high: Increases CPU load, may cause instability' - 'Must be higher than: max_rate × steps_per_mm for any axis' - Firmware automatically warns if actuator rates exceed capability - Higher frequencies increase interrupt load and may affect response time for other operations - 'WARNING: If actuator max_rate × steps_per_mm exceeds base_stepping_frequency, firmware outputs warning and clamps rate' typical_values: - value: 50000 description: 50 kHz, lower CPU load - value: 100000 description: 100 kHz, default - value: 200000 description: 200 kHz, higher performance related_settings: - microseconds_per_step_pulse - alpha_max_rate - beta_max_rate - gamma_max_rate - alpha_steps_per_mm - beta_steps_per_mm - gamma_steps_per_mm related_pages: - motion-control - stepper-motors examples: - 'base_stepping_frequency 100000 # 100 kHz (default, suitable for most applications)' - 'base_stepping_frequency 200000 # 200 kHz (higher performance, more CPU load)' - 'base_stepping_frequency 50000 # 50 kHz (lower CPU load, reduced max step rates)' - name: microseconds_per_step_pulse type: number default: 1 units: µs (microseconds) module: root context: Global setting defined_in: libs/Kernel.cpp:160 corresponding_v1: microseconds_per_step_pulse corresponding_v2: system.step_pulse_us description: Duration of the step pulse in microseconds. This is the time that the step signal remains high before returning low. Some stepper drivers require a minimum pulse width to reliably register steps. Check your driver datasheet for "Step Pulse Width" specification and set to at least 2× the minimum requirement for reliability. description_bullets: - Sets the unstep time in the StepTicker (applied at line 164 of Kernel.cpp) - 'Different driver requirements:' - Use 1 for onboard drivers (safe for all Smoothieboard drivers) - Increase if using external drivers and experiencing missed steps - 'Symptoms of too short pulse: missed steps, random position errors, inconsistent movement (worse at higher speeds)' - Longer pulses slightly reduce maximum step rate - Minimal CPU impact difference between 1 and 5 microseconds typical_values: - value: 1 description: default, modern drivers - value: 2 description: some older drivers like A4988 variants - value: 5 description: very old or slow drivers related_settings: - base_stepping_frequency related_pages: - stepper-motors - motion-control examples: - 'microseconds_per_step_pulse 1 # Default for modern drivers' - 'microseconds_per_step_pulse 2 # For A4988 and some older drivers' - 'microseconds_per_step_pulse 5 # For very old or slow drivers (TB6560, TB6600)' - name: grbl_mode type: bool default: false module: root context: Global setting defined_in: libs/Kernel.cpp:114-117 corresponding_v1: grbl_mode corresponding_v2: general.grbl_mode description: Enables GRBL compatibility mode. When enabled, the firmware behaves more like GRBL, changing error messages, command handling, and protocol responses to match GRBL conventions. This is useful for host software designed for GRBL controllers like bCNC and other CNC-focused applications. description_bullets: - 'Default follows build configuration: CNC builds default to true, others to false' - 'Changes error message formatting: Standard uses `Error: description`, GRBL mode uses `error:description`' - 'Homing: Standard uses G28, GRBL mode uses G28.2 for force homing and supports `$H` command' - 'Program end: Standard M30 deletes SD card files, GRBL mode M30 ends program (like M2)' - 'Status queries: Standard provides extended status with temperatures, GRBL mode provides GRBL-style status reports with `?` query' - 'Dwell command: Standard G4 P, GRBL mode G4 P (decimal seconds like LinuxCNC)' - 'Halt behavior: Standard outputs "HALTED, M999 or $X to exit HALT state", GRBL mode outputs "ALARM: Abort during cycle"' - Feed hold default state follows grbl_mode setting (can be overridden with `enable_feed_hold`) - 'M115 response includes `X-GRBL_MODE` flag: `FIRMWARE_NAME:Smoothieware, FIRMWARE_VERSION:1.0, X-GRBL_MODE:1, ...`' related_settings: - enable_feed_hold - ok_per_line related_pages: - grbl-mode - from-grbl - bcnc examples: - 'grbl_mode false # Standard RepRap protocol (default for 3D printer builds)' - 'grbl_mode true # GRBL compatibility mode (default for CNC builds)' - name: ok_per_line type: bool default: true module: root context: Global setting defined_in: libs/Kernel.cpp:122 corresponding_v1: ok_per_line corresponding_v2: none (true behavior is standard in v2) description: Controls when "ok" responses are sent. When true (default and recommended), sends "ok" once per line of input. When false, reverts to the old (incorrect) behavior of sending "ok" per G-code command, which could result in multiple "ok" responses for a single line containing multiple commands. Modern G-code protocol expects one "ok" per line, not per command. description_bullets: - 'Used in GcodeDispatch.cpp at line 415: `if(THEKERNEL->is_ok_per_line() || THEKERNEL->is_grbl_mode())`' - Modern protocol expects one "ok" per line, not per command - 'When true (correct, default): Single line `G0 X10 Y10 Z5` returns one `ok`' - 'When false (old behavior): Same line could return three `ok` responses' - GRBL mode always behaves as if true (ignores this setting) - Should almost always be left at true (default) - Only set to false for compatibility with very old host software - Required for proper command buffering in modern hosts related_settings: - grbl_mode related_pages: - communication - supported-g-codes examples: - 'ok_per_line true # One "ok" per line (correct, default, recommended)' - 'ok_per_line false # One "ok" per command (old behavior, not recommended)' - name: currentcontrol_module_enable type: bool default: false module: currentcontrol context: Global setting defined_in: modules/utils/currentcontrol/CurrentControl.cpp:43 required: false corresponding_v1: currentcontrol_module_enable corresponding_v2: none (replaced by TMC driver configuration in v2) description: Enables digital control of stepper motor driver currents via digipot chip. When enabled, allows software configuration of motor currents through the digipot (digital potentiometer) chip instead of manual potentiometer adjustment. This is board-specific and depends on hardware support. If disabled, the CurrentControl module deletes itself to free resources. description_bullets: - Requires compatible hardware with digipot chip - 'Supported boards:' - Enables M907 G-code command for runtime current adjustment - Allows fine-tuning motor currents in software - Supports dynamic current adjustment during operation related_settings: - digipotchip - digipot_max_current - digipot_factor - alpha_current - beta_current - gamma_current - delta_current related_pages: - currentcontrol - stepper-motors examples: - 'currentcontrol_module_enable false # Disabled (default, use manual pots)' - 'currentcontrol_module_enable true # Enable software current control' - name: digipotchip type: string default: mcp4451 module: currentcontrol context: Global setting defined_in: modules/utils/currentcontrol/CurrentControl.cpp:53 corresponding_v1: digipotchip corresponding_v2: none (replaced by TMC driver system in v2) description: Selects the digipot (digital potentiometer) chip used for current control. Different boards use different digipot chips, and this setting must match your hardware. Creates the appropriate digipot driver based on this setting. If unrecognized chip specified, defaults to MCP4451. description_bullets: - 'MCP4451 specifications:' - 'AD5206 specifications:' - 'CRITICAL: Must match your board''s hardware, incorrect setting prevents current control' - Check board documentation before changing related_settings: - currentcontrol_module_enable - digipot_max_current - digipot_factor related_pages: - currentcontrol - smoothieboard examples: - 'digipotchip mcp4451 # Smoothieboard, Azteeg X5 GT (default)' - 'digipotchip ad5206 # 4Pi boards' - name: digipot_max_current type: number default: 2 units: A (amperes) module: currentcontrol context: Global setting defined_in: modules/utils/currentcontrol/CurrentControl.cpp:62 minimum_value: '`0` (enforced by clamping in mcp4451.h:30)' maximum_value: Determined by board hardware limits (not enforced by software, user must verify) corresponding_v1: digipot_max_current corresponding_v2: tmc2590.{motor}.max_current description: 'Maximum current in amperes that can be set for any motor. This is a safety limit that prevents setting currents higher than the hardware can safely handle. The digipot will clamp any requested current to this maximum value using: `current = min(max(current, 0.0f), this->max_current)` (mcp4451.h line 30).' description_bullets: - Current values are clamped between 0 and this maximum - Per-driver limit, not total system limit - Protects against accidental over-current settings - 'Board-specific limits:' - 'Determining safe max current: check board specs, check stepper driver chip datasheet, consider power supply capacity, factor in cooling/heatsinking' - 'WARNING: Setting too high can damage drivers, overheat motors, damage power supply' typical_values: - value: 2 description: Smoothieboard/Azteeg X5 GT limit - value: 1.5 description: conservative for most steppers - value: 1 description: NEMA 17 typical related_settings: - digipotchip - digipot_factor - alpha_current - beta_current - gamma_current - delta_current related_pages: - currentcontrol - stepper-motors - smoothieboard-v1-specifications examples: - 'digipot_max_current 2.0 # Smoothieboard/Azteeg maximum (default)' - 'digipot_max_current 1.5 # Conservative limit for safety' - 'digipot_max_current 1.0 # Low-power NEMA 17 systems' - name: digipot_factor type: number default: 113.33 module: currentcontrol context: Global setting defined_in: modules/utils/currentcontrol/CurrentControl.cpp:63 corresponding_v1: digipot_factor corresponding_v2: tmc2590.{motor}.sense_resistor description: 'Conversion factor for translating current values (in amperes) to digipot wiper positions (0-255). This is hardware-specific and depends on the sense resistor values and driver chip characteristics. The formula used is: `wiper_value = ceil(factor × current)` (mcp4451.h line 63). For MCP4451 on Smoothieboard, the calculation is based on 0.05Ω sense resistors and DRV8825 chip characteristics.' description_bullets: - 'Used in MCP4451: `char current_to_wiper(float current) { int c = ceilf(this->factor * current); return (c > 255) ? 255 : c; }` (mcp4451.h lines 62-65)' - 'Different calculation for AD5206: `unsigned char current_to_wiper(float current) { return (unsigned char)((current * 1000) * 100 / 743); }` (not configurable)' - 'Board-specific values:' - 'Calculation for MCP4451: `factor = 255 / Imax × (Vref / (8 × Rsense))` where Vref=2.5V, Rsense=0.05Ω, Imax=2.0A → factor ≈ 113.33' - 'When to change: custom board with different sense resistors, different stepper driver chips, modified hardware with different Vref, after hardware repairs/modifications' - 'Testing: Measure actual motor current with multimeter, adjust if measured doesn''t match set current: `new_factor = old_factor × (target_current / measured_current)`' typical_values: - value: 113.33 description: Smoothieboard/Azteeg X5 GT with 0.05Ω sense resistors related_settings: - digipotchip - digipot_max_current - alpha_current - beta_current - gamma_current - delta_current related_pages: - currentcontrol - stepper-motors examples: - 'digipot_factor 113.33 # Smoothieboard/Azteeg X5 GT (default, 0.05Ω sense resistors)' - 'digipot_factor 150 # Custom board with different sense resistors (example)' - name: alpha_current type: number default: 0.8 units: A (amperes) module: currentcontrol context: Global setting defined_in: modules/utils/currentcontrol/CurrentControl.cpp:66 minimum_value: '`0` (enforced by clamping in mcp4451.h:30)' maximum_value: '`digipot_max_current` (enforced by clamping in mcp4451.h:30)' corresponding_v1: alpha_current corresponding_v2: current control.alpha.current description: Current setting for the first stepper motor driver (M1), channel 0 of the digipot. On Cartesian machines, this is typically the X axis. Current is specified in amperes and will be clamped to the `digipot_max_current` value (0 to max_current range enforced at mcp4451.h line 30). Proper current selection balances torque requirements against heat generation and motor/driver limits. description_bullets: - Channel 0 of the digipot - Affects M1 driver on Smoothieboard - 'Determining optimal current: check motor nameplate for rated current, start at 70-80% of rated, test for sufficient torque + acceptable temperature (<80°C) + no missed steps, adjust as needed' - 'Effects of too low current: insufficient torque, missed steps, poor positioning accuracy, stalling under load' - 'Effects of too high current: excessive heat, motor damage over time, driver thermal shutdown, power supply overload, no torque benefit above rated current' - 'Runtime adjustment via M907: `M907 X1.5` sets X motor to 1.5A' - 'Motor size guidelines:' related_m_codes: - code: M500 description: Save current values to config-override - code: M503 description: Display current motor current settings related_settings: - beta_current - gamma_current - delta_current - epsilon_current - zeta_current - digipot_max_current - digipot_factor related_pages: - currentcontrol - stepper-motors examples: - 'alpha_current 0.8 # Default, light/medium duty' - 'alpha_current 1.5 # Higher torque for heavier X axis' - 'alpha_current 1.0 # Balanced for most Cartesian printers' - name: beta_current type: number default: 0.8 units: A (amperes) module: currentcontrol context: Global setting defined_in: modules/utils/currentcontrol/CurrentControl.cpp:67 minimum_value: '`0` (enforced by clamping in mcp4451.h:30)' maximum_value: '`digipot_max_current` (enforced by clamping in mcp4451.h:30)' corresponding_v1: beta_current corresponding_v2: current control.beta.current description: Current setting for the second stepper motor driver (M2), channel 1 of the digipot. On Cartesian machines, this is typically the Y axis. All current selection guidelines from `alpha_current` apply equally to beta_current. description_bullets: - Channel 1 of the digipot - Affects M2 driver on Smoothieboard - See `alpha_current` for detailed current selection guidelines related_m_codes: - code: M500 description: Save current value to config-override - code: M503 description: Display current settings related_settings: - alpha_current - gamma_current - delta_current - digipot_max_current - digipot_factor related_pages: - currentcontrol - stepper-motors examples: - 'beta_current 0.8 # Default' - 'beta_current 1.5 # Higher torque for Y axis' - 'beta_current 1.2 # Balanced setting' - name: gamma_current type: number default: 0.8 units: A (amperes) module: currentcontrol context: Global setting defined_in: modules/utils/currentcontrol/CurrentControl.cpp:68 minimum_value: '`0` (enforced by clamping in mcp4451.h:30)' maximum_value: '`digipot_max_current` (enforced by clamping in mcp4451.h:30)' corresponding_v1: gamma_current corresponding_v2: current control.gamma.current description: Current setting for the third stepper motor driver (M3), channel 2 of the digipot. On Cartesian machines, this is typically the Z axis. Z-axis often benefits from higher current for stability as it needs to hold position against gravity and often has higher loads (print head, bed, etc.). May run slower so can handle more current without overheating. description_bullets: - Channel 2 of the digipot - Affects M3 driver on Smoothieboard - 'Z-axis specific considerations: needs to hold position against gravity, often has higher loads (print head, bed, gantry), may run slower (can handle more current), benefits from higher current for stability' - See `alpha_current` for general current selection guidelines related_m_codes: - code: M500 description: Save current value to config-override - code: M503 description: Display current settings related_settings: - alpha_current - beta_current - delta_current - digipot_max_current - digipot_factor related_pages: - currentcontrol - stepper-motors examples: - 'gamma_current 0.8 # Default' - 'gamma_current 1.5 # Higher for Z axis stability with heavy bed' - 'gamma_current 1.2 # Balanced for typical Z axis' - name: delta_current type: number default: 0.8 units: A (amperes) module: currentcontrol context: Global setting defined_in: modules/utils/currentcontrol/CurrentControl.cpp:69 minimum_value: '`0` (enforced by clamping in mcp4451.h:30)' maximum_value: '`digipot_max_current` (enforced by clamping in mcp4451.h:30)' corresponding_v1: delta_current corresponding_v2: current control.delta.current description: 'Current setting for the fourth stepper motor driver (M4), channel 3 of the digipot. Common assignments: on delta machines this would be one of the tower motors, on Cartesian machines with dual Z this could be the second Z motor, on machines with extruders this could be the first extruder motor, on 4-axis CNC this could be the rotary/fourth axis.' description_bullets: - Channel 3 of the digipot - Affects M4 driver on Smoothieboard - See `alpha_current` for detailed current selection guidelines related_m_codes: - code: M500 description: Save current value to config-override - code: M503 description: Display current settings related_settings: - alpha_current - beta_current - gamma_current - epsilon_current - zeta_current - digipot_max_current related_pages: - currentcontrol - stepper-motors examples: - 'delta_current 0.8 # Default' - 'delta_current 1.5 # Tower motor on delta or second Z motor' - 'delta_current 1.0 # Extruder motor' - name: epsilon_current type: number default: -1 units: A (amperes) module: currentcontrol context: Global setting defined_in: modules/utils/currentcontrol/CurrentControl.cpp:70 minimum_value: '`-1` (special value to disable)' maximum_value: '`digipot_max_current` (when enabled, enforced by clamping in mcp4451.h:30)' corresponding_v1: epsilon_current corresponding_v2: none (not standard on v2 board configuration) description: 'Current setting for the fifth stepper motor driver (M5), channel 4 of the digipot. Default value of -1 disables this channel (treated specially at mcp4451.h lines 26-28). Available on both MCP4451 and AD5206 digipot chips. Common assignments: delta printer tower B motor, second extruder, rotary axis, additional axis on multi-axis machines.' description_bullets: - Channel 4 of the digipot - Affects M5 driver on Smoothieboard (if present) - Value of -1 disables the channel (no current set) - 'Hardware support: MCP4451 (Smoothieboard, Azteeg X5 GT), AD5206 (4Pi boards)' - Set to -1 if motor is not used typical_values: - value: -1 description: disabled, default related_m_codes: - code: M500 description: Save current value to config-override - code: M503 description: Display current settings related_settings: - delta_current - zeta_current - eta_current - theta_current - digipot_max_current related_pages: - currentcontrol - stepper-motors examples: - 'epsilon_current -1 # Disabled (default, motor not used)' - 'epsilon_current 1.5 # Enable and set to 1.5A' - 'epsilon_current 1.0 # Second extruder motor' - name: zeta_current type: number default: -1 units: A (amperes) module: currentcontrol context: Global setting defined_in: modules/utils/currentcontrol/CurrentControl.cpp:71 minimum_value: '`-1` (special value to disable)' maximum_value: '`digipot_max_current` (when enabled, enforced by clamping in mcp4451.h:30)' corresponding_v1: zeta_current corresponding_v2: none (not standard on v2 board configuration) description: 'Current setting for the sixth stepper motor driver (M6), channel 5 of the digipot. Default value of -1 disables this channel. Available on both MCP4451 and AD5206 digipot chips. **NOTE: This is the LAST CHANNEL on AD5206-based boards** (AD5206 only has 6 channels: 0-5). Common assignments: delta printer tower C motor, third extruder, additional rotary axis, multi-axis CNC machines.' description_bullets: - Channel 5 of the digipot - Affects M6 driver (if present) on board - Value of -1 disables the channel - 'Hardware support: MCP4451 (Smoothieboard, Azteeg X5 GT), AD5206 (4Pi boards)' - 'CRITICAL: AD5206 chip only has 6 channels (0-5), so zeta_current is the last available channel on AD5206-based boards' - Set to -1 if motor is not used typical_values: - value: -1 description: disabled, default related_m_codes: - code: M500 description: Save current value to config-override - code: M503 description: Display current settings related_settings: - epsilon_current - eta_current - theta_current - digipot_max_current related_pages: - currentcontrol - stepper-motors examples: - 'zeta_current -1 # Disabled (default, motor not used)' - 'zeta_current 1.5 # Delta tower C or third extruder' - 'zeta_current 1.2 # Additional rotary axis' - name: eta_current type: number default: -1 units: A (amperes) module: currentcontrol context: Global setting defined_in: modules/utils/currentcontrol/CurrentControl.cpp:72 minimum_value: '`-1` (special value to disable)' maximum_value: '`digipot_max_current` (when enabled, enforced by clamping in mcp4451.h:30)' corresponding_v1: eta_current corresponding_v2: none (not standard on v2 board configuration) description: 'Current setting for the seventh stepper motor driver current control, channel 6 of the digipot. Default value of -1 disables this channel. **CRITICAL: This setting ONLY works with MCP4451-based boards** (Smoothieboard, Azteeg X5 GT). AD5206 boards do NOT support this channel (AD5206 only has 6 channels: 0-5). **IMPORTANT LIMITATION: This channel controls a digipot output but is NOT connected to a robot actuator in the firmware.** It can control the current of an external stepper driver but cannot be used as a motion axis.' description_bullets: - Channel 6 of the digipot - Value of -1 disables the channel - 'Hardware support: MCP4451 ONLY (Smoothieboard, Azteeg X5 GT) - NOT supported on AD5206 (4Pi boards)' - 'Use cases: external driver current control, auxiliary equipment, future expansion, custom hardware modifications' - Cannot be used for robot motion control axes (not connected to robot actuator system) typical_values: - value: -1 description: disabled, default related_m_codes: - code: M500 description: Save current value to config-override - code: M503 description: Display current settings related_settings: - theta_current - zeta_current - digipot_max_current - digipotchip related_pages: - currentcontrol - stepper-motors examples: - 'eta_current -1 # Disabled (default)' - 'eta_current 1.5 # Enable external driver current control (MCP4451 ONLY)' - name: theta_current type: number default: -1 units: A (amperes) module: currentcontrol context: Global setting defined_in: modules/utils/currentcontrol/CurrentControl.cpp:73 minimum_value: '`-1` (special value to disable)' maximum_value: '`digipot_max_current` (when enabled, enforced by clamping in mcp4451.h:30)' corresponding_v1: theta_current corresponding_v2: none (not standard on v2 board configuration) description: 'Current setting for the eighth stepper motor driver current control, channel 7 of the digipot (last channel). Default value of -1 disables this channel. **CRITICAL: This setting ONLY works with MCP4451-based boards** (Smoothieboard, Azteeg X5 GT). AD5206 boards do NOT support this channel (AD5206 only has 6 channels: 0-5). **IMPORTANT LIMITATION: This channel controls a digipot output but is NOT connected to a robot actuator in the firmware.** It can control the current of an external stepper driver but cannot be used as a motion axis.' description_bullets: - Channel 7 of the digipot (last channel) - Value of -1 disables the channel - 'Hardware support: MCP4451 ONLY (Smoothieboard, Azteeg X5 GT) - NOT supported on AD5206 (4Pi boards)' - 'MCP4451 channel mapping: Channels 0-3 on first chip (address 0x58), channels 4-7 on second chip (address 0x5A), theta_current is channel 7 (last channel of second chip)' - 'Use cases: external driver current control, auxiliary equipment, future expansion, custom hardware modifications' - Cannot be used for robot motion control axes (not connected to robot actuator system) typical_values: - value: -1 description: disabled, default related_m_codes: - code: M500 description: Save current value to config-override (if modified via direct digipot access) - code: M503 description: Display current settings related_settings: - eta_current - zeta_current - digipot_max_current - digipotchip related_pages: - currentcontrol - stepper-motors examples: - 'theta_current -1 # Disabled (default)' - 'theta_current 1.5 # Enable external driver current control (MCP4451 ONLY)'