[FeatureRequest]: Enforce maximum extrusion rate during printing moves in firmware

[timschneider]

Is your feature request related to a problem? Please describe.

The maximum volumetric extrusion rate is a hard physical limit set by the extruder/hotend and the filament material. Currently, RRF has no way to enforce this limit in firmware for printing moves only:

• Using M203 E... restricts all motion on the extruder axis, including retracts and tool changes, which have completely different (and typically higher) physical limits.
• Slicer-side max volumetric flow rate settings help, but they are not reliable enforcement. For example, OrcaSlicer ignores the max volumetric speed on the outermost perimeter when resonance avoidance is enabled, silently exceeding the hardware's real capability.
• Relying on slicer profiles contradicts RRF's long-standing philosophy of putting machine-level physical limits in firmware, where they belong.

The result is that operators either over-constrain the extruder (losing retract/tool-change speed) or under-constrain it (risking skipped steps, grinding, or poor print quality when a slicer setting is bypassed).

Describe the solution you propose.

Introduce M203.1 as a firmware-level limit that caps the extrusion rate only during moves that contain extrusion, leaving non-extrusion moves (retracts, tool changes, prime/purge) unaffected.

M203.1 should inherit the same parameter syntax as M203, including per-drive addressing for shared-axis extruders. This is important because extruders are typically mapped to a single logical axis via M584 (e.g. M584 E4:5), and the per-drive colon syntax of M203 is the established way to express different limits for each physical extruder:

M203 X15000 Y15000 U15000 Z100 E3600:3600   ; current M203
M203.1 E1200:900                            ; proposed: per-extruder extrusion-rate cap

A feedrate-style limit modelled on M204's P/T parameters was considered, but M204 does not currently support per-drive addressing, so it cannot express different limits for multiple extruders on the same logical axis. Extending M204 to add that syntax would be a larger change than simply adding M203.1, which follows M203's existing conventions.

Specification points to resolve (raised by @dc42):

• Criteria for which limit applies: M203.1 applies to any move where the extruder is extruding (positive E with concurrent XYZ/UVW motion). Pure extruder moves (retracts, priming, tool changes) fall under M203 E.
• Default value: M203.1 defaults to "no additional limit" when unset, so existing configurations remain unaffected. In that case only M203 E applies.
• Interaction with M203 E: M203 called with an E parameter resets M203.1 to its default. M203 calls without an E parameter leave M203.1 unchanged. This reflects the semantic that M203 declares the physical axis limit — any refinement via M203.1 is only meaningful relative to a specific M203 E value, so changing M203 E should invalidate it. The effective limit on a printing move is min(M203 E, M203.1).

Describe alternatives you've considered

• Slicer-side max volumetric flow rate: Works in most cases but is not a reliable enforcement mechanism. Slicers can and do override it in specific scenarios — for example, OrcaSlicer ignores the max volumetric speed on the outermost perimeter when resonance avoidance is enabled. It also depends on every slicer profile being configured correctly for every material, which shifts a hardware-level constraint into user-managed configuration.
• Using M203 E to cap the extruder axis: Solves the printing case but also throttles retracts, tool changes, and other non-extrusion moves that have much higher physical headroom. This forces a trade-off between print safety and non-printing move performance that shouldn't exist.
• Manually capping print speeds per filament in the slicer: Requires recalculation for every material and geometry, and provides no safety net if a slicer setting is missed or overridden.
• Feedrate-style limit analogous to M204 P/T: Considered, but M204 lacks per-drive syntax, so it cannot express separate limits for multiple extruders sharing a logical axis (e.g. M584 E4:5). Extending M203.1 following M203's existing per-drive conventions was the more natural fit.

Provide any additional context or information.

Forum discussion leading to this request: [link to the forum thread]

Prior art in RRF: M204 already distinguishes printing acceleration (P) from travel acceleration (T), acknowledging that these two move types have different physical constraints. This request applies the same reasoning to extrusion rate, while staying within M203's established per-drive syntax for consistency with how extruders are typically configured.

Integration with the RRF Configuration Tool: Once M203.1 is implemented, it would be valuable to expose it in the RRF Configuration Tool alongside the existing M203 fields, so that new configurations ship with a sensible extrusion-rate limit by default rather than relying on users to discover and add it manually. Reasonable starting values could be derived from the selected hotend/extruder preset — for example, a conservative default in the range of typical single-nozzle FFF hardware (roughly 10–15 mm³/s volumetric, translated to mm/min based on the configured filament diameter and steps/mm). Users with higher-performance hardware (volcano-style hotends, pellet extruders, CHT nozzles, etc.) can then raise the limit deliberately, with the awareness that they are declaring a physical machine capability.

This approach would make the feature discoverable, give every new RRF machine a reasonable safety net out of the box, and reinforce the principle that extrusion rate is a hardware property that belongs in the machine configuration — not a slicer setting.

Willingness to contribute: Happy to contribute to the implementation and/or the Configuration Tool integration once the specification is agreed.

[gloomyandy]

If this functionality is implemented I'd like to see the M203.1 command (or whatever command number is used) extended to allow the inclusion of P and T parameters which can then be used to set max feedrate limits for printing and travel moves (in the same way that M204 limits accelerations). The reason for this is that the current limits (from m203) apply per axis and not to the overall feedrate. This tends to be confusing as the actual impact on the feedrate may vary depending upon the kinematics in use. For instance with a coreXY machine pure X/Y moves have different limits to diagonal moves even though the same limit may be applied to X and Y in M203, which makes it difficult to set a firmware defined feedrate limit that applies along the direction of motion.

According to the documentation it seems that M204 only applies "for the current job only" perhaps it would make sense to make m204 and m203.1 be consistent. Similarly I would expect to see the way that m203.1 interacts with m203 and how m204 interacts with m201 to be consistent.

Arguably there should be a similar way to set the maximum instantaneous speed change along the direction of motion in addition to the current per axis limit, but I suspect that this falls outside the scope of this feature request.

[timschneider]

I was not aware of another open feature request covering this exact topic. It is a duplicate of #362 and only differs in the Details of implementation. So we can close this.